From srdonovan@usdonovans.com Mon Feb 3 15:55:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BC01A02B3 for ; Mon, 3 Feb 2014 15:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.561 X-Spam-Level: ** X-Spam-Status: No, score=2.561 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gXc2abS8Z1A for ; Mon, 3 Feb 2014 15:55:20 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3796F1A02A5 for ; Mon, 3 Feb 2014 15:55:20 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50018 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WATMC-0000vM-J1 for dime@ietf.org; Mon, 03 Feb 2014 15:55:19 -0800 Message-ID: <52F02C62.70600@usdonovans.com> Date: Mon, 03 Feb 2014 17:55:14 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------090502060007030709090101" X-OutGoing-Spam-Status: No, score=-1.9 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 Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 23:55:22 -0000 This is a multi-part message in MIME format. --------------090502060007030709090101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, I believe that the current DOIC Endpoint behavior definition is not sufficiently defined, especially for agents. There was also a change introduced in the -01 version of the draft that implies that there can be a DOIC association that goes through a DOIC enabled agent. This was not how I understood endpoints. The original diagrams showed a DOIC agent as terminating an endpoint that came to it. I suspect there were different assumptions that lead to clearly different interpretations. I propose that we return to the original diagrams and add the wording below on how DOC agents behave. One way to look at this is that DOC agents act as back-to-back DOC endpoints. I intentionally don't say back-to-back Diameter endpoints because this does not impact anything except the handling of DOIC related AVPs. Note that I don't believe this requires any changes to Diameter clients or servers. I also don't believe this requires any changes to the contents of the DOIC related AVPs but there is an open question as to whether there is a need to indicate when a OC-Supported-Features AVP is generated or modified by an agent. I propose to add the following section to the section on capabilities announcement. I'll send a separate email proposing text to section 5.5 on how DOC agents are to behave. Regards, Steve ----- 5.3.1 DOC Agent handling of DOIC capability exchange. A DOC agent is defined as a Diameter agent that supports the DOIC extension. A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension. An downstream DOIC Association is defined as the association between the DOIC supporting Diameter entity that sends a Diameter request message to a DOC agent and the DOC agent. A upstream DOIC Association is defined as the association between a DOC agent and the Diameter entity to which the DOC agent sends the Diameter request message. The following illustrated the upstream and downstream concepts. DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC node Direction of request message for a transaction -----> Direction of answer message for a transaction <----- Four scenarios must be supported: - Scenario 1 - There is both an upstream and downstream DOIC association. - Scenario 2 - There is no upstream DOIC association - Scenario 3 - There is no downstream DOIC association - Scenario 4 - No DOIC association in either direction Scenario 1 - Both upstream and downstream DOIC associations Request message handling: A DOC agent that receives a request that contains the OC-Supported-Features AVP must act as an endpoint for the downstream DOIC association. If the DOC agent relays or proxies the request message then the agent must include an OC-Supported-Features AVP in the relayed message. The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP. If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP. If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent must modify the OC-Supported-Features AVP to indicate support for those features. The modified OC-Supported-Features AVP must be included in the relayed request message. Note: any DOIC extension must define the changes needed to the OC-Feature-Vector AVP and any additional AVPs that need to be added to the OC-Supported-Features AVP as part of the capabilities advertisement for that feature. Question: Should there be an indication that the contents of the OC-Supported-Features AVP was changed? Question: Will this work when end-to-end security is introduced? Would adding a separate OC-Supported-Features AVP be better, especially when end-to-end security is considered? Answer message handling: When an agent receives the answer message that corresponds to the above request message, the agent must act as the DOIC endpoint for the upstream DOIC association. If the DOC agent relays or proxies the answer message then the agent must include an OC-Supported-Features AVP in the relayed message. The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP. If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP. If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent should modify the OC-Supported-Features AVP to indicate support for those features. The modified OC-Supported Features AVP must be included in the relayed answer message. Scenario 2 - No downstream DOIC association with an upstream association In this case a request is received that does not contain an OC-Supported-Features AVP. Request message handling: If a DOC agent receives a request that does NOT contain an OC-Supported-Features AVP then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent. The new OC-Supported-Features AVP must be included in the relayed/proxied request message. The agent will then become the reacting DOIC endpoint for the upstream DOIC association that results from the transaction. Note: Section x.x.x defines agent behavior when it is the reacting node for a DOIC association. Answer message handling In this case the answer message will contain an OC-Supported-Features AVP. The DOC agent must store the advertised capabilities for use when the DOC agent reacts to an overload report from the upstream Diameter node. The DOC agent should remove the OC-Supported-Features AVP from the answer message before relaying/proxying the answer message. Scenario 3 - Downstream DOC association with no upstream DOIC association In this case a OC-Supported-Features AVP is received in the request from the downstream Diameter entity but no OC-Supported-Features AVP is received in the answer message received from the upstream Diameter entity. In this case the agent must act as the reporting DOIC endpoint for the downstream DOIC association. Request message handling: Request message handling is the same as for scenario 1. Answer message handling: If a DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that includes an upstream DOC association then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent. The generation of this OC-Supported-Features AVP must also follow the rules specified in section 5.3.2. The new OC-Supported-Features AVP must be included in the relayed/proxied the answer message. Scenario 4 - No upstream association and no downstream association Request message handling: The request message handling in this case is the same as scenario 2. Answer message handling: If the DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that does not include a downstream DOC association then the agent must NOT generate an OC-Supported-Features AVP. The DOC Agent must relay/proxy the answer message with no DOIC related change. --------------090502060007030709090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I believe that the current DOIC Endpoint behavior definition is not sufficiently defined, especially for agents.

There was also a change introduced in the -01 version of the draft that implies that there can be a DOIC association that goes through a DOIC enabled agent.  This was not  how I understood endpoints.  The original diagrams showed a DOIC agent as terminating an endpoint that came to it.    I suspect there were different assumptions that lead to clearly different interpretations. 

I propose that we return to the original diagrams and add the wording below on how DOC agents behave.  One way to look at this is that DOC agents act as back-to-back DOC endpoints.  I intentionally don't say back-to-back Diameter endpoints because this does not impact anything except the handling of DOIC related AVPs.

Note that I don't believe this requires any changes to Diameter clients or servers.  I also don't believe this requires any changes to the contents of the DOIC related AVPs but there is an open question as to whether there is a need to indicate when a OC-Supported-Features AVP is generated or modified by an agent.

I propose to add the following section to the section on capabilities announcement.  I'll send a separate email proposing text to section 5.5 on how DOC agents are to behave.

Regards,

Steve

-----

5.3.1 DOC Agent handling of DOIC capability exchange.

A DOC agent is defined as a Diameter agent that supports the DOIC extension.

A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension.

An downstream DOIC Association is defined as the association between the DOIC supporting Diameter entity that sends a Diameter request message to a DOC agent and the DOC agent.

A upstream DOIC Association is defined as the association between a DOC agent and the Diameter entity to which the DOC agent sends the Diameter request message.  The following illustrated the upstream and downstream concepts.

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node
  Direction of request message for a transaction ----->
  Direction of answer message for a transaction <-----

Four scenarios must be supported:

  - Scenario 1 - There is both an upstream and downstream DOIC association.
  - Scenario 2 - There is no upstream DOIC association
  - Scenario 3 - There is no downstream DOIC association
  - Scenario 4 - No DOIC association in either direction

Scenario 1 - Both upstream and downstream DOIC associations

Request message handling:

A DOC agent that receives a request that contains the OC-Supported-Features AVP must act as an endpoint for the downstream DOIC association.

If the DOC agent relays or proxies the request message then the agent must include an OC-Supported-Features AVP in the relayed message.  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent must modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported-Features AVP must be included in the relayed request message.

  Note: any DOIC extension must define the changes needed to the OC-Feature-Vector AVP and any additional AVPs that need to be added to the OC-Supported-Features AVP as part of the capabilities advertisement for that feature.

Question: Should there be an indication that the contents of the OC-Supported-Features AVP was changed?

Question: Will this work when end-to-end security is introduced?  Would adding a separate OC-Supported-Features AVP be better, especially when end-to-end security is considered?

Answer message handling:

When an agent receives the  answer message that corresponds to the above request message, the agent must act as the DOIC endpoint for the upstream DOIC association. 

If the DOC agent relays or proxies the answer message then the agent must include an OC-Supported-Features AVP in the relayed message.  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent should modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported Features AVP must be included in the relayed answer message.

Scenario 2 - No downstream DOIC association with an upstream association

In this case a request is received that does not contain an OC-Supported-Features AVP.

Request message handling:

If a DOC agent receives a request that does NOT contain an OC-Supported-Features AVP then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The new OC-Supported-Features AVP must be included in the relayed/proxied request message.

The agent will then become the reacting DOIC endpoint for the upstream DOIC association that results from the transaction. 

Note: Section x.x.x defines agent behavior when it is the reacting node for a DOIC association.

Answer message handling

In this case the answer message will contain an OC-Supported-Features AVP.  The DOC agent must store the advertised capabilities for use when the DOC agent reacts to an overload report from the upstream Diameter node.

The DOC agent should remove the OC-Supported-Features AVP from the answer message before relaying/proxying the answer message. 

Scenario 3 - Downstream DOC association with no upstream DOIC association

In this case a OC-Supported-Features AVP is received in the request from the downstream Diameter entity but no OC-Supported-Features AVP is received in the answer message received from the upstream Diameter entity.  In this case the agent must act as the reporting DOIC endpoint for the downstream DOIC association.

Request message handling:

Request message handling is the same as for scenario 1.

Answer message handling:

If a DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that includes an upstream DOC association then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The generation of this OC-Supported-Features AVP must also follow the rules specified in section 5.3.2.  The new OC-Supported-Features AVP must be included in the relayed/proxied the answer message.

Scenario 4 - No upstream association and no downstream association

Request message handling:

The request message handling in this case is the same as scenario 2.

Answer message handling:

If the DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that does not include a downstream DOC association then the agent must NOT generate an OC-Supported-Features AVP.  The DOC Agent must relay/proxy the answer message with no DOIC related change.

 --------------090502060007030709090101-- From ulrich.wiehe@nsn.com Tue Feb 4 00:04:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51201A02A2 for ; Tue, 4 Feb 2014 00:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxLMjWxYUtx4 for ; Tue, 4 Feb 2014 00:04:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 234211A018E for ; Tue, 4 Feb 2014 00:04:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1484nDh023190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 09:04:49 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1484n0f019570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 09:04:49 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Feb 2014 09:04:48 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 09:04:48 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" , "srdonovan@usdonovans.com" Thread-Topic: [Dime] [dime] #23: DOIC behavior for realm overload Thread-Index: AQHPFrzwmz+sjQyANE6AjPwpA+4fnZqk0H3A Date: Tue, 4 Feb 2014 08:04:47 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1CF5@DEMUMBX014.nsn-intra.net> References: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> In-Reply-To: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1962 X-purgate-ID: 151667::1391501091-00001A6F-D68AA7BE/0-0/0-0 Subject: Re: [Dime] [dime] #23: DOIC behavior for realm overload X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 08:04:57 -0000 Steve, could you please explain why you propose to align in this direction? I would have thougth that realm type reports apply only to requests that co= ntain that realm but do not contain a destination-host. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Tuesday, January 21, 2014 4:25 PM To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #23: DOIC behavior for realm overload #23: DOIC behavior for realm overload This applies to draft-ietf-dime-ovli-01, which does not show up in the Component drop down menu. The current assumption in the -01 draft is inconsistent in the definition of behavior of behavior by a reacting node when it receives a realm overload report. Section 4.6 says overload treatment should apply to all request bound for the overloaded realm. Section 5.5.2 is not clear and there have been interpretations that a realm overload report only applies to requests that contain the realm and do not contain a destination-host AVP. Section 5.5.2 should be updated to be consistent with section 4.6. --=20 -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: draft-docdt-dime-ovli | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Tue Feb 4 00:14:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640A31A033D for ; Tue, 4 Feb 2014 00:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-TSXjSg_x3j for ; Tue, 4 Feb 2014 00:14:00 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B58061A018E for ; Tue, 4 Feb 2014 00:13:59 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s148DvSe006737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 09:13:58 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s148Dv1j020040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 09:13:57 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Feb 2014 09:13:57 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 09:13:57 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Open issues with DOIC Thread-Index: AQHPHsNfLmhPdpctmU2ow205pjRSvJqkwo9A Date: Tue, 4 Feb 2014 08:13:56 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1D0C@DEMUMBX014.nsn-intra.net> References: <52EC0806.1040101@usdonovans.com> In-Reply-To: <52EC0806.1040101@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: multipart/mixed; boundary="_004_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 39718 X-purgate-ID: 151667::1391501638-000025D0-89AB14F9/0-0/0-0 Subject: Re: [Dime] Open issues with DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 08:14:02 -0000 --_004_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_ Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_" --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, thank you for your offer to enter tickets. Please find a document attached that outlines some issues. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Friday, January 31, 2014 9:31 PM To: dime@ietf.org Subject: [Dime] Open issues with DOIC All, We have two weeks until the February 14 draft cutoff date for the London IE= TF meeting. We should attempt to have as many open issues resolved in a -02 draft as po= ssible. To this end, please open trouble tickets that can be used to track the issu= es. I have had to open the tickets against draft-docdt-dime-ovli, as draft= -ietf-dime-doic does not show up as one of the components. If you can't figure out how to enter the tickets (it requires a tools accou= nt), I would be happy to enter the ticket for you. Just send me an email o= utlining the issue and, if appropriate, the proposed resolution. So far we have the four trouble tickets that I have opened. I suspect that= there are other issues still lingering from our discussions before the hol= iday break. Regards, Steve --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

 = ;

thank you = for your offer to enter tickets.

 = ;

Please fin= d a document attached that outlines some issues.

 = ;

Ulrich

 = ;

From:= DiME [mailto:dime-b= ounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, January 31, 2014 9:31 PM
To: dime@ietf.org
Subject: [Dime] Open issues with DOIC

 

All,

We have two weeks until the February 14 draft cutoff date for the London IE= TF meeting.

We should attempt to have as many open issues resolved in a -02 draft as po= ssible.

To this end, please open trouble tickets that can be used to track the issu= es.  I have had to open the tickets against draft-docdt-dime-ovli, as = draft-ietf-dime-doic does not show up as one of the components.

If you can't figure out how to enter the tickets (it requires a tools accou= nt), I would be happy to enter the ticket for you.  Just send me an em= ail outlining the issue and, if appropriate, the proposed resolution. 

So far we have the four trouble tickets that I have opened.  I suspect= that there are other issues still lingering from our discussions before th= e holiday break.

Regards,

Steve

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_-- --_004_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Open Issues with DOIC.docx" Content-Description: Open Issues with DOIC.docx Content-Disposition: attachment; filename="Open Issues with DOIC.docx"; size=23813; creation-date="Mon, 03 Feb 2014 11:55:27 GMT"; modification-date="Tue, 04 Feb 2014 08:13:06 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQB8EO49fwEAAKQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lElrwzAQhe+F/geja7GV9FBKiZ1Dl2MbaAq9qvI4EdWGNNn+fcdOYkoWhzbkYhBmvvfmzUiD4dLo ZA4hKmdz1s96LAErXansJGcf45f0niURhS2FdhZytoLIhsX11WC88hATqrYxZ1NE/8B5lFMwImbO g6U/lQtGIB3DhHshv8UE+G2vd8elswgWU6wZrBi8kYGgSkhGIuCrMKTD5SyiM59Gc4VgRsH52M8I ypLHdXVtIGfCe62kQLLP57bckU5dVSkJpZMzQ4JZC615EFBBvKmZvBg8QSVmGpPnJVlbpxFAx7/J bbrMqLKxFKfKdyl097NxdiidhQslb9vqxpyOpab54CTESHM3OmvJRii7Teioj4grDfHs4ey5WHO7 5Mlnsxmc1uBsfagnX0KZUhQ7y3G8dUCkyC7R/Ibc1X6zBUh3DnjzPf+CNJiTkhXdwLH40nB25nsz b9EnTSzg6/1i6f+Cdxlp90+68I8wts9FXX1g63jzxhY/AAAA//8DAFBLAwQUAAYACAAAACEAHpEa t/MAAABOAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIyS20oDQQyG7wXfYch9N9sKItLZ3kihdyLr A4SZ7AF3Dsyk2r69oyC6UNte5vTny0/Wm4Ob1DunPAavYVnVoNibYEffa3htt4sHUFnIW5qCZw1H zrBpbm/WLzyRlKE8jDGrouKzhkEkPiJmM7CjXIXIvlS6kBxJCVOPkcwb9Yyrur7H9FcDmpmm2lkN aWfvQLXHWDZf1g5dNxp+Cmbv2MuJFcgHYW/ZLmIqbEnGco1qKfUsGmwwzyWdkWKsCjbgaaLV9UT/ X4uOhSwJoQmJz/N8dZwDWl4PdNmiecevOx8hWSwWfXv7Q4OzL2g+AQAA//8DAFBLAwQUAAYACAAA ACEA37VMthABAAC/AwAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsk09LxDAQxe+C3yHM3aRddZFl072IsFet4DWbTv9g k5RkVu23NxS228WlXnoJzAt57zfDZLv7MS37Qh8aZyWkPAGGVruisZWE9/zl7glYIGUL1TqLEnoM sMtub7av2CqKj0LddIFFFxsk1ETdRoigazQqcNehjTel80ZRLH0lOqU/VYVilSRr4acekF14sn0h we+Le2B538Xk/71dWTYan50+GrR0JUIEJIqdheipfIUk4aTwyAniOsJqUQTq2zjDM8BQz8WnS8br YyBnPmKzIwHnYlRFQ2jSOZr1kjQU9wTPJEMphnOW4XFJhtJZytWhnXCM0twgHpaE+MbD25/dnIgn EHHx7bJfAAAA//8DAFBLAwQUAAYACAAAACEAoLWljgIrAAAOOgIAEQAAAHdvcmQvZG9jdW1lbnQu eG1s7F1tb9tIkv5+wP0Hwl/WBiJH77K9ax1kOd4JMDvJOc4O7g6HBS21bWIkUUdS9nh+/T3VL1Q3 RVJixnESqhaLSSJRZLO6ul6fqvrbf/w+n3mPIoqDcHF+0DpuHnhiMQmnweL+/ODzzVXj5MCLE38x 9WfhQpwfPIv44D+G//5vf3s6m4aT1VwsEg+3WMRnj/j2IUmWZ2/fxpMHMffj43ApFvjyLozmfoJ/ Rvdv537022rZmITzpZ8Et8EsSJ7ftpvN/oG+TXh+sIoWZ/oWjXkwicI4vEvoJ2fh3V0wEfoP84to l+eqX17qJcsnvo3EDGsIF/FDsIzN3eZfeje84oO5yWPZSzzOZ+a6p+UuT5tG/hP2Yz5Ty34Ko+ky CicijvHppfoyvWOrWfZsTUC6RfqLXZbgPtOsZO4Hi/Q2xB2Z/U837xib91Y9+y3dav0ioMUQvHQb Tp/pz6X3dAZenF6fH4AneoNBHwypP/qIjW42WyftVu9d+uGluPNXs0R+0xuM34Fd1eUfrY/knT9G 8o9PyfNM4JpHf3Z+8JPwidNbB2/pu0hdMvMX9+YCsWh8/kTfvtVf48+luizKXdeu93k6S4YfcDy8 93G8ErH3FCQP3uWH92N6UqKeJ/+7lKs2z7Jeynz0ImSp8upEgm2L2nlbslRUe1iBiiQ2zuKlPwH7 LSMRi+hRHAxvHoR3F85mIR0cj+SQFyhC+8vl7NlLQs8hNHaXnpkMcdYgawKR3DWmwVw0wsdZ0Gi2 vMNLMRHzWxF5rcEbr91sdY6cG7woUTSHLfN4ta250XChWnbr2PM+jBufxP+tIL5F45eVXGuwkJ+u lsswSsS0cSX8ZAUifb2lazKOJhMcc6I9KJ1gMyarKCJdMRV3wSIgqeuFd/IbWvbGAr3RPz96WD39 lMgvt8VZNXbMnAA6FOPL1mlvJGVJMnyz5caTcJFAdMWer+iToRqefew8K3dz9RPNIiyOd7/JCiJF oWK29VfJQxgp6gSxl2rZWzELxCNERfLgJ3mbTSKkYMPB/Bv8bhZO1Otfdq4ue4p6+SvzFmHiLYSY iumbvLspNlzFYga1BLpOvUm4mk29W+HNg3im5Kz8HFsaCZgEwoMSW4YxvVHoRWIePoq817qLwnku F3/1PZJSJOU+L/afY+LJyczHe3rd49bZdi7RlDXEVsL69KrZG4+Mprq2WMe9XLKOtTf6zCf+bSzp 7d/ivlKRzcRdQvcDPc8PTlt9pdBwYe4FrZOOFCMQeAVXtAfdk/J7dPr9bvkV3d5Js/yKXvd0y0r7 3daWlQ467S0rPWl3t6wUBNuy0lazOdiy1Fbz9HTLWlut0+aWxbbaWG451VqdQXfbcrv9nlwuGROa W0hHkkB+OoOGE2RLEcPMArLb2rih/sf1aoYPIIRCtQptGURXkJkwU878eBIE5wfjcBUF0Ia/iCf6 pfDjZBQH/vnBDbRmTB971+Hch3n4dPYwWsSbP5mAU+27SBMs/gPXS45u61eM/xjTY53PNi00ZwlT 0bh8R6vH28vlk/zONdr0QaTDVIf3JAOGLJ8cS0Dq09iD4JqSuA0W02DiJzCEHwQJZKkwSS1CR+9g Hbhi6pqlmi1+WaqRa+VoJJZqGQnGUk1JdOVfl0tvSLUCm9Tb7kM8+LE3eYBHD7mHcMlEeDOoKi+B lpIybxFOBVtx5PoWWIJsxW0IM7bi1oYfW3GOZfoScr1M3kGCzVbwwbcEOA5jIbxPYiLjLN3j7hHC Q6MZ4gqr+weWdiztoHBlpIB9VvZZv7FvXibtYgE3lWLIpT4togxTPwmjZxMwdiLKLO5Y3LG4czws DtHZcUeQ5hWN2DJxZ7JzlPxSKawIScfgkUQg+aneP0b/5fmzJ8pDTB5CpE5kKO9+QckUyEgWdSzq WNSxqPtOsi5loi7WKXdvoYEKd16QeBPk46cCyak5slLS6rtTgAUvVggBHcrjDEVZ+pcjdhyx47zr 92LUhZRefQpi8ZXgKjJt7sImFZgHelAiKS10yUV/cAUAgv6mKjApEb8nHgKLcwnYCeYSR0dYJHLP I0EQM7JUCcQIDPF0GQaL5A0lmBf41tixkPCEwKPkM2HAItIDyMcAMxD79yTzcb8sPCsXHfamFNB0 0u3QmypUEsGW5JpT3eJYyqCTvK4gyZS91tCVcFP2Y/J/bvLrvpevyrxwAmgcArqHAvAtxNVvnz1o OTH5zQQ+EF9eCZPoUoSkXJbBrGkFWrbKy0HvFJBZRYzDsivt9xkCnnXr386ey37g3NpFRIKs1Ujl +fcEyks8H4hzuDRTT776Gw9oOFBFHiRvtYiXYhLcBfh6LvxFjND2T+ETgHHRGw/sA6Ab/k9gNQAQ Qa3k2LspZk9v7oPcZS/Y77RHgGop2gWpq7VBfywAEFNjxdDzU2ZLMRZ4D/piGyuceaVLjvXJ83+T WEChqGQYBLEv7UY2/om3D6Oyl7N3L599PaRPU57TeExzZsvubJOt4M6QDqHnAye6Aiz0EKQDTokQ oiRNgBIlVLd+NSkwRHykZMka+q4Fj5QgSHBgn+EHy92XSEUAgBWupUA2kfP82yJ88p7K3kTjzRUD uMmTDIfb7zxUqBofGEfxGIQroqKSdFq4gX3pRWMfeWgs0/emwd0d1g8CqAOvkJzuXgJ5eSyOU37C DfDCT9giX24SfqtS3TuoGr1Yc0ItJTHuD/oXKMdQ6iNfSQzfJx5l1m8FuN6P7lfydcpVQRmRR512 x6B3C9iFTuphuCSt4c9mz0d49gJY4sST+FCiJUgNBkKGH8Biv/RQ23w//LTrwoZG5Jb9wLn1L2VX 2u88VF5QCYI3PisVCkSdBx8AWi05iR5ZMDiBcl1+yp7uTXYte4FuqzkeaNAwINe4fdnV9usWbHHW VMApfjLnpuzW9kIKbk30KBIDTxKoLCuSVBxNHqbgETydJWHKa9bKPFW7QU/QxM/86q+e915C3Z+h bpLJA4QdneJFqE8r8av2b/FIbSbExjA40lIu17zy1NotvZQK68xO566cOIKgzNbasz+DbLpbRbgg Iri2rjn6K2k6fPYMdPriL7DerNfyd3srE98se63VEnkdZ3VlXNBrAqN7qjV1Zgsk8DzzarLiht48 JZkUvPFaoNibbJNKrWvjMJG62aTVsffrQ4CKI0gqqKapuPWBtKEKJAt4ORXxJApusfvYjYmPHcGl ETC1kHW4tuytTy57nZZ5a0XUdd2LLnmRgoEsDyWup1MISuBAd0Cv67vnaAn3m3wtkX8W3wNBHy7u gvtVpKrviBT64E1Q4gAtNg1h2tCCTdiHfAqSMDAR6fvDUevIg/dQRpjmVX/cvtTs4GevLDP4UZj4 oJhAL0eWJ+Qz6qE4vj+GMYiio+hIWpMJ7DJ1ZEPsslRF2EkgMbKukeRJ2Lsigkko61DyFklotWt4 U6DQ9CPe/gI3+036fMmwvGzm8C6I4uQIfOS6WBr6i/Vkn2e2mTybi1Gz+U6TL38fwdFuHG6LH7Up 4giUgi2G2YcVYluzK5XmYCq4pKm03hEps8h6UsRf094H40hxRdsIJnl6CCBzzaeGgdpHpdxjv/6Q tpTKbiAq9J4qsZG3q8feqE2XwhmQW5vWGOU6sSZjXUKE9XYRwc2JsBXFoXpDMgFuYTqndqSk3Kj1 l9wf3a5IbGujgV5HklftBEwo5VWWMYhj6JR6fjYt81npeGMvys5n2aq2P+uTBIGqDSw50+ZIlz6s 2R6NWkrE5L9Yg2SbHf6QlN7k+MYGAaqdRQTOSVwqb8ZSLH9u9YpIeVwODoexrzgcrEgXOqALrWpj u4wvh8eh5YIpTj6iQbNSCtjMlk9pyOhdX3YIPZ05JS/7plLwGmkGn02dtDsp3hYJqk9VzEcRUT06 nxO1ZbJ2HnWYDOlfVcFISkXpjgJdII0cf8OOlZZOGb1a416zdSFZ+zbSlTR0Jp2QzsVW/vdQgCuL S7BIelFtIJc9eftWK//YlXoIJohoGSF3NCWnRkRRGB3JyFHZs3Z6y+0LgvoC/4IDrVdUiyQpq7dg zXF+HIeTAJbttJRlrcUlQ32gPBXToRer8l7FmbiH4J50JY6zs0Hr1a8WczSDkOE2dw1ujCHDGdtp 5r56boGtJoCRhFaIwv0m3/gcws6MV3P0m3hWZnHWJShztsn+hukGF034cH5wZMlNUvUDZQdWy+F0 h3VgJteXPCxbAGJd1BCAnqUkZAKpoeqlC6xJKZHTAFrmZWFpvaMApdRG8YrsIc2EFISnCBLgoHGw xddoN5u9d90yfUdxWrEAM8lKQ1p9sVpIX/AygBmH4+u9l7pgtzeFHyDgP2jlk3ldRIIhdJVvHCfB bIatk+kK5QTpOmYSFFs207uVzhjsrrXzSzal+hnlNLCAjF95iGWlZwrXptFs9/wcuQco9wRoguec APebohMgXU5ajFNvDX2d1lvTi9AWmdDWLyoQRdWCqeFtb6F5WanZX/oNTgaDdxcdyV+VOyDkWwXt TcvSEJOcnHG/d3I1Vgw9tF/TxNBTAwaJBlJkRv86wjd360bvOq2rSxNFtUu89UP1OuTWWeuISizf wqYKdxol4U/hhibINVJbnrcLcR8m0DN0xOeCIsNBPDcex7qsvSgs5rimBeYFgtQZykhEmikuBXcF keWyfBivw1taXeZLs8y25VLYpaNNYZf2VSh8g+OwW/8FhwMy2s/azqLKtezP5a4P6TTeUjqU4vna 7pbAPwmMCZVOkOI7WKimSrS30FUgpo4BBki5UqwKt3JPvbwIkXPkO9Y7TjdXkRa6g4pFFJ6D7Jrt k+REWyqFBTZY6E8+ZriDVHIZpCrrDMeqlwkZ8gv5H/Sa0ScQe4HcFdBLSOgWvYhTLS2Nal2b/iOX 2MPEHH74+fpfl++uRp9/vvnX6Oe/f8gSoES0IYvrXJ174pvtbq/fy5Op7jdVTvxofdIc4AIOEDxc HbOCMUgb7azQOvO8oZsNmDxyfWA/q1icdTwkJaW7BkGHY4Lzr9xc+LJvyT5L/0WGCViKYgg6KL8W XLRXDQMyiY+9axtgsv6dR2ZfMAnI6TYtD9JwGBnUvKU4aWm7MfB0yRn1yLonFeVuQ4r1+asM2a+3 TwUmsIMNx5ws+HXRTpCd1m32Rt22stPyDT0rlvlExi2lTmI3wWEd2Mw9ZYSDyOAfUZIVuQiIceJd WFOz0C9Na1pLS29ze6RAUPIuqRARle+DtdCr5OUO0gwJYZtI/afhBQoswIhInig1j92i9B5IQlkl xKKVx3MrkBIKEAY7nIZy05KHKEySmTiSxgQeK6PBOJq3OL/qtzuoVU0LYxdYDrv7Tb58HtLrrs1S 022pWrsl90FbG5O4l8t16Y/oHHC7JcSBMp08uN1STsOtFrdb2td2SwrZkaoMhAjvkfaVgIhshjXX pnUlEAssp20Qd1LakL/cSYk7KR2Y3nhV++Ch3V8xnKTAsAYa3V/6qlG3tv7tyNQ/Pn+6AYoXISvk ciX8OTVNyfeSkUjHtGcp6LZG42qtrInJXTKtxpqvWJpOJ3NPumQWyjoZA6T4+QQhBMQBZEhcoSye lVMvhwbA55ZRKVXDsMBXOodZWdSVO8mWM5oiL+oabSzcE5N0MylxhFV0DdBkHR6hTMZrhCjw8AdV bkShEmDJEGcK4sTZ90yk6bTXvzoZ6CzjBpi3JOC2QPGSc+NddGc5Q1mpqbJQnxN5khkoGQ53FpN5 y+5pe6QRQwVJL3mksHe6qY88as5pUgn7BdVyYWMn4f0i+EMCpTU2RaJsieyr5X3kT1XgS4fo5eHc iVxqnXlBKueb/CBVPpN+2kD0xd4hxbJVuzaSHxtva6GF7eIfCT5Owic/opJFisSptyaZVEZ+JwEX ll1ps2P+6xC5kfyQS8neSbIrJSrh8mrEKeK8ClXrpkzkG0uQC9KZqkIAAXe9Xdg7nRNAWZeUt7II YwM8TRQoCBj/VaYY6AL1dI290bcAl0iwro3Zse3WQ1+3wzMrMpt0pER/ebB2jKbj5UAYw+V45cKE aryDwNK7lcOu7jf57GqBoM68UQw4HgEGZXAbxbwCogv5Yys5Y3KXGpqkxi5kpmF4pn6FzukbDYpK 70aTTIC3kUhknQhFGFllgeQQhxiwPMU+2CIE2WUAm0on8iZvoKIzBO9Qfy9ZJodHUocIVS2hTpd8 hTIq47IsSGEHumssSg7d3W8k3f8McGXYOQY8U/U5o8RV9sCZFVDO4t1gMB6nVc33KLC+b9yo0D39 9T1AAdmfl6gXA87N/qTwiRl8PsknmSONHiUOyse/ZRoBa3Humau2XDLaOXj9lnoZWQIrteUUIAKb RXMkVB5EMh02XGYPF7k0ki8u1w4WBIMBNZ/21UxTXLlpF5msdMopyohApcd4AmW/dJ2WBYzBplPV w3pWyyG15fqU+PMlalv0aBRkP6lCNp2kopD+JPPWpPY0EpZQfPFK7YXM4yxFRCARMUVNApXWAtYv 76uXtM6HSlKgCp2qT5EoxaG07o6r1zdytjVjADRPOqdX5TNEkKbNBTrHUpWoSjQ8zwG3QHhEqH6R OS6gBBFpAIiRBAgWqVN1vhIi2EmrYixNnJWteXQ6uDhViLNkKBWWySmX/WqHN03BjZgwRoAeZEF3 EDr6xuYAWqac+03Bmcju8h1yg7f+5Lc1+qvsrWxa5NsFmotRPUa12TgLxIip/KZ/rFW1MhpDae05 iXz8jBTHs5HJ4Fr3l842UEug3MqGdHvdy8E9OLiAY4OPpyQf1c2Bck7wN/q33JlI3MPAIp5ac7oE H6z/ucN2aYrlbFev3Xw3SpEqBdt1A4JtbhFBFqINMW6eQVpg+0bRlCA0b1jFyYKm8WR3XdlwIDxA shIRVr4FoBL1MqAYHznGqq0Cth9l+RC8kUw4r+m2BgnkStDDCQ3PwVygZ5xjnA1l61O6fhdArEtX W2n0rjAUZWywQdUo7s9idCIgaJxUB74qkPSu3/2n1zpRONjrq7E3aPZPduAKdyWV1/g+ha3T9pD0 3dRudGDIVihTb1KtSVJXVFoOt+Sq7i95w802NZXuoi8mzq0MDR52ycJylS3p2oZUtqrdghrAB0op 7NB2GrgC2d7li/Ggf7ILJ25iHdLJUl0XupK7C+5ztmYO3cvlAdEfWUQ1s4KKhgHwZCknP8mTpeQc Mp4sZVfG1TU+O7yiQXykeu5WCzlZwKfhvagcQhScPIvHQDypUiuKeGQELjlBlCvcLlldQcVyzZE4 jIhgREQ6d0/aVDwxjzjiyxERBckKT4Ywpf0MRwkRhnDReAxpXjj1cllMCGJM7qRsX4ZgRIq4BdY2 FzfMNhzjHtREzSLjmnEPjHtQHPJ1ZHpxFwBgvNBPAvmytJaD8pcCSFZVeyCNPoRzYP0h4E//ousR LZZV8vRvmHds2cELKDrbjPJilBf35P5eenJTlsDrdxu3iLD+cvNRTgONKfPm/Q8Cvb3TZu9/aWLe DQRbrP3YdFCBqgVlYcfCDjkZHqIHNyjhwe/fesB9mWlHqI2AuqkrpMNqESAVkuuvblqBO6S7OFxX Igk5XMfhOg7XGad2jCyrqp79GuE6k3HQlhpMPEBUE8TpdJcJCL7GFIJQpy4IVogWYrqlPkrk2aQr EWTsv7L/yv7r9+K/ZpxScknRqBJdHVP55th3BtOoRCLgdCzqWNSx9woKsPcKIjx8394rIainAIHD OwVCXf6L3VIJ4fVvjT3tYETYVmNb7fuy1Rj7wNgHxj4Q5jz2fsFMs+sQwQeqVfjmqpdO5n70fPiS zje/0vAW3WmewF5Zv0uhXWlMWOYbCXWFD8aOFjtaOOacJmRH63uQ9mVpwnsZKdejYHy0tMmKtKWe ZIvKSgwBR2tY02OWQ+dqHh+7Y2F8ftBqnp622dhjY28crtLUJ4TfKzYyKxNz61i47nGCrhWwy1EW vphiNIYCuGLKI80WUmXRTxH6H0aYUo4glGzLwEYdG3Vs1IECbNR970adC25Vc8dl24bfA3TkEjDl +ifeM2bcxbt0X2CoV4ngY6gXQ71Se+cVKjN3j6lnjq3VVcj9Jts0xQQGVXxws9c0XhKLiOhrE0bc ZVE7P7+sQeWvajomgPzWZDvZLoUGoQQTalAEvOu9wNB76oCEv8fPiwmAEuiC9RyuJDgsxIgimHTy i0NqQbfRkcZtnZP7duNB7/Tk1DSesRuBuN9kqbvuY5bp8WLa3aW1Vp9MCYIeziirF+Ctz/JLGA51 CQN6gKl2Y6YLkirUR48TZfBSbJNKt2jEEvUOo5JWZFr1+Lh12z25DrpK9UhB5YT8vaqXcObHkh0N etIEoKWaOogORIgT6Nl0pS0VW5edi17zQOY1C7pPZVuzUYspxxYHM8rf7zICrn/ZP7lo522b+43c tsFlszVQ05Ard5/Jf5leplVpppea9cCi+uQP6JxEw4m8fwRJcK+mPF6a2e966iMat3njWYBCPYdO uXysHwmLJoqDqc3H7jdZgpSdUiqgWXe5SRvDmwZLxH2dv3/8CI6REHWaWkknNTul0GnxJVs0mU6E 6dQjz5/DQ5PHWRIFePeVBHqq9k3r6yaSHChvRAzLu7n22qfHJ81TM2Sof9w9Huw0i84lysuQ6xPq yjVFcMaJOnMfx5VaDK/m2EqcLUmKzb5Qa4rihzY1cWbwHUkAhwMy7NbudEZd01cyC4U1pyqfkdH/ zQyU9JLn5caBNPxEjcucx+gtuBVou3WUXdzOx7jSNlyMmuOO6lD4Qse4X36MrQcWHeNPAvI+CSay khZ9U1SHxMYNSLljUa16KUNnW7s638hzay1Ii8obdG6lVn5p66m+h8Z5CH1Q1727FfXRE78vZ8SH OJmq/6Q+fViykUESZk3HN7uRZlm0/c3L5qBb3jUXHO579+gmSkMBqVWk5CkPLguO7S7tcvUzzGMt arjfFFDjo+y15s92aL/V7XSuxmmbL1sAuN/IJ1mvrjmPO23dJaR9ZWqMh4rxULFPxA3riNJUNC7f URoBxsp2F8M9clsOo76YdAwfRp7wh5RVB71Dt6SsXnzCH0aLgOGDKTQjcb6aOn5+8HkWBQDy/xqI B0GfU+dzam/U6jaa7Uazc9ManPVaZ83mf6sFRz/y0GhyRPYDfVRk/nle0/NGGCkCR1lZPLrvwKZp 5cUPckYCGUOYw0tTbmUncnfaeq5vx+JR2Rkco/1hYrRr8diqLB7btROPa2rIkNUXKAuydqTLJ40p /P1H1htlCX407lOhXFKjiCTppD0+dHxTyEkQlaiypm3nCzmtbrQdUit01dwQEWSK5Jpi6pXY8Iwl FVnrcGaQDo8CurZOmydbzOk2WmdvueTbGuXdL5QFMvP3QwvXtVG+loxylEUlraN0cN0kY0EMHDrH 8/wj2TDsEuNeMBuDpGbjJzLrqfO1TPEJzOBJx6aYDAaN1AjQRxF++MoNnhsNxbKVZWu9ZGu/smzt 1tiiH1Smxv7JVohXOUFSQXK3GvInlUnakQy2J+pK6hrjF32IgvvAUlVIwVHmmUAccqqfnr6bS3NW Taya6qWaJJCrkqFbZ9XUqp6aUOTYE0FKZn+uYLSjSq3qAcy90kbbCVg95rlnXLidhNVDm/XkQUwu xwQDml4ARBP1xIWpo0b+kZ++0VeIg5snWxLjnFL7EVNq1aObvRp74K3q4c09UzCwc25VeHO7qqke 3VG8tR82o+N7bydm9eBQPTlzaIfVr1H7MldxdVXCgmD6dlJWDwrVky+HKxpIvy2cxqEdDu3UK7TT qh7b6dfY6EEL/qqw03rKw7KcLuweR2HrYHmqgLZqnXb14I9iOmkNYYNkMZ4aKW3h1usN4nKoWi/Y 2pDTK+gR1en3t6B/uIdxjXoYr3FE7eqh3Frr4OphWUs7SBWhyydqjOaFDuag7bpWkmXnudtMu94N By3ZWT1oe1Jn/6V60Hb/ZOdEBW0dH2ZExfQTCVB1DG2DN7Vz1+3qwdxBLZFUw8b7S2qTQPnCy8Cf iwT9OH4S/lS15cDHubTMjaJdXfRPRhfkfWc7rbh1erJzgOX0cbEy+Dgj/LlzwKt0DrC0UPWMxGmd tVD1rIJSyvuR7YLtLv+XKxwdRVM9OFtPRVMQjTTlIlsJ2ake1q0nQw6tDJcbxLUMINLqOiJntHou hXP1uKut7aYjroZnPd7vtra0hGc9/sp6vPOliYl6Fjh2qgcmlVnDehx58rV52Kke0bTUj3GJqFuc 5fjUO9vleJEbdTc5sc9cDeVsQvVIkcXMe7kJawywQ92aJR8Z35wJH3CaMRtQaf24zRtq13UBvWoh jCtVo+0VRMcR1Xnh60718PVe1VbnEnAXX1cBkk6vmr3xiAPZXAOzEZdvfacNfmqhI770hF4KaPtm 041O2XErN6LFcSuOW21m3L5Js9ypmMESoma5nYr5J4ou1C7/ZJGjYv4pJUcOvthV566wqA/WDLST Mw9+n8/O4qU/QXflZYTWXNGjOBiqbJXqf+JjfgjmZtCUGe+3RfhEEzlQO/wUoKckRuWguyRdZ/r0 opaYrkT33qswIrtKP0c1MJf/xSfyzyURc5kTZjEf5VlX7naYK635Biy7XVgYy+7vT3ZXTPKmwqpO OQdIAa3K0HMef9vdvU/JwbK7WHaL3/35cibeQESr7ugQ2AkaAXt2Aem6L6MzIY3FNnEWJtOALTeF BwOPM8HjegOPLTlVMVWcyqmaiu2KqeKUHCy2S8T2YirHU+rpF2Rfr63vGQYUowU5mdsHNCnjwAsg 44NJkGAQxl0UzukrFt4svKG3VAfyZnPQ39JevHl6ugWT9AOnwizhXRGQkUqrmgrvitCIlBwsvIuF 944tZFX8JK/3Gstult0suzXMzZLdFfP/qbCqqeyumM1PycGyu1h2m66X4DoKi79UuJqzisWBFI5M bwaXvklWca/BAHxC+YRS/kE5zAzXURFvdEWTxlP8x5jG80pBZT6b+UgH68/EovH5E5Fvh4nVAJHj QquRl060S7Ok5v1bWjTdFtE89OusOt6WnMLUHpH5dFCRICDd6hAQNTB5VztwMO5cXYwP6rM/xrjD OMyqrramhWFgBhwU5sfYrPtOzLp1NVq3OjqKR6sfjMNVFKCvyS/iydVwNwGGQdHH3nU49xf05cNo EQfn2Z9M0OPPvotWqbjeUagvoWShIwpK5iWWK0UBZLSJxSPVQSk52oRwtbVTG8mwYJLyy8wHLlYt 7jcSh2wRl/vgbAparp/PQay0uv2eTAOSJenfymnfBPkkWCeAV3fo4YRzS2JshmEw5wdthciif1yv ZvgA2KxQ+QM6NrsWG73q4K06j6XvVceI7FWllVRGWyYEg0M3BwQfO4oLjAwWLEARu1LTju+437A8 ZVN9U4N8kwisJU+ro6pqLU+rwzb2T57qkUTg5RUKMdTcWhvmm7bpN50bTRctqzUUi1e3bII7ItSo I4IlXqvjnmotXqsjK/ZPvMJmdURr6fCTjSTH3vRvcjRIzRoG/elpJa7nwT4J55wp3PJd55wtpVkd cFZrpVk977qXSvOlppWw7FSCgtvr/DDtdSzZWT31WmvZWT3LuH+yc8u0khccwcGilUVrQZn799q5 bC1a+5x6tLsd9zn1GBFUsRQHg1hOTvDbje+81FwEFq4sXH9c4cp5SEe4ch5yJ+FauYm/t+44/7Ug HlYEniFzm4AHhsy9MmQOM78JdrdKHkLg7j7PogA9FH8NxIOgz6d+QhC8ZqvbaLYbzc5NC/W7dUNj A7+12f2xkr3Eh1qCyYualPGhfu1DXT2TvheH2m3Hel3S0rX4+Lv34HbcDNvctGK+CWxz3aKkXz1F 2qlxO+5+9RSpIsfel6behqvF1KN6o0xXbVk8XNIWkOA3pr6V/g53TX1SgJJ3hSoLZgZ81gjwaQnm 6vnXWgvm6vnXPRfMMz9OrsViKiIx/ejfiwsI4t+k76WlbVnZrWzVKiV3bq9WLwslNej9SExE8Cim LNRlRqcgis6duPe0E/egeua3zkJ9UD3zu+dCfQfRjRYPMcR9cbNW7wVaBpa3kWleNgfdruy/w4mL TZefY5yvEuPcm+6AfBi5p9P3XpRR38OolR02wOoQmPnQOqHuNzIncDFqjjEqmjwGrS51t5LNhoXw 3yhERk0H8ae8mv6UPzUroFZG7lO2lG1Zz8d9C4Fov9Icpkjc+9HUS0Kvd+zRGqwOf5G9gnanM0L7 Lnm/oZ+9Un18i+F7XvIUev50GiRBuPBpMt8yjBIveV6iVZUfCW8ZhSg3EtMz5x65b12ciXG/4QYa nInZNMu+SSamFnIREskcfSdPSqdci7If+j0LRSJQuY5UwuvW6J2H7ezL7esujzwaW1Xnvc4PBi/R RXIyC6ir1b6xwrBiu2OHPmydkBlZEP3mctAfphz0h9badAh1d/YaKeV8QS3bEzoiaH9tMtMyOEuO +jPBC3T73QwluK7zllCCvphIzZH/TReTI/8c+f9ExRK7TR2pv8SSemtLW91lJHL66no+4IZBEqsS WEfWs/XN1jcdMtWlqnXaPNkySpiHJymxbAYlvcRch72zvkmUWX1p3dL8HSfsshhTh5YxzTXCNHMQ 4YeauAMxVq0BHruMHOlkW8sdmAXr8xVnaO2frfU1JgewHGM5xnKM5Rh6mLzcDOEy6IgMfuX6ieng E8ch3EjpWL1E6g2zyZKhRoHR4Y4t+lk7sXZi7cTa6ZW1E4cCzg+4XHevynU5XvlDxStfuuk8G1ps aLGhxYbWKxtaL9zdnaUYSzGWYizFXlmKvWgbdZZhLMNYhrEMe00ZNj3ybh6ESsrEpqudjd4j2HG2 +12cmU/vpCty0ci6O4Kpp7X6Q7jlFtypgDsVbJaRcKeCzc4oXFSBKonoURwMVVrZoJFlO2aw0Art VMI7RzJt5JOt6i3OJ/vxJAg2lO+6cOcmQKc977sLlQ6pdeuliJNg4VNLncZP1LmAtJb9oQQYOMxQ UU25CozVFKspVlPjGEpIksEgiFhNUSVaSck6tJQjhSyVRG3M9kYhoSVrjNZn8VJMEvTPnj3vQBXj PKiWS3uLBTNkqCe/FMHDCmo0HLbJVemuf2mX87NKP5iJuyStHGWVziqdVfr5wVQ0Lt8RIhryRLuF W1T6nun04Yefr9Om6mk/1IrS15XL7FCx9GXp+3LSN/cwugbPtdO61FiVVmTevVyeUP0Rtzu6NZ6v Y0FxuyNud1Sh3ZE5c85BrFGpT2EcxPHaYGTV6J2HnezL7esujxDf8WfzDdu4Rpudz+B73EQ4nyAV Owu7HLOLJcNGS2HzYXYr2K14ObfCSlfsndGC1I3ptOtKqJoZMF+lqa7rS26JwrOXKcfWFoFh2ctk L7OCl1l7e1vhv7Y01fVvc3rqHju+Glua3EY3TYa2uI0uZuEA7UcU4dZuNMHkS0FOWxBBr9PajQ0w VVnDw3h4GE8UaNEmzez4D5PLMQec24EH/hfBIBBqWYlMERG3dhPnB3KkgypWcEzOmoUOvri1G2sn 1k4F0/NaPKzCxdizdvpC7fRnW7uxkGIhxUIqdksE2YQ23oNYND5vC8tuCQV8/dZuLMNYhrEMYxn2 9cKZ6zR58XSw0XI5CyaqXPv9pQkYXAb+XCQicjxkTspwUoaTMot4szMDJ2W+YlIGUuwrt3ZjS4wt MbbE2BL7epbYN2/t5oo4LiBjLDZjsV8Ui70n0D4YY3LQNLd2O4uX/mR/8snfrLWb1lx0vpYfZXki wNgx/bMIlH3a6qshekUXtE467fIr2oPuSfkVPJiHB/OsUZnfd2tGCtypo1On8t78AkeFQMd/d25r VsMeZv8vAAAAAP//7FhRj5swDP4riPfbEaBQqqNSR+/2su1Qu+09hZQiUYJIaLf9+tkh3MqVlkmT Jm1rH1piO84XJzafO384zqTxdV/MREUTFppVzQSrD8ycGw/3oJvjd41m7Vfc/jzxUgrjOKMiyfPQ jHhT56w2PrKjCVJGhVyInIbmp3zPBIqNFd/TEpW7RSnOpySi7+UelxTfwf5Ai9C0LVNLIly2Jyto mXUyVt59XvchpOxu+YizcSMtfDnnW0PumFGzhOUHlhqAUtCMgZBKI4HN0bwEMdo8R3e9SICbCsFV sGYt8nQVmpZlO87CneLCSrRkW9oU8lwTn4iUEw2IbgQOJd10OynYVqK/ikNkAuK1+79kQKaOfd3C 9gGfiuElH47nudct3MlUn8MlHxM3GEHquWQEqe/YI0intjuCFAI2gpRYlj8ClVhBMIKVkMAaAUts gHs9rsTx3TG4rjdRcDEp9W3BlM3V3adbyWq4WnhhCri5kDDgUA9WTQEC2kjeotBJUP/NOYxJqEsR 5s2/sKXLhdjQn+f3K2PxJX5zK0dtVbyVI3gz9t4Tt3J0wkL+IKXoytEgN/Aj5+lthNX4NTfoaxQ3 0KIbN9hAvBTN613wGzcYCAq5cQNkNpB8igd0yQjD/4AbjJOBaEmCyeKl/sRIFC0y8aPHwYalb66K kjZW3UOv7XnlZcx13/zU9Um901zuvKsbOOLBettfZfWLoH4TgWCJjOuuxg9EeAjGGiahqeM51jQw FYRsjU3vMTTxXe7hqe3g2Zs6us2osg8U15G8ArlLfHWwebYDT91ww6Xke3ThuKjGEvpTu2M0xW7B h84FlFvOVfOgh1kjdS+hjjvhBTbc+t8BtFHilCfv6jxF39BuxLlMAKXT9lxwKG00VEpuePpNPcCU Zs9KOf8BAAD//wMAUEsDBBQABgAIAAAAIQDjWkknlwYAAFUbAAAVAAAAd29yZC90aGVtZS90aGVt ZTEueG1s7FlNbxtFGL4j8R9Ge29jJ3YaR3Wq2LEbaFKi2C3qcbw73p1mdmc1M07qG2qPSEiIgjhQ iRsHBFRqJS7l1wSKoEj9C7wzs7veidckaSNaQX1IvLPPvN9fM7567V7M0CERkvKk7dUv1zxEEp8H NAnb3q1h/9Kah6TCSYAZT0jbmxLpXdt4/72reF1FJCYI9idyHbe9SKl0fWlJ+rCM5WWekgTejbmI sYJHES4FAh8B3ZgtLddqq0sxpomHEhwD2R0sqJT40haRNEy8jZx8jwGPREm94DMx0MSJu8eAg4O6 hsip7DKBDjFre8Aq4EdDck95iGGp4EXbq5mPt7RxdQmvZ5uYWrC3tK9vPtm+bENwsGx4inBUMK33 G60rWwV9A2BqHtfr9bq9ekHPALDvg6pWljLNRn+t3slplkD26zztbq1Za7j4Ev2VOZlbnU6n2cpk sUQNyH5tzOHXaquNzWUHb0AW35zDNzqb3e6qgzcgi1+dw/evtFYbLt6AIkaTgzm0dmi/n1EvIGPO tivhawBfq2XwGQqioQgvzWLME7Uw2GJ8l4s+IDSSYUUTpKYpGWMfIrmL45GgWHPA6wSX3tglX84t aWZI+oKmqu19mGLIihm9l89+ePnsCTq+//T4/s/HDx4c3//JEnJ2beMkLO968d3nfz36BP355NsX D7+sxssy/rcfP/31ly+qgZA/M3Gef/X496ePn3/92R/fP6yAbwo8KsOHNCYS3SRHaJ/HoJixiis5 GYnz7RhGmJZ3bCahxAnWXCro91TkoG9OMcu848jRIa4FbwuoH1XA65O7jsCDSEwUreB8I4od4C7n rMNFpRVuaF4lMw8nSVjNXEzKuH2MD6t4d3Hi+Lc3SaFy5mHpKN6NiCPmHsOJwiFJiEL6HT8gpEK7 O5Q6dt2lvuCSjxW6Q1EH00qTDOnIiabZpm0ag1+mVTqDvx3b7N5GHc6qtN4ihy4SsgKzCuGHhDlm vI4nCsdVJIc4ZmWD72AVVQk5mAq/jOtJBZ4OCeOoFxBobRVSfCRA35LTb2AoWZVu32XT2EUKRQ+q aO5gzsvILX7QjXCcVmEHNInK2A/kAYQoRntcVcF3uZsh+hn8gJOF7r5NiePu06vBLRo6Is0CRL+Z CG1FqNVOBY5p8k/lmFGox9b6F1eOoQA+/+ZRhU/f1kK8CT2pKhO2T5TfRbiTRbfLRUDf/pq7hSfJ HoEwn28870ruu5Lr/edL7qJ8PmuhndVWKLt6brBTsZmR48Uj8pgyNlBTRnakmZIlNIqgD4t6ozki kuLMlEbwNSvsDi4U2OxBgquPqYoGEU5hwq57mkgoM9KhRCmXcLQzy5W0NR6mdGUPhk19ZLAFQWK1 ywO7vKKX85NBQca0m9CcP3NGK5rAWZmtXMmIgtqvwqyuhTozt7oRzdQ6h1uhMjhxXjVYLKwJEwiC uQWsvAqHdM0aTiaYkUDb3Tbf3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkMgNip8JE+5p1itRK3lib7 GtzO4qQyu8YCdrn3XsdLeQTPvKQT90Q6sqScnCxBR22v1VxuesjHadsbw6EWvsYpeF3qoQ+zEG6H fCVs2J+azCbLZ95s5Yq5SVCHiwpr9zmFnTqQCqm2sIxsaJhXWQiwRHOy8i83wawXpYCN9FeQYmUN guGNSQF2dF1LxmPiq7KzSyvadvYxK6V8oogYRMERGrGJ2Mfgfh2qoE9AJdxNmIqgH+AmTVvbvHKL c5Z05fsrg7PrmKURzsqtTtE8ky3c5HEhg3kqiQe6VcpulDu/KiblL0iVchj/z1TR/QSuClYC7QEf 7nIFRjpf2x4XKuJQhdKI+n0Bk4OpHRAtcBsLryGo4EbZ/BfkUP+3OWdpmLSGE5/apyESFPqRigQh e1CWTPSdQqye9S5LkmWETESVxJWpFXtEDgkb6hq4qnu7hyIIdVNNsjJgcCfjz33OMmgU6iGnnG9O DSl6r82Bf3vysckMSrl12Aw0uf0LESu6qt1vtue9t6yIfjEbsxp5VgCzUitoZWn/iiKcs9XaijWn 8XIzFw68OK8xLBYDUQoXPkj/gf5Hhc+ICWPdUId8H2orgp8aNDEIG4jqS3bwQLpA2sURDE520QaT JmVNm41O2mp5s77gSbfge8LYWrKz+Pucxi6GM5edk4sXaezMwo6t7dpCU4NnT6YoLI3zk4xxjPld q/zDEx/dBUdvwQX/hClpggl+VRIYRs+ByQNIfsvRbN34GwAA//8DAFBLAwQUAAYACAAAACEAnw0N UJQIAAAkIgAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFpJbyPHFb4HyH8QeI6s2hfGGqPWOMFMEkTO JbcW2ZKIIdlEd0uaya/Pa5JtjeyPhpGTmvWqXr16+6Lvf/iy2169tP2w6fa3C/4dW1y1+1W33uwf bxf//qleu8XVMDb7dbPt9u3t4ms7LH748Mc/fP+6HNpxpG3DFaHYD8vudvHc75fD6qndNcP1brPq u6F7GK9X3W7ZPTxsVu35z+J8or9dPI3jYXlzcz70XXdo94Ttoet3zTh81/WPN6eTuVs979r9eCMY Mzd9u21GInh42hyGGdvu/8VGVz3NSF5+6xEvu+2875Wz39p5fu5r169/PvF7yJsOHPpu1Q4DcXa3 PT1312z2M5ph+3vwnPj5cXPfN/3Xb5B8ILH9t+t2V6/LQ9uviKEkc8YWNxNg3T40z9vxp+b+buwO tOWlocsscyfw09fDU7s/8v0/pAozXAl9gq+emr5ZjW1/d2hWRH3q9mPfbed96+7v3Zi63aGnx51P 0K9mPN5N+rceJiKmj3913TgfY4xrm8qZhgn6BmFMR2NOuH4BEUqbM12/gEijTYBntBZGQojhxWQM sdwlCHHSV0xBMLoKeCZZpjyEZGaVwhClEz5TZLSYtmqSgO/hTHMNsXEuk4N841wVDl/KueYRSo4L VXxE7+HCKA5lyqWKBcqHrimKQ2wXdYcbFniBZwwXBfKaWyUl5oFVLlqIzeoS8RknuMYUOO085oEz PuN7vBJYr3kw0mP5RHoRlnZUwmH5RJ0Z5nW0KlbIg6QZx9iyjPrsft7bKS/CX9CdqlKF2kuxQWPJ Cbrf4zOk2FgKgmStoPZOkArlI6TOCfJAGM4t5LUw1mV8JgpnIN9E1IVBPRBJKgWlLbIwCWqiyNIn zJ3CDZaplNoxaI1SkwVDvyONYAmfMZI5yB1pjTJQ36STykP5SGdrwdi8zRFTQL4Se39ZpL9AW2VG QMkppoMSyBYUs1pDChRnyULJKc5Zhp6CICrhe6SsCUpBKVY45JtS5A+gVpFKhQI1niAJ+16lWQnQ jypjDbY55ZgpUNrK8QtZgHIiWMwDLwL2O8qLgmOJ8toVLNMwWR2UaeQMRzOVpHCYB8laj7Fl5i20 epV5CNBbqsp4hdg0Ywz7Hc2ZTJDXmkthMDZBMtWIB1orhl+qtRECWqM2zAooOToScJTRXrIA5aOD YBVaFtlixbmYjjoETEHiPGLuJEk8hTwgaWP56GSigtaos2I4PyAPf0HauggRoAVT+MsM2qku1uFI q6tVDNJmuC0c8poceTFQr40U/CIk4PhjKGRgr2wk5deQ10Zbay5BHNZRYyzH8pkAFb/HGqMwD7yU WHtNljVDKzHZUEhHukMQF6EmmmKMhv7AVO5xPDXVagbfYxlFdHiPZVJhn2g5FzYjqglC3gpClPEc 8oACuoj4jBUJ+1FrKd+Atm0jVxHfE3nA2bpNskao8ZZyW+x7HePcQz1wgkl3ASKshvHUSWGx33FS UkhHHHVSJxYghCJ6gNxxSta5fn+fXzulMs6RnDLEH3yPJfIghFI+B72ls7Zg23ZU5Vzgjqd8B1qJ CzLjrJOMh1+gOsmCfYjLWnKoia7IKqFWefL9riAeeC5khvLxkidcL3jFKH2B2KgKDpAHU6GHbcFr JRn0FF6b6qAmeiraIr7HmYSzTk91Ee45kDuyEnpln0zFVZtP1hTMt2SLhbwOjOwevjTwS1YfJFVn 8J6gqLcBtTdQ58fBSBuMyBVTYI3Q0FsGayTuIxHECyifQFaC8x2C1AJ1NFD+6KGdBqpKMn4P5S4F Si5kkXEdHApjF3hQJMfSDlU4bCUE8RraQmQiBCifyCiaQL5RWLC4OoxCywglF6XVuGqLWpcKdSdS O5FBbxmNveB7ozUWd3FIbMpD7x8DYwVqFUFcxRQEKrehhsQkvcd8S9T1wC9NFNIxBclK3KuJZNu4 PxozNzg/IEgy0CtH0jfcg4xFJ1yfxsqlh+9JnBlcb6cp74V+h0pdjnuq1OJy2BaS0a5CmSaqg7Hv pUbAhZ5DogCE84PkTbZQpinKgHU0kZJmaAspCYe71ClzjbNognjsYVMWHHelUpERa3zmIgaob5nL gmvnTPFcQh5k6tlh75IVJWP4HkWdeuh3suZUtqG4nbX22LtkS8oDrTGTtHFnIUcTJIzOmZQH5yE5 y4R7g5kqvQAtq0jjPPT+RbOE67mihcSdhWJtSjDKFC+ThHwrnvpfAnG0eFvnGdP7HLYEVnD/jZoU 9QIFiWtcfZQkNI71pYgL9SlBaoDehdpLVWMeFKppFXpppdwS912o0chxRVnJsHD3uEpuJL5HUm8d RowqyZFDHa1GJdwlqE5Qiwe+h8Izh3lIpfkClnaNxgWoIZWmY1hyNXMK0JAC6ofYo3xuTqNFmjHu ltPA95/9/FVpTnm1Ow07U7O77zfN1adpJEyDyd3yvv8cN/sZft/SaLr9FnL3fD8Dr69PgGHXbLeV ZqEzgKbBJ8h6Mxxy+3BEvP3U9I9vmI/Gt1v2cJUms3/7Gds0tW37v/Td8+GE9bVvDn/dr2l5vpBT j/cE2+zHj5vdvD4839/Np/Y0Gf4G9Lxf/+Olnw7dvDHodTnSML+dOPSx2T/Ok9d1ez0XBqttfzcN /NtPzeFAQ1/acv/IbxfbzePTyBf0c6Rf66b/fPxx/yjOMHGE0a8JdvzRrKaX0e7zx7Th9Em7zh9v a3Jek29ral5Tb2t6XtNva2ZeM9MazbXbfrvZf6bB+vw5rT9022332q5/nBdvF79amvhF/wjx1Bxa kus0PScF604L53H6cPWybL/QnL1db0b6X4rDZr1rvtwuJE10p+Pn3dvma/c8vts7wabNh3erV+tm bGhqfxTVu8Mkul/RMk31VxtSyLuvu/u3YfyfToRvN8N41x6avhm7np58HPj/+Yj57d87PvwPAAD/ /wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnht bC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhM/BigIxDAbgu+A7lNyd zngQkel4WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y2VM00FQ1KIyOeh9HAz/n79UW FIuNvZ0pooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwmDJYrShjLZKAcrJQyjzpZd7Uj6nVdb3T+ bUD3YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4yDaPKAa8YHi3mqrcC7pr9cd/ 3QsAAP//AwBQSwMEFAAGAAgAAAAhAN0vHwPhAAAAVQEAABgAKABjdXN0b21YbWwvaXRlbVByb3Bz MS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJBBa8MwDIXvg/2H oHvqpOvWtMQpc0Kg17FBr66jJIbYCrYzNsb++xx26o67SLwnpO+h8vRhpuQdnddkOeSbDBK0ijpt Bw5vr21aQOKDtJ2cyCIHS3Cq7u/Kzh87GaQP5PAc0CTR0LGfGw5f7V7kj8VepE1R79LdQYhU5Hks D+22zg6teC7qb0gi2sYznsMYwnxkzKsRjfQbmtHGYU/OyBClGxj1vVbYkFoM2sC2WfbE1BLx5mIm qNY8v9sv2PtbuUZbnP4v5aqvk6bByXn8BFaV7A9q1TevqH4AAAD//wMAUEsDBBQABgAIAAAAIQCP SjVWdAgAAJFCAAAPAAAAd29yZC9zdHlsZXMueG1s5FvbcptIEH3fqv0HinfHutiS7YqS8nWTKsdx Irv2eQQjizUCLSBf8vXb0wMjBAK6Da7arX1KGJg+3dM9p8f2nI+fX5a+9SSj2AuDid3/0LMtGTih 6wUPE/v+7mrvyLbiRASu8MNATuxXGdufP/3+28fnkzh59WVsgYEgPokm9iJJVif7+7GzkEsRfwhX MoB38zBaigQeo4f9cD73HHkROuulDJL9Qa832o+kLxIAjxfeKrZTa88Ua89h5K6i0JFxDN4ufW1v KbzA/gTuuaFzIedi7Sexeoxuo/QxfcJ/rsIgia3nExE7nncHjkOISy8Ioy+nQezZ8EaKODmNPbHz 5UJ9tfONEyc5a2ee69n7CjH+BTafhD+xB4Ns5Fx5sDXmi+AhG3Pl3sVl3pOJLYO9+6kamoHdiS2i vempMraPYWb/5sJdbQUPT+jKSjiwcGBGzBMJCYR8KKO+pxI9GI+yh59rHwbEOglTEDQAYHmz8FhY ccgrZHmqqwTeyvl16DxKd5rAi4mNWDB4//U28sLIS14n9vGxwoTBqVx6XzzXlaoo07H7YOG58s+F DO5j6W7Gf1xhiaUWnXAdJOD+aIxV4Mfu5YsjV6rEwHQgVIZv1ARfmY1zOOjQ2tt4owcKqDj4dwbZ 1zncibKQQm0jC/2vBcKo162BBiqifABol+XrsL2Jg/YmDtubwOJttxbj9l4AebbNiK6NXFXSk5qE ji6+/DoMj2tKVs0oVVHjjFLRNM4o1UjjjFJJNM4oVUDjjFLCG2eU8ts4o5TO2hmOQOIqVtEQV4O0 se+8xJdqfi0B9VtSXdpqrFsRiYdIrBaWaqxFt+vIcrqeJTRXkU7fTpbTJAqDh8YVge6stu6bOfly uVqI2IMTTcPSD1ou/Z2Y+dL6I/LcRqhDXXylmPBgsrOF3frCkYvQd2Vk3ckXnVHG/JvQmupTRqNz LdN67T0sEmu6wJbbCDaqWPTqldD2r70Y16B2M40qQmkyTsrhqKIuq41/k663XmZLQziNjDSfM9Jc gEAX65foQKWovLsao1AJoISg2wU/BLRP8F83F759lWOK/7oVvdE+wX/duN5oH+ujPr9sprkQ0aNF 2l5j9t49D/0wmq/9bA800sOYvYMNBC0E9iY29kkkMWbv4C36tE4dB35yo9QpOxcbHmWgsNOhUXCz 0WNhJ6VAe31GROwEFbAGDKx2XMsAYpPuT/nkqV88cZsBsrQ5azZu52HFCkALIp2hf6zDpPkMPajg PCrK1wB+XRJLi4Y2rNh5VLS0nnS/Y+S4XeNjALXrgAygdq2QAVRRH9VnHtMT6SDtmyMDi03Lpoth 2ZGZecxmZgPEawEd9U3C+ati91bXQrlvElDYCSr3TQIKOzuFXmb6JgGrs75JwKroGtU5ynMqJyh2 38wDmZMAIaJuyJsA1A15E4C6IW8CUHvybgbpjrwJWGxuMJyaJ28CEH7C+VHfAOXJmwDE5gbNdunv jLK+h1bqf7jtgLwJKOwElcmbgMLOThV5E7DwE04lFLAM1RGwuiFvAlA35E0A6oa8CUDdkDcBqBvy JgC1J+9mkO7Im4DF5gbDqXnyJgCx6cEA5cmbAISfcLhhJ3njrn938iagsBNUJm8CCjs7BUI1h1QC FjtBBSxD3gQs/IRTDCkWFjcnqG7ImxBRN+RNAOqGvAlA3ZA3Aag9eTeDdEfeBCw2NxhOzZM3AYhN DwYoT94EIDY37CRv3IzvTt4EFHaCyuRNQGFnp0CohucIWOwEFbAMeROwsF5akzcBCD95KxAnom7I mxBRN+RNAOqGvAlA7cm7GaQ78iZgsbnBcGqevAlAbHowQHnyJgCxuWEneeMeeXfyJqCwE1QmbwIK OzsFQjXkTcBiJ6iAZaiOgNUNeROAsDBbkzcBCD95AxDuIk6auiFvQkTdkDcBqD15N4N0R94ELDY3 GE7NkzcBiE0PBihP3gQgNjeoe7ZwX5R8PbVfUQTUewbZrQYy4KAiSVTANMCfci4jUDLJ5tshLQGz CBmIFeVBDfEsDB8t2sXuYUWBkKG8me+FeKX7FW/p5IQIw3GNkuDu+7n1RQtgSvOwpLZv3oB6KC8X QnmSEg6Bn8nrCiQ7q+xmubIGAiGl60olQKhD+wqCoFTWoyYrnQ98iKKqdBj/bpui4v9B8+Zm3/R6 w9Gwd5RqI0ArpozkVVggufrjLJU/4WvwGIEbXDXOpYvRR1VS3r2NTAi9mgkQN31XWqWS8wHcwN41 DoKtx2w8gzlfiEinZyP+yL5Jo6xei/7h+PzySE9PxWKPUq5uAB99VA/XoBKL8Sk2OrKZBLUfJOvg CP9ElsrKetpQuE6Usuz6yc/8wBdaRqZWMV31aKcmT/xVo8lTLy9TnZ6qjy1Z3tbMjSxPDW9keTO9 9uc6IkddGM28HI4Or46RI1DRh0wNaji8IrkZVn9FhMjPrnSwOZlfuo7xr5zMD8cg8jaVNKispFRY 2E0lDQiVtH28wqV8v+JKVYpNxYVik399cR1cHfXPLlTN7iouvb02itFRVly5UsKx5lJygA+EAzLP Gv5MVTzmYiVqeIpsWiH1QVfLVJNKfjY/GOrvti6ewxD4X0GmiZK31PiM8pda4rfwE71yZQdBcapX 2QhBd3torori62Tm6xYB//kaqC4CimXkPN2t3BehzcL7c+n73wQ2lCRcVX/qy7lidzDU7+ERv2Bq FiZJuKyeH6ECptIALHHeGf2ogqhe+2C9nMkIJKw1638TqqNxiYpA+IPjejHNoQG8x65GXfVq37bq 2VnHsDRTdWAongm2+mGxltOXVt/akFyBNXfuCYxqV9etrDL9YvvEke+y/7fe9+bDFTPvuntV5X3Q Ud7ThruDXf6jee+oLZGznO3z+NM/AAAA//8DAFBLAwQUAAYACAAAACEA3qc5g18BAACTAgAAEQAI AWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJR a4MwFIXfB/sPkndN1DI6UQvb6F5WGKylY28hudUwEyVJa7tfv6itq2wPe0zOuR/n3CRdHGXlHUAb UasMhQFBHihWc6GKDG3WS3+OPGOp4rSqFWToBAYt8tublDUJqzW86roBbQUYz5GUSViTodLaJsHY sBIkNYFzKCfuai2pdUdd4IayT1oAjgi5wxIs5dRS3AH9ZiSiM5KzEdnsddUDOMNQgQRlDQ6DEP94 LWhp/hzolSunFPbUuE7nuNdszgZxdB+NGI1t2wZt3Mdw+UP8vnp566v6QnW7YoDylLOEaaC21vmm 0oKV3lZACZ5Q3vOequKrrPcpvnJ1G62osSu3/J0A/nCaDKb4t96NaDiI7vHyMOot49kl6AsPMYB7 rkIyFL4o2/jxab1EeUTCmU8in8TrkCSz+4SQjy7bZL6rNFzIc8L/EGdrMk/CeEq8API+8fQb5d8A AAD//wMAUEsDBBQABgAIAAAAIQCF2n6wmAAAAOgAAAATACgAY3VzdG9tWG1sL2l0ZW0xLnhtbCCi JAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsj70KwjAURnfBdwh5gKY4OIS2 UFAnESGLg0uS3jSB/JTkFuzbG0R8AsfvfHDgdIqLtGYNhQjwoBEmgZuHnj7H+9g8xJWSD7jJUGFl 5OIMWnKeHLoUKXkFHwtXPbWIC2esaAtBliYtEOtnUg4S68wzS8Y4Daek1wAR2aFtj0w55V2as1zs 9pX9RTV07Jc27HdvAAAA//8DAFBLAwQUAAYACAAAACEAQ01kb7cBAAATBQAAEgAAAHdvcmQvZm9u dFRhYmxlLnhtbKyT3W6jMBCF71fqOyDftxhCfxKVRBHdXO7FqvsADgzBEraRxwnt2+9gE3KRVG2q GgmJM/Zh/Pn4efWm2ugAFqXROUvuOItAl6aSepezf6+b2ycWoRO6Eq3RkLN3QLZa3vx67he10Q4j Wq9xYXPWONct4hjLBpTAO9OBplptrBKOPu0uNnUtS3gx5V6BdnHK+UNsoRWO/o2N7JCNbv1X3Hpj q86aEhCpWdUGPyWkZsuxu6hfaKGo60K0cmulL3RCG4SEagfR5oynfMPv6T08GZ8NbxYPDmUjLIKb JvIg10LJ9v2oYi8RQ6GTrmyO+kFYKbYthBLKHRX2uOU5+81ppJsNC0qSs4yEdTEpKTUVRjLOmU0K HQ815n38lGTufUghn3GV7zMO53NG4lUqwOgP9NFfo0RAdU4k5Q9E4p54DGRmVxGx3tcTvIJIup72 TzspaCuPT9lx/yci88+JBJ+vEymEomiID7IxEAgkBiLXZeN7JM6zwbOJzYmETwIl6gezUZi9lWCH dHxA45EYzIlC6nORXZULZSqw+sJVqeUbVJfvycVUzMYMnFj8RCrGC4PL/wAAAP//AwBQSwMEFAAG AAgAAAAhAErYipK7AAAABAEAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbIzOwWrDMAzG8Xth7xB0 X531MEpIUiijL9D1AVxHaQyxZCRt3vb0NWyX3XoUn/jx7w9faW0+UTQyDfCybaFBCjxFug1weT89 76FR8zT5lQkH+EaFw/i06UtX8HpGs/qpTVVIOxlgMcudcxoWTF63nJHqNrMkb/WUm+N5jgHfOHwk JHO7tn11gqu3WqBLzAp/WnlEKyxTFg6oWkPS+uslHwnG2sjZYoo/eGI5ChdFcWPv/rWPdwAAAP// AwBQSwMEFAAGAAgAAAAhAOfiJ+j4AQAA+QMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPLbtswELwX6D8Iuse03DZRDJpB4aDIoU0MWEnO LLWyCVMkQW7cuF/fpRTLctpTddqXZkc7I37z2ppsDyFqZxd5MZnmGVjlam03i/yx+nZR5llEaWtp nIVFfoCY34iPH/gqOA8BNcSMIGxc5FtEP2csqi20Mk6obanTuNBKpDRsmGsareDWqZcWLLLZdHrJ 4BXB1lBf+AEw7xHne/xf0NqpxC8+VQdPhAWvoPVGIoj7RMdMaoctZ0OVVw6lqXQLYkrlIeEruYEo vnDWB/zZhTqKoixLzvqYL7cySIV0QlEU5fU1Z6MK/+q90UoinVf80Cq46BrMHrpDZAmBs/EIp+Os Qb0EjYdEZZzy79oSmbShj4hdkJsg/TaK2VXiOKR8raSBJd1ANNJE4OxU4Hcgk74rqYkz3+N8Dwpd yKL+TQrP8uynjJAut8j3MmhpkS6Yxvqki42PGESl0RA29fq8C8dj41h/FkU3QMH5YALoOVDjnF23 IT409G34D7LFmGzHoac6ojMKhx3vUJeu9dIeyBw7LbO1BrJnzO4Bf7mwiyToWz8psIuPvnK3yUtv lz0vjvzwrHG79lKRaMWnq0uS8+SMUY+vyUFQk9RHxFOB35EMwaS19K7dQH2c+buRvPbU/8mimE2m 9HTmOtbIIMMvJv4AAAD//wMAUEsBAi0AFAAGAAgAAAAhAHwQ7j1/AQAApAUAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABOAgAACwAA AAAAAAAAAAAAAAC4AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA37VMthABAAC/AwAAHAAA AAAAAAAAAAAAAADcBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAA IQCgtaWOAisAAA46AgARAAAAAAAAAAAAAAAAAC4JAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQA BgAIAAAAIQDjWkknlwYAAFUbAAAVAAAAAAAAAAAAAAAAAF80AAB3b3JkL3RoZW1lL3RoZW1lMS54 bWxQSwECLQAUAAYACAAAACEAnw0NUJQIAAAkIgAAEQAAAAAAAAAAAAAAAAApOwAAd29yZC9zZXR0 aW5ncy54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAAAAAAAADsQwAAY3Vz dG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAN0vHwPhAAAAVQEAABgA AAAAAAAAAAAAAAAA8kUAAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBLAQItABQABgAIAAAAIQCP SjVWdAgAAJFCAAAPAAAAAAAAAAAAAAAAADFHAAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAA ACEA3qc5g18BAACTAgAAEQAAAAAAAAAAAAAAAADSTwAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAU AAYACAAAACEAhdp+sJgAAADoAAAAEwAAAAAAAAAAAAAAAABoUgAAY3VzdG9tWG1sL2l0ZW0xLnht bFBLAQItABQABgAIAAAAIQBDTWRvtwEAABMFAAASAAAAAAAAAAAAAAAAAFlTAAB3b3JkL2ZvbnRU YWJsZS54bWxQSwECLQAUAAYACAAAACEAStiKkrsAAAAEAQAAFAAAAAAAAAAAAAAAAABAVQAAd29y ZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA5+In6PgBAAD5AwAAEAAAAAAAAAAAAAAA AAAtVgAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADgAOAJQDAABbWQAAAAA= --_004_5BCBA1FC2B7F0B4C9D935572D9000668151B1D0CDEMUMBX014nsnin_-- From lionel.morand@orange.com Tue Feb 4 00:39:03 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C57E1A03A6 for ; Tue, 4 Feb 2014 00:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNSuI13J8R1Y for ; Tue, 4 Feb 2014 00:39:01 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA21A039E for ; Tue, 4 Feb 2014 00:39:00 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 11E782DC1D3; Tue, 4 Feb 2014 09:39:00 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E2C9427C06E; Tue, 4 Feb 2014 09:38:59 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 09:38:59 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] Open issues with DOIC Thread-Index: AQHPHsNfLmhPdpctmU2ow205pjRSvJqkwo9AgAAItmA= Date: Tue, 4 Feb 2014 08:38:58 +0000 Message-ID: <17538_1391503140_52F0A723_17538_890_1_6B7134B31289DC4FAF731D844122B36E4766D7@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <52EC0806.1040101@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B1D0C@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1D0C@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4766D7PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] Open issues with DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 08:39:03 -0000 --_000_6B7134B31289DC4FAF731D844122B36E4766D7PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please use the tracker! I will do it for you this time. So please wait for the tickets before answe= ring to this mail. Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -= DE/Munich) Envoy=E9 : mardi 4 f=E9vrier 2014 09:14 =C0 : ext Steve Donovan; dime@ietf.org Objet : Re: [Dime] Open issues with DOIC Steve, thank you for your offer to enter tickets. Please find a document attached that outlines some issues. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Friday, January 31, 2014 9:31 PM To: dime@ietf.org Subject: [Dime] Open issues with DOIC All, We have two weeks until the February 14 draft cutoff date for the London IE= TF meeting. We should attempt to have as many open issues resolved in a -02 draft as po= ssible. To this end, please open trouble tickets that can be used to track the issu= es. I have had to open the tickets against draft-docdt-dime-ovli, as draft= -ietf-dime-doic does not show up as one of the components. If you can't figure out how to enter the tickets (it requires a tools accou= nt), I would be happy to enter the ticket for you. Just send me an email o= utlining the issue and, if appropriate, the proposed resolution. So far we have the four trouble tickets that I have opened. I suspect that= there are other issues still lingering from our discussions before the hol= iday break. Regards, Steve ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E4766D7PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please use= the tracker!

I will do = it for you this time. So please wait for the tickets before answering to th= is mail.

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoy=E9 : mardi 4 f=E9vrier 2014 09:14
=C0 : ext Steve Donovan; dime@ietf.org
Objet : Re: [Dime] Open issues with DOIC

 

Steve,

 = ;

thank you = for your offer to enter tickets.

 = ;

Please fin= d a document attached that outlines some issues.

 = ;

Ulrich

 = ;

From:= DiME [mailto:dime-b= ounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, January 31, 2014 9:31 PM
To: dime@ietf.org
Subject: [Dime] Open issues with DOIC

 

All= ,

We have two weeks until the February 14 draft cutoff date for the London IE= TF meeting.

We should attempt to have as many open issues resolved in a -02 draft as po= ssible.

To this end, please open trouble tickets that can be used to track the issu= es.  I have had to open the tickets against draft-docdt-dime-ovli, as = draft-ietf-dime-doic does not show up as one of the components.

If you can't figure out how to enter the tickets (it requires a tools accou= nt), I would be happy to enter the ticket for you.  Just send me an em= ail outlining the issue and, if appropriate, the proposed resolution. 

So far we have the four trouble tickets that I have opened.  I suspect= that there are other issues still lingering from our discussions before th= e holiday break.

Regards,

Steve

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4766D7PEXCVZYM13corpora_-- From trac+dime@trac.tools.ietf.org Tue Feb 4 00:46:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927FB1A039E for ; Tue, 4 Feb 2014 00:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGa63DcCKCjV for ; Tue, 4 Feb 2014 00:46:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCFA1A01D7 for ; Tue, 4 Feb 2014 00:46:16 -0800 (PST) Received: from localhost ([127.0.0.1]:41973 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAbe3-00068l-Hv; Tue, 04 Feb 2014 09:46:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:46:15 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/29 Message-ID: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:46:18 -0000 #29: OC-Sequence-Number in OC-Supported-Features According to the current definition of the OC-Supported-Features AVP in the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence- Number AVP. The author of this document believes that OC-Sequence-Number within OC- Supported-Feature is not needed, is useless and could be misleading and therefore proposes to remove OC-Sequence-Number from OC-Supported-Feature. The -01 draft says in clause 4.1: The OC-Sequence-Number AVP is used to indicate whether the contents of the OC-Supported-Features AVP has changed since last time the node included the OC-Supported-Features AVP (see Section 4.4). Although sending the OC-Sequence-Number AVP is mandatory in the OC-Supported- Features AVP, the receiving node MAY always choose to ignore the sequence number if it can determine the feature support changes otherwise. The text seems to imply that the reporting DOIC endpoint, when receiving an application request message that contains an OC-Supported-Features AVP, needs to determine whether a feature support change occured (either by checking the value of the received sequence-number (probably) against a stored value, or by other unspecified means). However, this is not correct. The reporting DOIC endpoint may ignore the sequence-number even if it cannot determine whether or not a feature support change occured: The reporting DOIC endpoint simply takes the value of the OC-Feature- Vector as received in the request into account (if absent the default value applies) when processing the request. There is no need for the reporting DOIC endpoint to know whether a previous request contained the same or a different value in OC-Feature-Vector, i.e. whether there was a recent change. It has been argued that the reporting DOIC endpoint may (optionally) benefit from the presence of a Sequence-Number within OC-Supported- Features: The reporting DOIC endpoint may have stored the Sequence-Number and Feature-Vector as received in a previous request, and when receiving a new request the reporting DOIC endpoint would compare the received Sequence-Number from the new request with the stored Sequence-Number; If they match (i.e. no change of supported features occured) the reporting DOIC endpoint would ignore the received Feature-Vector from the new request and use the stored Feature-Vector for further processing; if they don't match (i.e. a change of supported features occured), the reporting DOIC endpoint would update the stored Sequence-Number and Feature-Vector with the received values from the new request and use the updated Feature- Vector for further processing. While it is debatable whether the described usecase is reasonable, the following issues have not been addressed: In configurations where the client does not support DOIC, an agent (A1) on a path from client to reporting DOIC endpoint (e.g. server) may take the role of a reacting DOIC endpoint and insert an OC-Supported-Features AVP in the (first) request message indicating its supported features. A subsequent request message sent from the same client to the same server may take another path on which another agent (A2) takes the role of the reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP in the subsequent request message indicating its supported features (which may be different from A1's supported features but may have the same sequence number). Since the reporting DOIC endpoint (e.g.server) - when receiving the subsequent request - cannot know whether the the reacting DOIC endpoint that inserted the OC-Supported-Features AVP in the subsequent request is identical to or different from the reacting DOIC endpoint that inserted the OC-Supported-Features AVP in the first request, it may frequently occure that the reporting DOIC endpoint receives request messages containing an OC-Supported-Features AVP with a Sequence-Number valuelower than the stored value (which may be interpreted as error), or equal to the stored value but with a different associated Feature Vector, or higher than the stored value but unmodified Feature Vector. In summary, the Sequence-Number within OC-Supported-Features is of no earthly use since the reporting DOIC endpoint cannot associate a received Sequence-Number (within OC-Supported-Features) with the identity of the reacting DOIC endpoint that sent the Sequence-Number. Even when such association was possible by enhancing the OC-Supported-Features AVP with the Diameter Identity of the reacting DOIC endpoint that generated the Sequence-Number, it would still simply not be needed as the reporting DOIC endpoint can base its processing on the received Feature-Vector (rather than on a stored Feature Vector). It is therefore proposed to remove the OC-Sequence-Number AVP from the OC- Supported Features AVP. -- ----------------------------------------------+-------------------------- Reporter: lionel.morand@orange-ftgroup.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: 2.0 Severity: Active WG Document | Keywords: ----------------------------------------------+-------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 00:47:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAB91A039E for ; Tue, 4 Feb 2014 00:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5yRf25AWCMn for ; Tue, 4 Feb 2014 00:47:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5777D1A01D7 for ; Tue, 4 Feb 2014 00:47:51 -0800 (PST) Received: from localhost ([127.0.0.1]:42037 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAbfa-0008EQ-Pi; Tue, 04 Feb 2014 09:47:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:47:50 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/30 Message-ID: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:47:53 -0000 #30: OC-Supported-Features AVP in answer messages According to the current feature advertisement/negotiation mechanism in the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP in answer messages to indicate their supported OC features to the reacting DOIC endpoint. The author of this document believes that the best a reacting node can do with such information is to ignore it, and therefore proposes to allow reporting nodes not to insert OC-Supported-Features AVPs in answer messages. Currently only one feature is defined (OLR_DEFAULT_ALGO). A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other feature is only interested in receiving/not receiving OC-OLR AVPs from reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not receiving an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: a) There is no overload b) DOIC is not supported The reacting DOIC endpoint does not need to differentiate between these two cases as the behavior (do not throttle) is the same in both cases. The -01 draft says in clause 4.1: If there is no single matching capability the reacting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. This however is inconsistent. The reacting node that ceases sending DOIC related AVPs would never recognize when the server is upgraded to support DOIC. Subsequent requests (not including DOIC related AVPs) may take a different path towards the server and on that path there may be an agent that supports DOIC (with a match of supported features) and could take the role of the reporting DOIC endpoint; but the agent cannot take this role since the reacting node (although supporting DOIC) ceased sending of OC- Supported-Features AVPs. In summary: As long as no extension feature is defined within draft-ietf- dime-ovli (i.e. never, since extensions will be defined in other drafts), there is no need for draft-ietf-dime-ovli to mandate or even describe inclusion of OC-Supported-Features AVP in answer messages. -- --------------------------------------+-------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: --------------------------------------+-------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 00:48:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08BE1A01D7 for ; Tue, 4 Feb 2014 00:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6wn1k7bS8HW for ; Tue, 4 Feb 2014 00:48:46 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08B1A039E for ; Tue, 4 Feb 2014 00:48:46 -0800 (PST) Received: from localhost ([127.0.0.1]:42103 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAbgT-0000k5-Qq; Tue, 04 Feb 2014 09:48:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:48:45 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/31 Message-ID: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:48:48 -0000 #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is to be included by the reacting DOIC endpoint in request messages that survived a throttling. This AVP would indicate the Sequence-Number (TimeStamp) of the OLR according to which the throttling (which was survived) is performed. Absence of this AVP indicates that currently no throttling is performed. Reporting DOIC endpoints may use this information in order to detect whether there is a need to update the reacting DOIC endpoint with the latest OLR. Absence of this feedback mechanism would result in the need for the reporting node to send OC-OLR AVPs in every answer as the reporting DOIC endpoint cannot know whether the reacting DOIC endpoint is actually doing the right thing with regard to throttling/not throttling. The feedback mechanism improves robustness as it allows the reporting DOIC endpoint to detect and correct inappropriate throttling by the reacting DOIC endpoint (caused by whatever reason). The feedback mechanism also allows to address REQ 18 from RFC 7068. In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to be used in request messages that survived a throttling. -- --------------------------------------+-------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: --------------------------------------+-------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 00:49:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C271A039E for ; Tue, 4 Feb 2014 00:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV7ZpFPw2Y87 for ; Tue, 4 Feb 2014 00:49:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 05D021A01D7 for ; Tue, 4 Feb 2014 00:49:39 -0800 (PST) Received: from localhost ([127.0.0.1]:42130 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAbhK-0000HZ-FA; Tue, 04 Feb 2014 09:49:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:49:38 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/32 Message-ID: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:49:40 -0000 #32: Sequence-Number Time-Stamp values within OC-OLR The -01 draft says in clause 4.4: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter between two overload control endpoints (neglecting the fact that the contents of the AVP is a 64-bit NTP timestamp [RFC5905]). The sequence number is only required to be unique between two overload control endpoints. Sequence numbers are treated in uni-directional manner, i.e. two sequence numbers on each direction between two endpoints are not related or correlated. When generating sequence numbers, the new sequence number MUST be greater than any sequence number previously seen between two endpoints within a time window that tolerates the wraparound of the NTP timestamp (i.e. approximately 68 years). With this mechanism it is difficult to get back to sync once you are out of sync (for whatever reason). It is proposed to mandate that the Sequence Number is a real 64-bit NTP timestamp (RFC5905) indicating the point in time when the OLR was created, and to mandate that OLRs with a time stamp higher than time of reception must be ignored by the reacting node. -- --------------------------------------+-------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: --------------------------------------+-------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 00:50:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CB91A03BE for ; Tue, 4 Feb 2014 00:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br5Oq0zYZadT for ; Tue, 4 Feb 2014 00:50:47 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CC8D11A039E for ; Tue, 4 Feb 2014 00:50:46 -0800 (PST) Received: from localhost ([127.0.0.1]:42235 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAbiQ-0005Jq-8W; Tue, 04 Feb 2014 09:50:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:50:46 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/33 Message-ID: <066.7a9f5ebf154a20a7d05d51b6a5e8f458@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #33: Overload Mitigation Differentiation per Client X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:50:48 -0000 #33: Overload Mitigation Differentiation per Client The -01 draft does not address the 3GPP requirement to allow reporting DOIC endpoints to request different amount of load reduction from different clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this requirement by adding two new report types (see below). -- --------------------------------------+-------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: --------------------------------------+-------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 00:54:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15C1A03C0 for ; Tue, 4 Feb 2014 00:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq5Nf5pCe-kD for ; Tue, 4 Feb 2014 00:54:38 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDED1A03BE for ; Tue, 4 Feb 2014 00:54:38 -0800 (PST) Received: from localhost ([127.0.0.1]:42421 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAbm9-0004PJ-Uy; Tue, 04 Feb 2014 09:54:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:54:37 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/34 Message-ID: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:54:40 -0000 #34: Semantics of OC-Report-Type AVP Text in clause 4.6 does not fully explain to which requests overload treatment of a given report type applies. Proposal: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. 1 A realm report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. -- --------------------------------------+-------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: --------------------------------------+-------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 00:56:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FEE1A03C0 for ; Tue, 4 Feb 2014 00:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-XjEOPHyg0g for ; Tue, 4 Feb 2014 00:56:27 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 56EA71A03BE for ; Tue, 4 Feb 2014 00:56:27 -0800 (PST) Received: from localhost ([127.0.0.1]:42504 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAbnu-0001U6-Kk; Tue, 04 Feb 2014 09:56:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:56:26 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/35 Message-ID: <074.3506850db4b958abdcbb1c3d56989112@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:56:29 -0000 #35: additional report types are proposed With regard to Overload Mitigation Differentiation per Client (#33) two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the request match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the request match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- ----------------------------------------------+-------------------------- Reporter: lionel.morand@orange-ftgroup.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: ----------------------------------------------+-------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 00:57:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08B1A03C8 for ; Tue, 4 Feb 2014 00:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlCBCRUW19Z3 for ; Tue, 4 Feb 2014 00:57:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFA61A03C6 for ; Tue, 4 Feb 2014 00:57:32 -0800 (PST) Received: from localhost ([127.0.0.1]:42534 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAboy-0003Qp-0x; Tue, 04 Feb 2014 09:57:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 08:57:32 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/35#comment:1 Message-ID: <081.1369d42c333cba463498f815385db1d3@trac.tools.ietf.org> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:57:34 -0000 #35: additional report types are proposed Changes (by lionel.morand@orange-ftgroup.com): * reporter: lionel.morand@orange-ftgroup.com => lionel.morand@orange.com -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From lionel.morand@orange.com Tue Feb 4 01:10:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC561A03C7 for ; Tue, 4 Feb 2014 01:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuUIXZoyPLPy for ; Tue, 4 Feb 2014 01:10:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id EE2971A03C6 for ; Tue, 4 Feb 2014 01:10:27 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 2311EC0627 for ; Tue, 4 Feb 2014 10:10:27 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id EE23315805E for ; Tue, 4 Feb 2014 10:10:26 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 10:10:26 +0100 From: To: "dime@ietf.org" Thread-Topic: [dime] #29: OC-Sequence-Number in OC-Supported-Features Thread-Index: AQHPIYWVqo9pNoXUG0eN8kgtXuIlR5qkzoFg Date: Tue, 4 Feb 2014 09:10:25 +0000 Message-ID: <6441_1391505027_52F0AE83_6441_12827_1_6B7134B31289DC4FAF731D844122B36E47683B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> In-Reply-To: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.4.23018 Subject: Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 09:10:30 -0000 This makes sense. I agree to remove it. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: mardi 4 f=E9vrier 2014 09:46 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features #29: OC-Sequence-Number in OC-Supported-Features According to the current definition of the OC-Supported-Features AVP in the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence- Number AVP. The author of this document believes that OC-Sequence-Number within OC- Supported-Feature is not needed, is useless and could be misleading and therefore proposes to remove OC-Sequence-Number from OC-Supported-Feature. The -01 draft says in clause 4.1: The OC-Sequence-Number AVP is used to indicate whether the contents of the OC-Supported-Features AVP has changed since last time the node included the OC-Supported-Features AVP (see Section 4.4). Although sending the OC-Sequence-Number AVP is mandatory in the OC-Supported- Features AVP, the receiving node MAY always choose to ignore the sequence number if it can determine the feature support changes otherwise. The text seems to imply that the reporting DOIC endpoint, when receiving an application request message that contains an OC-Supported-Features AVP, needs to determine whether a feature support change occured (either by checking the value of the received sequence-number (probably) against a stored value, or by other unspecified means). However, this is not correct. The reporting DOIC endpoint may ignore the sequence-number even if it cannot determine whether or not a feature support change occured: The reporting DOIC endpoint simply takes the value of the OC-Feature- Vector as received in the request into account (if absent the default value applies) when processing the request. There is no need for the reporting DOIC endpoint to know whether a previous request contained the same or a different value in OC-Feature-Vector, i.e. whether there was a recent change. It has been argued that the reporting DOIC endpoint may (optionally) benefit from the presence of a Sequence-Number within OC-Supported- Features: The reporting DOIC endpoint may have stored the Sequence-Number and Feature-Vector as received in a previous request, and when receiving a new request the reporting DOIC endpoint would compare the received Sequence-Number from the new request with the stored Sequence-Number; If they match (i.e. no change of supported features occured) the reporting DOIC endpoint would ignore the received Feature-Vector from the new request and use the stored Feature-Vector for further processing; if they don't match (i.e. a change of supported features occured), the reporting DOIC endpoint would update the stored Sequence-Number and Feature-Vector with the received values from the new request and use the updated Feature- Vector for further processing. While it is debatable whether the described usecase is reasonable, the following issues have not been addressed: In configurations where the client does not support DOIC, an agent (A1) on a path from client to reporting DOIC endpoint (e.g. server) may take the role of a reacting DOIC endpoint and insert an OC-Supported-Features AVP in the (first) request message indicating its supported features. A subsequent request message sent from the same client to the same server may take another path on which another agent (A2) takes the role of the reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP in the subsequent request message indicating its supported features (which may be different from A1's supported features but may have the same sequence number). Since the reporting DOIC endpoint (e.g.server) - when receiving the subsequent request - cannot know whether the the reacting DOIC endpoint that inserted the OC-Supported-Features AVP in the subsequent request is identical to or different from the reacting DOIC endpoint that inserted the OC-Supported-Features AVP in the first request, it may frequently occure that the reporting DOIC endpoint receives request messages containing an OC-Supported-Features AVP with a Sequence-Number valuelower than the stored value (which may be interpreted as error), or equal to the stored value but with a different associated Feature Vector, or higher than the stored value but unmodified Feature Vector. In summary, the Sequence-Number within OC-Supported-Features is of no earthly use since the reporting DOIC endpoint cannot associate a received Sequence-Number (within OC-Supported-Features) with the identity of the reacting DOIC endpoint that sent the Sequence-Number. Even when such association was possible by enhancing the OC-Supported-Features AVP with the Diameter Identity of the reacting DOIC endpoint that generated the Sequence-Number, it would still simply not be needed as the reporting DOIC endpoint can base its processing on the received Feature-Vector (rather than on a stored Feature Vector). It is therefore proposed to remove the OC-Sequence-Number AVP from the OC- Supported Features AVP. --=20 ----------------------------------------------+-------------------------- Reporter: lionel.morand@orange-ftgroup.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: 2.0 Severity: Active WG Document | Keywords: ----------------------------------------------+-------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Tue Feb 4 04:21:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C834C1A03A5 for ; Tue, 4 Feb 2014 04:21:14 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2aWB_bkBo8F for ; Tue, 4 Feb 2014 04:21:13 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 970681A0383 for ; Tue, 4 Feb 2014 04:21:12 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id mc6so6569677lab.28 for ; Tue, 04 Feb 2014 04:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=ZxwUHKvtB6431fXvLILJ2TU6CivVb9DdhV8gwkVo3F4=; b=n5AKqNwKkDc1aLBifj+qHn3Xe49z1mnas1lGJkki0gtYB6WY4Rer61qUDiMnyng/BL cq0HvfMs2FL0ZxLF82Lx+JYAq7ffwRYYZPmuM26FrV9Bu7v0NgX4dPrfLww4dhMm9FLJ To0IGL95YKMOcPIvsT7JcWLqJdUGB+BckEnYL4l+YTz959VRbcNvWRE/W11PrsJukN4r /kSu37UyMm5etkpA0fZs9ALWBKZ+rOteTg+X8i7pBiJQ/9pKgDBHjjq5fCg2qoMMLIrh 2gMrpHQIuT2NZMNDNEsql78SMl7IlAbg5NQw2NN0KnQX9kOWh3rcoMZFJExAxmuDOcgc vkJQ== X-Received: by 10.112.175.43 with SMTP id bx11mr1277923lbc.51.1391516471620; Tue, 04 Feb 2014 04:21:11 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:df9:2a53:6fef:a8e8? ([2001:6e8:480:60:df9:2a53:6fef:a8e8]) by mx.google.com with ESMTPSA id mo3sm25060636lbb.17.2014.02.04.04.21.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 04:21:11 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 4 Feb 2014 14:21:10 +0200 Message-Id: <34C91490-AB66-49EC-BAEC-B74E9810307F@gmail.com> To: "dime@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] DIME London agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 12:21:15 -0000 Folks, London IETF is getting closer and it is time to get up with the meeting agenda. We will, of course, spend time on the current working group documents (overload, security, ..). If you feel like presenting something and need a time slot just email the chairs with the topic + time wish you have in mind. - Jouni & Lionel From srdonovan@usdonovans.com Tue Feb 4 05:29:11 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED521A0448 for ; Tue, 4 Feb 2014 05:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.561 X-Spam-Level: ** X-Spam-Status: No, score=2.561 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roha7Knlx_3I for ; Tue, 4 Feb 2014 05:29:10 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id F22E61A0416 for ; Tue, 4 Feb 2014 05:29:09 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52464 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WAg3m-0000a9-Tq for dime@ietf.org; Tue, 04 Feb 2014 05:29:07 -0800 Message-ID: <52F0EB22.8090804@usdonovans.com> Date: Tue, 04 Feb 2014 07:29:06 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------040207030101090600060409" X-OutGoing-Spam-Status: No, score=-1.9 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 Subject: [Dime] DOIC endpoint behavior - Agent Overload Report handling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 13:29:11 -0000 This is a multi-part message in MIME format. --------------040207030101090600060409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The following wording is proposed to be added to section 5.5 on Overload Report Processing. This goes along with the proposed wording for agent involvement in capability exchange. The most important piece of behavior proposed is for the case when the agent is a back-to-back DOIC association agent as illustrated here: DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC node In this case, it is proposed that when the DOC agent receives a host or realm overload report the DOC agent simply passes it on without taking further action. The goal being to do the overload abatement as close to the source of the request as possible. The text isn't perfect yet, but I wanted to get the basic behavior proposal across. Regards, Steve 5.5.4 Agent Considerations As discussed in section x.x.x, agents can take on the role of reporting node and reacting node. Agent as reporting node A DOC agent will take on the role of a reporting node any time that there is a downstream DOIC association. For the report types supporting in this document, an agent should only originate an overload report in two cases: - When the agent is acting as overload authority for a set of servers. In this case, requests are sent to the destination-host of the agent and the agent is responsible for reporting on the overload state when the server farm represented by that destination-host value is entering an overloaded condition. - When the agent is acting as overload authority for a realm. In this case, the agent is responsible for inserting realm based overload reports into answer messages from servers in that realm. Agent as reacting node An agent will take on the role of a reacting node whenever there is an upstream DOIC association. In this case, the agent will be reacting to host overload reports. The behavior of the agent acting as a reacting node depends on whether or not there is a downstream association. If there is a downstream DOIC association then the DOC agent should pass any overload report on to the downstream Diameter node without taking any further action. Note: This is based on the assumption that it is best to handle the overload instance as close to the source of the Diameter transaction as possible. Note: This is not a must because there could be operator specific policies that result in handling of the overload condition in the agent. If there is no downstream DOIC association then the DOC agent is responsible for handling the overload condition. In this case the DOC agent must throttle requests targeted for the host or realm indicated in the overload report. The method used should be consistent with the considerations outlined in section 5.5.2. When a request message is selected for throttling, the DOC agent must generate the appropriate error response message. Editors note: the error message to be sent is TBD. --------------040207030101090600060409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The following wording is proposed to be added to section 5.5 on Overload Report Processing.

This goes along with the proposed wording for agent involvement in capability exchange.

The most important piece of behavior proposed is for the case when the agent is a back-to-back DOIC association agent as illustrated here:

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node

In this case, it is proposed that when the DOC agent receives a host or realm overload report the DOC agent simply passes it on without taking further action.  The goal being to do the overload abatement as close to the source of the request as possible.

The text isn't perfect yet, but I wanted to get the basic behavior proposal across.

Regards,

Steve

5.5.4 Agent Considerations

As discussed in section x.x.x, agents can take on the role of reporting node and reacting node.

Agent as reporting node

A DOC agent will take on the role of a reporting node any time that there is a downstream DOIC association.

For the report types supporting in this document, an agent should only originate an overload report in two cases:

- When the agent is acting as overload authority for a set of servers.  In this case, requests are sent to the destination-host of the agent and the agent is responsible for reporting on the overload state when the server farm represented by that destination-host value is entering an overloaded condition.

- When the agent is acting as overload authority for a realm.  In this case, the agent is responsible for inserting realm based overload reports into answer messages from servers in that realm.

Agent as reacting node

An agent will take on the role of a reacting node whenever there is an upstream DOIC association.  In this case, the agent will be reacting to host overload reports.

The behavior of the agent acting as a reacting node depends on whether or not there is a downstream association.

If there is a downstream DOIC association then the DOC agent should pass any overload report on to the downstream Diameter node without taking any further action.

  Note: This is based on the assumption that it is best to handle the overload instance as close to the source of the Diameter transaction as possible.

  Note: This is not a must because there could be operator specific policies that result in handling of the overload condition in the agent.

If there is no downstream DOIC association then the DOC agent is responsible for handling the overload condition.  In this case the DOC agent must throttle requests targeted for the host or realm indicated in the overload report.  The method used should be consistent with the considerations outlined in section 5.5.2.

When a request message is selected for throttling, the DOC agent must generate the appropriate error response message.

Editors note: the error message to be sent is TBD.
 --------------040207030101090600060409-- From ulrich.wiehe@nsn.com Tue Feb 4 05:43:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3408F1A0444 for ; Tue, 4 Feb 2014 05:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR0bzPkFNwNi for ; Tue, 4 Feb 2014 05:43:43 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 66E2E1A041E for ; Tue, 4 Feb 2014 05:43:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s14DhdFX026582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 14:43:39 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s14Dhbot013418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 14:43:39 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Feb 2014 14:43:38 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 14:43:37 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC Endpoint behavior -- Capability Exchange Thread-Index: AQHPITtpNodjRHLeL0WcNoascGL9zpqk0C7A Date: Tue, 4 Feb 2014 13:43:37 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net> References: <52F02C62.70600@usdonovans.com> In-Reply-To: <52F02C62.70600@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 18156 X-purgate-ID: 151667::1391521420-00001A6F-C6A00456/0-0/0-0 Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 13:43:46 -0000 Steve, please find comments inline. Regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, February 04, 2014 12:55 AM To: dime@ietf.org Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange All, I believe that the current DOIC Endpoint behavior definition is not suffici= ently defined, especially for agents. I agree. There was also a change introduced in the -01 version of the draft that imp= lies that there can be a DOIC association that goes through a DOIC enabled = agent.=A0 This was not=A0 how I understood endpoints. same with me =A0 The original diagrams showed a DOIC agen= t as terminating an endpoint that came to it.=A0=A0=A0 I suspect there were= different assumptions that lead to clearly different interpretations.=A0=20 I propose that we return to the original diagrams and add the wording below= on how DOC agents behave.=A0 One way to look at this is that DOC agents ac= t as back-to-back DOC endpoints.=A0 I intentionally don't say back-to-back = Diameter endpoints because this does not impact anything except the handlin= g of DOIC related AVPs. Note that I don't believe this requires any changes to Diameter clients or = servers.=A0 I also don't believe this requires any changes to the contents = of the DOIC related AVPs but there is an open question as to whether there = is a need to indicate when a OC-Supported-Features AVP is generated or modi= fied by an agent. I propose to add the following section to the section on capabilities annou= ncement.=A0 I'll send a separate email proposing text to section 5.5 on how= DOC agents are to behave.=20 Regards, Steve ----- 5.3.1 DOC Agent handling of DOIC capability exchange. A DOC agent is defined as a Diameter agent that supports the DOIC extension= . A Diameter agent that supports the DOIC extension is not necessari= ly taking the role of a reacting DOIC endpoint. It only takes the role of a reacting DOIC endpoint when receiving a request= that does not contain an OC-Supported-Features AVP. Similarily a Diameter agent that supports the DOIC extensions is not necess= arily taking the role of a reporting DOIC endpoint. It only takes the role of a reporting DOIC endpoint when receiving a realm = type request (not containing a destination host) that contains an OC-Suppor= ted-Features AVP while it is configured to act as a reporting DOIC endpoint= for that realm. A DOC node is defined as a Diameter client, Diameter server or Diameter age= nt that supports the DOIC extension and decided to take the role of a reacting DOIC endpoint and/or re= porting DOIC endpoint . An downstream DOIC Association is defined as the association between the DO= IC supporting Diameter entity that sends a Diameter request message to a DO= C agent and the DOC agent. A upstream DOIC Association is defined as the association between a DOC age= nt and the Diameter entity to which the DOC agent sends the Diameter reques= t message.=A0 The following illustrated the upstream and downstream concept= s. =A0 DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC a= ssociation--> DOC=A0 node =A0 Direction of request message for a transaction -----> =A0 Direction of answer message for a transaction <----- this depends on the point of view: one node's downstream DOIC asso= ciation is another node's upstream DOIC association. The general case is: +---------+ +---------+ +--------+ +--------+ = +--------+ +--------+ | client | | A1 | | A2 | | A3 | = | A4 | | server | | no DOIC | | no DOIC | | DOIC | | DOIC | = | DOIC | | DOIC | | support | | support | | support| | support| = | support| | support|=20 +---------+ +---------+ +--------+ +--------+ = +--------+ +--------+ | | | | = | | | | |<---DOIC association 1---------------= ---------->|<-------DOIC association 2-->| | | | | = | | | | |<-----------------DOIC association 3-= ---------------------------------------->| | | | | = | | | | | | = | | |----1.xxR------->|---2.xxR----->| | = | | | | |---3.xxR----->|----4.xxR-------------= ---------->| | | | | | = |--------5.xxR--------------->|=20 | | | | = |<-------6.xxA----------------| | | |<--8.xxA------|<---7.xxA-------------= -----------| | |<---10.xxA-------|<--9.xxA------| | = | | | | | | = | | | | | | = | | | | | | = | | | | | | = | | |----11.xxR------>|---12.xxR---->| | = | | | | |---13.xxR---->|-----14.xxR-----------= ---------->|-------15.xxR--------------->| | | | | = | | | | |<---18.xxA----|<----17.xxA-----------= -----------|<-----16.xxA-----------------| |<---20.xxA-------|<---19.xxA----| | = | | | | | | = | | DOIC association 1 is for realm type requests;=20 DOIC association 2 is for request for which A4 selects the server DOIC association 3 is for host type requests 1. the client that does not support DOIC sends 1.xxR (realm type request no= t containing destination host) to the next hop; 1.xxR does not contain an O= C-Supported-Features AVP 2. the agent A1 that does not support DOIC forwards the request to the next= hop; 2.xxR still dos not contain an OC-Supported-Feature AVP. 3. the agent A2 that supports DOIC decides to take the role of a reacting e= ndpoint; it inserts an OC-Supported-Features AVP into 3.xxR indicating supp= ort of features 1 and 2 (in this example). 4. agent A3, although it supports DOIC, does not take the role of a reactin= g endpoint (because 3.xxR contains an OC-Supported-Features AVP); it also d= oes not take the role of a reporting endpoint since it is not configured to= act as reporting endpoint for the destination realm received in 3.xxR; 4.x= xR (unmodified) is sent to the next hop. 5. agent A4 is configured to take the role of the reporting endpoint for th= e realm. It therefore removes the OC-Supported-Features AVP reveived in 4.x= xR and inserts its own supported features (in this example features 1 and 3= ) in 5.xxR. A4 also selects the server to which 5.xxR is sent. 6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA incl= uding an OLR1 (host type) requesting a feature 3 specific traffic reduction= (e.g. window size 20).=20 7. A4 calculates the overall realm overload level, removes the received OLR= 1 and adds its own calculated realm type OLR2 (e.g. a feature 1 specific tr= affic reduction of 50%-loss) to 7.xxA. A4 stores OLR1 for later use. 8. A3 not taking any DOIC role forwards the answer unmodified. 9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores OLR2= for later use. 10. A1 not supporting DOIC is transparent. 11. client sends a new request 11.xxR (containing destination host as learn= d from 10.xxA; no OC-Supported-Features AVP included. 12. A1 is transparent. 13. A2 decides to take the role of the reacting endpoint and includes again= its supported features 1 and 2 in OC-Supported-Features AVO sent within 13= .xxR. 14. A3 is transparent 15. A4 is transparent for host type requests that contain an OC-Supported-F= eatures AVP. 16. server returns 16.xxA including a host type OLR3 requesting a feature 1= specific traffic reduction of e.g. 30%-loss. 17. A4 is transparent 18. A3 is transparent 19. A2 stores OLR3 for later use and may remove OLR3 when sending 19.xxA. 20. client receives 20.xxA. Four scenarios must be supported: =A0 - Scenario 1 - There is both an upstream and downstream DOIC associatio= n. for example see A4 in the figure above =A0 - Scenario 2 - There is no upstream DOIC association do you mean "There is a downstream DOIC association but no upstrea= m DOIC association"? Not covered in the figure above. =A0 - Scenario 3 - There is no downstream DOIC association do you mean "There is an upstream DOIC association but no downstre= am DOIC association"? for example see A2 in the figure above =20 =A0 - Scenario 4 - No DOIC association in either direction for example see A3 in the figure above Scenario 1 - Both upstream and downstream DOIC associations Request message handling: A DOC agent that receives a request that contains the OC-Supported-Features= AVP must act as an endpoint for the downstream DOIC association. NO! see A3 receiving 3.xxR or 13.xxR (this may not be scenario 1, = but how does the agent know which scenario applies?) If the DOC agent relays or proxies the request message then the agent must = include an OC-Supported-Features AVP in the relayed message.=A0 The content= s of the OC-Supported-Features AVP must include, at a minimum, all of the c= ontent included in the received OC-Supported-Features AVP.=A0 If the agent = does not support any additional features then the sent OC-Supported-Feature= s AVP will remain the same as the received OC-Supported-Features AVP. There cannot be more than one OC-Supported-Features AVPs in one req= uest. An agent that inserts an OC-Supported-Features AVP must remove the re= ceived OC-Supported-Features AVP (see A4 when sending 5.xxR). The inserted = OC-Supported Features AVP shall indicate the features the inserting node su= pports, not more, not less If the agent supports DOIC features that are not indicated in the received = OC-Supported-Features AVP then the agent must modify the OC-Supported-Featu= res AVP to indicate support for those features.=A0 The modified OC-Supporte= d-Features AVP must be included in the relayed request message. =A0 Note: any DOIC extension must define the changes needed to the OC-Featu= re-Vector AVP and any additional AVPs that need to be added to the OC-Suppo= rted-Features AVP as part of the capabilities advertisement for that featur= e. Question: Should there be an indication that the contents of the OC-Support= ed-Features AVP was changed? no. for what reason? Question: Will this work when end-to-end security is introduced?=A0 Would a= dding a separate OC-Supported-Features AVP be better, especially when end-t= o-end security is considered? what is the issue? Answer message handling: When an agent receives the=A0 answer message that corresponds to the above = request message i.e. the request message into which the agent has inserted its OC-= Supported-Features AVP , the agent must act as the DOIC endpoint for the upstream DOIC association= .=A0=20 If the DOC agent relays or proxies the answer message then the agent must i= nclude an OC-Supported-Features AVP in the relayed message. OC-Supported-Features AVP in answer messages is an open issue =A0 The contents of the OC-Supported-Features AVP must include, at a minimu= m, all of the content included in the received OC-Supported-Features AVP.= =A0 If the agent does not support any additional features then the sent OC-= Supported-Features AVP will remain the same as the received OC-Supported-Fe= atures AVP. If the agent supports DOIC features that are not indicated in the received = OC-Supported-Features AVP then the agent should modify the OC-Supported-Fea= tures AVP to indicate support for those features.=A0 The modified OC-Suppor= ted Features AVP must be included in the relayed answer message. Scenario 2 - No downstream DOIC association with an upstream association wasn't that scenario 3? In this case a request is received that does not contain an OC-Supported-Fe= atures AVP. Request message handling: If a DOC agent receives a request that does NOT contain an OC-Supported-Fea= tures AVP then the agent must generate an OC-Supported-Features AVP reflect= ing the DOIC features supported by the DOC agent.=A0 The new OC-Supported-F= eatures AVP must be included in the relayed/proxied request message. The agent will then become the reacting DOIC endpoint for the upstream DOIC= association that results from the transaction.=A0=20 Note: Section x.x.x defines agent behavior when it is the reacting node for= a DOIC association. Answer message handling In this case the answer message will contain an OC-Supported-Features AVP.= =A0 The DOC agent must store the advertised capabilities for use when the D= OC agent reacts to an overload report from the upstream Diameter node. The DOC agent should remove the OC-Supported-Features AVP from the answer m= essage before relaying/proxying the answer message.=A0=20 Scenario 3 - Downstream DOC association with no upstream DOIC association wasn't this scenario 2? In this case a OC-Supported-Features AVP is received in the request from th= e downstream Diameter entity but no OC-Supported-Features AVP is received i= n the answer message received from the upstream Diameter entity.=A0 In this= case the agent must act as the reporting DOIC endpoint for the downstream = DOIC association. this is totally new to me. Where does this come from? If a server = does not support DOIC it cannot request load reduction from a downstream ag= ent. The downstream agent (even if it would detect the DOIC-non-support of = the server) cannot request load reduction from further downstream nodes on = behalf of the server Request message handling: Request message handling is the same as for scenario 1. Answer message handling: If a DOC agent receives an answer message that does not contain an OC-Suppo= rted-Features AVP for a transaction that includes an upstream DOC associati= on then the agent must generate an OC-Supported-Features AVP reflecting the= DOIC features supported by the DOC agent.=A0 The generation of this OC-Sup= ported-Features AVP must also follow the rules specified in section 5.3.2.= =A0 The new OC-Supported-Features AVP must be included in the relayed/proxi= ed the answer message. Scenario 4 - No upstream association and no downstream association Request message handling: The request message handling in this case is the same as scenario 2. Answer message handling: If the DOC agent receives an answer message that does not contain an OC-Sup= ported-Features AVP for a transaction that does not include a downstream DO= C association then the agent must NOT generate an OC-Supported-Features AVP= .=A0 The DOC Agent must relay/proxy the answer message with no DOIC related= change. the open issue seems to be: How can an agent determine which scena= rio is applicable? Let me try: An agent that does not support DOIC is always in scenario 4 (no upstream DO= IC association, no downstream DOIC association). For an agent that supports DOIC: When receiving a request that does not contain an OC-Supported-Features AVP= the agent is in scenario 3 or 4 (no downstream DOIC association). Whether = its 3 or 4 depends on whether or not an OLR is received in the correspondin= g answer. When receiving a host type request (a request that contains a Destination-H= ost AVP) that contains an OC-Supported-Feature AVP the agent is in scenario= 4 (no upstream DOIC association, no downstream DOIC association) When receiving a realm type request (a request that does not contain a Dest= ination-Host AVP) that contains an OC-Supported-Feature AVP and the agent i= s configured to act as reporting node for that realm, the agent is scenario= 1 or 2 (there is a downstream DOIC association). Whether its 1 or 2 depend= s on whether or not an OLR is received in the corresponding answer. When receiving a realm type request (a request that does not contain a Dest= ination-Host AVP) that contains an OC-Supported-Feature AVP and the agent i= s configured not to act as reporting node for that realm, the agent is in s= cenario 4 (no upstream DOIC association, no downstream DOIC association). <= /Ulrich> From ulrich.wiehe@nsn.com Tue Feb 4 06:55:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A21A00EE for ; Tue, 4 Feb 2014 06:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbf515fH-lh5 for ; Tue, 4 Feb 2014 06:55:42 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCA61A00EC for ; Tue, 4 Feb 2014 06:55:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s14Etftb022524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 15:55:41 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s14EtfY3011433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 15:55:41 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Feb 2014 15:55:40 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 15:55:40 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC endpoint behavior - Agent Overload Report handling Thread-Index: AQHPIa0b5xTwkmMKqUKKoWnk7AazK5qlHm7Q Date: Tue, 4 Feb 2014 14:55:40 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1E4F@DEMUMBX014.nsn-intra.net> References: <52F0EB22.8090804@usdonovans.com> In-Reply-To: <52F0EB22.8090804@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4558 X-purgate-ID: 151667::1391525741-000025D0-6814D4C9/0-0/0-0 Subject: Re: [Dime] DOIC endpoint behavior - Agent Overload Report handling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 14:55:45 -0000 Steve, my understanding is different. How would it be possible that the DOC agent that has both upstream and down= stream DOIC associations receives a realm overload report? A host overload report received by the DOC agent on the DOC agent's upstrea= m DOIC association will be consistent with the supported features advertis= ed by the DOC agent on the DOC agent's upstream DOIC association but it wil= l not necessarily be consistent with the supported features adverised by th= e DOC node on the DOC agent's downstream DOIC association. Actually there m= ay not be a single supported feature in common to both associations. Theref= ore it makes no sense to simply pass the OLR across associations. The DOC a= gent should rather aggregate all received OLRs on all its upstream associat= ions and transform the aggregation into a format the downstream DOC node un= derstands (i.e. consistent with the supported features advertised on the DO= C agent's downstream DOIC association). Regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, February 04, 2014 2:29 PM To: dime@ietf.org Subject: [Dime] DOIC endpoint behavior - Agent Overload Report handling The following wording is proposed to be added to section 5.5 on Overload Re= port Processing. This goes along with the proposed wording for agent involvement in capabili= ty exchange. The most important piece of behavior proposed is for the case when the agen= t is a back-to-back DOIC association agent as illustrated here: =A0 DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC a= ssociation--> DOC=A0 node In this case, it is proposed that when the DOC agent receives a host or rea= lm overload report the DOC agent simply passes it on without taking further= action.=A0 The goal being to do the overload abatement as close to the sou= rce of the request as possible. The text isn't perfect yet, but I wanted to get the basic behavior proposal= across. Regards, Steve 5.5.4 Agent Considerations As discussed in section x.x.x, agents can take on the role of reporting nod= e and reacting node. Agent as reporting node A DOC agent will take on the role of a reporting node any time that there i= s a downstream DOIC association. For the report types supporting in this document, an agent should only orig= inate an overload report in two cases: - When the agent is acting as overload authority for a set of servers.=A0 I= n this case, requests are sent to the destination-host of the agent and the= agent is responsible for reporting on the overload state when the server f= arm represented by that destination-host value is entering an overloaded co= ndition. In this case the overload report generated by the agent i= s of host-type - When the agent is acting as overload authority for a realm.=A0 In this ca= se, the agent is responsible for inserting realm based overload reports int= o answer messages from servers in that realm. In both cases the agent MUST remove OC-OLR AVPs from answer messag= es received from servers of the server farm / servers in the realm. Agent as reacting node An agent will take on the role of a reacting node whenever there is an upst= ream DOIC association.=A0 In this case, the agent will be reacting to host = overload reports. The behavior of the agent acting as a reacting node depends on whether or n= ot there is a downstream association. If there is a downstream DOIC association then the DOC agent should pass an= y overload report on to the downstream Diameter node without taking any fur= ther action. =A0 Note: This is based on the assumption that it is best to handle the ove= rload instance as close to the source of the Diameter transaction as possib= le. =A0 Note: This is not a must because there could be operator specific polic= ies that result in handling of the overload condition in the agent. If there is no downstream DOIC association then the DOC agent is responsibl= e for handling the overload condition.=A0 In this case the DOC agent must t= hrottle requests targeted for the host or realm indicated in the overload r= eport.=A0 The method used should be consistent with the considerations outl= ined in section 5.5.2. When a request message is selected for throttling, the DOC agent must gener= ate the appropriate error response message. Editors note: the error message to be sent is TBD. From lionel.morand@orange.com Tue Feb 4 07:01:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9EF1A0124 for ; Tue, 4 Feb 2014 07:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QfviqSdC_oo for ; Tue, 4 Feb 2014 07:01:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C7AB21A0120 for ; Tue, 4 Feb 2014 07:01:06 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D572D2DC080 for ; Tue, 4 Feb 2014 16:01:05 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BE28427C053 for ; Tue, 4 Feb 2014 16:01:05 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 16:01:05 +0100 From: To: "dime@ietf.org" Thread-Topic: [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPIYXLAgb8ZGaPek2BLgM9UmoN/5qk7I/g Date: Tue, 4 Feb 2014 15:01:04 +0000 Message-ID: <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> In-Reply-To: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.4.140016 Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 15:01:09 -0000 SSB0aGluayB0aGF0IHRoZXJlIGlzIGFjdHVhbGx5IGFuIGlzc3VlIGhlcmUgYnV0IHRoZSBwcm9w b3NlZCB3YXkgdG8gc29sdmUgaXQgaXMgbm90IHRoZSBjb3JyZWN0IG9uZS4NClRoZSBpbml0aWFs IGlkZWEgd2FzIHRvIGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIG92ZXJsb2FkIHJlcG9ydCB3aXRo IHNldmVyYWwgYWxnb3JpdGhtcy4gU28gdGhlIE9MUiB3YXMgc29tZWhvdyBvbmx5IG1lYW5pbmdm dWwgYWxvbmcgd2l0aCB0aGUgT0MtRmVhdHVyZS1WZWN0b3IgQVZQLg0KDQpCdXQgYmVjYXVzZSB0 aGUgT0MtRmVhdHVyZS1WZWN0b3IgQVZQIGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgZmxhZ3MsIGl0 IGlzIG5vdCBwb3NzaWJsZSB0byBzYXkgdGhhdCB0aGlzIE9MUiBpcyB0byBiZSB1c2VkIHdpdGgg b25seSBvbmUgZ2l2ZW4gYWxnbyB3aGVuIG1vcmUgdGhhbiBvbmUgaXMgZGVmaW5lZCAoYXMgdGhl IGJpdCBmbGFncyB3aWxsIGFkdmVydGl6ZSAxIEFORCAyIGZvciAyIHN1cHBvcnRlZCBhbGdvcyku IFNvIHRoZSBPQy1GZWF0dXJlLVZlY3RvciBjYW5ub3QgYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUg YWJhdGVtZW50IHRvIHBlcmZvcm0uDQoNCkFzIHRoZSBzeW50YXggb2YgdGhlIE9DLUZlYXR1cmUt VmVjdG9yIGlzIGFkYXB0ZWQgdG8gYWR2ZXJ0aXplIHN1cHBvcnRlZCBhbGdvcywgaXQgY291bGQg YmUgZWFzaWVyIHRvIGNsYXJpZnkgdGhhdCB0aGUgT0MtT0xSIEFWUCBpcyBUSEUgcmVwb3J0IEFW UCBmb3IgdGhlIHJlZHVjdGlvbiBhbGdvIChkZWZhdWx0KSBhbmQgYSBuZXcgZGVkaWNhdGVkIHJl cG9ydCBBVlAgbXVzdCBiZSBjcmVhdGVkIHdoZW4gYSBuZXcgYWxnbyBpcyBpbnRyb2R1Y2VkLiBJ biB0aGlzIHdheSwgdGhlIE9DLU9MUiBpcyBzZWxmLWV4cGxpY2l0Lg0KDQpJdCB3b3VsZCBiZSBw dXJlbHkgb3B0aW9uYWwgdG8gc2VuZCB0aGUgU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCBhbG9uZyB3 aXRoIHRoZSBPQy1PTFIgQVZQLg0KDQpMaW9uZWwgDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1lQHRyYWMudG9v bHMuaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDgNCsOA wqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PCoDogZGltZUBpZXRmLm9yZw0KT2JqZXTCoDog W2RpbWVdICMzMDogT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCBpbiBhbnN3ZXIgbWVzc2FnZXMN Cg0KIzMwOiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIGluIGFuc3dlciBtZXNzYWdlcw0KDQog QWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IGZlYXR1cmUgYWR2ZXJ0aXNlbWVudC9uZWdvdGlhdGlv biBtZWNoYW5pc20gaW4NCiB0aGUgLTAxIGRyYWZ0IHJlcG9ydGluZyBET0lDIGVuZHBvaW50IGlu c2VydCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQDQogaW4gYW5zd2VyIG1lc3NhZ2VzIHRv IGluZGljYXRlIHRoZWlyIHN1cHBvcnRlZCBPQyBmZWF0dXJlcyB0byB0aGUgcmVhY3RpbmcNCiBE T0lDIGVuZHBvaW50Lg0KIFRoZSBhdXRob3Igb2YgdGhpcyBkb2N1bWVudCBiZWxpZXZlcyB0aGF0 ICB0aGUgYmVzdCBhIHJlYWN0aW5nIG5vZGUgY2FuIGRvDQogd2l0aCBzdWNoIGluZm9ybWF0aW9u IGlzIHRvIGlnbm9yZSBpdCwgYW5kIHRoZXJlZm9yZSBwcm9wb3NlcyB0byBhbGxvdw0KIHJlcG9y dGluZyBub2RlcyBub3QgdG8gaW5zZXJ0IE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlBzIGluIGFu c3dlcg0KIG1lc3NhZ2VzLg0KIEN1cnJlbnRseSBvbmx5IG9uZSBmZWF0dXJlIGlzIGRlZmluZWQg KE9MUl9ERUZBVUxUX0FMR08pLg0KIEEgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB0aGF0IHN1cHBv cnRzIG9ubHkgT0xSX0RFRkFVTFRfQUxHTyBidXQgbm8gb3RoZXINCiBmZWF0dXJlIGlzIG9ubHkg aW50ZXJlc3RlZCBpbiByZWNlaXZpbmcvbm90IHJlY2VpdmluZyBPQy1PTFIgQVZQcyBmcm9tDQog cmVwb3J0aW5nIERPSUMtZW5kcG9pbnRzLiBSZWNlaXZpbmcgYW4gT0MtT0xSIEFWUCBpbXBsaWNp dGx5IGluZGljYXRlcw0KIHN1cHBvcnQgb2YgT0xSX0RFRkFVTFRfQUxHTyAgYnkgdGhlIHJlcG9y dGluZyBET0lDIGVuZHBvaW50OyBub3QgcmVjZWl2aW5nDQogYW4gT0MtT0xSLUFWUCBmcm9tIHRo ZSByZXBvcnRpbmcgRE9JQyBlbmRwb2ludCBtYXkgaGF2ZSB0d28gcmVhc29uczoNCg0KIGEpIFRo ZXJlIGlzIG5vIG92ZXJsb2FkDQogYikgRE9JQyBpcyBub3Qgc3VwcG9ydGVkDQoNCiBUaGUgcmVh Y3RpbmcgRE9JQyBlbmRwb2ludCBkb2VzIG5vdCBuZWVkIHRvIGRpZmZlcmVudGlhdGUgYmV0d2Vl biB0aGVzZQ0KIHR3byBjYXNlcyBhcyB0aGUgYmVoYXZpb3IgKGRvIG5vdCB0aHJvdHRsZSkgaXMg dGhlIHNhbWUgaW4gYm90aCBjYXNlcy4NCiBUaGUgLTAxIGRyYWZ0IHNheXMgaW4gIGNsYXVzZSA0 LjE6DQogICAgSWYgdGhlcmUgaXMgbm8gc2luZ2xlIG1hdGNoaW5nDQogICAgY2FwYWJpbGl0eSB0 aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIGFjdCBhcyBpZiBpdCBkb2VzIG5vdCBpbXBsZW1lbnQNCiAg ICBET0lDIGFuZCBjZWFzZSBpbnNlcnRpbmcgYW55IERPSUMgcmVsYXRlZCBBVlBzIGludG8gYW55 IERpYW1ldGVyDQogICAgbWVzc2FnZXMgd2l0aCB0aGlzIHNwZWNpZmljIHJlYWN0aW5nIG5vZGUu DQoNCiBUaGlzIGhvd2V2ZXIgaXMgaW5jb25zaXN0ZW50Lg0KIFRoZSByZWFjdGluZyBub2RlIHRo YXQgY2Vhc2VzIHNlbmRpbmcgRE9JQyByZWxhdGVkIEFWUHMgd291bGQgbmV2ZXINCiByZWNvZ25p emUgd2hlbiB0aGUgc2VydmVyIGlzIHVwZ3JhZGVkIHRvIHN1cHBvcnQgRE9JQy4NCiBTdWJzZXF1 ZW50IHJlcXVlc3RzIChub3QgaW5jbHVkaW5nIERPSUMgcmVsYXRlZCBBVlBzKSBtYXkgdGFrZSBh IGRpZmZlcmVudA0KIHBhdGggdG93YXJkcyB0aGUgc2VydmVyIGFuZCBvbiB0aGF0IHBhdGggdGhl cmUgbWF5IGJlIGFuIGFnZW50IHRoYXQNCiBzdXBwb3J0cyBET0lDICh3aXRoIGEgbWF0Y2ggb2Yg c3VwcG9ydGVkIGZlYXR1cmVzKSBhbmQgY291bGQgdGFrZSB0aGUgcm9sZQ0KIG9mIHRoZSByZXBv cnRpbmcgRE9JQyBlbmRwb2ludDsgYnV0IHRoZSBhZ2VudCBjYW5ub3QgdGFrZSB0aGlzIHJvbGUg c2luY2UNCiB0aGUgcmVhY3Rpbmcgbm9kZSAoYWx0aG91Z2ggc3VwcG9ydGluZyBET0lDKSBjZWFz ZWQgc2VuZGluZyBvZiBPQy0NCiBTdXBwb3J0ZWQtRmVhdHVyZXMgQVZQcy4NCiBJbiBzdW1tYXJ5 OiBBcyBsb25nIGFzIG5vIGV4dGVuc2lvbiBmZWF0dXJlIGlzIGRlZmluZWQgd2l0aGluICBkcmFm dC1pZXRmLQ0KIGRpbWUtb3ZsaSAgKGkuZS4gbmV2ZXIsIHNpbmNlIGV4dGVuc2lvbnMgd2lsbCAg YmUgZGVmaW5lZCBpbiBvdGhlcg0KIGRyYWZ0cyksIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGRyYWZ0 LWlldGYtZGltZS1vdmxpICB0byBtYW5kYXRlIG9yIGV2ZW4NCiBkZXNjcmliZSBpbmNsdXNpb24g b2YgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCBpbiBhbnN3ZXIgbWVzc2FnZXMuDQoNCi0tIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiBSZXBvcnRlcjogIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSAgfCAgICAgIE93 bmVyOiAgVWxyaWNoIFdpZWhlDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAg IHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAg ICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBkcmFmdC1kb2NkdC1kaW1lLW92bGkgICAgIHwg ICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgICAgICAgfCAgIEtl eXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL3dnL2RpbWUvdHJhYy90aWNrZXQvMzA+DQpkaW1lIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv d2cvZGltZS8+DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From lionel.morand@orange.com Tue Feb 4 07:37:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE40E1A0119 for ; Tue, 4 Feb 2014 07:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5lNMEgSkNsN for ; Tue, 4 Feb 2014 07:37:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5961A00F9 for ; Tue, 4 Feb 2014 07:37:08 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 46F8322C502 for ; Tue, 4 Feb 2014 16:37:07 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2BE5323807B for ; Tue, 4 Feb 2014 16:37:07 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 16:37:06 +0100 From: To: "dime@ietf.org" Thread-Topic: [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIYXrEbHIS33Ogky6NzoFq2RrOJqlOVzg Date: Tue, 4 Feb 2014 15:37:05 +0000 Message-ID: <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> In-Reply-To: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 15:37:11 -0000 SSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcg bm9kZSBET0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28gdGhlIG9w dGlvbnMgd291bGQgYmU6DQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0gT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGlu IHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhl IGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQpJZiB0aGVyZSBpcyBubyBvdGhlciBjcml0 ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0aGUgYmVzdCBhcHByb2FjaC4NCg0KTGlvbmVsDQoN Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFtt YWlsdG86dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBtYXJkaSA0 IGbDqXZyaWVyIDIwMTQgMDk6NDkNCsOAwqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PCoDog ZGltZUBpZXRmLm9yZw0KT2JqZXTCoDogW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy b3R0bGluZw0KDQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhDQp0aHJvdHRsaW5nDQoNCiBJdCBoYXMg YmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ IHRoYXQgaXMNCiB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBp biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQNCiBzdXJ2aXZlZCBhIHRocm90dGxpbmcuIFRoaXMgQVZQ IHdvdWxkIGluZGljYXRlIHRoZSBTZXF1ZW5jZS1OdW1iZXINCiAoVGltZVN0YW1wKSBvZiB0aGUg T0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQogc3Vydml2 ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJy ZW50bHkgbm8NCiB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4gIFJlcG9ydGluZyBET0lDIGVuZHBv aW50cyBtYXkgdXNlIHRoaXMNCiBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhl ciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZQ0KIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQg d2l0aCB0aGUgbGF0ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNt IHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlDQogcmVwb3J0aW5nIG5vZGUgdG8gc2Vu ZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDDQogZW5k cG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBh Y3R1YWxseSBkb2luZw0KIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5n L25vdCB0aHJvdHRsaW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0 bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDDQogZW5kcG9pbnQgdG8gZGV0ZWN0 IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmcNCiBE T0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4NCiBUaGUgZmVlZGJhY2sg bWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQog SW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCB0bw0KIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp dmVkIGEgdGhyb3R0bGluZy4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgbGlvbmVsLm1v cmFuZEBvcmFuZ2UuY29tICB8ICAgICAgT3duZXI6ICBVbHJpY2ggV2llaGUNCiAgICAgVHlwZTog IGRlZmVjdCAgICAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6 ICBtYWpvciAgICAgICAgICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIGRy YWZ0LWRvY2R0LWRpbWUtb3ZsaSAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgQWN0aXZl IFdHIERvY3VtZW50ICAgICAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJM OiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvZGltZS90cmFjL3RpY2tldC8zMT4NCmRp bWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9kaW1lLz4NCg0KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 LgoK From trac+dime@trac.tools.ietf.org Tue Feb 4 07:39:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E401A012A for ; Tue, 4 Feb 2014 07:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6VdfKNLCQkx for ; Tue, 4 Feb 2014 07:39:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1CB1A00EE for ; Tue, 4 Feb 2014 07:39:13 -0800 (PST) Received: from localhost ([127.0.0.1]:34236 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAi5c-00025U-Ju; Tue, 04 Feb 2014 16:39:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 15:39:07 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/35#comment:2 Message-ID: <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:39:16 -0000 #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33) two > additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DOIC endpoints to request different amount of load reduction from different clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this requirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the request match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the request match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Tue Feb 4 07:41:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A961A012A for ; Tue, 4 Feb 2014 07:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A-sgieiQHss for ; Tue, 4 Feb 2014 07:41:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0DF1A011C for ; Tue, 4 Feb 2014 07:41:26 -0800 (PST) Received: from localhost ([127.0.0.1]:34306 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WAi7p-0007Nk-Oj; Tue, 04 Feb 2014 16:41:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com X-Trac-Project: dime Date: Tue, 04 Feb 2014 15:41:25 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/33#comment:1 Message-ID: <081.efc851b7d0ee3815bbf76bcd49eb6b55@trac.tools.ietf.org> References: <066.7a9f5ebf154a20a7d05d51b6a5e8f458@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <066.7a9f5ebf154a20a7d05d51b6a5e8f458@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: Re: [Dime] [dime] #33: Overload Mitigation Differentiation per Client X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:41:27 -0000 #33: Overload Mitigation Differentiation per Client Changes (by lionel.morand@orange-ftgroup.com): * status: new => closed * resolution: => duplicate Comment: This is included in ticket#35 -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From ulrich.wiehe@nsn.com Tue Feb 4 08:03:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9062D1A0124 for ; Tue, 4 Feb 2014 08:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukUnhVjUt5BK for ; Tue, 4 Feb 2014 08:03:37 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 433081A0128 for ; Tue, 4 Feb 2014 08:03:36 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s14G3Zh3005888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 17:03:35 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s14G3Z74031557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 17:03:35 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 17:03:35 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPIbnza0SZ1wdbvEGvoj4P8RAtnpqlM3Sg Date: Tue, 4 Feb 2014 16:03:34 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8902 X-purgate-ID: 151667::1391529815-000025D0-5A665812/0-0/0-0 Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 16:03:40 -0000 RGVhciBMaW9uZWwsDQoNCnRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZS4NCg0KSWYgSSBjb3Jy ZWN0bHkgdW5kZXJzdGFuZCwgdGhlIHByaW5jaXBsZXMgd291bGQgYmU6DQoxLiBTZW5kaW5nIE9D LVN1cHBvcnRlZC1GZWF0dXJlcyBpbiBhbnN3ZXIgbWVzc2FnZXMgaXMgc3ludGFjdGljYWxseSBv cHRpb25hbC4NCjIuIFdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgZG9lcyBvbmx5IHN1cHBvcnQgT0xS X0RFRkFVTFRfQUxHTyAsIHRoZSByZXBvcnRpbmcgbm9kZSBzaG91bGQgbm90IGluc2VydCBhbiBP Qy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIGluIHRoZSBhbnN3ZXIgbWVzc2FnZS4NCjMuIFdoZW4g dGhlIHJlcG9ydGluZyBub2RlIGRvZXMgb25seSBzdXBwb3J0IE9MUl9ERUZBVUxUX0FMR08sIGl0 IHNob3VsZCBub3QgaW5zZXJ0IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgaW4gdGhlIGFu c3dlciBtZXNzYWdlLg0KNC4gQSByZWFjdGluZyBub2RlIHRoYXQgc3VwcG9ydHMgb25seSBPTFJf REVGQVVMVF9BTEdPIGNhbiBzYWZlbHkgaWdub3JlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlBz IHJlY2VpdmVkIGluIGFuc3dlciBtZXNzYWdlcy4NCjUuIEEgcmVhY3Rpbmcgbm9kZSB0aGF0IHN1 cHBvcnRzIG9ubHkgT0xSX0RFRkFVTFRfQUxHTyBjYW4gc2FmZWx5IGlnbm9yIGFsbCBleHRlbnNp b25zIHJlY2VpdmVkIGluIGFuIE9DLU9MUi4NCjYuIFdoZW4gYSBuZXcgZmVhdHVyZSBpcyBpbnRy b2R1Y2VkLCB0aGUgc3BlYyBpbnRyb2R1Y2luZyB0aGUgbmV3IGZlYXR1cmUgbXVzdCBkZWZpbmUg dGhlIGRldGFpbHMgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkgb2Ygbm9kZXMgc3VwcG9ydGlu ZyB0aGUgbmV3IGZlYXR1cmUgd2l0aCBub2RlcyB0aGF0IGRvIG5vdCBzdXBwb3J0IHRoZSBuZXcg ZmVhdHVyZSAodGFraW5nIGludG8gYWNjb3VudCB0aGF0IG5vZGVzIG5vdCBzdXBwb3J0aW5nIHRo ZSBuZXcgZmVhdHVyZSBhY3QgYWNjb3JkaW5nIHRvIHRoZSBwcmluY2lwbGVzIDEuLTUuKS4NCg0K DQpCZXN0IHJlZ2FyZHMNClVscmljaA0KICANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0 LCAyMDE0IDQ6MDEgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtk aW1lXSAjMzA6IE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgaW4gYW5zd2VyIG1lc3NhZ2VzDQoN CkkgdGhpbmsgdGhhdCB0aGVyZSBpcyBhY3R1YWxseSBhbiBpc3N1ZSBoZXJlIGJ1dCB0aGUgcHJv cG9zZWQgd2F5IHRvIHNvbHZlIGl0IGlzIG5vdCB0aGUgY29ycmVjdCBvbmUuDQpUaGUgaW5pdGlh bCBpZGVhIHdhcyB0byBiZSBhYmxlIHRvIHVzZSB0aGUgc2FtZSBvdmVybG9hZCByZXBvcnQgd2l0 aCBzZXZlcmFsIGFsZ29yaXRobXMuIFNvIHRoZSBPTFIgd2FzIHNvbWVob3cgb25seSBtZWFuaW5n ZnVsIGFsb25nIHdpdGggdGhlIE9DLUZlYXR1cmUtVmVjdG9yIEFWUC4NCg0KQnV0IGJlY2F1c2Ug dGhlIE9DLUZlYXR1cmUtVmVjdG9yIEFWUCBpcyBkZWZpbmVkIGFzIGEgc2V0IG9mIGZsYWdzLCBp dCBpcyBub3QgcG9zc2libGUgdG8gc2F5IHRoYXQgdGhpcyBPTFIgaXMgdG8gYmUgdXNlZCB3aXRo IG9ubHkgb25lIGdpdmVuIGFsZ28gd2hlbiBtb3JlIHRoYW4gb25lIGlzIGRlZmluZWQgKGFzIHRo ZSBiaXQgZmxhZ3Mgd2lsbCBhZHZlcnRpemUgMSBBTkQgMiBmb3IgMiBzdXBwb3J0ZWQgYWxnb3Mp LiBTbyB0aGUgT0MtRmVhdHVyZS1WZWN0b3IgY2Fubm90IGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhl IGFiYXRlbWVudCB0byBwZXJmb3JtLg0KDQpBcyB0aGUgc3ludGF4IG9mIHRoZSBPQy1GZWF0dXJl LVZlY3RvciBpcyBhZGFwdGVkIHRvIGFkdmVydGl6ZSBzdXBwb3J0ZWQgYWxnb3MsIGl0IGNvdWxk IGJlIGVhc2llciB0byBjbGFyaWZ5IHRoYXQgdGhlIE9DLU9MUiBBVlAgaXMgVEhFIHJlcG9ydCBB VlAgZm9yIHRoZSByZWR1Y3Rpb24gYWxnbyAoZGVmYXVsdCkgYW5kIGEgbmV3IGRlZGljYXRlZCBy ZXBvcnQgQVZQIG11c3QgYmUgY3JlYXRlZCB3aGVuIGEgbmV3IGFsZ28gaXMgaW50cm9kdWNlZC4g SW4gdGhpcyB3YXksIHRoZSBPQy1PTFIgaXMgc2VsZi1leHBsaWNpdC4NCg0KSXQgd291bGQgYmUg cHVyZWx5IG9wdGlvbmFsIHRvIHNlbmQgdGhlIFN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgYWxvbmcg d2l0aCB0aGUgT0MtT0xSIEFWUC4NCg0KTGlvbmVsIA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCkRlwqA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRv b2xzLmlldGYub3JnXSANCkVudm95w6nCoDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ4DQrD gMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCkNjwqA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6 IFtkaW1lXSAjMzA6IE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgaW4gYW5zd2VyIG1lc3NhZ2Vz DQoNCiMzMDogT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCBpbiBhbnN3ZXIgbWVzc2FnZXMNCg0K IEFjY29yZGluZyB0byB0aGUgY3VycmVudCBmZWF0dXJlIGFkdmVydGlzZW1lbnQvbmVnb3RpYXRp b24gbWVjaGFuaXNtIGluDQogdGhlIC0wMSBkcmFmdCByZXBvcnRpbmcgRE9JQyBlbmRwb2ludCBp bnNlcnQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUA0KIGluIGFuc3dlciBtZXNzYWdlcyB0 byBpbmRpY2F0ZSB0aGVpciBzdXBwb3J0ZWQgT0MgZmVhdHVyZXMgdG8gdGhlIHJlYWN0aW5nDQog RE9JQyBlbmRwb2ludC4NCiBUaGUgYXV0aG9yIG9mIHRoaXMgZG9jdW1lbnQgYmVsaWV2ZXMgdGhh dCAgdGhlIGJlc3QgYSByZWFjdGluZyBub2RlIGNhbiBkbw0KIHdpdGggc3VjaCBpbmZvcm1hdGlv biBpcyB0byBpZ25vcmUgaXQsIGFuZCB0aGVyZWZvcmUgcHJvcG9zZXMgdG8gYWxsb3cNCiByZXBv cnRpbmcgbm9kZXMgbm90IHRvIGluc2VydCBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQcyBpbiBh bnN3ZXINCiBtZXNzYWdlcy4NCiBDdXJyZW50bHkgb25seSBvbmUgZmVhdHVyZSBpcyBkZWZpbmVk IChPTFJfREVGQVVMVF9BTEdPKS4NCiBBIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgdGhhdCBzdXBw b3J0cyBvbmx5IE9MUl9ERUZBVUxUX0FMR08gYnV0IG5vIG90aGVyDQogZmVhdHVyZSBpcyBvbmx5 IGludGVyZXN0ZWQgaW4gcmVjZWl2aW5nL25vdCByZWNlaXZpbmcgT0MtT0xSIEFWUHMgZnJvbQ0K IHJlcG9ydGluZyBET0lDLWVuZHBvaW50cy4gUmVjZWl2aW5nIGFuIE9DLU9MUiBBVlAgaW1wbGlj aXRseSBpbmRpY2F0ZXMNCiBzdXBwb3J0IG9mIE9MUl9ERUZBVUxUX0FMR08gIGJ5IHRoZSByZXBv cnRpbmcgRE9JQyBlbmRwb2ludDsgbm90IHJlY2VpdmluZw0KIGFuIE9DLU9MUi1BVlAgZnJvbSB0 aGUgcmVwb3J0aW5nIERPSUMgZW5kcG9pbnQgbWF5IGhhdmUgdHdvIHJlYXNvbnM6DQoNCiBhKSBU aGVyZSBpcyBubyBvdmVybG9hZA0KIGIpIERPSUMgaXMgbm90IHN1cHBvcnRlZA0KDQogVGhlIHJl YWN0aW5nIERPSUMgZW5kcG9pbnQgZG9lcyBub3QgbmVlZCB0byBkaWZmZXJlbnRpYXRlIGJldHdl ZW4gdGhlc2UNCiB0d28gY2FzZXMgYXMgdGhlIGJlaGF2aW9yIChkbyBub3QgdGhyb3R0bGUpIGlz IHRoZSBzYW1lIGluIGJvdGggY2FzZXMuDQogVGhlIC0wMSBkcmFmdCBzYXlzIGluICBjbGF1c2Ug NC4xOg0KICAgIElmIHRoZXJlIGlzIG5vIHNpbmdsZSBtYXRjaGluZw0KICAgIGNhcGFiaWxpdHkg dGhlIHJlYWN0aW5nIG5vZGUgTVVTVCBhY3QgYXMgaWYgaXQgZG9lcyBub3QgaW1wbGVtZW50DQog ICAgRE9JQyBhbmQgY2Vhc2UgaW5zZXJ0aW5nIGFueSBET0lDIHJlbGF0ZWQgQVZQcyBpbnRvIGFu eSBEaWFtZXRlcg0KICAgIG1lc3NhZ2VzIHdpdGggdGhpcyBzcGVjaWZpYyByZWFjdGluZyBub2Rl Lg0KDQogVGhpcyBob3dldmVyIGlzIGluY29uc2lzdGVudC4NCiBUaGUgcmVhY3Rpbmcgbm9kZSB0 aGF0IGNlYXNlcyBzZW5kaW5nIERPSUMgcmVsYXRlZCBBVlBzIHdvdWxkIG5ldmVyDQogcmVjb2du aXplIHdoZW4gdGhlIHNlcnZlciBpcyB1cGdyYWRlZCB0byBzdXBwb3J0IERPSUMuDQogU3Vic2Vx dWVudCByZXF1ZXN0cyAobm90IGluY2x1ZGluZyBET0lDIHJlbGF0ZWQgQVZQcykgbWF5IHRha2Ug YSBkaWZmZXJlbnQNCiBwYXRoIHRvd2FyZHMgdGhlIHNlcnZlciBhbmQgb24gdGhhdCBwYXRoIHRo ZXJlIG1heSBiZSBhbiBhZ2VudCB0aGF0DQogc3VwcG9ydHMgRE9JQyAod2l0aCBhIG1hdGNoIG9m IHN1cHBvcnRlZCBmZWF0dXJlcykgYW5kIGNvdWxkIHRha2UgdGhlIHJvbGUNCiBvZiB0aGUgcmVw b3J0aW5nIERPSUMgZW5kcG9pbnQ7IGJ1dCB0aGUgYWdlbnQgY2Fubm90IHRha2UgdGhpcyByb2xl IHNpbmNlDQogdGhlIHJlYWN0aW5nIG5vZGUgKGFsdGhvdWdoIHN1cHBvcnRpbmcgRE9JQykgY2Vh c2VkIHNlbmRpbmcgb2YgT0MtDQogU3VwcG9ydGVkLUZlYXR1cmVzIEFWUHMuDQogSW4gc3VtbWFy eTogQXMgbG9uZyBhcyBubyBleHRlbnNpb24gZmVhdHVyZSBpcyBkZWZpbmVkIHdpdGhpbiAgZHJh ZnQtaWV0Zi0NCiBkaW1lLW92bGkgIChpLmUuIG5ldmVyLCBzaW5jZSBleHRlbnNpb25zIHdpbGwg IGJlIGRlZmluZWQgaW4gb3RoZXINCiBkcmFmdHMpLCB0aGVyZSBpcyBubyBuZWVkIGZvciBkcmFm dC1pZXRmLWRpbWUtb3ZsaSAgdG8gbWFuZGF0ZSBvciBldmVuDQogZGVzY3JpYmUgaW5jbHVzaW9u IG9mIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgaW4gYW5zd2VyIG1lc3NhZ2VzLg0KDQotLSAN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20gIHwgICAgICBP d25lcjogIFVscmljaCBXaWVoZQ0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAg ICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAg ICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgZHJhZnQtZG9jZHQtZGltZS1vdmxpICAgICB8 ICAgIFZlcnNpb246DQogU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAgICAgIHwgICBL ZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy93Zy9kaW1lL3RyYWMvdGlja2V0LzMwPg0KZGltZSA8aHR0cDovL3Rvb2xzLmlldGYub3Jn L3dnL2RpbWUvPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlz dA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aW1lDQo= From lionel.morand@orange.com Tue Feb 4 08:51:11 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FAE1A0120 for ; Tue, 4 Feb 2014 08:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENxTH37ovS9p for ; Tue, 4 Feb 2014 08:51:09 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 56F611A00F9 for ; Tue, 4 Feb 2014 08:51:08 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3866022C513; Tue, 4 Feb 2014 17:51:07 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1D41B35C048; Tue, 4 Feb 2014 17:51:07 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 17:51:06 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPIbnza0SZ1wdbvEGvoj4P8RAtnpqlM3SggAARYlA= Date: Tue, 4 Feb 2014 16:51:06 +0000 Message-ID: <7610_1391532667_52F11A7B_7610_3074_1_6B7134B31289DC4FAF731D844122B36E4774C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.4.140016 Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 16:51:11 -0000 SGkgVWxyaWNoLA0KDQpGb3IgdGhlIHBvaW50IDIgYW5kIDMsIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gdGhlICJTaG91bGQiIGFuZCB0aGUgIk1heSIgaXMgcXVpdGUgc3VidGxlIGhlcmUgYW5kIGlz IGZvciBtZSBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi4NCg0KRm9yIDQgYW5kIDUsIG9r IGlmIHRoZSBub2RlIG9ubHkgc3VwcG9ydHMgdGhlIGRlZmF1bHQgYWxnby4gSW4gb3RoZXIgd29y ZHMsIG9ubHkgdGhlIE9MUiBtYXR0ZXJzIGZvciBub2RlcyBzdXBwb3J0aW5nIG9ubHkgdGhlIGRl ZmF1bHQgYWxnby4gVGhlIHJlc3QgaXMgcHVyZWx5IGZvciBpbmZvcm1hdGlvbiBhbmQgY2FuIGJl IHNhZmVseSBpZ25vcmVkLg0KDQpGb3IgNiwgaWYgdGhlIG5ldyBmZWF0dXJlIGNvbnNpc3RzIGlu IGEgbmV3IGFsZ28sIGl0IHdvdWxkIG1lYW4gZGVmaW5pbmcgYSBuZXcgZGVkaWNhdGVkIE9MUiBB VlAuIFNvIG5vZGVzIHN1cHBvcnRpbmcgb25seSB0aGUgZGVmYXVsdCBhbGdvIHdpbGwgaWdub3Jl IGFueSB1bmtub3duIEFWUCBpZiByZWNlaXZlZC4NCg0KUmVnYXJkcywNCg0KTGlvbmVsDQoNCi0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogV2llaGUsIFVscmljaCAoTlNOIC0gREUv TXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXSANCkVudm95w6nCoDogbWFyZGkg NCBmw6l2cmllciAyMDE0IDE3OjA0DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE47IGRpbWVA aWV0Zi5vcmcNCk9iamV0wqA6IFJFOiBbZGltZV0gIzMwOiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMg QVZQIGluIGFuc3dlciBtZXNzYWdlcw0KDQpEZWFyIExpb25lbCwNCg0KdGhhbmsgeW91IGZvciB5 b3VyIHJlc3BvbnNlLg0KDQpJZiBJIGNvcnJlY3RseSB1bmRlcnN0YW5kLCB0aGUgcHJpbmNpcGxl cyB3b3VsZCBiZToNCjEuIFNlbmRpbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIGluIGFuc3dlciBt ZXNzYWdlcyBpcyBzeW50YWN0aWNhbGx5IG9wdGlvbmFsLg0KMi4gV2hlbiB0aGUgcmVhY3Rpbmcg bm9kZSBkb2VzIG9ubHkgc3VwcG9ydCBPTFJfREVGQVVMVF9BTEdPICwgdGhlIHJlcG9ydGluZyBu b2RlIHNob3VsZCBub3QgaW5zZXJ0IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgaW4gdGhl IGFuc3dlciBtZXNzYWdlLg0KMy4gV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBvbmx5IHN1 cHBvcnQgT0xSX0RFRkFVTFRfQUxHTywgaXQgc2hvdWxkIG5vdCBpbnNlcnQgYW4gT0MtU3VwcG9y dGVkLUZlYXR1cmVzIEFWUCBpbiB0aGUgYW5zd2VyIG1lc3NhZ2UuDQo0LiBBIHJlYWN0aW5nIG5v ZGUgdGhhdCBzdXBwb3J0cyBvbmx5IE9MUl9ERUZBVUxUX0FMR08gY2FuIHNhZmVseSBpZ25vcmUg T0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUHMgcmVjZWl2ZWQgaW4gYW5zd2VyIG1lc3NhZ2VzLg0K NS4gQSByZWFjdGluZyBub2RlIHRoYXQgc3VwcG9ydHMgb25seSBPTFJfREVGQVVMVF9BTEdPIGNh biBzYWZlbHkgaWdub3IgYWxsIGV4dGVuc2lvbnMgcmVjZWl2ZWQgaW4gYW4gT0MtT0xSLg0KNi4g V2hlbiBhIG5ldyBmZWF0dXJlIGlzIGludHJvZHVjZWQsIHRoZSBzcGVjIGludHJvZHVjaW5nIHRo ZSBuZXcgZmVhdHVyZSBtdXN0IGRlZmluZSB0aGUgZGV0YWlscyB0byBlbnN1cmUgaW50ZXJvcGVy YWJpbGl0eSBvZiBub2RlcyBzdXBwb3J0aW5nIHRoZSBuZXcgZmVhdHVyZSB3aXRoIG5vZGVzIHRo YXQgZG8gbm90IHN1cHBvcnQgdGhlIG5ldyBmZWF0dXJlICh0YWtpbmcgaW50byBhY2NvdW50IHRo YXQgbm9kZXMgbm90IHN1cHBvcnRpbmcgdGhlIG5ldyBmZWF0dXJlIGFjdCBhY2NvcmRpbmcgdG8g dGhlIHByaW5jaXBsZXMgMS4tNS4pLg0KDQoNCkJlc3QgcmVnYXJkcw0KVWxyaWNoDQogIA0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0K U2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgNDowMSBQTQ0KVG86IGRpbWVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMDogT0MtU3VwcG9ydGVkLUZlYXR1cmVz IEFWUCBpbiBhbnN3ZXIgbWVzc2FnZXMNCg0KSSB0aGluayB0aGF0IHRoZXJlIGlzIGFjdHVhbGx5 IGFuIGlzc3VlIGhlcmUgYnV0IHRoZSBwcm9wb3NlZCB3YXkgdG8gc29sdmUgaXQgaXMgbm90IHRo ZSBjb3JyZWN0IG9uZS4NClRoZSBpbml0aWFsIGlkZWEgd2FzIHRvIGJlIGFibGUgdG8gdXNlIHRo ZSBzYW1lIG92ZXJsb2FkIHJlcG9ydCB3aXRoIHNldmVyYWwgYWxnb3JpdGhtcy4gU28gdGhlIE9M UiB3YXMgc29tZWhvdyBvbmx5IG1lYW5pbmdmdWwgYWxvbmcgd2l0aCB0aGUgT0MtRmVhdHVyZS1W ZWN0b3IgQVZQLg0KDQpCdXQgYmVjYXVzZSB0aGUgT0MtRmVhdHVyZS1WZWN0b3IgQVZQIGlzIGRl ZmluZWQgYXMgYSBzZXQgb2YgZmxhZ3MsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBzYXkgdGhhdCB0 aGlzIE9MUiBpcyB0byBiZSB1c2VkIHdpdGggb25seSBvbmUgZ2l2ZW4gYWxnbyB3aGVuIG1vcmUg dGhhbiBvbmUgaXMgZGVmaW5lZCAoYXMgdGhlIGJpdCBmbGFncyB3aWxsIGFkdmVydGl6ZSAxIEFO RCAyIGZvciAyIHN1cHBvcnRlZCBhbGdvcykuIFNvIHRoZSBPQy1GZWF0dXJlLVZlY3RvciBjYW5u b3QgYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUgYWJhdGVtZW50IHRvIHBlcmZvcm0uDQoNCkFzIHRo ZSBzeW50YXggb2YgdGhlIE9DLUZlYXR1cmUtVmVjdG9yIGlzIGFkYXB0ZWQgdG8gYWR2ZXJ0aXpl IHN1cHBvcnRlZCBhbGdvcywgaXQgY291bGQgYmUgZWFzaWVyIHRvIGNsYXJpZnkgdGhhdCB0aGUg T0MtT0xSIEFWUCBpcyBUSEUgcmVwb3J0IEFWUCBmb3IgdGhlIHJlZHVjdGlvbiBhbGdvIChkZWZh dWx0KSBhbmQgYSBuZXcgZGVkaWNhdGVkIHJlcG9ydCBBVlAgbXVzdCBiZSBjcmVhdGVkIHdoZW4g YSBuZXcgYWxnbyBpcyBpbnRyb2R1Y2VkLiBJbiB0aGlzIHdheSwgdGhlIE9DLU9MUiBpcyBzZWxm LWV4cGxpY2l0Lg0KDQpJdCB3b3VsZCBiZSBwdXJlbHkgb3B0aW9uYWwgdG8gc2VuZCB0aGUgU3Vw cG9ydGVkLUZlYXR1cmVzIEFWUCBhbG9uZyB3aXRoIHRoZSBPQy1PTFIgQVZQLg0KDQpMaW9uZWwg DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2Vy IFttYWlsdG86dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBtYXJk aSA0IGbDqXZyaWVyIDIwMTQgMDk6NDgNCsOAwqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PC oDogZGltZUBpZXRmLm9yZw0KT2JqZXTCoDogW2RpbWVdICMzMDogT0MtU3VwcG9ydGVkLUZlYXR1 cmVzIEFWUCBpbiBhbnN3ZXIgbWVzc2FnZXMNCg0KIzMwOiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMg QVZQIGluIGFuc3dlciBtZXNzYWdlcw0KDQogQWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IGZlYXR1 cmUgYWR2ZXJ0aXNlbWVudC9uZWdvdGlhdGlvbiBtZWNoYW5pc20gaW4NCiB0aGUgLTAxIGRyYWZ0 IHJlcG9ydGluZyBET0lDIGVuZHBvaW50IGluc2VydCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMg QVZQDQogaW4gYW5zd2VyIG1lc3NhZ2VzIHRvIGluZGljYXRlIHRoZWlyIHN1cHBvcnRlZCBPQyBm ZWF0dXJlcyB0byB0aGUgcmVhY3RpbmcNCiBET0lDIGVuZHBvaW50Lg0KIFRoZSBhdXRob3Igb2Yg dGhpcyBkb2N1bWVudCBiZWxpZXZlcyB0aGF0ICB0aGUgYmVzdCBhIHJlYWN0aW5nIG5vZGUgY2Fu IGRvDQogd2l0aCBzdWNoIGluZm9ybWF0aW9uIGlzIHRvIGlnbm9yZSBpdCwgYW5kIHRoZXJlZm9y ZSBwcm9wb3NlcyB0byBhbGxvdw0KIHJlcG9ydGluZyBub2RlcyBub3QgdG8gaW5zZXJ0IE9DLVN1 cHBvcnRlZC1GZWF0dXJlcyBBVlBzIGluIGFuc3dlcg0KIG1lc3NhZ2VzLg0KIEN1cnJlbnRseSBv bmx5IG9uZSBmZWF0dXJlIGlzIGRlZmluZWQgKE9MUl9ERUZBVUxUX0FMR08pLg0KIEEgcmVhY3Rp bmcgRE9JQyBlbmRwb2ludCB0aGF0IHN1cHBvcnRzIG9ubHkgT0xSX0RFRkFVTFRfQUxHTyBidXQg bm8gb3RoZXINCiBmZWF0dXJlIGlzIG9ubHkgaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcvbm90IHJl Y2VpdmluZyBPQy1PTFIgQVZQcyBmcm9tDQogcmVwb3J0aW5nIERPSUMtZW5kcG9pbnRzLiBSZWNl aXZpbmcgYW4gT0MtT0xSIEFWUCBpbXBsaWNpdGx5IGluZGljYXRlcw0KIHN1cHBvcnQgb2YgT0xS X0RFRkFVTFRfQUxHTyAgYnkgdGhlIHJlcG9ydGluZyBET0lDIGVuZHBvaW50OyBub3QgcmVjZWl2 aW5nDQogYW4gT0MtT0xSLUFWUCBmcm9tIHRoZSByZXBvcnRpbmcgRE9JQyBlbmRwb2ludCBtYXkg aGF2ZSB0d28gcmVhc29uczoNCg0KIGEpIFRoZXJlIGlzIG5vIG92ZXJsb2FkDQogYikgRE9JQyBp cyBub3Qgc3VwcG9ydGVkDQoNCiBUaGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBkb2VzIG5vdCBu ZWVkIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGVzZQ0KIHR3byBjYXNlcyBhcyB0aGUgYmVo YXZpb3IgKGRvIG5vdCB0aHJvdHRsZSkgaXMgdGhlIHNhbWUgaW4gYm90aCBjYXNlcy4NCiBUaGUg LTAxIGRyYWZ0IHNheXMgaW4gIGNsYXVzZSA0LjE6DQogICAgSWYgdGhlcmUgaXMgbm8gc2luZ2xl IG1hdGNoaW5nDQogICAgY2FwYWJpbGl0eSB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIGFjdCBhcyBp ZiBpdCBkb2VzIG5vdCBpbXBsZW1lbnQNCiAgICBET0lDIGFuZCBjZWFzZSBpbnNlcnRpbmcgYW55 IERPSUMgcmVsYXRlZCBBVlBzIGludG8gYW55IERpYW1ldGVyDQogICAgbWVzc2FnZXMgd2l0aCB0 aGlzIHNwZWNpZmljIHJlYWN0aW5nIG5vZGUuDQoNCiBUaGlzIGhvd2V2ZXIgaXMgaW5jb25zaXN0 ZW50Lg0KIFRoZSByZWFjdGluZyBub2RlIHRoYXQgY2Vhc2VzIHNlbmRpbmcgRE9JQyByZWxhdGVk IEFWUHMgd291bGQgbmV2ZXINCiByZWNvZ25pemUgd2hlbiB0aGUgc2VydmVyIGlzIHVwZ3JhZGVk IHRvIHN1cHBvcnQgRE9JQy4NCiBTdWJzZXF1ZW50IHJlcXVlc3RzIChub3QgaW5jbHVkaW5nIERP SUMgcmVsYXRlZCBBVlBzKSBtYXkgdGFrZSBhIGRpZmZlcmVudA0KIHBhdGggdG93YXJkcyB0aGUg c2VydmVyIGFuZCBvbiB0aGF0IHBhdGggdGhlcmUgbWF5IGJlIGFuIGFnZW50IHRoYXQNCiBzdXBw b3J0cyBET0lDICh3aXRoIGEgbWF0Y2ggb2Ygc3VwcG9ydGVkIGZlYXR1cmVzKSBhbmQgY291bGQg dGFrZSB0aGUgcm9sZQ0KIG9mIHRoZSByZXBvcnRpbmcgRE9JQyBlbmRwb2ludDsgYnV0IHRoZSBh Z2VudCBjYW5ub3QgdGFrZSB0aGlzIHJvbGUgc2luY2UNCiB0aGUgcmVhY3Rpbmcgbm9kZSAoYWx0 aG91Z2ggc3VwcG9ydGluZyBET0lDKSBjZWFzZWQgc2VuZGluZyBvZiBPQy0NCiBTdXBwb3J0ZWQt RmVhdHVyZXMgQVZQcy4NCiBJbiBzdW1tYXJ5OiBBcyBsb25nIGFzIG5vIGV4dGVuc2lvbiBmZWF0 dXJlIGlzIGRlZmluZWQgd2l0aGluICBkcmFmdC1pZXRmLQ0KIGRpbWUtb3ZsaSAgKGkuZS4gbmV2 ZXIsIHNpbmNlIGV4dGVuc2lvbnMgd2lsbCAgYmUgZGVmaW5lZCBpbiBvdGhlcg0KIGRyYWZ0cyks IHRoZXJlIGlzIG5vIG5lZWQgZm9yIGRyYWZ0LWlldGYtZGltZS1vdmxpICB0byBtYW5kYXRlIG9y IGV2ZW4NCiBkZXNjcmliZSBpbmNsdXNpb24gb2YgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCBp biBhbnN3ZXIgbWVzc2FnZXMuDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGxpb25lbC5t b3JhbmRAb3JhbmdlLmNvbSAgfCAgICAgIE93bmVyOiAgVWxyaWNoIFdpZWhlDQogICAgIFR5cGU6 ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5 OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBk cmFmdC1kb2NkdC1kaW1lLW92bGkgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIEFjdGl2 ZSBXRyBEb2N1bWVudCAgICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVS TDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2RpbWUvdHJhYy90aWNrZXQvMzA+DQpk aW1lIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvZGltZS8+DQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From lionel.morand@orange.com Tue Feb 4 09:12:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D49F1A0035 for ; Tue, 4 Feb 2014 09:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbsU9p5ht8il for ; Tue, 4 Feb 2014 09:12:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A8CA01A0032 for ; Tue, 4 Feb 2014 09:12:35 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 12C623B41CB for ; Tue, 4 Feb 2014 18:12:35 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id F023227C053 for ; Tue, 4 Feb 2014 18:12:34 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 18:12:34 +0100 From: To: "dime@ietf.org" Thread-Topic: [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIYa/7jhHInzGCEuvJx0M5tUJhZqlVD/g Date: Tue, 4 Feb 2014 17:12:33 +0000 Message-ID: <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> In-Reply-To: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 17:12:38 -0000 VGhlIGNhc2UgIlJlYWxtIiBhcyBkZXNjcmliZWQgYmVsb3cgcmFpc2VzIGFub3RoZXIgcXVlc3Rp b246IGlzIGl0IHByb2hpYml0ZWQgZm9yIGEgcmVhbG0gdG8gb25seSByZWx5IG9uIGEgZ2xvYmFs IG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIHdob2xlIHJlYWxtLCB3aGF0ZXZlciB0aGUgbm9kZXMg aW5zaWRlIHRoaXMgcmVhbG0/DQpJZiBub3QsIG9ubHkgT0xSIHdpdGggdGhlIHJlcG9ydCB0eXBl ICJyZWFsbSIgd291bGQgYmUgcmVjZWl2ZWQgYnkgdGhlIHJlYWN0aW5nIG5vZGUuIEFuZCB0aGUg cmVkdWN0aW9uIGluZGljYXRlZCBpbiB0aGUgT0xSIHdpbGwgYXBwbHkgYWx3YXlzIGZvciB0aGUg cmVhbG0sIHdoYXRldmVyIHRoZSBwcmVzZW5jZSBvZiBEZXN0aW5hdGlvbi1ob3N0IEFWUCBpbiB0 aGUgcmVxdWVzdC4uLiBleGNlcHQgaWYgYW4gZXhwbGljaXQgcmVwb3J0IHdpdGggdGhlIHR5cGUg Ikhvc3QiIGFzIGJlZW4gcmVjZWl2ZWQgZm9yIHRoaXMgZGVzdGluYXRpb24taG9zdC4NCg0KRG9l cyBpdCBtYWtlIHNlbnNlPw0KDQpMaW9uZWwNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQpEZcKgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5p ZXRmLm9yZ10gDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo1NQ0Kw4DCoDog TU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1lQGlldGYub3JnDQpPYmpldMKgOiBbZGlt ZV0gIzM0OiBTZW1hbnRpY3Mgb2YgT0MtUmVwb3J0LVR5cGUgQVZQDQoNCiMzNDogU2VtYW50aWNz IG9mIE9DLVJlcG9ydC1UeXBlIEFWUA0KDQogVGV4dCBpbiBjbGF1c2UgNC42ICBkb2VzIG5vdCBm dWxseSBleHBsYWluIHRvIHdoaWNoIHJlcXVlc3RzIG92ZXJsb2FkDQogdHJlYXRtZW50IG9mIGEg Z2l2ZW4gcmVwb3J0IHR5cGUgYXBwbGllcy4NCiBQcm9wb3NhbDoNCg0KICAgIDAgIEEgaG9zdCBy ZXBvcnQuICBUaGUgb3ZlcmxvYWQgdHJlYXRtZW50IHNob3VsZCBhcHBseSB0byByZXF1ZXN0cw0K ICAgICAgIGZvciB3aGljaCBhbGwgb2YgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFyZSB0cnVl Og0KICAgICAgIGEpIFRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBpcyBwcmVzZW50IGluIHRoZSBy ZXF1ZXN0IGFuZCBpdHMgdmFsdWUNCiAgICAgICAgICBtYXRjaGVzIHRoZSB2YWx1ZSBvZiB0aGUg T3JpZ2luLUhvc3QgQVZQIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlDQogICAgICAgICAgdGhhdCBj b250YWluZWQgdGhlIE9DLU9MUiBBVlAuDQogICAgICAgYikgVGhlIHZhbHVlIG9mIHRoZSBEZXN0 aW5hdGlvbi1SZWFsbSBBVlAgaW4gdGhlIHJlcXVlc3QgbWF0Y2hlcyB0aGUNCiAgICAgICAgICB2 YWx1ZSBvZiB0aGUgT3JpZ2luLVJlYWxtIEFWUCBvZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZQ0KICAg ICAgICAgIHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KICAgICAgIGMpIFRoZSB2YWx1 ZSBvZiB0aGUgQXBwbGljYXRpb24tSUQgaW4gdGhlIERpYW1ldGVyIEhlYWRlciBvZiB0aGUNCiAg ICAgICAgICByZXF1ZXN0IG1hdGNoZXMgdGhlIHZhbHVlIG9mIHRoZSBBcHBsaWNhdGlvbi1JRCBv ZiB0aGUgRGlhbWV0ZXINCiAgICAgICAgICBIZWFkZXIgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2Ug dGhhdCBjb250YWluZWQgdGhlIE9DLU9MUiBBVlAuDQoNCg0KDQogICAgMSAgQSByZWFsbSByZXBv cnQuICBUaGUgb3ZlcmxvYWQgdHJlYXRtZW50IHNob3VsZCBhcHBseSB0bw0KICAgICAgIHJlcXVl c3RzIGZvciB3aGljaCBhbGwgb2YgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFyZSB0cnVlOg0K ICAgICAgIGEpIFRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBpcyBhYnNlbnQgaW4gdGhlIHJlcXVl c3QuDQogICAgICAgYikgVGhlIHZhbHVlIG9mIHRoZSBEZXN0aW5hdGlvbi1SZWFsbSBBVlAgaW4g dGhlIHJlcXVlc3QgbWF0Y2hlcyB0aGUNCiAgICAgICAgICB2YWx1ZSBvZiB0aGUgT3JpZ2luLVJl YWxtIEFWUCBvZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZQ0KICAgICAgICAgIHRoYXQgY29udGFpbmVk IHRoZSBPQy1PTFIgQVZQLg0KICAgICAgIGMpIFRoZSB2YWx1ZSBvZiB0aGUgQXBwbGljYXRpb24t SUQgaW4gdGhlIERpYW1ldGVyIEhlYWRlciBvZiB0aGUNCiAgICAgICAgICByZXF1ZXN0IG1hdGNo ZXMgdGhlIHZhbHVlIG9mIHRoZSBBcHBsaWNhdGlvbi1JRCBvZiB0aGUgRGlhbWV0ZXINCiAgICAg ICAgICBIZWFkZXIgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgdGhhdCBjb250YWluZWQgdGhlIE9D LU9MUiBBVlAuDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGxpb25lbC5tb3JhbmRAb3Jh bmdlLmNvbSAgfCAgICAgIE93bmVyOiAgVWxyaWNoIFdpZWhlDQogICAgIFR5cGU6ICBkZWZlY3Qg ICAgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3Ig ICAgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBkcmFmdC1kb2Nk dC1kaW1lLW92bGkgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1 bWVudCAgICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2RpbWUvdHJhYy90aWNrZXQvMzQ+DQpkaW1lIDxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvd2cvZGltZS8+DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From lionel.morand@orange.com Tue Feb 4 09:18:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2D71A00EC for ; Tue, 4 Feb 2014 09:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoSsoIw5gaIZ for ; Tue, 4 Feb 2014 09:18:26 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id D170D1A0032 for ; Tue, 4 Feb 2014 09:18:25 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id E2DC4190271 for ; Tue, 4 Feb 2014 18:18:24 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id C8D7E180068 for ; Tue, 4 Feb 2014 18:18:24 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 18:18:24 +0100 From: To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb9MiABLhdXq2UOcuMVjS/8sh5qlVdmQ Date: Tue, 4 Feb 2014 17:18:24 +0000 Message-ID: <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> In-Reply-To: <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.4.90915 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 17:18:28 -0000 I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33) two > additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DOIC endpoints to request different amount of load reduction from different clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this requirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the request match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the request match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Tue Feb 4 10:20:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4851A0155 for ; Tue, 4 Feb 2014 10:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOKf-o4kVI0q for ; Tue, 4 Feb 2014 10:20:01 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E68001A0035 for ; Tue, 4 Feb 2014 10:20:00 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 02D2C3B4358 for ; Tue, 4 Feb 2014 19:20:00 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DF0394C066 for ; Tue, 4 Feb 2014 19:19:59 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 19:19:59 +0100 From: To: "dime@ietf.org" Thread-Topic: [dime] #32: Sequence-Number Time-Stamp values within OC-OLR Thread-Index: AQHPIYYKB91oIzfs90+UMw0PXfYt15qlYXHQ Date: Tue, 4 Feb 2014 18:19:58 +0000 Message-ID: <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> In-Reply-To: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.4.140016 Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 18:20:04 -0000 VGhlIGV4aXN0aW5nIHdvcmRpbmcgc2VlbXMgYWN0dWFsbHkgZnV6enkuDQpJZiBpdCBpcyAibGlr ZSBhbiBOVFAgdGltZXN0YW1wIiwgYmUgcHJvdWQgYW5kIHNheSBpdCBsb3VkIQ0KDQpJbiBzdW1t YXJ5OiBvayB3aXRoIHRoZSBwcm9wb3NhbCBpZiBpdCBjbGFyaWZpZXMgdGhpcyBoYW5kbGluZyBv ZiB0aGlzIHNlcXVlbmNlLW51bWJlci4NCg0KTGlvbmVsDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1lQHRyYWMu dG9vbHMuaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NTAN CsOAwqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PCoDogZGltZUBpZXRmLm9yZw0KT2JqZXTC oDogW2RpbWVdICMzMjogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhpbiBP Qy1PTFINCg0KIzMyOiBTZXF1ZW5jZS1OdW1iZXIgVGltZS1TdGFtcCB2YWx1ZXMgd2l0aGluIE9D LU9MUg0KDQogVGhlIC0wMSBkcmFmdCBzYXlzIGluIGNsYXVzZSA0LjQ6DQogICAgRnJvbSB0aGUg ZnVuY3Rpb25hbGl0eSBwb2ludCBvZiB2aWV3LCB0aGUgT0MtU2VxdWVuY2UtTnVtYmVyIEFWUCBN VVNUDQogICAgYmUgdXNlZCBhcyBhIG5vbi12b2xhdGlsZSBpbmNyZWFzaW5nIGNvdW50ZXIgYmV0 d2VlbiB0d28gb3ZlcmxvYWQNCiAgICBjb250cm9sIGVuZHBvaW50cyAobmVnbGVjdGluZyB0aGUg ZmFjdCB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUgQVZQDQogICAgaXMgYSA2NC1iaXQgTlRQIHRp bWVzdGFtcCBbUkZDNTkwNV0pLiAgVGhlIHNlcXVlbmNlIG51bWJlciBpcyBvbmx5DQogICAgcmVx dWlyZWQgdG8gYmUgdW5pcXVlIGJldHdlZW4gdHdvIG92ZXJsb2FkIGNvbnRyb2wgZW5kcG9pbnRz Lg0KICAgIFNlcXVlbmNlIG51bWJlcnMgYXJlIHRyZWF0ZWQgaW4gdW5pLWRpcmVjdGlvbmFsIG1h bm5lciwgaS5lLiB0d28NCiAgICBzZXF1ZW5jZSBudW1iZXJzIG9uIGVhY2ggZGlyZWN0aW9uIGJl dHdlZW4gdHdvIGVuZHBvaW50cyBhcmUgbm90DQogICAgcmVsYXRlZCBvciBjb3JyZWxhdGVkLg0K DQogICAgV2hlbiBnZW5lcmF0aW5nIHNlcXVlbmNlIG51bWJlcnMsIHRoZSBuZXcgc2VxdWVuY2Ug bnVtYmVyIE1VU1QgYmUNCiAgICBncmVhdGVyIHRoYW4gYW55IHNlcXVlbmNlIG51bWJlciBwcmV2 aW91c2x5IHNlZW4gYmV0d2VlbiB0d28NCiAgICBlbmRwb2ludHMgd2l0aGluIGEgdGltZSB3aW5k b3cgdGhhdCB0b2xlcmF0ZXMgdGhlIHdyYXBhcm91bmQgb2YgdGhlDQogICAgTlRQIHRpbWVzdGFt cCAoaS5lLiBhcHByb3hpbWF0ZWx5IDY4IHllYXJzKS4NCg0KDQogV2l0aCB0aGlzIG1lY2hhbmlz bSBpdCBpcyBkaWZmaWN1bHQgdG8gZ2V0IGJhY2sgdG8gc3luYyBvbmNlIHlvdSBhcmUgb3V0DQog b2Ygc3luYyAoZm9yIHdoYXRldmVyIHJlYXNvbikuDQogSXQgaXMgcHJvcG9zZWQgdG8gbWFuZGF0 ZSB0aGF0IHRoZSBTZXF1ZW5jZSBOdW1iZXIgaXMgYSByZWFsIDY0LWJpdCBOVFANCiB0aW1lc3Rh bXAgKFJGQzU5MDUpIGluZGljYXRpbmcgdGhlIHBvaW50IGluIHRpbWUgd2hlbiB0aGUgT0xSIHdh cyBjcmVhdGVkLA0KIGFuZCB0byBtYW5kYXRlIHRoYXQgIE9MUnMgd2l0aCBhIHRpbWUgc3RhbXAg aGlnaGVyIHRoYW4gdGltZSBvZiByZWNlcHRpb24NCiBtdXN0IGJlIGlnbm9yZWQgYnkgdGhlIHJl YWN0aW5nIG5vZGUuDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbSAgfCAgICAgIE93bmVyOiAgVWxyaWNoIFdpZWhlDQogICAgIFR5cGU6ICBkZWZl Y3QgICAgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFq b3IgICAgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBkcmFmdC1k b2NkdC1kaW1lLW92bGkgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBE b2N1bWVudCAgICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2RpbWUvdHJhYy90aWNrZXQvMzI+DQpkaW1lIDxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvZGltZS8+DQoNCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nsalot@cisco.com Tue Feb 4 20:27:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF471A0026 for ; Tue, 4 Feb 2014 20:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qej7MJRHPm9D for ; Tue, 4 Feb 2014 20:27:05 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC81A0021 for ; Tue, 4 Feb 2014 20:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5490; q=dns/txt; s=iport; t=1391574425; x=1392784025; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=u3FjysCeUxTWeMG/Hmn5Ax9Trxt5X2eoBAhsCjehtMo=; b=m8ORMtLxzKP05Zzi6rBeodyw+IK4oxz3/Tt3/Mn8lB7ZGDkjDetvhHqr kNe0CcWpzs2SoQm+41zKTQdONFQ77038MRnf0NwcDI1dpYyYo1eYuSH38 Oix0p3J4j/A+wyjDcrbXxsjRtHKZjknKPt8pXkJMu4lyvTCurLsatoPaB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJ688VKtJV2a/2dsb2JhbABZgww4V4MBu0sYchZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGGQQDAgICJQsUAQgIAgQBEgiHfQ2tAaEwF4EpjGoRAQsUOAaCaTWBFASUQoUbiSuHRIFvgT6BcTk X-IronPort-AV: E=Sophos;i="4.95,784,1384300800"; d="scan'208";a="301919542" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 05 Feb 2014 04:27:04 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s154R4KM009099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 04:27:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 22:27:04 -0600 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQ Date: Wed, 5 Feb 2014 04:27:04 +0000 Message-ID: References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 04:27:08 -0000 SSBzaGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExpb25lbC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0KU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90 dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0 bGluZw0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJl cG9ydGluZyBub2RlIERPRVMgTk9UIGluc2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4gDQpT byB0aGUgb3B0aW9ucyB3b3VsZCBiZToNCjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyDQoy LSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgcmVxdWVzdCArIE9DLU9M UiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1l ZCBieSB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQoNCklmIHRoZXJlIGlzIG5vIG90 aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KDQpM aW9uZWwNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBkaW1lIGlzc3VlIHRy YWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCkVudm95w6nCoDog bWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4N CkNjwqA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl ZCBhIHRocm90dGxpbmcNCg0KIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCiBJ dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu Zm8gQVZQIHRoYXQgaXMgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBv aW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlz IEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQogKFRpbWVTdGFtcCkgb2Yg dGhlIE9MUiBhY2NvcmRpbmcgdG8gd2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdhcw0KIHN1 cnZpdmVkKSBpcyBwZXJmb3JtZWQuIEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5kaWNhdGVzIHRoYXQg Y3VycmVudGx5IG5vICB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4gIFJlcG9ydGluZyBET0lDIGVu ZHBvaW50cyBtYXkgdXNlIHRoaXMgIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0 aGVyIHRoZXJlIGlzIGEgbmVlZCB0byB1cGRhdGUgdGhlICByZWFjdGluZyBET0lDIGVuZHBvaW50 IHdpdGggdGhlIGxhdGVzdCBPTFIuDQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlz bSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVwb3J0aW5nIG5vZGUgdG8gc2Vu ZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDICBlbmRw b2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFj dHVhbGx5IGRvaW5nICB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9u b3QgdGhyb3R0bGluZy4NCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVzIHJvYnVzdG5l c3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyAgZW5kcG9pbnQgdG8gZGV0ZWN0IGFu ZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmcgIERPSUMg ZW5kcG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24pLg0KIFRoZSBmZWVkYmFjayBtZWNo YW5pc20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBSRkMgNzA2OC4NCiBJbiBz dW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5n LUluZm8gQVZQIHRvICBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh IHRocm90dGxpbmcuDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbSAgfCAgICAgIE93bmVyOiAgVWxyaWNoIFdpZWhlDQogICAgIFR5cGU6ICBkZWZl Y3QgICAgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFq b3IgICAgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBkcmFmdC1k b2NkdC1kaW1lLW92bGkgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBE b2N1bWVudCAgICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2RpbWUvdHJhYy90aWNrZXQvMzE+DQpkaW1lIDxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvZGltZS8+DQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIg YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsg eW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZQ0K From nsalot@cisco.com Tue Feb 4 20:27:32 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2401A0025 for ; Tue, 4 Feb 2014 20:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mOcdwDd5wH0 for ; Tue, 4 Feb 2014 20:27:30 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 087F61A0021 for ; Tue, 4 Feb 2014 20:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5026; q=dns/txt; s=iport; t=1391574449; x=1392784049; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hXOio5MH6/CwqG4mlu1juw/+U2Hv7Nyl9jCKkf3D7Ok=; b=U1OywvJNujIDkvKAghcVWCYcuCopS3p7Od/ig6Nn8DwoBxOoRC6xre7V i1Br3HbWTiYFN7ZxHYh7FrLJXZhWO9McKy21jEKzBb+ZXs7MyiKG9RQvV EdmUyXIYt8ITlBH5DyQ32Fxx3RJkovMlpJqif42K4i1vuX7dofTadWVCN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADC98VKtJXG//2dsb2JhbABZgww4V4MBu0sYchZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGHQMCAgIlCxQBCAgCBAESCId9Da0BoTAXgSmMahEBCxQWIgaCaTWBFASZXZBvgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,784,1384300800"; d="scan'208";a="18009201" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 05 Feb 2014 04:27:29 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s154RTKO032552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 04:27:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 22:27:28 -0600 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR Thread-Index: AQHPIdXBnHw4MicpWki54VifY9Wd6ZqmEWNA Date: Wed, 5 Feb 2014 04:27:27 +0000 Message-ID: References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 04:27:32 -0000 SSBhbHNvIGFncmVlLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAw NCwgMjAxNCAxMTo1MCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0g W2RpbWVdICMzMjogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhpbiBPQy1P TFINCg0KVGhlIGV4aXN0aW5nIHdvcmRpbmcgc2VlbXMgYWN0dWFsbHkgZnV6enkuDQpJZiBpdCBp cyAibGlrZSBhbiBOVFAgdGltZXN0YW1wIiwgYmUgcHJvdWQgYW5kIHNheSBpdCBsb3VkIQ0KDQpJ biBzdW1tYXJ5OiBvayB3aXRoIHRoZSBwcm9wb3NhbCBpZiBpdCBjbGFyaWZpZXMgdGhpcyBoYW5k bGluZyBvZiB0aGlzIHNlcXVlbmNlLW51bWJlci4NCg0KTGlvbmVsDQoNCi0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1l QHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAw OTo1MA0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1lQGlldGYub3JnDQpP YmpldMKgOiBbZGltZV0gIzMyOiBTZXF1ZW5jZS1OdW1iZXIgVGltZS1TdGFtcCB2YWx1ZXMgd2l0 aGluIE9DLU9MUg0KDQojMzI6IFNlcXVlbmNlLU51bWJlciBUaW1lLVN0YW1wIHZhbHVlcyB3aXRo aW4gT0MtT0xSDQoNCiBUaGUgLTAxIGRyYWZ0IHNheXMgaW4gY2xhdXNlIDQuNDoNCiAgICBGcm9t IHRoZSBmdW5jdGlvbmFsaXR5IHBvaW50IG9mIHZpZXcsIHRoZSBPQy1TZXF1ZW5jZS1OdW1iZXIg QVZQIE1VU1QNCiAgICBiZSB1c2VkIGFzIGEgbm9uLXZvbGF0aWxlIGluY3JlYXNpbmcgY291bnRl ciBiZXR3ZWVuIHR3byBvdmVybG9hZA0KICAgIGNvbnRyb2wgZW5kcG9pbnRzIChuZWdsZWN0aW5n IHRoZSBmYWN0IHRoYXQgdGhlIGNvbnRlbnRzIG9mIHRoZSBBVlANCiAgICBpcyBhIDY0LWJpdCBO VFAgdGltZXN0YW1wIFtSRkM1OTA1XSkuICBUaGUgc2VxdWVuY2UgbnVtYmVyIGlzIG9ubHkNCiAg ICByZXF1aXJlZCB0byBiZSB1bmlxdWUgYmV0d2VlbiB0d28gb3ZlcmxvYWQgY29udHJvbCBlbmRw b2ludHMuDQogICAgU2VxdWVuY2UgbnVtYmVycyBhcmUgdHJlYXRlZCBpbiB1bmktZGlyZWN0aW9u YWwgbWFubmVyLCBpLmUuIHR3bw0KICAgIHNlcXVlbmNlIG51bWJlcnMgb24gZWFjaCBkaXJlY3Rp b24gYmV0d2VlbiB0d28gZW5kcG9pbnRzIGFyZSBub3QNCiAgICByZWxhdGVkIG9yIGNvcnJlbGF0 ZWQuDQoNCiAgICBXaGVuIGdlbmVyYXRpbmcgc2VxdWVuY2UgbnVtYmVycywgdGhlIG5ldyBzZXF1 ZW5jZSBudW1iZXIgTVVTVCBiZQ0KICAgIGdyZWF0ZXIgdGhhbiBhbnkgc2VxdWVuY2UgbnVtYmVy IHByZXZpb3VzbHkgc2VlbiBiZXR3ZWVuIHR3bw0KICAgIGVuZHBvaW50cyB3aXRoaW4gYSB0aW1l IHdpbmRvdyB0aGF0IHRvbGVyYXRlcyB0aGUgd3JhcGFyb3VuZCBvZiB0aGUNCiAgICBOVFAgdGlt ZXN0YW1wIChpLmUuIGFwcHJveGltYXRlbHkgNjggeWVhcnMpLg0KDQoNCiBXaXRoIHRoaXMgbWVj aGFuaXNtIGl0IGlzIGRpZmZpY3VsdCB0byBnZXQgYmFjayB0byBzeW5jIG9uY2UgeW91IGFyZSBv dXQgIG9mIHN5bmMgKGZvciB3aGF0ZXZlciByZWFzb24pLg0KIEl0IGlzIHByb3Bvc2VkIHRvIG1h bmRhdGUgdGhhdCB0aGUgU2VxdWVuY2UgTnVtYmVyIGlzIGEgcmVhbCA2NC1iaXQgTlRQICB0aW1l c3RhbXAgKFJGQzU5MDUpIGluZGljYXRpbmcgdGhlIHBvaW50IGluIHRpbWUgd2hlbiB0aGUgT0xS IHdhcyBjcmVhdGVkLCAgYW5kIHRvIG1hbmRhdGUgdGhhdCAgT0xScyB3aXRoIGEgdGltZSBzdGFt cCBoaWdoZXIgdGhhbiB0aW1lIG9mIHJlY2VwdGlvbiAgbXVzdCBiZSBpZ25vcmVkIGJ5IHRoZSBy ZWFjdGluZyBub2RlLg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBsaW9uZWwubW9yYW5k QG9yYW5nZS5jb20gIHwgICAgICBPd25lcjogIFVscmljaCBXaWVoZQ0KICAgICBUeXBlOiAgZGVm ZWN0ICAgICAgICAgICAgICAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1h am9yICAgICAgICAgICAgICAgICAgICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgZHJhZnQt ZG9jZHQtZGltZS1vdmxpICAgICB8ICAgIFZlcnNpb246DQogU2V2ZXJpdHk6ICBBY3RpdmUgV0cg RG9jdW1lbnQgICAgICAgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxo dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9kaW1lL3RyYWMvdGlja2V0LzMyPg0KZGltZSA8 aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUvPg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4N CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5r IHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RpbWUNCg== From nsalot@cisco.com Tue Feb 4 20:35:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19221A0021 for ; Tue, 4 Feb 2014 20:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6eucjNzA3zC for ; Tue, 4 Feb 2014 20:35:08 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 33A511A0020 for ; Tue, 4 Feb 2014 20:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8044; q=dns/txt; s=iport; t=1391574908; x=1392784508; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w98s5lQOpHIuWy0Wy3EXPyqjeHfIX6L43wg5oNUm/64=; b=VGB/PGrCDfPQtk9b47MljwqoxqBVj/0DhfkqQahJFmm2Sa/XByw8Kvn8 0kYnIq1za7gD2DMYECHfIGO2x9L/n2fVgrYzJqzMuQBWCODA9Plc/Ry2e ECqwsIx+0Rp7O/9QBrXm70CJdDfW3Svq0CrTfxN6oMuHVddz1cqSjFN89 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIC+8VKtJXHA/2dsb2JhbABZgww4V4MBu0sYchZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGHQMCAgIlCxQBCAgCBAESCId9Da0FoS8XgSmMahEBCwMROAaCaTWBFASZXZBvgy2BagcXIg X-IronPort-AV: E=Sophos;i="4.95,784,1384300800"; d="scan'208";a="18012448" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 05 Feb 2014 04:35:07 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s154Z7cd021243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 04:35:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 22:35:06 -0600 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPIbojK6CrOby9bE2+HyxjAVNaRZqmExjw Date: Wed, 5 Feb 2014 04:35:06 +0000 Message-ID: References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 04:35:11 -0000 QnV0IGNhbiB0aGUgcmVhY3Rpbmcgbm9kZSBtYWtlIHVzZSBvZiBTdXBwb3J0ZWQtRmVhdHVyZS9P Qy1GZWF0dXJlLVZlY3RvciBBVlAsIHJlY2VpdmVkIGluIGFuc3dlciBtZXNzYWdlPw0KSSBndWVz cyBub3QuDQoNCkJhc2VkIG9uIHRoZSBTdXBwb3J0ZWQtRmVhdHVyZS9PQy1GZWF0dXJlLVZlY3Rv ciBBVlAgcmVjZWl2ZWQgdGhlIHJlcG9ydGluZyBub2RlIHdpbGwgZ2VuZXJhdGUgT0MtT0xSIG9y IG5ldyBPTFIgZGVmaW5lZCBpbiBmdXR1cmUgKGZvciBkaWZmZXJlbnQgYWJhdGVtZW50IGFsZ29y aXRobSkuIA0KU28gaW4gZ2VuZXJhbCwgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgU3VwcG9ydGVk LUZlYXR1cmUvT0MtRmVhdHVyZS1WZWN0b3IgQVZQIGlzIG5vdCB1c2VmdWwgZm9yIHRoZSByZWFj dGluZyBub2RlLg0KSWYgc28sIGl0IGNhbiBiZSByZW1vdmVkLg0KDQpSZWdhcmRzLA0KTmlyYXYu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpT ZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA4OjMxIFBNDQpUbzogZGltZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMwOiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMg QVZQIGluIGFuc3dlciBtZXNzYWdlcw0KDQpJIHRoaW5rIHRoYXQgdGhlcmUgaXMgYWN0dWFsbHkg YW4gaXNzdWUgaGVyZSBidXQgdGhlIHByb3Bvc2VkIHdheSB0byBzb2x2ZSBpdCBpcyBub3QgdGhl IGNvcnJlY3Qgb25lLg0KVGhlIGluaXRpYWwgaWRlYSB3YXMgdG8gYmUgYWJsZSB0byB1c2UgdGhl IHNhbWUgb3ZlcmxvYWQgcmVwb3J0IHdpdGggc2V2ZXJhbCBhbGdvcml0aG1zLiBTbyB0aGUgT0xS IHdhcyBzb21laG93IG9ubHkgbWVhbmluZ2Z1bCBhbG9uZyB3aXRoIHRoZSBPQy1GZWF0dXJlLVZl Y3RvciBBVlAuDQoNCkJ1dCBiZWNhdXNlIHRoZSBPQy1GZWF0dXJlLVZlY3RvciBBVlAgaXMgZGVm aW5lZCBhcyBhIHNldCBvZiBmbGFncywgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHNheSB0aGF0IHRo aXMgT0xSIGlzIHRvIGJlIHVzZWQgd2l0aCBvbmx5IG9uZSBnaXZlbiBhbGdvIHdoZW4gbW9yZSB0 aGFuIG9uZSBpcyBkZWZpbmVkIChhcyB0aGUgYml0IGZsYWdzIHdpbGwgYWR2ZXJ0aXplIDEgQU5E IDIgZm9yIDIgc3VwcG9ydGVkIGFsZ29zKS4gU28gdGhlIE9DLUZlYXR1cmUtVmVjdG9yIGNhbm5v dCBiZSB1c2VkIHRvIGluZGljYXRlIHRoZSBhYmF0ZW1lbnQgdG8gcGVyZm9ybS4NCg0KQXMgdGhl IHN5bnRheCBvZiB0aGUgT0MtRmVhdHVyZS1WZWN0b3IgaXMgYWRhcHRlZCB0byBhZHZlcnRpemUg c3VwcG9ydGVkIGFsZ29zLCBpdCBjb3VsZCBiZSBlYXNpZXIgdG8gY2xhcmlmeSB0aGF0IHRoZSBP Qy1PTFIgQVZQIGlzIFRIRSByZXBvcnQgQVZQIGZvciB0aGUgcmVkdWN0aW9uIGFsZ28gKGRlZmF1 bHQpIGFuZCBhIG5ldyBkZWRpY2F0ZWQgcmVwb3J0IEFWUCBtdXN0IGJlIGNyZWF0ZWQgd2hlbiBh IG5ldyBhbGdvIGlzIGludHJvZHVjZWQuIEluIHRoaXMgd2F5LCB0aGUgT0MtT0xSIGlzIHNlbGYt ZXhwbGljaXQuDQoNCkl0IHdvdWxkIGJlIHB1cmVseSBvcHRpb25hbCB0byBzZW5kIHRoZSBTdXBw b3J0ZWQtRmVhdHVyZXMgQVZQIGFsb25nIHdpdGggdGhlIE9DLU9MUiBBVlAuDQoNCkxpb25lbCAN Cg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBkaW1lIGlzc3VlIHRyYWNrZXIg W21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCkVudm95w6nCoDogbWFyZGkg NCBmw6l2cmllciAyMDE0IDA5OjQ4DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCkNjwqA6 IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6IFtkaW1lXSAjMzA6IE9DLVN1cHBvcnRlZC1GZWF0dXJl cyBBVlAgaW4gYW5zd2VyIG1lc3NhZ2VzDQoNCiMzMDogT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFW UCBpbiBhbnN3ZXIgbWVzc2FnZXMNCg0KIEFjY29yZGluZyB0byB0aGUgY3VycmVudCBmZWF0dXJl IGFkdmVydGlzZW1lbnQvbmVnb3RpYXRpb24gbWVjaGFuaXNtIGluICB0aGUgLTAxIGRyYWZ0IHJl cG9ydGluZyBET0lDIGVuZHBvaW50IGluc2VydCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQ ICBpbiBhbnN3ZXIgbWVzc2FnZXMgdG8gaW5kaWNhdGUgdGhlaXIgc3VwcG9ydGVkIE9DIGZlYXR1 cmVzIHRvIHRoZSByZWFjdGluZyAgRE9JQyBlbmRwb2ludC4NCiBUaGUgYXV0aG9yIG9mIHRoaXMg ZG9jdW1lbnQgYmVsaWV2ZXMgdGhhdCAgdGhlIGJlc3QgYSByZWFjdGluZyBub2RlIGNhbiBkbyAg d2l0aCBzdWNoIGluZm9ybWF0aW9uIGlzIHRvIGlnbm9yZSBpdCwgYW5kIHRoZXJlZm9yZSBwcm9w b3NlcyB0byBhbGxvdyAgcmVwb3J0aW5nIG5vZGVzIG5vdCB0byBpbnNlcnQgT0MtU3VwcG9ydGVk LUZlYXR1cmVzIEFWUHMgaW4gYW5zd2VyICBtZXNzYWdlcy4NCiBDdXJyZW50bHkgb25seSBvbmUg ZmVhdHVyZSBpcyBkZWZpbmVkIChPTFJfREVGQVVMVF9BTEdPKS4NCiBBIHJlYWN0aW5nIERPSUMg ZW5kcG9pbnQgdGhhdCBzdXBwb3J0cyBvbmx5IE9MUl9ERUZBVUxUX0FMR08gYnV0IG5vIG90aGVy ICBmZWF0dXJlIGlzIG9ubHkgaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcvbm90IHJlY2VpdmluZyBP Qy1PTFIgQVZQcyBmcm9tICByZXBvcnRpbmcgRE9JQy1lbmRwb2ludHMuIFJlY2VpdmluZyBhbiBP Qy1PTFIgQVZQIGltcGxpY2l0bHkgaW5kaWNhdGVzICBzdXBwb3J0IG9mIE9MUl9ERUZBVUxUX0FM R08gIGJ5IHRoZSByZXBvcnRpbmcgRE9JQyBlbmRwb2ludDsgbm90IHJlY2VpdmluZyAgYW4gT0Mt T0xSLUFWUCBmcm9tIHRoZSByZXBvcnRpbmcgRE9JQyBlbmRwb2ludCBtYXkgaGF2ZSB0d28gcmVh c29uczoNCg0KIGEpIFRoZXJlIGlzIG5vIG92ZXJsb2FkDQogYikgRE9JQyBpcyBub3Qgc3VwcG9y dGVkDQoNCiBUaGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBkb2VzIG5vdCBuZWVkIHRvIGRpZmZl cmVudGlhdGUgYmV0d2VlbiB0aGVzZSAgdHdvIGNhc2VzIGFzIHRoZSBiZWhhdmlvciAoZG8gbm90 IHRocm90dGxlKSBpcyB0aGUgc2FtZSBpbiBib3RoIGNhc2VzLg0KIFRoZSAtMDEgZHJhZnQgc2F5 cyBpbiAgY2xhdXNlIDQuMToNCiAgICBJZiB0aGVyZSBpcyBubyBzaW5nbGUgbWF0Y2hpbmcNCiAg ICBjYXBhYmlsaXR5IHRoZSByZWFjdGluZyBub2RlIE1VU1QgYWN0IGFzIGlmIGl0IGRvZXMgbm90 IGltcGxlbWVudA0KICAgIERPSUMgYW5kIGNlYXNlIGluc2VydGluZyBhbnkgRE9JQyByZWxhdGVk IEFWUHMgaW50byBhbnkgRGlhbWV0ZXINCiAgICBtZXNzYWdlcyB3aXRoIHRoaXMgc3BlY2lmaWMg cmVhY3Rpbmcgbm9kZS4NCg0KIFRoaXMgaG93ZXZlciBpcyBpbmNvbnNpc3RlbnQuDQogVGhlIHJl YWN0aW5nIG5vZGUgdGhhdCBjZWFzZXMgc2VuZGluZyBET0lDIHJlbGF0ZWQgQVZQcyB3b3VsZCBu ZXZlciAgcmVjb2duaXplIHdoZW4gdGhlIHNlcnZlciBpcyB1cGdyYWRlZCB0byBzdXBwb3J0IERP SUMuDQogU3Vic2VxdWVudCByZXF1ZXN0cyAobm90IGluY2x1ZGluZyBET0lDIHJlbGF0ZWQgQVZQ cykgbWF5IHRha2UgYSBkaWZmZXJlbnQgIHBhdGggdG93YXJkcyB0aGUgc2VydmVyIGFuZCBvbiB0 aGF0IHBhdGggdGhlcmUgbWF5IGJlIGFuIGFnZW50IHRoYXQgIHN1cHBvcnRzIERPSUMgKHdpdGgg YSBtYXRjaCBvZiBzdXBwb3J0ZWQgZmVhdHVyZXMpIGFuZCBjb3VsZCB0YWtlIHRoZSByb2xlICBv ZiB0aGUgcmVwb3J0aW5nIERPSUMgZW5kcG9pbnQ7IGJ1dCB0aGUgYWdlbnQgY2Fubm90IHRha2Ug dGhpcyByb2xlIHNpbmNlICB0aGUgcmVhY3Rpbmcgbm9kZSAoYWx0aG91Z2ggc3VwcG9ydGluZyBE T0lDKSBjZWFzZWQgc2VuZGluZyBvZiBPQy0gIFN1cHBvcnRlZC1GZWF0dXJlcyBBVlBzLg0KIElu IHN1bW1hcnk6IEFzIGxvbmcgYXMgbm8gZXh0ZW5zaW9uIGZlYXR1cmUgaXMgZGVmaW5lZCB3aXRo aW4gIGRyYWZ0LWlldGYtICBkaW1lLW92bGkgIChpLmUuIG5ldmVyLCBzaW5jZSBleHRlbnNpb25z IHdpbGwgIGJlIGRlZmluZWQgaW4gb3RoZXIgIGRyYWZ0cyksIHRoZXJlIGlzIG5vIG5lZWQgZm9y IGRyYWZ0LWlldGYtZGltZS1vdmxpICB0byBtYW5kYXRlIG9yIGV2ZW4gIGRlc2NyaWJlIGluY2x1 c2lvbiBvZiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIGluIGFuc3dlciBtZXNzYWdlcy4NCg0K LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tICB8ICAg ICAgT3duZXI6ICBVbHJpY2ggV2llaGUNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAg ICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAg ICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIGRyYWZ0LWRvY2R0LWRpbWUtb3ZsaSAg ICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgQWN0aXZlIFdHIERvY3VtZW50ICAgICAgICB8 ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvZGltZS90cmFjL3RpY2tldC8zMD4NCmRpbWUgPGh0dHA6Ly90b29scy5pZXRm Lm9yZy93Zy9kaW1lLz4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlz dA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aW1lDQo= From nsalot@cisco.com Tue Feb 4 20:50:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A551A0021 for ; Tue, 4 Feb 2014 20:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YyEVwHXrNel for ; Tue, 4 Feb 2014 20:49:58 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 60A761A0026 for ; Tue, 4 Feb 2014 20:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7472; q=dns/txt; s=iport; t=1391575798; x=1392785398; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wB5dujKzatqxBUesof/A9DwSCv6eOvnyytMvKm2Pk/c=; b=aW6WNFGdFGGUDBXyw4lG34MhVSMtC0XkSByVRM5pwoUnkokyZ7BOuXuF AzZlcwsy4uF/MAiw6X+VKsfRtUJMqB3zzVdR1VMy84xYaGNTtFTaREC8P KSmQKKVlJPlge2SebBFGq5UftyxJyP0YPy+9iDDF7rnS93S3yPDMrJeY4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAADC8VKtJV2c/2dsb2JhbABZgww4V75MgQoWdIIlAQEBAwEBAQFrEAcEAgEIEQQBAQsdBycLFAkIAgQBEgiHdQgNzjsXjhMRAQsUOAaDHoEUBIkRkEyQb4MtgXE5 X-IronPort-AV: E=Sophos;i="4.95,784,1384300800"; d="scan'208";a="301938144" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 05 Feb 2014 04:49:57 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s154nvsv017689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 04:49:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 22:49:57 -0600 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89eXJ9DV5yh0O/JvsvYrZiTpqlu04AgABay3A= Date: Wed, 5 Feb 2014 04:49:57 +0000 Message-ID: References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 04:50:00 -0000 Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Wed Feb 5 00:04:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490BA1A009E for ; Wed, 5 Feb 2014 00:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26gbGlcwlf0U for ; Wed, 5 Feb 2014 00:03:58 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 15D191A0063 for ; Wed, 5 Feb 2014 00:03:57 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1583uFp006740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 09:03:56 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1583to3029459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 09:03:55 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 09:03:55 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 09:03:55 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPIbnza0SZ1wdbvEGvoj4P8RAtnpqlM3SggAARYlCAAQdGQA== Date: Wed, 5 Feb 2014 08:03:55 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1F71@DEMUMBX014.nsn-intra.net> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> <7610_1391532667_52F11A7B_7610_3074_1_6B7134B31289DC4FAF731D844122B36E4774C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <7610_1391532667_52F11A7B_7610_3074_1_6B7134B31289DC4FAF731D844122B36E4774C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12330 X-purgate-ID: 151667::1391587436-000025D0-BD717AEE/0-0/0-0 Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 08:04:02 -0000 SGkgTG9pbmVsLA0KDQppdCBzZWVtcyB0aGF0IHdlIGNhbiBzYWZlbHkgcmVtb3ZlIE9DLVN1cHBv cnRlZC1GZWF0dXJlIEFWUCBmcm9tIGFuc3dlciBtZXNzYWdlcyBpbiB0aGUgZHJhZnQtaWV0Zi1k aW1lLW92bGkgKHdoaWNoIGRvZXMgbm90IGRlZmluZSBleHRlbnNpb25zIHRvIGl0c2VsZikuIFRo aXMgZG9lcyBub3QgbWVhbiB0aGF0IGEgZnV0dXJlIGV4dGVuc2lvbiBjYW5ub3QgKHJlKS1pbnRy b2R1Y2UgaXQgd2hlbiBuZWVkZWQuIEl0IGFsc28gZG9lcyBub3QgbWVhbiB0aGF0IHJlcG9ydGlu ZyBub2RlcyBhcmUgbm90IGFsbG93ZWQgdG8gaW5jbHVkZSBpdCBpbiBhbnN3ZXIgbWVzc2FnZXMg YXMgbG9uZyBhcyBhbnN3ZXIgbWVzc2FnZXMgaGF2ZSBhICpbQVZQXS4NCg0KQmVzdCByZWdhcmRz DQpVbHJpY2gNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBsaW9uZWwu bW9yYW5kQG9yYW5nZS5jb20gW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dIA0KU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgNTo1MSBQTQ0KVG86IFdpZWhlLCBVbHJpY2gg KE5TTiAtIERFL011bmljaCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbZGltZV0gIzMw OiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIGluIGFuc3dlciBtZXNzYWdlcw0KDQpIaSBVbHJp Y2gsDQoNCkZvciB0aGUgcG9pbnQgMiBhbmQgMywgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg IlNob3VsZCIgYW5kIHRoZSAiTWF5IiBpcyBxdWl0ZSBzdWJ0bGUgaGVyZSBhbmQgaXMgZm9yIG1l IG9ubHkgYW4gaW1wbGVtZW50YXRpb24gb3B0aW9uLg0KDQpGb3IgNCBhbmQgNSwgb2sgaWYgdGhl IG5vZGUgb25seSBzdXBwb3J0cyB0aGUgZGVmYXVsdCBhbGdvLiBJbiBvdGhlciB3b3Jkcywgb25s eSB0aGUgT0xSIG1hdHRlcnMgZm9yIG5vZGVzIHN1cHBvcnRpbmcgb25seSB0aGUgZGVmYXVsdCBh bGdvLiBUaGUgcmVzdCBpcyBwdXJlbHkgZm9yIGluZm9ybWF0aW9uIGFuZCBjYW4gYmUgc2FmZWx5 IGlnbm9yZWQuDQoNCkZvciA2LCBpZiB0aGUgbmV3IGZlYXR1cmUgY29uc2lzdHMgaW4gYSBuZXcg YWxnbywgaXQgd291bGQgbWVhbiBkZWZpbmluZyBhIG5ldyBkZWRpY2F0ZWQgT0xSIEFWUC4gU28g bm9kZXMgc3VwcG9ydGluZyBvbmx5IHRoZSBkZWZhdWx0IGFsZ28gd2lsbCBpZ25vcmUgYW55IHVu a25vd24gQVZQIGlmIHJlY2VpdmVkLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gp IFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dIA0KRW52b3nDqcKgOiBtYXJkaSA0IGbDqXZy aWVyIDIwMTQgMTc6MDQNCsOAwqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTjsgZGltZUBpZXRmLm9y Zw0KT2JqZXTCoDogUkU6IFtkaW1lXSAjMzA6IE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgaW4g YW5zd2VyIG1lc3NhZ2VzDQoNCkRlYXIgTGlvbmVsLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgcmVz cG9uc2UuDQoNCklmIEkgY29ycmVjdGx5IHVuZGVyc3RhbmQsIHRoZSBwcmluY2lwbGVzIHdvdWxk IGJlOg0KMS4gU2VuZGluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgaW4gYW5zd2VyIG1lc3NhZ2Vz IGlzIHN5bnRhY3RpY2FsbHkgb3B0aW9uYWwuDQoyLiBXaGVuIHRoZSByZWFjdGluZyBub2RlIGRv ZXMgb25seSBzdXBwb3J0IE9MUl9ERUZBVUxUX0FMR08gLCB0aGUgcmVwb3J0aW5nIG5vZGUgc2hv dWxkIG5vdCBpbnNlcnQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCBpbiB0aGUgYW5zd2Vy IG1lc3NhZ2UuDQozLiBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkb2VzIG9ubHkgc3VwcG9ydCBP TFJfREVGQVVMVF9BTEdPLCBpdCBzaG91bGQgbm90IGluc2VydCBhbiBPQy1TdXBwb3J0ZWQtRmVh dHVyZXMgQVZQIGluIHRoZSBhbnN3ZXIgbWVzc2FnZS4NCjQuIEEgcmVhY3Rpbmcgbm9kZSB0aGF0 IHN1cHBvcnRzIG9ubHkgT0xSX0RFRkFVTFRfQUxHTyBjYW4gc2FmZWx5IGlnbm9yZSBPQy1TdXBw b3J0ZWQtRmVhdHVyZXMgQVZQcyByZWNlaXZlZCBpbiBhbnN3ZXIgbWVzc2FnZXMuDQo1LiBBIHJl YWN0aW5nIG5vZGUgdGhhdCBzdXBwb3J0cyBvbmx5IE9MUl9ERUZBVUxUX0FMR08gY2FuIHNhZmVs eSBpZ25vciBhbGwgZXh0ZW5zaW9ucyByZWNlaXZlZCBpbiBhbiBPQy1PTFIuDQo2LiBXaGVuIGEg bmV3IGZlYXR1cmUgaXMgaW50cm9kdWNlZCwgdGhlIHNwZWMgaW50cm9kdWNpbmcgdGhlIG5ldyBm ZWF0dXJlIG11c3QgZGVmaW5lIHRoZSBkZXRhaWxzIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5 IG9mIG5vZGVzIHN1cHBvcnRpbmcgdGhlIG5ldyBmZWF0dXJlIHdpdGggbm9kZXMgdGhhdCBkbyBu b3Qgc3VwcG9ydCB0aGUgbmV3IGZlYXR1cmUgKHRha2luZyBpbnRvIGFjY291bnQgdGhhdCBub2Rl cyBub3Qgc3VwcG9ydGluZyB0aGUgbmV3IGZlYXR1cmUgYWN0IGFjY29yZGluZyB0byB0aGUgcHJp bmNpcGxlcyAxLi01LikuDQoNCg0KQmVzdCByZWdhcmRzDQpVbHJpY2gNCiAgDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA0OjAxIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMwOiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIGlu IGFuc3dlciBtZXNzYWdlcw0KDQpJIHRoaW5rIHRoYXQgdGhlcmUgaXMgYWN0dWFsbHkgYW4gaXNz dWUgaGVyZSBidXQgdGhlIHByb3Bvc2VkIHdheSB0byBzb2x2ZSBpdCBpcyBub3QgdGhlIGNvcnJl Y3Qgb25lLg0KVGhlIGluaXRpYWwgaWRlYSB3YXMgdG8gYmUgYWJsZSB0byB1c2UgdGhlIHNhbWUg b3ZlcmxvYWQgcmVwb3J0IHdpdGggc2V2ZXJhbCBhbGdvcml0aG1zLiBTbyB0aGUgT0xSIHdhcyBz b21laG93IG9ubHkgbWVhbmluZ2Z1bCBhbG9uZyB3aXRoIHRoZSBPQy1GZWF0dXJlLVZlY3RvciBB VlAuDQoNCkJ1dCBiZWNhdXNlIHRoZSBPQy1GZWF0dXJlLVZlY3RvciBBVlAgaXMgZGVmaW5lZCBh cyBhIHNldCBvZiBmbGFncywgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHNheSB0aGF0IHRoaXMgT0xS IGlzIHRvIGJlIHVzZWQgd2l0aCBvbmx5IG9uZSBnaXZlbiBhbGdvIHdoZW4gbW9yZSB0aGFuIG9u ZSBpcyBkZWZpbmVkIChhcyB0aGUgYml0IGZsYWdzIHdpbGwgYWR2ZXJ0aXplIDEgQU5EIDIgZm9y IDIgc3VwcG9ydGVkIGFsZ29zKS4gU28gdGhlIE9DLUZlYXR1cmUtVmVjdG9yIGNhbm5vdCBiZSB1 c2VkIHRvIGluZGljYXRlIHRoZSBhYmF0ZW1lbnQgdG8gcGVyZm9ybS4NCg0KQXMgdGhlIHN5bnRh eCBvZiB0aGUgT0MtRmVhdHVyZS1WZWN0b3IgaXMgYWRhcHRlZCB0byBhZHZlcnRpemUgc3VwcG9y dGVkIGFsZ29zLCBpdCBjb3VsZCBiZSBlYXNpZXIgdG8gY2xhcmlmeSB0aGF0IHRoZSBPQy1PTFIg QVZQIGlzIFRIRSByZXBvcnQgQVZQIGZvciB0aGUgcmVkdWN0aW9uIGFsZ28gKGRlZmF1bHQpIGFu ZCBhIG5ldyBkZWRpY2F0ZWQgcmVwb3J0IEFWUCBtdXN0IGJlIGNyZWF0ZWQgd2hlbiBhIG5ldyBh bGdvIGlzIGludHJvZHVjZWQuIEluIHRoaXMgd2F5LCB0aGUgT0MtT0xSIGlzIHNlbGYtZXhwbGlj aXQuDQoNCkl0IHdvdWxkIGJlIHB1cmVseSBvcHRpb25hbCB0byBzZW5kIHRoZSBTdXBwb3J0ZWQt RmVhdHVyZXMgQVZQIGFsb25nIHdpdGggdGhlIE9DLU9MUiBBVlAuDQoNCkxpb25lbCANCg0KLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21haWx0 bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10gDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOp dnJpZXIgMjAxNCAwOTo0OA0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1l QGlldGYub3JnDQpPYmpldMKgOiBbZGltZV0gIzMwOiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQ IGluIGFuc3dlciBtZXNzYWdlcw0KDQojMzA6IE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgaW4g YW5zd2VyIG1lc3NhZ2VzDQoNCiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgZmVhdHVyZSBhZHZl cnRpc2VtZW50L25lZ290aWF0aW9uIG1lY2hhbmlzbSBpbg0KIHRoZSAtMDEgZHJhZnQgcmVwb3J0 aW5nIERPSUMgZW5kcG9pbnQgaW5zZXJ0IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlANCiBp biBhbnN3ZXIgbWVzc2FnZXMgdG8gaW5kaWNhdGUgdGhlaXIgc3VwcG9ydGVkIE9DIGZlYXR1cmVz IHRvIHRoZSByZWFjdGluZw0KIERPSUMgZW5kcG9pbnQuDQogVGhlIGF1dGhvciBvZiB0aGlzIGRv Y3VtZW50IGJlbGlldmVzIHRoYXQgIHRoZSBiZXN0IGEgcmVhY3Rpbmcgbm9kZSBjYW4gZG8NCiB3 aXRoIHN1Y2ggaW5mb3JtYXRpb24gaXMgdG8gaWdub3JlIGl0LCBhbmQgdGhlcmVmb3JlIHByb3Bv c2VzIHRvIGFsbG93DQogcmVwb3J0aW5nIG5vZGVzIG5vdCB0byBpbnNlcnQgT0MtU3VwcG9ydGVk LUZlYXR1cmVzIEFWUHMgaW4gYW5zd2VyDQogbWVzc2FnZXMuDQogQ3VycmVudGx5IG9ubHkgb25l IGZlYXR1cmUgaXMgZGVmaW5lZCAoT0xSX0RFRkFVTFRfQUxHTykuDQogQSByZWFjdGluZyBET0lD IGVuZHBvaW50IHRoYXQgc3VwcG9ydHMgb25seSBPTFJfREVGQVVMVF9BTEdPIGJ1dCBubyBvdGhl cg0KIGZlYXR1cmUgaXMgb25seSBpbnRlcmVzdGVkIGluIHJlY2VpdmluZy9ub3QgcmVjZWl2aW5n IE9DLU9MUiBBVlBzIGZyb20NCiByZXBvcnRpbmcgRE9JQy1lbmRwb2ludHMuIFJlY2VpdmluZyBh biBPQy1PTFIgQVZQIGltcGxpY2l0bHkgaW5kaWNhdGVzDQogc3VwcG9ydCBvZiBPTFJfREVGQVVM VF9BTEdPICBieSB0aGUgcmVwb3J0aW5nIERPSUMgZW5kcG9pbnQ7IG5vdCByZWNlaXZpbmcNCiBh biBPQy1PTFItQVZQIGZyb20gdGhlIHJlcG9ydGluZyBET0lDIGVuZHBvaW50IG1heSBoYXZlIHR3 byByZWFzb25zOg0KDQogYSkgVGhlcmUgaXMgbm8gb3ZlcmxvYWQNCiBiKSBET0lDIGlzIG5vdCBz dXBwb3J0ZWQNCg0KIFRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGRvZXMgbm90IG5lZWQgdG8g ZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZXNlDQogdHdvIGNhc2VzIGFzIHRoZSBiZWhhdmlvciAo ZG8gbm90IHRocm90dGxlKSBpcyB0aGUgc2FtZSBpbiBib3RoIGNhc2VzLg0KIFRoZSAtMDEgZHJh ZnQgc2F5cyBpbiAgY2xhdXNlIDQuMToNCiAgICBJZiB0aGVyZSBpcyBubyBzaW5nbGUgbWF0Y2hp bmcNCiAgICBjYXBhYmlsaXR5IHRoZSByZWFjdGluZyBub2RlIE1VU1QgYWN0IGFzIGlmIGl0IGRv ZXMgbm90IGltcGxlbWVudA0KICAgIERPSUMgYW5kIGNlYXNlIGluc2VydGluZyBhbnkgRE9JQyBy ZWxhdGVkIEFWUHMgaW50byBhbnkgRGlhbWV0ZXINCiAgICBtZXNzYWdlcyB3aXRoIHRoaXMgc3Bl Y2lmaWMgcmVhY3Rpbmcgbm9kZS4NCg0KIFRoaXMgaG93ZXZlciBpcyBpbmNvbnNpc3RlbnQuDQog VGhlIHJlYWN0aW5nIG5vZGUgdGhhdCBjZWFzZXMgc2VuZGluZyBET0lDIHJlbGF0ZWQgQVZQcyB3 b3VsZCBuZXZlcg0KIHJlY29nbml6ZSB3aGVuIHRoZSBzZXJ2ZXIgaXMgdXBncmFkZWQgdG8gc3Vw cG9ydCBET0lDLg0KIFN1YnNlcXVlbnQgcmVxdWVzdHMgKG5vdCBpbmNsdWRpbmcgRE9JQyByZWxh dGVkIEFWUHMpIG1heSB0YWtlIGEgZGlmZmVyZW50DQogcGF0aCB0b3dhcmRzIHRoZSBzZXJ2ZXIg YW5kIG9uIHRoYXQgcGF0aCB0aGVyZSBtYXkgYmUgYW4gYWdlbnQgdGhhdA0KIHN1cHBvcnRzIERP SUMgKHdpdGggYSBtYXRjaCBvZiBzdXBwb3J0ZWQgZmVhdHVyZXMpIGFuZCBjb3VsZCB0YWtlIHRo ZSByb2xlDQogb2YgdGhlIHJlcG9ydGluZyBET0lDIGVuZHBvaW50OyBidXQgdGhlIGFnZW50IGNh bm5vdCB0YWtlIHRoaXMgcm9sZSBzaW5jZQ0KIHRoZSByZWFjdGluZyBub2RlIChhbHRob3VnaCBz dXBwb3J0aW5nIERPSUMpIGNlYXNlZCBzZW5kaW5nIG9mIE9DLQ0KIFN1cHBvcnRlZC1GZWF0dXJl cyBBVlBzLg0KIEluIHN1bW1hcnk6IEFzIGxvbmcgYXMgbm8gZXh0ZW5zaW9uIGZlYXR1cmUgaXMg ZGVmaW5lZCB3aXRoaW4gIGRyYWZ0LWlldGYtDQogZGltZS1vdmxpICAoaS5lLiBuZXZlciwgc2lu Y2UgZXh0ZW5zaW9ucyB3aWxsICBiZSBkZWZpbmVkIGluIG90aGVyDQogZHJhZnRzKSwgdGhlcmUg aXMgbm8gbmVlZCBmb3IgZHJhZnQtaWV0Zi1kaW1lLW92bGkgIHRvIG1hbmRhdGUgb3IgZXZlbg0K IGRlc2NyaWJlIGluY2x1c2lvbiBvZiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIGluIGFuc3dl ciBtZXNzYWdlcy4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgbGlvbmVsLm1vcmFuZEBv cmFuZ2UuY29tICB8ICAgICAgT3duZXI6ICBVbHJpY2ggV2llaGUNCiAgICAgVHlwZTogIGRlZmVj dCAgICAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpv ciAgICAgICAgICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIGRyYWZ0LWRv Y2R0LWRpbWUtb3ZsaSAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgQWN0aXZlIFdHIERv Y3VtZW50ICAgICAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvZGltZS90cmFjL3RpY2tldC8zMD4NCmRpbWUgPGh0 dHA6Ly90b29scy5pZXRmLm9yZy93Zy9kaW1lLz4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIN CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz Lg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhh bmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0K DQo= From ulrich.wiehe@nsn.com Wed Feb 5 00:53:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B13A1A00AF for ; Wed, 5 Feb 2014 00:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cyF78SJYmEk for ; Wed, 5 Feb 2014 00:53:54 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00C1A00A7 for ; Wed, 5 Feb 2014 00:53:53 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s158rmjO009418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 09:53:48 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s158rmqF005637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 09:53:48 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 09:53:47 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 09:53:47 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89Ab1hB/HwnEqAnOHI0lW5YpqlRfYAgADBN4CAAEyiEA== Date: Wed, 5 Feb 2014 08:53:47 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8723 X-purgate-ID: 151667::1391590428-000025D0-F594E01B/0-0/0-0 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 08:53:56 -0000 Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 nsalot@cisco.com Wed Feb 5 01:03:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22DA1A00A7 for ; Wed, 5 Feb 2014 01:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3b3Qg33HCT9 for ; Wed, 5 Feb 2014 01:03:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D09C91A00A5 for ; Wed, 5 Feb 2014 01:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9369; q=dns/txt; s=iport; t=1391590995; x=1392800595; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iKggL+q6TkPiDhxuFpVKhfTiRY7E3RBA5IFGdYoKJPE=; b=AAJLRkLH9ZJcw7QT/B1AqPySE8x70kpuqk0Fz1H2csTR46yZIirUFHD3 C9olf6bvkJFZ2PsMwuiBggivHGCah/K5qta7rzQILnw3qqd5/jn4j0Gud HGD9qSInuXuTIQt7oF3xUKMPbnhi5taaYvNv15FSzihgfN9fnXTcLRIKT c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAB798VKtJV2d/2dsb2JhbABZgw44Vb0kgQkWAXSDfQEBAQMBAQEBaxAHBAIBCBEEAQELHQcnCxQJCAIEARIIh3QIDcd8F44wEQELFDgGgx2BEwSJC5A7kGSDK4FxOQ X-IronPort-AV: E=Sophos;i="4.95,785,1384300800"; d="scan'208";a="298955767" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 05 Feb 2014 09:03:13 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1593C2t018550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 09:03:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 03:03:12 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89eXJ9DV5yh0O/JvsvYrZiTpqlu04AgABay3CAAKqNgP//nHVw Date: Wed, 5 Feb 2014 09:03:11 +0000 Message-ID: References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 09:03:18 -0000 Ulrich, I do not think so. If we believe that there should be host-specific OLR and if we want to supp= ort the model when the agent acts as reacting node (on behalf of the client= (s)), then the agents are naturally required to store OLR per client/host b= ehind the agent (based on the destination-host AVP in the answer message). Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, February 05, 2014 2:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ulrich.wiehe@nsn.com Wed Feb 5 01:32:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF09E1A00B3 for ; Wed, 5 Feb 2014 01:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGKwRgptYSSQ for ; Wed, 5 Feb 2014 01:32:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 98A291A00B1 for ; Wed, 5 Feb 2014 01:32:09 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s159W5QN022602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 10:32:05 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s159W4gJ005260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 10:32:05 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 10:32:04 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 10:32:04 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89Ab1hB/HwnEqAnOHI0lW5YpqlRfYAgADBN4CAAEyiEP//+h+AgAASgdA= Date: Wed, 5 Feb 2014 09:32:04 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10120 X-purgate-ID: 151667::1391592725-00001A6F-7D58E49B/0-0/0-0 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 09:32:14 -0000 Nirav, ... and this natural requirement is missing from the current draft. To address this requirement we could replace the descriptions for report ty= pes 0 and 1 with the decriptions of my proposed report types 2 and 3 respec= tively. As a consquence, however, the agent in the given example configuration woul= d have to store always OLRs per client even when S wants all clients to do = the same throttling. Would that be acceptable? Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, February 05, 2014 10:03 AM To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com; dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed Ulrich, I do not think so. If we believe that there should be host-specific OLR and if we want to supp= ort the model when the agent acts as reacting node (on behalf of the client= (s)), then the agents are naturally required to store OLR per client/host b= ehind the agent (based on the destination-host AVP in the answer message). Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, February 05, 2014 2:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ulrich.wiehe@nsn.com Wed Feb 5 03:38:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FBC1A00B2 for ; Wed, 5 Feb 2014 03:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yCeLAPjrT5V for ; Wed, 5 Feb 2014 03:37:59 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 098E81A00E8 for ; Wed, 5 Feb 2014 03:37:58 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s15BbvjF030337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 12:37:57 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s15BbvcV018860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 12:37:57 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 12:37:57 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 12:37:56 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIcxQ8/v/z65LoEmP8SlQdkHvG5qme77Q Date: Wed, 5 Feb 2014 11:37:56 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2062@DEMUMBX014.nsn-intra.net> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 11458 X-purgate-ID: 151667::1391600277-000025D0-7413441B/0-0/0-0 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 11:38:02 -0000 U29ycnksIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcXVlc3Rpb24uDQoNCkFuIGFnZW50IHRoYXQg aXMgY29uZmlndXJlZCB0byB0YWtlIHRoZSByb2xlIG9mIGEgcmVwb3J0aW5nIG5vZGUgZm9yIGEg cmVhbG0gDQotIHdpbGwgc2VuZCAoaW5zZXJ0KSByZWFsbSB0eXBlIE9MUnMgaW4gYW5zd2VyIG1l c3NhZ2VzIHRoYXQgY29ycmVzcG9uZCB0byByZWFsbSB0eXBlIHJlcXVlc3QgbWVzc2FnZXMgKHJl cXVlc3QgbWVzc2FnZXMgdGhhdCBkbyBub3QgY29udGFpbiBhIGRlc3RpbmF0aW9uIGhvc3QpLCBh bmQNCi0gd2lsbCBiZSB0cmFuc3BhcmVudCB3aXRoIHJlZ2FyZCB0byBob3N0IHR5cGUgcmVxdWVz dCBtZXNzYWdlcyAocmVxdWVzdCBtZXNzYWdlcyB0aGF0IGNvbnRhaW4gYSBkZXN0aW5hdGlvbiBo b3N0YW5kIGFuc3dlciBtZXNzYWdlcykgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGFuc3dlciBtZXNz YWdlcy4NCkNvbnNlcXVlbnRseSB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHJlY2VpdmUgcmVhbG0g dHlwZSBPTFJzIGZyb20gdGhlIGFnZW50IGFuZCBob3N0IHR5cGUgT0xScyBmcm9tIHRoZSBzZXJ2 ZXJzLg0KVGhlIHJlY2VpdmVkIHJlYWxtIHR5cGUgT0xSIHdpbGwgYmUgcmVsZXZhbnQgZm9yIHRo ZSByZWFjdGluZyBub2RlIHdoZW4gc2VuZGluZy90aHJvdHRsaW5nIHJlYWxtIHR5cGUgcmVxdWVz dHM7IHRoZSByZWNlaXZlZCBob3N0IHR5cGUgT0xSIHdpbGwgYmUgcmVsZXZhbnQgZm9yIHRoZSBy ZWFjdGluZyBub2RlIHdoZW4gc2VuZGluZy90aHJvdHRsaW5nIGhvc3QgdHlwZSByZXF1ZXN0cy4N Cg0KDQoNCistLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KfCBDbGllbnQgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBBZ2VudCAgfCAgICAgICAgICAgICAg ICB8IFNlcnZlciB8DQp8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgIHwNCnwgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAg ICAgICAgICAgfCAgICAgICAgfCANCistLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfDwtLS1ET0lDIGFzc29jaWF0aW9uIDEtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnw8LS0tLS0tLURPSUMgYXNzb2NpYXRpb24gMi0tPnwNCiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHw8LS0tLS0tLS0tLS0tLS0tLS1ET0lDIGFz c29jaWF0aW9uIDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQog ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfC0tLTEueHhSLS0tLS0ocmVhbG0gdHlw ZSByZXF1ZXN0KS0tLS0tLS0tLS0tLS0tPnxhZ2VudCBzZWxlY3RzIHNlcnZlciAgICAgICAgIHwN CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0t LS0tLS0tMi54eFItLS0tLS0tLS0tLS0tLS0+fCANCiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tMy54eEEtLS0tLS0tLS0tLS0tLS0t fA0KICAgIHw8LS00Lnh4QS0tLS0tKHJlYWxtIHR5cGUgT0xSICktLS0tLS0tLS0tLS0tLS0tLS18 YWdlbnQgaW5zZXJ0cyBPTFIgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfC0tLTUueHhSLS0tLS0oaG9z dCB0eXBlIHJlcXVlc3QpLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfGFnZW50IGlzIHRyYW5zcGFyZW50ICAgICAgICAgfA0KICAgIHw8LS02Lnh4QS0tLS0tKGhv c3QgdHlwZSBPTFIpLS0tLS0tLS0tLS0tLS0tLS0tLS18LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgIHwtLS03Lnh4Ui0tKHJlYWxtIHR5cGUgcmVxdWVzdCktPnggdGhyb3R0bGVk ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhY2NvcmRpbmcgdG8gIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSByZWNl aXZlICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcmVhbG0gdHlwZSBPTFJ8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgIHwtLS04Lnh4Ui0tKGhvc3QgdHlwZSByZXF1ZXN0KS0+eCAgdGhyb3R0 bGVkICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBhY2NvcmRpbmcgdG8gIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBy ZWNlaXZlICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaG9zdCB0eXBlIE9MUiB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFtt YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IGxpb25lbC5tb3Jh bmRAb3JhbmdlLmNvbQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgNjoxMyBQTQ0K VG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzNDogU2VtYW50 aWNzIG9mIE9DLVJlcG9ydC1UeXBlIEFWUA0KDQpUaGUgY2FzZSAiUmVhbG0iIGFzIGRlc2NyaWJl ZCBiZWxvdyByYWlzZXMgYW5vdGhlciBxdWVzdGlvbjogaXMgaXQgcHJvaGliaXRlZCBmb3IgYSBy ZWFsbSB0byBvbmx5IHJlbHkgb24gYSBnbG9iYWwgb3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUgd2hv bGUgcmVhbG0sIHdoYXRldmVyIHRoZSBub2RlcyBpbnNpZGUgdGhpcyByZWFsbT8NCklmIG5vdCwg b25seSBPTFIgd2l0aCB0aGUgcmVwb3J0IHR5cGUgInJlYWxtIiB3b3VsZCBiZSByZWNlaXZlZCBi eSB0aGUgcmVhY3Rpbmcgbm9kZS4gQW5kIHRoZSByZWR1Y3Rpb24gaW5kaWNhdGVkIGluIHRoZSBP TFIgd2lsbCBhcHBseSBhbHdheXMgZm9yIHRoZSByZWFsbSwgd2hhdGV2ZXIgdGhlIHByZXNlbmNl IG9mIERlc3RpbmF0aW9uLWhvc3QgQVZQIGluIHRoZSByZXF1ZXN0Li4uIGV4Y2VwdCBpZiBhbiBl eHBsaWNpdCByZXBvcnQgd2l0aCB0aGUgdHlwZSAiSG9zdCIgYXMgYmVlbiByZWNlaXZlZCBmb3Ig dGhpcyBkZXN0aW5hdGlvbi1ob3N0Lg0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2U/DQoNCkxpb25lbA0K DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IGRpbWUgaXNzdWUgdHJhY2tlciBb bWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXSANCkVudm95w6nCoDogbWFyZGkg NCBmw6l2cmllciAyMDE0IDA5OjU1DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCkNjwqA6 IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6IFtkaW1lXSAjMzQ6IFNlbWFudGljcyBvZiBPQy1SZXBv cnQtVHlwZSBBVlANCg0KIzM0OiBTZW1hbnRpY3Mgb2YgT0MtUmVwb3J0LVR5cGUgQVZQDQoNCiBU ZXh0IGluIGNsYXVzZSA0LjYgIGRvZXMgbm90IGZ1bGx5IGV4cGxhaW4gdG8gd2hpY2ggcmVxdWVz dHMgb3ZlcmxvYWQNCiB0cmVhdG1lbnQgb2YgYSBnaXZlbiByZXBvcnQgdHlwZSBhcHBsaWVzLg0K IFByb3Bvc2FsOg0KDQogICAgMCAgQSBob3N0IHJlcG9ydC4gIFRoZSBvdmVybG9hZCB0cmVhdG1l bnQgc2hvdWxkIGFwcGx5IHRvIHJlcXVlc3RzDQogICAgICAgZm9yIHdoaWNoIGFsbCBvZiB0aGUg Zm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIHRydWU6DQogICAgICAgYSkgVGhlIERlc3RpbmF0aW9u LUhvc3QgQVZQIGlzIHByZXNlbnQgaW4gdGhlIHJlcXVlc3QgYW5kIGl0cyB2YWx1ZQ0KICAgICAg ICAgIG1hdGNoZXMgdGhlIHZhbHVlIG9mIHRoZSBPcmlnaW4tSG9zdCBBVlAgb2YgdGhlIHJlY2Vp dmVkIG1lc3NhZ2UNCiAgICAgICAgICB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC4NCiAg ICAgICBiKSBUaGUgdmFsdWUgb2YgdGhlIERlc3RpbmF0aW9uLVJlYWxtIEFWUCBpbiB0aGUgcmVx dWVzdCBtYXRjaGVzIHRoZQ0KICAgICAgICAgIHZhbHVlIG9mIHRoZSBPcmlnaW4tUmVhbG0gQVZQ IG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlDQogICAgICAgICAgdGhhdCBjb250YWluZWQgdGhlIE9D LU9MUiBBVlAuDQogICAgICAgYykgVGhlIHZhbHVlIG9mIHRoZSBBcHBsaWNhdGlvbi1JRCBpbiB0 aGUgRGlhbWV0ZXIgSGVhZGVyIG9mIHRoZQ0KICAgICAgICAgIHJlcXVlc3QgbWF0Y2hlcyB0aGUg dmFsdWUgb2YgdGhlIEFwcGxpY2F0aW9uLUlEIG9mIHRoZSBEaWFtZXRlcg0KICAgICAgICAgIEhl YWRlciBvZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZSB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFW UC4NCg0KDQoNCiAgICAxICBBIHJlYWxtIHJlcG9ydC4gIFRoZSBvdmVybG9hZCB0cmVhdG1lbnQg c2hvdWxkIGFwcGx5IHRvDQogICAgICAgcmVxdWVzdHMgZm9yIHdoaWNoIGFsbCBvZiB0aGUgZm9s bG93aW5nIGNvbmRpdGlvbnMgYXJlIHRydWU6DQogICAgICAgYSkgVGhlIERlc3RpbmF0aW9uLUhv c3QgQVZQIGlzIGFic2VudCBpbiB0aGUgcmVxdWVzdC4NCiAgICAgICBiKSBUaGUgdmFsdWUgb2Yg dGhlIERlc3RpbmF0aW9uLVJlYWxtIEFWUCBpbiB0aGUgcmVxdWVzdCBtYXRjaGVzIHRoZQ0KICAg ICAgICAgIHZhbHVlIG9mIHRoZSBPcmlnaW4tUmVhbG0gQVZQIG9mIHRoZSByZWNlaXZlZCBtZXNz YWdlDQogICAgICAgICAgdGhhdCBjb250YWluZWQgdGhlIE9DLU9MUiBBVlAuDQogICAgICAgYykg VGhlIHZhbHVlIG9mIHRoZSBBcHBsaWNhdGlvbi1JRCBpbiB0aGUgRGlhbWV0ZXIgSGVhZGVyIG9m IHRoZQ0KICAgICAgICAgIHJlcXVlc3QgbWF0Y2hlcyB0aGUgdmFsdWUgb2YgdGhlIEFwcGxpY2F0 aW9uLUlEIG9mIHRoZSBEaWFtZXRlcg0KICAgICAgICAgIEhlYWRlciBvZiB0aGUgcmVjZWl2ZWQg bWVzc2FnZSB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC4NCg0KLS0gDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K IFJlcG9ydGVyOiAgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tICB8ICAgICAgT3duZXI6ICBVbHJp Y2ggV2llaGUNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgICAgfCAgICAgU3Rh dHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgICAgIHwgIE1pbGVz dG9uZToNCkNvbXBvbmVudDogIGRyYWZ0LWRvY2R0LWRpbWUtb3ZsaSAgICAgfCAgICBWZXJzaW9u Og0KIFNldmVyaXR5OiAgQWN0aXZlIFdHIERvY3VtZW50ICAgICAgICB8ICAgS2V5d29yZHM6DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvZGlt ZS90cmFjL3RpY2tldC8zND4NCmRpbWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9kaW1lLz4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K From ulrich.wiehe@nsn.com Wed Feb 5 05:57:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1845C1A013C for ; Wed, 5 Feb 2014 05:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv-gSQf5TUFl for ; Wed, 5 Feb 2014 05:57:14 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D64961A0134 for ; Wed, 5 Feb 2014 05:57:13 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s15Dv62A010821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 14:57:06 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s15Dv5ck020002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 14:57:05 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 14:57:05 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 14:57:05 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifEA= Date: Wed, 5 Feb 2014 13:57:04 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6890 X-purgate-ID: 151667::1391608628-000025D0-50FCDA8E/0-0/0-0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 13:57:17 -0000 T2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBP Qy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVl c3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChl dmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS4NCg0KT3RoZXIgY3JpdGVy aWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQoNCkZvciBteSBj bGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVp cmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJl cGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGlu ZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBh bmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/ DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1l LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkN ClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTQ0KVG86IGxpb25lbC5t b3JhbmRAb3JhbmdlLmNvbTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGlt ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0 IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgc2hhcmUgdGhlIHNhbWUg b3BpbmlvbiBhcyBMaW9uZWwuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDA0LCAyMDE0IDk6MDcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Rp bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSB1bmRlcnN0 YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VT IE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28gdGhlIG9wdGlvbnMgd291 bGQgYmU6DQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0gT0MtT25nb2luZy1UaHJv dHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5z d2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBu ZWVkcyB0byBiZSB1cGRhdGVkLg0KDQpJZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRo ZSBvcHRpb24gMSBzZWVtcyB0aGUgYmVzdCBhcHByb2FjaC4NCg0KTGlvbmVsDQoNCi0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJh YytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOpdnJpZXIg MjAxNCAwOTo0OQ0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1lQGlldGYu b3JnDQpPYmpldMKgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN CiMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQogSXQgaGFzIGJlZW4gcHJvcG9z ZWQgdG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0aGF0IGlzICB0 byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0IG1l c3NhZ2VzIHRoYXQgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNh dGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KIChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5n IHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXMNCiBzdXJ2aXZlZCkgaXMgcGVyZm9y bWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyAgdGhy b3R0bGluZyBpcyBwZXJmb3JtZWQuICBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0 aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5l ZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3Qg T0xSLg0KIEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5pc20gd291bGQgcmVzdWx0IGlu IHRoZSBuZWVkIGZvciB0aGUgIHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4g ZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9JQyAgZW5kcG9pbnQgY2Fubm90IGtub3cg d2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyAgdGhl IHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRocm90dGxpbmcvbm90IHRocm90dGxpbmcuDQog VGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1c3RuZXNzIGFzIGl0IGFsbG93cyB0 aGUgcmVwb3J0aW5nIERPSUMgIGVuZHBvaW50IHRvIGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJv cHJpYXRlIHRocm90dGxpbmcgYnkgdGhlIHJlYWN0aW5nICBET0lDIGVuZHBvaW50IChjYXVzZWQg Ynkgd2hhdGV2ZXIgcmVhc29uKS4NCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dz IHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQogSW4gc3VtbWFyeSBpdCBpcyBwcm9w b3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0byAgYmUg dXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLg0KDQot LSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20gIHwgICAg ICBPd25lcjogIFVscmljaCBXaWVoZQ0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAg ICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAg ICAgICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgZHJhZnQtZG9jZHQtZGltZS1vdmxpICAg ICB8ICAgIFZlcnNpb246DQogU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAgICAgIHwg ICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy93Zy9kaW1lL3RyYWMvdGlja2V0LzMxPg0KZGltZSA8aHR0cDovL3Rvb2xzLmlldGYu b3JnL3dnL2RpbWUvPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0 DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp bWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1F IG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaW1lDQo= From srdonovan@usdonovans.com Wed Feb 5 06:29:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860101A017B for ; Wed, 5 Feb 2014 06:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svmhTetuhhfK for ; Wed, 5 Feb 2014 06:29:38 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA551A015B for ; Wed, 5 Feb 2014 06:29:38 -0800 (PST) Received: from [137.254.4.59] (port=20124 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WB3To-0006qQ-T6 for dime@ietf.org; Wed, 05 Feb 2014 06:29:37 -0800 Message-ID: <52F24ACE.6080501@usdonovans.com> Date: Wed, 05 Feb 2014 08:29:34 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dime@ietf.org References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------000401090701060506020005" X-OutGoing-Spam-Status: No, score=-2.9 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 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 14:29:40 -0000 This is a multi-part message in MIME format. --------------000401090701060506020005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit inline On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested). SRD> Why in every answer message? Shouldn't lack of an OLR be interpreted as not overloaded? > > Other criteria like REQ18 or REQ13 do not seem to matter. SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs. > > For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR? SRD> That is the purpose of the sequence number. > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot) > Sent: Wednesday, February 05, 2014 5:27 AM > To: lionel.morand@orange.com; dime@ietf.org > Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > I share the same opinion as Lionel. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > Sent: Tuesday, February 04, 2014 9:07 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. > So the options would be: > 1- OC-OLR AVP in every answer > 2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated. > > If there is no other criterion, the option 1 seems the best approach. > > Lionel > > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoyé : mardi 4 février 2014 09:49 > À : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is to be included by the reacting DOIC endpoint in request messages that survived a throttling. This AVP would indicate the Sequence-Number > (TimeStamp) of the OLR according to which the throttling (which was > survived) is performed. Absence of this AVP indicates that currently no throttling is performed. Reporting DOIC endpoints may use this information in order to detect whether there is a need to update the reacting DOIC endpoint with the latest OLR. > Absence of this feedback mechanism would result in the need for the reporting node to send OC-OLR AVPs in every answer as the reporting DOIC endpoint cannot know whether the reacting DOIC endpoint is actually doing the right thing with regard to throttling/not throttling. > The feedback mechanism improves robustness as it allows the reporting DOIC endpoint to detect and correct inappropriate throttling by the reacting DOIC endpoint (caused by whatever reason). > The feedback mechanism also allows to address REQ 18 from RFC 7068. > In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to be used in request messages that survived a throttling. > --------------000401090701060506020005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit inline
On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).
SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?

Other criteria like REQ18 or REQ13 do not seem to matter.
SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.

For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?
SRD> That is the purpose of the sequence number.  


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
Sent: Wednesday, February 05, 2014 5:27 AM
To: lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

I share the same opinion as Lionel.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 9:07 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 
So the options would be:
1- OC-OLR AVP in every answer
2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.

If there is no other criterion, the option 1 seems the best approach.

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:49
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

 It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number
 (TimeStamp) of the OLR according to which the throttling (which was
 survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.
 Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.
 The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).
 The feedback mechanism also allows to address REQ 18 from RFC 7068.
 In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.

--------------000401090701060506020005-- From srdonovan@usdonovans.com Wed Feb 5 06:33:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643CB1A01AF for ; Wed, 5 Feb 2014 06:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LckpGW9dBQYa for ; Wed, 5 Feb 2014 06:33:46 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 79D801A0180 for ; Wed, 5 Feb 2014 06:33:46 -0800 (PST) Received: from [137.254.4.59] (port=24737 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WB3Xi-0002ba-M8 for dime@ietf.org; Wed, 05 Feb 2014 06:33:45 -0800 Message-ID: <52F24BC0.6070600@usdonovans.com> Date: Wed, 05 Feb 2014 08:33:36 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dime@ietf.org References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060407040009000905020305" X-OutGoing-Spam-Status: No, score=-2.9 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 Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 14:33:48 -0000 This is a multi-part message in MIME format. --------------060407040009000905020305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit How the sequence number is implemented is an implementation decision. There is no reason to mandate that is be an NTP timestamp. That should be included only as one way of addressing the requirement. Steve On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: > I also agree. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > Sent: Tuesday, February 04, 2014 11:50 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR > > The existing wording seems actually fuzzy. > If it is "like an NTP timestamp", be proud and say it loud! > > In summary: ok with the proposal if it clarifies this handling of this sequence-number. > > Lionel > > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoyé : mardi 4 février 2014 09:50 > À : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR > > #32: Sequence-Number Time-Stamp values within OC-OLR > > The -01 draft says in clause 4.4: > From the functionality point of view, the OC-Sequence-Number AVP MUST > be used as a non-volatile increasing counter between two overload > control endpoints (neglecting the fact that the contents of the AVP > is a 64-bit NTP timestamp [RFC5905]). The sequence number is only > required to be unique between two overload control endpoints. > Sequence numbers are treated in uni-directional manner, i.e. two > sequence numbers on each direction between two endpoints are not > related or correlated. > > When generating sequence numbers, the new sequence number MUST be > greater than any sequence number previously seen between two > endpoints within a time window that tolerates the wraparound of the > NTP timestamp (i.e. approximately 68 years). > > > With this mechanism it is difficult to get back to sync once you are out of sync (for whatever reason). > It is proposed to mandate that the Sequence Number is a real 64-bit NTP timestamp (RFC5905) indicating the point in time when the OLR was created, and to mandate that OLRs with a time stamp higher than time of reception must be ignored by the reacting node. > --------------060407040009000905020305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.

Steve
On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
I also agree.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 11:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

The existing wording seems actually fuzzy.
If it is "like an NTP timestamp", be proud and say it loud!

In summary: ok with the proposal if it clarifies this handling of this sequence-number.

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:50
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

#32: Sequence-Number Time-Stamp values within OC-OLR

 The -01 draft says in clause 4.4:
    From the functionality point of view, the OC-Sequence-Number AVP MUST
    be used as a non-volatile increasing counter between two overload
    control endpoints (neglecting the fact that the contents of the AVP
    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
    required to be unique between two overload control endpoints.
    Sequence numbers are treated in uni-directional manner, i.e. two
    sequence numbers on each direction between two endpoints are not
    related or correlated.

    When generating sequence numbers, the new sequence number MUST be
    greater than any sequence number previously seen between two
    endpoints within a time window that tolerates the wraparound of the
    NTP timestamp (i.e. approximately 68 years).


 With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
 It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.

--------------060407040009000905020305-- From srdonovan@usdonovans.com Wed Feb 5 06:56:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE01A0193 for ; Wed, 5 Feb 2014 06:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu01dJKaCgSB for ; Wed, 5 Feb 2014 06:56:28 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 335C41A0186 for ; Wed, 5 Feb 2014 06:56:28 -0800 (PST) Received: from [137.254.4.59] (port=48163 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WB3tj-0002o5-Q2 for dime@ietf.org; Wed, 05 Feb 2014 06:56:27 -0800 Message-ID: <52F25115.9030204@usdonovans.com> Date: Wed, 05 Feb 2014 08:56:21 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dime@ietf.org References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------010906000603070509050702" X-OutGoing-Spam-Status: No, score=-2.9 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 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 14:56:29 -0000 This is a multi-part message in MIME format. --------------010906000603070509050702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request. This implies that it would apply to requests that also have a Destination-Host specified. If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports. I propose that throttling would occur on the realm first and the host second. If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload. Messages to the host that survive realm abatement would then be candidates for host overload. Steve On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: > The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm? > If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host. > > Does it make sense? > > Lionel > > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoyé : mardi 4 février 2014 09:55 > À : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #34: Semantics of OC-Report-Type AVP > > #34: Semantics of OC-Report-Type AVP > > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: > > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > > > > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > --------------010906000603070509050702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

Steve
On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

Does it make sense?

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
Envoyé : mardi 4 février 2014 09:55
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #34: Semantics of OC-Report-Type AVP

#34: Semantics of OC-Report-Type AVP

 Text in clause 4.6  does not fully explain to which requests overload
 treatment of a given report type applies.
 Proposal:

    0  A host report.  The overload treatment should apply to requests
       for which all of the following conditions are true:
       a) The Destination-Host AVP is present in the request and its value
          matches the value of the Origin-Host AVP of the received message
          that contained the OC-OLR AVP.
       b) The value of the Destination-Realm AVP in the request matches the
          value of the Origin-Realm AVP of the received message
          that contained the OC-OLR AVP.
       c) The value of the Application-ID in the Diameter Header of the
          request matches the value of the Application-ID of the Diameter
          Header of the received message that contained the OC-OLR AVP.



    1  A realm report.  The overload treatment should apply to
       requests for which all of the following conditions are true:
       a) The Destination-Host AVP is absent in the request.
       b) The value of the Destination-Realm AVP in the request matches the
          value of the Origin-Realm AVP of the received message
          that contained the OC-OLR AVP.
       c) The value of the Application-ID in the Diameter Header of the
          request matches the value of the Application-ID of the Diameter
          Header of the received message that contained the OC-OLR AVP.

--------------010906000603070509050702-- From lionel.morand@orange.com Wed Feb 5 07:08:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33CB1A016E for ; Wed, 5 Feb 2014 07:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egX-Ety8P7LJ for ; Wed, 5 Feb 2014 07:07:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ECF401A00FD for ; Wed, 5 Feb 2014 07:07:57 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7C44B22C62F; Wed, 5 Feb 2014 16:07:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5C1154C071; Wed, 5 Feb 2014 16:07:56 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 16:07:56 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89Ab1hB/HwnEqAnOHI0lW5YpqlRfYAgADBN4CAAEyiEP//+h+AgAASgdCAAGGYIA== Date: Wed, 5 Feb 2014 15:07:54 +0000 Message-ID: <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:08:02 -0000 Isn't it implicit? An answer is sent to the origin-host of the corresponding request. The agen= t is not the targeting point of the answer and is not supposed to be the re= acting node. Now if an agent wants to act on behalf a client not supporting= the DOCI mechanism at the application, this agent will have to maintain a = binding for this client. This requirement is not bound to the overload cont= rol mechanism but to any function provides by the agent on behalf of downst= ream clients.=20 -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mercredi 5 f=E9vrier 2014 10:32 =C0=A0: ext Nirav Salot (nsalot); MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additional report types are proposed Nirav, ... and this natural requirement is missing from the current draft. To address this requirement we could replace the descriptions for report ty= pes 0 and 1 with the decriptions of my proposed report types 2 and 3 respec= tively. As a consquence, however, the agent in the given example configuration woul= d have to store always OLRs per client even when S wants all clients to do = the same throttling. Would that be acceptable? Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, February 05, 2014 10:03 AM To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Ulrich, I do not think so. If we believe that there should be host-specific OLR and if we want to supp= ort the model when the agent acts as reacting node (on behalf of the client= (s)), then the agents are naturally required to store OLR per client/host b= ehind the agent (based on the destination-host AVP in the answer message). Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, February 05, 2014 2:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Wed Feb 5 07:14:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39B51A01F1 for ; Wed, 5 Feb 2014 07:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7eaaPFQ1FDT for ; Wed, 5 Feb 2014 07:13:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id AA3841A01F0 for ; Wed, 5 Feb 2014 07:13:57 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 781DF3B4539; Wed, 5 Feb 2014 16:13:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 53E1815804E; Wed, 5 Feb 2014 16:13:56 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 16:13:56 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIoJ24+/FEd2zJkuheqQLvDc97ZqmxBJg Date: Wed, 5 Feb 2014 15:13:55 +0000 Message-ID: <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> In-Reply-To: <52F25115.9030204@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E487240PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.4.90915 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:14:02 -0000 --_000_6B7134B31289DC4FAF731D844122B36E487240PEXCVZYM13corpora_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0ZW5kIHRvIGFncmVlIGV4Y2VwdCB0aGF0IEkgd291bGQgcmV2ZXJzZSB0aGUgbG9naWMgYXMg Zm9yIHRoZSByb3V0aW5nIHByaW5jaXBsZXM6IHRoZSBEZXN0aW5hdGlvbi1ob3N0IHRha2VzIHBy ZWNlZGVuY2Ugd2hlbiBwcmVzZW50IG92ZXIgRGVzdGluYXRpb24tUmVhbG0uIFNvIHRoZSByZWFs bSBhYmF0ZW1lbnQgaXMgYXBwbGllZCBpbiBhbnkgY2FzZSBleGNlcHQgaWYgdGhlcmUgaXMgYW4g ZXhwbGljaXQgcmVwb3J0IGZvciB0aGUgZGVzdGluYXRpb24taG9zdC4NCg0KTGlvZW5sDQoNCkRl IDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2 ZSBEb25vdmFuDQpFbnZvecOpIDogbWVyY3JlZGkgNSBmw6l2cmllciAyMDE0IDE1OjU2DQrDgCA6 IGRpbWVAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzM0OiBTZW1hbnRpY3Mg b2YgT0MtUmVwb3J0LVR5cGUgQVZQDQoNCkl0IG1ha2VzIG1vcmUgc2Vuc2UgdG8gbWUgZm9yIGEg cmVhbG0gcmVwb3J0IHRvIGFwcGx5IHRvIGFsbCByZXF1ZXN0cyB0YXJnZXRlZCBmb3IgdGhhdCBy ZWFsbSwgaW5kZXBlbmRlbnQgdGhlIHR5cGUgb2YgcmVxdWVzdC4gIFRoaXMgaW1wbGllcyB0aGF0 IGl0IHdvdWxkIGFwcGx5IHRvIHJlcXVlc3RzIHRoYXQgYWxzbyBoYXZlIGEgRGVzdGluYXRpb24t SG9zdCBzcGVjaWZpZWQuDQoNCklmIHRoaXMgaXMgdGhlIGRlZmluaXRpb24gb2YgYSByZWFsbSBy ZXBvcnQgdGhlbiB3ZSBuZWVkIHRvIHNwZWNpZnkgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gcmVh bG0gcmVwb3J0cyBhbmQgaG9zdCByZXBvcnRzLg0KDQpJIHByb3Bvc2UgdGhhdCB0aHJvdHRsaW5n IHdvdWxkIG9jY3VyIG9uIHRoZSByZWFsbSBmaXJzdCBhbmQgdGhlIGhvc3Qgc2Vjb25kLiAgSWYg YSBtZXNzYWdlIHRhcmdldHRlZCBmb3IgdGhlIGhvc3QgaXMgdGhyb3R0bGVkIGFzIGEgcmVzdWx0 IG9mIHJlYWxtIG92ZXJsb2FkIHRoZW4gdGhhdCB0aHJvdHRsZWQgbWVzc2FnZSB3b3VsZCBjb3Vu dCBhcyBwYXJ0IG9mIHRoZSByZWR1Y3Rpb24gbmVlZGVkIHRvIGFkZHJlc3MgdGhlIGhvc3Qgb3Zl cmxvYWQuICBNZXNzYWdlcyB0byB0aGUgaG9zdCB0aGF0IHN1cnZpdmUgcmVhbG0gYWJhdGVtZW50 IHdvdWxkIHRoZW4gYmUgY2FuZGlkYXRlcyBmb3IgaG9zdCBvdmVybG9hZC4NCg0KU3RldmUNCk9u IDIvNC8xNCAxMToxMiBBTSwgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwu bW9yYW5kQG9yYW5nZS5jb20+IHdyb3RlOg0KDQpUaGUgY2FzZSAiUmVhbG0iIGFzIGRlc2NyaWJl ZCBiZWxvdyByYWlzZXMgYW5vdGhlciBxdWVzdGlvbjogaXMgaXQgcHJvaGliaXRlZCBmb3IgYSBy ZWFsbSB0byBvbmx5IHJlbHkgb24gYSBnbG9iYWwgb3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUgd2hv bGUgcmVhbG0sIHdoYXRldmVyIHRoZSBub2RlcyBpbnNpZGUgdGhpcyByZWFsbT8NCg0KSWYgbm90 LCBvbmx5IE9MUiB3aXRoIHRoZSByZXBvcnQgdHlwZSAicmVhbG0iIHdvdWxkIGJlIHJlY2VpdmVk IGJ5IHRoZSByZWFjdGluZyBub2RlLiBBbmQgdGhlIHJlZHVjdGlvbiBpbmRpY2F0ZWQgaW4gdGhl IE9MUiB3aWxsIGFwcGx5IGFsd2F5cyBmb3IgdGhlIHJlYWxtLCB3aGF0ZXZlciB0aGUgcHJlc2Vu Y2Ugb2YgRGVzdGluYXRpb24taG9zdCBBVlAgaW4gdGhlIHJlcXVlc3QuLi4gZXhjZXB0IGlmIGFu IGV4cGxpY2l0IHJlcG9ydCB3aXRoIHRoZSB0eXBlICJIb3N0IiBhcyBiZWVuIHJlY2VpdmVkIGZv ciB0aGlzIGRlc3RpbmF0aW9uLWhvc3QuDQoNCg0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2U/DQoNCg0K DQpMaW9uZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IGRpbWUg aXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0KDQpF bnZvecOpIDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjU1DQoNCsOAIDogTU9SQU5EIExpb25l bCBJTVQvT0xODQoNCkNjIDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0K T2JqZXQgOiBbZGltZV0gIzM0OiBTZW1hbnRpY3Mgb2YgT0MtUmVwb3J0LVR5cGUgQVZQDQoNCg0K DQojMzQ6IFNlbWFudGljcyBvZiBPQy1SZXBvcnQtVHlwZSBBVlANCg0KDQoNCiBUZXh0IGluIGNs YXVzZSA0LjYgIGRvZXMgbm90IGZ1bGx5IGV4cGxhaW4gdG8gd2hpY2ggcmVxdWVzdHMgb3Zlcmxv YWQNCg0KIHRyZWF0bWVudCBvZiBhIGdpdmVuIHJlcG9ydCB0eXBlIGFwcGxpZXMuDQoNCiBQcm9w b3NhbDoNCg0KDQoNCiAgICAwICBBIGhvc3QgcmVwb3J0LiAgVGhlIG92ZXJsb2FkIHRyZWF0bWVu dCBzaG91bGQgYXBwbHkgdG8gcmVxdWVzdHMNCg0KICAgICAgIGZvciB3aGljaCBhbGwgb2YgdGhl IGZvbGxvd2luZyBjb25kaXRpb25zIGFyZSB0cnVlOg0KDQogICAgICAgYSkgVGhlIERlc3RpbmF0 aW9uLUhvc3QgQVZQIGlzIHByZXNlbnQgaW4gdGhlIHJlcXVlc3QgYW5kIGl0cyB2YWx1ZQ0KDQog ICAgICAgICAgbWF0Y2hlcyB0aGUgdmFsdWUgb2YgdGhlIE9yaWdpbi1Ib3N0IEFWUCBvZiB0aGUg cmVjZWl2ZWQgbWVzc2FnZQ0KDQogICAgICAgICAgdGhhdCBjb250YWluZWQgdGhlIE9DLU9MUiBB VlAuDQoNCiAgICAgICBiKSBUaGUgdmFsdWUgb2YgdGhlIERlc3RpbmF0aW9uLVJlYWxtIEFWUCBp biB0aGUgcmVxdWVzdCBtYXRjaGVzIHRoZQ0KDQogICAgICAgICAgdmFsdWUgb2YgdGhlIE9yaWdp bi1SZWFsbSBBVlAgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UNCg0KICAgICAgICAgIHRoYXQgY29u dGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KDQogICAgICAgYykgVGhlIHZhbHVlIG9mIHRoZSBBcHBs aWNhdGlvbi1JRCBpbiB0aGUgRGlhbWV0ZXIgSGVhZGVyIG9mIHRoZQ0KDQogICAgICAgICAgcmVx dWVzdCBtYXRjaGVzIHRoZSB2YWx1ZSBvZiB0aGUgQXBwbGljYXRpb24tSUQgb2YgdGhlIERpYW1l dGVyDQoNCiAgICAgICAgICBIZWFkZXIgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgdGhhdCBjb250 YWluZWQgdGhlIE9DLU9MUiBBVlAuDQoNCg0KDQoNCg0KDQoNCiAgICAxICBBIHJlYWxtIHJlcG9y dC4gIFRoZSBvdmVybG9hZCB0cmVhdG1lbnQgc2hvdWxkIGFwcGx5IHRvDQoNCiAgICAgICByZXF1 ZXN0cyBmb3Igd2hpY2ggYWxsIG9mIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUgdHJ1ZToN Cg0KICAgICAgIGEpIFRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBpcyBhYnNlbnQgaW4gdGhlIHJl cXVlc3QuDQoNCiAgICAgICBiKSBUaGUgdmFsdWUgb2YgdGhlIERlc3RpbmF0aW9uLVJlYWxtIEFW UCBpbiB0aGUgcmVxdWVzdCBtYXRjaGVzIHRoZQ0KDQogICAgICAgICAgdmFsdWUgb2YgdGhlIE9y aWdpbi1SZWFsbSBBVlAgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UNCg0KICAgICAgICAgIHRoYXQg Y29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KDQogICAgICAgYykgVGhlIHZhbHVlIG9mIHRoZSBB cHBsaWNhdGlvbi1JRCBpbiB0aGUgRGlhbWV0ZXIgSGVhZGVyIG9mIHRoZQ0KDQogICAgICAgICAg cmVxdWVzdCBtYXRjaGVzIHRoZSB2YWx1ZSBvZiB0aGUgQXBwbGljYXRpb24tSUQgb2YgdGhlIERp YW1ldGVyDQoNCiAgICAgICAgICBIZWFkZXIgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgdGhhdCBj b250YWluZWQgdGhlIE9DLU9MUiBBVlAuDQoNCg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_6B7134B31289DC4FAF731D844122B36E487240PEXCVZYM13corpora_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6Ymxh Y2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmZv cm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRN TCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgdGVuZCB0byBhZ3JlZSBleGNlcHQgdGhhdCBJIHdvdWxkIHJldmVy c2UgdGhlIGxvZ2ljIGFzIGZvciB0aGUgcm91dGluZyBwcmluY2lwbGVzOiB0aGUgRGVzdGluYXRp b24taG9zdCB0YWtlcyBwcmVjZWRlbmNlIHdoZW4gcHJlc2VudCBvdmVyIERlc3RpbmF0aW9uLVJl YWxtLg0KIFNvIHRoZSByZWFsbSBhYmF0ZW1lbnQgaXMgYXBwbGllZCBpbiBhbnkgY2FzZSBleGNl cHQgaWYgdGhlcmUgaXMgYW4gZXhwbGljaXQgcmVwb3J0IGZvciB0aGUgZGVzdGluYXRpb24taG9z dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvZW5sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJz cDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij4gRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8 L2I+IFN0ZXZlIERvbm92YW48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgNSBm w6l2cmllciAyMDE0IDE1OjU2PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBkaW1lQGlldGYub3JnPGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzQ6IFNlbWFudGljcyBv ZiBPQy1SZXBvcnQtVHlwZSBBVlA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkl0IG1ha2VzIG1vcmUgc2Vu c2UgdG8gbWUgZm9yIGEgcmVhbG0gcmVwb3J0IHRvIGFwcGx5IHRvIGFsbCByZXF1ZXN0cyB0YXJn ZXRlZCBmb3IgdGhhdCByZWFsbSwgaW5kZXBlbmRlbnQgdGhlIHR5cGUgb2YgcmVxdWVzdC4mbmJz cDsgVGhpcyBpbXBsaWVzIHRoYXQgaXQgd291bGQgYXBwbHkgdG8gcmVxdWVzdHMgdGhhdCBhbHNv IGhhdmUgYSBEZXN0aW5hdGlvbi1Ib3N0DQogc3BlY2lmaWVkLjxicj4NCjxicj4NCklmIHRoaXMg aXMgdGhlIGRlZmluaXRpb24gb2YgYSByZWFsbSByZXBvcnQgdGhlbiB3ZSBuZWVkIHRvIHNwZWNp ZnkgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gcmVhbG0gcmVwb3J0cyBhbmQgaG9zdCByZXBvcnRz Ljxicj4NCjxicj4NCkkgcHJvcG9zZSB0aGF0IHRocm90dGxpbmcgd291bGQgb2NjdXIgb24gdGhl IHJlYWxtIGZpcnN0IGFuZCB0aGUgaG9zdCBzZWNvbmQuJm5ic3A7IElmIGEgbWVzc2FnZSB0YXJn ZXR0ZWQgZm9yIHRoZSBob3N0IGlzIHRocm90dGxlZCBhcyBhIHJlc3VsdCBvZiByZWFsbSBvdmVy bG9hZCB0aGVuIHRoYXQgdGhyb3R0bGVkIG1lc3NhZ2Ugd291bGQgY291bnQgYXMgcGFydCBvZiB0 aGUgcmVkdWN0aW9uIG5lZWRlZCB0byBhZGRyZXNzIHRoZSBob3N0IG92ZXJsb2FkLiZuYnNwOw0K IE1lc3NhZ2VzIHRvIHRoZSBob3N0IHRoYXQgc3Vydml2ZSByZWFsbSBhYmF0ZW1lbnQgd291bGQg dGhlbiBiZSBjYW5kaWRhdGVzIGZvciBob3N0IG92ZXJsb2FkLjxicj4NCjxicj4NClN0ZXZlPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMi80LzE0IDExOjEy IEFNLCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj4NCmxpb25lbC5t b3JhbmRAb3JhbmdlLmNvbTwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy ZT5UaGUgY2FzZSAmcXVvdDtSZWFsbSZxdW90OyBhcyBkZXNjcmliZWQgYmVsb3cgcmFpc2VzIGFu b3RoZXIgcXVlc3Rpb246IGlzIGl0IHByb2hpYml0ZWQgZm9yIGEgcmVhbG0gdG8gb25seSByZWx5 IG9uIGEgZ2xvYmFsIG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIHdob2xlIHJlYWxtLCB3aGF0ZXZl ciB0aGUgbm9kZXMgaW5zaWRlIHRoaXMgcmVhbG0/PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYg bm90LCBvbmx5IE9MUiB3aXRoIHRoZSByZXBvcnQgdHlwZSAmcXVvdDtyZWFsbSZxdW90OyB3b3Vs ZCBiZSByZWNlaXZlZCBieSB0aGUgcmVhY3Rpbmcgbm9kZS4gQW5kIHRoZSByZWR1Y3Rpb24gaW5k aWNhdGVkIGluIHRoZSBPTFIgd2lsbCBhcHBseSBhbHdheXMgZm9yIHRoZSByZWFsbSwgd2hhdGV2 ZXIgdGhlIHByZXNlbmNlIG9mIERlc3RpbmF0aW9uLWhvc3QgQVZQIGluIHRoZSByZXF1ZXN0Li4u IGV4Y2VwdCBpZiBhbiBleHBsaWNpdCByZXBvcnQgd2l0aCB0aGUgdHlwZSAmcXVvdDtIb3N0JnF1 b3Q7IGFzIGJlZW4gcmVjZWl2ZWQgZm9yIHRoaXMgZGVzdGluYXRpb24taG9zdC48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Eb2VzIGl0IG1ha2Ug c2Vuc2U/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+TGlvbmVsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+ RGUmbmJzcDs6IGRpbWUgaXNzdWUgdHJhY2tlciBbPGEgaHJlZj0ibWFpbHRvOnRyYWMmIzQzO2Rp bWVAdHJhYy50b29scy5pZXRmLm9yZyI+bWFpbHRvOnRyYWMmIzQzO2RpbWVAdHJhYy50b29scy5p ZXRmLm9yZzwvYT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkVudm95w6kmbmJzcDs6IG1hcmRp IDQgZsOpdnJpZXIgMjAxNCAwOTo1NTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPsOAJm5ic3A7OiBN T1JBTkQgTGlvbmVsIElNVC9PTE48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYyZuYnNwOzogPGEg aHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3ByZT4NCjxwcmU+T2JqZXQmbmJzcDs6IFtkaW1lXSAjMzQ6IFNlbWFudGljcyBvZiBPQy1SZXBv cnQtVHlwZSBBVlA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT4jMzQ6IFNlbWFudGljcyBvZiBPQy1SZXBvcnQtVHlwZSBBVlA8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gVGV4dCBpbiBjbGF1c2Ug NC42Jm5ic3A7IGRvZXMgbm90IGZ1bGx5IGV4cGxhaW4gdG8gd2hpY2ggcmVxdWVzdHMgb3Zlcmxv YWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gdHJlYXRtZW50IG9mIGEgZ2l2ZW4gcmVwb3J0IHR5 cGUgYXBwbGllcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gUHJvcG9zYWw6PG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7IDAmbmJzcDsgQSBob3N0IHJlcG9ydC4mbmJzcDsgVGhlIG92ZXJsb2FkIHRyZWF0bWVudCBz aG91bGQgYXBwbHkgdG8gcmVxdWVzdHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIHdoaWNoIGFsbCBvZiB0aGUgZm9sbG93aW5n IGNvbmRpdGlvbnMgYXJlIHRydWU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEpIFRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBpcyBw cmVzZW50IGluIHRoZSByZXF1ZXN0IGFuZCBpdHMgdmFsdWU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bWF0Y2hlcyB0aGUgdmFsdWUgb2YgdGhlIE9yaWdpbi1Ib3N0IEFWUCBvZiB0aGUgcmVjZWl2ZWQg bWVzc2FnZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFW UC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYikgVGhlIHZhbHVlIG9mIHRoZSBEZXN0aW5hdGlvbi1SZWFsbSBBVlAgaW4gdGhlIHJl cXVlc3QgbWF0Y2hlcyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsdWUgb2YgdGhlIE9yaWdp bi1SZWFsbSBBVlAgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2U8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhhdCBjb250YWluZWQgdGhlIE9DLU9MUiBBVlAuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGMpIFRoZSB2YWx1ZSBvZiB0aGUgQXBw bGljYXRpb24tSUQgaW4gdGhlIERpYW1ldGVyIEhlYWRlciBvZiB0aGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcmVxdWVzdCBtYXRjaGVzIHRoZSB2YWx1ZSBvZiB0aGUgQXBwbGljYXRpb24tSUQgb2Yg dGhlIERpYW1ldGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hlYWRlciBvZiB0aGUgcmVjZWl2ZWQg bWVzc2FnZSB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsg MSZuYnNwOyBBIHJlYWxtIHJlcG9ydC4mbmJzcDsgVGhlIG92ZXJsb2FkIHRyZWF0bWVudCBzaG91 bGQgYXBwbHkgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcmVxdWVzdHMgZm9yIHdoaWNoIGFsbCBvZiB0aGUgZm9sbG93aW5nIGNv bmRpdGlvbnMgYXJlIHRydWU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEpIFRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBpcyBhYnNl bnQgaW4gdGhlIHJlcXVlc3QuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGIpIFRoZSB2YWx1ZSBvZiB0aGUgRGVzdGluYXRpb24tUmVh bG0gQVZQIGluIHRoZSByZXF1ZXN0IG1hdGNoZXMgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZh bHVlIG9mIHRoZSBPcmlnaW4tUmVhbG0gQVZQIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjKSBUaGUg dmFsdWUgb2YgdGhlIEFwcGxpY2F0aW9uLUlEIGluIHRoZSBEaWFtZXRlciBIZWFkZXIgb2YgdGhl PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3QgbWF0Y2hlcyB0aGUgdmFsdWUgb2YgdGhlIEFw cGxpY2F0aW9uLUlEIG9mIHRoZSBEaWFtZXRlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIZWFkZXIg b2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgdGhhdCBjb250YWluZWQgdGhlIE9DLU9MUiBBVlAuPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_6B7134B31289DC4FAF731D844122B36E487240PEXCVZYM13corpora_-- From lionel.morand@orange.com Wed Feb 5 07:18:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ACD1A0216 for ; Wed, 5 Feb 2014 07:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSKAzkSLTQTf for ; Wed, 5 Feb 2014 07:18:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDDF1A0202 for ; Wed, 5 Feb 2014 07:18:48 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 7F7F73B4109; Wed, 5 Feb 2014 16:18:47 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5FFEB35C06C; Wed, 5 Feb 2014 16:18:47 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 16:18:47 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIcxQ8/v/z65LoEmP8SlQdkHvG5qme77QgABKjdA= Date: Wed, 5 Feb 2014 15:18:46 +0000 Message-ID: <7451_1391613527_52F25657_7451_48_1_6B7134B31289DC4FAF731D844122B36E487279@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2062@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2062@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:18:52 -0000 SGVyZSwgeW91IGFzc3VtZSBib3RoIHR5cGVzIG9mIHJlcG9ydHMgc2VudCBiYWNrIHRvIHRoZSBj bGllbnQuDQpNeSBwb2ludCB3YXM6IGlmIG9ubHkgcmVhbG0tYmFzZWQgcmVwb3J0IGFyZSBzZW50 IHRvIHRoZSBjbGllbnQsIHRoZSBhYmF0ZW1lbnQgd2lsbCBhcHBseSB3aGF0ZXZlciB0aGUgdHlw ZSBvZiByZXF1ZXN0cyBzZW50IHRvIHRoZSByZWFsbSwgd2l0aCBvciB3aXRob3V0IGRlc3RpbmF0 aW9uLWhvc3QuLi4gd2hlcmVhcyBpbiB5b3VyIGRlc2NyaXB0aW9uIGZvciByZWFsbSByZXBvcnQg aXQgd2FzIHNhaWQgdGhhdCB0aGUgZGVzdGluYXRpb24taG9zdCB3YXMgYWJzZW50Lg0KDQpUaGlz IHBvaW50IGlzIGNsYXJpZmllZCBpbiB0aGUgb3RoZXIgbWFpbCwgaW4gcmVzcG9uc2UvY29tcGxl bWVudCB0byBTdGV2ZS4NCg0KTGlvbmVsDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCkRlwqA6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgW21haWx0bzp1bHJpY2gu d2llaGVAbnNuLmNvbV0gDQpFbnZvecOpwqA6IG1lcmNyZWRpIDUgZsOpdnJpZXIgMjAxNCAxMjoz OA0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xOOyBkaW1lQGlldGYub3JnDQpPYmpldMKgOiBS RTogW2RpbWVdICMzNDogU2VtYW50aWNzIG9mIE9DLVJlcG9ydC1UeXBlIEFWUA0KDQpTb3JyeSwg SSBkb24ndCB1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbi4NCg0KQW4gYWdlbnQgdGhhdCBpcyBjb25m aWd1cmVkIHRvIHRha2UgdGhlIHJvbGUgb2YgYSByZXBvcnRpbmcgbm9kZSBmb3IgYSByZWFsbSAN Ci0gd2lsbCBzZW5kIChpbnNlcnQpIHJlYWxtIHR5cGUgT0xScyBpbiBhbnN3ZXIgbWVzc2FnZXMg dGhhdCBjb3JyZXNwb25kIHRvIHJlYWxtIHR5cGUgcmVxdWVzdCBtZXNzYWdlcyAocmVxdWVzdCBt ZXNzYWdlcyB0aGF0IGRvIG5vdCBjb250YWluIGEgZGVzdGluYXRpb24gaG9zdCksIGFuZA0KLSB3 aWxsIGJlIHRyYW5zcGFyZW50IHdpdGggcmVnYXJkIHRvIGhvc3QgdHlwZSByZXF1ZXN0IG1lc3Nh Z2VzIChyZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgY29udGFpbiBhIGRlc3RpbmF0aW9uIGhvc3RhbmQg YW5zd2VyIG1lc3NhZ2VzKSBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgYW5zd2VyIG1lc3NhZ2VzLg0K Q29uc2VxdWVudGx5IHRoZSByZWFjdGluZyBub2RlIHdpbGwgcmVjZWl2ZSByZWFsbSB0eXBlIE9M UnMgZnJvbSB0aGUgYWdlbnQgYW5kIGhvc3QgdHlwZSBPTFJzIGZyb20gdGhlIHNlcnZlcnMuDQpU aGUgcmVjZWl2ZWQgcmVhbG0gdHlwZSBPTFIgd2lsbCBiZSByZWxldmFudCBmb3IgdGhlIHJlYWN0 aW5nIG5vZGUgd2hlbiBzZW5kaW5nL3Rocm90dGxpbmcgcmVhbG0gdHlwZSByZXF1ZXN0czsgdGhl IHJlY2VpdmVkIGhvc3QgdHlwZSBPTFIgd2lsbCBiZSByZWxldmFudCBmb3IgdGhlIHJlYWN0aW5n IG5vZGUgd2hlbiBzZW5kaW5nL3Rocm90dGxpbmcgaG9zdCB0eXBlIHJlcXVlc3RzLg0KDQoNCg0K Ky0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0rDQp8IENsaWVudCB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IEFnZW50ICB8ICAgICAgICAgICAgICAgIHwgU2Vy dmVyIHwNCnwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgfA0KfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAg ICB8ICAgICAgICB8IA0KKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0rDQogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICB8PC0tLURPSUMgYXNzb2NpYXRpb24gMS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0+fDwtLS0tLS0tRE9JQyBhc3NvY2lhdGlvbiAyLS0+fA0KICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgfDwtLS0tLS0tLS0tLS0tLS0tLURPSUMgYXNzb2NpYXRp b24gMy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICB8LS0tMS54eFItLS0tLShyZWFsbSB0eXBlIHJlcXVl c3QpLS0tLS0tLS0tLS0tLS0+fGFnZW50IHNlbGVjdHMgc2VydmVyICAgICAgICAgfA0KICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0y Lnh4Ui0tLS0tLS0tLS0tLS0tLT58IA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0zLnh4QS0tLS0tLS0tLS0tLS0tLS18DQogICAg fDwtLTQueHhBLS0tLS0ocmVhbG0gdHlwZSBPTFIgKS0tLS0tLS0tLS0tLS0tLS0tLXxhZ2VudCBp bnNlcnRzIE9MUiAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8LS0tNS54eFItLS0tLShob3N0IHR5cGUg cmVxdWVzdCktLS0tLS0tLS0tLS0tLS0tfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0K ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8YWdl bnQgaXMgdHJhbnNwYXJlbnQgICAgICAgICB8DQogICAgfDwtLTYueHhBLS0tLS0oaG9zdCB0eXBl IE9MUiktLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwN CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICAgfC0tLTcueHhSLS0ocmVhbG0gdHlwZSByZXF1ZXN0KS0+eCB0aHJvdHRsZWQgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFjY29yZGluZyB0byAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHJlY2VpdmUgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICByZWFsbSB0eXBlIE9MUnwgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgfC0tLTgueHhSLS0oaG9zdCB0eXBlIHJlcXVlc3QpLT54ICB0aHJvdHRsZWQgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFjY29yZGluZyB0byAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHJlY2VpdmUg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBob3N0IHR5cGUgT0xSIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8IA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgbGlvbmVsLm1vcmFuZEBvcmFu Z2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA2OjEzIFBNDQpUbzogZGlt ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzM0OiBTZW1hbnRpY3Mgb2Yg T0MtUmVwb3J0LVR5cGUgQVZQDQoNClRoZSBjYXNlICJSZWFsbSIgYXMgZGVzY3JpYmVkIGJlbG93 IHJhaXNlcyBhbm90aGVyIHF1ZXN0aW9uOiBpcyBpdCBwcm9oaWJpdGVkIGZvciBhIHJlYWxtIHRv IG9ubHkgcmVseSBvbiBhIGdsb2JhbCBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSB3aG9sZSByZWFs bSwgd2hhdGV2ZXIgdGhlIG5vZGVzIGluc2lkZSB0aGlzIHJlYWxtPw0KSWYgbm90LCBvbmx5IE9M UiB3aXRoIHRoZSByZXBvcnQgdHlwZSAicmVhbG0iIHdvdWxkIGJlIHJlY2VpdmVkIGJ5IHRoZSBy ZWFjdGluZyBub2RlLiBBbmQgdGhlIHJlZHVjdGlvbiBpbmRpY2F0ZWQgaW4gdGhlIE9MUiB3aWxs IGFwcGx5IGFsd2F5cyBmb3IgdGhlIHJlYWxtLCB3aGF0ZXZlciB0aGUgcHJlc2VuY2Ugb2YgRGVz dGluYXRpb24taG9zdCBBVlAgaW4gdGhlIHJlcXVlc3QuLi4gZXhjZXB0IGlmIGFuIGV4cGxpY2l0 IHJlcG9ydCB3aXRoIHRoZSB0eXBlICJIb3N0IiBhcyBiZWVuIHJlY2VpdmVkIGZvciB0aGlzIGRl c3RpbmF0aW9uLWhvc3QuDQoNCkRvZXMgaXQgbWFrZSBzZW5zZT8NCg0KTGlvbmVsDQoNCi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86 dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBtYXJkaSA0IGbDqXZy aWVyIDIwMTQgMDk6NTUNCsOAwqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PCoDogZGltZUBp ZXRmLm9yZw0KT2JqZXTCoDogW2RpbWVdICMzNDogU2VtYW50aWNzIG9mIE9DLVJlcG9ydC1UeXBl IEFWUA0KDQojMzQ6IFNlbWFudGljcyBvZiBPQy1SZXBvcnQtVHlwZSBBVlANCg0KIFRleHQgaW4g Y2xhdXNlIDQuNiAgZG9lcyBub3QgZnVsbHkgZXhwbGFpbiB0byB3aGljaCByZXF1ZXN0cyBvdmVy bG9hZA0KIHRyZWF0bWVudCBvZiBhIGdpdmVuIHJlcG9ydCB0eXBlIGFwcGxpZXMuDQogUHJvcG9z YWw6DQoNCiAgICAwICBBIGhvc3QgcmVwb3J0LiAgVGhlIG92ZXJsb2FkIHRyZWF0bWVudCBzaG91 bGQgYXBwbHkgdG8gcmVxdWVzdHMNCiAgICAgICBmb3Igd2hpY2ggYWxsIG9mIHRoZSBmb2xsb3dp bmcgY29uZGl0aW9ucyBhcmUgdHJ1ZToNCiAgICAgICBhKSBUaGUgRGVzdGluYXRpb24tSG9zdCBB VlAgaXMgcHJlc2VudCBpbiB0aGUgcmVxdWVzdCBhbmQgaXRzIHZhbHVlDQogICAgICAgICAgbWF0 Y2hlcyB0aGUgdmFsdWUgb2YgdGhlIE9yaWdpbi1Ib3N0IEFWUCBvZiB0aGUgcmVjZWl2ZWQgbWVz c2FnZQ0KICAgICAgICAgIHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KICAgICAgIGIp IFRoZSB2YWx1ZSBvZiB0aGUgRGVzdGluYXRpb24tUmVhbG0gQVZQIGluIHRoZSByZXF1ZXN0IG1h dGNoZXMgdGhlDQogICAgICAgICAgdmFsdWUgb2YgdGhlIE9yaWdpbi1SZWFsbSBBVlAgb2YgdGhl IHJlY2VpdmVkIG1lc3NhZ2UNCiAgICAgICAgICB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFW UC4NCiAgICAgICBjKSBUaGUgdmFsdWUgb2YgdGhlIEFwcGxpY2F0aW9uLUlEIGluIHRoZSBEaWFt ZXRlciBIZWFkZXIgb2YgdGhlDQogICAgICAgICAgcmVxdWVzdCBtYXRjaGVzIHRoZSB2YWx1ZSBv ZiB0aGUgQXBwbGljYXRpb24tSUQgb2YgdGhlIERpYW1ldGVyDQogICAgICAgICAgSGVhZGVyIG9m IHRoZSByZWNlaXZlZCBtZXNzYWdlIHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KDQoN Cg0KICAgIDEgIEEgcmVhbG0gcmVwb3J0LiAgVGhlIG92ZXJsb2FkIHRyZWF0bWVudCBzaG91bGQg YXBwbHkgdG8NCiAgICAgICByZXF1ZXN0cyBmb3Igd2hpY2ggYWxsIG9mIHRoZSBmb2xsb3dpbmcg Y29uZGl0aW9ucyBhcmUgdHJ1ZToNCiAgICAgICBhKSBUaGUgRGVzdGluYXRpb24tSG9zdCBBVlAg aXMgYWJzZW50IGluIHRoZSByZXF1ZXN0Lg0KICAgICAgIGIpIFRoZSB2YWx1ZSBvZiB0aGUgRGVz dGluYXRpb24tUmVhbG0gQVZQIGluIHRoZSByZXF1ZXN0IG1hdGNoZXMgdGhlDQogICAgICAgICAg dmFsdWUgb2YgdGhlIE9yaWdpbi1SZWFsbSBBVlAgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UNCiAg ICAgICAgICB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC4NCiAgICAgICBjKSBUaGUgdmFs dWUgb2YgdGhlIEFwcGxpY2F0aW9uLUlEIGluIHRoZSBEaWFtZXRlciBIZWFkZXIgb2YgdGhlDQog ICAgICAgICAgcmVxdWVzdCBtYXRjaGVzIHRoZSB2YWx1ZSBvZiB0aGUgQXBwbGljYXRpb24tSUQg b2YgdGhlIERpYW1ldGVyDQogICAgICAgICAgSGVhZGVyIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdl IHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0 ZXI6ICBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20gIHwgICAgICBPd25lcjogIFVscmljaCBXaWVo ZQ0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICB8ICAgICBTdGF0dXM6ICBu ZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICAgfCAgTWlsZXN0b25lOg0K Q29tcG9uZW50OiAgZHJhZnQtZG9jZHQtZGltZS1vdmxpICAgICB8ICAgIFZlcnNpb246DQogU2V2 ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAgICAgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9kaW1lL3RyYWMv dGlja2V0LzM0Pg0KZGltZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUvPg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFu ayB5b3UuCgo= From nsalot@cisco.com Wed Feb 5 07:19:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC371A01FD for ; Wed, 5 Feb 2014 07:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdQFLkPN6xzS for ; Wed, 5 Feb 2014 07:19:36 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 580CD1A01FB for ; Wed, 5 Feb 2014 07:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22862; q=dns/txt; s=iport; t=1391613576; x=1392823176; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=p//24XV/2CqkFGp/igfmDs7YCuzwaEoURJpqiXBvkKo=; b=a79ZTj3dZIwKYvx5mXUE9NLSr36qMomLAoQuIWiN/cJvkUYnarvIIYZY /fyPQrE57SmopfbhZoLRZpCQAdhj5F5fOGJpEEVfbCp5nLEcCbS9sbsqH K4j6QCaI58mMfF5ltVLsDyY1sh1OlT9ep3Pm2iO1icmYgslccKqaShs34 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFACVW8lKtJXHB/2dsb2JhbABZgkhEOFeDAbtDGHYWdIIlAQEBBCMKWAQCAQgOAwQBAQsZBAMCAgIwFAkIAgQBEgiHfa4SoTQXjkQ3AQaCaTWBFASUQo5Gh0SBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208,217";a="302002070" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 05 Feb 2014 15:19:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s15FJZbt029434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 15:19:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 09:19:34 -0600 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bg Date: Wed, 5 Feb 2014 15:19:33 +0000 Message-ID: References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> In-Reply-To: <52F24ACE.6080501@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6432Axmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:19:43 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014D6432Axmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBP TFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KDQpXZSBoYWQgc29tZSBkaXNj dXNzaW9uIHNvbWV0aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhhdCBpdCBpcyByZWFzb25hYmxlIHRv IG5vdCBtYW5kYXRlIHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dl ciBtZXNzYWdlLiBFLmcuIHdoZW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9mIHRyYWNraW5nIHdo YXQgaXMgc2VudCB0byB3aGljaCBjbGllbnQgYW5kIGhlbmNlIHdhbnRzIHRvIGF2b2lkIHNlbmRp bmcgaW5mb3JtYXRpb24gd2hpY2ggaXMgcmVkdW5kYW50LiBCdXQgdGhpcyBpcyBvcHRpb25hbCBp bXBsZW1lbnRhdGlvbiBhbmQgYXQgdGhlIHNhbWUgdGltZSBuZWVkIG5vdCBiZSBwcm9oaWJpdGVk IGZyb20gcHJvdG9jb2wgcG9pbnQgb2Ygdmlldy4NCg0KU28gYmFzaWNhbGx5LCB0aGUgbGFjayBv ZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRo ZSByZWFjdGluZyBub2RlLiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3Qg YmFzZWQgb24gb2xkZXIgT0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlv ZCBvciB3aGVuIHRoZSBleHBsaWNpdCBPTFIgd2l0aCAiMCIgb3ZlcmxvYWQtbWV0cmljIGlzIHJl Y2VpdmVkLg0KSW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0 aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRo ZSByZWFjdGluZyBub2RlLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0 bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50 OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6MDAgUE0NClRvOiBkaW1lQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90 dGxpbmcNCg0KaW5saW5lDQpPbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0g REUvTXVuaWNoKSB3cm90ZToNCg0KT2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBu b2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhh dCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBw b3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVz dGVkKS4NClNSRD4gV2h5IGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlPyAgU2hvdWxkbid0IGxhY2sg b2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCg0KDQoNCg0K T3RoZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIu DQpTUkQ+IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMg ZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRv IGxvb2sgZm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNz YWdlIGlzIGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3Jl IGV4cGVuc2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLg0KDQoNCg0KDQoNCg0KRm9yIG15IGNsYXJp ZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQg dG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5 cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5v ZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBh dCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NClNS RD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoNCg0KDQoN Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxv dCkNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNDQoNClRvOiBs aW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47 IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGlt ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSSBzaGFy ZSB0aGUgc2FtZSBvcGluaW9uIGFzIExpb25lbC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0K DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRp bWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNv bTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPg0KDQpTZW50OiBUdWVzZGF5LCBGZWJy dWFyeSAwNCwgMjAxNCA5OjA3IFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGll dGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl ZCBhIHRocm90dGxpbmcNCg0KDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4g aXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZl cnkgYW5zd2VyLg0KDQpTbyB0aGUgb3B0aW9ucyB3b3VsZCBiZToNCg0KMS0gT0MtT0xSIEFWUCBp biBldmVyeSBhbnN3ZXINCg0KMi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2 ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQg dGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0K DQoNCg0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMg dGhlIGJlc3QgYXBwcm9hY2guDQoNCg0KDQpMaW9uZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KDQpEZSA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0 cmFjLnRvb2xzLmlldGYub3JnXQ0KDQpFbnZvecOpIDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5 OjQ5DQoNCsOAIDogTU9SQU5EIExpb25lbCBJTVQvT0xODQoNCkNjIDogZGltZUBpZXRmLm9yZzxt YWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KT2JqZXQgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2 ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN Cg0KDQoNCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJv dHRsaW5nLUluZm8gQVZQIHRoYXQgaXMgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBE T0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJvdHRs aW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQoNCiAoVGlt ZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hp Y2ggd2FzDQoNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGlu ZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuICBSZXBv cnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRlciB0 byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3Rpbmcg RE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLg0KDQogQWJzZW5jZSBvZiB0aGlzIGZl ZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVwb3J0 aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9y dGluZyBET0lDICBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lD IGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nICB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQg dG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20g aW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDICBlbmRw b2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRo ZSByZWFjdGluZyAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQoN CiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZy b20gUkZDIDcwNjguDQoNCiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUg T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvICBiZSB1c2VkIGluIHJlcXVlc3QgbWVz c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQoNCg0KDQo= --_000_A9CA33BB78081F478946E4F34BF9AAA014D6432Axmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzI0NDA2MSI+SSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAmcXVvdDtz aG91bGRu4oCZdCBsYWNrIG9mIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD8m cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMyNDQwNjEiPldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQg dGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0 byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUg c2VydmVyDQogaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xp ZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlz IHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRo ZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9m IHZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMjQ0MDYxIj5TbyBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90 IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUu IFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBP TFINCiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUg ZXhwbGljaXQgT0xSIHdpdGggJnF1b3Q7MCZxdW90OyBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkluIG15IHZpZXcsIHRoaXMgYWxsb3dz IGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNv dW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFttYWlsdG86ZGltZS1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdGV2ZSBEb25vdmFuPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODowMCBQTTxicj4NCjxi PlRvOjwvYj4gZGltZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtk aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PmlubGluZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIv NS8xNCA3OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+T2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9y dGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2Fn ZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBP Qy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMg cmVxdWVzdGVkKS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U1JEJmd0OyBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/Jm5ic3A7IFNob3Vs ZG4ndCBsYWNrIG9mIGFuIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD88YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T3RoZXIgY3JpdGVyaWEgbGlrZSBSRVEx OCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuPG86cD48L286cD48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNSRCZndDsgUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBpbiBl dmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBhbiBv dmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g QVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdvcmss IHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlDQogdGhhbiBpbnNlcnRpbmcgT0xScy48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Rm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vl c3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVy eSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0 IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8g bWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1l IG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj88bzpwPjwvbzpwPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U1JEJmd0OyBUaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBz ZXF1ZW5jZSBudW1iZXIuJm5ic3A7IDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1l LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC ZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpPG86cD48L286cD48L3ByZT4NCjxwcmU+ U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNPG86cD48L286cD48L3By ZT4NCjxwcmU+VG86IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxp b25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3Jn Ij5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBb RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgc2hhcmUgdGhlIHNh bWUgb3BpbmlvbiBhcyBMaW9uZWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5OaXJhdi48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IERpTUUg WzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3Jh bmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDk6MDcgUE08bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtEaW1lXSBb ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1 ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSB1bmRlcnN0YW5kIHRoYXQgdGhl IHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VTIE5PVCBpbnNlcnQg dGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvIHRoZSBv cHRpb25zIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjEtIE9DLU9MUiBBVlAgaW4g ZXZlcnkgYW5zd2VyPG86cD48L286cD48L3ByZT4NCjxwcmU+Mi0gT0MtT25nb2luZy1UaHJvdHRs aW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgJiM0MzsgT0MtT0xSIEFWUCBpbiBzb21lIGFu c3dlciB3aGVuIHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQg bmVlZHMgdG8gYmUgdXBkYXRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT5JZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRp b24gMSBzZWVtcyB0aGUgYmVzdCBhcHByb2FjaC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5MaW9uZWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EZSZuYnNwOzogZGltZSBpc3N1ZSB0cmFja2VyIFs8YSBo cmVmPSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnIj5tYWlsdG86dHJh YyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5FbnZvecOpJm5ic3A7OiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDk8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT7DgCZuYnNwOzogTU9SQU5EIExpb25lbCBJTVQvT0xOPG86cD48L286cD48L3By ZT4NCjxwcmU+Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9iamV0Jm5ic3A7OiBbZGltZV0gIzMx OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ IEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmct SW5mbyBBVlAgdGhhdCBpcyZuYnNwOyB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9J QyBlbmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQmbmJzcDsgc3Vydml2ZWQgYSB0aHJv dHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyPG86cD48 L286cD48L3ByZT4NCjxwcmU+IChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdo aWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gc3Vy dml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBj dXJyZW50bHkgbm8mbmJzcDsgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuJm5ic3A7IFJlcG9ydGlu ZyBET0lDIGVuZHBvaW50cyBtYXkgdXNlIHRoaXMmbmJzcDsgaW5mb3JtYXRpb24gaW4gb3JkZXIg dG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGUmbmJzcDsgcmVh Y3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBp biB0aGUgbmVlZCBmb3IgdGhlJm5ic3A7IHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFW UHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNwOyBlbmRwb2ludCBj YW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5 IGRvaW5nJm5ic3A7IHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5nL25v dCB0aHJvdHRsaW5nLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBUaGUgZmVlZGJhY2sgbWVjaGFu aXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZu YnNwOyBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRs aW5nIGJ5IHRoZSByZWFjdGluZyZuYnNwOyBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2 ZXIgcmVhc29uKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gVGhlIGZlZWRiYWNrIG1lY2hhbmlz bSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4LjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0Mt T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvJm5ic3A7IGJlIHVzZWQgaW4gcmVxdWVzdCBt ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A9CA33BB78081F478946E4F34BF9AAA014D6432Axmbrcdx10ciscoc_-- From srdonovan@usdonovans.com Wed Feb 5 07:35:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B081A01D1 for ; Wed, 5 Feb 2014 07:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxn90G3-x0Sk for ; Wed, 5 Feb 2014 07:35:25 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 79B361A01B7 for ; Wed, 5 Feb 2014 07:35:22 -0800 (PST) Received: from [137.254.4.59] (port=29326 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WB4VS-0005ka-GF; Wed, 05 Feb 2014 07:35:21 -0800 Message-ID: <52F25A38.2030408@usdonovans.com> Date: Wed, 05 Feb 2014 09:35:20 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "dime@ietf.org" References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060205050302040607040301" X-OutGoing-Spam-Status: No, score=-2.9 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 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:35:29 -0000 This is a multi-part message in MIME format. --------------060205050302040607040301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Agreed. To restate -- lack of an overload report does not change the current overload state for the host or realm. If there is a currently active overload report then it continues to apply until it either times out or is explicitly changed with a new overload report. If there is no currently active overload report then lack of an overload report implies there is no overload for the host and realm. Steve On 2/5/14 9:19 AM, Nirav Salot (nsalot) wrote: > > I agree with Steve except the part "shouldn’t lack of OLR be > interpreted as not overloaded?" > > > > We had some discussion sometime back and thought that it is reasonable > to not mandate the server to include the OLR in every answer message. > E.g. when the server is capable of tracking what is sent to which > client and hence wants to avoid sending information which is > redundant. But this is optional implementation and at the same time > need not be prohibited from protocol point of view. > > > > So basically, the lack of OLR should not affect the previously > received OLR at the reacting node. The reacting node can continue to > react based on older OLR until the expiry of the validity-period or > when the explicit OLR with "0" overload-metric is received. > > In my view, this allows for flexible implementation at the reporting > node and sound handling of OLR at the reacting node. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan > *Sent:* Wednesday, February 05, 2014 8:00 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info > AVP in request messages that survived a throttling > > > > inline > > On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested). > > SRD> Why in every answer message? Shouldn't lack of an OLR be > interpreted as not overloaded? > > > > Other criteria like REQ18 or REQ13 do not seem to matter. > > SRD> Requiring an overload report in every answer does directly break > REQ13, but requiring an overloaded node to look for an > OC-Ongoing-Throttling-Info AVP in every message is also substantial > additional work, potentially more expensive than inserting OLRs. > > > > For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR? > > SRD> That is the purpose of the sequence number. > > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot) > Sent: Wednesday, February 05, 2014 5:27 AM > To: lionel.morand@orange.com ; dime@ietf.org > Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > I share the same opinion as Lionel. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > Sent: Tuesday, February 04, 2014 9:07 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. > So the options would be: > 1- OC-OLR AVP in every answer > 2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated. > > If there is no other criterion, the option 1 seems the best approach. > > Lionel > > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoyé : mardi 4 février 2014 09:49 > À : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling > > It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is to be included by the reacting DOIC endpoint in request messages that survived a throttling. This AVP would indicate the Sequence-Number > (TimeStamp) of the OLR according to which the throttling (which was > survived) is performed. Absence of this AVP indicates that currently no throttling is performed. Reporting DOIC endpoints may use this information in order to detect whether there is a need to update the reacting DOIC endpoint with the latest OLR. > Absence of this feedback mechanism would result in the need for the reporting node to send OC-OLR AVPs in every answer as the reporting DOIC endpoint cannot know whether the reacting DOIC endpoint is actually doing the right thing with regard to throttling/not throttling. > The feedback mechanism improves robustness as it allows the reporting DOIC endpoint to detect and correct inappropriate throttling by the reacting DOIC endpoint (caused by whatever reason). > The feedback mechanism also allows to address REQ 18 from RFC 7068. > In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to be used in request messages that survived a throttling. > > > > --------------060205050302040607040301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Agreed.  To restate -- lack of an overload report does not change the current overload state for the host or realm.  If there is a currently active overload report then it continues to apply until it either times out or is explicitly changed with a new overload report.  If there is no currently active overload report then lack of an overload report implies there is no overload for the host and realm.

Steve
On 2/5/14 9:19 AM, Nirav Salot (nsalot) wrote:

I agree with Steve except the part "shouldn’t lack of OLR be interpreted as not overloaded?"

 

We had some discussion sometime back and thought that it is reasonable to not mandate the server to include the OLR in every answer message. E.g. when the server is capable of tracking what is sent to which client and hence wants to avoid sending information which is redundant. But this is optional implementation and at the same time need not be prohibited from protocol point of view.

 

So basically, the lack of OLR should not affect the previously received OLR at the reacting node. The reacting node can continue to react based on older OLR until the expiry of the validity-period or when the explicit OLR with "0" overload-metric is received.

In my view, this allows for flexible implementation at the reporting node and sound handling of OLR at the reacting node.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, February 05, 2014 8:00 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

 

inline

On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).

SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?

 
 
Other criteria like REQ18 or REQ13 do not seem to matter.

SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.

 
 
For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?

SRD> That is the purpose of the sequence number.  

 
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
Sent: Wednesday, February 05, 2014 5:27 AM
To: lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
I share the same opinion as Lionel.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 9:07 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 
So the options would be:
1- OC-OLR AVP in every answer
2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.
 
If there is no other criterion, the option 1 seems the best approach.
 
Lionel
 
-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:49
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
 It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number
 (TimeStamp) of the OLR according to which the throttling (which was
 survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.
 Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.
 The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).
 The feedback mechanism also allows to address REQ 18 from RFC 7068.
 In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.
 

 


--------------060205050302040607040301-- From lionel.morand@orange.com Wed Feb 5 07:37:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C241A017B for ; Wed, 5 Feb 2014 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyKZDG9p9alp for ; Wed, 5 Feb 2014 07:37:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BF8911A019D for ; Wed, 5 Feb 2014 07:37:05 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9F27A264335; Wed, 5 Feb 2014 16:37:04 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7E932238088; Wed, 5 Feb 2014 16:37:04 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 16:37:04 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR Thread-Index: AQHPIn9JV4bE26Dyt0O0z7brkzIM6ZqmyYww Date: Wed, 5 Feb 2014 15:37:03 +0000 Message-ID: <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> In-Reply-To: <52F24BC0.6070600@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E487344PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:37:09 -0000 --_000_6B7134B31289DC4FAF731D844122B36E487344PEXCVZYM13corpora_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgb3V0LW9mLXN5bmMgZmFpbG92ZXIgZGVzY3JpYmVkIGJ5IFVscmljaCBpcyBh IGdvb2QgdXNlIGNhc2UgdG8gbWFuZGF0ZSBhIHNwZWNpZmljIHNlbWFudGljLg0KDQpJcyB0aGVy ZSBhbnkgc3BlY2lmaWMgTk9UIHRvIG1hbmRhdGUgdGhlIHVzZSBvZiBOVFAgdGltZXN0YW1wcyBp ZiBpdCBpcyBhIHNpbXBsZSB3YXkgdG8gc29sdmUgdGhlIHBvc3NpYmxlIGlzc3VlcyBhbmQgcGxl YXNlIGV2ZXJ5b25lPw0KDQpMaW9uZWwNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVudm95w6kgOiBtZXJjcmVk aSA1IGbDqXZyaWVyIDIwMTQgMTU6MzQNCsOAIDogZGltZUBpZXRmLm9yZw0KT2JqZXQgOiBSZTog W0RpbWVdIFtkaW1lXSAjMzI6IFNlcXVlbmNlLU51bWJlciBUaW1lLVN0YW1wIHZhbHVlcyB3aXRo aW4gT0MtT0xSDQoNCkhvdyB0aGUgc2VxdWVuY2UgbnVtYmVyIGlzIGltcGxlbWVudGVkIGlzIGFu IGltcGxlbWVudGF0aW9uIGRlY2lzaW9uLiAgVGhlcmUgaXMgbm8gcmVhc29uIHRvIG1hbmRhdGUg dGhhdCBpcyBiZSBhbiBOVFAgdGltZXN0YW1wLiAgVGhhdCBzaG91bGQgYmUgaW5jbHVkZWQgb25s eSBhcyBvbmUgd2F5IG9mIGFkZHJlc3NpbmcgdGhlIHJlcXVpcmVtZW50Lg0KDQpTdGV2ZQ0KT24g Mi80LzE0IDEwOjI3IFBNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToNCg0KSSBhbHNvIGFn cmVlLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9y YW5nZS5jb20+DQoNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDExOjUwIFBNDQoN ClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTog W0RpbWVdIFtkaW1lXSAjMzI6IFNlcXVlbmNlLU51bWJlciBUaW1lLVN0YW1wIHZhbHVlcyB3aXRo aW4gT0MtT0xSDQoNCg0KDQpUaGUgZXhpc3Rpbmcgd29yZGluZyBzZWVtcyBhY3R1YWxseSBmdXp6 eS4NCg0KSWYgaXQgaXMgImxpa2UgYW4gTlRQIHRpbWVzdGFtcCIsIGJlIHByb3VkIGFuZCBzYXkg aXQgbG91ZCENCg0KDQoNCkluIHN1bW1hcnk6IG9rIHdpdGggdGhlIHByb3Bvc2FsIGlmIGl0IGNs YXJpZmllcyB0aGlzIGhhbmRsaW5nIG9mIHRoaXMgc2VxdWVuY2UtbnVtYmVyLg0KDQoNCg0KTGlv bmVsDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCg0KRGUgOiBkaW1lIGlzc3Vl IHRyYWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCg0KRW52b3nD qSA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo1MA0KDQrDgCA6IE1PUkFORCBMaW9uZWwgSU1U L09MTg0KDQpDYyA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNCk9iamV0 IDogW2RpbWVdICMzMjogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhpbiBP Qy1PTFINCg0KDQoNCiMzMjogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhp biBPQy1PTFINCg0KDQoNCiBUaGUgLTAxIGRyYWZ0IHNheXMgaW4gY2xhdXNlIDQuNDoNCg0KICAg IEZyb20gdGhlIGZ1bmN0aW9uYWxpdHkgcG9pbnQgb2YgdmlldywgdGhlIE9DLVNlcXVlbmNlLU51 bWJlciBBVlAgTVVTVA0KDQogICAgYmUgdXNlZCBhcyBhIG5vbi12b2xhdGlsZSBpbmNyZWFzaW5n IGNvdW50ZXIgYmV0d2VlbiB0d28gb3ZlcmxvYWQNCg0KICAgIGNvbnRyb2wgZW5kcG9pbnRzIChu ZWdsZWN0aW5nIHRoZSBmYWN0IHRoYXQgdGhlIGNvbnRlbnRzIG9mIHRoZSBBVlANCg0KICAgIGlz IGEgNjQtYml0IE5UUCB0aW1lc3RhbXAgW1JGQzU5MDVdKS4gIFRoZSBzZXF1ZW5jZSBudW1iZXIg aXMgb25seQ0KDQogICAgcmVxdWlyZWQgdG8gYmUgdW5pcXVlIGJldHdlZW4gdHdvIG92ZXJsb2Fk IGNvbnRyb2wgZW5kcG9pbnRzLg0KDQogICAgU2VxdWVuY2UgbnVtYmVycyBhcmUgdHJlYXRlZCBp biB1bmktZGlyZWN0aW9uYWwgbWFubmVyLCBpLmUuIHR3bw0KDQogICAgc2VxdWVuY2UgbnVtYmVy cyBvbiBlYWNoIGRpcmVjdGlvbiBiZXR3ZWVuIHR3byBlbmRwb2ludHMgYXJlIG5vdA0KDQogICAg cmVsYXRlZCBvciBjb3JyZWxhdGVkLg0KDQoNCg0KICAgIFdoZW4gZ2VuZXJhdGluZyBzZXF1ZW5j ZSBudW1iZXJzLCB0aGUgbmV3IHNlcXVlbmNlIG51bWJlciBNVVNUIGJlDQoNCiAgICBncmVhdGVy IHRoYW4gYW55IHNlcXVlbmNlIG51bWJlciBwcmV2aW91c2x5IHNlZW4gYmV0d2VlbiB0d28NCg0K ICAgIGVuZHBvaW50cyB3aXRoaW4gYSB0aW1lIHdpbmRvdyB0aGF0IHRvbGVyYXRlcyB0aGUgd3Jh cGFyb3VuZCBvZiB0aGUNCg0KICAgIE5UUCB0aW1lc3RhbXAgKGkuZS4gYXBwcm94aW1hdGVseSA2 OCB5ZWFycykuDQoNCg0KDQoNCg0KIFdpdGggdGhpcyBtZWNoYW5pc20gaXQgaXMgZGlmZmljdWx0 IHRvIGdldCBiYWNrIHRvIHN5bmMgb25jZSB5b3UgYXJlIG91dCAgb2Ygc3luYyAoZm9yIHdoYXRl dmVyIHJlYXNvbikuDQoNCiBJdCBpcyBwcm9wb3NlZCB0byBtYW5kYXRlIHRoYXQgdGhlIFNlcXVl bmNlIE51bWJlciBpcyBhIHJlYWwgNjQtYml0IE5UUCAgdGltZXN0YW1wIChSRkM1OTA1KSBpbmRp Y2F0aW5nIHRoZSBwb2ludCBpbiB0aW1lIHdoZW4gdGhlIE9MUiB3YXMgY3JlYXRlZCwgIGFuZCB0 byBtYW5kYXRlIHRoYXQgIE9MUnMgd2l0aCBhIHRpbWUgc3RhbXAgaGlnaGVyIHRoYW4gdGltZSBv ZiByZWNlcHRpb24gIG11c3QgYmUgaWdub3JlZCBieSB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KDQoN CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_6B7134B31289DC4FAF731D844122B36E487344PEXCVZYM13corpora_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6Ymxh Y2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmZv cm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRN TCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhlIG91dC1vZi1zeW5jIGZhaWxvdmVyIGRlc2NyaWJl ZCBieSBVbHJpY2ggaXMgYSBnb29kIHVzZSBjYXNlIHRvIG1hbmRhdGUgYSBzcGVjaWZpYyBzZW1h bnRpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgdGhlcmUgYW55IHNw ZWNpZmljIE5PVCB0byBtYW5kYXRlIHRoZSB1c2Ugb2YgTlRQIHRpbWVzdGFtcHMgaWYgaXQgaXMg YSBzaW1wbGUgd2F5IHRvIHNvbHZlIHRoZSBwb3NzaWJsZSBpc3N1ZXMgYW5kIHBsZWFzZSBldmVy eW9uZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5E ZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFy dCBkZTwvYj4gU3RldmUgRG9ub3Zhbjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVk aSA1IGbDqXZyaWVyIDIwMTQgMTU6MzQ8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGRpbWVAaWV0Zi5v cmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMjogU2VxdWVu Y2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhpbiBPQy1PTFI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkhvdyB0aGUgc2VxdWVuY2UgbnVtYmVyIGlzIGltcGxlbWVudGVkIGlzIGFuIGltcGxlbWVu dGF0aW9uIGRlY2lzaW9uLiZuYnNwOyBUaGVyZSBpcyBubyByZWFzb24gdG8gbWFuZGF0ZSB0aGF0 IGlzIGJlIGFuIE5UUCB0aW1lc3RhbXAuJm5ic3A7IFRoYXQgc2hvdWxkIGJlIGluY2x1ZGVkIG9u bHkgYXMgb25lIHdheSBvZiBhZGRyZXNzaW5nIHRoZSByZXF1aXJlbWVudC48YnI+DQo8YnI+DQpT dGV2ZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvNC8x NCAxMDoyNyBQTSwgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT5JIGFsc28gYWdyZWUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5O aXJhdi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206 IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1l LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25l bC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDExOjUwIFBN PG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3Jn Ij5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBb RGltZV0gW2RpbWVdICMzMjogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhp biBPQy1PTFI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT5UaGUgZXhpc3Rpbmcgd29yZGluZyBzZWVtcyBhY3R1YWxseSBmdXp6eS48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5JZiBpdCBpcyAmcXVvdDtsaWtlIGFuIE5UUCB0aW1lc3RhbXAmcXVvdDss IGJlIHByb3VkIGFuZCBzYXkgaXQgbG91ZCE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiBzdW1tYXJ5OiBvayB3aXRoIHRoZSBwcm9wb3NhbCBp ZiBpdCBjbGFyaWZpZXMgdGhpcyBoYW5kbGluZyBvZiB0aGlzIHNlcXVlbmNlLW51bWJlci48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5MaW9uZWw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EZSZuYnNwOzog ZGltZSBpc3N1ZSB0cmFja2VyIFs8YSBocmVmPSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRv b2xzLmlldGYub3JnIj5tYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9h Pl08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5FbnZvecOpJm5ic3A7OiBtYXJkaSA0IGbDqXZyaWVy IDIwMTQgMDk6NTA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7DgCZuYnNwOzogTU9SQU5EIExpb25l bCBJTVQvT0xOPG86cD48L286cD48L3ByZT4NCjxwcmU+Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0 bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pk9iamV0Jm5ic3A7OiBbZGltZV0gIzMyOiBTZXF1ZW5jZS1OdW1iZXIgVGltZS1TdGFtcCB2YWx1 ZXMgd2l0aGluIE9DLU9MUjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPiMzMjogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhp biBPQy1PTFI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT4gVGhlIC0wMSBkcmFmdCBzYXlzIGluIGNsYXVzZSA0LjQ6PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb20gdGhlIGZ1bmN0aW9uYWxpdHkgcG9pbnQgb2Yg dmlldywgdGhlIE9DLVNlcXVlbmNlLU51bWJlciBBVlAgTVVTVDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBiZSB1c2VkIGFzIGEgbm9uLXZvbGF0aWxlIGluY3JlYXNp bmcgY291bnRlciBiZXR3ZWVuIHR3byBvdmVybG9hZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyBjb250cm9sIGVuZHBvaW50cyAobmVnbGVjdGluZyB0aGUgZmFjdCB0 aGF0IHRoZSBjb250ZW50cyBvZiB0aGUgQVZQPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGlzIGEgNjQtYml0IE5UUCB0aW1lc3RhbXAgW1JGQzU5MDVdKS4mbmJzcDsg VGhlIHNlcXVlbmNlIG51bWJlciBpcyBvbmx5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJlcXVpcmVkIHRvIGJlIHVuaXF1ZSBiZXR3ZWVuIHR3byBvdmVybG9hZCBj b250cm9sIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsgU2VxdWVuY2UgbnVtYmVycyBhcmUgdHJlYXRlZCBpbiB1bmktZGlyZWN0aW9uYWwgbWFubmVy LCBpLmUuIHR3bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBzZXF1 ZW5jZSBudW1iZXJzIG9uIGVhY2ggZGlyZWN0aW9uIGJldHdlZW4gdHdvIGVuZHBvaW50cyBhcmUg bm90PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlbGF0ZWQgb3Ig Y29ycmVsYXRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiBnZW5lcmF0aW5nIHNlcXVlbmNlIG51bWJl cnMsIHRoZSBuZXcgc2VxdWVuY2UgbnVtYmVyIE1VU1QgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsgZ3JlYXRlciB0aGFuIGFueSBzZXF1ZW5jZSBudW1iZXIgcHJl dmlvdXNseSBzZWVuIGJldHdlZW4gdHdvPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGVuZHBvaW50cyB3aXRoaW4gYSB0aW1lIHdpbmRvdyB0aGF0IHRvbGVyYXRlcyB0 aGUgd3JhcGFyb3VuZCBvZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsgTlRQIHRpbWVzdGFtcCAoaS5lLiBhcHByb3hpbWF0ZWx5IDY4IHllYXJzKS48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT4gV2l0aCB0aGlzIG1lY2hhbmlzbSBpdCBpcyBkaWZmaWN1bHQg dG8gZ2V0IGJhY2sgdG8gc3luYyBvbmNlIHlvdSBhcmUgb3V0Jm5ic3A7IG9mIHN5bmMgKGZvciB3 aGF0ZXZlciByZWFzb24pLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBJdCBpcyBwcm9wb3NlZCB0 byBtYW5kYXRlIHRoYXQgdGhlIFNlcXVlbmNlIE51bWJlciBpcyBhIHJlYWwgNjQtYml0IE5UUCZu YnNwOyB0aW1lc3RhbXAgKFJGQzU5MDUpIGluZGljYXRpbmcgdGhlIHBvaW50IGluIHRpbWUgd2hl biB0aGUgT0xSIHdhcyBjcmVhdGVkLCZuYnNwOyBhbmQgdG8gbWFuZGF0ZSB0aGF0Jm5ic3A7IE9M UnMgd2l0aCBhIHRpbWUgc3RhbXAgaGlnaGVyIHRoYW4gdGltZSBvZiByZWNlcHRpb24mbmJzcDsg bXVzdCBiZSBpZ25vcmVkIGJ5IHRoZSByZWFjdGluZyBub2RlLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMK cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_6B7134B31289DC4FAF731D844122B36E487344PEXCVZYM13corpora_-- From ulrich.wiehe@nsn.com Wed Feb 5 07:39:44 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090221A01E4 for ; Wed, 5 Feb 2014 07:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb06rdbadFlK for ; Wed, 5 Feb 2014 07:39:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBA21A01AF for ; Wed, 5 Feb 2014 07:39:40 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s15FddMZ008994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 16:39:39 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s15FdciK020280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 16:39:38 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 16:39:38 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 16:39:38 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifECAAAXaAIAAEpmg Date: Wed, 5 Feb 2014 15:39:38 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B21F9@DEMUMBX014.nsn-intra.net> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> In-Reply-To: <52F24ACE.6080501@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6368 X-purgate-ID: 151667::1391614779-00001A6F-F19C8789/0-0/0-0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:39:44 -0000 SW4taW5saW5lDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw NSwgMjAxNCAzOjMwIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBb ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1 ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCmlubGluZQ0KT24gMi81 LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6DQpPayB0 aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1VU1QgaW5zZXJ0IGFuIE9DLU9M UiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJlc3BvbmQgdG8gcmVxdWVzdCBt ZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgKGV2ZW4g d2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLg0KU1JEPiBXaHkgaW4gZXZlcnkg YW5zd2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVk IGFzIG5vdCBvdmVybG9hZGVkPw0KPFVscmljaD5sYWNrIG9mIE9MUiBpbXBsaWVzIGxhY2sgb2Yg c2VxdWVuY2UgbnVtYmVyIGFuZCBsYWNrIG9yIHJlcG9ydCB0eXBlLiBIb3cgd291bGQgdGhlIHJl YWN0aW5nIG5vZGUgY2hlY2sgd2hldGhlciB0aGlzICJpbXBsaWNpdCBubyBvdmVybG9hZCBpbmRp Y2F0aW9uIiBpcyBpbi1zZXF1ZW5jZSBhbmQgd2hldGhlciB0aGUgcmVhbG0gb3IgdGhlIGhvc3Qg aXMgbm90IG92ZXJsb2FkZWQ/IEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgbGFjayBvZiBPTFIg aXMgaW50ZXJwcmV0ZWQgYXMgbm8gY2hhbmdlIGluIHRoZSBvdmVybG9hZDwvVWxyaWNoPg0KDQoN Ck90aGVyIGNyaXRlcmlhIGxpa2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0gdG8gbWF0dGVy Lg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2Vz IGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0 byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVz c2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9y ZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4NCjxVbHJpY2g+dGhlIHByb3Bvc2FsIHdh cyBub3QgInJlcXVpcmluZyIgYnV0ICJhbGxvd2luZyIgdGhlIHJlcG9ydGluZyBub2RlIChlc3Bl Y2lhbGx5IHdoZW4gbm90IG92ZXJsb2FkZWQpIHRvIGNoZWNrIE9DLU9uZ29pbmctVGhyb3R0bGlu Zy1JbmZvIEFWUHMuIDwvVWxyaWNoPg0KDQoNCg0KRm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vl c3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVy eSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0 IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8g bWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1l IG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NClNSRD4gVGhhdCBpcyB0aGUg cHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLsKgIA0KPFVscmljaD4gaG93ZXZlciwgImNo ZWNraW5nIHRoZSBzZXF1ZW5jZSBudW1iZXIiIGFjdHVhbGx5IG1lYW5zICJwcm9jZXNzaW5nIHRo ZSBPTFIiOyAibm90IHByb2Nlc3NpbmcgdGhlIE9MUiIgbWVhbnMgIm5vdCBldmVuIGNoZWNraW5n IHRoZSBzZXF1ZW5jZSBudW1iZXIiPC9VbHJpY2g+DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IGRpbWVA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk IGEgdGhyb3R0bGluZw0KDQpJIHNoYXJlIHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLg0KDQpS ZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1F IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFu ZEBvcmFuZ2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQpU bzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNl cm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4g ZXZlcnkgYW5zd2VyLiANClNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOg0KMS0gT0MtT0xSIEFWUCBp biBldmVyeSBhbnN3ZXINCjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVy eSByZXF1ZXN0ICsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRo cm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4NCg0K SWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJl c3QgYXBwcm9hY2guDQoNCkxpb25lbA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRl wqA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYu b3JnXQ0KRW52b3nDqcKgOiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDkNCsOAwqA6IE1PUkFO RCBMaW9uZWwgSU1UL09MTg0KQ2PCoDogZGltZUBpZXRmLm9yZw0KT2JqZXTCoDogW2RpbWVdICMz MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQojMzE6IFNlbmRpbmcgT0MtT25nb2lu Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh IHRocm90dGxpbmcNCg0KIEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1Pbmdv aW5nLVRocm90dGxpbmctSW5mbyBBVlAgdGhhdCBpcyAgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJl YWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0ICBzdXJ2aXZlZCBh IHRocm90dGxpbmcuIFRoaXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBTZXF1ZW5jZS1OdW1iZXIN CiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGlu ZyAod2hpY2ggd2FzDQogc3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFW UCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm8gIHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLiAg UmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhpcyAgaW5mb3JtYXRpb24gaW4gb3Jk ZXIgdG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGUgIHJlYWN0 aW5nIERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMg ZmVlZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlICByZXBv cnRpbmcgbm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVw b3J0aW5nIERPSUMgIGVuZHBvaW50IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlYWN0aW5nIERP SUMgZW5kcG9pbnQgaXMgYWN0dWFsbHkgZG9pbmcgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2Fy ZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20g aW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDICBlbmRw b2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRo ZSByZWFjdGluZyAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQog VGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9t IFJGQyA3MDY4Lg0KIEluIHN1bW1hcnkgaXQgaXMgcHJvcG9zZWQgdG8gZGVmaW5lIHRoZSBPQy1P bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdG8gIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdl cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4NCg0KDQo= From ben@nostrum.com Wed Feb 5 07:46:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E991A01F1 for ; Wed, 5 Feb 2014 07:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxPBA7Mb1KE1 for ; Wed, 5 Feb 2014 07:46:52 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9582C1A01E7 for ; Wed, 5 Feb 2014 07:46:51 -0800 (PST) Received: from vpn-cust-10-119-24-27.witopia.net (216.6.236.172.rdns.ubiquityservers.com [216.6.236.172] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s15Fkg0G098759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 09:46:48 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ben Campbell In-Reply-To: <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Wed, 5 Feb 2014 09:46:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 216.6.236.172 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:46:54 -0000 I concur with Steve on this one. Using a time stamp is a good way to = meet the requirements, but it's not our job to normatively state an = implementation. In fact, it violates an RFC 2119 "MUST" level = requirement to do so. Section 6 of 2119 includes the following: "In particular, [normative requirements] MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) " The only appropriate reason to require a timestamp would be if we = expected peers to interpret the field as a point in time. OTOH, it would = be perfectly reasonable to state the actual interop requirements, then = add a non-normative (probably indented) paragraph suggesting that a = timestamp is a good way to do this. On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: > I think the out-of-sync failover described by Ulrich is a good use = case to mandate a specific semantic. > =20 > Is there any specific NOT to mandate the use of NTP timestamps if it = is a simple way to solve the possible issues and please everyone? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR > =20 > How the sequence number is implemented is an implementation decision. = There is no reason to mandate that is be an NTP timestamp. That should = be included only as one way of addressing the requirement. >=20 > Steve >=20 > On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: > I also agree. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com > Sent: Tuesday, February 04, 2014 11:50 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR > =20 > The existing wording seems actually fuzzy. > If it is "like an NTP timestamp", be proud and say it loud! > =20 > In summary: ok with the proposal if it clarifies this handling of this = sequence-number. > =20 > Lionel > =20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoy=E9 : mardi 4 f=E9vrier 2014 09:50 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR > =20 > #32: Sequence-Number Time-Stamp values within OC-OLR > =20 > The -01 draft says in clause 4.4: > =46rom the functionality point of view, the OC-Sequence-Number AVP = MUST > be used as a non-volatile increasing counter between two overload > control endpoints (neglecting the fact that the contents of the = AVP > is a 64-bit NTP timestamp [RFC5905]). The sequence number is only > required to be unique between two overload control endpoints. > Sequence numbers are treated in uni-directional manner, i.e. two > sequence numbers on each direction between two endpoints are not > related or correlated. > =20 > When generating sequence numbers, the new sequence number MUST be > greater than any sequence number previously seen between two > endpoints within a time window that tolerates the wraparound of = the > NTP timestamp (i.e. approximately 68 years). > =20 > =20 > With this mechanism it is difficult to get back to sync once you are = out of sync (for whatever reason). > It is proposed to mandate that the Sequence Number is a real 64-bit = NTP timestamp (RFC5905) indicating the point in time when the OLR was = created, and to mandate that OLRs with a time stamp higher than time = of reception must be ignored by the reacting node. > =20 > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Wed Feb 5 07:53:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A161A01F1 for ; Wed, 5 Feb 2014 07:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLwn4sH0Fx1J for ; Wed, 5 Feb 2014 07:53:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id C8F441A01FD for ; Wed, 5 Feb 2014 07:53:45 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 960CC3741A3; Wed, 5 Feb 2014 16:53:44 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6D618158090; Wed, 5 Feb 2014 16:53:44 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 16:53:44 +0100 From: To: Ben Campbell Thread-Topic: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR Thread-Index: AQHPIol0V4bE26Dyt0O0z7brkzIM6ZqmztTw Date: Wed, 5 Feb 2014 15:53:43 +0000 Message-ID: <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> In-Reply-To: <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:53:48 -0000 Not sure to understand: if there is a kind of "interop requirement", it is = a case for a "MUST". We are not violating anything. Reporting and reacting nodes will just rely on the Diameter interfaces to k= now how to handle the received sequence-number. So any MUST on the format o= f the sequence-number is acceptable if it avoids interop issues. -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mercredi 5 f=E9vrier 2014 16:47 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O= C-OLR I concur with Steve on this one. Using a time stamp is a good way to meet t= he requirements, but it's not our job to normatively state an implementatio= n. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Sect= ion 6 of 2119 includes the following: "In particular, [normative requirements] MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) " The only appropriate reason to require a timestamp would be if we expected = peers to interpret the field as a point in time. OTOH, it would be perfectl= y reasonable to state the actual interop requirements, then add a non-norma= tive (probably indented) paragraph suggesting that a timestamp is a good wa= y to do this. On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: > I think the out-of-sync failover described by Ulrich is a good use case t= o mandate a specific semantic. >=20=20 > Is there any specific NOT to mandate the use of NTP timestamps if it is a= simple way to solve the possible issues and please everyone? >=20=20 > Lionel >=20=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O= C-OLR >=20=20 > How the sequence number is implemented is an implementation decision. Th= ere is no reason to mandate that is be an NTP timestamp. That should be in= cluded only as one way of addressing the requirement. >=20 > Steve >=20 > On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: > I also agree. >=20=20 > Regards, > Nirav. >=20=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@oran= ge.com > Sent: Tuesday, February 04, 2014 11:50 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within = OC-OLR >=20=20 > The existing wording seems actually fuzzy. > If it is "like an NTP timestamp", be proud and say it loud! >=20=20 > In summary: ok with the proposal if it clarifies this handling of this se= quence-number. >=20=20 > Lionel >=20=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoy=E9 : mardi 4 f=E9vrier 2014 09:50 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >=20=20 > #32: Sequence-Number Time-Stamp values within OC-OLR >=20=20 > The -01 draft says in clause 4.4: > From the functionality point of view, the OC-Sequence-Number AVP MUST > be used as a non-volatile increasing counter between two overload > control endpoints (neglecting the fact that the contents of the AVP > is a 64-bit NTP timestamp [RFC5905]). The sequence number is only > required to be unique between two overload control endpoints. > Sequence numbers are treated in uni-directional manner, i.e. two > sequence numbers on each direction between two endpoints are not > related or correlated. >=20=20 > When generating sequence numbers, the new sequence number MUST be > greater than any sequence number previously seen between two > endpoints within a time window that tolerates the wraparound of the > NTP timestamp (i.e. approximately 68 years). >=20=20 >=20=20 > With this mechanism it is difficult to get back to sync once you are out= of sync (for whatever reason). > It is proposed to mandate that the Sequence Number is a real 64-bit NTP = timestamp (RFC5905) indicating the point in time when the OLR was created,= and to mandate that OLRs with a time stamp higher than time of reception= must be ignored by the reacting node. >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From ben@nostrum.com Wed Feb 5 07:57:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167E81A0119 for ; Wed, 5 Feb 2014 07:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va_VnNqNoSvh for ; Wed, 5 Feb 2014 07:56:58 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 27FB11A010A for ; Wed, 5 Feb 2014 07:56:58 -0800 (PST) Received: from vpn-cust-10-119-24-27.witopia.net (216.6.236.172.rdns.ubiquityservers.com [216.6.236.172] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s15FupiO099126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 09:56:55 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ben Campbell In-Reply-To: <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Wed, 5 Feb 2014 09:56:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 216.6.236.172 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:57:00 -0000 My point is, we have an interop requirement that the sequence number = always increases over time scope. We do not have the interop requirement = that the sequence number be implemented as a time stamp. A time stamp is = probably a good way to meet the interop requirements, but it is not, in = itself, an interop requirement. On Feb 5, 2014, at 9:53 AM, = wrote: > Not sure to understand: if there is a kind of "interop requirement", = it is a case for a "MUST". > We are not violating anything. >=20 > Reporting and reacting nodes will just rely on the Diameter interfaces = to know how to handle the received sequence-number. So any MUST on the = format of the sequence-number is acceptable if it avoids interop issues. >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47 > =C0 : MORAND Lionel IMT/OLN > Cc : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR >=20 > I concur with Steve on this one. Using a time stamp is a good way to = meet the requirements, but it's not our job to normatively state an = implementation. In fact, it violates an RFC 2119 "MUST" level = requirement to do so. Section 6 of 2119 includes the following: >=20 > "In particular, [normative requirements] MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) " >=20 > The only appropriate reason to require a timestamp would be if we = expected peers to interpret the field as a point in time. OTOH, it would = be perfectly reasonable to state the actual interop requirements, then = add a non-normative (probably indented) paragraph suggesting that a = timestamp is a good way to do this. >=20 > On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: >=20 >> I think the out-of-sync failover described by Ulrich is a good use = case to mandate a specific semantic. >>=20 >> Is there any specific NOT to mandate the use of NTP timestamps if it = is a simple way to solve the possible issues and please everyone? >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR >>=20 >> How the sequence number is implemented is an implementation decision. = There is no reason to mandate that is be an NTP timestamp. That should = be included only as one way of addressing the requirement. >>=20 >> Steve >>=20 >> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: >> I also agree. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com >> Sent: Tuesday, February 04, 2014 11:50 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR >>=20 >> The existing wording seems actually fuzzy. >> If it is "like an NTP timestamp", be proud and say it loud! >>=20 >> In summary: ok with the proposal if it clarifies this handling of = this sequence-number. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] >> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>=20 >> #32: Sequence-Number Time-Stamp values within OC-OLR >>=20 >> The -01 draft says in clause 4.4: >> =46rom the functionality point of view, the OC-Sequence-Number AVP = MUST >> be used as a non-volatile increasing counter between two overload >> control endpoints (neglecting the fact that the contents of the = AVP >> is a 64-bit NTP timestamp [RFC5905]). The sequence number is only >> required to be unique between two overload control endpoints. >> Sequence numbers are treated in uni-directional manner, i.e. two >> sequence numbers on each direction between two endpoints are not >> related or correlated. >>=20 >> When generating sequence numbers, the new sequence number MUST be >> greater than any sequence number previously seen between two >> endpoints within a time window that tolerates the wraparound of = the >> NTP timestamp (i.e. approximately 68 years). >>=20 >>=20 >> With this mechanism it is difficult to get back to sync once you are = out of sync (for whatever reason). >> It is proposed to mandate that the Sequence Number is a real 64-bit = NTP timestamp (RFC5905) indicating the point in time when the OLR was = created, and to mandate that OLRs with a time stamp higher than time = of reception must be ignored by the reacting node. >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Wed Feb 5 08:29:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF46D1A0172 for ; Wed, 5 Feb 2014 08:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8wfYBPTsF92 for ; Wed, 5 Feb 2014 08:29:47 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id ABD8C1A00EE for ; Wed, 5 Feb 2014 08:29:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s15GTjsv007190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 17:29:45 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s15GTi2P017351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 17:29:44 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 17:29:44 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 17:29:43 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUA== Date: Wed, 5 Feb 2014 16:29:43 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2236DEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 28572 X-purgate-ID: 151667::1391617785-000025D0-253AD92C/0-0/0-0 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 16:29:51 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2236DEMUMBX014nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZXR0ZXIgbGlrZSBMaW9uZWzigJlzIGFwcHJvYWNoLCBidXQgZXZlbiB0aGF0IGlzIG5vdCBv ayBpbiB0aGUgdW5saWtlbHkgZXh0cmVtZSBjYXNlIHdoZXJlIHdlIGhhdmUgdHdvIHNlcnZlcnMg aW4gYSByZWFsbSwgUzEgaXMgbm90IG92ZXJsb2FkZWQgYXQgYWxsLCBTMiBpcyA1MCUgb3Zlcmxv YWRlZCwgYW5kIHRoZSBhZ2dyZWdhdGVkIHJlYWxtIG92ZXJsb2FkIGlzIDI1JS4gV2h5IHNob3Vs ZCBhIGNsaWVudCBkbyBhIDI1JSB0aHJvdHRsaW5nIHdoZW4gc2VuZGluZyBob3N0IHR5cGUgcmVx dWVzdHMgdG8gdGhlIG5vdCBhdCBhbGwgb3ZlcmxvYWRlZCBTMT8NCldoYXQgaXMgd3Jvbmcgd2l0 aCBsZXR0aW5nIHRoZSBjbGllbnQNCi1ub3QgdGhyb3R0bGUgaG9zdC10eXBlIHJlcXVlc3RzIHRv IFMxLA0KLXRocm90dGxlIGhvc3QgdHlwZSByZXF1ZXN0IHRvIFMyIHdpdGggNTAlIGFuZA0KLXRo cm90dGxlIHJlYWxtIHR5cGUgcmVxdWVzdHMgd2l0IDI1JT8NCg0KDQoNCkZyb206IERpTUUgW21h aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgbGlvbmVsLm1vcmFu ZEBvcmFuZ2UuY29tDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MTQgUE0N ClRvOiBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtk aW1lXSAjMzQ6IFNlbWFudGljcyBvZiBPQy1SZXBvcnQtVHlwZSBBVlANCg0KSSB0ZW5kIHRvIGFn cmVlIGV4Y2VwdCB0aGF0IEkgd291bGQgcmV2ZXJzZSB0aGUgbG9naWMgYXMgZm9yIHRoZSByb3V0 aW5nIHByaW5jaXBsZXM6IHRoZSBEZXN0aW5hdGlvbi1ob3N0IHRha2VzIHByZWNlZGVuY2Ugd2hl biBwcmVzZW50IG92ZXIgRGVzdGluYXRpb24tUmVhbG0uIFNvIHRoZSByZWFsbSBhYmF0ZW1lbnQg aXMgYXBwbGllZCBpbiBhbnkgY2FzZSBleGNlcHQgaWYgdGhlcmUgaXMgYW4gZXhwbGljaXQgcmVw b3J0IGZvciB0aGUgZGVzdGluYXRpb24taG9zdC4NCg0KTGlvZW5sDQoNCkRlIDogRGlNRSBbbWFp bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2ZSBEb25vdmFuDQpF bnZvecOpIDogbWVyY3JlZGkgNSBmw6l2cmllciAyMDE0IDE1OjU2DQrDgCA6IGRpbWVAaWV0Zi5v cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzNDog U2VtYW50aWNzIG9mIE9DLVJlcG9ydC1UeXBlIEFWUA0KDQpJdCBtYWtlcyBtb3JlIHNlbnNlIHRv IG1lIGZvciBhIHJlYWxtIHJlcG9ydCB0byBhcHBseSB0byBhbGwgcmVxdWVzdHMgdGFyZ2V0ZWQg Zm9yIHRoYXQgcmVhbG0sIGluZGVwZW5kZW50IHRoZSB0eXBlIG9mIHJlcXVlc3QuICBUaGlzIGlt cGxpZXMgdGhhdCBpdCB3b3VsZCBhcHBseSB0byByZXF1ZXN0cyB0aGF0IGFsc28gaGF2ZSBhIERl c3RpbmF0aW9uLUhvc3Qgc3BlY2lmaWVkLg0KDQpJZiB0aGlzIGlzIHRoZSBkZWZpbml0aW9uIG9m IGEgcmVhbG0gcmVwb3J0IHRoZW4gd2UgbmVlZCB0byBzcGVjaWZ5IHRoZSBpbnRlcmFjdGlvbiBi ZXR3ZWVuIHJlYWxtIHJlcG9ydHMgYW5kIGhvc3QgcmVwb3J0cy4NCg0KSSBwcm9wb3NlIHRoYXQg dGhyb3R0bGluZyB3b3VsZCBvY2N1ciBvbiB0aGUgcmVhbG0gZmlyc3QgYW5kIHRoZSBob3N0IHNl Y29uZC4gIElmIGEgbWVzc2FnZSB0YXJnZXR0ZWQgZm9yIHRoZSBob3N0IGlzIHRocm90dGxlZCBh cyBhIHJlc3VsdCBvZiByZWFsbSBvdmVybG9hZCB0aGVuIHRoYXQgdGhyb3R0bGVkIG1lc3NhZ2Ug d291bGQgY291bnQgYXMgcGFydCBvZiB0aGUgcmVkdWN0aW9uIG5lZWRlZCB0byBhZGRyZXNzIHRo ZSBob3N0IG92ZXJsb2FkLiAgTWVzc2FnZXMgdG8gdGhlIGhvc3QgdGhhdCBzdXJ2aXZlIHJlYWxt IGFiYXRlbWVudCB3b3VsZCB0aGVuIGJlIGNhbmRpZGF0ZXMgZm9yIGhvc3Qgb3ZlcmxvYWQuDQoN ClN0ZXZlDQpPbiAyLzQvMTQgMTE6MTIgQU0sIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWls dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiB3cm90ZToNCg0KVGhlIGNhc2UgIlJlYWxtIiBh cyBkZXNjcmliZWQgYmVsb3cgcmFpc2VzIGFub3RoZXIgcXVlc3Rpb246IGlzIGl0IHByb2hpYml0 ZWQgZm9yIGEgcmVhbG0gdG8gb25seSByZWx5IG9uIGEgZ2xvYmFsIG92ZXJsb2FkIHJlcG9ydCBm b3IgdGhlIHdob2xlIHJlYWxtLCB3aGF0ZXZlciB0aGUgbm9kZXMgaW5zaWRlIHRoaXMgcmVhbG0/ DQoNCklmIG5vdCwgb25seSBPTFIgd2l0aCB0aGUgcmVwb3J0IHR5cGUgInJlYWxtIiB3b3VsZCBi ZSByZWNlaXZlZCBieSB0aGUgcmVhY3Rpbmcgbm9kZS4gQW5kIHRoZSByZWR1Y3Rpb24gaW5kaWNh dGVkIGluIHRoZSBPTFIgd2lsbCBhcHBseSBhbHdheXMgZm9yIHRoZSByZWFsbSwgd2hhdGV2ZXIg dGhlIHByZXNlbmNlIG9mIERlc3RpbmF0aW9uLWhvc3QgQVZQIGluIHRoZSByZXF1ZXN0Li4uIGV4 Y2VwdCBpZiBhbiBleHBsaWNpdCByZXBvcnQgd2l0aCB0aGUgdHlwZSAiSG9zdCIgYXMgYmVlbiBy ZWNlaXZlZCBmb3IgdGhpcyBkZXN0aW5hdGlvbi1ob3N0Lg0KDQoNCg0KRG9lcyBpdCBtYWtlIHNl bnNlPw0KDQoNCg0KTGlvbmVsDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCg0K RGUgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRm Lm9yZ10NCg0KRW52b3nDqSA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo1NQ0KDQrDgCA6IE1P UkFORCBMaW9uZWwgSU1UL09MTg0KDQpDYyA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0 Zi5vcmc+DQoNCk9iamV0IDogW2RpbWVdICMzNDogU2VtYW50aWNzIG9mIE9DLVJlcG9ydC1UeXBl IEFWUA0KDQoNCg0KIzM0OiBTZW1hbnRpY3Mgb2YgT0MtUmVwb3J0LVR5cGUgQVZQDQoNCg0KDQog VGV4dCBpbiBjbGF1c2UgNC42ICBkb2VzIG5vdCBmdWxseSBleHBsYWluIHRvIHdoaWNoIHJlcXVl c3RzIG92ZXJsb2FkDQoNCiB0cmVhdG1lbnQgb2YgYSBnaXZlbiByZXBvcnQgdHlwZSBhcHBsaWVz Lg0KDQogUHJvcG9zYWw6DQoNCg0KDQogICAgMCAgQSBob3N0IHJlcG9ydC4gIFRoZSBvdmVybG9h ZCB0cmVhdG1lbnQgc2hvdWxkIGFwcGx5IHRvIHJlcXVlc3RzDQoNCiAgICAgICBmb3Igd2hpY2gg YWxsIG9mIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUgdHJ1ZToNCg0KICAgICAgIGEpIFRo ZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBpcyBwcmVzZW50IGluIHRoZSByZXF1ZXN0IGFuZCBpdHMg dmFsdWUNCg0KICAgICAgICAgIG1hdGNoZXMgdGhlIHZhbHVlIG9mIHRoZSBPcmlnaW4tSG9zdCBB VlAgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UNCg0KICAgICAgICAgIHRoYXQgY29udGFpbmVkIHRo ZSBPQy1PTFIgQVZQLg0KDQogICAgICAgYikgVGhlIHZhbHVlIG9mIHRoZSBEZXN0aW5hdGlvbi1S ZWFsbSBBVlAgaW4gdGhlIHJlcXVlc3QgbWF0Y2hlcyB0aGUNCg0KICAgICAgICAgIHZhbHVlIG9m IHRoZSBPcmlnaW4tUmVhbG0gQVZQIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlDQoNCiAgICAgICAg ICB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC4NCg0KICAgICAgIGMpIFRoZSB2YWx1ZSBv ZiB0aGUgQXBwbGljYXRpb24tSUQgaW4gdGhlIERpYW1ldGVyIEhlYWRlciBvZiB0aGUNCg0KICAg ICAgICAgIHJlcXVlc3QgbWF0Y2hlcyB0aGUgdmFsdWUgb2YgdGhlIEFwcGxpY2F0aW9uLUlEIG9m IHRoZSBEaWFtZXRlcg0KDQogICAgICAgICAgSGVhZGVyIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdl IHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KDQoNCg0KDQoNCg0KDQogICAgMSAgQSBy ZWFsbSByZXBvcnQuICBUaGUgb3ZlcmxvYWQgdHJlYXRtZW50IHNob3VsZCBhcHBseSB0bw0KDQog ICAgICAgcmVxdWVzdHMgZm9yIHdoaWNoIGFsbCBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMg YXJlIHRydWU6DQoNCiAgICAgICBhKSBUaGUgRGVzdGluYXRpb24tSG9zdCBBVlAgaXMgYWJzZW50 IGluIHRoZSByZXF1ZXN0Lg0KDQogICAgICAgYikgVGhlIHZhbHVlIG9mIHRoZSBEZXN0aW5hdGlv bi1SZWFsbSBBVlAgaW4gdGhlIHJlcXVlc3QgbWF0Y2hlcyB0aGUNCg0KICAgICAgICAgIHZhbHVl IG9mIHRoZSBPcmlnaW4tUmVhbG0gQVZQIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlDQoNCiAgICAg ICAgICB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC4NCg0KICAgICAgIGMpIFRoZSB2YWx1 ZSBvZiB0aGUgQXBwbGljYXRpb24tSUQgaW4gdGhlIERpYW1ldGVyIEhlYWRlciBvZiB0aGUNCg0K ICAgICAgICAgIHJlcXVlc3QgbWF0Y2hlcyB0aGUgdmFsdWUgb2YgdGhlIEFwcGxpY2F0aW9uLUlE IG9mIHRoZSBEaWFtZXRlcg0KDQogICAgICAgICAgSGVhZGVyIG9mIHRoZSByZWNlaXZlZCBtZXNz YWdlIHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0K DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg== --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2236DEMUMBX014nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLlByZm9ybWF0SFRNTCwgbGkuUHJmb3JtYXRIVE1M LCBkaXYuUHJmb3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCI7 DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUHJmb3Jt YXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVw dCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgYmV0dGVyIGxpa2UgTGlvbmVs4oCZcyBhcHByb2FjaCwgYnV0IGV2ZW4gdGhhdCBpcyBu b3Qgb2sgaW4gdGhlIHVubGlrZWx5IGV4dHJlbWUgY2FzZSB3aGVyZSB3ZSBoYXZlIHR3byBzZXJ2 ZXJzIGluIGEgcmVhbG0sIFMxIGlzIG5vdCBvdmVybG9hZGVkDQogYXQgYWxsLCBTMiBpcyA1MCUg b3ZlcmxvYWRlZCwgYW5kIHRoZSBhZ2dyZWdhdGVkIHJlYWxtIG92ZXJsb2FkIGlzIDI1JS4gV2h5 IHNob3VsZCBhIGNsaWVudCBkbyBhIDI1JSB0aHJvdHRsaW5nIHdoZW4gc2VuZGluZyBob3N0IHR5 cGUgcmVxdWVzdHMgdG8gdGhlIG5vdCBhdCBhbGwgb3ZlcmxvYWRlZCBTMT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgaXMgd3Jvbmcgd2l0aCBsZXR0aW5n IHRoZSBjbGllbnQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LW5vdCB0aHJvdHRsZSBob3N0LXR5cGUgcmVxdWVzdHMgdG8gUzEsDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi10aHJvdHRsZSBob3N0IHR5cGUgcmVxdWVzdCB0 byBTMiB3aXRoIDUwJSBhbmQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LXRocm90dGxlIHJlYWxtIHR5cGUgcmVxdWVzdHMgd2l0IDI1JT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPmV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA0OjE0IFBNPGJyPg0KPGI+VG86PC9iPiBTdGV2 ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGltZV0g W2RpbWVdICMzNDogU2VtYW50aWNzIG9mIE9DLVJlcG9ydC1UeXBlIEFWUDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0ZW5kIHRvIGFncmVlIGV4Y2VwdCB0 aGF0IEkgd291bGQgcmV2ZXJzZSB0aGUgbG9naWMgYXMgZm9yIHRoZSByb3V0aW5nIHByaW5jaXBs ZXM6IHRoZSBEZXN0aW5hdGlvbi1ob3N0IHRha2VzIHByZWNlZGVuY2Ugd2hlbiBwcmVzZW50IG92 ZXIgRGVzdGluYXRpb24tUmVhbG0uDQogU28gdGhlIHJlYWxtIGFiYXRlbWVudCBpcyBhcHBsaWVk IGluIGFueSBjYXNlIGV4Y2VwdCBpZiB0aGVyZSBpcyBhbiBleHBsaWNpdCByZXBvcnQgZm9yIHRo ZSBkZXN0aW5hdGlvbi1ob3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5M aW9lbmw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1h aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gU3RldmUgRG9ub3Zhbjxicj4NCjxiPkVudm95w6km bmJzcDs6PC9iPiBtZXJjcmVkaSA1IGbDqXZyaWVyIDIwMTQgMTU6NTY8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxi cj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzM0OiBTZW1hbnRpY3Mg b2YgT0MtUmVwb3J0LVR5cGUgQVZQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5JdCBtYWtlcyBtb3JlIHNlbnNlIHRvIG1lIGZvciBhIHJl YWxtIHJlcG9ydCB0byBhcHBseSB0byBhbGwgcmVxdWVzdHMgdGFyZ2V0ZWQgZm9yIHRoYXQgcmVh bG0sIGluZGVwZW5kZW50IHRoZSB0eXBlIG9mIHJlcXVlc3QuJm5ic3A7IFRoaXMgaW1wbGllcyB0 aGF0IGl0IHdvdWxkIGFwcGx5IHRvIHJlcXVlc3RzIHRoYXQgYWxzbyBoYXZlIGENCiBEZXN0aW5h dGlvbi1Ib3N0IHNwZWNpZmllZC48YnI+DQo8YnI+DQpJZiB0aGlzIGlzIHRoZSBkZWZpbml0aW9u IG9mIGEgcmVhbG0gcmVwb3J0IHRoZW4gd2UgbmVlZCB0byBzcGVjaWZ5IHRoZSBpbnRlcmFjdGlv biBiZXR3ZWVuIHJlYWxtIHJlcG9ydHMgYW5kIGhvc3QgcmVwb3J0cy48YnI+DQo8YnI+DQpJIHBy b3Bvc2UgdGhhdCB0aHJvdHRsaW5nIHdvdWxkIG9jY3VyIG9uIHRoZSByZWFsbSBmaXJzdCBhbmQg dGhlIGhvc3Qgc2Vjb25kLiZuYnNwOyBJZiBhIG1lc3NhZ2UgdGFyZ2V0dGVkIGZvciB0aGUgaG9z dCBpcyB0aHJvdHRsZWQgYXMgYSByZXN1bHQgb2YgcmVhbG0gb3ZlcmxvYWQgdGhlbiB0aGF0IHRo cm90dGxlZCBtZXNzYWdlIHdvdWxkIGNvdW50IGFzIHBhcnQgb2YgdGhlIHJlZHVjdGlvbiBuZWVk ZWQgdG8gYWRkcmVzcyB0aGUgaG9zdCBvdmVybG9hZC4mbmJzcDsNCiBNZXNzYWdlcyB0byB0aGUg aG9zdCB0aGF0IHN1cnZpdmUgcmVhbG0gYWJhdGVtZW50IHdvdWxkIHRoZW4gYmUgY2FuZGlkYXRl cyBmb3IgaG9zdCBvdmVybG9hZC48YnI+DQo8YnI+DQpTdGV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+T24gMi80LzE0 IDExOjEyIEFNLCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj4NCmxp b25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoZSBjYXNlICZxdW90O1JlYWxtJnF1b3Q7 IGFzIGRlc2NyaWJlZCBiZWxvdyByYWlzZXMgYW5vdGhlciBxdWVzdGlvbjogaXMgaXQgcHJvaGli aXRlZCBmb3IgYSByZWFsbSB0byBvbmx5IHJlbHkgb24gYSBnbG9iYWwgb3ZlcmxvYWQgcmVwb3J0 IGZvciB0aGUgd2hvbGUgcmVhbG0sIHdoYXRldmVyIHRoZSBub2RlcyBpbnNpZGUgdGhpcyByZWFs bT88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIG5vdCwg b25seSBPTFIgd2l0aCB0aGUgcmVwb3J0IHR5cGUgJnF1b3Q7cmVhbG0mcXVvdDsgd291bGQgYmUg cmVjZWl2ZWQgYnkgdGhlIHJlYWN0aW5nIG5vZGUuIEFuZCB0aGUgcmVkdWN0aW9uIGluZGljYXRl ZCBpbiB0aGUgT0xSIHdpbGwgYXBwbHkgYWx3YXlzIGZvciB0aGUgcmVhbG0sIHdoYXRldmVyIHRo ZSBwcmVzZW5jZSBvZiBEZXN0aW5hdGlvbi1ob3N0IEFWUCBpbiB0aGUgcmVxdWVzdC4uLiBleGNl cHQgaWYgYW4gZXhwbGljaXQgcmVwb3J0IHdpdGggdGhlIHR5cGUgJnF1b3Q7SG9zdCZxdW90OyBh cyBiZWVuIHJlY2VpdmVkIGZvciB0aGlzIGRlc3RpbmF0aW9uLWhvc3QuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRvZXMgaXQgbWFrZSBzZW5zZT88bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TGlvbmVsPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RGUmbmJzcDs6IGRpbWUg aXNzdWUgdHJhY2tlciBbPGEgaHJlZj0ibWFpbHRvOnRyYWMmIzQzO2RpbWVAdHJhYy50b29scy5p ZXRmLm9yZyI+bWFpbHRvOnRyYWMmIzQzO2RpbWVAdHJhYy50b29scy5pZXRmLm9yZzwvYT5dIDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RW52b3nDqSZuYnNw OzogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjU1PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj7DgCZuYnNwOzogTU9SQU5EIExpb25lbCBJTVQvT0xOPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DYyZuYnNwOzogPGEgaHJl Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PYmpldCZuYnNwOzogW2RpbWVdICMzNDog U2VtYW50aWNzIG9mIE9DLVJlcG9ydC1UeXBlIEFWUDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkZSIj4jMzQ6IFNlbWFudGljcyBvZiBPQy1SZXBvcnQtVHlwZSBBVlA8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+IFRleHQgaW4gY2xhdXNlIDQu NiZuYnNwOyBkb2VzIG5vdCBmdWxseSBleHBsYWluIHRvIHdoaWNoIHJlcXVlc3RzIG92ZXJsb2Fk PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gdHJlYXRtZW50 IG9mIGEgZ2l2ZW4gcmVwb3J0IHR5cGUgYXBwbGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBQcm9wb3NhbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsgQSBob3N0IHJlcG9y dC4mbmJzcDsgVGhlIG92ZXJsb2FkIHRyZWF0bWVudCBzaG91bGQgYXBwbHkgdG8gcmVxdWVzdHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3Igd2hpY2ggYWxsIG9mIHRoZSBmb2xsb3dpbmcg Y29uZGl0aW9ucyBhcmUgdHJ1ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhKSBUaGUgRGVz dGluYXRpb24tSG9zdCBBVlAgaXMgcHJlc2VudCBpbiB0aGUgcmVxdWVzdCBhbmQgaXRzIHZhbHVl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWF0Y2hlcyB0aGUg dmFsdWUgb2YgdGhlIE9yaWdpbi1Ib3N0IEFWUCBvZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgY29udGFpbmVkIHRo ZSBPQy1PTFIgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGIpIFRoZSB2YWx1ZSBvZiB0 aGUgRGVzdGluYXRpb24tUmVhbG0gQVZQIGluIHRoZSByZXF1ZXN0IG1hdGNoZXMgdGhlPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsdWUgb2YgdGhlIE9yaWdp bi1SZWFsbSBBVlAgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjKSBUaGUgdmFsdWUgb2YgdGhlIEFwcGxpY2F0aW9uLUlE IGluIHRoZSBEaWFtZXRlciBIZWFkZXIgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVzdCBtYXRjaGVzIHRoZSB2YWx1ZSBvZiB0aGUgQXBwbGlj YXRpb24tSUQgb2YgdGhlIERpYW1ldGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7SGVhZGVyIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlIHRoYXQgY29udGFpbmVk IHRoZSBPQy1PTFIgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDEmbmJzcDsgQSByZWFsbSByZXBvcnQuJm5ic3A7IFRoZSBvdmVybG9hZCB0 cmVhdG1lbnQgc2hvdWxkIGFwcGx5IHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVz dHMgZm9yIHdoaWNoIGFsbCBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIHRydWU6PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSkgVGhlIERlc3RpbmF0aW9uLUhvc3QgQVZQIGlzIGFi c2VudCBpbiB0aGUgcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiKSBUaGUgdmFs dWUgb2YgdGhlIERlc3RpbmF0aW9uLVJlYWxtIEFWUCBpbiB0aGUgcmVxdWVzdCBtYXRjaGVzIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlIG9mIHRo ZSBPcmlnaW4tUmVhbG0gQVZQIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBjb250YWluZWQgdGhlIE9DLU9MUiBB VlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYykgVGhlIHZhbHVlIG9mIHRoZSBBcHBsaWNh dGlvbi1JRCBpbiB0aGUgRGlhbWV0ZXIgSGVhZGVyIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3QgbWF0Y2hlcyB0aGUgdmFsdWUgb2YgdGhl IEFwcGxpY2F0aW9uLUlEIG9mIHRoZSBEaWFtZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhlYWRlciBvZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZSB0aGF0IGNv bnRhaW5lZCB0aGUgT0MtT0xSIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3Uu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2236DEMUMBX014nsnin_-- From ulrich.wiehe@nsn.com Wed Feb 5 08:42:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48DD1A001A for ; Wed, 5 Feb 2014 08:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQkIS29RxPBs for ; Wed, 5 Feb 2014 08:42:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DBB2C1A0013 for ; Wed, 5 Feb 2014 08:42:43 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s15GgdRX028302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 17:42:39 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s15GgdpB010670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 17:42:39 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 17:42:38 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 17:42:38 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "ext Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89Ab1hB/HwnEqAnOHI0lW5YpqlRfYAgADBN4CAAEyiEP//+h+AgAASgdCAAGGYIIAAHGQA Date: Wed, 5 Feb 2014 16:42:38 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2254@DEMUMBX014.nsn-intra.net> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12351 X-purgate-ID: 151667::1391618559-000025D0-79F41FE5/0-0/0-0 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 16:42:50 -0000 Even if some feel this is implicit, it should not harm to add the d) condit= ion explicitly please. -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Wednesday, February 05, 2014 4:08 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed Isn't it implicit? An answer is sent to the origin-host of the corresponding request. The agen= t is not the targeting point of the answer and is not supposed to be the re= acting node. Now if an agent wants to act on behalf a client not supporting= the DOCI mechanism at the application, this agent will have to maintain a = binding for this client. This requirement is not bound to the overload cont= rol mechanism but to any function provides by the agent on behalf of downst= ream clients.=20 -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mercredi 5 f=E9vrier 2014 10:32 =C0=A0: ext Nirav Salot (nsalot); MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additional report types are proposed Nirav, ... and this natural requirement is missing from the current draft. To address this requirement we could replace the descriptions for report ty= pes 0 and 1 with the decriptions of my proposed report types 2 and 3 respec= tively. As a consquence, however, the agent in the given example configuration woul= d have to store always OLRs per client even when S wants all clients to do = the same throttling. Would that be acceptable? Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, February 05, 2014 10:03 AM To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com; dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed Ulrich, I do not think so. If we believe that there should be host-specific OLR and if we want to supp= ort the model when the agent acts as reacting node (on behalf of the client= (s)), then the agents are naturally required to store OLR per client/host b= ehind the agent (based on the destination-host AVP in the answer message). Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, February 05, 2014 2:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Wed Feb 5 08:54:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABA31A0159 for ; Wed, 5 Feb 2014 08:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxpwkDj_9Z54 for ; Wed, 5 Feb 2014 08:54:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id AE4EF1A014E for ; Wed, 5 Feb 2014 08:54:32 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id DAF8A190586; Wed, 5 Feb 2014 17:54:30 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BC312384055; Wed, 5 Feb 2014 17:54:30 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 17:54:30 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89Ab1hB/HwnEqAnOHI0lW5YpqlRfYAgADBN4CAAEyiEP//+h+AgAASgdCAAGGYIIAAHGQAgAABq+A= Date: Wed, 5 Feb 2014 16:54:30 +0000 Message-ID: <18813_1391619270_52F26CC6_18813_5166_1_6B7134B31289DC4FAF731D844122B36E487640@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2254@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2254@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.4.90915 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 16:54:36 -0000 If I'm correct, the following condition: d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. is not correct as the message containing the OC-OLR AVP is an answer and th= ere is Destination-Host or Destination-Realm AVPs in an answer. If you want to clarify something, it can be in the section describing the a= gent behavior. And such clarification will be that when an agent received a= n OLR in response to a request initiated by a client not supporting DOIC, t= his agent needs to bind the received OLR to the origin-host of the client (= no need of the origin-realm). Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mercredi 5 f=E9vrier 2014 17:43 =C0=A0: MORAND Lionel IMT/OLN; ext Nirav Salot (nsalot); dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additional report types are proposed Even if some feel this is implicit, it should not harm to add the d) condit= ion explicitly please. -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Wednesday, February 05, 2014 4:08 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Isn't it implicit? An answer is sent to the origin-host of the corresponding request. The agen= t is not the targeting point of the answer and is not supposed to be the re= acting node. Now if an agent wants to act on behalf a client not supporting= the DOCI mechanism at the application, this agent will have to maintain a = binding for this client. This requirement is not bound to the overload cont= rol mechanism but to any function provides by the agent on behalf of downst= ream clients.=20 -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mercredi 5 f=E9vrier 2014 10:32 =C0=A0: ext Nirav Salot (nsalot); MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additional report types are proposed Nirav, ... and this natural requirement is missing from the current draft. To address this requirement we could replace the descriptions for report ty= pes 0 and 1 with the decriptions of my proposed report types 2 and 3 respec= tively. As a consquence, however, the agent in the given example configuration woul= d have to store always OLRs per client even when S wants all clients to do = the same throttling. Would that be acceptable? Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, February 05, 2014 10:03 AM To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Ulrich, I do not think so. If we believe that there should be host-specific OLR and if we want to supp= ort the model when the agent acts as reacting node (on behalf of the client= (s)), then the agents are naturally required to store OLR per client/host b= ehind the agent (based on the destination-host AVP in the answer message). Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, February 05, 2014 2:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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. From lionel.morand@orange.com Wed Feb 5 09:09:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEE61A00F7 for ; Wed, 5 Feb 2014 09:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGbB7aZryhO1 for ; Wed, 5 Feb 2014 09:09:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E539C1A0122 for ; Wed, 5 Feb 2014 09:09:39 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 76A6A22C3EB; Wed, 5 Feb 2014 18:09:38 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5AC684C07C; Wed, 5 Feb 2014 18:09:38 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 18:09:38 +0100 From: To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "srdonovan@usdonovans.com" Thread-Topic: [Dime] [dime] #28: Report type support in capabilities? Thread-Index: AQHPHtINDyLLtzyX8k6tlE6/3O5WMZqm5Qaw Date: Wed, 5 Feb 2014 17:09:37 +0000 Message-ID: <26607_1391620178_52F27052_26607_6697_1_6B7134B31289DC4FAF731D844122B36E4876CC@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org> In-Reply-To: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.5.114814 Subject: Re: [Dime] [dime] #28: Report type support in capabilities? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 17:09:42 -0000 The default mechanism implies that a client will be able to manage both typ= es of report. Therefore there is no need at this stage IMHO. In future, if there is a need to explicitly indicate which report type a no= de support, it may be a hint for defining different capabilities/algos. And= this new capability will be described a new companion document. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: vendredi 31 janvier 2014 23:16 =C0=A0: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com Cc=A0: dime@ietf.org Objet=A0: [Dime] [dime] #28: Report type support in capabilities? #28: Report type support in capabilities? This applies to draft-ietf-dime-ovli This is more of a question than an issue. We currently only include the abatement algorithm in the OC-Feature-Vector AVP. The question is whether we should expand it to include support for the host(server) report and realm report. The reason for the question is that the agent overload extension will likely include an indicator in the OC-Feature-Vector of support for the peer report type. --=20 -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Submitted WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From ulrich.wiehe@nsn.com Wed Feb 5 09:26:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C95C1A0199 for ; Wed, 5 Feb 2014 09:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScHaml0wDAtE for ; Wed, 5 Feb 2014 09:25:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id BAD641A016B for ; Wed, 5 Feb 2014 09:25:56 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s15HPq41030094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 18:25:52 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s15HPqtI012146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 18:25:52 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Feb 2014 18:25:51 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 18:25:51 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "ext Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89Ab1hB/HwnEqAnOHI0lW5YpqlRfYAgADBN4CAAEyiEP//+h+AgAASgdCAAGGYIIAAHGQAgAABq+CAAAQJYA== Date: Wed, 5 Feb 2014 17:25:50 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B228F@DEMUMBX014.nsn-intra.net> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2254@DEMUMBX014.nsn-intra.net> <18813_1391619270_52F26CC6_18813_5166_1_6B7134B31289DC4FAF731D844122B36E487640@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <18813_1391619270_52F26CC6_18813_5166_1_6B7134B31289DC4FAF731D844122B36E487640@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 15072 X-purgate-ID: 151667::1391621152-00001A6F-BBB35D19/0-0/0-0 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 17:26:01 -0000 Thank you for your proposal. Let's agree on the clarification in the sectio= n describing agent behavior:=20 When an agent received an OLR in response to a request initiated by a clien= t not supporting DOIC, this agent needs to bind the received OLR to the ori= gin-host of the client. Ulrich -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Wednesday, February 05, 2014 5:55 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed If I'm correct, the following condition: d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. is not correct as the message containing the OC-OLR AVP is an answer and th= ere is Destination-Host or Destination-Realm AVPs in an answer. If you want to clarify something, it can be in the section describing the a= gent behavior. And such clarification will be that when an agent received a= n OLR in response to a request initiated by a client not supporting DOIC, t= his agent needs to bind the received OLR to the origin-host of the client (= no need of the origin-realm). Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mercredi 5 f=E9vrier 2014 17:43 =C0=A0: MORAND Lionel IMT/OLN; ext Nirav Salot (nsalot); dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additional report types are proposed Even if some feel this is implicit, it should not harm to add the d) condit= ion explicitly please. -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Wednesday, February 05, 2014 4:08 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed Isn't it implicit? An answer is sent to the origin-host of the corresponding request. The agen= t is not the targeting point of the answer and is not supposed to be the re= acting node. Now if an agent wants to act on behalf a client not supporting= the DOCI mechanism at the application, this agent will have to maintain a = binding for this client. This requirement is not bound to the overload cont= rol mechanism but to any function provides by the agent on behalf of downst= ream clients.=20 -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mercredi 5 f=E9vrier 2014 10:32 =C0=A0: ext Nirav Salot (nsalot); MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additional report types are proposed Nirav, ... and this natural requirement is missing from the current draft. To address this requirement we could replace the descriptions for report ty= pes 0 and 1 with the decriptions of my proposed report types 2 and 3 respec= tively. As a consquence, however, the agent in the given example configuration woul= d have to store always OLRs per client even when S wants all clients to do = the same throttling. Would that be acceptable? Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, February 05, 2014 10:03 AM To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com; dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed Ulrich, I do not think so. If we believe that there should be host-specific OLR and if we want to supp= ort the model when the agent acts as reacting node (on behalf of the client= (s)), then the agents are naturally required to store OLR per client/host b= ehind the agent (based on the destination-host AVP in the answer message). Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, February 05, 2014 2:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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. From ulrich.wiehe@nsn.com Thu Feb 6 00:53:15 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9E81A01FB for ; Thu, 6 Feb 2014 00:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kg9Qd5FG0x9 for ; Thu, 6 Feb 2014 00:53:12 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9C11A018E for ; Thu, 6 Feb 2014 00:53:11 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s168r7Bv016411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 09:53:07 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s168r6tF019369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 09:53:06 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:53:06 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifECAAAXaAIAADfeAgAAEaQCAASwPUA== Date: Thu, 6 Feb 2014 08:53:05 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> In-Reply-To: <52F25A38.2030408@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8650 X-purgate-ID: 151667::1391676787-000025D0-C577FC85/0-0/0-0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 08:53:15 -0000 QWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxlczoNCjEuIExhY2sgb2Yg T0xSIG1lYW5zICJubyBjaGFuZ2UiDQoyLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3 aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xS IGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQt RmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5 IGhhcyBnb3QgdGhlIGxhdGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0 cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiKTsgb3Ro ZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChu byBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGlu IHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZl YXR1cmUgQVZQLg0KDQpDYW4gcGVvcGxlIHBsZWFzZSBjb25maXJtLg0KDQpVbHJpY2gNCg0KRnJv bTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBT dGV2ZSBEb25vdmFuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE0N ClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtE aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkFncmVlZC7C oCBUbyByZXN0YXRlIC0tIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGRvZXMgbm90IGNoYW5n ZSB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhvc3Qgb3IgcmVhbG0uwqAgSWYg dGhlcmUgaXMgYSBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IGNvbnRp bnVlcyB0byBhcHBseSB1bnRpbCBpdCBlaXRoZXIgdGltZXMgb3V0IG9yIGlzIGV4cGxpY2l0bHkg Y2hhbmdlZCB3aXRoIGEgbmV3IG92ZXJsb2FkIHJlcG9ydC7CoCBJZiB0aGVyZSBpcyBubyBjdXJy ZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVw b3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS4N Cg0KU3RldmUNCk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToN CkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQgInNob3VsZG7igJl0IGxhY2sgb2Yg T0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPyINCsKgDQpXZSBoYWQgc29tZSBk aXNjdXNzaW9uIHNvbWV0aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhhdCBpdCBpcyByZWFzb25hYmxl IHRvIG5vdCBtYW5kYXRlIHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFu c3dlciBtZXNzYWdlLiBFLmcuIHdoZW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9mIHRyYWNraW5n IHdoYXQgaXMgc2VudCB0byB3aGljaCBjbGllbnQgYW5kIGhlbmNlIHdhbnRzIHRvIGF2b2lkIHNl bmRpbmcgaW5mb3JtYXRpb24gd2hpY2ggaXMgcmVkdW5kYW50LiBCdXQgdGhpcyBpcyBvcHRpb25h bCBpbXBsZW1lbnRhdGlvbiBhbmQgYXQgdGhlIHNhbWUgdGltZSBuZWVkIG5vdCBiZSBwcm9oaWJp dGVkIGZyb20gcHJvdG9jb2wgcG9pbnQgb2Ygdmlldy4NCsKgDQpTbyBiYXNpY2FsbHksIHRoZSBs YWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIg YXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byBy ZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHkt cGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBvdmVybG9hZC1tZXRyaWMg aXMgcmVjZWl2ZWQuDQpJbiBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3IgZmxleGlibGUgaW1wbGVt ZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBoYW5kbGluZyBvZiBPTFIg YXQgdGhlIHJlYWN0aW5nIG5vZGUuDQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCkZyb206IERp TUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25v dmFuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6MDAgUE0NClRvOiBkaW1l QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl ZCBhIHRocm90dGxpbmcNCsKgDQppbmxpbmUNCk9uIDIvNS8xNCA3OjU3IEFNLCBXaWVoZSwgVWxy aWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOg0KT2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJl cG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVz c2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBh biBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24g aXMgcmVxdWVzdGVkKS4NClNSRD4gV2h5IGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlP8KgIFNob3Vs ZG4ndCBsYWNrIG9mIGFuIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD8NCg0K DQrCoA0KwqANCk90aGVyIGNyaXRlcmlhIGxpa2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0g dG8gbWF0dGVyLg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFu c3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFuIG92ZXJsb2Fk ZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g ZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29yaywgcG90ZW50 aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4NCg0KDQrCoA0KwqANCkZv ciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90 IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxs IGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSBy ZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQg T0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5l dyBPTFI/DQpTUkQ+IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJlci7C oCANCg0KDQrCoA0KwqANCsKgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlN RSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBOaXJhdiBT YWxvdCAobnNhbG90KQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFN DQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQpJ IHNoYXJlIHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLg0KwqANClJlZ2FyZHMsDQpOaXJhdi4N CsKgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0K U2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTQ0KVG86IGRpbWVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy b3R0bGluZw0KwqANCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0 aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2Vy LiANClNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOg0KMS0gT0MtT0xSIEFWUCBpbiBldmVyeSBhbnN3 ZXINCjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICsg T0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVy Zm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4NCsKgDQpJZiB0aGVyZSBp cyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0aGUgYmVzdCBhcHByb2Fj aC4NCsKgDQpMaW9uZWwNCsKgDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IGRp bWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0K RW52b3nDqcKgOiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDkNCsOAwqA6IE1PUkFORCBMaW9u ZWwgSU1UL09MTg0KQ2PCoDogZGltZUBpZXRmLm9yZw0KT2JqZXTCoDogW2RpbWVdICMzMTogU2Vu ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0 aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCiMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy b3R0bGluZw0KwqANCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2lu Zy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXPCoCB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVh Y3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXTCoCBzdXJ2aXZlZCBh IHRocm90dGxpbmcuIFRoaXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBTZXF1ZW5jZS1OdW1iZXIN CiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGlu ZyAod2hpY2ggd2FzDQogc3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFW UCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm/CoCB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC7C oCBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzwqAgaW5mb3JtYXRpb24gaW4g b3JkZXIgdG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGXCoCBy ZWFjdGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuDQogQWJzZW5jZSBvZiB0 aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZcKg IHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRo ZSByZXBvcnRpbmcgRE9JQ8KgIGVuZHBvaW50IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlYWN0 aW5nIERPSUMgZW5kcG9pbnQgaXMgYWN0dWFsbHkgZG9pbmfCoCB0aGUgcmlnaHQgdGhpbmcgd2l0 aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCiBUaGUgZmVlZGJhY2sgbWVj aGFuaXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9J Q8KgIGVuZHBvaW50IHRvIGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJvcHJpYXRlIHRocm90dGxp bmcgYnkgdGhlIHJlYWN0aW5nwqAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJl YXNvbikuDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJF USAxOCBmcm9tIFJGQyA3MDY4Lg0KIEluIHN1bW1hcnkgaXQgaXMgcHJvcG9zZWQgdG8gZGVmaW5l IHRoZSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdG/CoCBiZSB1c2VkIGluIHJlcXVl c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQrCoA0KwqANCg0K From nsalot@cisco.com Thu Feb 6 01:08:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065C61A01FB for ; Thu, 6 Feb 2014 01:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PicFMouSpWlI for ; Thu, 6 Feb 2014 01:08:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 16DCB1A00A9 for ; Thu, 6 Feb 2014 01:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10432; q=dns/txt; s=iport; t=1391677698; x=1392887298; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0svlZjTUzIz2KmV9QmlgZVIX6FsYT53H8OFW8772e9U=; b=iHygrat45nh8FRD+zBNlqBpQFcPI4Jofh2rz+7b9mpWGIqecFSbZka+7 KQIHipIinSfv9jL3bOrTTb2E7mRLcY5S+WtnU/IlKEEV0ESYBixpdjyMf L2//g9me/TZYx/2z7jFf9NioaUWYQrutJexpxQQs/j7JFn2CIvu+501mz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAApQ81KtJXHA/2dsb2JhbABZgwyBD4MBu24YbxZ0giUBAQEEIxFRBAIBCBEEAQEDAgYZBAMCAgIwFAEICAIEARIIh32tJ6EjF4EpjSA4BoJpNYEUBJRCjkaHRIFvgT6CKg X-IronPort-AV: E=Sophos;i="4.95,792,1384300800"; d="scan'208";a="18399818" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 06 Feb 2014 09:08:17 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1698HET000997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 09:08:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 03:08:17 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLww Date: Thu, 6 Feb 2014 09:08:16 +0000 Message-ID: References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.140.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 09:08:22 -0000 VWxyaWNoLA0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiBy ZXBvcnRpbmcgbm9kZSAib3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhl IHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVT VCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQg YW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2lt cGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9M UiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcg dGhlIHRyYWZmaWMuDQoNCkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8g bmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5n IGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3b3Jkcywg dGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9M UiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJk cyBpdC4NCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGlu ZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcg dGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0byBpbmNsdWRl IE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9uLg0KDQpSZXN0 IG9mIHRoZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuDQoNClJlZ2FyZHMsDQpO aXJhdi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2gg KE5TTiAtIERFL011bmljaCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0gDQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMjoyMyBQTQ0KVG86IGV4dCBTdGV2ZSBEb25vdmFu OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1l XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkFjdHVhbGx5IHdl IHNlZW0gdG8gYWdyZWUgb24gdHdvIHByaW5jaXBsZXM6DQoxLiBMYWNrIG9mIE9MUiBtZWFucyAi bm8gY2hhbmdlIg0KMi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVy bG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25z ZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQ IGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRo ZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1 Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5l LiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdo ZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMg dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4N Cg0KQ2FuIHBlb3BsZSBwbGVhc2UgY29uZmlybS4NCg0KVWxyaWNoDQoNCkZyb206IERpTUUgW21h aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zh bg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA0OjM1IFBNDQpUbzogTmlyYXYg U2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVd ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBZ3JlZWQuwqAgVG8gcmVzdGF0 ZSAtLSBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJl bnQgb3ZlcmxvYWQgc3RhdGUgZm9yIHRoZSBob3N0IG9yIHJlYWxtLsKgIElmIHRoZXJlIGlzIGEg Y3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBw bHkgdW50aWwgaXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0 aCBhIG5ldyBvdmVybG9hZCByZXBvcnQuwqAgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5IGFjdGl2 ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBpbXBsaWVz IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uDQoNClN0ZXZlDQpP biAyLzUvMTQgOToxOSBBTSwgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6DQpJIGFncmVlIHdp dGggU3RldmUgZXhjZXB0IHRoZSBwYXJ0ICJzaG91bGRu4oCZdCBsYWNrIG9mIE9MUiBiZSBpbnRl cnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD8iDQrCoA0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBz b21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFu ZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2Fn ZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNl bnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9y bWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50 YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHBy b3RvY29sIHBvaW50IG9mIHZpZXcuDQrCoA0KU28gYmFzaWNhbGx5LCB0aGUgbGFjayBvZiBPTFIg c2hvdWxkIG5vdCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRoZSByZWFj dGluZyBub2RlLiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3QgYmFzZWQg b24gb2xkZXIgT0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlvZCBvciB3 aGVuIHRoZSBleHBsaWNpdCBPTFIgd2l0aCAiMCIgb3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVk Lg0KSW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0 IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFj dGluZyBub2RlLg0KwqANClJlZ2FyZHMsDQpOaXJhdi4NCsKgDQpGcm9tOiBEaU1FIFttYWlsdG86 ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3Zhbg0KU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNDQpUbzogZGltZUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQrCoA0KaW5saW5lDQpPbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0g REUvTXVuaWNoKSB3cm90ZToNCk9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBvcnRpbmcgbm9k ZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHRoYXQg Y29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4gT0MtU3VwcG9y dGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlzIHJlcXVlc3Rl ZCkuDQpTUkQ+IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT/CoCBTaG91bGRuJ3QgbGFjayBv ZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KwqANCsKgDQpP dGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci4N ClNSRD4gUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBk aXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8g bG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3Nh Z2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUg ZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5nIE9MUnMuDQoNCg0KwqANCsKgDQpGb3IgbXkgY2xhcmlm aWNhdGlvbjogSSBndWVzcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGlzIG5vdCByZXF1aXJlZCB0 byBwcm9jZXNzIGV2ZXJ5IHNpbmdsZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2lsbCBiZSByZXBsYXlz IGFueXdheSkuIFdoYXQgd291bGQgYmUgdGhlIHByb2NlZHVyZSBpbiB0aGUgcmVhY3Rpbmcgbm9k ZSBpbiBvcmRlciB0byBtaW5pbWl6ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVkIE9MUnMgYW5kIGF0 IHRoZSBzYW1lIHRpbWUgbWluaW1pemUgdGhlIHJpc2sgdG9vIG1pc3MgYSBuZXcgT0xSPw0KU1JE PiBUaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuwqAgDQoNCg0KwqAN CsKgDQrCoA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxv dCkNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTQ0KVG86IGxpb25l bC5tb3JhbmRAb3JhbmdlLmNvbTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBb ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1 ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSBzaGFyZSB0aGUg c2FtZSBvcGluaW9uIGFzIExpb25lbC4NCsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IFR1ZXNk YXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDk6MDcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKg DQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJlcG9ydGlu ZyBub2RlIERPRVMgTk9UIGluc2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4gDQpTbyB0aGUg b3B0aW9ucyB3b3VsZCBiZToNCjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyDQoyLSBPQy1P bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgcmVxdWVzdCArIE9DLU9MUiBBVlAg aW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0 aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQrCoA0KSWYgdGhlcmUgaXMgbm8gb3RoZXIg Y3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQrCoA0KTGlv bmVsDQrCoA0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBkaW1lIGlzc3VlIHRy YWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCkVudm95w6nCoDog bWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4N CkNjwqA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl ZCBhIHRocm90dGxpbmcNCsKgDQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKg DQogSXQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGlu Zy1JbmZvIEFWUCB0aGF0IGlzwqAgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMg ZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0wqAgc3Vydml2ZWQgYSB0aHJvdHRsaW5n LiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQogKFRpbWVTdGFt cCkgb2YgdGhlIE9MUiBhY2NvcmRpbmcgdG8gd2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdh cw0KIHN1cnZpdmVkKSBpcyBwZXJmb3JtZWQuIEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5kaWNhdGVz IHRoYXQgY3VycmVudGx5IG5vwqAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuwqAgUmVwb3J0aW5n IERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhpc8KgIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRl dGVjdCB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCB0byB1cGRhdGUgdGhlwqAgcmVhY3RpbmcgRE9J QyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLg0KIEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFj ayBtZWNoYW5pc20gd291bGQgcmVzdWx0IGluIHRoZSBuZWVkIGZvciB0aGXCoCByZXBvcnRpbmcg bm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5n IERPSUPCoCBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVu ZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nwqAgdGhlIHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRv IHRocm90dGxpbmcvbm90IHRocm90dGxpbmcuDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXBy b3ZlcyByb2J1c3RuZXNzIGFzIGl0IGFsbG93cyB0aGUgcmVwb3J0aW5nIERPSUPCoCBlbmRwb2lu dCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSBy ZWFjdGluZ8KgIERPSUMgZW5kcG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24pLg0KIFRo ZSBmZWVkYmFjayBtZWNoYW5pc20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBS RkMgNzA2OC4NCiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvwqAgYmUgdXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2Vz IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLg0KwqANCsKgDQoNCg== From lionel.morand@orange.com Thu Feb 6 01:20:07 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13861A022D for ; Thu, 6 Feb 2014 01:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpXeFNTWL1HM for ; Thu, 6 Feb 2014 01:19:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68C1A0083 for ; Thu, 6 Feb 2014 01:19:59 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 53F513B467F; Thu, 6 Feb 2014 10:19:57 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2D64223805E; Thu, 6 Feb 2014 10:19:57 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 6 Feb 2014 10:19:56 +0100 From: To: "Nirav Salot (nsalot)" , "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKA= Date: Thu, 6 Feb 2014 09:19:56 +0000 Message-ID: <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 09:20:07 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogRGlNRSBbbWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBOaXJhdiBTYWxvdCAobnNhbG90KQ0KRW52 b3nDqcKgOiBqZXVkaSA2IGbDqXZyaWVyIDIwMTQgMTA6MDgNCsOAwqA6IFdpZWhlLCBVbHJpY2gg KE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpPYmpl dMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN Cg0KVWxyaWNoLA0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBv biByZXBvcnRpbmcgbm9kZSAib3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikg dGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkg TVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWlu ZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINClRoZSByZXBvcnRpbmcgbm9kZSBtYXkg c2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVk IE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxp bmcgdGhlIHRyYWZmaWMuDQoNCltMTV0gQWdyZWUuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBub3Qg ZGVlbWVkIHJlcXVpcmVkIGZvciB0aGUgZGVmYXVsdCBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRo aXMgZHJhZnQuIEhvdyBhbmQgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgZGVjaWRlcyB0byBpbmNs dWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciBtYXkgZGVwZW5kIG9uIHRoZSBhcHBsaWNhdGlvbiBv ciBvbiB0aGUgaW1wbGVtZW50YXRpb24uIEF0IGxlYXN0LCBpdCBpcyBteSBjdXJyZW50IHVuZGVy c3RhbmRpbmcuDQoNCkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8gbmVl ZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5nIGF0 IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3b3JkcywgdGhl IHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9MUiB0 byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJkcyBp dC4NCg0KW0xNXSBBZ3JlZQ0KDQpUaGVyZSBtYXkgYmUgb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0 aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgbGFzdCBvdmVybG9hZCBzaXR1YXRpb24g ZW5kZWQgbG9uZyB0aW1lIGJhY2sgaW4gdGhlIHBhc3QsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGl0 IHRvIGluY2x1ZGUgT0xSIGlmIGN1cnJlbnRseSB0aGVyZSBpcyBubyBvdmVybG9hZCBjb25kaXRp b24uDQoNCltMTV0gQWdyZWUNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmlu ZSB3aXRoIG1lLg0KDQpbTE1dIEFncmVlDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkg W21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg MDYsIDIwMTQgMjoyMyBQTQ0KVG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBTYWxvdCAobnNh bG90KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkFjdHVhbGx5IHdlIHNlZW0gdG8gYWdyZWUgb24g dHdvIHByaW5jaXBsZXM6DQoxLiBMYWNrIG9mIE9MUiBtZWFucyAibm8gY2hhbmdlIg0KMi4gdGhl IHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZ IGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGlj aCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRo YXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3QgT0xSICh3aGlj aCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGlu ZGljYXRpbmcgIm5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdh cmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBv ciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2gg Y29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KQ2FuIHBlb3BsZSBwbGVh c2UgY29uZmlybS4NCg0KVWxyaWNoDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAwNSwgMjAxNCA0OjM1IFBNDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRp bWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp dmVkIGEgdGhyb3R0bGluZw0KDQpBZ3JlZWQuwqAgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92 ZXJsb2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUg Zm9yIHRoZSBob3N0IG9yIHJlYWxtLsKgIElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBv dmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVy IHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCBy ZXBvcnQuwqAgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQg dGhlbiBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBpbXBsaWVzIHRoZXJlIGlzIG5vIG92ZXJs b2FkIGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uDQoNClN0ZXZlDQpPbiAyLzUvMTQgOToxOSBBTSwg TmlyYXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6DQpJIGFncmVlIHdpdGggU3RldmUgZXhjZXB0IHRo ZSBwYXJ0ICJzaG91bGRu4oCZdCBsYWNrIG9mIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3Zl cmxvYWRlZD8iDQrCoA0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0 aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRv IGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBz ZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50 IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJl ZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBz YW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZp ZXcuDQrCoA0KU28gYmFzaWNhbGx5LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3Qg dGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLiBUaGUgcmVh Y3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3QgYmFzZWQgb24gb2xkZXIgT0xSIHVudGls IHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlvZCBvciB3aGVuIHRoZSBleHBsaWNpdCBP TFIgd2l0aCAiMCIgb3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVkLg0KSW4gbXkgdmlldywgdGhp cyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9k ZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLg0KwqANClJl Z2FyZHMsDQpOaXJhdi4NCsKgDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3Zhbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAwNSwgMjAxNCA4OjAwIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1l XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KaW5saW5lDQpP biAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToN Ck9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4g T0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1 ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAo ZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlzIHJlcXVlc3RlZCkuDQpTUkQ+IFdoeSBpbiBl dmVyeSBhbnN3ZXIgbWVzc2FnZT/CoCBTaG91bGRuJ3QgbGFjayBvZiBhbiBPTFIgYmUgaW50ZXJw cmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KwqANCsKgDQpPdGhlciBjcml0ZXJpYSBsaWtl IFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci4NClNSRD4gUmVxdWlyaW5nIGFu IG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVEx MywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFu dGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5z ZXJ0aW5nIE9MUnMuDQoNCg0KwqANCsKgDQpGb3IgbXkgY2xhcmlmaWNhdGlvbjogSSBndWVzcyB0 aGF0IHRoZSByZWFjdGluZyBub2RlIGlzIG5vdCByZXF1aXJlZCB0byBwcm9jZXNzIGV2ZXJ5IHNp bmdsZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2lsbCBiZSByZXBsYXlzIGFueXdheSkuIFdoYXQgd291 bGQgYmUgdGhlIHByb2NlZHVyZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSBpbiBvcmRlciB0byBtaW5p bWl6ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVkIE9MUnMgYW5kIGF0IHRoZSBzYW1lIHRpbWUgbWlu aW1pemUgdGhlIHJpc2sgdG9vIG1pc3MgYSBuZXcgT0xSPw0KU1JEPiBUaGF0IGlzIHRoZSBwdXJw b3NlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuwqAgDQoNCg0KwqANCsKgDQrCoA0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNClNlbnQ6IFdlZG5lc2Rh eSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTQ0KVG86IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNv bTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSBzaGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExp b25lbC4NCsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAy MDE0IDk6MDcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQpJIHVuZGVyc3RhbmQgdGhh dCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIERPRVMgTk9UIGlu c2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4gDQpTbyB0aGUgb3B0aW9ucyB3b3VsZCBiZToN CjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyDQoyLSBPQy1PbmdvaW5nLVRocm90dGxpbmct SW5mbyBBVlAgaW4gZXZlcnkgcmVxdWVzdCArIE9DLU9MUiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hl biB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0aGUgY2xpZW50IG5lZWRzIHRv IGJlIHVwZGF0ZWQuDQrCoA0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0 aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQrCoA0KTGlvbmVsDQrCoA0KLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFj K2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCkVudm95w6nCoDogbWFyZGkgNCBmw6l2cmllciAy MDE0IDA5OjQ5DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCkNjwqA6IGRpbWVAaWV0Zi5v cmcNCk9iamV0wqA6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKg DQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQogSXQgaGFzIGJlZW4gcHJv cG9zZWQgdG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0aGF0IGlz wqAgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVz dCBtZXNzYWdlcyB0aGF0wqAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBp bmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQogKFRpbWVTdGFtcCkgb2YgdGhlIE9MUiBhY2Nv cmRpbmcgdG8gd2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdhcw0KIHN1cnZpdmVkKSBpcyBw ZXJmb3JtZWQuIEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5kaWNhdGVzIHRoYXQgY3VycmVudGx5IG5v wqAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuwqAgUmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1h eSB1c2UgdGhpc8KgIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0aGVyIHRoZXJl IGlzIGEgbmVlZCB0byB1cGRhdGUgdGhlwqAgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRo ZSBsYXRlc3QgT0xSLg0KIEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5pc20gd291bGQg cmVzdWx0IGluIHRoZSBuZWVkIGZvciB0aGXCoCByZXBvcnRpbmcgbm9kZSB0byBzZW5kIE9DLU9M UiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5nIERPSUPCoCBlbmRwb2ludCBj YW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5 IGRvaW5nwqAgdGhlIHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRocm90dGxpbmcvbm90IHRo cm90dGxpbmcuDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1c3RuZXNzIGFz IGl0IGFsbG93cyB0aGUgcmVwb3J0aW5nIERPSUPCoCBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNv cnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZ8KgIERPSUMgZW5k cG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24pLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5p c20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBSRkMgNzA2OC4NCiBJbiBzdW1t YXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu Zm8gQVZQIHRvwqAgYmUgdXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0 aHJvdHRsaW5nLg0KwqANCsKgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From ulrich.wiehe@nsn.com Thu Feb 6 02:27:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7101A0200 for ; Thu, 6 Feb 2014 02:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7VncionSv9M for ; Thu, 6 Feb 2014 02:27:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A289F1A00C4 for ; Thu, 6 Feb 2014 02:27:09 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s16AR4KD013165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 11:27:04 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s16AR4IR002682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 11:27:04 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 11:27:04 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "Nirav Salot (nsalot)" , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifECAAAXaAIAADfeAgAAEaQCAASwPUP//+iEAgAADQgCAABZZ8A== Date: Thu, 6 Feb 2014 10:27:03 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 14772 X-purgate-ID: 151667::1391682424-00001A6F-2EAD70A3/0-0/0-0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 10:27:13 -0000 TmlyYXYsIExpb25lbCwNCg0KSSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhv dWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlm aWVkIHByaW5jaXBsZSAyJzoNCg0KMicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdo ZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIg aW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1G ZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkg aGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUuZy4gdGhl IGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVj dGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiLCBvciBhbiBvbGQgIGJ1dCBz b29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRl ZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcg bm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFu IE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBv cnRlZC1GZWF0dXJlIEFWUC4NCg0KSSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15 b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2Ug YWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdo aWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQg c3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0KVWxyaWNoICANCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFtt YWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAwNiwgMjAxNCAxMDoyMCBBTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxy aWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0K U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IERpTUUgW21haWx0 bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxv dCkNCkVudm95w6nCoDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4DQrDgMKgOiBXaWVoZSwg VWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9y Zw0KT2JqZXTCoDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv dHRsaW5nDQoNClVscmljaCwNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVo YXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdh cmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBv ciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2gg Y29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQpUaGUgcmVwb3J0aW5nIG5v ZGUgbWF5IHNpbXBseSBub3QgaW5jbHVkZSBPTFIgYXNzdW1pbmcgdGhhdCB0aGUgZWFybGllciBw cm92aWRlZCBPTFIgd2lsbCBleHBpcmUgYW5kIHRoZSByZWFjdGluZyBub2RlIHdpbGwgc3RvcCB0 aHJvdHRsaW5nIHRoZSB0cmFmZmljLg0KDQpbTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQg aXMgbm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJl ZCBpbiB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMg dG8gaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGlj YXRpb24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVu dCB1bmRlcnN0YW5kaW5nLg0KDQpBcyB3ZSBoYWQgZGlzY3Vzc2VkIGVhcmxpZXIsIHRoZXJlIGlz IG5vIG5lZWQgZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBleHBsaWNpdGx5IHN0b3AgdGhyb3R0 bGluZyBhdCBlYWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4gSW4gb3RoZXIgd29y ZHMsIHRoZSByZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhlIG5hdHVyYWwgZXhwaXJ5IG9mIHRo ZSBPTFIgdG8gZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhlIHNpZ25hbGluZyB0cmFmZmljIHRv d2FyZHMgaXQuDQoNCltMTV0gQWdyZWUNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcu IHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0 dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVk IGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQg Y29uZGl0aW9uLg0KDQpbTE1dIEFncmVlDQoNClJlc3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVsb3cg YXJlIGZpbmUgd2l0aCBtZS4NCg0KW0xNXSBBZ3JlZQ0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N dW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dIA0KU2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE0NClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fs b3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBY3R1YWxseSB3ZSBzZWVtIHRvIGFn cmVlIG9uIHR3byBwcmluY2lwbGVzOg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSIN CjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBu b3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVz dHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBh d2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9M UiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFu IE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMg bm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJs b2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3Rz IHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkNhbiBwZW9w bGUgcGxlYXNlIGNvbmZpcm0uDQoNClVscmljaA0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fs b3QpOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQWdyZWVkLsKgIFRvIHJlc3RhdGUgLS0gbGFjayBv ZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2Fk IHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS7CoCBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBh Y3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0 IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3Zl cmxvYWQgcmVwb3J0LsKgIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQg cmVwb3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVyZSBpcyBu byBvdmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQpTdGV2ZQ0KT24gMi81LzE0IDk6 MTkgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4 Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMg bm90IG92ZXJsb2FkZWQ/Ig0KwqANCldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFj ayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNl cnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hl biB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNo IGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGlj aCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBh dCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2lu dCBvZiB2aWV3Lg0KwqANClNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3VsZCBub3Qg YWZmZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4g VGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVyIE9M UiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUgZXhw bGljaXQgT0xSIHdpdGggIjAiIG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZlZC4NCkluIG15IHZp ZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0 aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4N CsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwg RmVicnVhcnkgMDUsIDIwMTQgODowMCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCmlu bGluZQ0KT24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkg d3JvdGU6DQpPayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1VU1QgaW5z ZXJ0IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJlc3BvbmQg dG8gcmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJl cyBBVlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLg0KU1JEPiBX aHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJl IGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCsKgDQrCoA0KT3RoZXIgY3JpdGVy aWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQpTUkQ+IFJlcXVp cmluZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0bHkgYnJl YWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sgZm9yIGFu IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlzIGFsc28g c3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVuc2l2ZSB0 aGFuIGluc2VydGluZyBPTFJzLg0KDQoNCsKgDQrCoA0KRm9yIG15IGNsYXJpZmljYXRpb246IEkg Z3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBl dmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBX aGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIg dG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0 aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NClNSRD4gVGhhdCBpcyB0 aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLsKgIA0KDQoNCsKgDQrCoA0KwqANCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBsaW9uZWwubW9yYW5kQG9y YW5nZS5jb207IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTog U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkgc2hhcmUgdGhlIHNhbWUgb3Bpbmlv biBhcyBMaW9uZWwuDQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJydWFy eSAwNCwgMjAxNCA5OjA3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1l XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSB1bmRlcnN0 YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VT IE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28gdGhlIG9wdGlvbnMgd291 bGQgYmU6DQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0gT0MtT25nb2luZy1UaHJv dHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5z d2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBu ZWVkcyB0byBiZSB1cGRhdGVkLg0KwqANCklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwg dGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KwqANCkxpb25lbA0KwqANCi0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWls dG86dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOp dnJpZXIgMjAxNCAwOTo0OQ0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1l QGlldGYub3JnDQpPYmpldMKgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQrCoA0KIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIEl0IGhhcyBi ZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg dGhhdCBpc8KgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlu IHJlcXVlc3QgbWVzc2FnZXMgdGhhdMKgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAg d291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KIChUaW1lU3RhbXApIG9mIHRoZSBP TFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXMNCiBzdXJ2aXZl ZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJl bnRseSBub8KgIHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLsKgIFJlcG9ydGluZyBET0lDIGVuZHBv aW50cyBtYXkgdXNlIHRoaXPCoCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhl ciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZcKgIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQg d2l0aCB0aGUgbGF0ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNt IHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlwqAgcmVwb3J0aW5nIG5vZGUgdG8gc2Vu ZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5k cG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBh Y3R1YWxseSBkb2luZ8KgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5n L25vdCB0aHJvdHRsaW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0 bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9pbnQgdG8gZGV0ZWN0 IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmfCoCBE T0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4NCiBUaGUgZmVlZGJhY2sg bWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQog SW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCB0b8KgIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp dmVkIGEgdGhyb3R0bGluZy4NCsKgDQrCoA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u Yw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLg0KVGhhbmsgeW91Lg0KDQo= From trac+dime@trac.tools.ietf.org Thu Feb 6 02:44:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5DF1A02F6 for ; Thu, 6 Feb 2014 02:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMcuRMcTY7HR for ; Thu, 6 Feb 2014 02:44:54 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDAD1A02B7 for ; Thu, 6 Feb 2014 02:44:54 -0800 (PST) Received: from localhost ([127.0.0.1]:57234 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBMRw-0001Or-C9; Thu, 06 Feb 2014 11:44:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: maria.cruz.bartolome@ericsson.com X-Trac-Project: dime Date: Thu, 06 Feb 2014 10:44:52 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/36 Message-ID: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 10:44:56 -0000 #36: OC-Validity-Duration AVP In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when the OC-Validity-Duration AVP needs to be updated is ambiguous. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP (as indicated by the OC-Sequence-Number AVP). Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. -- -----------------------------------------------+--------------------------- Reporter: maria.cruz.bartolome@ericsson.com | Owner: MCruz Type: enhancement | Bartolomé Priority: major | Status: new Component: draft-docdt-dime-ovli | Milestone: Severity: Active WG Document | Version: | Keywords: -----------------------------------------------+--------------------------- Ticket URL: dime From ulrich.wiehe@nsn.com Thu Feb 6 05:12:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F151A03B7 for ; Thu, 6 Feb 2014 05:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb653Gkgu_qG for ; Thu, 6 Feb 2014 05:12:13 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DFDCF1A00F6 for ; Thu, 6 Feb 2014 05:12:12 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s16DCA2c017720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 14:12:10 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s16DCAXp015002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 14:12:10 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 6 Feb 2014 14:12:09 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 14:12:09 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell , "ext lionel.morand@orange.com" Thread-Topic: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR Thread-Index: AQHPIogkEv+6guWjnUWY08652K0oDJqmvRSAgAAB/ICAAADZgIABWrJw Date: Thu, 6 Feb 2014 13:12:09 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> In-Reply-To: <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8690 X-purgate-ID: 151667::1391692330-000025D0-2BE85AC5/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 13:12:17 -0000 I cannot understand what is the problem with mandating timestamp. But I can see interoperability problems with the current definition: Assume the sender sends sequence numbers 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3, ... 3, 4, 4, ... 4, 5,....=20 but the receicer for any reason receives=20 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3, ... 3, 4, 4, ... 4, 5,....=20 The receiver would accept 1, 1, ... 1, 2, 2, ... 2, 3, 30000 and then silently discards 3, ... 3, 4, 4, ... 4, 5,.... 4, 5, ....=20 with no way to come back to sync. Are we sure that this cannot happen? Mandating timestamp for sequence number generation at the sender and plausi= bility checking (i.e. received value must be between stored value and time = of reception) for the receiver may not be the only way to solve the problem= . But in the moment I don't see another way. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, February 05, 2014 4:57 PM To: ext lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC= -OLR My point is, we have an interop requirement that the sequence number always= increases over time scope. We do not have the interop requirement that the= sequence number be implemented as a time stamp. A time stamp is probably a= good way to meet the interop requirements, but it is not, in itself, an i= nterop requirement. On Feb 5, 2014, at 9:53 AM, wrote: > Not sure to understand: if there is a kind of "interop requirement", it i= s a case for a "MUST". > We are not violating anything. >=20 > Reporting and reacting nodes will just rely on the Diameter interfaces to= know how to handle the received sequence-number. So any MUST on the format= of the sequence-number is acceptable if it avoids interop issues. >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47 > =C0 : MORAND Lionel IMT/OLN > Cc : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O= C-OLR >=20 > I concur with Steve on this one. Using a time stamp is a good way to meet= the requirements, but it's not our job to normatively state an implementat= ion. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Se= ction 6 of 2119 includes the following: >=20 > "In particular, [normative requirements] MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) " >=20 > The only appropriate reason to require a timestamp would be if we expecte= d peers to interpret the field as a point in time. OTOH, it would be perfec= tly reasonable to state the actual interop requirements, then add a non-nor= mative (probably indented) paragraph suggesting that a timestamp is a good = way to do this. >=20 > On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: >=20 >> I think the out-of-sync failover described by Ulrich is a good use case = to mandate a specific semantic. >>=20 >> Is there any specific NOT to mandate the use of NTP timestamps if it is = a simple way to solve the possible issues and please everyone? >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within = OC-OLR >>=20 >> How the sequence number is implemented is an implementation decision. T= here is no reason to mandate that is be an NTP timestamp. That should be i= ncluded only as one way of addressing the requirement. >>=20 >> Steve >>=20 >> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: >> I also agree. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@ora= nge.com >> Sent: Tuesday, February 04, 2014 11:50 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within= OC-OLR >>=20 >> The existing wording seems actually fuzzy. >> If it is "like an NTP timestamp", be proud and say it loud! >>=20 >> In summary: ok with the proposal if it clarifies this handling of this s= equence-number. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] >> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>=20 >> #32: Sequence-Number Time-Stamp values within OC-OLR >>=20 >> The -01 draft says in clause 4.4: >> From the functionality point of view, the OC-Sequence-Number AVP MUST >> be used as a non-volatile increasing counter between two overload >> control endpoints (neglecting the fact that the contents of the AVP >> is a 64-bit NTP timestamp [RFC5905]). The sequence number is only >> required to be unique between two overload control endpoints. >> Sequence numbers are treated in uni-directional manner, i.e. two >> sequence numbers on each direction between two endpoints are not >> related or correlated. >>=20 >> When generating sequence numbers, the new sequence number MUST be >> greater than any sequence number previously seen between two >> endpoints within a time window that tolerates the wraparound of the >> NTP timestamp (i.e. approximately 68 years). >>=20 >>=20 >> With this mechanism it is difficult to get back to sync once you are out= of sync (for whatever reason). >> It is proposed to mandate that the Sequence Number is a real 64-bit NTP = timestamp (RFC5905) indicating the point in time when the OLR was created,= and to mandate that OLRs with a time stamp higher than time of reception= must be ignored by the reacting node. >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 srdonovan@usdonovans.com Thu Feb 6 07:35:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EEC1A03E0 for ; Thu, 6 Feb 2014 07:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3Sp27i0sQ2L for ; Thu, 6 Feb 2014 07:35:01 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 815411A0203 for ; Thu, 6 Feb 2014 07:35:01 -0800 (PST) Received: from [137.254.4.55] (port=28607 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WBQyh-0003OK-0a for dime@ietf.org; Thu, 06 Feb 2014 07:35:00 -0800 Message-ID: <52F3ABA5.30504@usdonovans.com> Date: Thu, 06 Feb 2014 09:35:01 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dime@ietf.org References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> In-Reply-To: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> Content-Type: multipart/alternative; boundary="------------060906030800010805000505" X-OutGoing-Spam-Status: No, score=-2.9 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 Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 15:35:04 -0000 This is a multi-part message in MIME format. --------------060906030800010805000505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This change looks pretty straight forward to me. I'll add it to the -02 version of the draft unless I hear objections soon. Steve On 2/6/14 4:44 AM, dime issue tracker wrote: > #36: OC-Validity-Duration AVP > > In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when > the OC-Validity-Duration AVP needs to be updated is ambiguous. > > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid since the reception of the new OC-OLR AVP (as indicated by the > OC-Sequence-Number AVP). > > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. > --------------060906030800010805000505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit This change looks pretty straight forward to me.  I'll add it to the -02 version of the draft unless I hear objections soon.

Steve
On 2/6/14 4:44 AM, dime issue tracker wrote:
#36: OC-Validity-Duration AVP

 In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when
 the OC-Validity-Duration AVP needs to be updated is ambiguous.

 Now:
    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
    and describes the number of seconds the OC-OLR AVP and its content is
    valid since the reception of the new OC-OLR AVP (as indicated by the
    OC-Sequence-Number AVP).

 Proposal:
    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
    and describes the number of seconds the OC-OLR AVP and its content is
    valid in relation to the reception of the first OC-OLR AVP with a
    specific sequence number. For a given sequence number, the
    OC-Validity-Duration shall always carry the same value.

--------------060906030800010805000505-- From nsalot@cisco.com Thu Feb 6 07:49:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA331A01B1 for ; Thu, 6 Feb 2014 07:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkoTUzM5EmTB for ; Thu, 6 Feb 2014 07:49:09 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAAC1A01E1 for ; Thu, 6 Feb 2014 07:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16172; q=dns/txt; s=iport; t=1391701748; x=1392911348; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=74LkHPc8ZZjhEPsiqfWVBDgnTnweKtwK3tl4YYCYQY4=; b=OXWiVoofm8UaL7i7yMgnnOMcWXDYKOBGdxSCHOUIYqbYrci/lihohEas Zw6P86mD8n4UbEOy8D/X+ZLTLZE4u40EMworIzIdUxom/P/shYvqCBNfa bxU4EzpyrfE966NJRRLcqKa7+ql11/tgdfAslhGVQz79MjzS0YUeWY7+G o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAESu81KtJXG9/2dsb2JhbABZgww4V4MBu3AYcxZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGGQQDAgICJQsUAQgIAgQBEgiHfQ2sfaEiEwSBKYxvEQEfFiIGgmk1gRQElEKORodEgW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="18473410" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 06 Feb 2014 15:49:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16Fn7s6007578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:49:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:49:07 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7Kfw Date: Thu, 6 Feb 2014 15:49:06 +0000 Message-ID: References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 15:49:12 -0000 VWxyaWNoLA0KDQpJdCBzZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUgcGFnZSBidXQgcHJvYmFibHkg dGhlIHByb3Bvc2VkIHdvcmRpbmcgYmVsb3cgaXMgbm90IHRoZSBiZXN0Lg0KSG93IGFib3V0IHRo ZSBmb2xsb3dpbmcuDQoNCldoZW4gdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUg bmV3IG92ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlk ZWQgb3ZlcmxvYWQgcmVwb3J0IHRvd2FyZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNs dWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3Vw cG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5v ZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5n IG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92 aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRl IHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1 cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFp bHRvOnVscmljaC53aWVoZUBuc24uY29tXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwg MjAxNCAzOjU3IFBNDQpUbzogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgTmlyYXYgU2Fs b3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBS RTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTmly YXYsIExpb25lbCwNCg0KSSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdo IHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVk IHByaW5jaXBsZSAyJzoNCg0KMicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRo ZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4g cmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0 dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFz IGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUuZy4gdGhlIGxh dGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlv biBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiLCBvciBhbiBvbGQgIGJ1dCBzb29u IGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCk7 IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9k ZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9M UiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRl ZC1GZWF0dXJlIEFWUC4NCg0KSSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Ut d2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxs b3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNo IGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3Rh dHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0KVWxyaWNoICANCg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFttYWls dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAw NiwgMjAxNCAxMDoyMCBBTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNo IChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n DQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IERpTUUgW21haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkN CkVudm95w6nCoDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4DQrDgMKgOiBXaWVoZSwgVWxy aWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0K T2JqZXTCoDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQoNClVscmljaCwNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZp b3Igb24gcmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUu Li4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBu b3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29u dGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQpUaGUgcmVwb3J0aW5nIG5vZGUg bWF5IHNpbXBseSBub3QgaW5jbHVkZSBPTFIgYXNzdW1pbmcgdGhhdCB0aGUgZWFybGllciBwcm92 aWRlZCBPTFIgd2lsbCBleHBpcmUgYW5kIHRoZSByZWFjdGluZyBub2RlIHdpbGwgc3RvcCB0aHJv dHRsaW5nIHRoZSB0cmFmZmljLg0KDQpbTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMg bm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBp biB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8g aW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRp b24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1 bmRlcnN0YW5kaW5nLg0KDQpBcyB3ZSBoYWQgZGlzY3Vzc2VkIGVhcmxpZXIsIHRoZXJlIGlzIG5v IG5lZWQgZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBleHBsaWNpdGx5IHN0b3AgdGhyb3R0bGlu ZyBhdCBlYWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4gSW4gb3RoZXIgd29yZHMs IHRoZSByZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhlIG5hdHVyYWwgZXhwaXJ5IG9mIHRoZSBP TFIgdG8gZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhlIHNpZ25hbGluZyB0cmFmZmljIHRvd2Fy ZHMgaXQuDQoNCltMTV0gQWdyZWUNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdo ZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0 aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZv ciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29u ZGl0aW9uLg0KDQpbTE1dIEFncmVlDQoNClJlc3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVsb3cgYXJl IGZpbmUgd2l0aCBtZS4NCg0KW0xNXSBBZ3JlZQ0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5p Y2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDA2LCAyMDE0IDI6MjMgUE0NClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3Qg KG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTog U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBY3R1YWxseSB3ZSBzZWVtIHRvIGFncmVl IG9uIHR3byBwcmluY2lwbGVzOg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSINCjIu IHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3Qp IE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMg d2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2Fy ZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAo d2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9M UiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90 IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2Fk ZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdo aWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkNhbiBwZW9wbGUg cGxlYXNlIGNvbmZpcm0uDQoNClVscmljaA0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3Qp OyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz dXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQWdyZWVkLsKgIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBh biBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0 YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS7CoCBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3Rp dmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVp dGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3Zlcmxv YWQgcmVwb3J0LsKgIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVw b3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVyZSBpcyBubyBv dmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQpTdGV2ZQ0KT24gMi81LzE0IDk6MTkg QU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2Vw dCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90 IG92ZXJsb2FkZWQ/Ig0KwqANCldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBh bmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZl ciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0 aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNs aWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBp cyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0 aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBv ZiB2aWV3Lg0KwqANClNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3VsZCBub3QgYWZm ZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4gVGhl IHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVyIE9MUiB1 bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUgZXhwbGlj aXQgT0xSIHdpdGggIjAiIG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZlZC4NCkluIG15IHZpZXcs IHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5n IG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4NCsKg DQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwgRmVi cnVhcnkgMDUsIDIwMTQgODowMCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCmlubGlu ZQ0KT24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3Jv dGU6DQpPayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1VU1QgaW5zZXJ0 IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJlc3BvbmQgdG8g cmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBB VlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLg0KU1JEPiBXaHkg aW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGlu dGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCsKgDQrCoA0KT3RoZXIgY3JpdGVyaWEg bGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQpTUkQ+IFJlcXVpcmlu ZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0bHkgYnJlYWsg UkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sgZm9yIGFuIE9D LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlzIGFsc28gc3Vi c3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFu IGluc2VydGluZyBPTFJzLg0KDQoNCsKgDQrCoA0KRm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vl c3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVy eSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0 IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8g bWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1l IG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NClNSRD4gVGhhdCBpcyB0aGUg cHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLsKgIA0KDQoNCsKgDQrCoA0KwqANCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBXZWRu ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBsaW9uZWwubW9yYW5kQG9yYW5n ZS5jb207IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0 aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBh cyBMaW9uZWwuDQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAw NCwgMjAxNCA5OjA3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBb ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1 ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSB1bmRlcnN0YW5k IHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VTIE5P VCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28gdGhlIG9wdGlvbnMgd291bGQg YmU6DQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0gT0MtT25nb2luZy1UaHJvdHRs aW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2Vy IHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVk cyB0byBiZSB1cGRhdGVkLg0KwqANCklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhl IG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KwqANCkxpb25lbA0KwqANCi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86 dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOpdnJp ZXIgMjAxNCAwOTo0OQ0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1lQGll dGYub3JnDQpPYmpldMKgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n DQrCoA0KIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1 ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIEl0IGhhcyBiZWVu IHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdGhh dCBpc8KgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGluIHJl cXVlc3QgbWVzc2FnZXMgdGhhdMKgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291 bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KIChUaW1lU3RhbXApIG9mIHRoZSBPTFIg YWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXMNCiBzdXJ2aXZlZCkg aXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRs eSBub8KgIHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLsKgIFJlcG9ydGluZyBET0lDIGVuZHBvaW50 cyBtYXkgdXNlIHRoaXPCoCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0 aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZcKgIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgd2l0 aCB0aGUgbGF0ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNtIHdv dWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlwqAgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBP Qy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9p bnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1 YWxseSBkb2luZ8KgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5nL25v dCB0aHJvdHRsaW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0bmVz cyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9pbnQgdG8gZGV0ZWN0IGFu ZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmfCoCBET0lD IGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4NCiBUaGUgZmVlZGJhY2sgbWVj aGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQogSW4g c3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGlu Zy1JbmZvIEFWUCB0b8KgIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk IGEgdGhyb3R0bGluZy4NCsKgDQrCoA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0K cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KVGhhbmsgeW91Lg0KDQo= From srdonovan@usdonovans.com Thu Feb 6 07:49:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8471A0177 for ; Thu, 6 Feb 2014 07:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kLV9urhPSXi for ; Thu, 6 Feb 2014 07:49:35 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 420381A01E1 for ; Thu, 6 Feb 2014 07:49:34 -0800 (PST) Received: from [137.254.4.55] (port=52164 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WBRCl-0007qv-DU for dime@ietf.org; Thu, 06 Feb 2014 07:49:32 -0800 Message-ID: <52F3AF0D.3050306@usdonovans.com> Date: Thu, 06 Feb 2014 09:49:33 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dime@ietf.org References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------070405090507090307080405" X-OutGoing-Spam-Status: No, score=-1.9 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 Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 15:49:39 -0000 This is a multi-part message in MIME format. --------------070405090507090307080405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit A couple of things - The requirement is that the sequence number increase monotonically over time, including over a reboot. Use of NTP time is one way of doing this but is not the only way. Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent. This actually has better properties than an NTP time stamp as it would take much longer to roll over. One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot. We also have a duration timer on overload reports. This gives us one way to reset. It should only be required to remember the sequence number of an active overload report. Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. The requirement we need is similar to the session-id in the base Diameter specification. The wording there is -- "The Session-Id MUST be globally and eternally unique". We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report. It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below..." Steve On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > I cannot understand what is the problem with mandating timestamp. > But I can see interoperability problems with the current definition: > > Assume the sender sends sequence numbers > 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3, ... 3, 4, 4, ... 4, 5,.... > but the receicer for any reason receives > 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3, ... 3, 4, 4, ... 4, 5,.... > The receiver would accept > 1, 1, ... 1, 2, 2, ... 2, 3, 30000 > and then silently discards > 3, ... 3, 4, 4, ... 4, 5,.... 4, 5, .... > with no way to come back to sync. > > Are we sure that this cannot happen? > > Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way. > > Ulrich > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell > Sent: Wednesday, February 05, 2014 4:57 PM > To: ext lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR > > My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to meet the interop requirements, but it is not, in itself, an interop requirement. > > On Feb 5, 2014, at 9:53 AM, wrote: > >> Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST". >> We are not violating anything. >> >> Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues. >> >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@nostrum.com] >> Envoyé : mercredi 5 février 2014 16:47 >> À : MORAND Lionel IMT/OLN >> Cc : Steve Donovan; dime@ietf.org >> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following: >> >> "In particular, [normative requirements] MUST only be used where it is >> actually required for interoperation or to limit behavior which has >> potential for causing harm (e.g., limiting retransmisssions) " >> >> The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this. >> >> On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: >> >>> I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic. >>> >>> Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone? >>> >>> Lionel >>> >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>> Envoyé : mercredi 5 février 2014 15:34 >>> À : dime@ietf.org >>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>> >>> How the sequence number is implemented is an implementation decision. There is no reason to mandate that is be an NTP timestamp. That should be included only as one way of addressing the requirement. >>> >>> Steve >>> >>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: >>> I also agree. >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com >>> Sent: Tuesday, February 04, 2014 11:50 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>> >>> The existing wording seems actually fuzzy. >>> If it is "like an NTP timestamp", be proud and say it loud! >>> >>> In summary: ok with the proposal if it clarifies this handling of this sequence-number. >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] >>> Envoyé : mardi 4 février 2014 09:50 >>> À : MORAND Lionel IMT/OLN >>> Cc : dime@ietf.org >>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>> >>> #32: Sequence-Number Time-Stamp values within OC-OLR >>> >>> The -01 draft says in clause 4.4: >>> From the functionality point of view, the OC-Sequence-Number AVP MUST >>> be used as a non-volatile increasing counter between two overload >>> control endpoints (neglecting the fact that the contents of the AVP >>> is a 64-bit NTP timestamp [RFC5905]). The sequence number is only >>> required to be unique between two overload control endpoints. >>> Sequence numbers are treated in uni-directional manner, i.e. two >>> sequence numbers on each direction between two endpoints are not >>> related or correlated. >>> >>> When generating sequence numbers, the new sequence number MUST be >>> greater than any sequence number previously seen between two >>> endpoints within a time window that tolerates the wraparound of the >>> NTP timestamp (i.e. approximately 68 years). >>> >>> >>> With this mechanism it is difficult to get back to sync once you are out of sync (for whatever reason). >>> It is proposed to mandate that the Sequence Number is a real 64-bit NTP timestamp (RFC5905) indicating the point in time when the OLR was created, and to mandate that OLRs with a time stamp higher than time of reception must be ignored by the reacting node. >>> >>> >>> _________________________________________________________________________________________________________________________ >>> >>> 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. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> >> _________________________________________________________________________________________________________________________ >> >> 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. >> >> _______________________________________________ >> 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 > --------------070405090507090307080405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A couple of things -

The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.

We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value.

The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.

It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."

Steve
On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
I cannot understand what is the problem with mandating timestamp.
But I can see interoperability problems with the current definition:

Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.

Are we sure that this cannot happen?

Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.

Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, February 05, 2014 4:57 PM
To: ext lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.

On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:


Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
We are not violating anything.

Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.

-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] 
Envoyé : mercredi 5 février 2014 16:47
À : MORAND Lionel IMT/OLN
Cc : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:

"In particular, [normative requirements] MUST only be used where it is
  actually required for interoperation or to limit behavior which has
  potential for causing harm (e.g., limiting retransmisssions)  "

The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.

On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:


I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.

Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:34
À : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.

Steve

On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
I also agree.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 11:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

The existing wording seems actually fuzzy.
If it is "like an NTP timestamp", be proud and say it loud!

In summary: ok with the proposal if it clarifies this handling of this sequence-number.

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:50
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

#32: Sequence-Number Time-Stamp values within OC-OLR

The -01 draft says in clause 4.4:
   From the functionality point of view, the OC-Sequence-Number AVP MUST
   be used as a non-volatile increasing counter between two overload
   control endpoints (neglecting the fact that the contents of the AVP
   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
   required to be unique between two overload control endpoints.
   Sequence numbers are treated in uni-directional manner, i.e. two
   sequence numbers on each direction between two endpoints are not
   related or correlated.

   When generating sequence numbers, the new sequence number MUST be
   greater than any sequence number previously seen between two
   endpoints within a time window that tolerates the wraparound of the
   NTP timestamp (i.e. approximately 68 years).


With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.


_________________________________________________________________________________________________________________________

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.

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


_________________________________________________________________________________________________________________________

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.

_______________________________________________
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

--------------070405090507090307080405-- From lionel.morand@orange.com Thu Feb 6 10:07:07 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD51A018C for ; Thu, 6 Feb 2014 10:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0xrQ-IRymr8 for ; Thu, 6 Feb 2014 10:07:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DF7101A013C for ; Thu, 6 Feb 2014 10:07:05 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 879CE22C5B1; Thu, 6 Feb 2014 19:07:04 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6C443238076; Thu, 6 Feb 2014 19:07:04 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 6 Feb 2014 19:07:04 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyh8Vr4ckhycckOtZMdYVbaIJJqoSuqAgAAnBTA= Date: Thu, 6 Feb 2014 18:07:02 +0000 Message-ID: <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> In-Reply-To: <52F3ABA5.30504@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.6.21815 Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 18:07:07 -0000 SGkgTWFyaWEgQ3J1eiwNCg0KSGkgTWFyaWEgQ3J1eiwgU3RldmUsDQoNCkJlIGNhcmVmdWwhIFRo ZSByZWZlcmVuY2UgeW91IGFyZSB1c2luZyBzZWVtcyB0byBiZSBvZGQuDQoNClRoZSBjdXJyZW50 IHRleHQgaW4gdGhlIGRyYWZ0IHNheXM6DQoNCjQuNS4gT0MtVmFsaWRpdHktRHVyYXRpb24gQVZQ DQoNCg0KICAgVGhlIE9DLVZhbGlkaXR5LUR1cmF0aW9uIEFWUCAoQVZQIGNvZGUgVEJENCkgaXMg dHlwZSBvZiBVbnNpZ25lZDMyDQogICBhbmQgZGVzY3JpYmVzIHRoZSBudW1iZXIgb2Ygc2Vjb25k cyB0aGUgIm5ldyBhbmQgZnJlc2giIE9DLU9MUiBBVlANCiAgIGFuZCBpdHMgY29udGVudCBpcyB2 YWxpZCBzaW5jZSB0aGUgcmVjZXB0aW9uIG9mIHRoZSBuZXcgT0MtT0xSIEFWUC4NCiAgIFRoZSBk ZWZhdWx0IHZhbHVlIGZvciB0aGUgT0MtVmFsaWRpdHktRHVyYXRpb24gQVZQIHZhbHVlIGlzIDUg KGkuZS4sDQogICA1IHNlY29uZHMpLiAgV2hlbiB0aGUgT0MtVmFsaWRpdHktRHVyYXRpb24gQVZQ IGlzIG5vdCBwcmVzZW50IGluIHRoZQ0KICAgT0MtT0xSIEFWUCwgdGhlIGRlZmF1bHQgdmFsdWUg YXBwbGllcy4gIFZhbGlkaXR5IGR1cmF0aW9uIHZhbHVlcyAwDQogICAoaS5lLiwgMCBzZWNvbmRz KSBhbmQgYWJvdmUgODY0MDAgKGkuZS4sIDI0IGhvdXJzKSBNVVNUIE5PVCBiZSB1c2VkLg0KICAg SW52YWxpZCB2YWxpZGl0eSBkdXJhdGlvbiB2YWx1ZXMgYXJlIHRyZWF0ZWQgYXMgaWYgdGhlIE9D LVZhbGlkaXR5LQ0KICAgRHVyYXRpb24gQVZQIHdlcmUgbm90IHByZXNlbnQuDQoNCiAgIEEgdGlt ZW91dCBvZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGhhcyBzcGVjaWZpYyBjb25jZXJucyB0aGF0IG5l ZWQgdG8NCiAgIGJlIHRha2VuIGludG8gYWNjb3VudCBieSB0aGUgZW5kcG9pbnQgYWN0aW5nIG9u IHRoZSBlYXJsaWVyIHJlY2VpdmVkDQogICBvdmVybG9hZCByZXBvcnQocykuICBTZWN0aW9uIDQu NyBkaXNjdXNzZXMgdGhlIGltcGFjdHMgb2YgdGltZW91dCBpbg0KICAgdGhlIHNjb3BlIG9mIHRo ZSB0cmFmZmljIGFiYXRlbWVudCBhbGdvcml0aG1zLg0KDQogICBBcyBhIGdlbmVyYWwgZ3VpZGFu Y2UgZm9yIGltcGxlbWVudGF0aW9ucyBpdCBpcyBSRUNPTU1FTkRFRCBuZXZlciB0bw0KICAgbGV0 IGFueSBvdmVybG9hZCByZXBvcnQgdG8gdGltZW91dC4gIEZvbGxvd2luZyB0byB0aGlzIHJ1bGUs IGFuDQogICBvdmVybG9hZCBlbmRwb2ludCBzaG91bGQgZXhwbGljaXRseSBzaWduYWwgdGhlIGVu ZCBvZiBvdmVybG9hZA0KICAgY29uZGl0aW9uIGFuZCBub3QgcmVseSBvbiB0aGUgZXhwaXJhdGlv biBvZiB0aGUgdmFsaWRpdHkgdGltZSBvZiB0aGUNCiAgIG92ZXJsb2FkIHJlcG9ydCBpbiB0aGUg cmVhY3Rpbmcgbm9kZS4gIFRoaXMgbGVhdmVzIG5vIG5lZWQgZm9yIHRoZQ0KICAgcmVhY3Rpbmcg bm9kZSB0byByZWFzb24gb3IgZ3Vlc3MgdGhlIG92ZXJsb2FkIGNvbmRpdGlvbiBvZiB0aGUNCiAg IHJlcG9ydGluZyBub2RlLg0KDQpJIHRoaW5rIHRoYXQgdGhlIGRlZmluaXRpb24gb2YgdGhlIE9D LVZhbGlkaXR5LUR1cmF0aW9uIEFWUCBzaG91bGQgcmVtYWluIGluZGVwZW5kZW50IG9mIHRoZSBu b3Rpb24gb2YgU2VxdWVuY2UtTnVtYmVyLg0KVGhlIHNlcXVlbmNlIG51bWJlciBkb2VzIG5vdCBj aGFuZ2UgdGhlIHZhbHVlIG9mIHRoZSBPQy1WYWxpZGl0eS1EdXJhdGlvbiBBVlAuIEl0IGluZGlj YXRlcyB0aGF0IHRoZSBPTFIgaGFzIHRvIGJlIHVwZGF0ZWQgb3Igbm90LiBBbmQgaWYgaXQgaXMs IGEgbmV3IGR1cmF0aW9uIHdpbGwgYmUgdGhlcmUgKGVpdGhlciBpbXBsaWNpdCBvciBleHBsaWNp dCB3aXRoIHRoZSBPQy1WYWxpZGl0eS1EdXJhdGlvbiBBVlApLg0KDQpTbyBpZiBzb21ldGhpbmcg bmVlZHMgdG8gYmUgY2xhcmlmaWVkIChJIGhhdmVuJ3QgY2hlY2tlZCksIGl0IHNob3VsZCBiZSBp biB0aGUgaGFuZGxpbmcgb2YgdGhlIE9MUi4NCg0KUmVnYXJkcywNCg0KTGlvbmVsIA0KDQpEZcKg OiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZl IERvbm92YW4NCkVudm95w6nCoDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDE2OjM1DQrDgMKgOiBk aW1lQGlldGYub3JnDQpPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzY6IE9DLVZhbGlkaXR5 LUR1cmF0aW9uIEFWUA0KDQpUaGlzIGNoYW5nZSBsb29rcyBwcmV0dHkgc3RyYWlnaHQgZm9yd2Fy ZCB0byBtZS7CoCBJJ2xsIGFkZCBpdCB0byB0aGUgLTAyIHZlcnNpb24gb2YgdGhlIGRyYWZ0IHVu bGVzcyBJIGhlYXIgb2JqZWN0aW9ucyBzb29uLg0KDQpTdGV2ZQ0KT24gMi82LzE0IDQ6NDQgQU0s IGRpbWUgaXNzdWUgdHJhY2tlciB3cm90ZToNCiMzNjogT0MtVmFsaWRpdHktRHVyYXRpb24gQVZQ DQoNCiBJbiBkcmFmdC1pZXRmLWRpbWUtb3ZsaS0wMSBjaGFwdGVyIDQuNSwgdGhlIHN0YXRlbWVu dCB0aGF0IGRlc2NyaWJlcyB3aGVuDQogdGhlIE9DLVZhbGlkaXR5LUR1cmF0aW9uIEFWUCBuZWVk cyB0byBiZSB1cGRhdGVkIGlzIGFtYmlndW91cy4NCg0KIE5vdzoNCiAgICBUaGUgT0MtVmFsaWRp dHktRHVyYXRpb24gQVZQIChBVlAgY29kZSBUQkQ0KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzINCiAg ICBhbmQgZGVzY3JpYmVzIHRoZSBudW1iZXIgb2Ygc2Vjb25kcyB0aGUgT0MtT0xSIEFWUCBhbmQg aXRzIGNvbnRlbnQgaXMNCiAgICB2YWxpZCBzaW5jZSB0aGUgcmVjZXB0aW9uIG9mIHRoZSBuZXcg T0MtT0xSIEFWUCAoYXMgaW5kaWNhdGVkIGJ5IHRoZQ0KICAgIE9DLVNlcXVlbmNlLU51bWJlciBB VlApLg0KDQogUHJvcG9zYWw6DQogICAgVGhlIE9DLVZhbGlkaXR5LUR1cmF0aW9uIEFWUCAoQVZQ IGNvZGUgVEJENCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyDQogICAgYW5kIGRlc2NyaWJlcyB0aGUg bnVtYmVyIG9mIHNlY29uZHMgdGhlIE9DLU9MUiBBVlAgYW5kIGl0cyBjb250ZW50IGlzDQogICAg dmFsaWQgaW4gcmVsYXRpb24gdG8gdGhlIHJlY2VwdGlvbiBvZiB0aGUgZmlyc3QgT0MtT0xSIEFW UCB3aXRoIGENCiAgICBzcGVjaWZpYyBzZXF1ZW5jZSBudW1iZXIuIEZvciBhIGdpdmVuIHNlcXVl bmNlIG51bWJlciwgdGhlDQogICAgT0MtVmFsaWRpdHktRHVyYXRpb24gc2hhbGwgYWx3YXlzIGNh cnJ5IHRoZSBzYW1lIHZhbHVlLg0KDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From maria.cruz.bartolome@ericsson.com Thu Feb 6 23:13:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BAF1A05BE for ; Thu, 6 Feb 2014 23:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3AznJ56i0Xk for ; Thu, 6 Feb 2014 23:13:49 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4E79A1A05BD for ; Thu, 6 Feb 2014 23:13:47 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-03-52f487a9dc87 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3C.DF.23809.9A784F25; Fri, 7 Feb 2014 08:13:46 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 08:13:45 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyh3Mk+g2dTxBkStndl7a0rG2ZqoSuqAgAAqeQCAAOmhgA== Date: Fri, 7 Feb 2014 07:13:44 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje6q9i9BBtMnslvM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBvND5gL5llU/Ng1la2B8YlZFyMnh4SAicSq51+YIWwxiQv3 1rN1MXJxCAkcYpT4veUME4SzmFHiyb69YFVsAnYSl06/AEpwcIgIKEuc/uUAEhYWsJD4tvMN C0TYUuL0i2CQsIiAk0Rz/ztGEJtFQEVi4uGDYDavgK9E9/3vzBDjHzFKXL33nBHE4RRoYZT4 dOQiWBUj0EXfT61hArGZBcQlbj2ZzwRxqYDEkj3noa4WlXj5+B8rhK0o0f60gRHkCGYBTYn1 u/QhWhUlpnQ/ZIdYLChxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMbLnJmbmpJcbbWIEBv3B Lb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYx6f85qLfzZ /Mrs2VlLTYW1zKckq+2bV3xzSfn6b3GKQSDf1X33Zy8rFvDk+vrXeNs6/Zx5fQ8lw64c1ZIv fFz8X2yaf0pFsMh3x+zXj75mHFF+GCbh9dp5lfHX6BcTLA0uTDy15/31t09ViuqnphpJx9Z6 OkzWv77/BvsvzUtTtCSj5kkUsnAosRRnJBpqMRcVJwIAtZx2YkgCAAA= Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 07:13:51 -0000 VGhhbmtzIExpb25lbCwNClRoZSBjb21tZW50IGVxdWFsbHkgYXBwbGllcyBpbiBvcmRlciB0byBj bGFyaWZ5IHdoZW4gdGhlIFZhbGlkaXR5LUR1cmF0aW9uIHNob3VsZCBpbmNsdWRlIGEgbmV3IHZh bHVlLiANCg0KTm93Og0KICAgVGhlIE9DLVZhbGlkaXR5LUR1cmF0aW9uIEFWUCAoQVZQIGNvZGUg VEJENCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyDQogICBhbmQgZGVzY3JpYmVzIHRoZSBudW1iZXIg b2Ygc2Vjb25kcyB0aGUgIm5ldyBhbmQgZnJlc2giIE9DLU9MUiBBVlANCiAgIGFuZCBpdHMgY29u dGVudCBpcyB2YWxpZCBzaW5jZSB0aGUgcmVjZXB0aW9uIG9mIHRoZSBuZXcgT0MtT0xSIEFWUC4N Cg0KIFByb3Bvc2FsOg0KICAgIFRoZSBPQy1WYWxpZGl0eS1EdXJhdGlvbiBBVlAgKEFWUCBjb2Rl IFRCRDQpIGlzIHR5cGUgb2YgVW5zaWduZWQzMg0KICAgIGFuZCBkZXNjcmliZXMgdGhlIG51bWJl ciBvZiBzZWNvbmRzIHRoZSBPQy1PTFIgQVZQIGFuZCBpdHMgY29udGVudCBpcw0KICAgIHZhbGlk IGluIHJlbGF0aW9uIHRvIHRoZSByZWNlcHRpb24gb2YgdGhlIGZpcnN0IE9DLU9MUiBBVlAgd2l0 aCBhDQogICAgc3BlY2lmaWMgc2VxdWVuY2UgbnVtYmVyLiBGb3IgYSBnaXZlbiBzZXF1ZW5jZSBu dW1iZXIsIHRoZQ0KICAgIE9DLVZhbGlkaXR5LUR1cmF0aW9uIHNoYWxsIGFsd2F5cyBjYXJyeSB0 aGUgc2FtZSB2YWx1ZS4NCg0KDQpCZXN0IHJlZ2FyZHMNCi9NQ3J1eg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBqdWV2ZXMsIDA2 IGRlIGZlYnJlcm8gZGUgMjAxNCAxOTowNw0KVG86IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzNjogT0MtVmFsaWRpdHktRHVyYXRpb24g QVZQDQoNCkhpIE1hcmlhIENydXosDQoNCkhpIE1hcmlhIENydXosIFN0ZXZlLA0KDQpCZSBjYXJl ZnVsISBUaGUgcmVmZXJlbmNlIHlvdSBhcmUgdXNpbmcgc2VlbXMgdG8gYmUgb2RkLg0KDQpUaGUg Y3VycmVudCB0ZXh0IGluIHRoZSBkcmFmdCBzYXlzOg0KDQo0LjUuIE9DLVZhbGlkaXR5LUR1cmF0 aW9uIEFWUA0KDQoNCiAgIFRoZSBPQy1WYWxpZGl0eS1EdXJhdGlvbiBBVlAgKEFWUCBjb2RlIFRC RDQpIGlzIHR5cGUgb2YgVW5zaWduZWQzMg0KICAgYW5kIGRlc2NyaWJlcyB0aGUgbnVtYmVyIG9m IHNlY29uZHMgdGhlICJuZXcgYW5kIGZyZXNoIiBPQy1PTFIgQVZQDQogICBhbmQgaXRzIGNvbnRl bnQgaXMgdmFsaWQgc2luY2UgdGhlIHJlY2VwdGlvbiBvZiB0aGUgbmV3IE9DLU9MUiBBVlAuDQog ICBUaGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhlIE9DLVZhbGlkaXR5LUR1cmF0aW9uIEFWUCB2YWx1 ZSBpcyA1IChpLmUuLA0KICAgNSBzZWNvbmRzKS4gIFdoZW4gdGhlIE9DLVZhbGlkaXR5LUR1cmF0 aW9uIEFWUCBpcyBub3QgcHJlc2VudCBpbiB0aGUNCiAgIE9DLU9MUiBBVlAsIHRoZSBkZWZhdWx0 IHZhbHVlIGFwcGxpZXMuICBWYWxpZGl0eSBkdXJhdGlvbiB2YWx1ZXMgMA0KICAgKGkuZS4sIDAg c2Vjb25kcykgYW5kIGFib3ZlIDg2NDAwIChpLmUuLCAyNCBob3VycykgTVVTVCBOT1QgYmUgdXNl ZC4NCiAgIEludmFsaWQgdmFsaWRpdHkgZHVyYXRpb24gdmFsdWVzIGFyZSB0cmVhdGVkIGFzIGlm IHRoZSBPQy1WYWxpZGl0eS0NCiAgIER1cmF0aW9uIEFWUCB3ZXJlIG5vdCBwcmVzZW50Lg0KDQog ICBBIHRpbWVvdXQgb2YgdGhlIG92ZXJsb2FkIHJlcG9ydCBoYXMgc3BlY2lmaWMgY29uY2VybnMg dGhhdCBuZWVkIHRvDQogICBiZSB0YWtlbiBpbnRvIGFjY291bnQgYnkgdGhlIGVuZHBvaW50IGFj dGluZyBvbiB0aGUgZWFybGllciByZWNlaXZlZA0KICAgb3ZlcmxvYWQgcmVwb3J0KHMpLiAgU2Vj dGlvbiA0LjcgZGlzY3Vzc2VzIHRoZSBpbXBhY3RzIG9mIHRpbWVvdXQgaW4NCiAgIHRoZSBzY29w ZSBvZiB0aGUgdHJhZmZpYyBhYmF0ZW1lbnQgYWxnb3JpdGhtcy4NCg0KICAgQXMgYSBnZW5lcmFs IGd1aWRhbmNlIGZvciBpbXBsZW1lbnRhdGlvbnMgaXQgaXMgUkVDT01NRU5ERUQgbmV2ZXIgdG8N CiAgIGxldCBhbnkgb3ZlcmxvYWQgcmVwb3J0IHRvIHRpbWVvdXQuICBGb2xsb3dpbmcgdG8gdGhp cyBydWxlLCBhbg0KICAgb3ZlcmxvYWQgZW5kcG9pbnQgc2hvdWxkIGV4cGxpY2l0bHkgc2lnbmFs IHRoZSBlbmQgb2Ygb3ZlcmxvYWQNCiAgIGNvbmRpdGlvbiBhbmQgbm90IHJlbHkgb24gdGhlIGV4 cGlyYXRpb24gb2YgdGhlIHZhbGlkaXR5IHRpbWUgb2YgdGhlDQogICBvdmVybG9hZCByZXBvcnQg aW4gdGhlIHJlYWN0aW5nIG5vZGUuICBUaGlzIGxlYXZlcyBubyBuZWVkIGZvciB0aGUNCiAgIHJl YWN0aW5nIG5vZGUgdG8gcmVhc29uIG9yIGd1ZXNzIHRoZSBvdmVybG9hZCBjb25kaXRpb24gb2Yg dGhlDQogICByZXBvcnRpbmcgbm9kZS4NCg0KSSB0aGluayB0aGF0IHRoZSBkZWZpbml0aW9uIG9m IHRoZSBPQy1WYWxpZGl0eS1EdXJhdGlvbiBBVlAgc2hvdWxkIHJlbWFpbiBpbmRlcGVuZGVudCBv ZiB0aGUgbm90aW9uIG9mIFNlcXVlbmNlLU51bWJlci4NClRoZSBzZXF1ZW5jZSBudW1iZXIgZG9l cyBub3QgY2hhbmdlIHRoZSB2YWx1ZSBvZiB0aGUgT0MtVmFsaWRpdHktRHVyYXRpb24gQVZQLiBJ dCBpbmRpY2F0ZXMgdGhhdCB0aGUgT0xSIGhhcyB0byBiZSB1cGRhdGVkIG9yIG5vdC4gQW5kIGlm IGl0IGlzLCBhIG5ldyBkdXJhdGlvbiB3aWxsIGJlIHRoZXJlIChlaXRoZXIgaW1wbGljaXQgb3Ig ZXhwbGljaXQgd2l0aCB0aGUgT0MtVmFsaWRpdHktRHVyYXRpb24gQVZQKS4NCg0KU28gaWYgc29t ZXRoaW5nIG5lZWRzIHRvIGJlIGNsYXJpZmllZCAoSSBoYXZlbid0IGNoZWNrZWQpLCBpdCBzaG91 bGQgYmUgaW4gdGhlIGhhbmRsaW5nIG9mIHRoZSBPTFIuDQoNClJlZ2FyZHMsDQoNCkxpb25lbCAN Cg0KRGXCoDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBTdGV2ZSBEb25vdmFuIEVudm95w6nCoDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDE2OjM1IMOA wqA6IGRpbWVAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtEaW1lXSBbZGltZV0gIzM2OiBPQy1WYWxp ZGl0eS1EdXJhdGlvbiBBVlANCg0KVGhpcyBjaGFuZ2UgbG9va3MgcHJldHR5IHN0cmFpZ2h0IGZv cndhcmQgdG8gbWUuwqAgSSdsbCBhZGQgaXQgdG8gdGhlIC0wMiB2ZXJzaW9uIG9mIHRoZSBkcmFm dCB1bmxlc3MgSSBoZWFyIG9iamVjdGlvbnMgc29vbi4NCg0KU3RldmUNCk9uIDIvNi8xNCA0OjQ0 IEFNLCBkaW1lIGlzc3VlIHRyYWNrZXIgd3JvdGU6DQojMzY6IE9DLVZhbGlkaXR5LUR1cmF0aW9u IEFWUA0KDQogSW4gZHJhZnQtaWV0Zi1kaW1lLW92bGktMDEgY2hhcHRlciA0LjUsIHRoZSBzdGF0 ZW1lbnQgdGhhdCBkZXNjcmliZXMgd2hlbiAgdGhlIE9DLVZhbGlkaXR5LUR1cmF0aW9uIEFWUCBu ZWVkcyB0byBiZSB1cGRhdGVkIGlzIGFtYmlndW91cy4NCg0KIE5vdzoNCiAgICBUaGUgT0MtVmFs aWRpdHktRHVyYXRpb24gQVZQIChBVlAgY29kZSBUQkQ0KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzIN CiAgICBhbmQgZGVzY3JpYmVzIHRoZSBudW1iZXIgb2Ygc2Vjb25kcyB0aGUgT0MtT0xSIEFWUCBh bmQgaXRzIGNvbnRlbnQgaXMNCiAgICB2YWxpZCBzaW5jZSB0aGUgcmVjZXB0aW9uIG9mIHRoZSBu ZXcgT0MtT0xSIEFWUCAoYXMgaW5kaWNhdGVkIGJ5IHRoZQ0KICAgIE9DLVNlcXVlbmNlLU51bWJl ciBBVlApLg0KDQogUHJvcG9zYWw6DQogICAgVGhlIE9DLVZhbGlkaXR5LUR1cmF0aW9uIEFWUCAo QVZQIGNvZGUgVEJENCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyDQogICAgYW5kIGRlc2NyaWJlcyB0 aGUgbnVtYmVyIG9mIHNlY29uZHMgdGhlIE9DLU9MUiBBVlAgYW5kIGl0cyBjb250ZW50IGlzDQog ICAgdmFsaWQgaW4gcmVsYXRpb24gdG8gdGhlIHJlY2VwdGlvbiBvZiB0aGUgZmlyc3QgT0MtT0xS IEFWUCB3aXRoIGENCiAgICBzcGVjaWZpYyBzZXF1ZW5jZSBudW1iZXIuIEZvciBhIGdpdmVuIHNl cXVlbmNlIG51bWJlciwgdGhlDQogICAgT0MtVmFsaWRpdHktRHVyYXRpb24gc2hhbGwgYWx3YXlz IGNhcnJ5IHRoZSBzYW1lIHZhbHVlLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwg T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBt YWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGltZQ0K From lionel.morand@orange.com Thu Feb 6 23:32:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEC11A05BD for ; Thu, 6 Feb 2014 23:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRcgQWyyLRCc for ; Thu, 6 Feb 2014 23:32:56 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E57DC1A05BC for ; Thu, 6 Feb 2014 23:32:55 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CF85C32461C; Fri, 7 Feb 2014 08:32:53 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B43EC27C08C; Fri, 7 Feb 2014 08:32:53 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 7 Feb 2014 08:32:53 +0100 From: To: "dime@ietf.org" , Maria Cruz Bartolome Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyh3Mk+g2dTxBkStndl7a0rG2ZqoSuqAgAAqeQCAAOmhgIAACEru Date: Fri, 7 Feb 2014 07:32:53 +0000 Message-ID: <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 07:32:59 -0000 Hi, My point is just to say that we should make the difference between the defi= nition and the use of the AVP. And about the clarification, I would say that it is rather about how to pop= ulate the OC-OLR AVP or when a new sequence number should be used. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange Maria Cruz Bartolome a =E9crit : Thanks Lionel, The comment equally applies in order to clarify when the Validity-Duration = should include a new value. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 06 de febrero de 2014 19:07 To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi Maria Cruz, Hi Maria Cruz, Steve, Be careful! The reference you are using seems to be odd. The current text in the draft says: 4.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity- Duration AVP were not present. A timeout of the overload report has specific concerns that need to be taken into account by the endpoint acting on the earlier received overload report(s). Section 4.7 discusses the impacts of timeout in the scope of the traffic abatement algorithms. As a general guidance for implementations it is RECOMMENDED never to let any overload report to timeout. Following to this rule, an overload endpoint should explicitly signal the end of overload condition and not rely on the expiration of the validity time of the overload report in the reacting node. This leaves no need for the reacting node to reason or guess the overload condition of the reporting node. I think that the definition of the OC-Validity-Duration AVP should remain i= ndependent of the notion of Sequence-Number. The sequence number does not change the value of the OC-Validity-Duration A= VP. It indicates that the OLR has to be updated or not. And if it is, a new= duration will be there (either implicit or explicit with the OC-Validity-D= uration AVP). So if something needs to be clarified (I haven't checked), it should be in = the handling of the OLR. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy= =E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: [Dime] [= dime] #36: OC-Validity-Duration AVP This change looks pretty straight forward to me. I'll add it to the -02 ve= rsion of the draft unless I hear objections soon. Steve On 2/6/14 4:44 AM, dime issue tracker wrote: #36: OC-Validity-Duration AVP In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when = the OC-Validity-Duration AVP needs to be updated is ambiguous. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP (as indicated by the OC-Sequence-Number AVP). Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From maria.cruz.bartolome@ericsson.com Thu Feb 6 23:38:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9FB1A05C5 for ; Thu, 6 Feb 2014 23:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24q7dj3ED2pE for ; Thu, 6 Feb 2014 23:38:19 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4326C1A05C2 for ; Thu, 6 Feb 2014 23:38:19 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-1e-52f48d693749 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2C.7C.10875.96D84F25; Fri, 7 Feb 2014 08:38:17 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 08:38:16 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyh3Mk+g2dTxBkStndl7a0rG2ZqoSuqAgAAqeQCAAOmhgIAACErugAAAQ9A= Date: Fri, 7 Feb 2014 07:38:16 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> In-Reply-To: <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW5m75cgg5ZWeYu5vSvYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0b3yDnvBDauKS0cuMzcwztfvYuTkkBAwkTjw6xcrhC0mceHe erYuRi4OIYFDjBKLdzcwQTiLGSV63nxjBKliE7CTuHT6BVCCg0NEQFni9C8HkLCwgIXEt51v WCDClhKnXwRDmH4S1y5lg1SwCKhI3Lr1iA3E5hXwlZjefZoFYno7s8Tzd4fBpnMK5EpcunSd GcRmBLrn+6k1TCA2s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/qPsVJdqfNjBC1OtJ3Jg6hQ3C 1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI3tuYmZOernhJkZg0B/c8lt3 B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMhlwnzzY1kP0+kr BX7/7p5I26PCnf2v59L16o0n/+9at1yR40da5BrnKZ5FZ7zt6qfP2XNn8vrczVr+vTsdAt/U 7nrHyNl253KTDe+XnVMUbpjpfDE285l9zXdHYeuZBX+SN5Y8PuO+dHHWHjFjDpP9BwuEZi5K Cagz+GGc1Hwg4/TFldaqullKLMUZiYZazEXFiQDAvd5wSAIAAA== Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 07:38:22 -0000 Hello Lionel, all, I would like to clarify what "new and fresh", or even only "new" OC-OLR AV= P mean in the text. It should be understood that it does not refer to the new (latest) received= AVP, but just the one that contains (potentially) new values, what only ha= ppens for a new Sequence Number. In that line is the proposed text I provid= ed. Best regards /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: viernes, 07 de febrero de 2014 8:33 To: dime@ietf.org; Maria Cruz Bartolome Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi, My point is just to say that we should make the difference between the defi= nition and the use of the AVP. And about the clarification, I would say that it is rather about how to pop= ulate the OC-OLR AVP or when a new sequence number should be used. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange Maria Cruz Bartolome a =E9crit : Thanks Lionel, The comment equally applies in order to clarify when the Validity-Duration = should include a new value. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 06 de febrero de 2014 19:07 To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi Maria Cruz, Hi Maria Cruz, Steve, Be careful! The reference you are using seems to be odd. The current text in the draft says: 4.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity- Duration AVP were not present. A timeout of the overload report has specific concerns that need to be taken into account by the endpoint acting on the earlier received overload report(s). Section 4.7 discusses the impacts of timeout in the scope of the traffic abatement algorithms. As a general guidance for implementations it is RECOMMENDED never to let any overload report to timeout. Following to this rule, an overload endpoint should explicitly signal the end of overload condition and not rely on the expiration of the validity time of the overload report in the reacting node. This leaves no need for the reacting node to reason or guess the overload condition of the reporting node. I think that the definition of the OC-Validity-Duration AVP should remain i= ndependent of the notion of Sequence-Number. The sequence number does not change the value of the OC-Validity-Duration A= VP. It indicates that the OLR has to be updated or not. And if it is, a new= duration will be there (either implicit or explicit with the OC-Validity-D= uration AVP). So if something needs to be clarified (I haven't checked), it should be in = the handling of the OLR. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy= =E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: [Dime] [= dime] #36: OC-Validity-Duration AVP This change looks pretty straight forward to me. I'll add it to the -02 ve= rsion of the draft unless I hear objections soon. Steve On 2/6/14 4:44 AM, dime issue tracker wrote: #36: OC-Validity-Duration AVP In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when = the OC-Validity-Duration AVP needs to be updated is ambiguous. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP (as indicated by the OC-Sequence-Number AVP). Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Fri Feb 7 00:01:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE131A0058 for ; Fri, 7 Feb 2014 00:01:37 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idTkUoTzEOhJ for ; Fri, 7 Feb 2014 00:01:35 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E40211A027D for ; Fri, 7 Feb 2014 00:01:34 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id p9so2336874lbv.20 for ; Fri, 07 Feb 2014 00:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=njHOf4ctb7uRzo9JBI55R0TJSlIw/kYCpDEGrVh40dM=; b=P3mQ+qombkngQ88vEj6U1DmIHHQXdWLD9U3pfPSRiXRNyLoNZpc5XZL1jC++yLT9Sb Hv0FJi3aWnvHA4YqdtE2kHiIqWlEZtU0iQvECQMv4zPFqIj/BThPMJ2tlaKNXeXLLYln 5Cs1IDSbvAj+QLHvy1mMDtszcjUwPFdJBobmhXH28ml+3IEDfOoScOBOrjzoBCwDsTC7 r4lt8oL4VymgvQEaAGQ3JSlVSYfDvXjeYZqbCJN/hhkS2u18+kWSJi32GZ3kkoci3DTa 3JCXxSzfo9Rvygc2YAaAO7OzitoSZS3zSppqkJUSEu7aah6hyS9xs6ZyOVwl8Tirxyeu zlkg== X-Received: by 10.152.27.100 with SMTP id s4mr9090907lag.18.1391760092744; Fri, 07 Feb 2014 00:01:32 -0800 (PST) Received: from [192.168.250.18] ([194.100.71.98]) by mx.google.com with ESMTPSA id qx7sm3962307lbb.9.2014.02.07.00.01.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 00:01:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> Date: Fri, 7 Feb 2014 10:01:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78300994-0C77-47B5-B28E-D03048916AF3@gmail.com> References: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Cc: lionel.morand@orange-ftgroup.com Subject: Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 08:01:37 -0000 Finally catching up with these.. see inline. On Feb 4, 2014, at 10:46 AM, dime issue tracker = wrote: > #29: OC-Sequence-Number in OC-Supported-Features >=20 > According to the current definition of the OC-Supported-Features AVP = in > the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence- > Number AVP. > The author of this document believes that OC-Sequence-Number within = OC- > Supported-Feature is not needed, is useless and could be misleading = and > therefore proposes to remove OC-Sequence-Number from = OC-Supported-Feature. >=20 > The -01 draft says in clause 4.1: > The OC-Sequence-Number AVP is used to indicate whether the contents > of the OC-Supported-Features AVP has changed since last time the = node > included the OC-Supported-Features AVP (see Section 4.4). Although > sending the OC-Sequence-Number AVP is mandatory in the = OC-Supported- > Features AVP, the receiving node MAY always choose to ignore the > sequence number if it can determine the feature support changes > otherwise. >=20 > The text seems to imply that the reporting DOIC endpoint, when = receiving > an application request message that contains an OC-Supported-Features = AVP, > needs to determine whether a feature support change occured (either by > checking the value of the received sequence-number (probably) against = a > stored value, or by other unspecified means). However, this is not > correct. The reporting DOIC endpoint may ignore the sequence-number = even > if it cannot determine whether or not a feature support change = occured: > The reporting DOIC endpoint simply takes the value of the OC-Feature- > Vector as received in the request into account (if absent the default > value applies) when processing the request. There is no need for the > reporting DOIC endpoint to know whether a previous request contained = the > same or a different value in OC-Feature-Vector, i.e. whether there was = a > recent change. This is true for the current default algorithm. May not be true in the future. Note, in IETF space versioning Diameter applications is not that straight forward as in 3GPP, thus I would rather have forward looking solution, even if that in places would mean "placeholder" AVPs. > It has been argued that the reporting DOIC endpoint may (optionally) > benefit from the presence of a Sequence-Number within OC-Supported- > Features: The reporting DOIC endpoint may have stored the = Sequence-Number > and Feature-Vector as received in a previous request, and when = receiving a > new request the reporting DOIC endpoint would compare the received > Sequence-Number from the new request with the stored Sequence-Number; = If > they match (i.e. no change of supported features occured) the = reporting > DOIC endpoint would ignore the received Feature-Vector from the new > request and use the stored Feature-Vector for further processing; if = they > don't match (i.e. a change of supported features occured), the = reporting > DOIC endpoint would update the stored Sequence-Number and = Feature-Vector > with the received values from the new request and use the updated = Feature- > Vector for further processing. While it is debatable whether the = described > usecase is reasonable, the following issues have not been addressed: > In configurations where the client does not support DOIC, an agent = (A1) on > a path from client to reporting DOIC endpoint (e.g. server) may take = the > role of a reacting DOIC endpoint and insert an OC-Supported-Features = AVP > in the (first) request message indicating its supported features. A > subsequent request message sent from the same client to the same = server > may take another path on which another agent (A2) takes the role of = the > reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP = in > the subsequent request message indicating its supported features = (which > may be different from A1's supported features but may have the same > sequence number). Since the reporting DOIC endpoint (e.g.server) - = when Since seq-no is NTP time, this would not happen, excluding cases where clocks either in A1 or A2 are wrong. But that is a different issue then.. > receiving the subsequent request - cannot know whether the the = reacting > DOIC endpoint that inserted the OC-Supported-Features AVP in the > subsequent request is identical to or different from the reacting DOIC > endpoint that inserted the OC-Supported-Features AVP in the first = request, Right. > it may frequently occure that the reporting DOIC endpoint receives = request > messages containing an OC-Supported-Features AVP with a = Sequence-Number > valuelower than the stored value (which may be interpreted as error), = or > equal to the stored value but with a different associated Feature = Vector, > or higher than the stored value but unmodified Feature Vector. See the above comment on the NPT. > In summary, the Sequence-Number within OC-Supported-Features is of no > earthly use since the reporting DOIC endpoint cannot associate a = received > Sequence-Number (within OC-Supported-Features) with the identity of = the > reacting DOIC endpoint that sent the Sequence-Number. Even when such > association was possible by enhancing the OC-Supported-Features AVP = with > the Diameter Identity of the reacting DOIC endpoint that generated the > Sequence-Number, it would still simply not be needed as the reporting > DOIC endpoint can base its processing on the received Feature-Vector > (rather than on a stored Feature Vector). I buy the reasoning for the lack of binding between the reacting node identity and the supported features AVP. However, we should not assume that _all_ implementations will behave as expected above i.e. not storing the feature vector. > It is therefore proposed to remove the OC-Sequence-Number AVP from the = OC- > Supported Features AVP. I have no (more) strong view here. If folks are OK to remove the seq-no, so be it. - Jouni >=20 > --=20 > = ----------------------------------------------+-------------------------- > Reporter: lionel.morand@orange-ftgroup.com | Owner: Ulrich = Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: 2.0 > Severity: Active WG Document | Keywords: > = ----------------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 00:38:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C482A1A05E4 for ; Fri, 7 Feb 2014 00:38:19 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdQqclnsHDnZ for ; Fri, 7 Feb 2014 00:38:15 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 886181A05CF for ; Fri, 7 Feb 2014 00:38:15 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id 10so876346lbg.8 for ; Fri, 07 Feb 2014 00:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3BQMUWwLeB8fmGcwdT+RentYLmctiKqYOrnhSHlMvbg=; b=k0qQPAkchJCiWI6Z0nWCyI3E0Xx63LXfZp+D3cxiHSecntn6u2Qyid9xHYBAxsRP9/ w+w91llHC48k8v8ODpOkrnBh0nkA4o/p/QxxnxxcuCGh1+UReBrvAIwVNfQhX8q3ZCb1 PaKAHPkfPYAHesF1l8ZjXJ6EblJxNDDivWVlcwOVI3OypScsetOc2726XHYQKyzTs/fQ UZT8maaVqKqn106HfChb2GvepE/8IfJF0p32sVVAuZ1bVkVL8Ng5dAgJuyHzD3sivnM7 kC8m9KFyJMkfKJWVeCbysp+Y9DcX8tiGUV8DXTLwp+J71DiA00y/vF/FMbiUH8391gBe l+wg== X-Received: by 10.152.88.82 with SMTP id be18mr9009322lab.3.1391762293482; Fri, 07 Feb 2014 00:38:13 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id th3sm4059117lbb.11.2014.02.07.00.38.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 00:38:06 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <52F02C62.70600@usdonovans.com> Date: Fri, 7 Feb 2014 10:38:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52F02C62.70600@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 08:38:20 -0000 Steve, On Feb 4, 2014, at 1:55 AM, Steve Donovan = wrote: > All, >=20 > I believe that the current DOIC Endpoint behavior definition is not = sufficiently defined, especially for agents. >=20 > There was also a change introduced in the -01 version of the draft = that implies that there can be a DOIC association that goes through a = DOIC enabled agent. This was not how I understood endpoints. The = original diagrams showed a DOIC agent as terminating an endpoint that = came to it. I suspect there were different assumptions that lead to = clearly different interpretations. =20 Yes.. one of the confusion points was how the endpoint is actually identified, specifically in a case of agents. Is=20 that done B2B fashion where the client thinks the agent is actually the server or whether the client still talks directly to the server endpoint (and the agent just keeps out of the DOIC business or participates to it if configured to do so). The modified figure attempt to cover both.. with little success apparently; lack of explaining text I would say.=20 It is definitive that more text and clarity is needed here. - JOuni > I propose that we return to the original diagrams and add the wording = below on how DOC agents behave. One way to look at this is that DOC = agents act as back-to-back DOC endpoints. I intentionally don't say = back-to-back Diameter endpoints because this does not impact anything = except the handling of DOIC related AVPs. >=20 > Note that I don't believe this requires any changes to Diameter = clients or servers. I also don't believe this requires any changes to = the contents of the DOIC related AVPs but there is an open question as = to whether there is a need to indicate when a OC-Supported-Features AVP = is generated or modified by an agent. >=20 > I propose to add the following section to the section on capabilities = announcement. I'll send a separate email proposing text to section 5.5 = on how DOC agents are to behave.=20 >=20 > Regards, >=20 > Steve >=20 > ----- >=20 > 5.3.1 DOC Agent handling of DOIC capability exchange. >=20 > A DOC agent is defined as a Diameter agent that supports the DOIC = extension. >=20 > A DOC node is defined as a Diameter client, Diameter server or = Diameter agent that supports the DOIC extension. >=20 > An downstream DOIC Association is defined as the association between = the DOIC supporting Diameter entity that sends a Diameter request = message to a DOC agent and the DOC agent. >=20 > A upstream DOIC Association is defined as the association between a = DOC agent and the Diameter entity to which the DOC agent sends the = Diameter request message. The following illustrated the upstream and = downstream concepts. >=20 > DOC node <--downstream DOIC association--> DOC agent <--upstream = DOIC association--> DOC node > Direction of request message for a transaction -----> > Direction of answer message for a transaction <----- >=20 > Four scenarios must be supported: >=20 > - Scenario 1 - There is both an upstream and downstream DOIC = association. > - Scenario 2 - There is no upstream DOIC association > - Scenario 3 - There is no downstream DOIC association > - Scenario 4 - No DOIC association in either direction >=20 > Scenario 1 - Both upstream and downstream DOIC associations >=20 > Request message handling: >=20 > A DOC agent that receives a request that contains the = OC-Supported-Features AVP must act as an endpoint for the downstream = DOIC association. >=20 > If the DOC agent relays or proxies the request message then the agent = must include an OC-Supported-Features AVP in the relayed message. The = contents of the OC-Supported-Features AVP must include, at a minimum, = all of the content included in the received OC-Supported-Features AVP. = If the agent does not support any additional features then the sent = OC-Supported-Features AVP will remain the same as the received = OC-Supported-Features AVP. >=20 > If the agent supports DOIC features that are not indicated in the = received OC-Supported-Features AVP then the agent must modify the = OC-Supported-Features AVP to indicate support for those features. The = modified OC-Supported-Features AVP must be included in the relayed = request message. >=20 > Note: any DOIC extension must define the changes needed to the = OC-Feature-Vector AVP and any additional AVPs that need to be added to = the OC-Supported-Features AVP as part of the capabilities advertisement = for that feature. >=20 > Question: Should there be an indication that the contents of the = OC-Supported-Features AVP was changed? >=20 > Question: Will this work when end-to-end security is introduced? = Would adding a separate OC-Supported-Features AVP be better, especially = when end-to-end security is considered? >=20 > Answer message handling: >=20 > When an agent receives the answer message that corresponds to the = above request message, the agent must act as the DOIC endpoint for the = upstream DOIC association. =20 >=20 > If the DOC agent relays or proxies the answer message then the agent = must include an OC-Supported-Features AVP in the relayed message. The = contents of the OC-Supported-Features AVP must include, at a minimum, = all of the content included in the received OC-Supported-Features AVP. = If the agent does not support any additional features then the sent = OC-Supported-Features AVP will remain the same as the received = OC-Supported-Features AVP. >=20 > If the agent supports DOIC features that are not indicated in the = received OC-Supported-Features AVP then the agent should modify the = OC-Supported-Features AVP to indicate support for those features. The = modified OC-Supported Features AVP must be included in the relayed = answer message. >=20 > Scenario 2 - No downstream DOIC association with an upstream = association >=20 > In this case a request is received that does not contain an = OC-Supported-Features AVP. >=20 > Request message handling: >=20 > If a DOC agent receives a request that does NOT contain an = OC-Supported-Features AVP then the agent must generate an = OC-Supported-Features AVP reflecting the DOIC features supported by the = DOC agent. The new OC-Supported-Features AVP must be included in the = relayed/proxied request message. >=20 > The agent will then become the reacting DOIC endpoint for the upstream = DOIC association that results from the transaction. =20 >=20 > Note: Section x.x.x defines agent behavior when it is the reacting = node for a DOIC association. >=20 > Answer message handling >=20 > In this case the answer message will contain an OC-Supported-Features = AVP. The DOC agent must store the advertised capabilities for use when = the DOC agent reacts to an overload report from the upstream Diameter = node. >=20 > The DOC agent should remove the OC-Supported-Features AVP from the = answer message before relaying/proxying the answer message. =20 >=20 > Scenario 3 - Downstream DOC association with no upstream DOIC = association >=20 > In this case a OC-Supported-Features AVP is received in the request = from the downstream Diameter entity but no OC-Supported-Features AVP is = received in the answer message received from the upstream Diameter = entity. In this case the agent must act as the reporting DOIC endpoint = for the downstream DOIC association. >=20 > Request message handling: >=20 > Request message handling is the same as for scenario 1. >=20 > Answer message handling: >=20 > If a DOC agent receives an answer message that does not contain an = OC-Supported-Features AVP for a transaction that includes an upstream = DOC association then the agent must generate an OC-Supported-Features = AVP reflecting the DOIC features supported by the DOC agent. The = generation of this OC-Supported-Features AVP must also follow the rules = specified in section 5.3.2. The new OC-Supported-Features AVP must be = included in the relayed/proxied the answer message. >=20 > Scenario 4 - No upstream association and no downstream association >=20 > Request message handling: >=20 > The request message handling in this case is the same as scenario 2. >=20 > Answer message handling: >=20 > If the DOC agent receives an answer message that does not contain an = OC-Supported-Features AVP for a transaction that does not include a = downstream DOC association then the agent must NOT generate an = OC-Supported-Features AVP. The DOC Agent must relay/proxy the answer = message with no DOIC related change. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 00:44:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C0F1A039F for ; Fri, 7 Feb 2014 00:44: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu82Kiyqlwy5 for ; Fri, 7 Feb 2014 00:44:26 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 60E7E1A05E8 for ; Fri, 7 Feb 2014 00:44:26 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id z11so1426966lbi.12 for ; Fri, 07 Feb 2014 00:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K6YDJpN6nhQVNpvo0t5gT1ylVWRPh5XAIfD6AYKTI1Y=; b=HB4/lm4Bg7NuCL++m3Np9/RDTMslvdj/LpHq0VVHbi5BTFrov39JmlPmkCVUmvHOHG zc3xzIR3oPnRrqKdr9MKyRhwd9l2Ae3bfFSNQuRyIjUyuGGnzmZAww9TpgIH9E8YFhPP IwxxDhRpeXn73QOCrNdH2nf+AAlah6PBUE8hC0CTnRpnJiAdWw8/pzpPeh0n99i0obvQ lz2WOgU4oBYjX/LI5MSvTN/IwayvrnGD1nC9ZzwVZ1ORLpN8aeuS4KHkr0il3jr5LBIp uJNmby2xEnQfox+VxHpXLtvVnhNgJ+Lz+LQohxNKH/PExp1clPlfJD4gqy9HVf95vev9 uY7w== X-Received: by 10.152.36.8 with SMTP id m8mr9256309laj.24.1391762664334; Fri, 07 Feb 2014 00:44:24 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id gi5sm4093044lbc.4.2014.02.07.00.44.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 00:44:14 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net> Date: Fri, 7 Feb 2014 10:44:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84E09CCD-8651-45C2-867F-6E881C2E96AA@gmail.com> References: <52F02C62.70600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 08:44:34 -0000 Gotta hate these mega long mails ;) See inline.. On Feb 4, 2014, at 3:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Steve, >=20 > please find comments inline. >=20 > Regards > Ulrich >=20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve = Donovan > Sent: Tuesday, February 04, 2014 12:55 AM > To: dime@ietf.org > Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange >=20 > All, >=20 > I believe that the current DOIC Endpoint behavior definition is not = sufficiently defined, especially for agents. > I agree. >=20 > There was also a change introduced in the -01 version of the draft = that implies that there can be a DOIC association that goes through a = DOIC enabled agent. This was not how I understood endpoints. > same with me The original diagrams showed a DOIC = agent as terminating an endpoint that came to it. I suspect there = were different assumptions that lead to clearly different = interpretations. =20 >=20 > I propose that we return to the original diagrams and add the wording = below on how DOC agents behave. One way to look at this is that DOC = agents act as back-to-back DOC endpoints. I intentionally don't say = back-to-back Diameter endpoints because this does not impact anything = except the handling of DOIC related AVPs. >=20 > Note that I don't believe this requires any changes to Diameter = clients or servers. I also don't believe this requires any changes to = the contents of the DOIC related AVPs but there is an open question as = to whether there is a need to indicate when a OC-Supported-Features AVP = is generated or modified by an agent. >=20 > I propose to add the following section to the section on capabilities = announcement. I'll send a separate email proposing text to section 5.5 = on how DOC agents are to behave.=20 >=20 > Regards, >=20 > Steve >=20 > ----- >=20 > 5.3.1 DOC Agent handling of DOIC capability exchange. >=20 > A DOC agent is defined as a Diameter agent that supports the DOIC = extension. > A Diameter agent that supports the DOIC extension is not = necessarily taking the role of a reacting DOIC endpoint. > It only takes the role of a reacting DOIC endpoint when receiving a = request that does not contain an OC-Supported-Features AVP. > Similarily a Diameter agent that supports the DOIC extensions is not = necessarily taking the role of a reporting DOIC endpoint. > It only takes the role of a reporting DOIC endpoint when receiving a = realm type request (not containing a destination host) that contains an = OC-Supported-Features AVP while it is configured to act as a reporting = DOIC endpoint for that realm. >=20 > A DOC node is defined as a Diameter client, Diameter server or = Diameter agent that supports the DOIC extension > and decided to take the role of a reacting DOIC endpoint = and/or reporting DOIC endpoint . >=20 > An downstream DOIC Association is defined as the association between = the DOIC supporting Diameter entity that sends a Diameter request = message to a DOC agent and the DOC agent. >=20 > A upstream DOIC Association is defined as the association between a = DOC agent and the Diameter entity to which the DOC agent sends the = Diameter request message. The following illustrated the upstream and = downstream concepts. >=20 > DOC node <--downstream DOIC association--> DOC agent <--upstream = DOIC association--> DOC node > Direction of request message for a transaction -----> > Direction of answer message for a transaction <----- > this depends on the point of view: one node's downstream DOIC = association is another node's upstream DOIC association. > The general case is: >=20 > +---------+ +---------+ +--------+ +--------+ = +--------+ +--------+ > | client | | A1 | | A2 | | A3 | = | A4 | | server | > | no DOIC | | no DOIC | | DOIC | | DOIC | = | DOIC | | DOIC | > | support | | support | | support| | support| = | support| | support|=20 > +---------+ +---------+ +--------+ +--------+ = +--------+ +--------+ > | | | | = | | > | | |<---DOIC association = 1------------------------->|<-------DOIC association 2-->| > | | | | = | | > | | |<-----------------DOIC = association 3----------------------------------------->| > | | | | = | | > | | | | = | | > |----1.xxR------->|---2.xxR----->| | = | | > | | = |---3.xxR----->|----4.xxR----------------------->| = | > | | | | = |--------5.xxR--------------->|=20 > | | | | = |<-------6.xxA----------------| > | | = |<--8.xxA------|<---7.xxA------------------------| = | > |<---10.xxA-------|<--9.xxA------| | = | | > | | | | = | | > | | | | = | | > | | | | = | | > | | | | = | | > |----11.xxR------>|---12.xxR---->| | = | | > | | = |---13.xxR---->|-----14.xxR--------------------->|-------15.xxR-----------= ---->| > | | | | = | | > | | = |<---18.xxA----|<----17.xxA----------------------|<-----16.xxA------------= -----| > |<---20.xxA-------|<---19.xxA----| | = | | > | | | | = | | > DOIC association 1 is for realm type requests;=20 > DOIC association 2 is for request for which A4 selects the server > DOIC association 3 is for host type requests >=20 > 1. the client that does not support DOIC sends 1.xxR (realm type = request not containing destination host) to the next hop; 1.xxR does not = contain an OC-Supported-Features AVP > 2. the agent A1 that does not support DOIC forwards the request to the = next hop; 2.xxR still dos not contain an OC-Supported-Feature AVP. > 3. the agent A2 that supports DOIC decides to take the role of a = reacting endpoint; it inserts an OC-Supported-Features AVP into 3.xxR = indicating support of features 1 and 2 (in this example). > 4. agent A3, although it supports DOIC, does not take the role of a = reacting endpoint (because 3.xxR contains an OC-Supported-Features AVP); = it also does not take the role of a reporting endpoint since it is not = configured to act as reporting endpoint for the destination realm = received in 3.xxR; 4.xxR (unmodified) is sent to the next hop. > 5. agent A4 is configured to take the role of the reporting endpoint = for the realm. It therefore removes the OC-Supported-Features AVP = reveived in 4.xxR and inserts its own supported features (in this = example features 1 and 3) in 5.xxR. A4 also selects the server to which = 5.xxR is sent. > 6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA = including an OLR1 (host type) requesting a feature 3 specific traffic = reduction (e.g. window size 20).=20 > 7. A4 calculates the overall realm overload level, removes the = received OLR1 and adds its own calculated realm type OLR2 (e.g. a = feature 1 specific traffic reduction of 50%-loss) to 7.xxA. A4 stores = OLR1 for later use. > 8. A3 not taking any DOIC role forwards the answer unmodified. > 9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores = OLR2 for later use. > 10. A1 not supporting DOIC is transparent. > 11. client sends a new request 11.xxR (containing destination host as = learnd from 10.xxA; no OC-Supported-Features AVP included. > 12. A1 is transparent. > 13. A2 decides to take the role of the reacting endpoint and includes = again its supported features 1 and 2 in OC-Supported-Features AVO sent = within 13.xxR. > 14. A3 is transparent > 15. A4 is transparent for host type requests that contain an = OC-Supported-Features AVP. > 16. server returns 16.xxA including a host type OLR3 requesting a = feature 1 specific traffic reduction of e.g. 30%-loss. > 17. A4 is transparent > 18. A3 is transparent > 19. A2 stores OLR3 for later use and may remove OLR3 when sending = 19.xxA. > 20. client receives 20.xxA. > Thanks for the diagram. It is pretty thorough. >=20 > Four scenarios must be supported: >=20 > - Scenario 1 - There is both an upstream and downstream DOIC = association. > for example see A4 in the figure above > - Scenario 2 - There is no upstream DOIC association > do you mean "There is a downstream DOIC association but no = upstream DOIC association"? Not covered in the figure above. > - Scenario 3 - There is no downstream DOIC association > do you mean "There is an upstream DOIC association but no = downstream DOIC association"? for example see A2 in the figure above = =20 > - Scenario 4 - No DOIC association in either direction > for example see A3 in the figure above >=20 > Scenario 1 - Both upstream and downstream DOIC associations >=20 > Request message handling: >=20 > A DOC agent that receives a request that contains the = OC-Supported-Features AVP must act as an endpoint for the downstream = DOIC association. > NO! see A3 receiving 3.xxR or 13.xxR (this may not be = scenario 1, but how does the agent know which scenario = applies?) >=20 > If the DOC agent relays or proxies the request message then the agent = must include an OC-Supported-Features AVP in the relayed message. The = contents of the OC-Supported-Features AVP must include, at a minimum, = all of the content included in the received OC-Supported-Features AVP. = If the agent does not support any additional features then the sent = OC-Supported-Features AVP will remain the same as the received = OC-Supported-Features AVP. > There cannot be more than one OC-Supported-Features AVPs in = one request. An agent that inserts an OC-Supported-Features AVP must = remove the received OC-Supported-Features AVP (see A4 when sending = 5.xxR). The inserted OC-Supported Features AVP shall indicate the = features the inserting node supports, not more, not less >=20 > If the agent supports DOIC features that are not indicated in the = received OC-Supported-Features AVP then the agent must modify the = OC-Supported-Features AVP to indicate support for those features. The = modified OC-Supported-Features AVP must be included in the relayed = request message. >=20 > Note: any DOIC extension must define the changes needed to the = OC-Feature-Vector AVP and any additional AVPs that need to be added to = the OC-Supported-Features AVP as part of the capabilities advertisement = for that feature. >=20 > Question: Should there be an indication that the contents of the = OC-Supported-Features AVP was changed? > no. for what reason? >=20 > Question: Will this work when end-to-end security is introduced? = Would adding a separate OC-Supported-Features AVP be better, especially = when end-to-end security is considered? > what is the issue? With e2e security, modified AVPs fail the integrity check and therefore are subject to be rejected.. >=20 > Answer message handling: >=20 > When an agent receives the answer message that corresponds to the = above request message > i.e. the request message into which the agent has inserted = its OC-Supported-Features AVP > , the agent must act as the DOIC endpoint for the upstream DOIC = association. =20 >=20 > If the DOC agent relays or proxies the answer message then the agent = must include an OC-Supported-Features AVP in the relayed message. > OC-Supported-Features AVP in answer messages is an open issue = I don't think this is an open issue.. we already had supported features in answers covered Section 5.3. > The contents of the OC-Supported-Features AVP must include, at a = minimum, all of the content included in the received = OC-Supported-Features AVP. If the agent does not support any additional = features then the sent OC-Supported-Features AVP will remain the same as = the received OC-Supported-Features AVP. >=20 > If the agent supports DOIC features that are not indicated in the = received OC-Supported-Features AVP then the agent should modify the = OC-Supported-Features AVP to indicate support for those features. The = modified OC-Supported Features AVP must be included in the relayed = answer message. >=20 > Scenario 2 - No downstream DOIC association with an upstream = association > wasn't that scenario 3? >=20 > In this case a request is received that does not contain an = OC-Supported-Features AVP. >=20 > Request message handling: >=20 > If a DOC agent receives a request that does NOT contain an = OC-Supported-Features AVP then the agent must generate an = OC-Supported-Features AVP reflecting the DOIC features supported by the = DOC agent. The new OC-Supported-Features AVP must be included in the = relayed/proxied request message. >=20 > The agent will then become the reacting DOIC endpoint for the upstream = DOIC association that results from the transaction. =20 >=20 > Note: Section x.x.x defines agent behavior when it is the reacting = node for a DOIC association. >=20 > Answer message handling >=20 > In this case the answer message will contain an OC-Supported-Features = AVP. The DOC agent must store the advertised capabilities for use when = the DOC agent reacts to an overload report from the upstream Diameter = node. >=20 > The DOC agent should remove the OC-Supported-Features AVP from the = answer message before relaying/proxying the answer message. =20 >=20 > Scenario 3 - Downstream DOC association with no upstream DOIC = association > wasn't this scenario 2? >=20 > In this case a OC-Supported-Features AVP is received in the request = from the downstream Diameter entity but no OC-Supported-Features AVP is = received in the answer message received from the upstream Diameter = entity. In this case the agent must act as the reporting DOIC endpoint = for the downstream DOIC association. > this is totally new to me. Where does this come from? If a = server does not support DOIC it cannot request load reduction from a = downstream agent. The downstream agent (even if it would detect the = DOIC-non-support of the server) cannot request load reduction from = further downstream nodes on behalf of the server >=20 > Request message handling: >=20 > Request message handling is the same as for scenario 1. >=20 > Answer message handling: >=20 > If a DOC agent receives an answer message that does not contain an = OC-Supported-Features AVP for a transaction that includes an upstream = DOC association then the agent must generate an OC-Supported-Features = AVP reflecting the DOIC features supported by the DOC agent. The = generation of this OC-Supported-Features AVP must also follow the rules = specified in section 5.3.2. The new OC-Supported-Features AVP must be = included in the relayed/proxied the answer message. >=20 > Scenario 4 - No upstream association and no downstream association >=20 > Request message handling: >=20 > The request message handling in this case is the same as scenario 2. >=20 > Answer message handling: >=20 > If the DOC agent receives an answer message that does not contain an = OC-Supported-Features AVP for a transaction that does not include a = downstream DOC association then the agent must NOT generate an = OC-Supported-Features AVP. The DOC Agent must relay/proxy the answer = message with no DOIC related change. >=20 > the open issue seems to be: How can an agent determine which = scenario is applicable? Let me try: > An agent that does not support DOIC is always in scenario 4 (no = upstream DOIC association, no downstream DOIC association). > For an agent that supports DOIC: > When receiving a request that does not contain an = OC-Supported-Features AVP the agent is in scenario 3 or 4 (no downstream = DOIC association). Whether its 3 or 4 depends on whether or not an OLR = is received in the corresponding answer. > When receiving a host type request (a request that contains a = Destination-Host AVP) that contains an OC-Supported-Feature AVP the = agent is in scenario 4 (no upstream DOIC association, no downstream DOIC = association) > When receiving a realm type request (a request that does not contain a = Destination-Host AVP) that contains an OC-Supported-Feature AVP and the = agent is configured to act as reporting node for that realm, the agent = is scenario 1 or 2 (there is a downstream DOIC association). Whether its = 1 or 2 depends on whether or not an OLR is received in the corresponding = answer. > When receiving a realm type request (a request that does not contain a = Destination-Host AVP) that contains an OC-Supported-Feature AVP and the = agent is configured not to act as reporting node for that realm, the = agent is in scenario 4 (no upstream DOIC association, no downstream DOIC = association). I tend to agree most of assertions. However, I need to reread this mail/proposal a couple of time since my attention span has = difficulties with very long mails :) - Jouni >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 01:45:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A781A05E5 for ; Fri, 7 Feb 2014 01:45:13 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31hmE4BjMUwW for ; Fri, 7 Feb 2014 01:45:11 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 282AB1A05E6 for ; Fri, 7 Feb 2014 01:45:10 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so2439826lbj.17 for ; Fri, 07 Feb 2014 01:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=78KdxZ+/vNKH2Tr81vNr38ctxvvOXGevofIWhNKqfQE=; b=AfG+ACTcFHXO7em60htF53nhfOPb4qeypsbtuBl0FOSoNsrup2cIi+C36YYV56BmP1 eGwkcyjeINmwdDyUdwBp/WbCEfyYTGizrsxm9drbWcy/thDpCfp4OZxR6JjKp4aKhBfc x3bXAh3iitZ9oJoLKW9NelOTZyT0Pw23ky/9iFrsVpg7xsxxTb5qlPvIj5xZIo+44ysR kdHJrnrgIUypMrsKSxa0/XXBBv/sEPdl94BQpbG1MDh4mKW8F3MuYBnOfchqD4oFbxdv TfwsqZyDurEYTfsLvu1RDnmUk2O5zODIeoO+3dQhM4G5jFNosR5j1xeupH4gGd6B/MaB EYKQ== X-Received: by 10.112.204.104 with SMTP id kx8mr8852483lbc.12.1391766309074; Fri, 07 Feb 2014 01:45:09 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id yq2sm5946300lab.3.2014.02.07.01.45.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 01:45:07 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <52F0EB22.8090804@usdonovans.com> Date: Fri, 7 Feb 2014 11:45:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80E5E47E-9AD1-432F-9CA5-BA7D3D73D894@gmail.com> References: <52F0EB22.8090804@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC endpoint behavior - Agent Overload Report handling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 09:45:13 -0000 Comments inline: On Feb 4, 2014, at 3:29 PM, Steve Donovan = wrote: > The following wording is proposed to be added to section 5.5 on = Overload Report Processing. >=20 > This goes along with the proposed wording for agent involvement in = capability exchange. >=20 > The most important piece of behavior proposed is for the case when the = agent is a back-to-back DOIC association agent as illustrated here: >=20 > DOC node <--downstream DOIC association--> DOC agent <--upstream = DOIC association--> DOC node >=20 > In this case, it is proposed that when the DOC agent receives a host = or realm overload report the DOC agent simply passes it on without = taking further action. The goal being to do the overload abatement as = close to the source of the request as possible. >=20 > The text isn't perfect yet, but I wanted to get the basic behavior = proposal across. >=20 > Regards, >=20 > Steve >=20 > 5.5.4 Agent Considerations >=20 > As discussed in section x.x.x, agents can take on the role of = reporting node and reacting node. >=20 > Agent as reporting node >=20 > A DOC agent will take on the role of a reporting node any time that = there is a downstream DOIC association. >=20 > For the report types supporting in this document, an agent should only = originate an overload report in two cases: >=20 > - When the agent is acting as overload authority for a set of servers. = In this case, requests are sent to the destination-host of the agent = and the agent is responsible for reporting on the overload state when = the server farm represented by that destination-host value is entering = an overloaded condition. Makes sense and is inline what I originally thought. > - When the agent is acting as overload authority for a realm. In this = case, the agent is responsible for inserting realm based overload = reports into answer messages from servers in that realm. Ok. > Agent as reacting node >=20 > An agent will take on the role of a reacting node whenever there is an = upstream DOIC association. In this case, the agent will be reacting to = host overload reports. >=20 > The behavior of the agent acting as a reacting node depends on whether = or not there is a downstream association. >=20 > If there is a downstream DOIC association then the DOC agent should = pass any overload report on to the downstream Diameter node without = taking any further action. >=20 > Note: This is based on the assumption that it is best to handle the = overload instance as close to the source of the Diameter transaction as = possible. >=20 > Note: This is not a must because there could be operator specific = policies that result in handling of the overload condition in the agent. I kind of agree Ulrich's concern here. If the two associations have different supported features some modifications may be needed on the OLRs. However, I also think the "the DOC agent should pass any" is enough to cover the case Ulrich points at, assuming we note the case where downstream and upstream associations have different capabilities. >=20 > If there is no downstream DOIC association then the DOC agent is = responsible for handling the overload condition. In this case the DOC = agent must throttle requests targeted for the host or realm indicated in = the overload report. The method used should be consistent with the = considerations outlined in section 5.5.2. Ok. - Jouni >=20 > When a request message is selected for throttling, the DOC agent must = generate the appropriate error response message. >=20 > Editors note: the error message to be sent is TBD. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Feb 7 01:59:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995A91A05E2 for ; Fri, 7 Feb 2014 01:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd5cRLM2b-Lo for ; Fri, 7 Feb 2014 01:59:26 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC091A05C7 for ; Fri, 7 Feb 2014 01:59:25 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s179xKJt000888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2014 10:59:20 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s179xKim023403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 10:59:20 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Feb 2014 10:59:19 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 10:59:19 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "ext lionel.morand@orange.com" , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifECAAAXaAIAADfeAgAAEaQCAASwPUP//+iEAgAADQgCAABZZ8IAAVmMAgAE5EdA= Date: Fri, 7 Feb 2014 09:59:19 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 17822 X-purgate-ID: 151667::1391767160-00001A6F-ACB5B3A9/0-0/0-0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 09:59:29 -0000 TmlyYXYsDQoNCkknbSBhZnJhaWQgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3Qg dGhlIGludGVudGlvbi4NCg0KIndoZW4gaXQgd2FudHMgdG8gcHJvdmlkZS91cGRhdGUuLi4uaXQg c2hhbGwgaW5jbHVkZS4uLiIgdHJhbnNsYXRlcyB0byAiLi4uaXQgbWF5IGluY2x1ZGUuLi4iLg0K DQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gIndo ZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQpXZSBoYXZlIHRo ZSBmb2xsb3dpbmcgY2FzZXM6DQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUg cmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCmIpIHRoZSByZXBv cnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0 bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhh dCB3aWxsIHNvb24gZXhwaXJlDQpjKSBvdGhlcndpc2UNCg0KaW4gY2FzZSBhKSB0aGUgcmVwb3J0 aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFINCmluIGNhc2UgYikgdGhlIHJl cG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5vZGUgd2l0 aCB0aGUgbGF0ZXN0IE9MUg0KaW4gY2FzZSBjKSB0aGUgcmVwb3J0aW5nIG5vZGUgTVVTVCBpbmNs dWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9ydGluZyBub2RlIGRvZXMgbm90IGtu b3cgd2hldGhlciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0ZSkNCg0KVWxyaWNoDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90 KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2 LCAyMDE0IDQ6NDkgUE0NClRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQg bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv dHRsaW5nDQoNClVscmljaCwNCg0KSXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0 IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC4NCkhv dyBhYm91dCB0aGUgZm9sbG93aW5nLg0KDQpXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0 byBwcm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJs aWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQg c2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWlu aW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyBy ZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhl IHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFs cmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBt YXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFp bmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011 bmljaCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMDYsIDIwMTQgMzo1NyBQTQ0KVG86IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207 IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0K U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQoNCk5pcmF2LCBMaW9uZWwsDQoNCkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJu IChhbHRob3VnaCB2aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRo ZSBtb2RpZmllZCBwcmluY2lwbGUgMic6DQoNCjInLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1h dHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4g YW4gT0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBw b3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBh bHJlYWR5IGhhcyBnb3QgcmVhc29uYWJsZSBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0aW9uIChl LmcuIHRoZSBsYXRlc3QgT0xSLCB3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZp YyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIiwgb3IgYW4gb2xk ICBidXQgc29vbiBleHBpcmluZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92 ZXJsb2FkZWQpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVw b3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJl dHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBP Qy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxzIGRv LXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29yayB3 aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5nIG5v ZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50IG92 ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRlIE9MUnMuDQoNClVscmljaCAgDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IGxpb25lbC5tb3JhbmRAb3Jhbmdl LmNvbSBbbWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbV0gDQpTZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgV2ll aGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg dGhyb3R0bGluZw0KDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBEaU1F IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90 IChuc2Fsb3QpDQpFbnZvecOpwqA6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOA0Kw4DCoDog V2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVA aWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk IGEgdGhyb3R0bGluZw0KDQpVbHJpY2gsDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgZm9yY2luZyB0 aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2RlICJvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMg bm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJs b2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3Rz IHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KVGhlIHJlcG9y dGluZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVh cmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxs IHN0b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy4NCg0KW0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29y ZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBk ZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBk ZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhl IGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15 IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4NCg0KQXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVyLCB0 aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBzdG9w IHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIEluIG90 aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4cGly eSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcgdHJh ZmZpYyB0b3dhcmRzIGl0Lg0KDQpbTE1dIEFncmVlDQoNClRoZXJlIG1heSBiZSBvdGhlciBjYXNl cywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJs b2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMg bm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92 ZXJsb2FkIGNvbmRpdGlvbi4NCg0KW0xNXSBBZ3JlZQ0KDQpSZXN0IG9mIHRoZSBwcmluY2lwbGVz IGJlbG93IGFyZSBmaW5lIHdpdGggbWUuDQoNCltMTV0gQWdyZWUNCg0KUmVnYXJkcywNCk5pcmF2 Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2llaGUsIFVscmljaCAoTlNO IC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXSANClNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNDQpUbzogZXh0IFN0ZXZlIERvbm92YW47IE5p cmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtk aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQWN0dWFsbHkgd2Ugc2Vl bSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxlczoNCjEuIExhY2sgb2YgT0xSIG1lYW5zICJubyBj aGFuZ2UiDQoyLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2Fk ZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRv IHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYg aXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgdGhlIGxh dGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlv biBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiKTsgb3RoZXJ3aXNlIChpLmUuIGlm IGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhl ciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byBy ZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQpD YW4gcGVvcGxlIHBsZWFzZSBjb25maXJtLg0KDQpVbHJpY2gNCg0KRnJvbTogRGlNRSBbbWFpbHRv OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuDQpT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE0NClRvOiBOaXJhdiBTYWxv dCAobnNhbG90KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMx OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkFncmVlZC7CoCBUbyByZXN0YXRlIC0t IGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBv dmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhvc3Qgb3IgcmVhbG0uwqAgSWYgdGhlcmUgaXMgYSBjdXJy ZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IGNvbnRpbnVlcyB0byBhcHBseSB1 bnRpbCBpdCBlaXRoZXIgdGltZXMgb3V0IG9yIGlzIGV4cGxpY2l0bHkgY2hhbmdlZCB3aXRoIGEg bmV3IG92ZXJsb2FkIHJlcG9ydC7CoCBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92 ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhl cmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS4NCg0KU3RldmUNCk9uIDIv NS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToNCkkgYWdyZWUgd2l0aCBT dGV2ZSBleGNlcHQgdGhlIHBhcnQgInNob3VsZG7igJl0IGxhY2sgb2YgT0xSIGJlIGludGVycHJl dGVkIGFzIG5vdCBvdmVybG9hZGVkPyINCsKgDQpXZSBoYWQgc29tZSBkaXNjdXNzaW9uIHNvbWV0 aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhhdCBpdCBpcyByZWFzb25hYmxlIHRvIG5vdCBtYW5kYXRl IHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlLiBF LmcuIHdoZW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9mIHRyYWNraW5nIHdoYXQgaXMgc2VudCB0 byB3aGljaCBjbGllbnQgYW5kIGhlbmNlIHdhbnRzIHRvIGF2b2lkIHNlbmRpbmcgaW5mb3JtYXRp b24gd2hpY2ggaXMgcmVkdW5kYW50LiBCdXQgdGhpcyBpcyBvcHRpb25hbCBpbXBsZW1lbnRhdGlv biBhbmQgYXQgdGhlIHNhbWUgdGltZSBuZWVkIG5vdCBiZSBwcm9oaWJpdGVkIGZyb20gcHJvdG9j b2wgcG9pbnQgb2Ygdmlldy4NCsKgDQpTbyBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91 bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5n IG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBv bGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4g dGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQpJ biBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3IgZmxleGlibGUgaW1wbGVtZW50YXRpb24gYXQgdGhl IHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBoYW5kbGluZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5n IG5vZGUuDQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCkZyb206IERpTUUgW21haWx0bzpkaW1l LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBXZWRu ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6MDAgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN CsKgDQppbmxpbmUNCk9uIDIvNS8xNCA3OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N dW5pY2gpIHdyb3RlOg0KT2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBN VVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3Jy ZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQt RmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS4N ClNSRD4gV2h5IGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlP8KgIFNob3VsZG4ndCBsYWNrIG9mIGFu IE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD8NCg0KDQrCoA0KwqANCk90aGVy IGNyaXRlcmlhIGxpa2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLg0KU1JE PiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVj dGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29r IGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBp cyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBl bnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4NCg0KDQrCoA0KwqANCkZvciBteSBjbGFyaWZpY2F0 aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHBy b2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55 d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGlu IG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhl IHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/DQpTUkQ+IFRo YXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJlci7CoCANCg0KDQrCoA0KwqAN CsKgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KQ0K U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNDQpUbzogbGlvbmVsLm1v cmFuZEBvcmFuZ2UuY29tOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQpJIHNoYXJlIHRoZSBzYW1l IG9waW5pb24gYXMgTGlvbmVsLg0KwqANClJlZ2FyZHMsDQpOaXJhdi4NCsKgDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0KU2VudDogVHVlc2RheSwg RmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkg dW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5v ZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLiANClNvIHRoZSBvcHRp b25zIHdvdWxkIGJlOg0KMS0gT0MtT0xSIEFWUCBpbiBldmVyeSBhbnN3ZXINCjItIE9DLU9uZ29p bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICsgT0MtT0xSIEFWUCBpbiBz b21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBj bGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4NCsKgDQpJZiB0aGVyZSBpcyBubyBvdGhlciBjcml0 ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0aGUgYmVzdCBhcHByb2FjaC4NCsKgDQpMaW9uZWwN CsKgDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IGRpbWUgaXNzdWUgdHJhY2tl ciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0KRW52b3nDqcKgOiBtYXJk aSA0IGbDqXZyaWVyIDIwMTQgMDk6NDkNCsOAwqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PC oDogZGltZUBpZXRmLm9yZw0KT2JqZXTCoDogW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg dGhyb3R0bGluZw0KwqANCiMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCiBJ dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu Zm8gQVZQIHRoYXQgaXPCoCB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRw b2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXTCoCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuIFRo aXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBTZXF1ZW5jZS1OdW1iZXINCiAoVGltZVN0YW1wKSBv ZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQog c3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhh dCBjdXJyZW50bHkgbm/CoCB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC7CoCBSZXBvcnRpbmcgRE9J QyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzwqAgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0ZWN0 IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGXCoCByZWFjdGluZyBET0lDIGVu ZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuDQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1l Y2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZcKgIHJlcG9ydGluZyBub2Rl IHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9J Q8KgIGVuZHBvaW50IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9p bnQgaXMgYWN0dWFsbHkgZG9pbmfCoCB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhy b3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVz IHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQ8KgIGVuZHBvaW50IHRv IGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJvcHJpYXRlIHRocm90dGxpbmcgYnkgdGhlIHJlYWN0 aW5nwqAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQogVGhlIGZl ZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3 MDY4Lg0KIEluIHN1bW1hcnkgaXQgaXMgcHJvcG9zZWQgdG8gZGVmaW5lIHRoZSBPQy1PbmdvaW5n LVRocm90dGxpbmctSW5mbyBBVlAgdG/CoCBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQrCoA0KwqANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp Lg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0K From jouni.nospam@gmail.com Fri Feb 7 02:04:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954A01A05E2 for ; Fri, 7 Feb 2014 02:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXJK0ANgiTUo for ; Fri, 7 Feb 2014 02:04:35 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id CA0D21A05C7 for ; Fri, 7 Feb 2014 02:04:34 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id c6so2409150lan.24 for ; Fri, 07 Feb 2014 02:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lvhN5XwNmbtg98xDuaq+P2TGcN2HqogdBBexu+SgDZU=; b=EK8tVOXRZaAlIoPEGtBNCjpiDbh7g3/8c0CLytqIpCqmpvALI8pxYA/+FfT3fZuAv/ /67OkicTcr74BPpBE5c1asVD00hbtE62CaJX5vakYXLzfKf2RL/kFI5pltmR9K2jFpFi +b3HCkfapmSAvspDVxl1fm3DKjJhCpOrjiW4uaIQkgec06X/SOQ9hTzi/DrFXH5dH7LO RgQ8ciImZpUgYS4jvs6I4rgWTJ0X2OIJD7v3Pn08LIDVsBSXaN+0aBmuk3AVlmobMS18 3SKxvhqbJIH8HTpWDV5ckV2mKgJRu6p4KA7UL5qpOzOHVHo02gpykkXlF0bJ+kgPV8f4 9kcA== X-Received: by 10.152.205.11 with SMTP id lc11mr9398812lac.29.1391767472750; Fri, 07 Feb 2014 02:04:32 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id 10sm6013703lan.5.2014.02.07.02.04.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:04:21 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 7 Feb 2014 12:04:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:04:36 -0000 On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote: > I think that there is actually an issue here but the proposed way to = solve it is not the correct one. Agree. > The initial idea was to be able to use the same overload report with = several algorithms. So the OLR was somehow only meaningful along with = the OC-Feature-Vector AVP. The initial idea was to go on lines of RFC5447. > But because the OC-Feature-Vector AVP is defined as a set of flags, it = is not possible to say that this OLR is to be used with only one given = algo when more than one is defined (as the bit flags will advertize 1 = AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to = indicate the abatement to perform. My intention was always allow: client announces ABC server supports BCD server announced only e.g. C since it is common alternatively server announced nothing and then the default applies > As the syntax of the OC-Feature-Vector is adapted to advertize = supported algos, it could be easier to clarify that the OC-OLR AVP is = THE report AVP for the reduction algo (default) and a new dedicated = report AVP must be created when a new algo is introduced. In this way, = the OC-OLR is self-explicit. Bah. OLR should work for additional abatement algorithms IF we agree that the OLR is align with the announced abatement algorithm..=20 > It would be purely optional to send the Supported-Features AVP along = with the OC-OLR AVP. It is already today if you only support the default, right. - Jouni >=20 > Lionel=20 >=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #30: OC-Supported-Features AVP in answer messages >=20 > #30: OC-Supported-Features AVP in answer messages >=20 > According to the current feature advertisement/negotiation mechanism = in > the -01 draft reporting DOIC endpoint insert an OC-Supported-Features = AVP > in answer messages to indicate their supported OC features to the = reacting > DOIC endpoint. > The author of this document believes that the best a reacting node = can do > with such information is to ignore it, and therefore proposes to allow > reporting nodes not to insert OC-Supported-Features AVPs in answer > messages. > Currently only one feature is defined (OLR_DEFAULT_ALGO). > A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no = other > feature is only interested in receiving/not receiving OC-OLR AVPs from > reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates > support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not = receiving > an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >=20 > a) There is no overload > b) DOIC is not supported >=20 > The reacting DOIC endpoint does not need to differentiate between = these > two cases as the behavior (do not throttle) is the same in both cases. > The -01 draft says in clause 4.1: > If there is no single matching > capability the reacting node MUST act as if it does not implement > DOIC and cease inserting any DOIC related AVPs into any Diameter > messages with this specific reacting node. >=20 > This however is inconsistent. > The reacting node that ceases sending DOIC related AVPs would never > recognize when the server is upgraded to support DOIC. > Subsequent requests (not including DOIC related AVPs) may take a = different > path towards the server and on that path there may be an agent that > supports DOIC (with a match of supported features) and could take the = role > of the reporting DOIC endpoint; but the agent cannot take this role = since > the reacting node (although supporting DOIC) ceased sending of OC- > Supported-Features AVPs. > In summary: As long as no extension feature is defined within = draft-ietf- > dime-ovli (i.e. never, since extensions will be defined in other > drafts), there is no need for draft-ietf-dime-ovli to mandate or even > describe inclusion of OC-Supported-Features AVP in answer messages. >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 02:09:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E80E1A036B for ; Fri, 7 Feb 2014 02:09:59 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGyZYgRpHx1B for ; Fri, 7 Feb 2014 02:09:56 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE371A01FB for ; Fri, 7 Feb 2014 02:09:55 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so2486327lbd.1 for ; Fri, 07 Feb 2014 02:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XMTpNaTr1cK4WrXlwBhKOtq89v2aeDF7jgDxilWgDrM=; b=zb6mx65XtxIY5zzcOapAI0useRlVUQhquDPF3eZrPaBSHcHKjIrhcBMkZMw1efeQSr Rv0lmegpzRZbd4Z7rkjFnwgWi2yWyWN/1kDUwA1uTUZKU4DjdFwzhY1THHWf4vh0socC sqQWzuZbPieMz4CwATbfk9NMpX4tzUBIgg/+l0AUaq/tQSk7Iv0TBOFnpqGe8fJDth5C FmMuZmp6oR4H2w6ovzALLV8XWBRY++ezCnX5dktewMvo1eHglVsY0RuaKhOCrMALZxS7 4CLmh1f8o7ApmoZjvPMhhc1GB86/B8S85pWl73cmuP9bW21CjZ89+XQ7Iu0HPG41/W9L r6lA== X-Received: by 10.152.19.66 with SMTP id c2mr431095lae.54.1391767793816; Fri, 07 Feb 2014 02:09:53 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id th3sm4316838lbb.11.2014.02.07.02.09.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:09:03 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1F71@DEMUMBX014.nsn-intra.net> Date: Fri, 7 Feb 2014 12:09:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> <7610_1391532667_52F11A7B_7610_3074_1_6B7134B31289DC4FAF731D844122B36E4774C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1F71@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:09:59 -0000 On Feb 5, 2014, at 10:03 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Hi Loinel, >=20 > it seems that we can safely remove OC-Supported-Feature AVP from = answer messages in the draft-ietf-dime-ovli (which does not define = extensions to itself). This does not mean that a future extension cannot = (re)-introduce it when needed. It also does not mean that reporting = nodes are not allowed to include it in answer messages as long as answer = messages have a *[AVP]. Not so fast. Leaving OC-Supported-Feature AVP away from the=20 answer is already supported by the -01. So there is nothing to fix in that part. The thing that need to be fixed is the inconsistency on you pointed out which would make reacting node not to send any DOIC AVPs. - JOuni >=20 > Best regards > Ulrich >=20 > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20= > Sent: Tuesday, February 04, 2014 5:51 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: RE: [dime] #30: OC-Supported-Features AVP in answer messages >=20 > Hi Ulrich, >=20 > For the point 2 and 3, the difference between the "Should" and the = "May" is quite subtle here and is for me only an implementation option. >=20 > For 4 and 5, ok if the node only supports the default algo. In other = words, only the OLR matters for nodes supporting only the default algo. = The rest is purely for information and can be safely ignored. >=20 > For 6, if the new feature consists in a new algo, it would mean = defining a new dedicated OLR AVP. So nodes supporting only the default = algo will ignore any unknown AVP if received. >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 17:04 > =C0 : MORAND Lionel IMT/OLN; dime@ietf.org > Objet : RE: [dime] #30: OC-Supported-Features AVP in answer messages >=20 > Dear Lionel, >=20 > thank you for your response. >=20 > If I correctly understand, the principles would be: > 1. Sending OC-Supported-Features in answer messages is syntactically = optional. > 2. When the reacting node does only support OLR_DEFAULT_ALGO , the = reporting node should not insert an OC-Supported-Features AVP in the = answer message. > 3. When the reporting node does only support OLR_DEFAULT_ALGO, it = should not insert an OC-Supported-Features AVP in the answer message. > 4. A reacting node that supports only OLR_DEFAULT_ALGO can safely = ignore OC-Supported-Features AVPs received in answer messages. > 5. A reacting node that supports only OLR_DEFAULT_ALGO can safely = ignor all extensions received in an OC-OLR. > 6. When a new feature is introduced, the spec introducing the new = feature must define the details to ensure interoperability of nodes = supporting the new feature with nodes that do not support the new = feature (taking into account that nodes not supporting the new feature = act according to the principles 1.-5.). >=20 >=20 > Best regards > Ulrich >=20 >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext = lionel.morand@orange.com > Sent: Tuesday, February 04, 2014 4:01 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer = messages >=20 > I think that there is actually an issue here but the proposed way to = solve it is not the correct one. > The initial idea was to be able to use the same overload report with = several algorithms. So the OLR was somehow only meaningful along with = the OC-Feature-Vector AVP. >=20 > But because the OC-Feature-Vector AVP is defined as a set of flags, it = is not possible to say that this OLR is to be used with only one given = algo when more than one is defined (as the bit flags will advertize 1 = AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to = indicate the abatement to perform. >=20 > As the syntax of the OC-Feature-Vector is adapted to advertize = supported algos, it could be easier to clarify that the OC-OLR AVP is = THE report AVP for the reduction algo (default) and a new dedicated = report AVP must be created when a new algo is introduced. In this way, = the OC-OLR is self-explicit. >=20 > It would be purely optional to send the Supported-Features AVP along = with the OC-OLR AVP. >=20 > Lionel=20 >=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #30: OC-Supported-Features AVP in answer messages >=20 > #30: OC-Supported-Features AVP in answer messages >=20 > According to the current feature advertisement/negotiation mechanism = in > the -01 draft reporting DOIC endpoint insert an OC-Supported-Features = AVP > in answer messages to indicate their supported OC features to the = reacting > DOIC endpoint. > The author of this document believes that the best a reacting node = can do > with such information is to ignore it, and therefore proposes to allow > reporting nodes not to insert OC-Supported-Features AVPs in answer > messages. > Currently only one feature is defined (OLR_DEFAULT_ALGO). > A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no = other > feature is only interested in receiving/not receiving OC-OLR AVPs from > reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates > support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not = receiving > an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >=20 > a) There is no overload > b) DOIC is not supported >=20 > The reacting DOIC endpoint does not need to differentiate between = these > two cases as the behavior (do not throttle) is the same in both cases. > The -01 draft says in clause 4.1: > If there is no single matching > capability the reacting node MUST act as if it does not implement > DOIC and cease inserting any DOIC related AVPs into any Diameter > messages with this specific reacting node. >=20 > This however is inconsistent. > The reacting node that ceases sending DOIC related AVPs would never > recognize when the server is upgraded to support DOIC. > Subsequent requests (not including DOIC related AVPs) may take a = different > path towards the server and on that path there may be an agent that > supports DOIC (with a match of supported features) and could take the = role > of the reporting DOIC endpoint; but the agent cannot take this role = since > the reacting node (although supporting DOIC) ceased sending of OC- > Supported-Features AVPs. > In summary: As long as no extension feature is defined within = draft-ietf- > dime-ovli (i.e. never, since extensions will be defined in other > drafts), there is no need for draft-ietf-dime-ovli to mandate or even > describe inclusion of OC-Supported-Features AVP in answer messages. >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 02:14:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C81A036B for ; Fri, 7 Feb 2014 02:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uxaNPE8At5Z for ; Fri, 7 Feb 2014 02:14:05 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4601A01FB for ; Fri, 7 Feb 2014 02:14:04 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id pv20so2450565lab.16 for ; Fri, 07 Feb 2014 02:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZoL58QA9aoRPsAZ6ggtLs/pj+TzWbnJSne+zr2MV654=; b=loBUlDWOEbrKoWQlxBrgcmxF9JO4aJzBedyQ9ETBARFEMBX05pSKKF3G9ixQrzuy8X TOGb9cAmsqsMTDkwsMrI6D+9qq3nup9T65GLBG//L4YwxWX5bKBHzsbIRq7XXEyf5XU3 WHiCHaogFZnbi+kcGqwDc3gB/NSg46UVk0Z0BylLo5Og5xjKT4zYUvNSCSoNT0UnND+J Yba232bosE7hthmVY+7xXvk43r96T6nEAeZr+NpSPPt3/GrN6CQHqDFij+oJN+HAltsN 3VP03tH4CP5b5yueZ5SBxXxEE8b37i9cDVKgPdppFPkpnYbAQJYNQyB8pl5k2bqDoCmt aFRg== X-Received: by 10.112.14.1 with SMTP id l1mr5246186lbc.39.1391768043169; Fri, 07 Feb 2014 02:14:03 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id v5sm6072264laj.0.2014.02.07.02.13.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:13:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> Date: Fri, 7 Feb 2014 12:13:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:14:07 -0000 Few comments here. On Feb 4, 2014, at 10:54 AM, dime issue tracker = wrote: > #34: Semantics of OC-Report-Type AVP >=20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: >=20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its = value > matches the value of the Origin-Host AVP of the received = message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches = the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. It is perfectly valid to send a request that has Destination-Host AVP but no Destination-Realm AVP. It just means the Diameter nodes must=20 be adjacent peers.=20 > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the = Diameter > Header of the received message that contained the OC-OLR AVP. No need for this since we agreed that DOIC implicitly always refers=20 to the application on which the DOIC AVPs are carried in. > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches = the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the = Diameter > Header of the received message that contained the OC-OLR AVP. Same not as above. - JOuni >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Fri Feb 7 02:19:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4375F1A05F0 for ; Fri, 7 Feb 2014 02:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmec_8RK7zTp for ; Fri, 7 Feb 2014 02:19:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 59A031A05ED for ; Fri, 7 Feb 2014 02:19:27 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 10E251B8637; Fri, 7 Feb 2014 11:19:25 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E1A1D384075; Fri, 7 Feb 2014 11:19:24 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 7 Feb 2014 11:19:24 +0100 From: To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyh3Mk+g2dTxBkStndl7a0rG2ZqoSuqAgAAqeQCAAOmhgIAACErugAAAQ9CAABU4MA== Date: Fri, 7 Feb 2014 10:19:23 +0000 Message-ID: <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.6.83315 Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:19:31 -0000 Hi Maria Cruz, I'm fine with the proposed clarification. My point is that some parts belong to the handling of the OLR itself and so= me other to the definition of the Validity duration. Here is a proposal for clarification. Let me know if it covers your concern. Regards, Lionel ******************* 4.3. OC-OLR AVP [skip] The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP. It is possible to replay the same OC-OLR AVP multiple times between the overload control endpoints, however, when the OC-OLR AVP content changes or sending endpoint otherwise wants the receiving endpoint to update its overload control information, then the OC-Sequence-Number AVP MUST contain a new greater value than the previously received. The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one. [New] The OC-Validity-Duration AVP indicates the validity time of the overload report associated with a specific sequence number, measured after recept= ion of the OC-OLR AVP. The validity time MUST NOT be updated after reception= =20 of subsequent OC-OLR AVPs with the same sequence number. The default val= ue for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the= =20 OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default v= alue applies. [Skip] 4.5. OC-Validity-Duration AVP OLD: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity- Duration AVP were not present. NEW: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and indicates in seconds the validity time of the overload report. The number of seconds is measured after reception of the first=20 OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20 The default value for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values 0 (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used. When invalid values are used, the default value for the OC-Validity-Dura= tion AVP applies. -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 08:38 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hello Lionel, all, I would like to clarify what "new and fresh", or even only "new" OC-OLR AV= P mean in the text. It should be understood that it does not refer to the new (latest) received= AVP, but just the one that contains (potentially) new values, what only ha= ppens for a new Sequence Number. In that line is the proposed text I provid= ed. Best regards /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: viernes, 07 de febrero de 2014 8:33 To: dime@ietf.org; Maria Cruz Bartolome Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi, My point is just to say that we should make the difference between the defi= nition and the use of the AVP. And about the clarification, I would say that it is rather about how to pop= ulate the OC-OLR AVP or when a new sequence number should be used. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange Maria Cruz Bartolome a =E9crit : Thanks Lionel, The comment equally applies in order to clarify when the Validity-Duration = should include a new value. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 06 de febrero de 2014 19:07 To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi Maria Cruz, Hi Maria Cruz, Steve, Be careful! The reference you are using seems to be odd. The current text in the draft says: 4.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity- Duration AVP were not present. A timeout of the overload report has specific concerns that need to be taken into account by the endpoint acting on the earlier received overload report(s). Section 4.7 discusses the impacts of timeout in the scope of the traffic abatement algorithms. As a general guidance for implementations it is RECOMMENDED never to let any overload report to timeout. Following to this rule, an overload endpoint should explicitly signal the end of overload condition and not rely on the expiration of the validity time of the overload report in the reacting node. This leaves no need for the reacting node to reason or guess the overload condition of the reporting node. I think that the definition of the OC-Validity-Duration AVP should remain i= ndependent of the notion of Sequence-Number. The sequence number does not change the value of the OC-Validity-Duration A= VP. It indicates that the OLR has to be updated or not. And if it is, a new= duration will be there (either implicit or explicit with the OC-Validity-D= uration AVP). So if something needs to be clarified (I haven't checked), it should be in = the handling of the OLR. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy= =E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: [Dime] [= dime] #36: OC-Validity-Duration AVP This change looks pretty straight forward to me. I'll add it to the -02 ve= rsion of the draft unless I hear objections soon. Steve On 2/6/14 4:44 AM, dime issue tracker wrote: #36: OC-Validity-Duration AVP In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when = the OC-Validity-Duration AVP needs to be updated is ambiguous. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP (as indicated by the OC-Sequence-Number AVP). Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Fri Feb 7 02:21:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093991A05F1 for ; Fri, 7 Feb 2014 02:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiZsZdEpZexe for ; Fri, 7 Feb 2014 02:21:02 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DE3C11A05C7 for ; Fri, 7 Feb 2014 02:21:01 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l4so2488085lbv.33 for ; Fri, 07 Feb 2014 02:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TIz2C9OWfgrWlFngeMLK8+qLZWK8d1VZZiPB7S4w8QQ=; b=oG6r7JeCwiZvs2QyyqJKWFc+tfasWslh2wD+khDcjHbfIU3QEEA420xB5iIiG/ew+7 0498YPOmIEjtyZVFaJPK0B+MRWrvoqvUFg5BKni3vaKQ56xO1e94vOwKxK1hj3W9HSAG zy54onWtWf+7mMv5OkCn5apAIr2E0wB3IWKiEbJZnG6a0fVNcfarZcGUmjslNId4g3SY C2yauNvECn81CpRYPNMG3io7pOy29t7VX6ua6aNdP5sECDnC14ElE6Ixrd3buU8LzsGw cjM1/3M64NYO9hKtidcdXZrscJn+nC5o1HwW9Y4C93gZjNEEgqJ8eg41F3HR4R858/sI /U2Q== X-Received: by 10.112.136.227 with SMTP id qd3mr452658lbb.55.1391768459839; Fri, 07 Feb 2014 02:20:59 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id v5sm6098345laj.0.2014.02.07.02.20.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:20:46 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> Date: Fri, 7 Feb 2014 12:20:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:21:04 -0000 On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > I better like Lionel=92s approach, but even that is not ok in the = unlikely extreme case where we have two servers in a realm, S1 is not = overloaded at all, S2 is 50% overloaded, and the aggregated realm = overload is 25%. Why should a client do a 25% throttling when sending = host type requests to the not at all overloaded S1? > What is wrong with letting the client > -not throttle host-type requests to S1, > -throttle host type request to S2 with 50% and > -throttle realm type requests wit 25%? Isn't this what Lionel said below? I am OK with Lionel's "wording" here. - Jouni > =20 > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext = lionel.morand@orange.com > Sent: Wednesday, February 05, 2014 4:14 PM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > I tend to agree except that I would reverse the logic as for the = routing principles: the Destination-host takes precedence when present = over Destination-Realm. So the realm abatement is applied in any case = except if there is an explicit report for the destination-host. > =20 > Lioenl > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > It makes more sense to me for a realm report to apply to all requests = targeted for that realm, independent the type of request. This implies = that it would apply to requests that also have a Destination-Host = specified. >=20 > If this is the definition of a realm report then we need to specify = the interaction between realm reports and host reports. >=20 > I propose that throttling would occur on the realm first and the host = second. If a message targetted for the host is throttled as a result of = realm overload then that throttled message would count as part of the = reduction needed to address the host overload. Messages to the host = that survive realm abatement would then be candidates for host overload. >=20 > Steve >=20 > On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: > The case "Realm" as described below raises another question: is it = prohibited for a realm to only rely on a global overload report for the = whole realm, whatever the nodes inside this realm? > If not, only OLR with the report type "realm" would be received by the = reacting node. And the reduction indicated in the OLR will apply always = for the realm, whatever the presence of Destination-host AVP in the = request... except if an explicit report with the type "Host" as been = received for this destination-host. > =20 > Does it make sense? > =20 > Lionel > =20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #34: Semantics of OC-Report-Type AVP > =20 > #34: Semantics of OC-Report-Type AVP > =20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: > =20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its = value > matches the value of the Origin-Host AVP of the received = message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request = matches the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of = the > request matches the value of the Application-ID of the = Diameter > Header of the received message that contained the OC-OLR = AVP. > =20 > =20 > =20 > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request = matches the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of = the > request matches the value of the Application-ID of the = Diameter > Header of the received message that contained the OC-OLR = AVP. > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 02:23:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3811A035D for ; Fri, 7 Feb 2014 02:23:20 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ9fqgZAB2J2 for ; Fri, 7 Feb 2014 02:23:19 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 99BA21A05ED for ; Fri, 7 Feb 2014 02:23:18 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id c6so2511890lan.11 for ; Fri, 07 Feb 2014 02:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YJeIpM+GXO9iKIzVXoJEtXVJ/YwNP2EBxz99oHee4RQ=; b=iODJMso8t8TVGfnL90WjWhpWPRxa05CL1Yql0Jc+SxiNbp5e7qp+JSi4K+Z13a70r+ +kAzcLruJNOeoRfsICo6qYfAfiSG5RFQXGBo0eTWVGJHvMHEHD/Rr5nGgc+jptmw4k3c wgGlkcNChljwObS8CYNnbGwrjjvs5/gUsOwJ2uPe2FJiSmEluWX7EYIOI0m6NvroNWOu j0NR9/INPwfnFk5jKfA/32oQhaAPU+9QG55W/E/oGVamZS3DT1NPkdbrv0IgxkR5fdI/ av7j+F2kK19R70cLBdFxtiJuxE/DWCAJ7yHHkBShn86FXGieVxT4FDaTPYUGiwI/C/gT K+sQ== X-Received: by 10.112.132.131 with SMTP id ou3mr8906703lbb.29.1391768596616; Fri, 07 Feb 2014 02:23:16 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id y2sm6072123lal.10.2014.02.07.02.23.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:23:15 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <26607_1391620178_52F27052_26607_6697_1_6B7134B31289DC4FAF731D844122B36E4876CC@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 7 Feb 2014 12:23:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org> <26607_1391620178_52F27052_26607_6697_1_6B7134B31289DC4FAF731D844122B36E4876CC@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #28: Report type support in capabilities? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:23:20 -0000 Agree. On Feb 5, 2014, at 7:09 PM, lionel.morand@orange.com wrote: > The default mechanism implies that a client will be able to manage = both types of report. Therefore there is no need at this stage IMHO. >=20 > In future, if there is a need to explicitly indicate which report type = a node support, it may be a hint for defining different = capabilities/algos. And this new capability will be described a new = companion document. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue = tracker > Envoy=E9 : vendredi 31 janvier 2014 23:16 > =C0 : draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com > Cc : dime@ietf.org > Objet : [Dime] [dime] #28: Report type support in capabilities? >=20 > #28: Report type support in capabilities? >=20 > This applies to draft-ietf-dime-ovli >=20 > This is more of a question than an issue. >=20 > We currently only include the abatement algorithm in the = OC-Feature-Vector > AVP. The question is whether we should expand it to include support = for > the host(server) report and realm report. >=20 > The reason for the question is that the agent overload extension will > likely include an indicator in the OC-Feature-Vector of support for = the > peer report type. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-docdt-dime- > srdonovan@usdonovans.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Submitted WG Document | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 02:26:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317761A05F5 for ; Fri, 7 Feb 2014 02:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAm5x0vfzoJT for ; Fri, 7 Feb 2014 02:26:00 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA181A05ED for ; Fri, 7 Feb 2014 02:25:59 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id 10so976692lbg.36 for ; Fri, 07 Feb 2014 02:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j55DjSWCFaaY8DFtolC7xLFF1nXT8q5G6tlexTNwgwQ=; b=k7HiI+DJW7/OtFEG+AME5S+R83avuV0bqir9dI0GjxiwSK/eWWPqAMxP4YwY6/1HNa OE5vOD6XXnJewwlU0ysSCNb4fPru7IBIfvX0g2AxhNkRq+wOJm3psVzFs9vmLugK6v78 EtkSD2dgJFWsIy1Vv759Zcik0ZyTB78k+S34Z5r3Ze6Yhq4ZICFPaI9zcklyc0LUs/67 xWvQ/NW5AtRg15xs3SnKUcrmglf/h7q4skJbI2O+zrEx8Ebsh1RXTthdeDdtcci4+zX1 MXkfXlgvPApVgEq6mRjDmlCPpeoDKvyY0n5Ai7Oesh6N/IWeCCMgMgLuHDCJBcPXn/qH 6OFQ== X-Received: by 10.152.27.100 with SMTP id s4mr9600067lag.18.1391768757646; Fri, 07 Feb 2014 02:25:57 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id ri4sm4373006lbb.6.2014.02.07.02.25.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:25:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> Date: Fri, 7 Feb 2014 12:25:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89F5C818-E425-46EB-81A7-A90907A5F320@gmail.com> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:26:01 -0000 My personal take is that we should simply say it is a NTP timestamp and not fuzzy around it with other possible treatment possibilities. - Jouni On Feb 4, 2014, at 10:49 AM, dime issue tracker = wrote: > #32: Sequence-Number Time-Stamp values within OC-OLR >=20 > The -01 draft says in clause 4.4: > =46rom the functionality point of view, the OC-Sequence-Number AVP = MUST > be used as a non-volatile increasing counter between two overload > control endpoints (neglecting the fact that the contents of the AVP > is a 64-bit NTP timestamp [RFC5905]). The sequence number is only > required to be unique between two overload control endpoints. > Sequence numbers are treated in uni-directional manner, i.e. two > sequence numbers on each direction between two endpoints are not > related or correlated. >=20 > When generating sequence numbers, the new sequence number MUST be > greater than any sequence number previously seen between two > endpoints within a time window that tolerates the wraparound of the > NTP timestamp (i.e. approximately 68 years). >=20 >=20 > With this mechanism it is difficult to get back to sync once you are = out > of sync (for whatever reason). > It is proposed to mandate that the Sequence Number is a real 64-bit = NTP > timestamp (RFC5905) indicating the point in time when the OLR was = created, > and to mandate that OLRs with a time stamp higher than time of = reception > must be ignored by the reacting node. >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Feb 7 02:52:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE21A00BC for ; Fri, 7 Feb 2014 02:52:53 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYB-TeMlkKeP for ; Fri, 7 Feb 2014 02:52:50 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 53E3C1A0033 for ; Fri, 7 Feb 2014 02:52:49 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so2440207lan.26 for ; Fri, 07 Feb 2014 02:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CVOYcvw4fUGSIPy2XsL3Oq0SRAolrw4bvrhxYQ0CfxQ=; b=U2d9ndkgd5dv3dfDdhLgQjqw8LoqqhjKMHEZ1nhal+TNNMWoGLxn+8mcxlG0sem2BH IFplIb4pCgyw/qnHcKIAJe5k+KVMJbM0MAu2BrGayPl91JF4AYza6ltB6CTR53Ri+73+ KJ7qbkG+JpoFNdrzC5cbbpoydInDFlGfCiRz6vUf3nOOc4uMIMFseRNrmWZBXXw8dB9o QX65BfdFey5q/rrfYAExjj8j9etrINU19wSIvFauagoLYaaLyFKcRFnCPZww705EMLZB mp3JcN6o3OumwHr3Ks+bdnkpF2ho+4w5SsgFfRKhTe3MdjXcUC6jIS39L0V6ZHqIWHDa 7NXA== X-Received: by 10.152.42.129 with SMTP id o1mr9569762lal.19.1391770367122; Fri, 07 Feb 2014 02:52:47 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:5cf:580e:21dd:449d? ([2001:6e8:480:60:5cf:580e:21dd:449d]) by mx.google.com with ESMTPSA id cu8sm4437040lbb.12.2014.02.07.02.52.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:52:41 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 7 Feb 2014 12:52:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 10:52:53 -0000 OK by me. - JOuni On Feb 7, 2014, at 12:19 PM, wrote: > Hi Maria Cruz, >=20 > I'm fine with the proposed clarification. > My point is that some parts belong to the handling of the OLR itself = and some other to the definition of the Validity duration. >=20 > Here is a proposal for clarification. Let me know if it covers your = concern. >=20 > Regards, >=20 > Lionel >=20 > ******************* >=20 > 4.3. OC-OLR AVP >=20 > [skip] >=20 > The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP. > It is possible to replay the same OC-OLR AVP multiple times between > the overload control endpoints, however, when the OC-OLR AVP content > changes or sending endpoint otherwise wants the receiving endpoint = to > update its overload control information, then the OC-Sequence-Number > AVP MUST contain a new greater value than the previously received. > The receiver SHOULD discard an OC-OLR AVP with a sequence number = that > is less than previously received one. >=20 > [New] >=20 > The OC-Validity-Duration AVP indicates the validity time of the = overload > report associated with a specific sequence number, measured after = reception > of the OC-OLR AVP. The validity time MUST NOT be updated after = reception=20 > of subsequent OC-OLR AVPs with the same sequence number. The default = value > for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When = the=20 > OC-Validity-Duration AVP is not present in the OC-OLR AVP, the = default value > applies. >=20 > [Skip] >=20 > 4.5. OC-Validity-Duration AVP >=20 > OLD: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 >=20 > NEW: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and indicates in seconds the validity time of the overload report. > The number of seconds is measured after reception of the first=20 > OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20 > The default value for the OC-Validity-Duration AVP is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. OC-Validity-Duration AVP = values 0 > (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used. > When invalid values are used, the default value for the = OC-Validity-Duration > AVP applies. >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz = Bartolome > Envoy=E9 : vendredi 7 f=E9vrier 2014 08:38 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hello Lionel, all, >=20 > I would like to clarify what "new and fresh", or even only "new" = OC-OLR AVP mean in the text. > It should be understood that it does not refer to the new (latest) = received AVP, but just the one that contains (potentially) new values, = what only happens for a new Sequence Number. In that line is the = proposed text I provided. >=20 > Best regards > /MCruz >=20 > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: viernes, 07 de febrero de 2014 8:33 > To: dime@ietf.org; Maria Cruz Bartolome > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi, >=20 > My point is just to say that we should make the difference between the = definition and the use of the AVP. >=20 > And about the clarification, I would say that it is rather about how = to populate the OC-OLR AVP or when a new sequence number should be used. >=20 > Regards, >=20 > Lionel >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > Maria Cruz Bartolome a =E9crit : >=20 >=20 > Thanks Lionel, > The comment equally applies in order to clarify when the = Validity-Duration should include a new value. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content = is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com > Sent: jueves, 06 de febrero de 2014 19:07 > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi Maria Cruz, >=20 > Hi Maria Cruz, Steve, >=20 > Be careful! The reference you are using seems to be odd. >=20 > The current text in the draft says: >=20 > 4.5. OC-Validity-Duration AVP >=20 >=20 > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 > A timeout of the overload report has specific concerns that need to > be taken into account by the endpoint acting on the earlier received > overload report(s). Section 4.7 discusses the impacts of timeout in > the scope of the traffic abatement algorithms. >=20 > As a general guidance for implementations it is RECOMMENDED never to > let any overload report to timeout. Following to this rule, an > overload endpoint should explicitly signal the end of overload > condition and not rely on the expiration of the validity time of the > overload report in the reacting node. This leaves no need for the > reacting node to reason or guess the overload condition of the > reporting node. >=20 > I think that the definition of the OC-Validity-Duration AVP should = remain independent of the notion of Sequence-Number. > The sequence number does not change the value of the = OC-Validity-Duration AVP. It indicates that the OLR has to be updated or = not. And if it is, a new duration will be there (either implicit or = explicit with the OC-Validity-Duration AVP). >=20 > So if something needs to be clarified (I haven't checked), it should = be in the handling of the OLR. >=20 > Regards, >=20 > Lionel >=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan = Envoy=E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: = [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > This change looks pretty straight forward to me. I'll add it to the = -02 version of the draft unless I hear objections soon. >=20 > Steve > On 2/6/14 4:44 AM, dime issue tracker wrote: > #36: OC-Validity-Duration AVP >=20 > In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes = when the OC-Validity-Duration AVP needs to be updated is ambiguous. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content = is > valid since the reception of the new OC-OLR AVP (as indicated by = the > OC-Sequence-Number AVP). >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content = is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites ou copies sans autorisation. Si vous avez recu ce message par = erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites ou copies sans autorisation. Si vous avez recu ce message par = erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Feb 7 03:05:24 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFDC1A0600 for ; Fri, 7 Feb 2014 03:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnTzTtKno61z for ; Fri, 7 Feb 2014 03:05:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 018481A1EE9 for ; Fri, 7 Feb 2014 03:00:11 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s17B09DK007363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2014 12:00:09 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s17B07se027118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 12:00:08 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 12:00:07 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR Thread-Index: AQHPI1MNxVZGwh/8+0yzA1dy86pS0Zqpm+fw Date: Fri, 7 Feb 2014 11:00:06 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> In-Reply-To: <52F3AF0D.3050306@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B253CDEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 33006 X-purgate-ID: 151667::1391770809-000025D0-3433E316/0-0/0-0 Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 11:05:24 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B253CDEMUMBX014nsnin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, sounds like an acceptable proposal which allows to come back to sync after = OLR expiry. This requires however an update of clause 5.5.2 to clearly state Once the overload report expires there is no reason to remember anything ab= out it and the next overload report received could, conceivably have any va= lue. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Thursday, February 06, 2014 4:50 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC= -OLR A couple of things - The requirement is that the sequence number increase monotonically over tim= e, including over a reboot. Use of NTP time is one way of doing this but i= s not the only way. Someone could, for instance, use a time stamp to set t= he sequence number for the first overload report sent after a reboot and th= en increment the sequence number value by one for each subsequent overload = report sent. This actually has better properties than an NTP time stamp as= it would take much longer to roll over. One could also create a global se= quence number service that is not tied to time and have a Diameter server q= uery that global sequence number server after each reboot. We also have a duration timer on overload reports. This gives us one way t= o reset. It should only be required to remember the sequence number of an = active overload report. Once the overload report expires there is no reaso= n to remember anything about it and the next overload report received could= , conceivably have any value. The requirement we need is similar to the session-id in the base Diameter s= pecification. The wording there is -- "The Session-Id MUST be globally and= eternally unique". We just need eternally as the spacial differentiation = is based on the context of the message carrying the overload report. It would be perfectly valid for the DOIC draft to suggest the use of NTP ti= mestamps to populate the sequence number but it should be worded in a simil= ar fashion as the Diameter base RFC -- The Session-Id includes a mandatory = portion and an implementation-defined portion; a recommended format for the= implementation-defined portion is outlined below ..." Steve On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: I cannot understand what is the problem with mandating timestamp. But I can see interoperability problems with the current definition: Assume the sender sends sequence numbers 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3, ... 3, 4, 4, ... 4, 5,.... but the receicer for any reason receives 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3, ... 3, 4, 4, ... 4, 5,.... The receiver would accept 1, 1, ... 1, 2, 2, ... 2, 3, 30000 and then silently discards 3, ... 3, 4, 4, ... 4, 5,.... 4, 5, .... with no way to come back to sync. Are we sure that this cannot happen? Mandating timestamp for sequence number generation at the sender and plausi= bility checking (i.e. received value must be between stored value and time = of reception) for the receiver may not be the only way to solve the problem= . But in the moment I don't see another way. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, February 05, 2014 4:57 PM To: ext lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC= -OLR My point is, we have an interop requirement that the sequence number always= increases over time scope. We do not have the interop requirement that the= sequence number be implemented as a time stamp. A time stamp is probably a= good way to meet the interop requirements, but it is not, in itself, an i= nterop requirement. On Feb 5, 2014, at 9:53 AM, wr= ote: Not sure to understand: if there is a kind of "interop requirement", it is = a case for a "MUST". We are not violating anything. Reporting and reacting nodes will just rely on the Diameter interfaces to k= now how to handle the received sequence-number. So any MUST on the format o= f the sequence-number is acceptable if it avoids interop issues. -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-= OLR I concur with Steve on this one. Using a time stamp is a good way to meet t= he requirements, but it's not our job to normatively state an implementatio= n. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Sect= ion 6 of 2119 includes the following: "In particular, [normative requirements] MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) " The only appropriate reason to require a timestamp would be if we expected = peers to interpret the field as a point in time. OTOH, it would be perfectl= y reasonable to state the actual interop requirements, then add a non-norma= tive (probably indented) paragraph suggesting that a timestamp is a good wa= y to do this. On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: I think the out-of-sync failover described by Ulrich is a good use case to = mandate a specific semantic. Is there any specific NOT to mandate the use of NTP timestamps if it is a s= imple way to solve the possible issues and please everyone? Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34 =C0 : dime@ietf.org Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-= OLR How the sequence number is implemented is an implementation decision. Ther= e is no reason to mandate that is be an NTP timestamp. That should be incl= uded only as one way of addressing the requirement. Steve On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: I also agree. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 11:50 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC= -OLR The existing wording seems actually fuzzy. If it is "like an NTP timestamp", be proud and say it loud! In summary: ok with the proposal if it clarifies this handling of this sequ= ence-number. Lionel -----Message d'origine----- De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] Envoy=E9 : mardi 4 f=E9vrier 2014 09:50 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR #32: Sequence-Number Time-Stamp values within OC-OLR The -01 draft says in clause 4.4: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter between two overload control endpoints (neglecting the fact that the contents of the AVP is a 64-bit NTP timestamp [RFC5905]). The sequence number is only required to be unique between two overload control endpoints. Sequence numbers are treated in uni-directional manner, i.e. two sequence numbers on each direction between two endpoints are not related or correlated. When generating sequence numbers, the new sequence number MUST be greater than any sequence number previously seen between two endpoints within a time window that tolerates the wraparound of the NTP timestamp (i.e. approximately 68 years). With this mechanism it is difficult to get back to sync once you are out o= f sync (for whatever reason). It is proposed to mandate that the Sequence Number is a real 64-bit NTP ti= mestamp (RFC5905) indicating the point in time when the OLR was created, a= nd to mandate that OLRs with a time stamp higher than time of reception m= ust be ignored by the reacting node. ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ 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 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B253CDEMUMBX014nsnin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

sounds lik= e an acceptable proposal which allows to come back to sync after OLR expiry= .

This requi= res however an update of clause 5.5.2 to clearly state

Once the overload report expire= s there is no reason to remember anything about it and the next overload re= port received could, conceivably have any value.

 = ;

Ulrich

 = ;

From:= DiME [mailto:dime-b= ounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 06, 2014 4:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values wi= thin OC-OLR

 

A couple of things - =

The requirement is that the sequence number increase monotonically over tim= e, including over a reboot.  Use of NTP time is one way of doing this = but is not the only way.  Someone could, for instance, use a time stam= p to set the sequence number for the first overload report sent after a reboot and then increment the sequence number= value by one for each subsequent overload report sent.  This actually= has better properties than an NTP time stamp as it would take much longer = to roll over.  One could also create a global sequence number service that is not tied to time and have a Diame= ter server query that global sequence number server after each reboot.

We also have a duration timer on overload reports.  This gives us one = way to reset.  It should only be required to remember the sequence num= ber of an active overload report.  Once the overload report expires th= ere is no reason to remember anything about it and the next overload report received could, conceivably have any value. <= br>
The requirement we need is similar to the session-id in the base Diameter s= pecification.  The wording there is -- "The Session-Id MUST be gl= obally and eternally unique".  We just need eternally as the spac= ial differentiation is based on the context of the message carrying the overload report.

It would be perfectly valid for the DOIC draft to suggest the use of NTP ti= mestamps to populate the sequence number but it should be worded in a simil= ar fashion as the Diameter base RFC -- The Session-Id includes a mandatory = portion and an implementation-defined portion; a recommended format for the implementation-defined portion is ou= tlined below ..."

Steve

On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) w= rote:

I cannot understand what is the problem with mandating timestamp.=

But I can see interoperability problems with the current definition:
 
Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,...=
. 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.
 
Are we sure that this cannot happen?
 
Mandating timestamp for sequence number generation at the sender and p=
lausibility checking (i.e. received value must be between stored value and =
time of reception) for the receiver may not be the only way to solve the pr=
oblem. But in the moment I don't see another way.
 
Ulrich
 
 
-----Original Message-----
From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, February 05, 2014 4:57 PM
To: ext lionel.morand@oran=
ge.com
Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


My point is, we have an interop requirement that the sequence number a=
lways increases over time scope. We do not have the interop requirement tha=
t the sequence number be implemented as a time stamp. A time stamp is proba=
bly a good way to  meet the interop requirements, but it is not, in it=
self, an interop requirement.


 


On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:


 




Not sure to understand: if there is a kind of "interop requiremen=
t", it is a case for a "MUST".


We are not violating anything.


 


Reporting and reacting nodes will just rely on the Diameter interfaces=
 to know how to handle the received sequence-number. So any MUST on the for=
mat of the sequence-number is acceptable if it avoids interop issues.<=
/o:p>


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] 


Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47


=C0 : MORAND Lionel IMT/OLN


Cc : Steve Donovan; dime@ietf.org=



Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


I concur with Steve on this one. Using a time stamp is a good way to m=
eet the requirements, but it's not our job to normatively state an implemen=
tation. In fact, it violates an RFC 2119 "MUST" level requirement=
 to do so. Section 6 of 2119 includes the following:


 


"In particular, [normative requirements] MUST only be used where =
it is


  actually required for interoperation or to limit behavior which=
 has


  potential for causing harm (e.g., limiting retransmisssions)&nb=
sp; "


 


The only appropriate reason to require a timestamp would be if we expe=
cted peers to interpret the field as a point in time. OTOH, it would be per=
fectly reasonable to state the actual interop requirements, then add a non-=
normative (probably indented) paragraph suggesting that a timestamp is a go=
od way to do this.


 


On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:


 




I think the out-of-sync failover described by Ulrich is a good use cas=
e to mandate a specific semantic.


 


Is there any specific NOT to mandate the use of NTP timestamps if it i=
s a simple way to solve the possible issues and please everyone?=



 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


How the sequence number is implemented is an implementation decision.&=
nbsp; There is no reason to mandate that is be an NTP timestamp.  That=
 should be included only as one way of addressing the requirement.


 


Steve


 


On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:


I also agree.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: Tuesday, February 04, 2014 11:50 PM


To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


The existing wording seems actually fuzzy.


If it is "like an NTP timestamp", be proud and say it loud!<=
o:p>


 


In summary: ok with the proposal if it clarifies this handling of this=
 sequence-number.


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]


Envoy=E9 : mardi 4 f=E9vrier 2014 09:50


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


 


#32: Sequence-Number Time-Stamp values within OC-OLR


 


The -01 draft says in clause 4.4:


   From the functionality point of view, the OC-Sequence-Num=
ber AVP MUST


   be used as a non-volatile increasing counter between two =
overload


   control endpoints (neglecting the fact that the contents =
of the AVP


   is a 64-bit NTP timestamp [RFC5905]).  The sequence =
number is only


   required to be unique between two overload control endpoi=
nts.


   Sequence numbers are treated in uni-directional manner, i=
.e. two


   sequence numbers on each direction between two endpoints =
are not


   related or correlated.


 


   When generating sequence numbers, the new sequence number=
 MUST be


   greater than any sequence number previously seen between =
two


   endpoints within a time window that tolerates the wraparo=
und of the


   NTP timestamp (i.e. approximately 68 years).

 


 


With this mechanism it is difficult to get back to sync once you are o=
ut  of sync (for whatever reason).


It is proposed to mandate that the Sequence Number is a real 64-bit NT=
P  timestamp (RFC5905) indicating the point in time when the OLR was c=
reated,  and to mandate that  OLRs with a time stamp higher than =
time of reception  must be ignored by the reacting node.

 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 

 

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B253CDEMUMBX014nsnin_-- From ulrich.wiehe@nsn.com Fri Feb 7 05:08:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CF41A1DE2 for ; Fri, 7 Feb 2014 05:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t2IBXwxqSiu for ; Fri, 7 Feb 2014 05:08:18 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6848E1A16F1 for ; Fri, 7 Feb 2014 05:08:17 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s17D8Gua026464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2014 14:08:16 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s17D8FMB029243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 14:08:16 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Feb 2014 14:08:15 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 14:08:15 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen , "dime@ietf.org" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPI+1LK95DWDMaH0qQEyVc/ebDNpqpv0Fw Date: Fri, 7 Feb 2014 13:08:15 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3345 X-purgate-ID: 151667::1391778496-000025D0-1E8E819B/0-0/0-0 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 13:08:21 -0000 Jouni=20 Please see inline. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen Sent: Friday, February 07, 2014 11:14 AM To: dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Few comments here. On Feb 4, 2014, at 10:54 AM, dime issue tracker wrote: > #34: Semantics of OC-Report-Type AVP >=20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: >=20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches th= e > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. It is perfectly valid to send a request that has Destination-Host AVP but no Destination-Realm AVP. It just means the Diameter nodes must=20 be adjacent peers.=20 ok, then let's remove b) from 0 > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. No need for this since we agreed that DOIC implicitly always refers=20 to the application on which the DOIC AVPs are carried in. yes, we agreed on that, so c) is correct and it does not harm to ke= ep c) > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches th= e > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. Same not as above. I understand that this "above" referrs to 0c), not to 0b). Same response as above. - JOuni >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 > _______________________________________________ > 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 ulrich.wiehe@nsn.com Fri Feb 7 05:12:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7D1A1EE8 for ; Fri, 7 Feb 2014 05:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffHaxo1wW8eP for ; Fri, 7 Feb 2014 05:12:47 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EED2F1A1E10 for ; Fri, 7 Feb 2014 05:12:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s17DCjHI001954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2014 14:12:45 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s17DCiXb006822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 14:12:44 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Feb 2014 14:12:44 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 14:12:44 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUIACsQCAgAA/36A= Date: Fri, 7 Feb 2014 13:12:43 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6282 X-purgate-ID: 151667::1391778765-000025D0-D151C4C2/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 13:12:49 -0000 -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 07, 2014 11:21 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > I better like Lionel's approach, but even that is not ok in the unlikely = extreme case where we have two servers in a realm, S1 is not overloaded at = all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh= ould a client do a 25% throttling when sending host type requests to the no= t at all overloaded S1? > What is wrong with letting the client > -not throttle host-type requests to S1, > -throttle host type request to S2 with 50% and > -throttle realm type requests wit 25%? Isn't this what Lionel said below? no it is not I am OK with Lionel's "wording" here. - Jouni > =20 > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@= orange.com > Sent: Wednesday, February 05, 2014 4:14 PM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > I tend to agree except that I would reverse the logic as for the routing = principles: the Destination-host takes precedence when present over Destina= tion-Realm. So the realm abatement is applied in any case except if there i= s an explicit report for the destination-host. > =20 > Lioenl > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > It makes more sense to me for a realm report to apply to all requests tar= geted for that realm, independent the type of request. This implies that i= t would apply to requests that also have a Destination-Host specified. >=20 > If this is the definition of a realm report then we need to specify the i= nteraction between realm reports and host reports. >=20 > I propose that throttling would occur on the realm first and the host sec= ond. If a message targetted for the host is throttled as a result of realm= overload then that throttled message would count as part of the reduction = needed to address the host overload. Messages to the host that survive rea= lm abatement would then be candidates for host overload. >=20 > Steve >=20 > On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: > The case "Realm" as described below raises another question: is it prohib= ited for a realm to only rely on a global overload report for the whole rea= lm, whatever the nodes inside this realm? > If not, only OLR with the report type "realm" would be received by the re= acting node. And the reduction indicated in the OLR will apply always for t= he realm, whatever the presence of Destination-host AVP in the request... e= xcept if an explicit report with the type "Host" as been received for this = destination-host. > =20 > Does it make sense? > =20 > Lionel > =20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #34: Semantics of OC-Report-Type AVP > =20 > #34: Semantics of OC-Report-Type AVP > =20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: > =20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its valu= e > matches the value of the Origin-Host AVP of the received messag= e > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > =20 > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Feb 7 05:54:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FA51A00F6 for ; Fri, 7 Feb 2014 05:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enWh3sAC396x for ; Fri, 7 Feb 2014 05:54:44 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E1F2F1A1F06 for ; Fri, 7 Feb 2014 05:54:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s17Dsfur031653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2014 14:54:41 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s17DsfXl022447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 14:54:41 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Feb 2014 14:54:41 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 14:54:41 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPIbnza0SZ1wdbvEGvoj4P8RAtnpqlM3SggAARYlCAAQdGQIADOPCAgABLE3A= Date: Fri, 7 Feb 2014 13:54:40 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B25EB@DEMUMBX014.nsn-intra.net> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> <7610_1391532667_52F11A7B_7610_3074_1_6B7134B31289DC4FAF731D844122B36E4774C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1F71@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 11028 X-purgate-ID: 151667::1391781282-00001A6F-270DE711/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 13:54:47 -0000 See inline -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 07, 2014 11:09 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message= s On Feb 5, 2014, at 10:03 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Hi Loinel, >=20 > it seems that we can safely remove OC-Supported-Feature AVP from answer m= essages in the draft-ietf-dime-ovli (which does not define extensions to it= self). This does not mean that a future extension cannot (re)-introduce it = when needed. It also does not mean that reporting nodes are not allowed to = include it in answer messages as long as answer messages have a *[AVP]. Not so fast. Leaving OC-Supported-Feature AVP away from the=20 answer is already supported by the -01. So there is nothing to fix in that part. it seems you agree that=20 a) reporting nodes that only support OLR_DEFAULT_ALGO are not required to s= end OC-Supported-Features AVP in answer messages (of course they may if the= re is the *[AVP]) b) reacting nodes that only support OLR_DEFAULT_ALGO can safely ignore OC-= Supported-Features AVPs received in answer messages c) behavior of the reacting node that only supports OLR_DEFAULT_ALGO does n= ot depend on presence/absence of OC-Supported-Features AVPs in received ans= wer messages if that's agreed, why not say so clearly in the draft? (the clear way to say so is to remove this AVP from answers. The thing that need to be fixed is the inconsistency on you pointed out which would make reacting node not to send any DOIC AVPs. - JOuni >=20 > Best regards > Ulrich >=20 > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: Tuesday, February 04, 2014 5:51 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: RE: [dime] #30: OC-Supported-Features AVP in answer messages >=20 > Hi Ulrich, >=20 > For the point 2 and 3, the difference between the "Should" and the "May" = is quite subtle here and is for me only an implementation option. >=20 > For 4 and 5, ok if the node only supports the default algo. In other word= s, only the OLR matters for nodes supporting only the default algo. The res= t is purely for information and can be safely ignored. >=20 > For 6, if the new feature consists in a new algo, it would mean defining = a new dedicated OLR AVP. So nodes supporting only the default algo will ign= ore any unknown AVP if received. >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 17:04 > =C0 : MORAND Lionel IMT/OLN; dime@ietf.org > Objet : RE: [dime] #30: OC-Supported-Features AVP in answer messages >=20 > Dear Lionel, >=20 > thank you for your response. >=20 > If I correctly understand, the principles would be: > 1. Sending OC-Supported-Features in answer messages is syntactically opti= onal. > 2. When the reacting node does only support OLR_DEFAULT_ALGO , the report= ing node should not insert an OC-Supported-Features AVP in the answer messa= ge. > 3. When the reporting node does only support OLR_DEFAULT_ALGO, it should = not insert an OC-Supported-Features AVP in the answer message. > 4. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignore = OC-Supported-Features AVPs received in answer messages. > 5. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignor a= ll extensions received in an OC-OLR. > 6. When a new feature is introduced, the spec introducing the new feature= must define the details to ensure interoperability of nodes supporting the= new feature with nodes that do not support the new feature (taking into ac= count that nodes not supporting the new feature act according to the princi= ples 1.-5.). >=20 >=20 > Best regards > Ulrich >=20 >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@= orange.com > Sent: Tuesday, February 04, 2014 4:01 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messa= ges >=20 > I think that there is actually an issue here but the proposed way to solv= e it is not the correct one. > The initial idea was to be able to use the same overload report with seve= ral algorithms. So the OLR was somehow only meaningful along with the OC-Fe= ature-Vector AVP. >=20 > But because the OC-Feature-Vector AVP is defined as a set of flags, it is= not possible to say that this OLR is to be used with only one given algo w= hen more than one is defined (as the bit flags will advertize 1 AND 2 for 2= supported algos). So the OC-Feature-Vector cannot be used to indicate the = abatement to perform. >=20 > As the syntax of the OC-Feature-Vector is adapted to advertize supported = algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP = for the reduction algo (default) and a new dedicated report AVP must be cre= ated when a new algo is introduced. In this way, the OC-OLR is self-explici= t. >=20 > It would be purely optional to send the Supported-Features AVP along with= the OC-OLR AVP. >=20 > Lionel=20 >=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #30: OC-Supported-Features AVP in answer messages >=20 > #30: OC-Supported-Features AVP in answer messages >=20 > According to the current feature advertisement/negotiation mechanism in > the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP > in answer messages to indicate their supported OC features to the reactin= g > DOIC endpoint. > The author of this document believes that the best a reacting node can d= o > with such information is to ignore it, and therefore proposes to allow > reporting nodes not to insert OC-Supported-Features AVPs in answer > messages. > Currently only one feature is defined (OLR_DEFAULT_ALGO). > A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other > feature is only interested in receiving/not receiving OC-OLR AVPs from > reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates > support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not receivin= g > an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >=20 > a) There is no overload > b) DOIC is not supported >=20 > The reacting DOIC endpoint does not need to differentiate between these > two cases as the behavior (do not throttle) is the same in both cases. > The -01 draft says in clause 4.1: > If there is no single matching > capability the reacting node MUST act as if it does not implement > DOIC and cease inserting any DOIC related AVPs into any Diameter > messages with this specific reacting node. >=20 > This however is inconsistent. > The reacting node that ceases sending DOIC related AVPs would never > recognize when the server is upgraded to support DOIC. > Subsequent requests (not including DOIC related AVPs) may take a differen= t > path towards the server and on that path there may be an agent that > supports DOIC (with a match of supported features) and could take the rol= e > of the reporting DOIC endpoint; but the agent cannot take this role since > the reacting node (although supporting DOIC) ceased sending of OC- > Supported-Features AVPs. > In summary: As long as no extension feature is defined within draft-ietf= - > dime-ovli (i.e. never, since extensions will be defined in other > drafts), there is no need for draft-ietf-dime-ovli to mandate or even > describe inclusion of OC-Supported-Features AVP in answer messages. >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From maria.cruz.bartolome@ericsson.com Fri Feb 7 07:26:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF31ABBB1 for ; Fri, 7 Feb 2014 07:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh5uBXcLIXqJ for ; Fri, 7 Feb 2014 07:26:55 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE361A8033 for ; Fri, 7 Feb 2014 07:26:51 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-92-52f4fb3a0219 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 73.DB.10875.A3BF4F25; Fri, 7 Feb 2014 16:26:51 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 16:26:50 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifECAAAXaAIAADfeAgAAEaQCAASwPUP//+iEAgAADQgCAABZZ8IAAVmMAgAE5EdCAAF/ugA== Date: Fri, 7 Feb 2014 15:26:50 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvja717y9BBtfvMlnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOm/tjMVHFnKWPHuXR9LA+OShYxdjJwcEgImEs/+XWKBsMUk LtxbzwZiCwkcYpS42Z3excgFZC9mlFiy/gNYEZuAncSl0y+Yuhg5OEQElCVO/3IACQsLlEu8 vHSFGcQWEaiQ+Lz1EhOEXSfxfNM5VhCbRUBF4kn7GbAaXgFfib5rt9kh5q9gl3i/pokdJMEp ECDR8P8Z2C5GoIO+n1oDNohZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8rhK0k0bjkCSvIbcwC mhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYRWchmToLoWMWko5ZSDoWMLKsYmTPTczMSS833MQI DPuDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhNpi8L b7q6ddsVQTOBPbMEdueu2v/Oxijob/Te8rtPk7nOXuxddLb2y6rdl7U9xGa/vnZm9rpdQX3v YyLFY2fYnK6rMeD7/VFscuLu4ochmpk3zvnX5vwIj1gimfnu3bSqOkU/qV37w5+XLtnHq7pz z6Lo7ovhtuHPlXq4RC5bbs+04i6+FZGixFKckWioxVxUnAgAwgLxlkkCAAA= Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 15:27:00 -0000 SGVsbG8gVWxyaWNoLCBOaXJhdiwNCg0KSSBhZ3JlZSB3aXRoIFVscmljaCB0aGF0IHRoZSB0ZXh0 IHByb3ZpZGVkIGJ5IE5pcmF2IGlzIGp1c3QgYSBNQVksIGFuZCB3aGV0aGVyIG9yIG5vdCB0aGUg c2VydmVyIHNlbmRzIGFuIE9MUiBpbiBhbGwgYW5zd2VycyBzaGFsbCBub3QgYmUganVzdCBhIE1B WS4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGNyaXRlcmlhIHByb3ZpZGVkIGJ5IFVscmljaCBvbiB3 aGVuIE9MUiBoYXMgdG8gYmUgc2VudCByZXF1aXJlcyB0aGUgc2VydmVyIGhhcyBzb21lIGtub3ds ZWRnZToNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2Rl IGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlz IG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25v d3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBl eHBpcmUNCmMpIG90aGVyd2lzZQ0KDQpSZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93 bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRv ZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBrbm93bGVkZ2U/IA0KVGFrZSBpbnRvIGFjY291bnQgYXMg d2VsbCB0aGF0IGEgInJlYWN0aW5nIiBub2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChpbiBjYXNl IGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8gYSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxmIG9mIGEg bm9uLXN1cHBvcnRpbmcgY2xpZW50KSAgYW5kIGEgQ2xpZW50LiBJbiB0aGUgY2FzZSBvZiBBZ2Vu dHMsIGluIGZhY3QgdGhlIFNlcnZlciBtYXkgbm90IGV2ZW4ga25vdyBpZiB0aGlzIGlzIGdvaW5n IHRvIGFjdCBhcyBhIHJlYWN0aW5nIG5vZGUgb3IganVzdCB0cmFuc3BhcmVudGx5LCBpbiBmYWN0 LCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaGF2ZSBhbnkga25vd2xlZGdlIGFib3V0IHdo YXQgYWdlbnRzIGluIHRoZSBjaGFpbiB0byB0aGUgZmluYWwgQ2xpZW50Lg0KDQpUaGVyZWZvcmUs IEkgZGVmaW5pdGVseSB0aGluayB0aGF0IHNlbmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBz b21lIGltcG9ydGFudCBhZHZhbnRhZ2VzOg0KLQlzdGF0ZS1sZXNzIGltcGxlbWVudGF0aW9uICh0 cmFuc2FjdGlvbiBvciBzZXNzaW9uKSBpcyBzaW1wbGVyLA0KLQl0aGUgc2VydmVyIGRvZXMgbm90 IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFj dGluZyBub2RlDQotCXRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBib3RoZXIgd2hldGhlciBh biByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBvciB3aGV0aGVyIHRo aXMgT0xSIGlzIHN0aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLg0KLQlzZW5kaW5nIGFuIGFk ZGl0aW9uYWwgQVZQIGlzIG5vdCBwcm9jZXNzaW5nIGNvbnN1bWluZywgaW4gY29tcGFyaXNvbiB3 aXRoIHJlcXVpcmVkIGFib3ZlIGNoZWNrcyAoaWYgdGhpcyBpcyBub3Qgc2VudCkuIA0KCUluIGZh Y3QsIGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwgdGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBs ZXggaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUg bm9kZXMsIA0KCWFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNhcmUgdG8gdGFrZSBhcHByb3By aWF0ZSBhY3Rpb25zICANCi0JbW9yZSByb2J1c3Qgc29sdXRpb24sIGFzIG5vIG5lZWQgdG8gY2F0 ZXIgZm9yIGFsbCB0aGUgY2hlY2tzIG9uIHRoZSBuZWVkIHRvIHNlbmQgaW5mb3JtYXRpb24sICBm b3Igc2l0dWF0aW9ucyB3aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCAg4oCmDQoNCg0K QmVzdCByZWdhcmRzDQovTUNydXoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWVoZSwg VWxyaWNoIChOU04gLSBERS9NdW5pY2gpDQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRl IDIwMTQgMTA6NTkNClRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBsaW9uZWwubW9y YW5kQG9yYW5nZS5jb207IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K TmlyYXYsDQoNCkknbSBhZnJhaWQgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3Qg dGhlIGludGVudGlvbi4NCg0KIndoZW4gaXQgd2FudHMgdG8gcHJvdmlkZS91cGRhdGUuLi4uaXQg c2hhbGwgaW5jbHVkZS4uLiIgdHJhbnNsYXRlcyB0byAiLi4uaXQgbWF5IGluY2x1ZGUuLi4iLg0K DQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gIndo ZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQpXZSBoYXZlIHRo ZSBmb2xsb3dpbmcgY2FzZXM6DQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUg cmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCmIpIHRoZSByZXBv cnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0 bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhh dCB3aWxsIHNvb24gZXhwaXJlDQpjKSBvdGhlcndpc2UNCg0KaW4gY2FzZSBhKSB0aGUgcmVwb3J0 aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFIgaW4gY2FzZSBiKSB0aGUgcmVw b3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUgcmVhY3Rpbmcgbm9kZSB3aXRo IHRoZSBsYXRlc3QgT0xSIGluIGNhc2UgYykgdGhlIHJlcG9ydGluZyBub2RlIE1VU1QgaW5jbHVk ZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcgbm9kZSBkb2VzIG5vdCBrbm93 IHdoZXRoZXIgdGhpcyBpcyBhIHJlcGxheSBvciBhbiB1cGRhdGUpDQoNClVscmljaA0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkg W21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAy MDE0IDQ6NDkgUE0NClRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgbGlv bmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0K U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQoNClVscmljaCwNCg0KSXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0IHBy b2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC4NCkhvdyBh Ym91dCB0aGUgZm9sbG93aW5nLg0KDQpXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBw cm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVy IHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hh bGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5n IE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFj dGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJl cG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVh ZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkg aW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmlu ZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmlj aCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAwNiwgMjAxNCAzOjU3IFBNDQpUbzogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgTmly YXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN Cg0KTmlyYXYsIExpb25lbCwNCg0KSSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFs dGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1v ZGlmaWVkIHByaW5jaXBsZSAyJzoNCg0KMicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVy IHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBP TFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRl ZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVh ZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUuZy4g dGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJl ZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiLCBvciBhbiBvbGQgIGJ1 dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3Zlcmxv YWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRp bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJu IGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1 cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KSSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hh dC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4g d2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMs IHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3Zlcmxv YWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0KVWxyaWNoICANCg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t IFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDA2LCAyMDE0IDEwOjIwIEFNDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IFdpZWhlLCBV bHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3Jn DQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90 dGxpbmcNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogRGlNRSBbbWFp bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBOaXJhdiBTYWxvdCAobnNh bG90KQ0KRW52b3nDqcKgOiBqZXVkaSA2IGbDqXZyaWVyIDIwMTQgMTA6MDgNCsOAwqA6IFdpZWhl LCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYu b3JnDQpPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo cm90dGxpbmcNCg0KVWxyaWNoLA0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBi ZWhhdmlvciBvbiByZXBvcnRpbmcgbm9kZSAib3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBh d2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVk IG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGlj aCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINClRoZSByZXBvcnRpbmcg bm9kZSBtYXkgc2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVy IHByb3ZpZGVkIE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9w IHRocm90dGxpbmcgdGhlIHRyYWZmaWMuDQoNCltMTV0gQWdyZWUuIEluIG90aGVyIHdvcmRzLCBp dCBpcyBub3QgZGVlbWVkIHJlcXVpcmVkIGZvciB0aGUgZGVmYXVsdCBtZWNoYW5pc20gZGVzY3Jp YmVkIGluIHRoaXMgZHJhZnQuIEhvdyBhbmQgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgZGVjaWRl cyB0byBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciBtYXkgZGVwZW5kIG9uIHRoZSBhcHBs aWNhdGlvbiBvciBvbiB0aGUgaW1wbGVtZW50YXRpb24uIEF0IGxlYXN0LCBpdCBpcyBteSBjdXJy ZW50IHVuZGVyc3RhbmRpbmcuDQoNCkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUg aXMgbm8gbmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJv dHRsaW5nIGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3 b3JkcywgdGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2Yg dGhlIE9MUiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMg dG93YXJkcyBpdC4NCg0KW0xNXSBBZ3JlZQ0KDQpUaGVyZSBtYXkgYmUgb3RoZXIgY2FzZXMsIGUu Zy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgbGFzdCBvdmVybG9hZCBz aXR1YXRpb24gZW5kZWQgbG9uZyB0aW1lIGJhY2sgaW4gdGhlIHBhc3QsIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIGl0IHRvIGluY2x1ZGUgT0xSIGlmIGN1cnJlbnRseSB0aGVyZSBpcyBubyBvdmVybG9h ZCBjb25kaXRpb24uDQoNCltMTV0gQWdyZWUNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxv dyBhcmUgZmluZSB3aXRoIG1lLg0KDQpbTE1dIEFncmVlDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERF L011bmljaCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0gDQpTZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMDYsIDIwMTQgMjoyMyBQTQ0KVG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBT YWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0g IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkFjdHVhbGx5IHdlIHNlZW0gdG8g YWdyZWUgb24gdHdvIHByaW5jaXBsZXM6DQoxLiBMYWNrIG9mIE9MUiBtZWFucyAibm8gY2hhbmdl Ig0KMi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9y IG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1 ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlz IGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3Qg T0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3Ig YW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBp cyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zl cmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVz dHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KQ2FuIHBl b3BsZSBwbGVhc2UgY29uZmlybS4NCg0KVWxyaWNoDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1l LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA0OjM1IFBNDQpUbzogTmlyYXYgU2Fsb3QgKG5z YWxvdCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0 aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBZ3JlZWQuwqAgVG8gcmVzdGF0ZSAtLSBsYWNr IG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3Zlcmxv YWQgc3RhdGUgZm9yIHRoZSBob3N0IG9yIHJlYWxtLsKgIElmIHRoZXJlIGlzIGEgY3VycmVudGx5 IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwg aXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBv dmVybG9hZCByZXBvcnQuwqAgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5IGFjdGl2ZSBvdmVybG9h ZCByZXBvcnQgdGhlbiBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBpbXBsaWVzIHRoZXJlIGlz IG5vIG92ZXJsb2FkIGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uDQoNClN0ZXZlDQpPbiAyLzUvMTQg OToxOSBBTSwgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6DQpJIGFncmVlIHdpdGggU3RldmUg ZXhjZXB0IHRoZSBwYXJ0ICJzaG91bGRu4oCZdCBsYWNrIG9mIE9MUiBiZSBpbnRlcnByZXRlZCBh cyBub3Qgb3ZlcmxvYWRlZD8iDQrCoA0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBi YWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUg c2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3 aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hp Y2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdo aWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5k IGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBv aW50IG9mIHZpZXcuDQrCoA0KU28gYmFzaWNhbGx5LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxkIG5v dCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBub2Rl LiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3QgYmFzZWQgb24gb2xkZXIg T0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlvZCBvciB3aGVuIHRoZSBl eHBsaWNpdCBPTFIgd2l0aCAiMCIgb3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVkLg0KSW4gbXkg dmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0IHRoZSByZXBv cnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFjdGluZyBub2Rl Lg0KwqANClJlZ2FyZHMsDQpOaXJhdi4NCsKgDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3Zhbg0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0K aW5saW5lDQpPbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNo KSB3cm90ZToNCk9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBp bnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9u ZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1 cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlzIHJlcXVlc3RlZCkuDQpTUkQ+ IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT/CoCBTaG91bGRuJ3QgbGFjayBvZiBhbiBPTFIg YmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KwqANCsKgDQpPdGhlciBjcml0 ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci4NClNSRD4gUmVx dWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBi cmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3Ig YW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxz byBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZl IHRoYW4gaW5zZXJ0aW5nIE9MUnMuDQoNCg0KwqANCsKgDQpGb3IgbXkgY2xhcmlmaWNhdGlvbjog SSBndWVzcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGlzIG5vdCByZXF1aXJlZCB0byBwcm9jZXNz IGV2ZXJ5IHNpbmdsZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2lsbCBiZSByZXBsYXlzIGFueXdheSku IFdoYXQgd291bGQgYmUgdGhlIHByb2NlZHVyZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSBpbiBvcmRl ciB0byBtaW5pbWl6ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVkIE9MUnMgYW5kIGF0IHRoZSBzYW1l IHRpbWUgbWluaW1pemUgdGhlIHJpc2sgdG9vIG1pc3MgYSBuZXcgT0xSPw0KU1JEPiBUaGF0IGlz IHRoZSBwdXJwb3NlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuwqAgDQoNCg0KwqANCsKgDQrCoA0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNClNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTQ0KVG86IGxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMx OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSBzaGFyZSB0aGUgc2FtZSBvcGlu aW9uIGFzIExpb25lbC4NCsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDA0LCAyMDE0IDk6MDcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Rp bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQpJIHVuZGVy c3RhbmQgdGhhdCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIERP RVMgTk9UIGluc2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4gDQpTbyB0aGUgb3B0aW9ucyB3 b3VsZCBiZToNCjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyDQoyLSBPQy1PbmdvaW5nLVRo cm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgcmVxdWVzdCArIE9DLU9MUiBBVlAgaW4gc29tZSBh bnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0aGUgY2xpZW50 IG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQrCoA0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9u LCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQrCoA0KTGlvbmVsDQrCoA0K LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21h aWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCkVudm95w6nCoDogbWFyZGkgNCBm w6l2cmllciAyMDE0IDA5OjQ5DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCkNjwqA6IGRp bWVAaWV0Zi5vcmcNCk9iamV0wqA6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90 dGxpbmcNCsKgDQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQogSXQgaGFz IGJlZW4gcHJvcG9zZWQgdG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW UCB0aGF0IGlzwqAgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQg aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0wqAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFW UCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQogKFRpbWVTdGFtcCkgb2YgdGhl IE9MUiBhY2NvcmRpbmcgdG8gd2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdhcw0KIHN1cnZp dmVkKSBpcyBwZXJmb3JtZWQuIEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5kaWNhdGVzIHRoYXQgY3Vy cmVudGx5IG5vwqAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuwqAgUmVwb3J0aW5nIERPSUMgZW5k cG9pbnRzIG1heSB1c2UgdGhpc8KgIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0 aGVyIHRoZXJlIGlzIGEgbmVlZCB0byB1cGRhdGUgdGhlwqAgcmVhY3RpbmcgRE9JQyBlbmRwb2lu dCB3aXRoIHRoZSBsYXRlc3QgT0xSLg0KIEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5p c20gd291bGQgcmVzdWx0IGluIHRoZSBuZWVkIGZvciB0aGXCoCByZXBvcnRpbmcgbm9kZSB0byBz ZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5nIERPSUPCoCBl bmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlz IGFjdHVhbGx5IGRvaW5nwqAgdGhlIHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRocm90dGxp bmcvbm90IHRocm90dGxpbmcuDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1 c3RuZXNzIGFzIGl0IGFsbG93cyB0aGUgcmVwb3J0aW5nIERPSUPCoCBlbmRwb2ludCB0byBkZXRl Y3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZ8Kg IERPSUMgZW5kcG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24pLg0KIFRoZSBmZWVkYmFj ayBtZWNoYW5pc20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBSRkMgNzA2OC4N CiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJv dHRsaW5nLUluZm8gQVZQIHRvwqAgYmUgdXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy dml2ZWQgYSB0aHJvdHRsaW5nLg0KwqANCsKgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0K VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsN CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo= From maria.cruz.bartolome@ericsson.com Fri Feb 7 08:15:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8C91A01B9 for ; Fri, 7 Feb 2014 08:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2Qc1situwnj for ; Fri, 7 Feb 2014 08:15:16 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1601A00C9 for ; Fri, 7 Feb 2014 08:15:15 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-10-52f5069211f7 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.07.23809.29605F25; Fri, 7 Feb 2014 17:15:15 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 17:15:14 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIYbAlWmMf1mPE0uklIAv2DU+a5qmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28A== Date: Fri, 7 Feb 2014 16:15:14 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje5ktq9BBhN7uSzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtRT19gKemwqJq9uYm1g3KnfxcjJISFgIrF3wSIWCFtM4sK9 9WxdjFwcQgKHGCX2vl/DAuEsZpQ4PeMdG0gVm4CdxKXTL5i6GDk4RASUJU7/cgAJCwvYS3y9 cYYZxBYRcJBY8/wkC0RJmETb8wqQMIuAisS+NTvASngFfCV6z+1jhhi/kEXi1Od1zCD1nAIB EjMuyYPUMALd8/3UGiYQm1lAXOLWk/lMEHcKSCzZc54ZwhaVePn4HyuErSTRuOQJK0S9nsSN qVPYIGxtiWULX0PtFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMbLnJmbmpJcbbWIEBv3B Lb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwZOjoTFLKe f/vCpf+t8OHx4JhNa7lVIlmzmbW5b1T96P6eE/59MsuSqfafsq8d+cBzavdXj2lhXeIzz9i5 styVkNn4JOJvbO3/1LIj6+dNmJPt5fltzXmGT+oONgn2Qkfi5zipr+JQO9Cy01pjE0eMceoO O7G5DanzM2eU8HhHcGZd2ny/ba0SS3FGoqEWc1FxIgDlg0BpSAIAAA== Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 16:15:19 -0000 Dear all, I am in favor of the proposal made by Ulrich in the sequence diagram he pro= vided. ---- As a summary: Consequently the reacting node will receive realm type OLRs from the agent = and host type OLRs from the servers. The received realm type OLR will be relevant for the reacting node when sen= ding/throttling realm type requests; the received host type OLR will be rel= evant for the reacting node when sending/throttling host type request= s. ----- It may occur though, that a Client has only received Realm type OLR, and th= en it has to send a request to one specific host, then the Client will not = apply any restriction, but as soon as the response is received back, Client= will update Host type OLR. Same will apply when only Host type OLR has be= en received by Client. The alternative will be to always send back from an Agent both Host OLR plu= s Realm OLR, but I do not think this is necessary and may complicate the so= lution. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: viernes, 07 de febrero de 2014 14:13 To: ext Jouni Korhonen Cc: dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 07, 2014 11:21 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > I better like Lionel's approach, but even that is not ok in the unlikely = extreme case where we have two servers in a realm, S1 is not overloaded at = all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh= ould a client do a 25% throttling when sending host type requests to the no= t at all overloaded S1? > What is wrong with letting the client > -not throttle host-type requests to S1, > -throttle host type request to S2 with 50% and > -throttle realm type requests wit 25%? Isn't this what Lionel said below? no it is not I am OK with Lionel's "wording" here. - Jouni > =20 > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@= orange.com > Sent: Wednesday, February 05, 2014 4:14 PM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > I tend to agree except that I would reverse the logic as for the routing = principles: the Destination-host takes precedence when present over Destina= tion-Realm. So the realm abatement is applied in any case except if there i= s an explicit report for the destination-host. > =20 > Lioenl > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > It makes more sense to me for a realm report to apply to all requests tar= geted for that realm, independent the type of request. This implies that i= t would apply to requests that also have a Destination-Host specified. >=20 > If this is the definition of a realm report then we need to specify the i= nteraction between realm reports and host reports. >=20 > I propose that throttling would occur on the realm first and the host sec= ond. If a message targetted for the host is throttled as a result of realm= overload then that throttled message would count as part of the reduction = needed to address the host overload. Messages to the host that survive rea= lm abatement would then be candidates for host overload. >=20 > Steve >=20 > On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: > The case "Realm" as described below raises another question: is it prohib= ited for a realm to only rely on a global overload report for the whole rea= lm, whatever the nodes inside this realm? > If not, only OLR with the report type "realm" would be received by the re= acting node. And the reduction indicated in the OLR will apply always for t= he realm, whatever the presence of Destination-host AVP in the request... e= xcept if an explicit report with the type "Host" as been received for this = destination-host. > =20 > Does it make sense? > =20 > Lionel > =20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #34: Semantics of OC-Report-Type AVP > =20 > #34: Semantics of OC-Report-Type AVP > =20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: > =20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its valu= e > matches the value of the Origin-Host AVP of the received messag= e > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > =20 > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > _______________________________________________ > 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 trac+dime@trac.tools.ietf.org Fri Feb 7 12:32:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ECE1A0474 for ; Fri, 7 Feb 2014 12:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd0zMX20njCw for ; Fri, 7 Feb 2014 12:32:08 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E1F0E1A0478 for ; Fri, 7 Feb 2014 12:32:07 -0800 (PST) Received: from localhost ([127.0.0.1]:48373 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBs5e-0006OL-MR; Fri, 07 Feb 2014 21:31:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 20:31:57 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/37 Message-ID: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #37: Inconsistent name and abbreviation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:32:10 -0000 #37: Inconsistent name and abbreviation The introduction refers to the mechanism as Diameter Overload Control (DOC). Elsewhere it's Diameter Overload Information Conveyance (DOIC). We need to pick one and stick with it. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: trivial | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 12:37:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4261A04BE for ; Fri, 7 Feb 2014 12:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIyRj7Gv3iQj for ; Fri, 7 Feb 2014 12:37:40 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6B1A0478 for ; Fri, 7 Feb 2014 12:37:40 -0800 (PST) Received: from localhost ([127.0.0.1]:48663 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBsB7-0005Zy-BX; Fri, 07 Feb 2014 21:37:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 20:37:37 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/38 Message-ID: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #38: Server Farm Definition Issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:37:42 -0000 #38: Server Farm Definition Issue A "server farm" is defined as "A set of Diameter servers that can handle any request for a given set of Diameter applications.". This is not strictly true. For example, if a request includes a Destination-Server AVP, then then in general only that particular server in the farm can handle the request. I assume that we don't mean to limit the server farm concept to situations where the entire farm is known by a single Diameter-Identity, do we? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 12:41:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8461ACCE2 for ; Fri, 7 Feb 2014 12:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1i-oh7tdMe4 for ; Fri, 7 Feb 2014 12:41:44 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A3EC21A0478 for ; Fri, 7 Feb 2014 12:41:44 -0800 (PST) Received: from localhost ([127.0.0.1]:48830 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBsF1-0006C5-JP; Fri, 07 Feb 2014 21:41:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 20:41:39 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/39 Message-ID: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #39: Definition of Diameter Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:41:46 -0000 #39: Definition of Diameter Routing Do we need this definition? Diameter routing should be fully defined by the base specification. But if we do, I think the phrase "non-adjacent nodes" in the first sentence is misleading. Destination-Realm is also used to route between adjacent nodes, at least until you reach the node responsible for the ream+application. We should also include Application-Id. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 12:45:07 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35B1A0488 for ; Fri, 7 Feb 2014 12:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VSKRRGWzT32 for ; Fri, 7 Feb 2014 12:45:06 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D6A231A0478 for ; Fri, 7 Feb 2014 12:45:05 -0800 (PST) Received: from localhost ([127.0.0.1]:48933 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBsIE-0003Uh-H4; Fri, 07 Feb 2014 21:44:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 20:44:58 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/39#comment:1 Message-ID: <072.86c3403c16322c0a18c7803e95c20bff@trac.tools.ietf.org> References: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: Re: [Dime] [dime] #39: Definition of Diameter Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:45:07 -0000 #39: Definition of Diameter Routing Comment (by ben@nostrum.com): (Oops, sent to soon). The last sentence says "It is possible to enhance the routing decision with application-level knowledge..." The passive voice obscures the responsibility. What actor may do this? (I suggest recasting the sentence as "XXX may enhance..." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 12:50:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808DC1AD34C for ; Fri, 7 Feb 2014 12:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHtRZxFOaLKa for ; Fri, 7 Feb 2014 12:50:55 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECBB1A0459 for ; Fri, 7 Feb 2014 12:50:55 -0800 (PST) Received: from localhost ([127.0.0.1]:49240 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBsNw-0008Aa-Kg; Fri, 07 Feb 2014 21:50:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 20:50:52 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/40 Message-ID: <057.01735c3128fb78d15e8c46bffd9dff62@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #40: Need defintions for Overload Report and Abatement Algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:50:57 -0000 #40: Need defintions for Overload Report and Abatement Algorithm Both are mentioned in other definitions but not defined themselves. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 12:54:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043C81A0459 for ; Fri, 7 Feb 2014 12:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pPBVkTEOoAU for ; Fri, 7 Feb 2014 12:54:38 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BEEBC1A04DC for ; Fri, 7 Feb 2014 12:54:38 -0800 (PST) Received: from localhost ([127.0.0.1]:49321 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBsRX-0004bC-Su; Fri, 07 Feb 2014 21:54:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 20:54:35 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/41 Message-ID: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #41: Need better overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:54:41 -0000 #41: Need better overview The overview is short on explanation. We need a high level, non-normative "how it works" description of the mechanism, including roles, responsibilities, associations, and information flows. This doesn't need too much detail (e.g. message and AVP definitions belong elsewhere.) Some of the information in the endpoint architecture section would be better off here. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 12:57:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FCB1A04BE for ; Fri, 7 Feb 2014 12:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSIO8hAIvxB4 for ; Fri, 7 Feb 2014 12:57:15 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E2F071A0459 for ; Fri, 7 Feb 2014 12:57:14 -0800 (PST) Received: from localhost ([127.0.0.1]:49455 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBsU2-0005yh-28; Fri, 07 Feb 2014 21:57:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 20:57:10 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/42 Message-ID: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #42: IETF defined example of a stateless application. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:57:16 -0000 #42: IETF defined example of a stateless application. In section 3.1.1, under the definition of "Stateless Application", is there an IETF defined application that can be added as an example? Not all readers may be familiar with 3GPP applications. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: trivial | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 13:34:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCA51A01C0 for ; Fri, 7 Feb 2014 13:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUCOTJ9fEMhB for ; Fri, 7 Feb 2014 13:34:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 47EC91A0428 for ; Fri, 7 Feb 2014 13:34:26 -0800 (PST) Received: from localhost ([127.0.0.1]:51534 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBt3z-0003W5-R8; Fri, 07 Feb 2014 22:34:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 21:34:19 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/43 Message-ID: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #43: Overstated guidance on session-ending requests. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:34:28 -0000 #43: Overstated guidance on session-ending requests. In section 3.1.4, under "Intra-Session Requests" indicates that session ending requests should be throttled less aggressively. While I agree that's a good idea in general, I think that's a mater of local policy, and not up to DOIC to specify. It would be better to indicate that prioritization under overload is up to local policy, and list prioritizing of session-ending requests as an example of a potential local policy. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 13:49:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90DE1A04B2 for ; Fri, 7 Feb 2014 13:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3mQmoYlyWZk for ; Fri, 7 Feb 2014 13:49:09 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2A48F1A0420 for ; Fri, 7 Feb 2014 13:49:09 -0800 (PST) Received: from localhost ([127.0.0.1]:52171 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBtID-0004od-Ux; Fri, 07 Feb 2014 22:49:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 21:49:01 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/44 Message-ID: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #44: Incorrect sequence number behavior X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:49:11 -0000 #44: Incorrect sequence number behavior section 4.3 says that the receiver should discard an OLR with a sequence number less than the most recent. That should be less than or equal. Technically, re-applying the same OLR should make no difference, but it's never needed, and could be error prone if the sender screwed something up. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: trivial | Milestone: Component: draft- | Version: docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 13:54:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2876F1A04B2 for ; Fri, 7 Feb 2014 13:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuU_-FvE8CKw for ; Fri, 7 Feb 2014 13:54:43 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9852B1A01C0 for ; Fri, 7 Feb 2014 13:54:43 -0800 (PST) Received: from localhost ([127.0.0.1]:52557 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBtNg-00043u-L9; Fri, 07 Feb 2014 22:54:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 21:54:40 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/45 Message-ID: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #45: Why is a validity duration of 0 disallowed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:54:45 -0000 #45: Why is a validity duration of 0 disallowed? Section 4.5 disallows a validity duration of zero. Why do we want to disallow that? It would allow a quick way of ending any existing overload condition without worrying about the semantics of the abatement algorithm. (We currently use a reduction percentage of zero to end an overload condition--but that's specific to the loss algorithm and might not make sense for all future ones.) Note that setting an expiration time to zero is the standard way of removing state in several other protocols (e.g. SIP). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 13:59:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609E71A0506 for ; Fri, 7 Feb 2014 13:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKTaWeY8wQtl for ; Fri, 7 Feb 2014 13:59:44 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 23AFF1A01C0 for ; Fri, 7 Feb 2014 13:59:43 -0800 (PST) Received: from localhost ([127.0.0.1]:52863 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBtSV-0001Sk-Bp; Fri, 07 Feb 2014 22:59:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 21:59:39 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/46 Message-ID: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:59:46 -0000 #46: Bad normative advice on not letting overload reports expire Section 4.5 says " As a general guidance for implementations it is RECOMMENDED never to let any overload report to timeout." In my opinion, this is bad advice. If an overload report is close to expiring anyway, it's better to just let it expire than to generate a new report to end the condition. Furthermore, this falls into the category of normative language that does not effect interoperability. That is forbidden by RFC 2119, except for situations where not following it does significant harm. If we believe letting reports expire does significant harm, we should explain why. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 14:05:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30181A0506 for ; Fri, 7 Feb 2014 14:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5-OQMSYqfiB for ; Fri, 7 Feb 2014 14:05:29 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7278B1A03CA for ; Fri, 7 Feb 2014 14:05:29 -0800 (PST) Received: from localhost ([127.0.0.1]:53126 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBtY5-0007Hc-7t; Fri, 07 Feb 2014 23:05:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 22:05:25 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/47 Message-ID: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #47: reduction percentages greater than 100 should be ignored X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:05:31 -0000 #47: reduction percentages greater than 100 should be ignored Section 4.7 says " [Reduction-Percentage] Values greater than 100 are interpreted as 100." An OLR with an invalid value should be ignored. An invalid value indicates incorrect behavior on the part of the sender. In this case, it's not safe to assume we know what the sender really intended. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 14:10:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47591A04B2 for ; Fri, 7 Feb 2014 14:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7IkOWU52zC6 for ; Fri, 7 Feb 2014 14:10:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B89C11A015B for ; Fri, 7 Feb 2014 14:10:50 -0800 (PST) Received: from localhost ([127.0.0.1]:53346 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBtdF-0000OV-3h; Fri, 07 Feb 2014 23:10:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 22:10:45 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/48 Message-ID: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #48: Setting M-Bit gives wrong semantics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:10:53 -0000 #48: Setting M-Bit gives wrong semantics Multiple sections indicate that a new application that incorporates DOIC can set the M-Bit on DOIC sub-avps. I don't think this ever does the right thing. IIUC, If a node that otherwise supports DOIC encounters a DOIC avp that it doesn't understand, and has the M-Bit set, it will cause a failure of the application command. I don't think we want the lack of support of some DOIC feature or extension to ever cause an application-level failure. I think we are looking for something that would just cause the OLR to be ignored. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Feb 7 14:20:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69291AD68A for ; Fri, 7 Feb 2014 14:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5piqLRQyuhf6 for ; Fri, 7 Feb 2014 14:20:04 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE01AD687 for ; Fri, 7 Feb 2014 14:20:03 -0800 (PST) Received: from localhost ([127.0.0.1]:54156 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBtmB-0006qi-VJ; Fri, 07 Feb 2014 23:19:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Fri, 07 Feb 2014 22:19:59 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/49 Message-ID: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:20:05 -0000 #49: capabilities announcement mechanism needs to be rethought The capabilities announcement mechanism needs serious rethought. Specifically, the lifetime of the state associated with a capabilities announcement is unclear. It does not make sense to tie that lifetime to Diameter session lifetimes, unless we expect to have different capability sets for different sessions. (and it doesn't help at all for non-session applications or pseudo-sessions.) I think we either need to mandate that the capabilities are stateless, that is, must be included in every request, and any OLR in a response must match the OC-Supported-Features from the corresponding request. Otherwise, we need a way to activate and deactivate the set associated with a capabilities set. (This is a side effect of allowing DOIC to cross non-supporting agents. If we didn't allow that, we could make DOIC support and capabilites negotiation happen as part of the CAR exchange. ) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From jouni.nospam@gmail.com Sat Feb 8 02:33:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3651A0292 for ; Sat, 8 Feb 2014 02:33:55 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCzxqvPd164l for ; Sat, 8 Feb 2014 02:33:52 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 03E8C1A05B2 for ; Sat, 8 Feb 2014 02:33:51 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so3374581lbi.21 for ; Sat, 08 Feb 2014 02:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CBbcGhucI4ArZHkAuUvf5yYtuKbWdUCD8p/IpuoRr4A=; b=GGXq3S9l4d4cFAbEL+0PWTTtkIoMGX1Ju0CJBLLHia+JV6mdCXKnvKeILYo3vdKIPW LqnMMEjTGLybfSxYSgG7PnGkQlHrieHPeXvS9ZPGddIQTEeHd2J3rQmlDjbMH6y6nwAR waAHkRF+9G1Ji5B/k1DiCaL7GkdWg4Ciaxlv8nEZ7UF9N+YKV1o5wTr6RBRoQva7Fuan 9rkAlfsgAVMBgEsRHVKnn9JPTXayJFBgtvSZ2yBdmuJegWacm8n2E5rLmn0ZYHEQcBbg VMft8u2BjdxTpcuRw4o1OWukyQiknpWs7vgxDonSDYdpviMjRLYqYSdC1efb6QtFZiw6 J4pg== X-Received: by 10.152.161.234 with SMTP id xv10mr763452lab.41.1391855630680; Sat, 08 Feb 2014 02:33:50 -0800 (PST) Received: from [10.37.91.160] ([77.95.242.69]) by mx.google.com with ESMTPSA id th3sm8075349lbb.11.2014.02.08.02.33.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Feb 2014 02:33:50 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> Date: Sat, 8 Feb 2014 12:33:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 10:33:55 -0000 Sounds acceptable. Would the following then work for all: o clarify that once the overload report expires there is no reason to remember anything about it o the sequence number would be similar to session-id.. based=20 on the NTP time + any vendor specific data to make it=20 "globally and eternally unique". - Jouni On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Steve, > =20 > sounds like an acceptable proposal which allows to come back to sync = after OLR expiry. > This requires however an update of clause 5.5.2 to clearly state > Once the overload report expires there is no reason to remember = anything about it and the next overload report received could, = conceivably have any value.=20 >=20 > =20 > Ulrich > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve = Donovan > Sent: Thursday, February 06, 2014 4:50 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR > =20 > A couple of things -=20 >=20 > The requirement is that the sequence number increase monotonically = over time, including over a reboot. Use of NTP time is one way of doing = this but is not the only way. Someone could, for instance, use a time = stamp to set the sequence number for the first overload report sent = after a reboot and then increment the sequence number value by one for = each subsequent overload report sent. This actually has better = properties than an NTP time stamp as it would take much longer to roll = over. One could also create a global sequence number service that is = not tied to time and have a Diameter server query that global sequence = number server after each reboot. >=20 > We also have a duration timer on overload reports. This gives us one = way to reset. It should only be required to remember the sequence = number of an active overload report. Once the overload report expires = there is no reason to remember anything about it and the next overload = report received could, conceivably have any value.=20 >=20 > The requirement we need is similar to the session-id in the base = Diameter specification. The wording there is -- "The Session-Id MUST be = globally and eternally unique". We just need eternally as the spacial = differentiation is based on the context of the message carrying the = overload report. >=20 > It would be perfectly valid for the DOIC draft to suggest the use of = NTP timestamps to populate the sequence number but it should be worded = in a similar fashion as the Diameter base RFC -- The Session-Id includes = a mandatory portion and an implementation-defined portion; a recommended = format for the implementation-defined portion is outlined below ..." >=20 > Steve >=20 > On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > I cannot understand what is the problem with mandating timestamp. > But I can see interoperability problems with the current definition: > =20 > Assume the sender sends sequence numbers > 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3, ... 3, 4, 4, ... 4, 5,....=20 > but the receicer for any reason receives=20 > 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3, ... 3, 4, 4, ... 4, 5,....=20 > The receiver would accept > 1, 1, ... 1, 2, 2, ... 2, 3, 30000 > and then silently discards > 3, ... 3, 4, 4, ... 4, 5,.... 4, 5, ....=20 > with no way to come back to sync. > =20 > Are we sure that this cannot happen? > =20 > Mandating timestamp for sequence number generation at the sender and = plausibility checking (i.e. received value must be between stored value = and time of reception) for the receiver may not be the only way to solve = the problem. But in the moment I don't see another way. > =20 > Ulrich > =20 > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben = Campbell > Sent: Wednesday, February 05, 2014 4:57 PM > To: ext lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR > =20 > My point is, we have an interop requirement that the sequence number = always increases over time scope. We do not have the interop requirement = that the sequence number be implemented as a time stamp. A time stamp is = probably a good way to meet the interop requirements, but it is not, in = itself, an interop requirement. > =20 > On Feb 5, 2014, at 9:53 AM, = wrote: > =20 > Not sure to understand: if there is a kind of "interop requirement", = it is a case for a "MUST". > We are not violating anything. > =20 > Reporting and reacting nodes will just rely on the Diameter interfaces = to know how to handle the received sequence-number. So any MUST on the = format of the sequence-number is acceptable if it avoids interop issues. > =20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47 > =C0 : MORAND Lionel IMT/OLN > Cc : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR > =20 > I concur with Steve on this one. Using a time stamp is a good way to = meet the requirements, but it's not our job to normatively state an = implementation. In fact, it violates an RFC 2119 "MUST" level = requirement to do so. Section 6 of 2119 includes the following: > =20 > "In particular, [normative requirements] MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) " > =20 > The only appropriate reason to require a timestamp would be if we = expected peers to interpret the field as a point in time. OTOH, it would = be perfectly reasonable to state the actual interop requirements, then = add a non-normative (probably indented) paragraph suggesting that a = timestamp is a good way to do this. > =20 > On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: > =20 > I think the out-of-sync failover described by Ulrich is a good use = case to mandate a specific semantic. > =20 > Is there any specific NOT to mandate the use of NTP timestamps if it = is a simple way to solve the possible issues and please everyone? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR > =20 > How the sequence number is implemented is an implementation decision. = There is no reason to mandate that is be an NTP timestamp. That should = be included only as one way of addressing the requirement. > =20 > Steve > =20 > On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: > I also agree. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com > Sent: Tuesday, February 04, 2014 11:50 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values = within OC-OLR > =20 > The existing wording seems actually fuzzy. > If it is "like an NTP timestamp", be proud and say it loud! > =20 > In summary: ok with the proposal if it clarifies this handling of this = sequence-number. > =20 > Lionel > =20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoy=E9 : mardi 4 f=E9vrier 2014 09:50 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR > =20 > #32: Sequence-Number Time-Stamp values within OC-OLR > =20 > The -01 draft says in clause 4.4: > =46rom the functionality point of view, the OC-Sequence-Number AVP = MUST > be used as a non-volatile increasing counter between two overload > control endpoints (neglecting the fact that the contents of the AVP > is a 64-bit NTP timestamp [RFC5905]). The sequence number is only > required to be unique between two overload control endpoints. > Sequence numbers are treated in uni-directional manner, i.e. two > sequence numbers on each direction between two endpoints are not > related or correlated. > =20 > When generating sequence numbers, the new sequence number MUST be > greater than any sequence number previously seen between two > endpoints within a time window that tolerates the wraparound of the > NTP timestamp (i.e. approximately 68 years). > =20 > =20 > With this mechanism it is difficult to get back to sync once you are = out of sync (for whatever reason). > It is proposed to mandate that the Sequence Number is a real 64-bit = NTP timestamp (RFC5905) indicating the point in time when the OLR was = created, and to mandate that OLRs with a time stamp higher than time = of reception must be ignored by the reacting node. > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Sat Feb 8 08:34:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A681A040A for ; Sat, 8 Feb 2014 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHNNb8aBXPMd for ; Sat, 8 Feb 2014 08:34:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDCE1A03CC for ; Sat, 8 Feb 2014 08:34:42 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id BB4CB1B8239; Sat, 8 Feb 2014 17:34:41 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 9A079180065; Sat, 8 Feb 2014 17:34:41 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 8 Feb 2014 17:34:41 +0100 From: To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" Thread-Topic: [Dime] [dime] #48: Setting M-Bit gives wrong semantics Thread-Index: AQHPJFF6Ab6u61L6RkaLYcwLVhapC5qriYTA Date: Sat, 8 Feb 2014 16:34:40 +0000 Message-ID: <27855_1391877281_52F65CA1_27855_6436_1_6B7134B31289DC4FAF731D844122B36E493891@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> In-Reply-To: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.115114 Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 16:34:45 -0000 Hi Ben, I don't think that there is something wrong here. The setting of M-bit is per application, and it is true for any AVP. I'm not sure to understand your example. The use of the DOIC is defined per= application. For a newly defined application: - Either the node supports the new application and it will understand any A= VP defined as AVP to understand; - Either the node does not support new application and it will not receive = messages for this application or it will be transparent to any unknown AVP = (e.g. Relay). Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: vendredi 7 f=E9vrier 2014 23:11 =C0=A0: draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com Cc=A0: dime@ietf.org Objet=A0: [Dime] [dime] #48: Setting M-Bit gives wrong semantics #48: Setting M-Bit gives wrong semantics Multiple sections indicate that a new application that incorporates DOIC can set the M-Bit on DOIC sub-avps. I don't think this ever does the right thing. IIUC, If a node that otherwise supports DOIC encounters a DOIC avp that it doesn't understand, and has the M-Bit set, it will cause a failure of the application command. I don't think we want the lack of support of some DOIC feature or extension to ever cause an application-level failure. I think we are looking for something that would just cause the OLR to be ignored. --=20 -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Sat Feb 8 08:37:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94F61A0411 for ; Sat, 8 Feb 2014 08:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqDg6a6o26sB for ; Sat, 8 Feb 2014 08:37:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 14F691A03CC for ; Sat, 8 Feb 2014 08:37:16 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BD21522C17F; Sat, 8 Feb 2014 17:37:15 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A29AD4C06E; Sat, 8 Feb 2014 17:37:15 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 8 Feb 2014 17:37:15 +0100 From: To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" Thread-Topic: [Dime] [dime] #47: reduction percentages greater than 100 should be ignored Thread-Index: AQHPJFC6A8FdueQIi02gzJE0FZ/OW5qrjtDQ Date: Sat, 8 Feb 2014 16:37:14 +0000 Message-ID: <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> In-Reply-To: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.31815 Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be ignored X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 16:37:18 -0000 Hi Ben, OK with this statement. But if it is agreed, would it mean that the same consideration should apply= for the OC-Validity-Duration AVP values? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: vendredi 7 f=E9vrier 2014 23:05 =C0=A0: draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com Cc=A0: dime@ietf.org Objet=A0: [Dime] [dime] #47: reduction percentages greater than 100 should = be ignored #47: reduction percentages greater than 100 should be ignored Section 4.7 says " [Reduction-Percentage] Values greater than 100 are interpreted as 100." An OLR with an invalid value should be ignored. An invalid value indicates incorrect behavior on the part of the sender. In this case, it's not safe to assume we know what the sender really intended. --=20 -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Sat Feb 8 08:54:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A41A01E8 for ; Sat, 8 Feb 2014 08:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwJiT9GQAdJi for ; Sat, 8 Feb 2014 08:53:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 612931A0413 for ; Sat, 8 Feb 2014 08:53:59 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id ABD723244F8; Sat, 8 Feb 2014 17:53:59 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8F0454C06E; Sat, 8 Feb 2014 17:53:59 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 8 Feb 2014 17:53:59 +0100 From: To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" Thread-Topic: [Dime] [dime] #44: Incorrect sequence number behavior Thread-Index: AQHPJE5xFgHh+FiMkUemW8Uvvhb8WZqrkCvw Date: Sat, 8 Feb 2014 16:53:59 +0000 Message-ID: <10919_1391878439_52F66127_10919_17464_1_6B7134B31289DC4FAF731D844122B36E4938F4@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> In-Reply-To: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.31815 Subject: Re: [Dime] [dime] #44: Incorrect sequence number behavior X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 16:54:01 -0000 Hi Ben, The case "equal" is discussed in the previous sentence. Check the following: The received OC-Supported-Features AVP does not change the existing overload condition and/or traffic abatement algorithm settings if the OC-Sequence-Number AVP contains a value that is equal to the previously received/recorded one. If the OC-Supported-Features AVP is received for the first time for the reporting node or the OC- Sequence-Number AVP value is less than the previously received/ recorded one (and is outside the valid overflow window), then either the sequence number is stale (e.g. an intentional or unintentional replay) and SHOULD be silently discarded. The first sentence implies that the received OLR is ignored.=20 And actually, there is something wrong in the last sentence. At the end,=20 recorded one (and is outside the valid overflow window), then either the sequence number is stale or replay (e.g. an intentional or unintenti= onal replay) and SHOULD be silently discarded. The "either" in the first line should be removed. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: vendredi 7 f=E9vrier 2014 22:49 =C0=A0: draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com Cc=A0: dime@ietf.org Objet=A0: [Dime] [dime] #44: Incorrect sequence number behavior #44: Incorrect sequence number behavior section 4.3 says that the receiver should discard an OLR with a sequence number less than the most recent. That should be less than or equal. Technically, re-applying the same OLR should make no difference, but it's never needed, and could be error prone if the sender screwed something up. --=20 -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: trivial | Milestone: Component: draft- | Version: docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Sat Feb 8 09:00:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784431A0186 for ; Sat, 8 Feb 2014 09:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAqgMTIeVJEH for ; Sat, 8 Feb 2014 09:00:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 58B151A0143 for ; Sat, 8 Feb 2014 09:00:20 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 049BE22C326; Sat, 8 Feb 2014 18:00:21 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DA838238084; Sat, 8 Feb 2014 18:00:20 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 8 Feb 2014 18:00:20 +0100 From: To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" Thread-Topic: [Dime] [dime] #39: Definition of Diameter Routing Thread-Index: AQHPJEUGqbnG5Xa8gUiUuN1o70Nx0ZqqMZ8AgAFjT7A= Date: Sat, 8 Feb 2014 17:00:19 +0000 Message-ID: <12142_1391878820_52F662A4_12142_3836_1_6B7134B31289DC4FAF731D844122B36E493936@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org> <072.86c3403c16322c0a18c7803e95c20bff@trac.tools.ietf.org> In-Reply-To: <072.86c3403c16322c0a18c7803e95c20bff@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.102414 Subject: Re: [Dime] [dime] #39: Definition of Diameter Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 17:00:23 -0000 Hi Ben, The "XXX" refers to Diameter application designers. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: vendredi 7 f=E9vrier 2014 21:45 =C0=A0: draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #39: Definition of Diameter Routing #39: Definition of Diameter Routing Comment (by ben@nostrum.com): (Oops, sent to soon). The last sentence says "It is possible to enhance the routing decision with application-level knowledge..." The passive voice obscures the responsibility. What actor may do this? (I suggest recasting the sentence as "XXX may enhance..." --=20 -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Sat Feb 8 09:02:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124661A03DE for ; Sat, 8 Feb 2014 09:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiVjG56sKK38 for ; Sat, 8 Feb 2014 09:02:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE41A01B9 for ; Sat, 8 Feb 2014 09:02:19 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 7E5A81902ED; Sat, 8 Feb 2014 18:02:19 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6563D38406E; Sat, 8 Feb 2014 18:02:19 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 8 Feb 2014 18:02:19 +0100 From: To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" Thread-Topic: [Dime] [dime] #40: Need defintions for Overload Report and Abatement Algorithm Thread-Index: AQHPJEZPu9Gl9+RpsUy6JrZGtBgZzZqrlj5A Date: Sat, 8 Feb 2014 17:02:17 +0000 Message-ID: <8933_1391878939_52F6631B_8933_14079_1_6B7134B31289DC4FAF731D844122B36E493949@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <057.01735c3128fb78d15e8c46bffd9dff62@trac.tools.ietf.org> In-Reply-To: <057.01735c3128fb78d15e8c46bffd9dff62@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.150022 Subject: Re: [Dime] [dime] #40: Need defintions for Overload Report and Abatement Algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 17:02:21 -0000 Hi Ben, Ok with the principle but it would better to propose a text for discussion. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: vendredi 7 f=E9vrier 2014 21:51 =C0=A0: draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com Cc=A0: dime@ietf.org Objet=A0: [Dime] [dime] #40: Need defintions for Overload Report and Abatem= ent Algorithm #40: Need defintions for Overload Report and Abatement Algorithm Both are mentioned in other definitions but not defined themselves. --=20 -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Sat Feb 8 09:02:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942A81A01B9 for ; Sat, 8 Feb 2014 09:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78ujgUoPm3ck for ; Sat, 8 Feb 2014 09:02:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4C1A03DE for ; Sat, 8 Feb 2014 09:02:53 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 117F9C02D2; Sat, 8 Feb 2014 18:02:54 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id EC49838406E; Sat, 8 Feb 2014 18:02:53 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 8 Feb 2014 18:02:53 +0100 From: To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" Thread-Topic: [Dime] [dime] #41: Need better overview Thread-Index: AQHPJEbUpscmID0i+0C5RKej3sq4uZqrlpKg Date: Sat, 8 Feb 2014 17:02:52 +0000 Message-ID: <8933_1391878974_52F6633D_8933_14099_1_6B7134B31289DC4FAF731D844122B36E49395B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> In-Reply-To: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.150022 Subject: Re: [Dime] [dime] #41: Need better overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 17:02:55 -0000 Hi Ben, Any proposal? Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoy=E9=A0: vendredi 7 f=E9vrier 2014 21:55 =C0=A0: draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com Cc=A0: dime@ietf.org Objet=A0: [Dime] [dime] #41: Need better overview #41: Need better overview The overview is short on explanation. We need a high level, non-normative "how it works" description of the mechanism, including roles, responsibilities, associations, and information flows. This doesn't need too much detail (e.g. message and AVP definitions belong elsewhere.) Some of the information in the endpoint architecture section would be better off here. --=20 -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Sun Feb 9 04:42:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CD71A022D for ; Sun, 9 Feb 2014 04:42:50 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhp0ANwGwhFK for ; Sun, 9 Feb 2014 04:42:48 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78E1A0033 for ; Sun, 9 Feb 2014 04:42:47 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id z11so2964682lbi.40 for ; Sun, 09 Feb 2014 04:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UAVGTFg1oLS5WFXTj3+4yh5k6WoM8AuKSN1Ap2GLYYo=; b=xldlBTL/lw4ENHnC1C1w/MKZB6wSe8rEAIHOYge7j9w8iobk8TI2unWo2556Wmi8ZX qpfJcSxBSZDV4xJHCfVi44hUwcIDyu4518s1+hM/qw8J4q6yxUIWK1VhplXk6CuEf9wv 5ZA4bXgq42MbZj1FHsdgP7RHRSrWUzhhRQlDF9E7awruL882cil7jFPUX0O3Xzj3Aac0 R0lHHv3GcjJAQVl8X8x+1tmYZK/bkfjZX/Ct0qcjP6lj2focNugNIbHcGTtMg2KN6lu1 jrtvsbFD8qm2lkZwr51Mu/uMeK4K9eCwn6lCU6zouutO/lw1rSB7HZRtcr0XMUEuFcSq 9FDQ== X-Received: by 10.112.164.35 with SMTP id yn3mr791235lbb.45.1391949767114; Sun, 09 Feb 2014 04:42:47 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id pz10sm11999713lbb.10.2014.02.09.04.42.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Feb 2014 04:42:46 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B25EB@DEMUMBX014.nsn-intra.net> Date: Sun, 9 Feb 2014 14:42:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> <7610_1391532667_52F11A7B_7610_3074_1_6B7134B31289DC4FAF731D844122B36E4774C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1F71@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25EB@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Feb 2014 12:42:51 -0000 On Feb 7, 2014, at 3:54 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > See inline >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, February 07, 2014 11:09 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext lionel.morand@orange.com; dime@ietf.org > Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer = messages >=20 >=20 > On Feb 5, 2014, at 10:03 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Hi Loinel, >>=20 >> it seems that we can safely remove OC-Supported-Feature AVP from = answer messages in the draft-ietf-dime-ovli (which does not define = extensions to itself). This does not mean that a future extension cannot = (re)-introduce it when needed. It also does not mean that reporting = nodes are not allowed to include it in answer messages as long as answer = messages have a *[AVP]. >=20 > Not so fast. Leaving OC-Supported-Feature AVP away from the=20 > answer is already supported by the -01. So there is nothing > to fix in that part. > it seems you agree that=20 > a) reporting nodes that only support OLR_DEFAULT_ALGO are not required = to send OC-Supported-Features AVP in answer messages (of course they may = if there is the *[AVP]) As I said this is already in the draft, thus ok. We just need to clarify the use of OC-Supported-Features, remove the contradicting text and clarify that the absence of the OC-Supported-Features equals to the OLR_DEFAULT_ALGO (currently it only states that for the OC-Feature-Vector). - JOuni > b) reacting nodes that only support OLR_DEFAULT_ALGO can safely = ignore OC-Supported-Features AVPs received in answer messages > c) behavior of the reacting node that only supports OLR_DEFAULT_ALGO = does not depend on presence/absence of OC-Supported-Features AVPs in = received answer messages > if that's agreed, why not say so clearly in the draft? > (the clear way to say so is to remove this AVP from answers. >=20 >=20 > The thing that need to be fixed is the inconsistency on you > pointed out which would make reacting node not to send any > DOIC AVPs. >=20 > - JOuni >=20 >>=20 >> Best regards >> Ulrich >>=20 >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20= >> Sent: Tuesday, February 04, 2014 5:51 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >> Subject: RE: [dime] #30: OC-Supported-Features AVP in answer messages >>=20 >> Hi Ulrich, >>=20 >> For the point 2 and 3, the difference between the "Should" and the = "May" is quite subtle here and is for me only an implementation option. >>=20 >> For 4 and 5, ok if the node only supports the default algo. In other = words, only the OLR matters for nodes supporting only the default algo. = The rest is purely for information and can be safely ignored. >>=20 >> For 6, if the new feature consists in a new algo, it would mean = defining a new dedicated OLR AVP. So nodes supporting only the default = algo will ignore any unknown AVP if received. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 >> Envoy=E9 : mardi 4 f=E9vrier 2014 17:04 >> =C0 : MORAND Lionel IMT/OLN; dime@ietf.org >> Objet : RE: [dime] #30: OC-Supported-Features AVP in answer messages >>=20 >> Dear Lionel, >>=20 >> thank you for your response. >>=20 >> If I correctly understand, the principles would be: >> 1. Sending OC-Supported-Features in answer messages is syntactically = optional. >> 2. When the reacting node does only support OLR_DEFAULT_ALGO , the = reporting node should not insert an OC-Supported-Features AVP in the = answer message. >> 3. When the reporting node does only support OLR_DEFAULT_ALGO, it = should not insert an OC-Supported-Features AVP in the answer message. >> 4. A reacting node that supports only OLR_DEFAULT_ALGO can safely = ignore OC-Supported-Features AVPs received in answer messages. >> 5. A reacting node that supports only OLR_DEFAULT_ALGO can safely = ignor all extensions received in an OC-OLR. >> 6. When a new feature is introduced, the spec introducing the new = feature must define the details to ensure interoperability of nodes = supporting the new feature with nodes that do not support the new = feature (taking into account that nodes not supporting the new feature = act according to the principles 1.-5.). >>=20 >>=20 >> Best regards >> Ulrich >>=20 >>=20 >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext = lionel.morand@orange.com >> Sent: Tuesday, February 04, 2014 4:01 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer = messages >>=20 >> I think that there is actually an issue here but the proposed way to = solve it is not the correct one. >> The initial idea was to be able to use the same overload report with = several algorithms. So the OLR was somehow only meaningful along with = the OC-Feature-Vector AVP. >>=20 >> But because the OC-Feature-Vector AVP is defined as a set of flags, = it is not possible to say that this OLR is to be used with only one = given algo when more than one is defined (as the bit flags will = advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector = cannot be used to indicate the abatement to perform. >>=20 >> As the syntax of the OC-Feature-Vector is adapted to advertize = supported algos, it could be easier to clarify that the OC-OLR AVP is = THE report AVP for the reduction algo (default) and a new dedicated = report AVP must be created when a new algo is introduced. In this way, = the OC-OLR is self-explicit. >>=20 >> It would be purely optional to send the Supported-Features AVP along = with the OC-OLR AVP. >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 >> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #30: OC-Supported-Features AVP in answer messages >>=20 >> #30: OC-Supported-Features AVP in answer messages >>=20 >> According to the current feature advertisement/negotiation mechanism = in >> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features = AVP >> in answer messages to indicate their supported OC features to the = reacting >> DOIC endpoint. >> The author of this document believes that the best a reacting node = can do >> with such information is to ignore it, and therefore proposes to = allow >> reporting nodes not to insert OC-Supported-Features AVPs in answer >> messages. >> Currently only one feature is defined (OLR_DEFAULT_ALGO). >> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no = other >> feature is only interested in receiving/not receiving OC-OLR AVPs = from >> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly = indicates >> support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not = receiving >> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >>=20 >> a) There is no overload >> b) DOIC is not supported >>=20 >> The reacting DOIC endpoint does not need to differentiate between = these >> two cases as the behavior (do not throttle) is the same in both = cases. >> The -01 draft says in clause 4.1: >> If there is no single matching >> capability the reacting node MUST act as if it does not implement >> DOIC and cease inserting any DOIC related AVPs into any Diameter >> messages with this specific reacting node. >>=20 >> This however is inconsistent. >> The reacting node that ceases sending DOIC related AVPs would never >> recognize when the server is upgraded to support DOIC. >> Subsequent requests (not including DOIC related AVPs) may take a = different >> path towards the server and on that path there may be an agent that >> supports DOIC (with a match of supported features) and could take the = role >> of the reporting DOIC endpoint; but the agent cannot take this role = since >> the reacting node (although supporting DOIC) ceased sending of OC- >> Supported-Features AVPs. >> In summary: As long as no extension feature is defined within = draft-ietf- >> dime-ovli (i.e. never, since extensions will be defined in other >> drafts), there is no need for draft-ietf-dime-ovli to mandate or = even >> describe inclusion of OC-Supported-Features AVP in answer messages. >>=20 >> --=20 >> --------------------------------------+-------------------------- >> Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-docdt-dime-ovli | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------------+-------------------------- >>=20 >> Ticket URL: >> dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From jouni.nospam@gmail.com Sun Feb 9 04:45:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1911A05F9 for ; Sun, 9 Feb 2014 04:45:59 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiHaxPVfJxMK for ; Sun, 9 Feb 2014 04:45:57 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C25F61A022D for ; Sun, 9 Feb 2014 04:45:56 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so4001855lbd.15 for ; Sun, 09 Feb 2014 04:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LoyybCqC2eb8bteXg4JLoC/cE642CSbMOcgXFK0R4+s=; b=mf5nmLdUT3w2iC/CpyC0jleNrLL+BPKgr9ouQPs9VkS7bK8V/j10nZYtmzjxVuRR0Q b6bCiRJfP3HWxkbCIRfYi4VzevXz3F8xGuycC0uvCeGueVKQkgRJcidWLV6fZA89qdaz s4rvFxTXzlcbTpUB/nLPnphxVMQph7IwH3bo7nKtOMfDXSs20cSxRAn37nrVHFiNOG1r aoDNsKXbZGWXJeJnraMWO4tXsd7Gs4FHPKrMAp6Sk/MD2MsyRdWwo4kzvxihEL1vy9Pw 69UIIKpWUtdGz+OtyWq1XSVDUhzgKaiPlcTmQu3AzWgBkO+S7gvCfggKhLVFO9DdbizT LIpA== X-Received: by 10.112.180.72 with SMTP id dm8mr16847784lbc.28.1391949956352; Sun, 09 Feb 2014 04:45:56 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id dm8sm16941302lad.7.2014.02.09.04.45.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Feb 2014 04:45:53 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> Date: Sun, 9 Feb 2014 14:45:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Feb 2014 12:45:59 -0000 On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, February 07, 2014 11:21 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >=20 >=20 > On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> I better like Lionel's approach, but even that is not ok in the = unlikely extreme case where we have two servers in a realm, S1 is not = overloaded at all, S2 is 50% overloaded, and the aggregated realm = overload is 25%. Why should a client do a 25% throttling when sending = host type requests to the not at all overloaded S1? >> What is wrong with letting the client >> -not throttle host-type requests to S1, >> -throttle host type request to S2 with 50% and >> -throttle realm type requests wit 25%? >=20 > Isn't this what Lionel said below? > no it is not Ok, maybe I misread the "realm abatement is applied in any case except if there is an explicit report for the destination-host"? If this means the realm abatement is still applied after applying the host abatement, then I agree it is not the same you said. - Jouni > I am OK with Lionel's > "wording" here. >=20 > - Jouni >=20 >>=20 >>=20 >>=20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext = lionel.morand@orange.com >> Sent: Wednesday, February 05, 2014 4:14 PM >> To: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >>=20 >> I tend to agree except that I would reverse the logic as for the = routing principles: the Destination-host takes precedence when present = over Destination-Realm. So the realm abatement is applied in any case = except if there is an explicit report for the destination-host. >>=20 >> Lioenl >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >>=20 >> It makes more sense to me for a realm report to apply to all requests = targeted for that realm, independent the type of request. This implies = that it would apply to requests that also have a Destination-Host = specified. >>=20 >> If this is the definition of a realm report then we need to specify = the interaction between realm reports and host reports. >>=20 >> I propose that throttling would occur on the realm first and the host = second. If a message targetted for the host is throttled as a result of = realm overload then that throttled message would count as part of the = reduction needed to address the host overload. Messages to the host = that survive realm abatement would then be candidates for host overload. >>=20 >> Steve >>=20 >> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: >> The case "Realm" as described below raises another question: is it = prohibited for a realm to only rely on a global overload report for the = whole realm, whatever the nodes inside this realm? >> If not, only OLR with the report type "realm" would be received by = the reacting node. And the reduction indicated in the OLR will apply = always for the realm, whatever the presence of Destination-host AVP in = the request... except if an explicit report with the type "Host" as been = received for this destination-host. >>=20 >> Does it make sense? >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 >> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #34: Semantics of OC-Report-Type AVP >>=20 >> #34: Semantics of OC-Report-Type AVP >>=20 >> Text in clause 4.6 does not fully explain to which requests overload >> treatment of a given report type applies. >> Proposal: >>=20 >> 0 A host report. The overload treatment should apply to requests >> for which all of the following conditions are true: >> a) The Destination-Host AVP is present in the request and its = value >> matches the value of the Origin-Host AVP of the received = message >> that contained the OC-OLR AVP. >> b) The value of the Destination-Realm AVP in the request = matches the >> value of the Origin-Realm AVP of the received message >> that contained the OC-OLR AVP. >> c) The value of the Application-ID in the Diameter Header of = the >> request matches the value of the Application-ID of the = Diameter >> Header of the received message that contained the OC-OLR = AVP. >>=20 >>=20 >>=20 >> 1 A realm report. The overload treatment should apply to >> requests for which all of the following conditions are true: >> a) The Destination-Host AVP is absent in the request. >> b) The value of the Destination-Realm AVP in the request = matches the >> value of the Origin-Realm AVP of the received message >> that contained the OC-OLR AVP. >> c) The value of the Application-ID in the Diameter Header of = the >> request matches the value of the Application-ID of the = Diameter >> Header of the received message that contained the OC-OLR = AVP. >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From nsalot@cisco.com Sun Feb 9 22:58:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030D21A07B4 for ; Sun, 9 Feb 2014 22:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqPhKu_yih98 for ; Sun, 9 Feb 2014 22:58:37 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 531E41A079E for ; Sun, 9 Feb 2014 22:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3918; q=dns/txt; s=iport; t=1392015517; x=1393225117; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/6hME5HgMQlCSs40ryyozHmMw6irNwfsps0fEhCDd9g=; b=XnpFn9iy25apgzDeuBkeCw6OjYRB0Dyfy1kiPNAUEyoJvSDwUQiNmpPl eCNLQDS31GIqy8Qhlc2L4uaCwSSgkTYgQAFAHTLRxbGYm36cFWEaaRDCI N7ydmjdnVzVowKIsCtxk3SRe7e09XS28I4TG59PiQJ48ysJmKwCHa7iBl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFABR4+FKtJV2a/2dsb2JhbABZgww4V79NgQoWdIIlAQEBBAEBAWsXBAIBCBEEAQELHQcnCxQJCAIEARIIh30NyFAXjhsRAQsUOAaDHoEUBIkRkEyQb4MtgXE5 X-IronPort-AV: E=Sophos;i="4.95,816,1384300800"; d="scan'208";a="302924855" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 10 Feb 2014 06:58:37 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1A6wbcC030713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 06:58:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 00:58:37 -0600 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" Thread-Topic: [Dime] [dime] #48: Setting M-Bit gives wrong semantics Thread-Index: AQHPJFF9MyABzxUc/kmFOHAbJuqeZJqr80UAgAIeznA= Date: Mon, 10 Feb 2014 06:58:36 +0000 Message-ID: References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <27855_1391877281_52F65CA1_27855_6436_1_6B7134B31289DC4FAF731D844122B36E493891@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <27855_1391877281_52F65CA1_27855_6436_1_6B7134B31289DC4FAF731D844122B36E493891@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 06:58:46 -0000 Agree with Lionel. For existing application, the M-bit will never be set. For new applications, which are defined after the DOIC, the M-bit could be = set. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Saturday, February 08, 2014 10:05 PM To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics Hi Ben, I don't think that there is something wrong here. The setting of M-bit is per application, and it is true for any AVP. I'm not sure to understand your example. The use of the DOIC is defined per= application. For a newly defined application: - Either the node supports the new application and it will understand any A= VP defined as AVP to understand; - Either the node does not support new application and it will not receive = messages for this application or it will be transparent to any unknown AVP = (e.g. Relay). Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: vendredi 7 f=E9vrier 2014 23:11 =C0=A0: draft-docdt-dime-ovli= @tools.ietf.org; ben@nostrum.com Cc=A0: dime@ietf.org Objet=A0: [Dime] [dim= e] #48: Setting M-Bit gives wrong semantics #48: Setting M-Bit gives wrong semantics Multiple sections indicate that a new application that incorporates DOIC = can set the M-Bit on DOIC sub-avps. I don't think this ever does the right = thing. IIUC, If a node that otherwise supports DOIC encounters a DOIC avp that it= doesn't understand, and has the M-Bit set, it will cause a failure of the= application command. I don't think we want the lack of support of some D= OIC feature or extension to ever cause an application-level failure. I th= ink we are looking for something that would just cause the OLR to be ignor= ed. --=20 -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jean-jacques.trottin@alcatel-lucent.com Mon Feb 10 00:03:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6DA1A009A for ; Mon, 10 Feb 2014 00:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klEwVFQEcpeJ for ; Mon, 10 Feb 2014 00:03:51 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC391A0068 for ; Mon, 10 Feb 2014 00:03:51 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1A83n5G004828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Feb 2014 02:03:50 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1A83isO025043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Feb 2014 09:03:48 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 09:03:26 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org list" Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPIbybCAijuwdnOUWT6I7GO6C9KJqlMRIAgAANSACAAP8KgIADR6KAgAA/BwCAAGNpMA== Date: Mon, 10 Feb 2014 08:03:25 +0000 Message-ID: References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1EA9@DEMUMBX014.nsn-intra.net> <7610_1391532667_52F11A7B_7610_3074_1_6B7134B31289DC4FAF731D844122B36E4774C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1F71@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25EB@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B25EB@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 08:03:55 -0000 Hi all My own remarks - my trend is that the reacting and reporting node exchange their capabilit= ies so that each is aware of what the other supports. This also may allow t= he reporting node to indicate the reacting node which capabilities it has s= elected among those proposed by the reacting node. In 3GPP, there is a si= milar mechanism commonly used with supported features in the requests and = in the answer and this has not rose issues.=20 =20 - Ulrich is proposing an optimization to avoid to send the OC-Supported-f= eatures AVP in the answer, as currently we have only one algo (the default = one). I also assume that no ORL is sent in this answer (Reporting node bei= ng not in an overloaded situation). So even if the reacting node does not k= now immediately if the reporting node is supporting DOIC with default algo = or not, the reacting node will learn this later when the reporting node wi= ll send its first OC-OLR AVP which, with the current draft, is only used w= ith the default algo. So this optimization is applicable. Nevertheless, as = mentioned for 3GPP where a similar mechanism, 3GGP has not felt the requir= ement to introduce such an optimization for some cases, so this optimizatio= n may be not so a strong requirement. - then for the future, I would rather think that if new algos or new featur= es adding extensions to an algo, we will come back to the use of the OC Sup= ported Features in requests and answers. I am not sure that we should alway= s rely on new OLR AVPs for this as the existing OC-OLR AVP can be reused.=20 - so I am not against to have no OC-Supported feature in the answer, but I = would also allow it to be present(so a MAY) in the answers, which is more f= uture safe. =20 =20 - by the way, is the default algorithm mandatory? From the current draft as= the default algo is the only algo that a reacting node can advertise, so = the answer is currently yes. But, for future, I think we were in favor to h= ave at least a common supported algorithm by any entity supporting DOIC for= interoperability reasons. I have not seen this written; I think it should = be clarified in the draft. Best regards JJacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: vendredi 7 f=E9vrier 2014 14:55 =C0=A0: ext Jouni Korhonen Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag= es See inline -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 07, 2014 11:09 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message= s On Feb 5, 2014, at 10:03 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Hi Loinel, >=20 > it seems that we can safely remove OC-Supported-Feature AVP from answer m= essages in the draft-ietf-dime-ovli (which does not define extensions to it= self). This does not mean that a future extension cannot (re)-introduce it = when needed. It also does not mean that reporting nodes are not allowed to = include it in answer messages as long as answer messages have a *[AVP]. Not so fast. Leaving OC-Supported-Feature AVP away from the=20 answer is already supported by the -01. So there is nothing to fix in that part. it seems you agree that=20 a) reporting nodes that only support OLR_DEFAULT_ALGO are not required to s= end OC-Supported-Features AVP in answer messages (of course they may if the= re is the *[AVP]) b) reacting nodes that only support OLR_DEFAULT_ALGO can safely ignore OC-= Supported-Features AVPs received in answer messages c) behavior of the reacting node that only supports OLR_DEFAULT_ALGO does n= ot depend on presence/absence of OC-Supported-Features AVPs in received ans= wer messages if that's agreed, why not say so clearly in the draft? (the clear way to say so is to remove this AVP from answers. The thing that need to be fixed is the inconsistency on you pointed out which would make reacting node not to send any DOIC AVPs. - JOuni >=20 > Best regards > Ulrich >=20 > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: Tuesday, February 04, 2014 5:51 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: RE: [dime] #30: OC-Supported-Features AVP in answer messages >=20 > Hi Ulrich, >=20 > For the point 2 and 3, the difference between the "Should" and the "May" = is quite subtle here and is for me only an implementation option. >=20 > For 4 and 5, ok if the node only supports the default algo. In other word= s, only the OLR matters for nodes supporting only the default algo. The res= t is purely for information and can be safely ignored. >=20 > For 6, if the new feature consists in a new algo, it would mean defining = a new dedicated OLR AVP. So nodes supporting only the default algo will ign= ore any unknown AVP if received. >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 17:04 > =C0 : MORAND Lionel IMT/OLN; dime@ietf.org > Objet : RE: [dime] #30: OC-Supported-Features AVP in answer messages >=20 > Dear Lionel, >=20 > thank you for your response. >=20 > If I correctly understand, the principles would be: > 1. Sending OC-Supported-Features in answer messages is syntactically opti= onal. > 2. When the reacting node does only support OLR_DEFAULT_ALGO , the report= ing node should not insert an OC-Supported-Features AVP in the answer messa= ge. > 3. When the reporting node does only support OLR_DEFAULT_ALGO, it should = not insert an OC-Supported-Features AVP in the answer message. > 4. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignore = OC-Supported-Features AVPs received in answer messages. > 5. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignor a= ll extensions received in an OC-OLR. > 6. When a new feature is introduced, the spec introducing the new feature= must define the details to ensure interoperability of nodes supporting the= new feature with nodes that do not support the new feature (taking into ac= count that nodes not supporting the new feature act according to the princi= ples 1.-5.). >=20 >=20 > Best regards > Ulrich >=20 >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@= orange.com > Sent: Tuesday, February 04, 2014 4:01 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messa= ges >=20 > I think that there is actually an issue here but the proposed way to solv= e it is not the correct one. > The initial idea was to be able to use the same overload report with seve= ral algorithms. So the OLR was somehow only meaningful along with the OC-Fe= ature-Vector AVP. >=20 > But because the OC-Feature-Vector AVP is defined as a set of flags, it is= not possible to say that this OLR is to be used with only one given algo w= hen more than one is defined (as the bit flags will advertize 1 AND 2 for 2= supported algos). So the OC-Feature-Vector cannot be used to indicate the = abatement to perform. >=20 > As the syntax of the OC-Feature-Vector is adapted to advertize supported = algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP = for the reduction algo (default) and a new dedicated report AVP must be cre= ated when a new algo is introduced. In this way, the OC-OLR is self-explici= t. >=20 > It would be purely optional to send the Supported-Features AVP along with= the OC-OLR AVP. >=20 > Lionel=20 >=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #30: OC-Supported-Features AVP in answer messages >=20 > #30: OC-Supported-Features AVP in answer messages >=20 > According to the current feature advertisement/negotiation mechanism in > the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP > in answer messages to indicate their supported OC features to the reactin= g > DOIC endpoint. > The author of this document believes that the best a reacting node can d= o > with such information is to ignore it, and therefore proposes to allow > reporting nodes not to insert OC-Supported-Features AVPs in answer > messages. > Currently only one feature is defined (OLR_DEFAULT_ALGO). > A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other > feature is only interested in receiving/not receiving OC-OLR AVPs from > reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates > support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not receivin= g > an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >=20 > a) There is no overload > b) DOIC is not supported >=20 > The reacting DOIC endpoint does not need to differentiate between these > two cases as the behavior (do not throttle) is the same in both cases. > The -01 draft says in clause 4.1: > If there is no single matching > capability the reacting node MUST act as if it does not implement > DOIC and cease inserting any DOIC related AVPs into any Diameter > messages with this specific reacting node. >=20 > This however is inconsistent. > The reacting node that ceases sending DOIC related AVPs would never > recognize when the server is upgraded to support DOIC. > Subsequent requests (not including DOIC related AVPs) may take a differen= t > path towards the server and on that path there may be an agent that > supports DOIC (with a match of supported features) and could take the rol= e > of the reporting DOIC endpoint; but the agent cannot take this role since > the reacting node (although supporting DOIC) ceased sending of OC- > Supported-Features AVPs. > In summary: As long as no extension feature is defined within draft-ietf= - > dime-ovli (i.e. never, since extensions will be defined in other > drafts), there is no need for draft-ietf-dime-ovli to mandate or even > describe inclusion of OC-Supported-Features AVP in answer messages. >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 jean-jacques.trottin@alcatel-lucent.com Mon Feb 10 00:58:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00C41A05BF for ; Mon, 10 Feb 2014 00:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRFlkGC_NpiW for ; Mon, 10 Feb 2014 00:58:43 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id C96D81A0081 for ; Mon, 10 Feb 2014 00:58:43 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1A8wfj2024653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Feb 2014 02:58:43 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1A8wfYM005201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Feb 2014 09:58:41 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 09:58:41 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyiVRUleRbeSh0iImOK3F7m+mZqoSuqAgAAqeQCAANvNAIAABVqAgAABgQCAAC0EgIAACU8AgAShATA= Date: Mon, 10 Feb 2014 08:58:40 +0000 Message-ID: References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> In-Reply-To: <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 08:58:47 -0000 Hi all I agree to enhance the wording so by starting from the new Lionel's wordin= g. My comment is that we have to clearly distinguish the "validity duration" = given by the OC-Validity-Duration AVP (eg 10 s) from the "validity time" (= absolute value) at the end of which the received OLR is no more applicable= . - If the reacting node receives a new sequence number at T1 and a validity = duration of 10s, this will determine a validity time eg of T1+ 10s where th= e received OLR is applicable. - If later at T2, it receives another OLR with the Same sequence number, t= he validity time remains unchanged at T1+10s (as stated in Lionel's propos= al), this allows to ignore the OLRs with the same sequence number. - If at T3, the reacting node receives another OLR with a new sequence num= ber and with the same value, 10 s, (or a new value, eg 15s) for validity d= uration, the validity time becomes T3+10s (or T3+15s). So we can have sit= uations where the sequence number is changed but the other content of OC-OL= R AVP (reduction%, validity duration) itself has not changed: the effect is= only to shift the validity time in the reacting node. Do you share all this understanding?=20 So in the description, to be careful between validity duration and validity= time that may confuse. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: vendredi 7 f=E9vrier 2014 11:53 =C0=A0: lionel.morand@orange.com Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration AVP OK by me. - JOuni On Feb 7, 2014, at 12:19 PM, wrote: > Hi Maria Cruz, >=20 > I'm fine with the proposed clarification. > My point is that some parts belong to the handling of the OLR itself and = some other to the definition of the Validity duration. >=20 > Here is a proposal for clarification. Let me know if it covers your conce= rn. >=20 > Regards, >=20 > Lionel >=20 > ******************* >=20 > 4.3. OC-OLR AVP >=20 > [skip] >=20 > The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP. > It is possible to replay the same OC-OLR AVP multiple times between > the overload control endpoints, however, when the OC-OLR AVP content > changes or sending endpoint otherwise wants the receiving endpoint to > update its overload control information, then the OC-Sequence-Number > AVP MUST contain a new greater value than the previously received. > The receiver SHOULD discard an OC-OLR AVP with a sequence number that > is less than previously received one. >=20 > [New] >=20 > The OC-Validity-Duration AVP indicates the validity time of the overloa= d > report associated with a specific sequence number, measured after recep= tion > of the OC-OLR AVP. The validity time MUST NOT be updated after receptio= n=20 > of subsequent OC-OLR AVPs with the same sequence number. The default va= lue > for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When th= e=20 > OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default = value > applies. >=20 > [Skip] >=20 > 4.5. OC-Validity-Duration AVP >=20 > OLD: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 >=20 > NEW: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and indicates in seconds the validity time of the overload report. > The number of seconds is measured after reception of the first=20 > OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20 > The default value for the OC-Validity-Duration AVP is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values = 0 > (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used. > When invalid values are used, the default value for the OC-Validity-Dur= ation > AVP applies. >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20 > Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 08:38 =C0 : dime@ietf.org= =20 > Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hello Lionel, all, >=20 > I would like to clarify what "new and fresh", or even only "new" OC-OLR = AVP mean in the text. > It should be understood that it does not refer to the new (latest) receiv= ed AVP, but just the one that contains (potentially) new values, what only = happens for a new Sequence Number. In that line is the proposed text I prov= ided. >=20 > Best regards > /MCruz >=20 > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: viernes, 07 de febrero de 2014 8:33 > To: dime@ietf.org; Maria Cruz Bartolome > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi, >=20 > My point is just to say that we should make the difference between the de= finition and the use of the AVP. >=20 > And about the clarification, I would say that it is rather about how to p= opulate the OC-OLR AVP or when a new sequence number should be used. >=20 > Regards, >=20 > Lionel >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > Maria Cruz Bartolome a =E9crit : >=20 >=20 > Thanks Lionel, > The comment equally applies in order to clarify when the Validity-Duratio= n should include a new value. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 > lionel.morand@orange.com > Sent: jueves, 06 de febrero de 2014 19:07 > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi Maria Cruz, >=20 > Hi Maria Cruz, Steve, >=20 > Be careful! The reference you are using seems to be odd. >=20 > The current text in the draft says: >=20 > 4.5. OC-Validity-Duration AVP >=20 >=20 > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 > A timeout of the overload report has specific concerns that need to > be taken into account by the endpoint acting on the earlier received > overload report(s). Section 4.7 discusses the impacts of timeout in > the scope of the traffic abatement algorithms. >=20 > As a general guidance for implementations it is RECOMMENDED never to > let any overload report to timeout. Following to this rule, an > overload endpoint should explicitly signal the end of overload > condition and not rely on the expiration of the validity time of the > overload report in the reacting node. This leaves no need for the > reacting node to reason or guess the overload condition of the > reporting node. >=20 > I think that the definition of the OC-Validity-Duration AVP should remain= independent of the notion of Sequence-Number. > The sequence number does not change the value of the OC-Validity-Duration= AVP. It indicates that the OLR has to be updated or not. And if it is, a n= ew duration will be there (either implicit or explicit with the OC-Validity= -Duration AVP). >=20 > So if something needs to be clarified (I haven't checked), it should be i= n the handling of the OLR. >=20 > Regards, >=20 > Lionel >=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20 > Envoy=E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re:=20 > [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > This change looks pretty straight forward to me. I'll add it to the -02 = version of the draft unless I hear objections soon. >=20 > Steve > On 2/6/14 4:44 AM, dime issue tracker wrote: > #36: OC-Validity-Duration AVP >=20 > In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when= the OC-Validity-Duration AVP needs to be updated is ambiguous. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid since the reception of the new OC-OLR AVP (as indicated by the > OC-Sequence-Number AVP). >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 nsalot@cisco.com Mon Feb 10 01:05:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2989B1A07CE for ; Mon, 10 Feb 2014 01:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-DlA02Kb56L for ; Mon, 10 Feb 2014 01:05:17 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7211A07CB for ; Mon, 10 Feb 2014 01:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20372; q=dns/txt; s=iport; t=1392023117; x=1393232717; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8w2DAvXcCHf26cSwoqO2rTvtMMOJi8ocURdYNn6rEBk=; b=F+UUD4xvKMf0SNRLUT8lyoaQLBtR2l+Bz/mHt5Q2QitW0ud6zrQxOlzv kP01ayjyBNQPpVb5rZXDwgDqSzHwvm7xGlXXcqVSbhJh+5i9yZvX/krCG aaCQ12YrCtcleyOHUWMzZRZy/RZmZSy5uBjE0PssUvRZFESfKlzPSZC8Z w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAAmV+FKtJV2b/2dsb2JhbABZgww4V4MBvEsYcxZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGGQQDAgICJQsUAQgIAgQBEgiHfQ2oE6BOEwSBKYxyEQEfFiIGgmk1gRQElEKORodEgW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,816,1384300800"; d="scan'208";a="19198554" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 10 Feb 2014 09:05:16 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1A95GHO006869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 09:05:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 03:05:16 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAiAa9cA== Date: Mon, 10 Feb 2014 09:05:15 +0000 Message-ID: References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:05:21 -0000 VWxyaWNoLA0KDQpUaGUgY2FzZSAiYyIsIGkuZS4gIm90aGVyd2lzZSIgaXMgdGhlIHdob2xlIHBy b2JsZW0uDQpZb3UgYXNzdW1lIHRoYXQgIm90aGVyd2lzZSIgaXQgc2hhbGwgaW5jbHVkZSB0aGUg T0xSIGluIHRoZSBhbnN3ZXIgbWVzc2FnZS4NCldoaWxlIEkgYWxyZWFkeSBwb2ludGVkIG91dCBh IHZhbGlkIGNhc2UgKHdoaWNoIGlzIG5laXRoZXIgImEiIG5vciAiYiIpIC0gaS5lLiB0aGUgbGFz dCBvdmVybG9hZCBjb25kaXRpb24gZW5kZWQgbG9uZyB0aW1lIGFnbyAtIHdoZXJlIHRoZSByZXBv cnRpbmcgbm9kZSBuZWVkIG5vdC93aWxsIG5vdCBpbmNsdWRlIE9MUi4NCg0KU28gaXQgaXMgbm90 IGNvcnJlY3QgdGhhdCAib3RoZXJ3aXNlIiB0aGUgcmVwb3J0aW5nIG5vZGUgc2hhbGwgaW5jbHVk ZSBPTFIgaW4gYW5zd2VyIG1lc3NhZ2UuDQoNClRvIGJlIGhvbmVzdCwgd2UgbmVlZCBub3QgbmFp bCBkb3duIHRoZSBleGFjdCBjb25kaXRpb24gb24gd2hlbiB0aGUgT0xSIGlzIGluY2x1ZGVkIGJ5 IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgaXQgY2FuIGJlIGEgYml0IGxvc2UgYXMgd2VsbC4NCkkg ZG8gbm90IHNlZSBhbnkgaXNzdWUgb24gTGlvbmVsJ3MgaW50ZXJwcmV0YXRpb24gLSBpLmUuIGxl dCByZXBvcnRpbmcgbm9kZSBkbyB3aGF0IGl0IHRoaW5rcyBpcyB0aGUgYmVzdCB0byBkbyB0byBt aXRpZ2F0ZSBpdHMgb3duIG92ZXJsb2FkIGNvbmRpdGlvbi4gSW5zdGVhZCBvZiBuYWlsaW5nIGRv d24gYWxsIHRoZSB1c2UgY2FzZXMgZnJvbSB0aGUgcHJvdG9jb2wgcG9pbnQgb2YgdmlldyAod2hp Y2ggSSB0aGluayBpcyBub3QgbmVlZGVkIGFuZCBzZWNvbmRseSBub3QgcG9zc2libGUpLg0KU28g SSBzdGlsbCB0aGluayB0aGUgdGV4dCBiZWxvdyBpcyByZWFzb25hYmxlLiBCdXQgSSBhbSBmaW5l IGZvciBvdGhlciBhbHRlcm5hdGl2ZSBiYXNlZCBvbiB0aGUgYWJvdmUgbGluZSBvZiB0aGlua2lu Zy4NCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3Zlcmxv YWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9h ZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGlu IHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVh dHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRp b25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBu b3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRo ZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBp biB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZl YXR1cmUgQVZQLg0KIA0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmlj aC53aWVoZUBuc24uY29tXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDcsIDIwMTQgMzoyOSBQ TQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t OyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBb ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1 ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LA0KDQpJJ20g YWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24u DQoNCiJ3aGVuIGl0IHdhbnRzIHRvIHByb3ZpZGUvdXBkYXRlLi4uLml0IHNoYWxsIGluY2x1ZGUu Li4iIHRyYW5zbGF0ZXMgdG8gIi4uLml0IG1heSBpbmNsdWRlLi4uIi4NCg0KImluIG90aGVyIGNh c2VzIiBpbiB0aGUgZ2l2ZW4gY29udGV4dCB0cmFuc2xhdGVzIHRvICJ3aGVuIGl0IGRvZXMgbm90 IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUuLi4iDQoNCg0KV2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNh c2VzOg0KYSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUg aGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMg bm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93 cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4 cGlyZQ0KYykgb3RoZXJ3aXNlDQoNCmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBv ciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1h eSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9M UiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0 aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMg aXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKQ0KDQpVbHJpY2gNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90 QGNpc2NvLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA0OjQ5IFBNDQpU bzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IGxpb25lbC5tb3JhbmRAb3Jh bmdlLmNvbTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBb RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpVbHJpY2gs DQoNCkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJv cG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuDQpIb3cgYWJvdXQgdGhlIGZvbGxv d2luZy4NCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3Zl cmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVy bG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xS IGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQt RmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRk aXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBp cyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRv IHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9M UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk LUZlYXR1cmUgQVZQLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxy aWNoLndpZWhlQG5zbi5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMzo1 NyBQTQ0KVG86IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IE5pcmF2IFNhbG90IChuc2Fs b3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1l XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LCBMaW9u ZWwsDQoNCkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRp bmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lw bGUgMic6DQoNCjInLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJs b2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNl IHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAg aWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgcmVh c29uYWJsZSBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0aW9uIChlLmcuIHRoZSBsYXRlc3QgT0xS LCB3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4g T0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIiwgb3IgYW4gb2xkICBidXQgc29vbiBleHBpcmlu ZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQpOyBvdGhlcndp c2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1h dHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVz cG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy ZSBBVlAuDQoNCkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdhbnQgYXBw cm9hY2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93IHRoZSBy ZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBhcmUgbm90 IChzdWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1cywgd2l0 aCB1cCB0byBkYXRlIE9MUnMuDQoNClVscmljaCAgDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSBbbWFpbHRvOmxpb25l bC5tb3JhbmRAb3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAx MDoyMCBBTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBE RS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQot LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNCkVudm95w6nC oDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4DQrDgMKgOiBXaWVoZSwgVWxyaWNoIChOU04g LSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KT2JqZXTCoDog UmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNClVs cmljaCwNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVw b3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSBy ZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1Qg cmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFu IE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQpUaGUgcmVwb3J0aW5nIG5vZGUgbWF5IHNpbXBs eSBub3QgaW5jbHVkZSBPTFIgYXNzdW1pbmcgdGhhdCB0aGUgZWFybGllciBwcm92aWRlZCBPTFIg d2lsbCBleHBpcmUgYW5kIHRoZSByZWFjdGluZyBub2RlIHdpbGwgc3RvcCB0aHJvdHRsaW5nIHRo ZSB0cmFmZmljLg0KDQpbTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1l ZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRy YWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0 aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24g dGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5k aW5nLg0KDQpBcyB3ZSBoYWQgZGlzY3Vzc2VkIGVhcmxpZXIsIHRoZXJlIGlzIG5vIG5lZWQgZm9y IHRoZSByZXBvcnRpbmcgbm9kZSB0byBleHBsaWNpdGx5IHN0b3AgdGhyb3R0bGluZyBhdCBlYWNo IHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4gSW4gb3RoZXIgd29yZHMsIHRoZSByZXBv cnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhlIG5hdHVyYWwgZXhwaXJ5IG9mIHRoZSBPTFIgdG8gZmFj aWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhlIHNpZ25hbGluZyB0cmFmZmljIHRvd2FyZHMgaXQuDQoN CltMTV0gQWdyZWUNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJl cG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVuZGVk IGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0byBp bmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9uLg0K DQpbTE1dIEFncmVlDQoNClJlc3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVsb3cgYXJlIGZpbmUgd2l0 aCBtZS4NCg0KW0xNXSBBZ3JlZQ0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWls dG86dWxyaWNoLndpZWhlQG5zbi5jb21dIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAy MDE0IDI6MjMgUE0NClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7 IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1 cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBY3R1YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBw cmluY2lwbGVzOg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSINCjIuIHRoZSByZXBv cnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNp ZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29u dGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRo ZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5 IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0 aW5nICJubyBvdmVybG9hZCIpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4u KSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90 KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRh aW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNv bmZpcm0uDQoNClVscmljaA0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwgRmVi cnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh IHRocm90dGxpbmcNCg0KQWdyZWVkLsKgIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9h ZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0 aGUgaG9zdCBvciByZWFsbS7CoCBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3Zlcmxv YWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1l cyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0 LsKgIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4g bGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVyZSBpcyBubyBvdmVybG9hZCBm b3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQpTdGV2ZQ0KT24gMi81LzE0IDk6MTkgQU0sIE5pcmF2 IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFy dCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2Fk ZWQ/Ig0KwqANCldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdo dCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNs dWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVy IGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQg aGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRh bnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0 aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3Lg0K wqANClNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3VsZCBub3QgYWZmZWN0IHRoZSBw cmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4gVGhlIHJlYWN0aW5n IG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVyIE9MUiB1bnRpbCB0aGUg ZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUgZXhwbGljaXQgT0xSIHdp dGggIjAiIG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZlZC4NCkluIG15IHZpZXcsIHRoaXMgYWxs b3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5k IHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4NCsKgDQpSZWdhcmRz LA0KTmlyYXYuDQrCoA0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUs IDIwMTQgODowMCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCmlubGluZQ0KT24gMi81 LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6DQpPayB0 aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1VU1QgaW5zZXJ0IGFuIE9DLU9M UiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJlc3BvbmQgdG8gcmVxdWVzdCBt ZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgKGV2ZW4g d2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLg0KU1JEPiBXaHkgaW4gZXZlcnkg YW5zd2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVk IGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCsKgDQrCoA0KT3RoZXIgY3JpdGVyaWEgbGlrZSBSRVEx OCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQpTUkQ+IFJlcXVpcmluZyBhbiBvdmVy bG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1 dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sgZm9yIGFuIE9DLU9uZ29pbmct VGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlzIGFsc28gc3Vic3RhbnRpYWwg YWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGluc2VydGlu ZyBPTFJzLg0KDQoNCsKgDQrCoA0KRm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0 aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUg T0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJl IHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUg cHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXpl IHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBv ZiB0aGUgc2VxdWVuY2UgbnVtYmVyLsKgIA0KDQoNCsKgDQrCoA0KwqANCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IGRp bWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp dmVkIGEgdGhyb3R0bGluZw0KwqANCkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwu DQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlv bmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5 OjA3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMx OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSB1bmRlcnN0YW5kIHRoYXQgdGhl IHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VTIE5PVCBpbnNlcnQg dGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28gdGhlIG9wdGlvbnMgd291bGQgYmU6DQoxLSBP Qy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g QVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhl IGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1 cGRhdGVkLg0KwqANCklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAx IHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KwqANCkxpb25lbA0KwqANCi0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1l QHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAw OTo0OQ0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1lQGlldGYub3JnDQpP YmpldMKgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIzMx OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIEl0IGhhcyBiZWVuIHByb3Bvc2Vk IHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdGhhdCBpc8KgIHRv IGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVz c2FnZXMgdGhhdMKgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNh dGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KIChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5n IHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXMNCiBzdXJ2aXZlZCkgaXMgcGVyZm9y bWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBub8KgIHRo cm90dGxpbmcgaXMgcGVyZm9ybWVkLsKgIFJlcG9ydGluZyBET0lDIGVuZHBvaW50cyBtYXkgdXNl IHRoaXPCoCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBh IG5lZWQgdG8gdXBkYXRlIHRoZcKgIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0 ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3Vs dCBpbiB0aGUgbmVlZCBmb3IgdGhlwqAgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQ cyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9pbnQgY2Fubm90 IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2lu Z8KgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRs aW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBh bGxvd3MgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9pbnQgdG8gZGV0ZWN0IGFuZCBjb3JyZWN0 IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmfCoCBET0lDIGVuZHBvaW50 IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4NCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFs c28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQogSW4gc3VtbWFyeSBp dCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW UCB0b8KgIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0 bGluZy4NCsKgDQrCoA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsg eW91Lg0KDQo= From nsalot@cisco.com Mon Feb 10 01:11:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1834E1A06A9 for ; Mon, 10 Feb 2014 01:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpcXB8PMpuvP for ; Mon, 10 Feb 2014 01:11:50 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A071C1A04C5 for ; Mon, 10 Feb 2014 01:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22966; q=dns/txt; s=iport; t=1392023510; x=1393233110; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xLFhgQNMN4cvQytMn14YnGYAwPyUGNoSBngzIJZ+YDA=; b=SrEhe5a4hGaJOqnrbtxAUMxV7uKX22l2YPS699nooH8QavwmYvG16IsQ DfZwAdMDSR/uv6bzzm2CgPvuXskE1zVQu85e13vOSxJ/O7AUHbFt0KspN uSVT3jLgfvyCVh6bOIRtxlJ/xTXHnEwMSErXWZfZJ8iN3ZdcGF6YVUnJD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHiX+FKtJXG9/2dsb2JhbABZgww4V4MBvEsYdBZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGCw4EAwICAiULFAEICAIEARIIE4dqDagUoE4TBIEpjHIRAR8WIgYEgmU1gRQElEKORodEgW+BPoFoBwIXIg X-IronPort-AV: E=Sophos;i="4.95,816,1384300800"; d="scan'208";a="19188700" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-3.cisco.com with ESMTP; 10 Feb 2014 09:11:49 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1A9Bmlj007464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 09:11:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 03:11:48 -0600 From: "Nirav Salot (nsalot)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQ Date: Mon, 10 Feb 2014 09:11:47 +0000 Message-ID: References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:11:55 -0000 TWFyaWEtQ3J1eiwNCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSBvbiAic2VuZGluZyBPTFIgaW4g QUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMiLg0KQW5kIHdlIGFyZSBu b3QgdHJ5aW5nIHRvIHByZXZlbnQgaXQgLSBhdCBsZWFzdCB0aGF0IGlzIG15IGludGVudGlvbi4g DQpCdXQgdGhlIG1haW4gcXVlc3Rpb24gaXMsIGFyZSB3ZSB0cnlpbmcgdG8gcHJldmVudCBhbnkg b3RoZXIgcG9zc2libGUgaW1wbGVtZW50YXRpb24sIHdoaWNoIG1heSBiZSBzbWFydGVyIGFuZCBj YW4gYXZvaWQgaW5jbHVkaW5nIHJlZHVuZGFudCBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2Fn ZT8NCg0KTW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Ygb3Zl cmxvYWQgY29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2Vz Lg0KQnV0IGF0IHRoZSBzYW1lIHRpbWUsIEkgZG8gbm90IHdhbnQgdG8gcmVzdHJpY3QgdGhlIGRl dmVsb3BlcnMgd2hpY2ggY2FuIGNvbWUgdXAgd2l0aCBzb21lIG5pY2UgdHdlYWtzIGFuZCB0cmlj a3MgdG8gYXZvaWQgc2VuZGluZyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBldmVyeSBtZXNzYWdl LiBBbmQgdGhpcyBpcyB3aGVyZSB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYW5kIGF2b2lkIHB1dHRp bmcgc3VjaCByZXN0cmljdGlvbnMgaW4gcHJvdG9jb2wgZGVmaW5pdGlvbi4gDQpXaGF0IGRvIHlv dSB0aGluaz8NCg0KVGhpcyBhbHNvIHRoZSByZWFzb24gSSB3YXMgc3VnZ2VzdGluZyBsb29zZSBk ZXNjcmlwdGlvbiBvZiB3aGVuIHRvIGluY2x1ZGUgT0xSIChmcm9tIHRoZSByZXBvcnRpbmcgbm9k ZSBwb2ludCBvZiB2aWV3KS4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3 LCAyMDE0IDg6NTcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtk aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSGVsbG8gVWxyaWNoLCBO aXJhdiwNCg0KSSBhZ3JlZSB3aXRoIFVscmljaCB0aGF0IHRoZSB0ZXh0IHByb3ZpZGVkIGJ5IE5p cmF2IGlzIGp1c3QgYSBNQVksIGFuZCB3aGV0aGVyIG9yIG5vdCB0aGUgc2VydmVyIHNlbmRzIGFu IE9MUiBpbiBhbGwgYW5zd2VycyBzaGFsbCBub3QgYmUganVzdCBhIE1BWS4NCg0KT24gdGhlIG90 aGVyIGhhbmQsIGNyaXRlcmlhIHByb3ZpZGVkIGJ5IFVscmljaCBvbiB3aGVuIE9MUiBoYXMgdG8g YmUgc2VudCByZXF1aXJlcyB0aGUgc2VydmVyIGhhcyBzb21lIGtub3dsZWRnZToNCmEpIHRoZSBy ZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdv dCB0aGUgbGF0ZXN0IE9MUg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVk IChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVh Y3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCmMpIG90aGVy d2lzZQ0KDQpSZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xS IHJlY2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVp cmUgdGhpcyBrbm93bGVkZ2U/IA0KVGFrZSBpbnRvIGFjY291bnQgYXMgd2VsbCB0aGF0IGEgInJl YWN0aW5nIiBub2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChpbiBjYXNlIGl0IHByb3ZpZGVzIHNl cnZpY2UgdG8gYSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcg Y2xpZW50KSAgYW5kIGEgQ2xpZW50LiBJbiB0aGUgY2FzZSBvZiBBZ2VudHMsIGluIGZhY3QgdGhl IFNlcnZlciBtYXkgbm90IGV2ZW4ga25vdyBpZiB0aGlzIGlzIGdvaW5nIHRvIGFjdCBhcyBhIHJl YWN0aW5nIG5vZGUgb3IganVzdCB0cmFuc3BhcmVudGx5LCBpbiBmYWN0LCB0aGUgc2VydmVyIGRv ZXMgbm90IG5lZWQgdG8gaGF2ZSBhbnkga25vd2xlZGdlIGFib3V0IHdoYXQgYWdlbnRzIGluIHRo ZSBjaGFpbiB0byB0aGUgZmluYWwgQ2xpZW50Lg0KDQpUaGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0 aGluayB0aGF0IHNlbmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBh ZHZhbnRhZ2VzOg0KLQlzdGF0ZS1sZXNzIGltcGxlbWVudGF0aW9uICh0cmFuc2FjdGlvbiBvciBz ZXNzaW9uKSBpcyBzaW1wbGVyLA0KLQl0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFjdGluZyBub2RlDQotCXRo ZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBib3RoZXIgd2hldGhlciBhbiByZWFjdGluZyBub2Rl IGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBvciB3aGV0aGVyIHRoaXMgT0xSIGlzIHN0aWxs IHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLg0KLQlzZW5kaW5nIGFuIGFkZGl0aW9uYWwgQVZQIGlz IG5vdCBwcm9jZXNzaW5nIGNvbnN1bWluZywgaW4gY29tcGFyaXNvbiB3aXRoIHJlcXVpcmVkIGFi b3ZlIGNoZWNrcyAoaWYgdGhpcyBpcyBub3Qgc2VudCkuIA0KCUluIGZhY3QsIGluIGFuIG92ZXJs b2FkIHNpdHVhdGlvbiwgdGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBp bmZvcm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsIA0KCWFuZCB0 aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNhcmUgdG8gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb25zICAN Ci0JbW9yZSByb2J1c3Qgc29sdXRpb24sIGFzIG5vIG5lZWQgdG8gY2F0ZXIgZm9yIGFsbCB0aGUg Y2hlY2tzIG9uIHRoZSBuZWVkIHRvIHNlbmQgaW5mb3JtYXRpb24sICBmb3Igc2l0dWF0aW9ucyB3 aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCAg4oCmDQoNCg0KQmVzdCByZWdhcmRzDQov TUNydXoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBE RS9NdW5pY2gpDQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTkNClRv OiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207 IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtk aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsDQoNCkknbSBh ZnJhaWQgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi4N Cg0KIndoZW4gaXQgd2FudHMgdG8gcHJvdmlkZS91cGRhdGUuLi4uaXQgc2hhbGwgaW5jbHVkZS4u LiIgdHJhbnNsYXRlcyB0byAiLi4uaXQgbWF5IGluY2x1ZGUuLi4iLg0KDQoiaW4gb3RoZXIgY2Fz ZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gIndoZW4gaXQgZG9lcyBub3Qg d2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQpXZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2Fz ZXM6DQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBo YXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBu b3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dz IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhw aXJlDQpjKSBvdGhlcndpc2UNCg0KaW4gY2FzZSBhKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9y IG1heSBub3QgcmVwbGF5IHRoZSBPTFIgaW4gY2FzZSBiKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5 IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUgcmVhY3Rpbmcgbm9kZSB3aXRoIHRoZSBsYXRlc3QgT0xS IGluIGNhc2UgYykgdGhlIHJlcG9ydGluZyBub2RlIE1VU1QgaW5jbHVkZSB0aGUgT0xSIGluIHRo ZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcgbm9kZSBkb2VzIG5vdCBrbm93IHdoZXRoZXIgdGhpcyBp cyBhIHJlcGxheSBvciBhbiB1cGRhdGUpDQoNClVscmljaA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RA Y2lzY28uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkgUE0NClRv OiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFu Z2UuY29tOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtE aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNClVscmljaCwN Cg0KSXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0IHByb2JhYmx5IHRoZSBwcm9w b3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC4NCkhvdyBhYm91dCB0aGUgZm9sbG93 aW5nLg0KDQpXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVy bG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJs b2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIg aW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1G ZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRp dGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlz IG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8g dGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xS IGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQt RmVhdHVyZSBBVlAuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgW21haWx0bzp1bHJp Y2gud2llaGVAbnNuLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3 IFBNDQpUbzogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgTmlyYXYgU2Fsb3QgKG5zYWxv dCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVd IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsIExpb25l bCwNCg0KSSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGlu ZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBs ZSAyJzoNCg0KMicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zlcmxv YWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2Ug dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBp ZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFz b25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIs IHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBP TFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiLCBvciBhbiBvbGQgIGJ1dCBzb29uIGV4cGlyaW5n IE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCk7IG90aGVyd2lz ZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0 dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNw b25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJl IEFWUC4NCg0KSSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Utd2FudCBhcHBy b2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJl cG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3Qg KHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRo IHVwIHRvIGRhdGUgT0xScy4NCg0KVWxyaWNoICANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFttYWlsdG86bGlvbmVs Lm1vcmFuZEBvcmFuZ2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDEw OjIwIEFNDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERF L011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCi0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBOaXJhdiBTYWxvdCAobnNhbG90KSBFbnZvecOpwqA6 IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgMKgOiBXaWVoZSwgVWxyaWNoIChOU04gLSBE RS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZyBPYmpldMKgOiBSZTog W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KVWxyaWNo LA0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiByZXBvcnRp bmcgbm9kZSAib3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9y dGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1 cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0Mt U3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5v dCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxs IGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRy YWZmaWMuDQoNCltMTV0gQWdyZWUuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBub3QgZGVlbWVkIHJl cXVpcmVkIGZvciB0aGUgZGVmYXVsdCBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQu IEhvdyBhbmQgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgZGVjaWRlcyB0byBpbmNsdWRlIHRoZSBP TFIgaW4gdGhlIGFuc3dlciBtYXkgZGVwZW5kIG9uIHRoZSBhcHBsaWNhdGlvbiBvciBvbiB0aGUg aW1wbGVtZW50YXRpb24uIEF0IGxlYXN0LCBpdCBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcu DQoNCkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhl IHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5nIGF0IGVhY2ggcmVh Y3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3b3JkcywgdGhlIHJlcG9ydGlu ZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9MUiB0byBmYWNpbGl0 YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJkcyBpdC4NCg0KW0xN XSBBZ3JlZQ0KDQpUaGVyZSBtYXkgYmUgb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0 aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgbGFzdCBvdmVybG9hZCBzaXR1YXRpb24gZW5kZWQgbG9u ZyB0aW1lIGJhY2sgaW4gdGhlIHBhc3QsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGl0IHRvIGluY2x1 ZGUgT0xSIGlmIGN1cnJlbnRseSB0aGVyZSBpcyBubyBvdmVybG9hZCBjb25kaXRpb24uDQoNCltM TV0gQWdyZWUNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1l Lg0KDQpbTE1dIEFncmVlDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgW21haWx0bzp1 bHJpY2gud2llaGVAbnNuLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAy OjIzIFBNDQpUbzogZXh0IFN0ZXZlIERvbm92YW47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1l QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl ZCBhIHRocm90dGxpbmcNCg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNp cGxlczoNCjEuIExhY2sgb2YgT0xSIG1lYW5zICJubyBjaGFuZ2UiDQoyLiB0aGUgcmVwb3J0aW5n IG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5v dCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5l ZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVh Y3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgdGhlIGxhdGVzdCBPTFIgKHdoaWNoIG1heSBiZSBh biBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAi bm8gb3ZlcmxvYWQiKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhl IHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVT VCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQg YW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQpDYW4gcGVvcGxlIHBsZWFzZSBjb25maXJt Lg0KDQpVbHJpY2gNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDA1LCAyMDE0IDQ6MzUgUE0NClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv dHRsaW5nDQoNCkFncmVlZC7CoCBUbyByZXN0YXRlIC0tIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVw b3J0IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhv c3Qgb3IgcmVhbG0uwqAgSWYgdGhlcmUgaXMgYSBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJl cG9ydCB0aGVuIGl0IGNvbnRpbnVlcyB0byBhcHBseSB1bnRpbCBpdCBlaXRoZXIgdGltZXMgb3V0 IG9yIGlzIGV4cGxpY2l0bHkgY2hhbmdlZCB3aXRoIGEgbmV3IG92ZXJsb2FkIHJlcG9ydC7CoCBJ ZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sg b2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRo ZSBob3N0IGFuZCByZWFsbS4NCg0KU3RldmUNCk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxv dCAobnNhbG90KSB3cm90ZToNCkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQgInNo b3VsZG7igJl0IGxhY2sgb2YgT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPyIN CsKgDQpXZSBoYWQgc29tZSBkaXNjdXNzaW9uIHNvbWV0aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhh dCBpdCBpcyByZWFzb25hYmxlIHRvIG5vdCBtYW5kYXRlIHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0 aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlLiBFLmcuIHdoZW4gdGhlIHNlcnZlciBpcyBj YXBhYmxlIG9mIHRyYWNraW5nIHdoYXQgaXMgc2VudCB0byB3aGljaCBjbGllbnQgYW5kIGhlbmNl IHdhbnRzIHRvIGF2b2lkIHNlbmRpbmcgaW5mb3JtYXRpb24gd2hpY2ggaXMgcmVkdW5kYW50LiBC dXQgdGhpcyBpcyBvcHRpb25hbCBpbXBsZW1lbnRhdGlvbiBhbmQgYXQgdGhlIHNhbWUgdGltZSBu ZWVkIG5vdCBiZSBwcm9oaWJpdGVkIGZyb20gcHJvdG9jb2wgcG9pbnQgb2Ygdmlldy4NCsKgDQpT byBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlv dXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2Rl IGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGly eSBvZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICIw IiBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQpJbiBteSB2aWV3LCB0aGlzIGFsbG93cyBm b3IgZmxleGlibGUgaW1wbGVtZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3Vu ZCBoYW5kbGluZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuDQrCoA0KUmVnYXJkcywNCk5p cmF2Lg0KwqANCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0 IDg6MDAgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAj MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQppbmxpbmUNCk9uIDIvNS8xNCA3 OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOg0KT2sgdGhlbiBs ZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQ IGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2Fn ZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4g bm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS4NClNSRD4gV2h5IGluIGV2ZXJ5IGFuc3dl ciBtZXNzYWdlP8KgIFNob3VsZG4ndCBsYWNrIG9mIGFuIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBu b3Qgb3ZlcmxvYWRlZD8NCg0KDQrCoA0KwqANCk90aGVyIGNyaXRlcmlhIGxpa2UgUkVRMTggb3Ig UkVRMTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQg cmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVx dWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90 dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0 aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xS cy4NCg0KDQrCoA0KwqANCkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJl YWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiBy ZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUg cHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nl c3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUg cmlzayB0b28gbWlzcyBhIG5ldyBPTFI/DQpTUkQ+IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhl IHNlcXVlbmNlIG51bWJlci4NCg0KDQrCoA0KwqANCsKgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw NSwgMjAxNCA1OjI3IEFNDQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBkaW1lQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo cm90dGxpbmcNCsKgDQpJIHNoYXJlIHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLg0KwqANClJl Z2FyZHMsDQpOaXJhdi4NCsKgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlN RSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3Jh bmRAb3JhbmdlLmNvbQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTQ0K VG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0 IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNv bmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIg aW4gZXZlcnkgYW5zd2VyLiANClNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOg0KMS0gT0MtT0xSIEFW UCBpbiBldmVyeSBhbnN3ZXINCjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBl dmVyeSByZXF1ZXN0ICsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50 IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4N CsKgDQpJZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0 aGUgYmVzdCBhcHByb2FjaC4NCsKgDQpMaW9uZWwNCsKgDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCkRlwqA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRv b2xzLmlldGYub3JnXQ0KRW52b3nDqcKgOiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDkNCsOA wqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PCoDogZGltZUBpZXRmLm9yZw0KT2JqZXTCoDog W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCiMzMTogU2VuZGlu ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0 IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZp bmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXPCoCB0byBiZSBpbmNs dWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo YXTCoCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuIFRoaXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBT ZXF1ZW5jZS1OdW1iZXINCiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGlj aCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQogc3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJz ZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm/CoCB0aHJvdHRsaW5n IGlzIHBlcmZvcm1lZC7CoCBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzwqAg aW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRv IHVwZGF0ZSB0aGXCoCByZWFjdGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIu DQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhl IG5lZWQgZm9yIHRoZcKgIHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZl cnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9JQ8KgIGVuZHBvaW50IGNhbm5vdCBrbm93IHdo ZXRoZXIgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaXMgYWN0dWFsbHkgZG9pbmfCoCB0aGUg cmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCiBU aGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRo ZSByZXBvcnRpbmcgRE9JQ8KgIGVuZHBvaW50IHRvIGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJv cHJpYXRlIHRocm90dGxpbmcgYnkgdGhlIHJlYWN0aW5nwqAgRE9JQyBlbmRwb2ludCAoY2F1c2Vk IGJ5IHdoYXRldmVyIHJlYXNvbikuDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93 cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4Lg0KIEluIHN1bW1hcnkgaXQgaXMgcHJv cG9zZWQgdG8gZGVmaW5lIHRoZSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdG/CoCBi ZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQrC oA0KwqANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5n IGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGltZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RpbWUNCg== From maria.cruz.bartolome@ericsson.com Mon Feb 10 01:25:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099921A06AF for ; Mon, 10 Feb 2014 01:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJmO5qLEPs3t for ; Mon, 10 Feb 2014 01:25:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05BC01A07CC for ; Mon, 10 Feb 2014 01:25:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-f9-52f89b1be83b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 97.63.10875.B1B98F25; Mon, 10 Feb 2014 10:25:47 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 10:25:46 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyh3Mk+g2dTxBkStndl7a0rG2ZqoSuqAgAAqeQCAAOmhgIAACErugAAAQ9CAABU4MIAEwPXw Date: Mon, 10 Feb 2014 09:25:46 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92097726B1@ESESSMB101.ericsson.se> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvja707B9BBtu3y1nM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD0rL7IUnI2tuH1uEUsD42rvLkZODgkBE4m9e+ewQNhiEhfu rWfrYuTiEBI4xCjx6MM1dghnCaPE9RnHWUGq2ATsJC6dfsHUxcjBISKgLHH6lwNIWFjAQuLb zjcsEGFLidMvgkHCIgJREs0TvjOChFkEVCUON1mAhHkFfCUaz/eyQEw/zSLx6fBZVhCHU6Cd UWLypqPMIFWMQAd9P7WGCcRmFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSazYfokRol5P 4sbUKWwQtrbEsoWvmSE2C0qcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGNlzEzNz0ssNNzEC w/7glt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkY9nd1d PV6CPzn89iw9vSDRXVRKvF7Goqfj/XW9wnpll5/L1lo+k5v3YltREZeKVIZEuMK3g273Sm2N l/KeKtibtp1DQSmolOmG74JDSYluTq3H/b9PN5z0IdJGxSs/yuyMaqbDVf0QtgDhBg3u6k+u P3JXH5fxv7tU3y4lTGG9zJVFc4z1lViKMxINtZiLihMBFXeu8kkCAAA= Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:25:52 -0000 Hello Lionel, all, Proposal is fine for me. Thanks /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: viernes, 07 de febrero de 2014 11:19 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] [dime] #36: OC-Validity-Duration AVP Hi Maria Cruz, I'm fine with the proposed clarification. My point is that some parts belong to the handling of the OLR itself and so= me other to the definition of the Validity duration. Here is a proposal for clarification. Let me know if it covers your concern= . Regards, Lionel ******************* 4.3. OC-OLR AVP [skip] The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP. It is possible to replay the same OC-OLR AVP multiple times between the overload control endpoints, however, when the OC-OLR AVP content changes or sending endpoint otherwise wants the receiving endpoint to update its overload control information, then the OC-Sequence-Number AVP MUST contain a new greater value than the previously received. The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one. [New] The OC-Validity-Duration AVP indicates the validity time of the overload report associated with a specific sequence number, measured after recept= ion of the OC-OLR AVP. The validity time MUST NOT be updated after reception= =20 of subsequent OC-OLR AVPs with the same sequence number. The default val= ue for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the= =20 OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default v= alue applies. [Skip] 4.5. OC-Validity-Duration AVP OLD: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity- Duration AVP were not present. NEW: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and indicates in seconds the validity time of the overload report. The number of seconds is measured after reception of the first=20 OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20 The default value for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values 0 (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used. When invalid values are used, the default value for the OC-Validity-Dura= tion AVP applies. -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 08:38 =C0=A0: dime@ietf.org Objet= =A0: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hello Lionel, all, I would like to clarify what "new and fresh", or even only "new" OC-OLR AV= P mean in the text. It should be understood that it does not refer to the new (latest) received= AVP, but just the one that contains (potentially) new values, what only ha= ppens for a new Sequence Number. In that line is the proposed text I provid= ed. Best regards /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: viernes, 07 de febrero de 2014 8:33 To: dime@ietf.org; Maria Cruz Bartolome Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi, My point is just to say that we should make the difference between the defi= nition and the use of the AVP. And about the clarification, I would say that it is rather about how to pop= ulate the OC-OLR AVP or when a new sequence number should be used. Regards, Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange Maria Cruz Bartolome a =E9crit : Thanks Lionel, The comment equally applies in order to clarify when the Validity-Duration = should include a new value. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 06 de febrero de 2014 19:07 To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi Maria Cruz, Hi Maria Cruz, Steve, Be careful! The reference you are using seems to be odd. The current text in the draft says: 4.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the "new and fresh" OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity- Duration AVP were not present. A timeout of the overload report has specific concerns that need to be taken into account by the endpoint acting on the earlier received overload report(s). Section 4.7 discusses the impacts of timeout in the scope of the traffic abatement algorithms. As a general guidance for implementations it is RECOMMENDED never to let any overload report to timeout. Following to this rule, an overload endpoint should explicitly signal the end of overload condition and not rely on the expiration of the validity time of the overload report in the reacting node. This leaves no need for the reacting node to reason or guess the overload condition of the reporting node. I think that the definition of the OC-Validity-Duration AVP should remain i= ndependent of the notion of Sequence-Number. The sequence number does not change the value of the OC-Validity-Duration A= VP. It indicates that the OLR has to be updated or not. And if it is, a new= duration will be there (either implicit or explicit with the OC-Validity-D= uration AVP). So if something needs to be clarified (I haven't checked), it should be in = the handling of the OLR. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy= =E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: [Dime] [= dime] #36: OC-Validity-Duration AVP This change looks pretty straight forward to me. I'll add it to the -02 ve= rsion of the draft unless I hear objections soon. Steve On 2/6/14 4:44 AM, dime issue tracker wrote: #36: OC-Validity-Duration AVP In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when = the OC-Validity-Duration AVP needs to be updated is ambiguous. Now: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid since the reception of the new OC-OLR AVP (as indicated by the OC-Sequence-Number AVP). Proposal: The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid in relation to the reception of the first OC-OLR AVP with a specific sequence number. For a given sequence number, the OC-Validity-Duration shall always carry the same value. ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From maria.cruz.bartolome@ericsson.com Mon Feb 10 01:32:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9371A06A9 for ; Mon, 10 Feb 2014 01:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR_0WOhnFsky for ; Mon, 10 Feb 2014 01:32:50 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 367C21A06B2 for ; Mon, 10 Feb 2014 01:32:49 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-10-52f89cc041d0 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5C.93.04249.0CC98F25; Mon, 10 Feb 2014 10:32:48 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 10:32:47 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifECAAAXaAIAADfeAgAAEaQCAASwPUP//+iEAgAADQgCAABZZ8IAAVmMAgAE5EdCAAF/ugIAEQVKAgAAVgXA= Date: Mon, 10 Feb 2014 09:32:47 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje6BOT+CDN6cF7aY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGSvfaxW828lYcbuvmaWBsWcrYxcjB4eEgInEgWsWXYycQKaY xIV769m6GLk4hASOMEqsbTvLCuEsYZT4t3Q9I0gVm4CdxKXTL5hAmkUElCVO/3IACQsLlEu8 vHSFGcQWEaiQ+Lz1EhNIr4hAF6PE8dXvwXpZBFQlDizbyg5i8wr4SjzevoMRYsF6Dok5M76D dXMCJRr2vGYFsRmBTvp+ag0TiM0sIC5x68l8JohTBSSW7DnPDGGLSrx8/I8VwlaSWLH9Ethn zAKaEut36UO0KkpM6X4ItVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGLkKE4tTspNNzLY xAgM/INbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGI+0 uDyefsPGRSrj23/xa+vWv5X2iLWeyqTVKbqkXfbZpmUsKbvTLD8XOE+1fWQ1lXX3z08vxcKu tj+d/OtHb3MzF9PursbPhTwS/LsOVbu0t1fO296sv0qnlvuScqkRi82MhBKhjUpLvFNmBFqq qGyvP6n3/bzXpR2tHf8viBnWmcScKwzrV2Ipzkg01GIuKk4EABFwPWNKAgAA Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:32:54 -0000 TmlyYXYsIGFsbCwNCg0KSSB0aGluayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCBy b2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KSSB1 bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwgYXMgYSBwdXJlICJtYXkiLCBidXQgbGVhdmluZyBpdCB1 cCB0byBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBhc3N1cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFs aWQgT0xSIGluZm9ybWF0aW9uLCB3aGF0IGlzIGJhc2ljIGZvciB0aGlzIG1lY2hhbmlzbSB0byB3 b3JrLiANCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0g DQpTZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyDQpUbzogTWFyaWEgQ3J1 eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpNYXJpYS1DcnV6LA0KDQpJIGZ1bGx5 IGFncmVlIHdpdGggeW91IG9uICJzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBp bXBvcnRhbnQgYWR2YW50YWdlcyIuDQpBbmQgd2UgYXJlIG5vdCB0cnlpbmcgdG8gcHJldmVudCBp dCAtIGF0IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9uLiANCkJ1dCB0aGUgbWFpbiBxdWVzdGlv biBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1l bnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVk dW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPw0KDQpNb3N0IHByb2JhYmx5LCB0 aGUgdmVyeSBmaXJzdCBpbXBsZW1lbnRhdGlvbiBvZiBvdmVybG9hZCBjb250cm9sIHdpbGwgaW5j bHVkZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMuDQpCdXQgYXQgdGhlIHNhbWUgdGlt ZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29t ZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRo ZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdl IG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBp biBwcm90b2NvbCBkZWZpbml0aW9uLiANCldoYXQgZG8geW91IHRoaW5rPw0KDQpUaGlzIGFsc28g dGhlIHJlYXNvbiBJIHdhcyBzdWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8g aW5jbHVkZSBPTFIgKGZyb20gdGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLg0KDQpS ZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1F IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBC YXJ0b2xvbWUNClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDcsIDIwMTQgODo1NyBQTQ0KVG86IGRp bWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp dmVkIGEgdGhyb3R0bGluZw0KDQpIZWxsbyBVbHJpY2gsIE5pcmF2LA0KDQpJIGFncmVlIHdpdGgg VWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1BWSwgYW5k IHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNo YWxsIG5vdCBiZSBqdXN0IGEgTUFZLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJv dmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBz ZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdlOg0KYSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRo YXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQpiKSB0 aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBh IHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4g T0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KYykgb3RoZXJ3aXNlDQoNClJlcG9ydGluZyBub2Rl IG11c3QgaGF2ZSBzb21lIGtub3dsZWRnZSBhYm91dCBPTFIgcmVjZXB0aW9uL3N0YXR1cyBpbiBy ZWFjdGluZyBub2RlLiBIb3cgZG9lcyBzZXJ2ZXIgYWNxdWlyZSB0aGlzIGtub3dsZWRnZT8gDQpU YWtlIGludG8gYWNjb3VudCBhcyB3ZWxsIHRoYXQgYSAicmVhY3RpbmciIG5vZGUgbWF5IGJlIGJv dGggYW4gQWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMgc2VydmljZSB0byBhIHJlYWxtIG9yIGFj dGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpICBhbmQgYSBDbGllbnQu IEluIHRoZSBjYXNlIG9mIEFnZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBr bm93IGlmIHRoaXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRy YW5zcGFyZW50bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFu eSBrbm93bGVkZ2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBD bGllbnQuDQoNClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIg aW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXM6DQotCXN0YXRlLWxl c3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNlc3Npb24pIGlzIHNpbXBsZXIsDQot CXRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8g c2VuZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGUNCi0JdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVk IHRvIGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQg YW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJl ZCkuDQotCXNlbmRpbmcgYW4gYWRkaXRpb25hbCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3Vt aW5nLCBpbiBjb21wYXJpc29uIHdpdGggcmVxdWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlz IG5vdCBzZW50KS4gDQoJSW4gZmFjdCwgaW4gYW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFz aWVzdCBhbmQgbGVhc3QgY29tcGxleCBpcyB0byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwg YWZmZWN0ZWQvYXBwbGljYWJsZSBub2RlcywgDQoJYW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRha2Ug Y2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMgIA0KLQltb3JlIHJvYnVzdCBzb2x1dGlv biwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVja3Mgb24gdGhlIG5lZWQgdG8g c2VuZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdl IGlzIGxvc3QsICDigKYNCg0KDQpCZXN0IHJlZ2FyZHMNCi9NQ3J1eg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkNClNlbnQ6IHZpZXJu ZXMsIDA3IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo1OQ0KVG86IGV4dCBOaXJhdiBTYWxvdCAobnNh bG90KTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgZXh0IFN0ZXZlIERvbm92YW47IGRp bWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp dmVkIGEgdGhyb3R0bGluZw0KDQpOaXJhdiwNCg0KSSdtIGFmcmFpZCB5b3VyIHByb3Bvc2VkIHRl eHQgZG9lcyBub3QgcmVmbGVjdCB0aGUgaW50ZW50aW9uLg0KDQoid2hlbiBpdCB3YW50cyB0byBw cm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uIiB0cmFuc2xhdGVzIHRvICIuLi5p dCBtYXkgaW5jbHVkZS4uLiIuDQoNCiJpbiBvdGhlciBjYXNlcyIgaW4gdGhlIGdpdmVuIGNvbnRl eHQgdHJhbnNsYXRlcyB0byAid2hlbiBpdCBkb2VzIG5vdCB3YW50IHRvIHByb3ZpZGUvdXBkYXRl Li4uIg0KDQoNCldlIGhhdmUgdGhlIGZvbGxvd2luZyBjYXNlczoNCmEpIHRoZSByZXBvcnRpbmcg bm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0 ZXN0IE9MUg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRv ZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9k ZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCmMpIG90aGVyd2lzZQ0KDQpp biBjYXNlIGEpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCByZXBsYXkgdGhlIE9M UiBpbiBjYXNlIGIpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCB1cGRkYXRlIHRo ZSByZWFjdGluZyBub2RlIHdpdGggdGhlIGxhdGVzdCBPTFIgaW4gY2FzZSBjKSB0aGUgcmVwb3J0 aW5nIG5vZGUgTVVTVCBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9ydGlu ZyBub2RlIGRvZXMgbm90IGtub3cgd2hldGhlciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0 ZSkNCg0KVWxyaWNoDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBO aXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQpTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMDYsIDIwMTQgNDo0OSBQTQ0KVG86IFdpZWhlLCBVbHJpY2ggKE5TTiAt IERFL011bmljaCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IGV4dCBTdGV2ZSBEb25v dmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KVWxyaWNoLA0KDQpJdCBzZWVtcyB3ZSBhbGwgYXJl IG9uIHNhbWUgcGFnZSBidXQgcHJvYmFibHkgdGhlIHByb3Bvc2VkIHdvcmRpbmcgYmVsb3cgaXMg bm90IHRoZSBiZXN0Lg0KSG93IGFib3V0IHRoZSBmb2xsb3dpbmcuDQoNCldoZW4gdGhlIHJlcG9y dGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUgbmV3IG92ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0 byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVwb3J0IHRvd2FyZHMgYSBy ZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRo ZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRo ZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2Fz ZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVy bG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhl IHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0 aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KUmVnYXJk cywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2llaGUsIFVs cmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0KU2Vu dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDM6NTcgUE0NClRvOiBleHQgbGlvbmVsLm1v cmFuZEBvcmFuZ2UuY29tOyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZlIERvbm92YW47 IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1 cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpOaXJhdiwgTGlvbmVsLA0KDQpJIGNhbiB1bmRlcnN0YW5k IE5pcmF2J3MgY29uY2VybiAoYWx0aG91Z2ggdmlvbGF0aW5nIFJFUTEwKSBhbmQgaG9wIGl0IGlz IGFkZHJlc3NlZCBieSB0aGUgbW9kaWZpZWQgcHJpbmNpcGxlIDInOg0KDQoyJy4gdGhlIHJlcG9y dGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lk ZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250 YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhl IHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29udHJv bCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9MUiBy ZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVy bG9hZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24gZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9ydGlu ZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBh d2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVk IG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGlj aCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQpJIGRvbid0IGFncmVl IHdpdGggTGlvbmVscyBkby13aGF0LXlvdS13YW50IGFwcHJvYWNoLiBPdmVybG9hZCBjb250cm9s IHdpbGwgbm90IHdvcmsgd2hlbiB3ZSBhbGxvdyB0aGUgcmVwb3J0aW5nIG5vZGUgbm90IHRvIHVw ZGF0ZSByZWFjdGluZyBub2Rlcywgd2hpY2ggYXJlIG5vdCAoc3VmZmljaWFudGx5KSBhd2FyZSBv ZiB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0dXMsIHdpdGggdXAgdG8gZGF0ZSBPTFJzLg0KDQpV bHJpY2ggIA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBsaW9u ZWwubW9yYW5kQG9yYW5nZS5jb20gW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dDQpT ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NClRvOiBOaXJhdiBTYWxv dCAobnNhbG90KTsgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERv bm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0 aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0 IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95w6nCoDogamV1ZGkgNiBmw6l2cmllciAyMDE0 IDEwOjA4IMOAwqA6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBE b25vdmFuOyBkaW1lQGlldGYub3JnIE9iamV0wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0 aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpVbHJpY2gsDQoNCkkgYW0gbm90IHN1cmUgYWJv dXQgZm9yY2luZyB0aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2RlICJvdGhlcndpc2UgKGku ZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3 aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2Vz IHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAu Ig0KVGhlIHJlcG9ydGluZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5n IHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rp bmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy4NCg0KW0xNXSBBZ3JlZS4g SW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0 IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3aGVuIHRoZSByZXBv cnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyIG1heSBk ZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVh c3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4NCg0KQXMgd2UgaGFkIGRpc2N1c3Nl ZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhw bGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1l IHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBu YXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBz aWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0Lg0KDQpbTE1dIEFncmVlDQoNClRoZXJlIG1heSBi ZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRo ZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFz dCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRo ZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi4NCg0KW0xNXSBBZ3JlZQ0KDQpSZXN0IG9mIHRo ZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuDQoNCltMTV0gQWdyZWUNCg0KUmVn YXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2llaGUs IFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0K U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE0NClRvOiBleHQgU3RldmUg RG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBY3R1 YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmluY2lwbGVzOg0KMS4gTGFjayBvZiBPTFIg bWVhbnMgIm5vIGNoYW5nZSINCjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRo ZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4g cmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0 dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFz IGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZm aWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIpOyBvdGhlcndp c2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1h dHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVz cG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy ZSBBVlAuDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uDQoNClVscmljaA0KDQpGcm9tOiBE aU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZl IERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0KVG86 IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVd IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQWdyZWVkLsKgIFRv IHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRo ZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS7CoCBJZiB0aGVy ZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVz IHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFu Z2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LsKgIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRs eSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQg aW1wbGllcyB0aGVyZSBpcyBubyBvdmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQpT dGV2ZQ0KT24gMi81LzE0IDk6MTkgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KSSBh Z3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIg YmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KwqANCldlIGhhZCBzb21lIGRpc2N1 c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8g bm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2Vy IG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hh dCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGlu ZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGlt cGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQg ZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3Lg0KwqANClNvIGJhc2ljYWxseSwgdGhlIGxhY2sg b2YgT0xSIHNob3VsZCBub3QgYWZmZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0 aGUgcmVhY3Rpbmcgbm9kZS4gVGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0 IGJhc2VkIG9uIG9sZGVyIE9MUiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJp b2Qgb3Igd2hlbiB0aGUgZXhwbGljaXQgT0xSIHdpdGggIjAiIG92ZXJsb2FkLW1ldHJpYyBpcyBy ZWNlaXZlZC4NCkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRh dGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0 aGUgcmVhY3Rpbmcgbm9kZS4NCsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KRnJvbTogRGlNRSBb bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4N ClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODowMCBQTQ0KVG86IGRpbWVAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg dGhyb3R0bGluZw0KwqANCmlubGluZQ0KT24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2gg KE5TTiAtIERFL011bmljaCkgd3JvdGU6DQpPayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0 aW5nIG5vZGVzIE1VU1QgaW5zZXJ0IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdl cyB0aGF0IGNvcnJlc3BvbmQgdG8gcmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9D LVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyBy ZXF1ZXN0ZWQpLg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0 IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCsKg DQrCoA0KT3RoZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBt YXR0ZXIuDQpTUkQ+IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2Vy IGRvZXMgZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBu b2RlIHRvIGxvb2sgZm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVy eSBtZXNzYWdlIGlzIGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxs eSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLg0KDQoNCsKgDQrCoA0KRm9yIG15 IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVx dWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUg cmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0 aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJz IGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9M Uj8NClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoN CsKgDQrCoA0KwqANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWls dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChu c2Fsb3QpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBs aW9uZWwubW9yYW5kQG9yYW5nZS5jb207IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGlt ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkgc2hhcmUg dGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuDQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n DQrCoA0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBv cnRpbmcgbm9kZSBET0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28g dGhlIG9wdGlvbnMgd291bGQgYmU6DQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0g T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIg QVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQg YnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KwqANCklmIHRoZXJlIGlzIG5vIG90 aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KwqAN Ckxpb25lbA0KwqANCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1 ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOp wqA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo0OQ0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQv T0xODQpDY8KgOiBkaW1lQGlldGYub3JnDQpPYmpldMKgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9D LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy dml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n DQrCoA0KIEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90 dGxpbmctSW5mbyBBVlAgdGhhdCBpc8KgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBE T0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdMKgIHN1cnZpdmVkIGEgdGhyb3R0 bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KIChUaW1l U3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGlj aCB3YXMNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGlj YXRlcyB0aGF0IGN1cnJlbnRseSBub8KgIHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLsKgIFJlcG9y dGluZyBET0lDIGVuZHBvaW50cyBtYXkgdXNlIHRoaXPCoCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0 byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZcKgIHJlYWN0aW5n IERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMgZmVl ZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlwqAgcmVwb3J0 aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9y dGluZyBET0lDwqAgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9J QyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZ8KgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2Fy ZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20g aW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5k cG9pbnQgdG8gZGV0ZWN0IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0 aGUgcmVhY3RpbmfCoCBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4N CiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZy b20gUkZDIDcwNjguDQogSW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9D LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0b8KgIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNz YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4NCsKgDQrCoA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRp TUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRp TUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K From maria.cruz.bartolome@ericsson.com Mon Feb 10 01:35:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD11A06A9 for ; Mon, 10 Feb 2014 01:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geN_8w0XS8FS for ; Mon, 10 Feb 2014 01:35:50 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5211A06AA for ; Mon, 10 Feb 2014 01:35:49 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-48-52f89d74fa02 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 53.99.23809.47D98F25; Mon, 10 Feb 2014 10:35:48 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 10:35:48 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyh3Mk+g2dTxBkStndl7a0rG2ZqoSuqAgAAqeQCAANvNAIAABVqAgAABgQCAAC0EgIAACU8AgAShATCAABESgA== Date: Mon, 10 Feb 2014 09:35:47 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92097726DC@ESESSMB101.ericsson.se> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW7J3B9BBg/mG1vM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ/LOpkKVhZXfFo8nb2BsTm2i5GTQ0LAROLmyTNsELaYxIV7 64FsLg4hgUOMEk9PLGeEcJYwSlx52sIEUsUmYCdx6fQLIJuDQ0RAWeL0LweQsLCAhcS3nW9Y IMKWEqdfBIOERQSyJNatessCYrMIqEpcfHiNGcTmFfCV+DL3BdT4i6wSyz8+YQPp5RSIlbhw Xg6khhHonu+n1oBtZRYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwphK0ms2H6JEaJeT+LG1Cls ELa2xLKFr6H2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGNlzEzNz0suNNjECg/7glt+q OxjvnBM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbsqA0WbRezpsnb HTu2V6Ew95vXu8Xet0qv2N2fsDQ9cKp072ubwOzO5Vrv5qgv1FXPPs40vTn1IVfbF3eTm3b8 6uK+VUGbmmb9YPi2T+eXC+eHG3O/XzRnV1tk/ZD7jKkHs1i6NfNJhtV7reWTmGL1ntkav+Lw Deq9H1Q18f6TBh2Z+5Vpf5VYijMSDbWYi4oTAVvaEOpIAgAA Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:35:54 -0000 Hello Jean-Jacques, et all, I share your interpretation. But, do you find this is still misleading in proposed text? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: lunes, 10 de febrero de 2014 9:59 To: dime@ietf.org Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi all I agree to enhance the wording so by starting from the new Lionel's wordin= g. My comment is that we have to clearly distinguish the "validity duration" = given by the OC-Validity-Duration AVP (eg 10 s) from the "validity time" (= absolute value) at the end of which the received OLR is no more applicable= . - If the reacting node receives a new sequence number at T1 and a validity = duration of 10s, this will determine a validity time eg of T1+ 10s where th= e received OLR is applicable. - If later at T2, it receives another OLR with the Same sequence number, t= he validity time remains unchanged at T1+10s (as stated in Lionel's propos= al), this allows to ignore the OLRs with the same sequence number. - If at T3, the reacting node receives another OLR with a new sequence num= ber and with the same value, 10 s, (or a new value, eg 15s) for validity d= uration, the validity time becomes T3+10s (or T3+15s). So we can have sit= uations where the sequence number is changed but the other content of OC-OL= R AVP (reduction%, validity duration) itself has not changed: the effect is= only to shift the validity time in the reacting node. Do you share all this understanding?=20 So in the description, to be careful between validity duration and validity= time that may confuse. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Env= oy=E9=A0: vendredi 7 f=E9vrier 2014 11:53 =C0=A0: lionel.morand@orange.com = Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration = AVP OK by me. - JOuni On Feb 7, 2014, at 12:19 PM, wrote: > Hi Maria Cruz, >=20 > I'm fine with the proposed clarification. > My point is that some parts belong to the handling of the OLR itself and = some other to the definition of the Validity duration. >=20 > Here is a proposal for clarification. Let me know if it covers your conce= rn. >=20 > Regards, >=20 > Lionel >=20 > ******************* >=20 > 4.3. OC-OLR AVP >=20 > [skip] >=20 > The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP. > It is possible to replay the same OC-OLR AVP multiple times between > the overload control endpoints, however, when the OC-OLR AVP content > changes or sending endpoint otherwise wants the receiving endpoint to > update its overload control information, then the OC-Sequence-Number > AVP MUST contain a new greater value than the previously received. > The receiver SHOULD discard an OC-OLR AVP with a sequence number that > is less than previously received one. >=20 > [New] >=20 > The OC-Validity-Duration AVP indicates the validity time of the overloa= d > report associated with a specific sequence number, measured after recep= tion > of the OC-OLR AVP. The validity time MUST NOT be updated after receptio= n=20 > of subsequent OC-OLR AVPs with the same sequence number. The default va= lue > for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When th= e=20 > OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default = value > applies. >=20 > [Skip] >=20 > 4.5. OC-Validity-Duration AVP >=20 > OLD: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 >=20 > NEW: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and indicates in seconds the validity time of the overload report. > The number of seconds is measured after reception of the first=20 > OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20 > The default value for the OC-Validity-Duration AVP is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values = 0 > (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used. > When invalid values are used, the default value for the OC-Validity-Dur= ation > AVP applies. >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20 > Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 08:38 =C0 : dime@ietf.org= =20 > Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hello Lionel, all, >=20 > I would like to clarify what "new and fresh", or even only "new" OC-OLR = AVP mean in the text. > It should be understood that it does not refer to the new (latest) receiv= ed AVP, but just the one that contains (potentially) new values, what only = happens for a new Sequence Number. In that line is the proposed text I prov= ided. >=20 > Best regards > /MCruz >=20 > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: viernes, 07 de febrero de 2014 8:33 > To: dime@ietf.org; Maria Cruz Bartolome > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi, >=20 > My point is just to say that we should make the difference between the de= finition and the use of the AVP. >=20 > And about the clarification, I would say that it is rather about how to p= opulate the OC-OLR AVP or when a new sequence number should be used. >=20 > Regards, >=20 > Lionel >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > Maria Cruz Bartolome a =E9crit : >=20 >=20 > Thanks Lionel, > The comment equally applies in order to clarify when the Validity-Duratio= n should include a new value. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 > lionel.morand@orange.com > Sent: jueves, 06 de febrero de 2014 19:07 > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi Maria Cruz, >=20 > Hi Maria Cruz, Steve, >=20 > Be careful! The reference you are using seems to be odd. >=20 > The current text in the draft says: >=20 > 4.5. OC-Validity-Duration AVP >=20 >=20 > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 > A timeout of the overload report has specific concerns that need to > be taken into account by the endpoint acting on the earlier received > overload report(s). Section 4.7 discusses the impacts of timeout in > the scope of the traffic abatement algorithms. >=20 > As a general guidance for implementations it is RECOMMENDED never to > let any overload report to timeout. Following to this rule, an > overload endpoint should explicitly signal the end of overload > condition and not rely on the expiration of the validity time of the > overload report in the reacting node. This leaves no need for the > reacting node to reason or guess the overload condition of the > reporting node. >=20 > I think that the definition of the OC-Validity-Duration AVP should remain= independent of the notion of Sequence-Number. > The sequence number does not change the value of the OC-Validity-Duration= AVP. It indicates that the OLR has to be updated or not. And if it is, a n= ew duration will be there (either implicit or explicit with the OC-Validity= -Duration AVP). >=20 > So if something needs to be clarified (I haven't checked), it should be i= n the handling of the OLR. >=20 > Regards, >=20 > Lionel >=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20 > Envoy=E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: > [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > This change looks pretty straight forward to me. I'll add it to the -02 = version of the draft unless I hear objections soon. >=20 > Steve > On 2/6/14 4:44 AM, dime issue tracker wrote: > #36: OC-Validity-Duration AVP >=20 > In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when= the OC-Validity-Duration AVP needs to be updated is ambiguous. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid since the reception of the new OC-OLR AVP (as indicated by the > OC-Sequence-Number AVP). >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 nsalot@cisco.com Mon Feb 10 01:41:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56921A07CF for ; Mon, 10 Feb 2014 01:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAymbpfG1fZR for ; Mon, 10 Feb 2014 01:41:39 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 82C141A07CC for ; Mon, 10 Feb 2014 01:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25482; q=dns/txt; s=iport; t=1392025298; x=1393234898; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sBbjSWFePakg8FpkANgnTs3W0sstBVvHikVTNrIKxc0=; b=U1SLHZ9/lRq+5SAVpE6rT+GLkfbxMgB+DMZ505kp5vBiJN9x9GM4PqGI Xj5I6IX3/t8nvJSieCwSIYocqqNmjkqZx1uFKNYW3apzcdyskXcQ6gmym OObfiTUclHo/cszmFv30ASEA/PrQn/EMOxgUe/96CaOf7Av0SCpxCUm1w Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAIOe+FKtJV2b/2dsb2JhbABZgww4V4MBvEoYdhZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGCw4EAwICAiULFAEICAIEARIIE4dqDagVoE4TBIEpjHIRAR8WIgYEgmU1gRQElEKORodEgW+BPoFoBwIXIg X-IronPort-AV: E=Sophos;i="4.95,816,1384300800"; d="scan'208";a="19201981" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 10 Feb 2014 09:41:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1A9fb82009558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 09:41:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 03:41:37 -0600 From: "Nirav Salot (nsalot)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwA== Date: Mon, 10 Feb 2014 09:41:37 +0000 Message-ID: References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.45.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:41:43 -0000 QnV0IE1hcmlhLUNydXosDQoNCkhvdyBjYW4gd2Ugc2F5IHRoYXQgImluY2x1ZGluZyB0aGUgT0xS IGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZmaWNpZW50PyINCkl0 IGlzIHNpbXBsZSBmb3Igc3VyZSBidXQgbm90IGVmZmljaWVudC4gDQoNCkEgc2xpZ2h0bHkgZGlm ZmVyZW50IHdvcmRpbmcgZnJvbSB3aGF0IEkgcHJvcG9zZWQgZWFybGllciBpcywNCldoZW4gdGhl IHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQgdGhhdCBuZWVkcyB0byBi ZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5nIHRoZSBlYXJsaWVyIHBy b3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhlIG92ZXJsb2FkIHJlcG9y dCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9u c2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0 b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwgaW4g b3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlm IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcg bm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3Bv bnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4N Cg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENy dXogQmFydG9sb21lDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDM6MDMgUE0NClRv OiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz dXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsIGFsbCwNCg0KSSB0aGluayB3ZSBzaG91bGQg ZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVudCBhbmQg c2ltcGxlIGFzIHBvc3NpYmxlLg0KSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwgYXMgYSBwdXJl ICJtYXkiLCBidXQgbGVhdmluZyBpdCB1cCB0byBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBhc3N1 cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQgT0xSIGluZm9ybWF0aW9uLCB3aGF0IGlzIGJhc2lj IGZvciB0aGlzIG1lY2hhbmlzbSB0byB3b3JrLiANCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFtt YWlsdG86bnNhbG90QGNpc2NvLmNvbV0gDQpTZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAy MDE0IDEwOjEyDQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K DQpNYXJpYS1DcnV6LA0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91IG9uICJzZW5kaW5nIE9MUiBp biBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlcyIuDQpBbmQgd2UgYXJl IG5vdCB0cnlpbmcgdG8gcHJldmVudCBpdCAtIGF0IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9u LiANCkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFu eSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5k IGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNz YWdlPw0KDQpNb3N0IHByb2JhYmx5LCB0aGUgdmVyeSBmaXJzdCBpbXBsZW1lbnRhdGlvbiBvZiBv dmVybG9hZCBjb250cm9sIHdpbGwgaW5jbHVkZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2Fn ZXMuDQpCdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUg ZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRy aWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3Nh Z2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0 dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLiANCldoYXQgZG8g eW91IHRoaW5rPw0KDQpUaGlzIGFsc28gdGhlIHJlYXNvbiBJIHdhcyBzdWdnZXN0aW5nIGxvb3Nl IGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVkZSBPTFIgKGZyb20gdGhlIHJlcG9ydGluZyBu b2RlIHBvaW50IG9mIHZpZXcpLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IEZyaWRheSwgRmVicnVhcnkg MDcsIDIwMTQgODo1NyBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0g W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpIZWxsbyBVbHJpY2gs IE5pcmF2LA0KDQpJIGFncmVlIHdpdGggVWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkg TmlyYXYgaXMganVzdCBhIE1BWSwgYW5kIHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMg YW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNoYWxsIG5vdCBiZSBqdXN0IGEgTUFZLg0KDQpPbiB0aGUg b3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0 byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdlOg0KYSkgdGhl IHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkg Z290IHRoZSBsYXRlc3QgT0xSDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2Fk ZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSBy ZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KYykgb3Ro ZXJ3aXNlDQoNClJlcG9ydGluZyBub2RlIG11c3QgaGF2ZSBzb21lIGtub3dsZWRnZSBhYm91dCBP TFIgcmVjZXB0aW9uL3N0YXR1cyBpbiByZWFjdGluZyBub2RlLiBIb3cgZG9lcyBzZXJ2ZXIgYWNx dWlyZSB0aGlzIGtub3dsZWRnZT8gDQpUYWtlIGludG8gYWNjb3VudCBhcyB3ZWxsIHRoYXQgYSAi cmVhY3RpbmciIG5vZGUgbWF5IGJlIGJvdGggYW4gQWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMg c2VydmljZSB0byBhIHJlYWxtIG9yIGFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGlu ZyBjbGllbnQpICBhbmQgYSBDbGllbnQuIEluIHRoZSBjYXNlIG9mIEFnZW50cywgaW4gZmFjdCB0 aGUgU2VydmVyIG1heSBub3QgZXZlbiBrbm93IGlmIHRoaXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEg cmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRyYW5zcGFyZW50bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIg ZG9lcyBub3QgbmVlZCB0byBoYXZlIGFueSBrbm93bGVkZ2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4g dGhlIGNoYWluIHRvIHRoZSBmaW5hbCBDbGllbnQuDQoNClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5 IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50 IGFkdmFudGFnZXM6DQotCXN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9uIG9y IHNlc3Npb24pIGlzIHNpbXBsZXIsDQotCXRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRl cm1pbmUgd2hldGhlciBvciBub3QgdG8gc2VuZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGUNCi0J dGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5v ZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3Rp bGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuDQotCXNlbmRpbmcgYW4gYWRkaXRpb25hbCBBVlAg aXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29uIHdpdGggcmVxdWlyZWQg YWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gDQoJSW4gZmFjdCwgaW4gYW4gb3Zl cmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxleCBpcyB0byBzZW5k IGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBub2RlcywgDQoJYW5k IHRoZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMg IA0KLQltb3JlIHJvYnVzdCBzb2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRo ZSBjaGVja3Mgb24gdGhlIG5lZWQgdG8gc2VuZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1YXRpb25z IHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlzIGxvc3QsICDigKYNCg0KDQpCZXN0IHJlZ2FyZHMN Ci9NQ3J1eg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRv OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpZWhlLCBVbHJpY2ggKE5TTiAt IERFL011bmljaCkNClNlbnQ6IHZpZXJuZXMsIDA3IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo1OQ0K VG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNv bTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0g W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpOaXJhdiwNCg0KSSdt IGFmcmFpZCB5b3VyIHByb3Bvc2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGUgaW50ZW50aW9u Lg0KDQoid2hlbiBpdCB3YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRl Li4uIiB0cmFuc2xhdGVzIHRvICIuLi5pdCBtYXkgaW5jbHVkZS4uLiIuDQoNCiJpbiBvdGhlciBj YXNlcyIgaW4gdGhlIGdpdmVuIGNvbnRleHQgdHJhbnNsYXRlcyB0byAid2hlbiBpdCBkb2VzIG5v dCB3YW50IHRvIHByb3ZpZGUvdXBkYXRlLi4uIg0KDQoNCldlIGhhdmUgdGhlIGZvbGxvd2luZyBj YXNlczoNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2Rl IGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlz IG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25v d3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBl eHBpcmUNCmMpIG90aGVyd2lzZQ0KDQppbiBjYXNlIGEpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkg b3IgbWF5IG5vdCByZXBsYXkgdGhlIE9MUiBpbiBjYXNlIGIpIHRoZSByZXBvcnRpbmcgbm9kZSBt YXkgb3IgbWF5IG5vdCB1cGRkYXRlIHRoZSByZWFjdGluZyBub2RlIHdpdGggdGhlIGxhdGVzdCBP TFIgaW4gY2FzZSBjKSB0aGUgcmVwb3J0aW5nIG5vZGUgTVVTVCBpbmNsdWRlIHRoZSBPTFIgaW4g dGhlIGFuc3dlciAodGhlIHJlcG9ydGluZyBub2RlIGRvZXMgbm90IGtub3cgd2hldGhlciB0aGlz IGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0ZSkNCg0KVWxyaWNoDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxv dEBjaXNjby5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgNDo0OSBQTQ0K VG86IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBsaW9uZWwubW9yYW5kQG9y YW5nZS5jb207IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KVWxyaWNo LA0KDQpJdCBzZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUgcGFnZSBidXQgcHJvYmFibHkgdGhlIHBy b3Bvc2VkIHdvcmRpbmcgYmVsb3cgaXMgbm90IHRoZSBiZXN0Lg0KSG93IGFib3V0IHRoZSBmb2xs b3dpbmcuDQoNCldoZW4gdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUgbmV3IG92 ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3Zl cmxvYWQgcmVwb3J0IHRvd2FyZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNsdWRlIE9M UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk LUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFk ZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg aXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0 byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBP TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl ZC1GZWF0dXJlIEFWUC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVs cmljaC53aWVoZUBuc24uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDM6 NTcgUE0NClRvOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBOaXJhdiBTYWxvdCAobnNh bG90KTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGlt ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpOaXJhdiwgTGlv bmVsLA0KDQpJIGNhbiB1bmRlcnN0YW5kIE5pcmF2J3MgY29uY2VybiAoYWx0aG91Z2ggdmlvbGF0 aW5nIFJFUTEwKSBhbmQgaG9wIGl0IGlzIGFkZHJlc3NlZCBieSB0aGUgbW9kaWZpZWQgcHJpbmNp cGxlIDInOg0KDQoyJy4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVy bG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25z ZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQ IGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJl YXNvbmFibGUgb3ZlcmxvYWQgY29udHJvbCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9M Uiwgd2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFu IE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24gZXhwaXJp bmcgT0xSIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3 aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBt YXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJl c3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1 cmUgQVZQLg0KDQpJIGRvbid0IGFncmVlIHdpdGggTGlvbmVscyBkby13aGF0LXlvdS13YW50IGFw cHJvYWNoLiBPdmVybG9hZCBjb250cm9sIHdpbGwgbm90IHdvcmsgd2hlbiB3ZSBhbGxvdyB0aGUg cmVwb3J0aW5nIG5vZGUgbm90IHRvIHVwZGF0ZSByZWFjdGluZyBub2Rlcywgd2hpY2ggYXJlIG5v dCAoc3VmZmljaWFudGx5KSBhd2FyZSBvZiB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0dXMsIHdp dGggdXAgdG8gZGF0ZSBPTFJzLg0KDQpVbHJpY2ggIA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20gW21haWx0bzpsaW9u ZWwubW9yYW5kQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQg MTA6MjAgQU0NClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgV2llaGUsIFVscmljaCAoTlNOIC0g REUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0K LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95w6nC oDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4IMOAwqA6IFdpZWhlLCBVbHJpY2ggKE5TTiAt IERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnIE9iamV0wqA6IFJl OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpVbHJp Y2gsDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgZm9yY2luZyB0aGlzIGJlaGF2aW9yIG9uIHJlcG9y dGluZyBub2RlICJvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVw b3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJl dHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBP Qy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KVGhlIHJlcG9ydGluZyBub2RlIG1heSBzaW1wbHkg bm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xSIHdp bGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0aGUg dHJhZmZpYy4NCg0KW0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQg cmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFm dC4gSG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhl IE9MUiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRo ZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGlu Zy4NCg0KQXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0 aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCBy ZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0 aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2ls aXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0Lg0KDQpb TE1dIEFncmVlDQoNClRoZXJlIG1heSBiZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBv cnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBs b25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5j bHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi4NCg0K W0xNXSBBZ3JlZQ0KDQpSZXN0IG9mIHRoZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGgg bWUuDQoNCltMTV0gQWdyZWUNCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRv OnVscmljaC53aWVoZUBuc24uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0 IDI6MjMgUE0NClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRp bWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp dmVkIGEgdGhyb3R0bGluZw0KDQpBY3R1YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmlu Y2lwbGVzOg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSINCjIuIHRoZSByZXBvcnRp bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUg bm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFp bmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSBy ZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJl IGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5n ICJubyBvdmVybG9hZCIpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0 aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBN VVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5l ZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZp cm0uDQoNClVscmljaA0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMDUsIDIwMTQgNDozNSBQTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo cm90dGxpbmcNCg0KQWdyZWVkLsKgIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9hZCBy ZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUg aG9zdCBvciByZWFsbS7CoCBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQg cmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBv dXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LsKg IElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gbGFj ayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVyZSBpcyBubyBvdmVybG9hZCBmb3Ig dGhlIGhvc3QgYW5kIHJlYWxtLg0KDQpTdGV2ZQ0KT24gMi81LzE0IDk6MTkgQU0sIE5pcmF2IFNh bG90IChuc2Fsb3QpIHdyb3RlOg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAi c2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/ Ig0KwqANCldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0 aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRl IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlz IGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVu Y2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQu IEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1l IG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3Lg0KwqAN ClNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3VsZCBub3QgYWZmZWN0IHRoZSBwcmV2 aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4gVGhlIHJlYWN0aW5nIG5v ZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVyIE9MUiB1bnRpbCB0aGUgZXhw aXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUgZXhwbGljaXQgT0xSIHdpdGgg IjAiIG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZlZC4NCkluIG15IHZpZXcsIHRoaXMgYWxsb3dz IGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNv dW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4NCsKgDQpSZWdhcmRzLA0K TmlyYXYuDQrCoA0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIw MTQgODowMCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVd ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCmlubGluZQ0KT24gMi81LzE0 IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6DQpPayB0aGVu IGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1VU1QgaW5zZXJ0IGFuIE9DLU9MUiBB VlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJlc3BvbmQgdG8gcmVxdWVzdCBtZXNz YWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgKGV2ZW4gd2hl biBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5z d2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFz IG5vdCBvdmVybG9hZGVkPw0KDQoNCsKgDQrCoA0KT3RoZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBv ciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQpTUkQ+IFJlcXVpcmluZyBhbiBvdmVybG9h ZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1dCBy ZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sgZm9yIGFuIE9DLU9uZ29pbmctVGhy b3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlzIGFsc28gc3Vic3RhbnRpYWwgYWRk aXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGluc2VydGluZyBP TFJzLg0KDQoNCsKgDQrCoA0KRm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUg cmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xS IHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRo ZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJv Y2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRo ZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0 aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoNCsKgDQrCoA0KwqANCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IGRpbWVAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg dGhyb3R0bGluZw0KwqANCkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuDQrCoA0K UmVnYXJkcywNCk5pcmF2Lg0KwqANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBE aU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1v cmFuZEBvcmFuZ2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBN DQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlYWwg Y29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VTIE5PVCBpbnNlcnQgdGhlIE9M UiBpbiBldmVyeSBhbnN3ZXIuIA0KU28gdGhlIG9wdGlvbnMgd291bGQgYmU6DQoxLSBPQy1PTFIg QVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu IGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJl bnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVk Lg0KwqANCklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1z IHRoZSBiZXN0IGFwcHJvYWNoLg0KwqANCkxpb25lbA0KwqANCi0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1lQHRyYWMu dG9vbHMuaWV0Zi5vcmddDQpFbnZvecOpwqA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo0OQ0K w4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBkaW1lQGlldGYub3JnDQpPYmpldMKg OiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIzMxOiBTZW5k aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRl ZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdGhhdCBpc8KgIHRvIGJlIGlu Y2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMg dGhhdMKgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhl IFNlcXVlbmNlLU51bWJlcg0KIChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdo aWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXMNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBB YnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBub8KgIHRocm90dGxp bmcgaXMgcGVyZm9ybWVkLsKgIFJlcG9ydGluZyBET0lDIGVuZHBvaW50cyBtYXkgdXNlIHRoaXPC oCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQg dG8gdXBkYXRlIHRoZcKgIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0IE9M Ui4NCiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0 aGUgbmVlZCBmb3IgdGhlwqAgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBl dmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9pbnQgY2Fubm90IGtub3cg d2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZ8KgIHRo ZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLg0K IFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3Mg dGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9pbnQgdG8gZGV0ZWN0IGFuZCBjb3JyZWN0IGluYXBw cm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmfCoCBET0lDIGVuZHBvaW50IChjYXVz ZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4NCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxs b3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQogSW4gc3VtbWFyeSBpdCBpcyBw cm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0b8Kg IGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4N CsKgDQrCoA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxp bmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaW1lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg== From lionel.morand@orange.com Mon Feb 10 01:42:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A691A07D5 for ; Mon, 10 Feb 2014 01:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wf50z_r0DWj for ; Mon, 10 Feb 2014 01:41:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9901A07D7 for ; Mon, 10 Feb 2014 01:41:52 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 24EE618C228; Mon, 10 Feb 2014 10:41:52 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 056E9238078; Mon, 10 Feb 2014 10:41:52 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 10:41:51 +0100 From: To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyiVRUleRbeSh0iImOK3F7m+mZqoSuqAgAAqeQCAANvNAIAABVqAgAABgQCAAC0EgIAACU8AgAShATCAAACAgIAAER6Q Date: Mon, 10 Feb 2014 09:41:51 +0000 Message-ID: <14276_1392025312_52F89EE0_14276_5794_1_6B7134B31289DC4FAF731D844122B36E496D10@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> <087A34937E64E74E848732CFF8354B92097726DC@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92097726DC@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.83914 Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:42:00 -0000 Hi JJ, Just on the definition of "time".... It could be a period/moment and not on= ly a absolute time. Validity time can be used for both and it is why it is important each time = to clarify its meaning. For the rest, I think that the proposed text is clear enough to avoid ambig= uity. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: lundi 10 f=E9vrier 2014 10:36 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hello Jean-Jacques, et all, I share your interpretation. But, do you find this is still misleading in proposed text? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: lunes, 10 de febrero de 2014 9:59 To: dime@ietf.org Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi all I agree to enhance the wording so by starting from the new Lionel's wordin= g. My comment is that we have to clearly distinguish the "validity duration" = given by the OC-Validity-Duration AVP (eg 10 s) from the "validity time" (= absolute value) at the end of which the received OLR is no more applicable. - If the reacting node receives a new sequence number at T1 and a validity = duration of 10s, this will determine a validity time eg of T1+ 10s where th= e received OLR is applicable. - If later at T2, it receives another OLR with the Same sequence number, t= he validity time remains unchanged at T1+10s (as stated in Lionel's propos= al), this allows to ignore the OLRs with the same sequence number. - If at T3, the reacting node receives another OLR with a new sequence num= ber and with the same value, 10 s, (or a new value, eg 15s) for validity d= uration, the validity time becomes T3+10s (or T3+15s). So we can have sit= uations where the sequence number is changed but the other content of OC-OL= R AVP (reduction%, validity duration) itself has not changed: the effect is= only to shift the validity time in the reacting node. Do you share all this understanding?=20 So in the description, to be careful between validity duration and validity= time that may confuse. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Env= oy=E9=A0: vendredi 7 f=E9vrier 2014 11:53 =C0=A0: lionel.morand@orange.com = Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration = AVP OK by me. - JOuni On Feb 7, 2014, at 12:19 PM, wrote: > Hi Maria Cruz, >=20 > I'm fine with the proposed clarification. > My point is that some parts belong to the handling of the OLR itself and = some other to the definition of the Validity duration. >=20 > Here is a proposal for clarification. Let me know if it covers your conce= rn. >=20 > Regards, >=20 > Lionel >=20 > ******************* >=20 > 4.3. OC-OLR AVP >=20 > [skip] >=20 > The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP. > It is possible to replay the same OC-OLR AVP multiple times between > the overload control endpoints, however, when the OC-OLR AVP content > changes or sending endpoint otherwise wants the receiving endpoint to > update its overload control information, then the OC-Sequence-Number > AVP MUST contain a new greater value than the previously received. > The receiver SHOULD discard an OC-OLR AVP with a sequence number that > is less than previously received one. >=20 > [New] >=20 > The OC-Validity-Duration AVP indicates the validity time of the overload > report associated with a specific sequence number, measured after recep= tion > of the OC-OLR AVP. The validity time MUST NOT be updated after receptio= n=20 > of subsequent OC-OLR AVPs with the same sequence number. The default va= lue > for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When th= e=20 > OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default = value > applies. >=20 > [Skip] >=20 > 4.5. OC-Validity-Duration AVP >=20 > OLD: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 >=20 > NEW: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and indicates in seconds the validity time of the overload report. > The number of seconds is measured after reception of the first=20 > OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20 > The default value for the OC-Validity-Duration AVP is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values 0 > (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used. > When invalid values are used, the default value for the OC-Validity-Dur= ation > AVP applies. >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20 > Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 08:38 =C0 : dime@ietf.org= =20 > Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hello Lionel, all, >=20 > I would like to clarify what "new and fresh", or even only "new" OC-OLR = AVP mean in the text. > It should be understood that it does not refer to the new (latest) receiv= ed AVP, but just the one that contains (potentially) new values, what only = happens for a new Sequence Number. In that line is the proposed text I prov= ided. >=20 > Best regards > /MCruz >=20 > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: viernes, 07 de febrero de 2014 8:33 > To: dime@ietf.org; Maria Cruz Bartolome > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi, >=20 > My point is just to say that we should make the difference between the de= finition and the use of the AVP. >=20 > And about the clarification, I would say that it is rather about how to p= opulate the OC-OLR AVP or when a new sequence number should be used. >=20 > Regards, >=20 > Lionel >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > Maria Cruz Bartolome a =E9crit : >=20 >=20 > Thanks Lionel, > The comment equally applies in order to clarify when the Validity-Duratio= n should include a new value. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 > lionel.morand@orange.com > Sent: jueves, 06 de febrero de 2014 19:07 > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi Maria Cruz, >=20 > Hi Maria Cruz, Steve, >=20 > Be careful! The reference you are using seems to be odd. >=20 > The current text in the draft says: >=20 > 4.5. OC-Validity-Duration AVP >=20 >=20 > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 > A timeout of the overload report has specific concerns that need to > be taken into account by the endpoint acting on the earlier received > overload report(s). Section 4.7 discusses the impacts of timeout in > the scope of the traffic abatement algorithms. >=20 > As a general guidance for implementations it is RECOMMENDED never to > let any overload report to timeout. Following to this rule, an > overload endpoint should explicitly signal the end of overload > condition and not rely on the expiration of the validity time of the > overload report in the reacting node. This leaves no need for the > reacting node to reason or guess the overload condition of the > reporting node. >=20 > I think that the definition of the OC-Validity-Duration AVP should remain= independent of the notion of Sequence-Number. > The sequence number does not change the value of the OC-Validity-Duration= AVP. It indicates that the OLR has to be updated or not. And if it is, a n= ew duration will be there (either implicit or explicit with the OC-Validity= -Duration AVP). >=20 > So if something needs to be clarified (I haven't checked), it should be i= n the handling of the OLR. >=20 > Regards, >=20 > Lionel >=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20 > Envoy=E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: > [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > This change looks pretty straight forward to me. I'll add it to the -02 = version of the draft unless I hear objections soon. >=20 > Steve > On 2/6/14 4:44 AM, dime issue tracker wrote: > #36: OC-Validity-Duration AVP >=20 > In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when= the OC-Validity-Duration AVP needs to be updated is ambiguous. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid since the reception of the new OC-OLR AVP (as indicated by the > OC-Sequence-Number AVP). >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jean-jacques.trottin@alcatel-lucent.com Mon Feb 10 01:46:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086DB1A07CC for ; Mon, 10 Feb 2014 01:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as4nx7CfwuHS for ; Mon, 10 Feb 2014 01:46:09 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFA41A07D3 for ; Mon, 10 Feb 2014 01:46:07 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1A9k3r1008963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 03:46:04 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1A9k2sU002978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 10:46:02 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 10:46:02 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP Thread-Index: AQHPIyiVRUleRbeSh0iImOK3F7m+mZqoSuqAgAAqeQCAANvNAIAABVqAgAABgQCAAC0EgIAACU8AgAShATCAAACAgIAAERww Date: Mon, 10 Feb 2014 09:46:01 +0000 Message-ID: References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> <087A34937E64E74E848732CFF8354B92097726DC@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92097726DC@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:46:13 -0000 Hi MCruz I have not yet thought to some wording enhancement, I wanted first to check= is we have the same understanding. I have noted in the proposal: "The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and ind= icates in seconds the validity time of the overload report" So I would prefer to use "validity duration", as the OC-Validity-Duration A= VP indicates a duration, not a time. But elsewhere, what is important is th= e update of the validity time when a new sequence number.=20 Best regards JJacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: lundi 10 f=E9vrier 2014 10:36 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hello Jean-Jacques, et all, I share your interpretation. But, do you find this is still misleading in proposed text? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: lunes, 10 de febrero de 2014 9:59 To: dime@ietf.org Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP Hi all I agree to enhance the wording so by starting from the new Lionel's wordin= g. My comment is that we have to clearly distinguish the "validity duration" = given by the OC-Validity-Duration AVP (eg 10 s) from the "validity time" (= absolute value) at the end of which the received OLR is no more applicable= . - If the reacting node receives a new sequence number at T1 and a validity = duration of 10s, this will determine a validity time eg of T1+ 10s where th= e received OLR is applicable. - If later at T2, it receives another OLR with the Same sequence number, t= he validity time remains unchanged at T1+10s (as stated in Lionel's propos= al), this allows to ignore the OLRs with the same sequence number. - If at T3, the reacting node receives another OLR with a new sequence num= ber and with the same value, 10 s, (or a new value, eg 15s) for validity d= uration, the validity time becomes T3+10s (or T3+15s). So we can have sit= uations where the sequence number is changed but the other content of OC-OL= R AVP (reduction%, validity duration) itself has not changed: the effect is= only to shift the validity time in the reacting node. Do you share all this understanding?=20 So in the description, to be careful between validity duration and validity= time that may confuse. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Env= oy=E9=A0: vendredi 7 f=E9vrier 2014 11:53 =C0=A0: lionel.morand@orange.com = Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration = AVP OK by me. - JOuni On Feb 7, 2014, at 12:19 PM, wrote: > Hi Maria Cruz, >=20 > I'm fine with the proposed clarification. > My point is that some parts belong to the handling of the OLR itself and = some other to the definition of the Validity duration. >=20 > Here is a proposal for clarification. Let me know if it covers your conce= rn. >=20 > Regards, >=20 > Lionel >=20 > ******************* >=20 > 4.3. OC-OLR AVP >=20 > [skip] >=20 > The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP. > It is possible to replay the same OC-OLR AVP multiple times between > the overload control endpoints, however, when the OC-OLR AVP content > changes or sending endpoint otherwise wants the receiving endpoint to > update its overload control information, then the OC-Sequence-Number > AVP MUST contain a new greater value than the previously received. > The receiver SHOULD discard an OC-OLR AVP with a sequence number that > is less than previously received one. >=20 > [New] >=20 > The OC-Validity-Duration AVP indicates the validity time of the overloa= d > report associated with a specific sequence number, measured after recep= tion > of the OC-OLR AVP. The validity time MUST NOT be updated after receptio= n=20 > of subsequent OC-OLR AVPs with the same sequence number. The default va= lue > for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When th= e=20 > OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default = value > applies. >=20 > [Skip] >=20 > 4.5. OC-Validity-Duration AVP >=20 > OLD: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 >=20 > NEW: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and indicates in seconds the validity time of the overload report. > The number of seconds is measured after reception of the first=20 > OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20 > The default value for the OC-Validity-Duration AVP is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values = 0 > (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used. > When invalid values are used, the default value for the OC-Validity-Dur= ation > AVP applies. >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20 > Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 08:38 =C0 : dime@ietf.org= =20 > Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hello Lionel, all, >=20 > I would like to clarify what "new and fresh", or even only "new" OC-OLR = AVP mean in the text. > It should be understood that it does not refer to the new (latest) receiv= ed AVP, but just the one that contains (potentially) new values, what only = happens for a new Sequence Number. In that line is the proposed text I prov= ided. >=20 > Best regards > /MCruz >=20 > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: viernes, 07 de febrero de 2014 8:33 > To: dime@ietf.org; Maria Cruz Bartolome > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi, >=20 > My point is just to say that we should make the difference between the de= finition and the use of the AVP. >=20 > And about the clarification, I would say that it is rather about how to p= opulate the OC-OLR AVP or when a new sequence number should be used. >=20 > Regards, >=20 > Lionel >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > Maria Cruz Bartolome a =E9crit : >=20 >=20 > Thanks Lionel, > The comment equally applies in order to clarify when the Validity-Duratio= n should include a new value. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 > lionel.morand@orange.com > Sent: jueves, 06 de febrero de 2014 19:07 > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > Hi Maria Cruz, >=20 > Hi Maria Cruz, Steve, >=20 > Be careful! The reference you are using seems to be odd. >=20 > The current text in the draft says: >=20 > 4.5. OC-Validity-Duration AVP >=20 >=20 > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the "new and fresh" OC-OLR AVP > and its content is valid since the reception of the new OC-OLR AVP. > The default value for the OC-Validity-Duration AVP value is 5 (i.e., > 5 seconds). When the OC-Validity-Duration AVP is not present in the > OC-OLR AVP, the default value applies. Validity duration values 0 > (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. > Invalid validity duration values are treated as if the OC-Validity- > Duration AVP were not present. >=20 > A timeout of the overload report has specific concerns that need to > be taken into account by the endpoint acting on the earlier received > overload report(s). Section 4.7 discusses the impacts of timeout in > the scope of the traffic abatement algorithms. >=20 > As a general guidance for implementations it is RECOMMENDED never to > let any overload report to timeout. Following to this rule, an > overload endpoint should explicitly signal the end of overload > condition and not rely on the expiration of the validity time of the > overload report in the reacting node. This leaves no need for the > reacting node to reason or guess the overload condition of the > reporting node. >=20 > I think that the definition of the OC-Validity-Duration AVP should remain= independent of the notion of Sequence-Number. > The sequence number does not change the value of the OC-Validity-Duration= AVP. It indicates that the OLR has to be updated or not. And if it is, a n= ew duration will be there (either implicit or explicit with the OC-Validity= -Duration AVP). >=20 > So if something needs to be clarified (I haven't checked), it should be i= n the handling of the OLR. >=20 > Regards, >=20 > Lionel >=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20 > Envoy=E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re: > [Dime] [dime] #36: OC-Validity-Duration AVP >=20 > This change looks pretty straight forward to me. I'll add it to the -02 = version of the draft unless I hear objections soon. >=20 > Steve > On 2/6/14 4:44 AM, dime issue tracker wrote: > #36: OC-Validity-Duration AVP >=20 > In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when= the OC-Validity-Duration AVP needs to be updated is ambiguous. >=20 > Now: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid since the reception of the new OC-OLR AVP (as indicated by the > OC-Sequence-Number AVP). >=20 > Proposal: > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content is > valid in relation to the reception of the first OC-OLR AVP with a > specific sequence number. For a given sequence number, the > OC-Validity-Duration shall always carry the same value. >=20 >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 maria.cruz.bartolome@ericsson.com Mon Feb 10 01:53:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9FC1A06BA for ; Mon, 10 Feb 2014 01:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6YnP0ZkRd0r for ; Mon, 10 Feb 2014 01:52:59 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A76941A06B9 for ; Mon, 10 Feb 2014 01:52:58 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-da-52f8a179bf8e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D8.58.10875.971A8F25; Mon, 10 Feb 2014 10:52:58 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 10:52:57 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmAMkAgACifECAAAXaAIAADfeAgAAEaQCAASwPUP//+iEAgAADQgCAABZZ8IAAVmMAgAE5EdCAAF/ugIAEQVKAgAAVgXD///LUgIAAEWdQ Date: Mon, 10 Feb 2014 09:52:56 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvjW7Vwh9BBj1HOS3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxofG9WwFm24yVux69JilgfHFZcYuRk4OCQETidubJzJB2GIS F+6tZ+ti5OIQEjjEKLGsbxFYQkhgCaNE48ZKEJtNwE7i0ukXQHEODhEBZYnTvxxAwsIC5RIv L11hBrFFBCokPm+9xAQyR0RgGqPEkqPb2EASLAKqEq0HroEV8Qr4Stz8d4YFYtk2TomVjf/B lnECJe6sWwZmMwJd9P3UGjCbWUBc4taT+VCXCkgs2XOeGcIWlXj5+B8rhK0ksWL7JUaQ45gF NCXW79KHaFWUmNL9kB1ir6DEyZlPWCYwis5CMnUWQscsJB2zkHQsYGRZxciem5iZk15uuIkR GPgHt/zW3cF46pzIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBaz/E6 pNr4+l/+X8e8Tb9P9Zo97yvU2MbS5VOR+9f/XPR8L+v1c4w+HerYd4H9rv8bh3lcB5/FKKyZ JeO7Reqe2AWH3aWtR2ZsWvxibfEVS8a07WeSvil+nX54V692zWOdhCeTfrY8b7ApSb/8ac0m vQj+A7felr2XdesJr9l+wkPy5dScOP2vSizFGYmGWsxFxYkA8OQ5z0oCAAA= Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:53:04 -0000 SGVsbG8gTmlyYXYsDQoNCkFueSBzb2x1dGlvbiBzaG91bGQgYmFsYW5jZSBkaWZmZXJlbnQgZmFj dG9ycywgZWZmaWNpZW5jeSBjb3VsZCBiZSBkaXNjdXNzZWQgZnJvbSBkaWZmZXJlbnQgcGVyc3Bl Y3RpdmVzLCBidXQgZmlyc3Qgd2UgbmVlZCB0byBhc3N1cmUgdGhlIG1lY2hhbmlzbSB3ZSBhcmUg ZGVmaW5pbmcgaXMgcHJvdmlkaW5nIHZhbGlkIE9MUiB0byByZWFjdGluZyBub2Rlcy4NCg0KWW91 ciBwcm9wb3NlZCB0ZXh0ICANCiIgQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3 aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9y dCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5n IG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0 IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINCg0KSWYgdGhlIHJlcG9ydGlu ZyBpcyBub3QgYXdhcmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0IGlzIHBy b3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2UgaXQgaXMg YSAibWF5IikgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9hZCBtaXRp Z2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3QgcHJvcGVy bHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFu ZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxkIGJlIG5vdCBvbmx5 IHRoZSBjbGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hl biB0aGUgYWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQg aXMgcmVhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4gDQpUaGVu LCBvbiBvbmUgaGFuZCBpdCBpcyBub3Qgc2ltcGxlIHRvIGtub3cgd2hlbiByZWFjdGluZyBub2Rl cyBoYXZlIHZhbGlkIE9MUiBpbmZvIChhcyBleHBsYWluZWQgYmVsb3cpLCBidXQgaWYgT0xSIGlz IG5vdCBzZW50IGFnYWluIChhcyBwZXIgeW91ciBwcm9wb3NlZCAibWF5IikgdGhlbiBvbmUgb3Ig bXVsdGlwbGUgcmVhY3Rpbmcgbm9kZXMgZG8gbm90IGhhdmUgdGhlIHJlcXVpcmVkIE9MUiwgdGhl biBvdmVybG9hZCBtaXRpZ2F0aW9uIHdpbGwgbm90IHdvcmsuDQoNClRoZXJlZm9yZSwgaW4gbXkg b3BpbmlvbiwgdGhlIHNpbXBsZXN0IHdheSB0byBwcm92aWRlIHJlcXVpcmVkIGluZm9ybWF0aW9u IGlzIHRvIHByb3ZpZGUgT0xSIGluIEFMTCBhbnN3ZXJzLg0KDQpCZXN0IHJlZ2FyZHMNCi9NQ3J1 eg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxv dCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXSANClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJv IGRlIDIwMTQgMTA6NDINClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0K U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQpIb3cgY2FuIHdlIHNheSB0aGF0ICJpbmNsdWRpbmcg dGhlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcyBpcyBzaW1wbGUgYW5kIGVmZmljaWVu dD8iDQpJdCBpcyBzaW1wbGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuIA0KDQpBIHNsaWdo dGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVhcmxpZXIgaXMsIFdo ZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQgdGhhdCBuZWVk cyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5nIHRoZSBlYXJs aWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhlIG92ZXJsb2Fk IHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUg cmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUg QVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxs eSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3 YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVh Y3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhl IHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJl IEFWUC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1h cmlhIENydXogQmFydG9sb21lDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDM6MDMg UE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsIGFsbCwNCg0KSSB0aGluayB3ZSBz aG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVu dCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwgYXMg YSBwdXJlICJtYXkiLCBidXQgbGVhdmluZyBpdCB1cCB0byBpbXBsZW1lbnRhdGlvbiBkb2VzIG5v dCBhc3N1cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQgT0xSIGluZm9ybWF0aW9uLCB3aGF0IGlz IGJhc2ljIGZvciB0aGlzIG1lY2hhbmlzbSB0byB3b3JrLiANCg0KQmVzdCByZWdhcmRzDQovTUNy dXoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pcmF2IFNhbG90IChuc2Fs b3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJv IGRlIDIwMTQgMTA6MTINClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0K U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0 bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nDQoNCk1hcmlhLUNydXosDQoNCkkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ugb24gInNlbmRpbmcg T0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzIi4NCkFuZCB3 ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBteSBpbnRl bnRpb24uIA0KQnV0IHRoZSBtYWluIHF1ZXN0aW9uIGlzLCBhcmUgd2UgdHJ5aW5nIHRvIHByZXZl bnQgYW55IG90aGVyIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uLCB3aGljaCBtYXkgYmUgc21hcnRl ciBhbmQgY2FuIGF2b2lkIGluY2x1ZGluZyByZWR1bmRhbnQgT0xSIGluIGFsbCB0aGUgYW5zd2Vy IG1lc3NhZ2U/DQoNCk1vc3QgcHJvYmFibHksIHRoZSB2ZXJ5IGZpcnN0IGltcGxlbWVudGF0aW9u IG9mIG92ZXJsb2FkIGNvbnRyb2wgd2lsbCBpbmNsdWRlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBt ZXNzYWdlcy4NCkJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJlc3RyaWN0 IHRoZSBkZXZlbG9wZXJzIHdoaWNoIGNhbiBjb21lIHVwIHdpdGggc29tZSBuaWNlIHR3ZWFrcyBh bmQgdHJpY2tzIHRvIGF2b2lkIHNlbmRpbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gZXZlcnkg bWVzc2FnZS4gQW5kIHRoaXMgaXMgd2hlcmUgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGFuZCBhdm9p ZCBwdXR0aW5nIHN1Y2ggcmVzdHJpY3Rpb25zIGluIHByb3RvY29sIGRlZmluaXRpb24uIA0KV2hh dCBkbyB5b3UgdGhpbms/DQoNClRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1Z2dlc3Rpbmcg bG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUgcmVwb3J0 aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KU2VudDogRnJpZGF5LCBGZWJy dWFyeSAwNywgMjAxNCA4OjU3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtE aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkhlbGxvIFVs cmljaCwgTmlyYXYsDQoNCkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBwcm92aWRl ZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNlcnZlciBz ZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVkuDQoNCk9u IHRoZSBvdGhlciBoYW5kLCBjcml0ZXJpYSBwcm92aWRlZCBieSBVbHJpY2ggb24gd2hlbiBPTFIg aGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMgdGhlIHNlcnZlciBoYXMgc29tZSBrbm93bGVkZ2U6DQph KSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxy ZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3Zl cmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQg dGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlDQpj KSBvdGhlcndpc2UNCg0KUmVwb3J0aW5nIG5vZGUgbXVzdCBoYXZlIHNvbWUga25vd2xlZGdlIGFi b3V0IE9MUiByZWNlcHRpb24vc3RhdHVzIGluIHJlYWN0aW5nIG5vZGUuIEhvdyBkb2VzIHNlcnZl ciBhY3F1aXJlIHRoaXMga25vd2xlZGdlPyANClRha2UgaW50byBhY2NvdW50IGFzIHdlbGwgdGhh dCBhICJyZWFjdGluZyIgbm9kZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAoaW4gY2FzZSBpdCBwcm92 aWRlcyBzZXJ2aWNlIHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBw b3J0aW5nIGNsaWVudCkgIGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBm YWN0IHRoZSBTZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3Qg YXMgYSByZWFjdGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNl cnZlciBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50 cyBpbiB0aGUgY2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC4NCg0KVGhlcmVmb3JlLCBJIGRlZmlu aXRlbHkgdGhpbmsgdGhhdCBzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBv cnRhbnQgYWR2YW50YWdlczoNCi0Jc3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rp b24gb3Igc2Vzc2lvbikgaXMgc2ltcGxlciwNCi0JdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRv IGRldGVybWluZSB3aGV0aGVyIG9yIG5vdCB0byBzZW5kIGFuIE9MIHRvIGEgcmVhY3Rpbmcgbm9k ZQ0KLQl0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gYm90aGVyIHdoZXRoZXIgYW4gcmVhY3Rp bmcgbm9kZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBPTFIgb3Igd2hldGhlciB0aGlzIE9MUiBp cyBzdGlsbCB2YWxpZCAoaGFzIG5vdCBleHBpcmVkKS4NCi0Jc2VuZGluZyBhbiBhZGRpdGlvbmFs IEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1 aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLiANCglJbiBmYWN0LCBpbiBh biBvdmVybG9hZCBzaXR1YXRpb24sIHRoZSBlYXNpZXN0IGFuZCBsZWFzdCBjb21wbGV4IGlzIHRv IHNlbmQgaW5mb3JtYXRpb24gb3V0IHRvIGFsbCBhZmZlY3RlZC9hcHBsaWNhYmxlIG5vZGVzLCAN CglhbmQgdGhlIGxhdHRlciBzaG91bGQgdGFrZSBjYXJlIHRvIHRha2UgYXBwcm9wcmlhdGUgYWN0 aW9ucyAgDQotCW1vcmUgcm9idXN0IHNvbHV0aW9uLCBhcyBubyBuZWVkIHRvIGNhdGVyIGZvciBh bGwgdGhlIGNoZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5kIGluZm9ybWF0aW9uLCAgZm9yIHNpdHVh dGlvbnMgd2hlcmUgYW4gYW5zd2VyIG1lc3NhZ2UgaXMgbG9zdCwgIOKApg0KDQoNCkJlc3QgcmVn YXJkcw0KL01DcnV6DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFtt YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAo TlNOIC0gREUvTXVuaWNoKQ0KU2VudDogdmllcm5lcywgMDcgZGUgZmVicmVybyBkZSAyMDE0IDEw OjU5DQpUbzogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFu Z2UuY29tOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtE aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LA0K DQpJJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRl bnRpb24uDQoNCiJ3aGVuIGl0IHdhbnRzIHRvIHByb3ZpZGUvdXBkYXRlLi4uLml0IHNoYWxsIGlu Y2x1ZGUuLi4iIHRyYW5zbGF0ZXMgdG8gIi4uLml0IG1heSBpbmNsdWRlLi4uIi4NCg0KImluIG90 aGVyIGNhc2VzIiBpbiB0aGUgZ2l2ZW4gY29udGV4dCB0cmFuc2xhdGVzIHRvICJ3aGVuIGl0IGRv ZXMgbm90IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUuLi4iDQoNCg0KV2UgaGF2ZSB0aGUgZm9sbG93 aW5nIGNhc2VzOg0KYSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5n IG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQpiKSB0aGUgcmVwb3J0aW5nIG5v ZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFu ZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBz b29uIGV4cGlyZQ0KYykgb3RoZXJ3aXNlDQoNCmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2Rl IG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBu b2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0 ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9M UiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVy IHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKQ0KDQpVbHJpY2gNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86 bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA0OjQ5 IFBNDQpUbzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IGxpb25lbC5tb3Jh bmRAb3JhbmdlLmNvbTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6 IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpV bHJpY2gsDQoNCkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0 aGUgcHJvcG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuDQpIb3cgYWJvdXQgdGhl IGZvbGxvd2luZy4NCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBu ZXcgb3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRl ZCBvdmVybG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1 ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBw b3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9k ZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcg bm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3Zp ZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUg dGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3Vw cG9ydGVkLUZlYXR1cmUgQVZQLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWls dG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIw MTQgMzo1NyBQTQ0KVG86IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IE5pcmF2IFNhbG90 IChuc2Fsb3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2 LCBMaW9uZWwsDQoNCkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2 aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBw cmluY2lwbGUgMic6DQoNCjInLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVy IG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJl c3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy ZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBn b3QgcmVhc29uYWJsZSBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0aW9uIChlLmcuIHRoZSBsYXRl c3QgT0xSLCB3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24g b3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIiwgb3IgYW4gb2xkICBidXQgc29vbiBl eHBpcmluZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQpOyBv dGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUg KG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIg aW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQt RmVhdHVyZSBBVlAuDQoNCkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdh bnQgYXBwcm9hY2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93 IHRoZSByZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBh cmUgbm90IChzdWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1 cywgd2l0aCB1cCB0byBkYXRlIE9MUnMuDQoNClVscmljaCAgDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSBbbWFpbHRv Omxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwg MjAxNCAxMDoyMCBBTQ0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChO U04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVj dDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN Cg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IERpTUUgW21haWx0bzpkaW1l LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52 b3nDqcKgOiBqZXVkaSA2IGbDqXZyaWVyIDIwMTQgMTA6MDggw4DCoDogV2llaGUsIFVscmljaCAo TlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcgT2JqZXTC oDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN ClVscmljaCwNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24g cmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRo ZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1V U1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVk IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQpUaGUgcmVwb3J0aW5nIG5vZGUgbWF5IHNp bXBseSBub3QgaW5jbHVkZSBPTFIgYXNzdW1pbmcgdGhhdCB0aGUgZWFybGllciBwcm92aWRlZCBP TFIgd2lsbCBleHBpcmUgYW5kIHRoZSByZWFjdGluZyBub2RlIHdpbGwgc3RvcCB0aHJvdHRsaW5n IHRoZSB0cmFmZmljLg0KDQpbTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRl ZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlz IGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVk ZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Ig b24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0 YW5kaW5nLg0KDQpBcyB3ZSBoYWQgZGlzY3Vzc2VkIGVhcmxpZXIsIHRoZXJlIGlzIG5vIG5lZWQg Zm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBleHBsaWNpdGx5IHN0b3AgdGhyb3R0bGluZyBhdCBl YWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4gSW4gb3RoZXIgd29yZHMsIHRoZSBy ZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhlIG5hdHVyYWwgZXhwaXJ5IG9mIHRoZSBPTFIgdG8g ZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhlIHNpZ25hbGluZyB0cmFmZmljIHRvd2FyZHMgaXQu DQoNCltMTV0gQWdyZWUNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhl IHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVu ZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0 byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9u Lg0KDQpbTE1dIEFncmVlDQoNClJlc3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVsb3cgYXJlIGZpbmUg d2l0aCBtZS4NCg0KW0xNXSBBZ3JlZQ0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFtt YWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYs IDIwMTQgMjoyMyBQTQ0KVG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBTYWxvdCAobnNhbG90 KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkFjdHVhbGx5IHdlIHNlZW0gdG8gYWdyZWUgb24gdHdv IHByaW5jaXBsZXM6DQoxLiBMYWNrIG9mIE9MUiBtZWFucyAibm8gY2hhbmdlIg0KMi4gdGhlIHJl cG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRl Y2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBj b250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQg dGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3QgT0xSICh3aGljaCBt YXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGlj YXRpbmcgIm5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUu Li4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBu b3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29u dGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KQ2FuIHBlb3BsZSBwbGVhc2Ug Y29uZmlybS4NCg0KVWxyaWNoDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KU2VudDogV2VkbmVzZGF5LCBG ZWJydWFyeSAwNSwgMjAxNCA0OjM1IFBNDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk IGEgdGhyb3R0bGluZw0KDQpBZ3JlZWQuwqAgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92ZXJs b2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUgZm9y IHRoZSBob3N0IG9yIHJlYWxtLsKgIElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBvdmVy bG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVyIHRp bWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCByZXBv cnQuwqAgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhl biBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBpbXBsaWVzIHRoZXJlIGlzIG5vIG92ZXJsb2Fk IGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uDQoNClN0ZXZlDQpPbiAyLzUvMTQgOToxOSBBTSwgTmly YXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6DQpJIGFncmVlIHdpdGggU3RldmUgZXhjZXB0IHRoZSBw YXJ0ICJzaG91bGRu4oCZdCBsYWNrIG9mIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3Zlcmxv YWRlZD8iDQrCoA0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91 Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGlu Y2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2 ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFu ZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVu ZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1l IHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcu DQrCoA0KU28gYmFzaWNhbGx5LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3QgdGhl IHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLiBUaGUgcmVhY3Rp bmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3QgYmFzZWQgb24gb2xkZXIgT0xSIHVudGlsIHRo ZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlvZCBvciB3aGVuIHRoZSBleHBsaWNpdCBPTFIg d2l0aCAiMCIgb3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVkLg0KSW4gbXkgdmlldywgdGhpcyBh bGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZSBh bmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLg0KwqANClJlZ2Fy ZHMsDQpOaXJhdi4NCsKgDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3Zhbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw NSwgMjAxNCA4OjAwIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBb ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1 ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KaW5saW5lDQpPbiAy LzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCk9r IHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4gT0Mt T0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1ZXN0 IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZl biB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlzIHJlcXVlc3RlZCkuDQpTUkQ+IFdoeSBpbiBldmVy eSBhbnN3ZXIgbWVzc2FnZT/CoCBTaG91bGRuJ3QgbGFjayBvZiBhbiBPTFIgYmUgaW50ZXJwcmV0 ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KwqANCsKgDQpPdGhlciBjcml0ZXJpYSBsaWtlIFJF UTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci4NClNSRD4gUmVxdWlyaW5nIGFuIG92 ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywg YnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2lu Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlh bCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0 aW5nIE9MUnMuDQoNCg0KwqANCsKgDQpGb3IgbXkgY2xhcmlmaWNhdGlvbjogSSBndWVzcyB0aGF0 IHRoZSByZWFjdGluZyBub2RlIGlzIG5vdCByZXF1aXJlZCB0byBwcm9jZXNzIGV2ZXJ5IHNpbmds ZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2lsbCBiZSByZXBsYXlzIGFueXdheSkuIFdoYXQgd291bGQg YmUgdGhlIHByb2NlZHVyZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSBpbiBvcmRlciB0byBtaW5pbWl6 ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVkIE9MUnMgYW5kIGF0IHRoZSBzYW1lIHRpbWUgbWluaW1p emUgdGhlIHJpc2sgdG9vIG1pc3MgYSBuZXcgT0xSPw0KU1JEPiBUaGF0IGlzIHRoZSBwdXJwb3Nl IG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuDQoNCg0KwqANCsKgDQrCoA0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNClNlbnQ6IFdlZG5lc2RheSwgRmVi cnVhcnkgMDUsIDIwMTQgNToyNyBBTQ0KVG86IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgZGlt ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2 ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSBzaGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExpb25lbC4N CsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9u ZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDk6 MDcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6 IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUg cmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIERPRVMgTk9UIGluc2VydCB0 aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4gDQpTbyB0aGUgb3B0aW9ucyB3b3VsZCBiZToNCjEtIE9D LU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyDQoyLSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB VlAgaW4gZXZlcnkgcmVxdWVzdCArIE9DLU9MUiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUg Y3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVw ZGF0ZWQuDQrCoA0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEg c2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQrCoA0KTGlvbmVsDQrCoA0KLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQpEZcKgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK2RpbWVA dHJhYy50b29scy5pZXRmLm9yZ10NCkVudm95w6nCoDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5 OjQ5DQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCkNjwqA6IGRpbWVAaWV0Zi5vcmcNCk9i amV0wqA6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQojMzE6 IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQogSXQgaGFzIGJlZW4gcHJvcG9zZWQg dG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0aGF0IGlzwqAgdG8g YmUgaW5jbHVkZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNz YWdlcyB0aGF0wqAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0 ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQogKFRpbWVTdGFtcCkgb2YgdGhlIE9MUiBhY2NvcmRpbmcg dG8gd2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdhcw0KIHN1cnZpdmVkKSBpcyBwZXJmb3Jt ZWQuIEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5kaWNhdGVzIHRoYXQgY3VycmVudGx5IG5vwqAgdGhy b3R0bGluZyBpcyBwZXJmb3JtZWQuwqAgUmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1heSB1c2Ug dGhpc8KgIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0aGVyIHRoZXJlIGlzIGEg bmVlZCB0byB1cGRhdGUgdGhlwqAgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRl c3QgT0xSLg0KIEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5pc20gd291bGQgcmVzdWx0 IGluIHRoZSBuZWVkIGZvciB0aGXCoCByZXBvcnRpbmcgbm9kZSB0byBzZW5kIE9DLU9MUiBBVlBz IGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5nIERPSUPCoCBlbmRwb2ludCBjYW5ub3Qg a25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5n wqAgdGhlIHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRocm90dGxpbmcvbm90IHRocm90dGxp bmcuDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1c3RuZXNzIGFzIGl0IGFs bG93cyB0aGUgcmVwb3J0aW5nIERPSUPCoCBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3Qg aW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZ8KgIERPSUMgZW5kcG9pbnQg KGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24pLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gYWxz byBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBSRkMgNzA2OC4NCiBJbiBzdW1tYXJ5IGl0 IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ IHRvwqAgYmUgdXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs aW5nLg0KwqANCsKgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUg bWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RpbWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K From jouni.nospam@gmail.com Mon Feb 10 02:53:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2CA1A07F5 for ; Mon, 10 Feb 2014 02:53:36 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaWAeBukYmPI for ; Mon, 10 Feb 2014 02:53:34 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 196E51A06C1 for ; Mon, 10 Feb 2014 02:53:33 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id b8so4677300lan.32 for ; Mon, 10 Feb 2014 02:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yzlwe8ubvJoWivRtbVl1CruI7XYYFsVuSQxNHuLO7LQ=; b=XUClYOKIiMi0/PpeH0E2SalP5yY6QRAHKaX/mN1Oib20YedD/zB3YWbkeGFypiNkKV ruNU9i8gXQt1qm67RF/+Y+2oDDvJKflTcT2aXRJ2LqsOpPJ84U3k0JKYspdgRQ5SKmDy 1l0uYJTa8PXjckMFKxLrqkIwTzlMJ3FmX8epLS5nKp6qd3dcQrUQ7MOQse1EXilxlXEe 9d7IwQVncACHYQ7yCsghf+JhloxmryzhJZjuE9Krcvgi9mNKahN/GahqrqFC/S1flVzY 4JkepcuDI8CkVJo80XDppPyzLhYDE+n9vvKG30ZHUCNhb9daVBjTfsGvJEXIrrCGLK6K DP/w== X-Received: by 10.112.40.114 with SMTP id w18mr20341437lbk.20.1392029613337; Mon, 10 Feb 2014 02:53:33 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id cl5sm15346903lbb.14.2014.02.10.02.53.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 02:53:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> Date: Mon, 10 Feb 2014 12:53:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <213D2B01-4A4F-4C06-9272-B93D98F629BC@gmail.com> References: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Cc: ben@nostrum.com, draft-docdt-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 10:53:36 -0000 Good point. I would clarify that a server farm could mean both: one with a single identity and one with multiple identities. The selection is=20 implementation and deployment specific. - Jouni On Feb 7, 2014, at 10:37 PM, dime issue tracker = wrote: > #38: Server Farm Definition Issue >=20 > A "server farm" is defined as "A set of Diameter servers that can = handle > any request for a given set of Diameter applications.". This is not > strictly true. For example, if a request includes a Destination-Server > AVP, then then in general only that particular server in the farm can > handle the request. >=20 > I assume that we don't mean to limit the server farm concept to = situations > where the entire farm is known by a single Diameter-Identity, do we? >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-docdt-dime- > ben@nostrum.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: draft- | Version: 1.0 > docdt-dime-ovli | Keywords: > Severity: Active WG | > Document | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > dime >=20 From maria.cruz.bartolome@ericsson.com Mon Feb 10 02:55:15 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5061A07F7 for ; Mon, 10 Feb 2014 02:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQLxNOzKA2qE for ; Mon, 10 Feb 2014 02:55:13 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 563841A06C1 for ; Mon, 10 Feb 2014 02:55:12 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-7d-52f8b00f6b4f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 1D.C1.04853.F00B8F25; Mon, 10 Feb 2014 11:55:11 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 11:55:11 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] DOIC Endpoint behavior -- Capability Exchange Thread-Index: AQHPITtp8ZynZj/2J0iPmqbtOtVyKpqlCvuAgAlOiUA= Date: Mon, 10 Feb 2014 10:55:10 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92097727F2@ESESSMB101.ericsson.se> References: <52F02C62.70600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvjS7/hh9BBmePaljM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOUv/jIXNE9hrLi0sY+lgXFDdhcjJ4eEgInEosW3WSBsMYkL 99azdTFycQgJnGCU+N60mBXCWcIo0fF3JRtIFZuAncSl0y+Yuhg5OEQElCVO/3IACQsLOEqc XtgJNkhEwEliwdn1bBC2lcS7ta3sIDaLgKrEih9tYHFeAV+J1gtN7CBjhAQKJZ7uNwQJcwoE SJxdNwtsDCPQPd9PrWECsZkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/7FC2EoSK7ZfYoSo15O4 MXUKG4StLbFs4WtmiLWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGyeLU4uLcdCMDvdz0 3BK91KLM5OLi/Dy94tRNjMDYOLjlt9EOxpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAmOIhUCnrFa7+87qPuVyq9r+cZd/TM8+HFJatuyclcfnAKxNOv8U6fv6a T6SFF8n7bjA85v5bUvX0CXY1Zz/hhFcexXM+yu3MKrn/9Fvlx6m3BD6KaL/mT+nu2WlQmV97 ZVKv2PRZR6+IlHR8Y/h3bO407wv564tONYby8qYy73ratCDX5zeLEktxRqKhFnNRcSIAM6h4 VlsCAAA= Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 10:55:16 -0000 Hello Ulrich et all, As far as I can follow your comments on diagram, I tend to agree with your = proposal, but I cannot fully follow this, since diagram is not properly rec= eived. Is it possible to provide diagram in another format that is not modified by= each one email configuration? I think this is very important for discussio= n and agreement Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: martes, 04 de febrero de 2014 14:44 To: ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange Steve, please find comments inline. Regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, February 04, 2014 12:55 AM To: dime@ietf.org Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange All, I believe that the current DOIC Endpoint behavior definition is not suffici= ently defined, especially for agents. I agree. There was also a change introduced in the -01 version of the draft that imp= lies that there can be a DOIC association that goes through a DOIC enabled = agent.=A0 This was not=A0 how I understood endpoints. same with me =A0 The original diagrams showed a DOIC agen= t as terminating an endpoint that came to it.=A0=A0=A0 I suspect there were= different assumptions that lead to clearly different interpretations.=A0=20 I propose that we return to the original diagrams and add the wording below= on how DOC agents behave.=A0 One way to look at this is that DOC agents ac= t as back-to-back DOC endpoints.=A0 I intentionally don't say back-to-back = Diameter endpoints because this does not impact anything except the handlin= g of DOIC related AVPs. Note that I don't believe this requires any changes to Diameter clients or = servers.=A0 I also don't believe this requires any changes to the contents = of the DOIC related AVPs but there is an open question as to whether there = is a need to indicate when a OC-Supported-Features AVP is generated or modi= fied by an agent. I propose to add the following section to the section on capabilities annou= ncement.=A0 I'll send a separate email proposing text to section 5.5 on how= DOC agents are to behave.=20 Regards, Steve ----- 5.3.1 DOC Agent handling of DOIC capability exchange. A DOC agent is defined as a Diameter agent that supports the DOIC extension= . A Diameter agent that supports the DOIC extension is not necessari= ly taking the role of a reacting DOIC endpoint. It only takes the role of a reacting DOIC endpoint when receiving a request= that does not contain an OC-Supported-Features AVP. Similarily a Diameter agent that supports the DOIC extensions is not necess= arily taking the role of a reporting DOIC endpoint. It only takes the role of a reporting DOIC endpoint when receiving a realm = type request (not containing a destination host) that contains an OC-Suppor= ted-Features AVP while it is configured to act as a reporting DOIC endpoint= for that realm. A DOC node is defined as a Diameter client, Diameter server or Diameter age= nt that supports the DOIC extension and decided to take the role o= f a reacting DOIC endpoint and/or reporting DOIC endpoint . An downstream DOIC Association is defined as the association between the DO= IC supporting Diameter entity that sends a Diameter request message to a DO= C agent and the DOC agent. A upstream DOIC Association is defined as the association between a DOC age= nt and the Diameter entity to which the DOC agent sends the Diameter reques= t message.=A0 The following illustrated the upstream and downstream concept= s. =A0 DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC a= ssociation--> DOC=A0 node =A0 Direction of request message for a transaction -----> =A0 Direction of answer message for a transaction <----- this depe= nds on the point of view: one node's downstream DOIC association is another= node's upstream DOIC association. The general case is: +---------+ +---------+ +--------+ +--------+ = +--------+ +--------+ | client | | A1 | | A2 | | A3 | = | A4 | | server | | no DOIC | | no DOIC | | DOIC | | DOIC | = | DOIC | | DOIC | | support | | support | | support| | support| = | support| | support|=20 +---------+ +---------+ +--------+ +--------+ = +--------+ +--------+ | | | | = | | | | |<---DOIC association 1---------------= ---------->|<-------DOIC association 2-->| | | | | = | | | | |<-----------------DOIC association 3-= ---------------------------------------->| | | | | = | | | | | | = | | |----1.xxR------->|---2.xxR----->| | = | | | | |---3.xxR----->|----4.xxR-------------= ---------->| | | | | | = |--------5.xxR--------------->|=20 | | | | = |<-------6.xxA----------------| | | |<--8.xxA------|<---7.xxA-------------= -----------| | |<---10.xxA-------|<--9.xxA------| | = | | | | | | = | | | | | | = | | | | | | = | | | | | | = | | |----11.xxR------>|---12.xxR---->| | = | | | | |---13.xxR---->|-----14.xxR-----------= ---------->|-------15.xxR--------------->| | | | | = | | | | |<---18.xxA----|<----17.xxA-----------= -----------|<-----16.xxA-----------------| |<---20.xxA-------|<---19.xxA----| | = | | | | | | = | | DOIC association 1 is for realm type requests; DOIC association 2 is for re= quest for which A4 selects the server DOIC association 3 is for host type r= equests 1. the client that does not support DOIC sends 1.xxR (realm type request no= t containing destination host) to the next hop; 1.xxR does not contain an O= C-Supported-Features AVP 2. the agent A1 that does not support DOIC forward= s the request to the next hop; 2.xxR still dos not contain an OC-Supported-= Feature AVP. 3. the agent A2 that supports DOIC decides to take the role of a reacting e= ndpoint; it inserts an OC-Supported-Features AVP into 3.xxR indicating supp= ort of features 1 and 2 (in this example). 4. agent A3, although it supports DOIC, does not take the role of a reactin= g endpoint (because 3.xxR contains an OC-Supported-Features AVP); it also d= oes not take the role of a reporting endpoint since it is not configured to= act as reporting endpoint for the destination realm received in 3.xxR; 4.x= xR (unmodified) is sent to the next hop. 5. agent A4 is configured to take the role of the reporting endpoint for th= e realm. It therefore removes the OC-Supported-Features AVP reveived in 4.x= xR and inserts its own supported features (in this example features 1 and 3= ) in 5.xxR. A4 also selects the server to which 5.xxR is sent. 6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA incl= uding an OLR1 (host type) requesting a feature 3 specific traffic reduction= (e.g. window size 20).=20 7. A4 calculates the overall realm overload level, removes the received OLR= 1 and adds its own calculated realm type OLR2 (e.g. a feature 1 specific tr= affic reduction of 50%-loss) to 7.xxA. A4 stores OLR1 for later use. 8. A3 not taking any DOIC role forwards the answer unmodified. 9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores OLR2= for later use. 10. A1 not supporting DOIC is transparent. 11. client sends a new request 11.xxR (containing destination host as learn= d from 10.xxA; no OC-Supported-Features AVP included. 12. A1 is transparent. 13. A2 decides to take the role of the reacting endpoint and includes again= its supported features 1 and 2 in OC-Supported-Features AVO sent within 13= .xxR. 14. A3 is transparent 15. A4 is transparent for host type requests that contain an OC-Supported-F= eatures AVP. 16. server returns 16.xxA including a host type OLR3 requesting a feature 1= specific traffic reduction of e.g. 30%-loss. 17. A4 is transparent 18. A3 is transparent 19. A2 stores OLR3 for later use and may remove OLR3 when sending 19.xxA. 20. client receives 20.xxA. Four scenarios must be supported: =A0 - Scenario 1 - There is both an upstream and downstream DOIC associatio= n. for example see A4 in the figure above =A0 - Scenario 2 - There is no upstream DOIC association do you me= an "There is a downstream DOIC association but no upstream DOIC association= "? Not covered in the figure above. =A0 - Scenario 3 - There is no downstream DOIC association do you = mean "There is an upstream DOIC association but no downstream DOIC associat= ion"? for example see A2 in the figure above =A0 - Scenario 4 - No DOIC association in either direction for exa= mple see A3 in the figure above Scenario 1 - Both upstream and downstream DOIC associations Request message handling: A DOC agent that receives a request that contains the OC-Supported-Features= AVP must act as an endpoint for the downstream DOIC association. NO! see A3 receiving 3.xxR or 13.xxR (this may not be scenario 1, = but how does the agent know which scenario applies?) If the DOC agent relays or proxies the request message then the agent must = include an OC-Supported-Features AVP in the relayed message.=A0 The content= s of the OC-Supported-Features AVP must include, at a minimum, all of the c= ontent included in the received OC-Supported-Features AVP.=A0 If the agent = does not support any additional features then the sent OC-Supported-Feature= s AVP will remain the same as the received OC-Supported-Features AVP. There cannot be more than one OC-Supported-Features AVPs in one req= uest. An agent that inserts an OC-Supported-Features AVP must remove the re= ceived OC-Supported-Features AVP (see A4 when sending 5.xxR). The inserted = OC-Supported Features AVP shall indicate the features the inserting node su= pports, not more, not less If the agent supports DOIC features that are not indicated in the received = OC-Supported-Features AVP then the agent must modify the OC-Supported-Featu= res AVP to indicate support for those features.=A0 The modified OC-Supporte= d-Features AVP must be included in the relayed request message. =A0 Note: any DOIC extension must define the changes needed to the OC-Featu= re-Vector AVP and any additional AVPs that need to be added to the OC-Suppo= rted-Features AVP as part of the capabilities advertisement for that featur= e. Question: Should there be an indication that the contents of the OC-Support= ed-Features AVP was changed? no. for what reason? Question: Will this work when end-to-end security is introduced?=A0 Would a= dding a separate OC-Supported-Features AVP be better, especially when end-t= o-end security is considered? what is the issue? Answer message handling: When an agent receives the=A0 answer message that corresponds to the above = request message i.e. the request message into which the agent has = inserted its OC-Supported-Features AVP , the agent must act as th= e DOIC endpoint for the upstream DOIC association.=A0=20 If the DOC agent relays or proxies the answer message then the agent must i= nclude an OC-Supported-Features AVP in the relayed message. OC-Supported-Features AVP in answer messages is an open issue =A0 The contents of the OC-Supported-Features AVP must include, at a minimu= m, all of the content included in the received OC-Supported-Features AVP.= =A0 If the agent does not support any additional features then the sent OC-= Supported-Features AVP will remain the same as the received OC-Supported-Fe= atures AVP. If the agent supports DOIC features that are not indicated in the received = OC-Supported-Features AVP then the agent should modify the OC-Supported-Fea= tures AVP to indicate support for those features.=A0 The modified OC-Suppor= ted Features AVP must be included in the relayed answer message. Scenario 2 - No downstream DOIC association with an upstream association wasn't that scenario 3? In this case a request is received that does not contain an OC-Supported-Fe= atures AVP. Request message handling: If a DOC agent receives a request that does NOT contain an OC-Supported-Fea= tures AVP then the agent must generate an OC-Supported-Features AVP reflect= ing the DOIC features supported by the DOC agent.=A0 The new OC-Supported-F= eatures AVP must be included in the relayed/proxied request message. The agent will then become the reacting DOIC endpoint for the upstream DOIC= association that results from the transaction.=A0=20 Note: Section x.x.x defines agent behavior when it is the reacting node for= a DOIC association. Answer message handling In this case the answer message will contain an OC-Supported-Features AVP.= =A0 The DOC agent must store the advertised capabilities for use when the D= OC agent reacts to an overload report from the upstream Diameter node. The DOC agent should remove the OC-Supported-Features AVP from the answer m= essage before relaying/proxying the answer message.=A0=20 Scenario 3 - Downstream DOC association with no upstream DOIC association <= Ulrich> wasn't this scenario 2? In this case a OC-Supported-Features AVP is received in the request from th= e downstream Diameter entity but no OC-Supported-Features AVP is received i= n the answer message received from the upstream Diameter entity.=A0 In this= case the agent must act as the reporting DOIC endpoint for the downstream = DOIC association. this is totally new to me. Where does this come from? If a server = does not support DOIC it cannot request load reduction from a downstream ag= ent. The downstream agent (even if it would detect the DOIC-non-support of = the server) cannot request load reduction from further downstream nodes on = behalf of the server Request message handling: Request message handling is the same as for scenario 1. Answer message handling: If a DOC agent receives an answer message that does not contain an OC-Suppo= rted-Features AVP for a transaction that includes an upstream DOC associati= on then the agent must generate an OC-Supported-Features AVP reflecting the= DOIC features supported by the DOC agent.=A0 The generation of this OC-Sup= ported-Features AVP must also follow the rules specified in section 5.3.2.= =A0 The new OC-Supported-Features AVP must be included in the relayed/proxi= ed the answer message. Scenario 4 - No upstream association and no downstream association Request message handling: The request message handling in this case is the same as scenario 2. Answer message handling: If the DOC agent receives an answer message that does not contain an OC-Sup= ported-Features AVP for a transaction that does not include a downstream DO= C association then the agent must NOT generate an OC-Supported-Features AVP= .=A0 The DOC Agent must relay/proxy the answer message with no DOIC related= change. the open issue seems to be: How can an agent determine which scena= rio is applicable? Let me try: An agent that does not support DOIC is always in scenario 4 (no upstream DO= IC association, no downstream DOIC association). For an agent that supports DOIC: When receiving a request that does not contain an OC-Supported-Features AVP= the agent is in scenario 3 or 4 (no downstream DOIC association). Whether = its 3 or 4 depends on whether or not an OLR is received in the correspondin= g answer. When receiving a host type request (a request that contains a Destination-H= ost AVP) that contains an OC-Supported-Feature AVP the agent is in scenario= 4 (no upstream DOIC association, no downstream DOIC association) When rece= iving a realm type request (a request that does not contain a Destination-H= ost AVP) that contains an OC-Supported-Feature AVP and the agent is configu= red to act as reporting node for that realm, the agent is scenario 1 or 2 (= there is a downstream DOIC association). Whether its 1 or 2 depends on whet= her or not an OLR is received in the corresponding answer. When receiving a realm type request (a request that does not contain a Dest= ination-Host AVP) that contains an OC-Supported-Feature AVP and the agent i= s configured not to act as reporting node for that realm, the agent is in s= cenario 4 (no upstream DOIC association, no downstream DOIC association). <= /Ulrich> _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Feb 10 03:00:26 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C4D1A07FB for ; Mon, 10 Feb 2014 03:00:26 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vym9zPeskwN for ; Mon, 10 Feb 2014 03:00:20 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AF2A61A07FD for ; Mon, 10 Feb 2014 03:00:19 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id c11so4745889lbj.30 for ; Mon, 10 Feb 2014 03:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V6PgGeDu9fLIN8rJi+s/tY77MFCe+QzFnCoCjIAIMKU=; b=udrbAUesDnhnzfJWk7xVDnOAFq38u77VoKV3A3qT2MMPUTHXZahqYZfKHRn3UND8D6 UNsOiFD5Z0VAripS0oxOOxmyRTFT48cOSGKEh7j6b3YFk6KugQhEaDuK9maDI6rA211a NAA9kaiyfOwNUSEn/3u88tHafCV5jAcjNhtvI1/vpcTn74lhKNNFOdxRL+SrlU1cd95s Z5uT5JQdliwgGfkzaiYzML7p4BLHU+WV2Wl3JKBGkhXBEQAc20ETENgmM3TnMqNJhASW i3cGcq9/hq9RN/ePUM4EZIoY3JdrzbLDmvk4ZlcQSOwCM6dxvLR4FRyxGD/KuMBkazav 99eA== X-Received: by 10.152.36.8 with SMTP id m8mr21878241laj.24.1392030019009; Mon, 10 Feb 2014 03:00:19 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id cl5sm15376627lbb.14.2014.02.10.03.00.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:00:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org> Date: Mon, 10 Feb 2014 13:00:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Cc: ben@nostrum.com, draft-docdt-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #42: IETF defined example of a stateless application. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:00:26 -0000 RFC4740 understands and deals with NO_STATE_MAINTAINED.. so we could use = that? - Jouni On Feb 7, 2014, at 10:57 PM, dime issue tracker = wrote: > #42: IETF defined example of a stateless application. >=20 > In section 3.1.1, under the definition of "Stateless Application", is > there an IETF defined application that can be added as an example? Not = all > readers may be familiar with 3GPP applications. >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-docdt-dime- > ben@nostrum.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: trivial | Milestone: > Component: draft- | Version: 1.0 > docdt-dime-ovli | Keywords: > Severity: Active WG | > Document | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > dime >=20 From lionel.morand@orange.com Mon Feb 10 03:01:39 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3371E1A07F9 for ; Mon, 10 Feb 2014 03:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAGEie--6LtC for ; Mon, 10 Feb 2014 03:01:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8DA1A0806 for ; Mon, 10 Feb 2014 03:01:36 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 7AB561904A2; Mon, 10 Feb 2014 12:01:35 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2B58DC806C; Mon, 10 Feb 2014 12:01:35 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 12:01:34 +0100 From: To: Jouni Korhonen , "dime@ietf.org" Thread-Topic: [Dime] [dime] #42: IETF defined example of a stateless application. Thread-Index: AQHPJk9QmuZ6tfQvKkGjvbjVFarCYpquUjvg Date: Mon, 10 Feb 2014 11:01:33 +0000 Message-ID: <11942_1392030095_52F8B18F_11942_3080_1_6B7134B31289DC4FAF731D844122B36E497057@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.140315 Cc: "ben@nostrum.com" , "draft-docdt-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #42: IETF defined example of a stateless application. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:01:39 -0000 I was proposing the same thing :) -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: lundi 10 f=E9vrier 2014 12:00 =C0=A0: dime@ietf.org Cc=A0: ben@nostrum.com; draft-docdt-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #42: IETF defined example of a stateless applic= ation. RFC4740 understands and deals with NO_STATE_MAINTAINED.. so we could use th= at? - Jouni On Feb 7, 2014, at 10:57 PM, dime issue tracker wrote: > #42: IETF defined example of a stateless application. >=20 > In section 3.1.1, under the definition of "Stateless Application", is > there an IETF defined application that can be added as an example? Not all > readers may be familiar with 3GPP applications. >=20 > --=20 > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-docdt-dime- > ben@nostrum.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: trivial | Milestone: > Component: draft- | Version: 1.0 > docdt-dime-ovli | Keywords: > Severity: Active WG | > Document | > -------------------------+-----------------------------------------------= -- >=20 > Ticket URL: > dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jean-jacques.trottin@alcatel-lucent.com Mon Feb 10 03:09:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9401A080E for ; Mon, 10 Feb 2014 03:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7Lwh2zpE3uw for ; Mon, 10 Feb 2014 03:09:24 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 681F61A080B for ; Mon, 10 Feb 2014 03:09:24 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1AB9MTJ023747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Feb 2014 05:09:23 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AB9LEt019025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Feb 2014 12:09:22 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 12:09:21 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #35: additional report types are proposed Thread-Index: AQHPIb89LRIcp4kT7Umf//YV8Pl9CpqlRfYAgADBN4CAAEQggIAAAqGAgAAIEgCAAF3UAIAAGngAgAADUQCAB4gtsA== Date: Mon, 10 Feb 2014 11:09:21 +0000 Message-ID: References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2254@DEMUMBX014.nsn-intra.net> <18813_1391619270_52F26CC6_18813_5166_1_6B7134B31289DC4FAF731D844122B36E487640@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <18813_1391619270_52F26CC6_18813_5166_1_6B7134B31289DC4FAF731D844122B36E487640@PEXCVZYM13.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: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #35: additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:09:28 -0000 Hi all =20 I also agree with Lionel and Nirav. As Ulrich proposes, I also think good t= o have a clarification and the hereafter proposed sentence from Ulrich in a= gent behavior (when acting on behalf of the client) is OK for me: "When an agent receives an OLR in response to a request initiated by a clie= nt not supporting DOIC, this agent, acting on behalf of the client, needs t= o (or MUST) bind the received OLR to the origin-host in the request of the = client". JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: mercredi 5 f=E9vrier 2014 17:55 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@iet= f.org Objet=A0: Re: [Dime] [dime] #35: additional report types are proposed If I'm correct, the following condition: d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. is not correct as the message containing the OC-OLR AVP is an answer and th= ere is Destination-Host or Destination-Realm AVPs in an answer. If you want to clarify something, it can be in the section describing the a= gent behavior. And such clarification will be that when an agent received a= n OLR in response to a request initiated by a client not supporting DOIC, t= his agent needs to bind the received OLR to the origin-host of the client (= no need of the origin-realm). Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: mercredi 5 f=E9vrier 2014 17:43 =C0=A0: MORAND Lionel IMT/OLN; ext = Nirav Salot (nsalot); dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additi= onal report types are proposed Even if some feel this is implicit, it should not harm to add the d) condit= ion explicitly please. -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Wednesday, February 05, 2014 4:08 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed Isn't it implicit? An answer is sent to the origin-host of the corresponding request. The agen= t is not the targeting point of the answer and is not supposed to be the re= acting node. Now if an agent wants to act on behalf a client not supporting= the DOCI mechanism at the application, this agent will have to maintain a = binding for this client. This requirement is not bound to the overload cont= rol mechanism but to any function provides by the agent on behalf of downst= ream clients.=20 -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: mercredi 5 f=E9vrier 2014 10:32 =C0=A0: ext Nirav Salot (nsalot); M= ORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: RE: [Dime] [dime] #35: additi= onal report types are proposed Nirav, ... and this natural requirement is missing from the current draft. To address this requirement we could replace the descriptions for report ty= pes 0 and 1 with the decriptions of my proposed report types 2 and 3 respec= tively. As a consquence, however, the agent in the given example configuration woul= d have to store always OLRs per client even when S wants all clients to do = the same throttling. Would that be acceptable? Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, February 05, 2014 10:03 AM To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com; dime@ietf.or= g Subject: RE: [Dime] [dime] #35: additional report types are proposed Ulrich, I do not think so. If we believe that there should be host-specific OLR and if we want to supp= ort the model when the agent acts as reacting node (on behalf of the client= (s)), then the agents are naturally required to store OLR per client/host b= ehind the agent (based on the destination-host AVP in the answer message). Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, February 05, 2014 2:24 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] [dime] #35: additional report types are proposed Hi Lionel, Nirav, your argument only holds in configurations where the client is the reacting= node. In a configuration like this +-------+ | C1 | +------+ | |----------| A | +------+ +-------+ | | | S | | |---------------| | +-------+ | | +------+ | C2 |----------| | | | +------+ +-------+ where clients C1 and C2 do not support DOIC and the same agent A takes the = role of the reacting node on behalf of both C1 and C2 the situation is diff= erent. According to the current version of the draft this will result in bi= g mess with frequent replacements of OLRs in A when e.g. S requests a 50% r= eduction from C1 and 0% reduction from C2.=20 Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Wednesday, February 05, 2014 5:50 AM To: lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed Same view as Lionel below. New report types seem more confusing than adding value. The reporting node knows the host which is going to receive the message (an= d hence report within the message) and hence it can generate "host specific= " report and it insert into the message. No need to define new report types for achieving this. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, February 04, 2014 10:48 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #35: additional report types are proposed I don't see the added-value of these new report types. In any case the reporting node will decide which reduction value to send to= each node and the reacting node will behave accordingly to the value recei= ved in the OLR. So what is the point to say "this value applies to you only= "? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker= Envoy=E9=A0: mardi 4 f=E9vrier 2014 16:39 =C0=A0: MORAND Lionel IMT/OLN Cc= =A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #35: additional report types= are proposed #35: additional report types are proposed Description changed by lionel.morand@orange-ftgroup.com: Old description: > With regard to Overload Mitigation Differentiation per Client (#33)=20 > two additional report types are proposed: > > 2 A host per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. > > 3 A realm per client report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches=20 > the > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > d) The values of the Origin-Host and Origin-Realm AVPs in the=20 > request > match the values of the Destination-Host and Destination-Realm > AVPs respectively of the received message that contained the OC- > OLR AVP. New description: The -01 draft does not address the 3GPP requirement to allow reporting DO= IC endpoints to request different amount of load reduction from different = clients (see TR 29.809 clause 6.4.7). Since 3GPP is the main consumer of DOIC it is proposed to address this re= quirement by adding two new report types. two additional report types are proposed: 2 A host per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. 3 A realm per client report. The overload treatment should apply to requests for which all of the following conditions are true: a) The Destination-Host AVP is absent in the request. b) The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. c) The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. d) The values of the Origin-Host and Origin-Realm AVPs in the reque= st match the values of the Destination-Host and Destination-Realm AVPs respectively of the received message that contained the OC- OLR AVP. -- --=20 --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Feb 10 03:12:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBE01A0818 for ; Mon, 10 Feb 2014 03:12:14 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch5LPblMkFwo for ; Mon, 10 Feb 2014 03:12:13 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B146A1A080F for ; Mon, 10 Feb 2014 03:12:12 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l4so4664651lbv.33 for ; Mon, 10 Feb 2014 03:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iDPofoySkYNLuCbwyWsWBWcea2tICtgoSP73eIdUj8s=; b=DzKK/vvmxuTs6Qe4XLb5KH3DheB5FtltphJLXIY0R778EYC3hW2kbMhqNgeajsyd/P n6bTDKMEYjR/3Ie5/QMyJJOv9Qu8E41EN5BF2FJ+TgP4mHxdmB4url/7xwlK082NsXvF ft0kxrhtaoUd3MjHYbKaP73gCPMfRlXEKTIFsvkOBIemsM4qHjn0JB6xwB/sSTrrpLrk fNqm2XyxmDyWUi//RYEEBmKH12+OqVpoan7lcX2xMh6K7AIm7mVdUWVeQqOq9uV6Jfjw Ync17FL6DZIoozkGT7FRT8e48ZVAdCN2B5EfbKS/tLRffpAuiD8m/7Lr3+CmoXhMcKr8 wUAw== X-Received: by 10.112.26.79 with SMTP id j15mr46520lbg.73.1392030731922; Mon, 10 Feb 2014 03:12:11 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ir3sm21768300lac.9.2014.02.10.03.12.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:12:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> Date: Mon, 10 Feb 2014 13:12:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Cc: ben@nostrum.com, draft-docdt-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:12:15 -0000 On Feb 7, 2014, at 11:54 PM, dime issue tracker = wrote: > #45: Why is a validity duration of 0 disallowed? >=20 > Section 4.5 disallows a validity duration of zero. Why do we want to > disallow that? It would allow a quick way of ending any existing = overload > condition without worrying about the semantics of the abatement = algorithm. > (We currently use a reduction percentage of zero to end an overload > condition--but that's specific to the loss algorithm and might not = make > sense for all future ones.) Right. Avoiding two ways of ending overload condition was the reason. I am OK to have validity duration 0 as an additional method ending the overload condition based on the reasoning above. - Jouni >=20 > Note that setting an expiration time to zero is the standard way of > removing state in several other protocols (e.g. SIP). >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-docdt-dime- > ben@nostrum.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: draft- | Version: 1.0 > docdt-dime-ovli | Keywords: > Severity: Active WG | > Document | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > dime >=20 From lionel.morand@orange.com Mon Feb 10 03:15:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D9C1A080F for ; Mon, 10 Feb 2014 03:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgL84EKJdvm0 for ; Mon, 10 Feb 2014 03:15:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D151B1A080B for ; Mon, 10 Feb 2014 03:15:33 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C52F33242C1; Mon, 10 Feb 2014 12:15:32 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A90A835C06D; Mon, 10 Feb 2014 12:15:32 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 12:15:32 +0100 From: To: Jouni Korhonen Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPI+wA3JLjYqL7IkqggWkMy8Pxz5quWNQA Date: Mon, 10 Feb 2014 11:15:31 +0000 Message-ID: <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> In-Reply-To: <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:15:37 -0000 Hi Jouni, > As the syntax of the OC-Feature-Vector is adapted to advertize supported = algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP = for the reduction algo (default) and a new dedicated report AVP must be cre= ated when a new algo is introduced. In this way, the OC-OLR is self-explici= t. Bah. OLR should work for additional abatement algorithms IF we agree that the OLR is align with the announced abatement algorithm..=20 [LM] The issue if when you have more than one algo (let say 2). There is no= way for the reporting node to indicate the algo to use with the OLR sent i= n the answer using the OC-Feature-Vector. The only info that you could have= is "use either one or the other". The simpliest way would be to define a new AVP when you want to support mor= e than the default algo. If you want to rely on the same OLR with another a= lgo, you should have a way to indicate the algo to use with the given OLR.= =20 > It would be purely optional to send the Supported-Features AVP along with= the OC-OLR AVP. It is already today if you only support the default, right. [LM] Right. No issue here. -----Message d'origine----- De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Envoy=E9=A0: vendredi 7 f=E9vrier 2014 11:04 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag= es On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote: > I think that there is actually an issue here but the proposed way to solv= e it is not the correct one. Agree. > The initial idea was to be able to use the same overload report with seve= ral algorithms. So the OLR was somehow only meaningful along with the OC-Fe= ature-Vector AVP. The initial idea was to go on lines of RFC5447. > But because the OC-Feature-Vector AVP is defined as a set of flags, it is= not possible to say that this OLR is to be used with only one given algo w= hen more than one is defined (as the bit flags will advertize 1 AND 2 for 2= supported algos). So the OC-Feature-Vector cannot be used to indicate the = abatement to perform. My intention was always allow: client announces ABC server supports BCD server announced only e.g. C since it is common alternatively server announced nothing and then the default applies > As the syntax of the OC-Feature-Vector is adapted to advertize supported = algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP = for the reduction algo (default) and a new dedicated report AVP must be cre= ated when a new algo is introduced. In this way, the OC-OLR is self-explici= t. Bah. OLR should work for additional abatement algorithms IF we agree that the OLR is align with the announced abatement algorithm..=20 > It would be purely optional to send the Supported-Features AVP along with= the OC-OLR AVP. It is already today if you only support the default, right. - Jouni >=20 > Lionel=20 >=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #30: OC-Supported-Features AVP in answer messages >=20 > #30: OC-Supported-Features AVP in answer messages >=20 > According to the current feature advertisement/negotiation mechanism in > the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP > in answer messages to indicate their supported OC features to the reacting > DOIC endpoint. > The author of this document believes that the best a reacting node can do > with such information is to ignore it, and therefore proposes to allow > reporting nodes not to insert OC-Supported-Features AVPs in answer > messages. > Currently only one feature is defined (OLR_DEFAULT_ALGO). > A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other > feature is only interested in receiving/not receiving OC-OLR AVPs from > reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates > support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not receiving > an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >=20 > a) There is no overload > b) DOIC is not supported >=20 > The reacting DOIC endpoint does not need to differentiate between these > two cases as the behavior (do not throttle) is the same in both cases. > The -01 draft says in clause 4.1: > If there is no single matching > capability the reacting node MUST act as if it does not implement > DOIC and cease inserting any DOIC related AVPs into any Diameter > messages with this specific reacting node. >=20 > This however is inconsistent. > The reacting node that ceases sending DOIC related AVPs would never > recognize when the server is upgraded to support DOIC. > Subsequent requests (not including DOIC related AVPs) may take a different > path towards the server and on that path there may be an agent that > supports DOIC (with a match of supported features) and could take the role > of the reporting DOIC endpoint; but the agent cannot take this role since > the reacting node (although supporting DOIC) ceased sending of OC- > Supported-Features AVPs. > In summary: As long as no extension feature is defined within draft-ietf- > dime-ovli (i.e. never, since extensions will be defined in other > drafts), there is no need for draft-ietf-dime-ovli to mandate or even > describe inclusion of OC-Supported-Features AVP in answer messages. >=20 > --=20 > --------------------------------------+-------------------------- > Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-docdt-dime-ovli | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+-------------------------- >=20 > Ticket URL: > dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Mon Feb 10 03:16:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869291A0813 for ; Mon, 10 Feb 2014 03:16:19 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLpCyNqaMPLf for ; Mon, 10 Feb 2014 03:16:17 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 40FDF1A080B for ; Mon, 10 Feb 2014 03:16:17 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id n15so4719285lbi.11 for ; Mon, 10 Feb 2014 03:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7sZzUcY+YycH/kzFEX0dg8eukEplZFbdzMB2xnubI1k=; b=T0ILNWOUlH9LUEPiO1m+uxqx6vLJZrcTWV2sbTWsBk3VdbebmkLDnMoPmCn9+uI2IF yIL4yg3fEJTP797KLxTndIVzAemuTUqiDT2IJ701sn4U+WeH/e9xfNqt/hN8w2dvQxGs Hp7MVFzrw3hkwPXcvDpteWKnl+0LiO/NjZbKckxmw4FIwkxc0EqGJ/xZRRpFbdb2cWbi /0AWwxTsrJB3XGFD/pjOXg9MUXe9qOeSrEv8OBuDHuq+eR/pjuE0nhFkU9e5T8IAbk1M 4OPNRs65cPcIUtm2lV7JgdoOWbKuiOeRI6mFEXOiPLm2du6J42k/+pEq9/B8j4uxkxiP KF5w== X-Received: by 10.152.209.7 with SMTP id mi7mr1213404lac.42.1392030976544; Mon, 10 Feb 2014 03:16:16 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id bl3sm15443004lbd.7.2014.02.10.03.16.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:16:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> Date: Mon, 10 Feb 2014 13:16:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Cc: ben@nostrum.com, draft-docdt-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:16:19 -0000 My reasoning for explicit termination was that knowing the = implementation folks they will let overload conditions expire unless advised otherwise. And having unnecessary stuff hanging around waiting for a cleanup is not a good thing in general. But I am open here for other options.. - Jouni On Feb 7, 2014, at 11:59 PM, dime issue tracker = wrote: > #46: Bad normative advice on not letting overload reports expire >=20 > Section 4.5 says " As a general guidance for implementations it is > RECOMMENDED never to let any overload report to timeout." In my = opinion, > this is bad advice. If an overload report is close to expiring anyway, > it's better to just let it expire than to generate a new report to end = the > condition. >=20 > Furthermore, this falls into the category of normative language that = does > not effect interoperability. That is forbidden by RFC 2119, except for > situations where not following it does significant harm. If we believe > letting reports expire does significant harm, we should explain why. >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-docdt-dime- > ben@nostrum.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: draft- | Version: 1.0 > docdt-dime-ovli | Keywords: > Severity: Active WG | > Document | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > dime >=20 From jouni.nospam@gmail.com Mon Feb 10 03:24:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6841A080D for ; Mon, 10 Feb 2014 03:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UqjF1re4sJq for ; Mon, 10 Feb 2014 03:24:06 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CC42C1A080C for ; Mon, 10 Feb 2014 03:24:05 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id b8so4587538lan.4 for ; Mon, 10 Feb 2014 03:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3o9bhx/gxV1b2RywW2sFgwVcJDkmJ9Fv6LrJS/6IDbU=; b=jUv7Bs0M3Rl6CzHGT7DHac11OQ/RizYkGe/ymrlsmUh1Q8CQAdh5E5jOqnNbWWP1Ub jog4gVbqjaYy4Tv4g7D8uISLxt0Vw0xTACQ1BypFDw1cY0VUslaxWKDgskEUj3Bz22n8 hWtsthpRGmq0TdujTwcgLIvAFRaLQe0DcL0BteVMib7nIfI47xcwti4Ro5ZrAvy7zy/c JuGYHlTTTrEKGQgfoQK7HsO2eK1DHMWGVjx6hAsG7Fu9U1oKE3VGaKbI+1pMVb3KJBRF mA6jTpkndPFT6ap0MRmRBrPpgXIblFDATELiPI5Pq7JccPw83C4gCRikrg3DYhv9jtKs HTxw== X-Received: by 10.112.253.34 with SMTP id zx2mr622084lbc.61.1392031445100; Mon, 10 Feb 2014 03:24:05 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id cl5sm15436746lbb.14.2014.02.10.03.24.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:24:00 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Mon, 10 Feb 2014 13:23:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:24:09 -0000 On Feb 10, 2014, at 1:15 PM, wrote: > Hi Jouni, >=20 >> As the syntax of the OC-Feature-Vector is adapted to advertize = supported algos, it could be easier to clarify that the OC-OLR AVP is = THE report AVP for the reduction algo (default) and a new dedicated = report AVP must be created when a new algo is introduced. In this way, = the OC-OLR is self-explicit. >=20 > Bah. OLR should work for additional abatement algorithms > IF we agree that the OLR is align with the announced > abatement algorithm..=20 >=20 > [LM] The issue if when you have more than one algo (let say 2). There = is no way for the reporting node to indicate the algo to use with the = OLR sent in the answer using the OC-Feature-Vector. The only info that = you could have is "use either one or the other". This we can fix (and I personally would like to fix). The reporting node announces in its OC-Feature-Vector the selected common algorithm for the sent OLR. We had this at some point of time, btw. > The simpliest way would be to define a new AVP when you want to = support more than the default algo. If you want to rely on the same OLR = with another algo, you should have a way to indicate the algo to use = with the given OLR. I recall there was a strong arguments against algorithm types in OLRs.. - Jouni >=20 >=20 >> It would be purely optional to send the Supported-Features AVP along = with the OC-OLR AVP. >=20 > It is already today if you only support the default, right. >=20 > [LM] Right. No issue here. >=20 > -----Message d'origine----- > De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer = messages >=20 >=20 > On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote: >=20 >> I think that there is actually an issue here but the proposed way to = solve it is not the correct one. >=20 > Agree. >=20 >> The initial idea was to be able to use the same overload report with = several algorithms. So the OLR was somehow only meaningful along with = the OC-Feature-Vector AVP. >=20 > The initial idea was to go on lines of RFC5447. >=20 >> But because the OC-Feature-Vector AVP is defined as a set of flags, = it is not possible to say that this OLR is to be used with only one = given algo when more than one is defined (as the bit flags will = advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector = cannot be used to indicate the abatement to perform. >=20 > My intention was always allow: >=20 > client announces ABC > server supports BCD > server announced only e.g. C since it is common > alternatively server announced nothing and then the default applies >=20 >> As the syntax of the OC-Feature-Vector is adapted to advertize = supported algos, it could be easier to clarify that the OC-OLR AVP is = THE report AVP for the reduction algo (default) and a new dedicated = report AVP must be created when a new algo is introduced. In this way, = the OC-OLR is self-explicit. >=20 > Bah. OLR should work for additional abatement algorithms > IF we agree that the OLR is align with the announced > abatement algorithm..=20 >=20 >> It would be purely optional to send the Supported-Features AVP along = with the OC-OLR AVP. >=20 > It is already today if you only support the default, right. >=20 > - Jouni >=20 >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 >> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #30: OC-Supported-Features AVP in answer messages >>=20 >> #30: OC-Supported-Features AVP in answer messages >>=20 >> According to the current feature advertisement/negotiation mechanism = in >> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features = AVP >> in answer messages to indicate their supported OC features to the = reacting >> DOIC endpoint. >> The author of this document believes that the best a reacting node = can do >> with such information is to ignore it, and therefore proposes to = allow >> reporting nodes not to insert OC-Supported-Features AVPs in answer >> messages. >> Currently only one feature is defined (OLR_DEFAULT_ALGO). >> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no = other >> feature is only interested in receiving/not receiving OC-OLR AVPs = from >> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly = indicates >> support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not = receiving >> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >>=20 >> a) There is no overload >> b) DOIC is not supported >>=20 >> The reacting DOIC endpoint does not need to differentiate between = these >> two cases as the behavior (do not throttle) is the same in both = cases. >> The -01 draft says in clause 4.1: >> If there is no single matching >> capability the reacting node MUST act as if it does not implement >> DOIC and cease inserting any DOIC related AVPs into any Diameter >> messages with this specific reacting node. >>=20 >> This however is inconsistent. >> The reacting node that ceases sending DOIC related AVPs would never >> recognize when the server is upgraded to support DOIC. >> Subsequent requests (not including DOIC related AVPs) may take a = different >> path towards the server and on that path there may be an agent that >> supports DOIC (with a match of supported features) and could take the = role >> of the reporting DOIC endpoint; but the agent cannot take this role = since >> the reacting node (although supporting DOIC) ceased sending of OC- >> Supported-Features AVPs. >> In summary: As long as no extension feature is defined within = draft-ietf- >> dime-ovli (i.e. never, since extensions will be defined in other >> drafts), there is no need for draft-ietf-dime-ovli to mandate or = even >> describe inclusion of OC-Supported-Features AVP in answer messages. >>=20 >> --=20 >> --------------------------------------+-------------------------- >> Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-docdt-dime-ovli | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------------+-------------------------- >>=20 >> Ticket URL: >> dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From jouni.nospam@gmail.com Mon Feb 10 03:29:03 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5E1A0855 for ; Mon, 10 Feb 2014 03:29:03 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvF9_2nnJk_c for ; Mon, 10 Feb 2014 03:29:01 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 71CAD1A0832 for ; Mon, 10 Feb 2014 03:28:50 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id c6so4713531lan.11 for ; Mon, 10 Feb 2014 03:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FY3mqPN7rkFYMVDNVjrAysmKLkBEWspUWmE7UTXtkI0=; b=zfRbLkZmlIa3bAGMgzyshFqqEKqXxNCrsRfLwBaaZsu3aCXN7TXofD+1/6TZdEvIxC E5Qi3Np5P8eREhPy1NxnF3nSmfJtv4sDrHuZRtZvAuy+bjAOh0ycwMPqu9TXMdtk9+LM RLz8/lleP0M1C74Cp0p4IcGhAU9kF4H03fnDxLHS82+qnyINEAZN2ddaDtc7GWEbSSLV sGAr5EMcJSvzKOG7ADjpTXtfEha1+ZlasK17Hm1YNbhtnBmq5E0sN1BMLvEgRlRtQEfH rO/M2E6A2tbJLM/L3ZXY7lLzJDZ91Wd7x+DmFYkiJnfsOlLC9VratrOrvMceogE/lhYc xNNg== X-Received: by 10.152.198.201 with SMTP id je9mr93666lac.73.1392031729704; Mon, 10 Feb 2014 03:28:49 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id g8sm21858507lae.1.2014.02.10.03.28.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:28:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> Date: Mon, 10 Feb 2014 13:28:45 +0200 Content-Transfer-Encoding: 7bit Message-Id: <85246750-FB35-4890-9952-C4F1C5E108AA@gmail.com> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:29:03 -0000 >> b) The value of the Destination-Realm AVP in the request matches the >> value of the Origin-Realm AVP of the received message >> that contained the OC-OLR AVP. > > It is perfectly valid to send a request that has Destination-Host AVP > but no Destination-Realm AVP. It just means the Diameter nodes must > be adjacent peers. > ok, then let's remove b) from 0 My statement above is actually wrong. Sorry about misinformation. - Jouni From lionel.morand@orange.com Mon Feb 10 03:30:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0BA1A080B for ; Mon, 10 Feb 2014 03:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILfFKzkASg0K for ; Mon, 10 Feb 2014 03:30:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 24E011A081C for ; Mon, 10 Feb 2014 03:30:52 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 88AAE190555; Mon, 10 Feb 2014 12:30:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 650C6C807C; Mon, 10 Feb 2014 12:30:49 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 12:30:49 +0100 From: To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPJZThK95DWDMaH0qQEyVc/ebDNpquWr2w Date: Mon, 10 Feb 2014 11:30:48 +0000 Message-ID: <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.140315 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:30:55 -0000 No it was not my intention and it is why it was written "except" :) The abatement for the Realm applies when NO explicit reduction is requested= for a specific node of this realm. In such a case i.e. when an OLR is rece= ived for a specific node inside a realm for which a reduction also applies,= *ONLY* the reduction requested for the node applied. Is it clearer? Lioenl=20 -----Message d'origine----- De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Envoy=E9=A0: dimanche 9 f=E9vrier 2014 13:46 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich) Cc=A0: MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, February 07, 2014 11:21 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >=20 >=20 > On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> I better like Lionel's approach, but even that is not ok in the unlikely= extreme case where we have two servers in a realm, S1 is not overloaded at= all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why s= hould a client do a 25% throttling when sending host type requests to the n= ot at all overloaded S1? >> What is wrong with letting the client >> -not throttle host-type requests to S1, >> -throttle host type request to S2 with 50% and >> -throttle realm type requests wit 25%? >=20 > Isn't this what Lionel said below? > no it is not Ok, maybe I misread the "realm abatement is applied in any case except if there is an explicit report for the destination-host"? If this means the realm abatement is still applied after applying the host abatement, then I agree it is not the same you said. - Jouni > I am OK with Lionel's > "wording" here. >=20 > - Jouni >=20 >>=20 >>=20 >>=20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand= @orange.com >> Sent: Wednesday, February 05, 2014 4:14 PM >> To: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >>=20 >> I tend to agree except that I would reverse the logic as for the routing= principles: the Destination-host takes precedence when present over Destin= ation-Realm. So the realm abatement is applied in any case except if there = is an explicit report for the destination-host. >>=20 >> Lioenl >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >>=20 >> It makes more sense to me for a realm report to apply to all requests ta= rgeted for that realm, independent the type of request. This implies that = it would apply to requests that also have a Destination-Host specified. >>=20 >> If this is the definition of a realm report then we need to specify the = interaction between realm reports and host reports. >>=20 >> I propose that throttling would occur on the realm first and the host se= cond. If a message targetted for the host is throttled as a result of real= m overload then that throttled message would count as part of the reduction= needed to address the host overload. Messages to the host that survive re= alm abatement would then be candidates for host overload. >>=20 >> Steve >>=20 >> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: >> The case "Realm" as described below raises another question: is it prohi= bited for a realm to only rely on a global overload report for the whole re= alm, whatever the nodes inside this realm? >> If not, only OLR with the report type "realm" would be received by the r= eacting node. And the reduction indicated in the OLR will apply always for = the realm, whatever the presence of Destination-host AVP in the request... = except if an explicit report with the type "Host" as been received for this= destination-host. >>=20 >> Does it make sense? >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 >> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #34: Semantics of OC-Report-Type AVP >>=20 >> #34: Semantics of OC-Report-Type AVP >>=20 >> Text in clause 4.6 does not fully explain to which requests overload >> treatment of a given report type applies. >> Proposal: >>=20 >> 0 A host report. The overload treatment should apply to requests >> for which all of the following conditions are true: >> a) The Destination-Host AVP is present in the request and its value >> matches the value of the Origin-Host AVP of the received message >> that contained the OC-OLR AVP. >> b) The value of the Destination-Realm AVP in the request matches t= he >> value of the Origin-Realm AVP of the received message >> that contained the OC-OLR AVP. >> c) The value of the Application-ID in the Diameter Header of the >> request matches the value of the Application-ID of the Diameter >> Header of the received message that contained the OC-OLR AVP. >>=20 >>=20 >>=20 >> 1 A realm report. The overload treatment should apply to >> requests for which all of the following conditions are true: >> a) The Destination-Host AVP is absent in the request. >> b) The value of the Destination-Realm AVP in the request matches t= he >> value of the Origin-Realm AVP of the received message >> that contained the OC-OLR AVP. >> c) The value of the Application-ID in the Diameter Header of the >> request matches the value of the Application-ID of the Diameter >> Header of the received message that contained the OC-OLR AVP. >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Mon Feb 10 03:36:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA31C1A080B for ; Mon, 10 Feb 2014 03:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HADSPBevADhg for ; Mon, 10 Feb 2014 03:36:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1353B1A0884 for ; Mon, 10 Feb 2014 03:36:40 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5D5653B4196; Mon, 10 Feb 2014 12:36:39 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3AF4C2380D3; Mon, 10 Feb 2014 12:36:39 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 12:36:38 +0100 From: To: Jouni Korhonen Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages Thread-Index: AQHPI+wA3JLjYqL7IkqggWkMy8Pxz5quWNQA///zv4CAABOHwA== Date: Mon, 10 Feb 2014 11:36:38 +0000 Message-ID: <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> In-Reply-To: <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.83914 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:36:43 -0000 -----Message d'origine----- De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Envoy=E9=A0: lundi 10 f=E9vrier 2014 12:24 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag= es On Feb 10, 2014, at 1:15 PM, wrote: > Hi Jouni, >=20 >> As the syntax of the OC-Feature-Vector is adapted to advertize supported= algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP= for the reduction algo (default) and a new dedicated report AVP must be cr= eated when a new algo is introduced. In this way, the OC-OLR is self-explic= it. >=20 > Bah. OLR should work for additional abatement algorithms > IF we agree that the OLR is align with the announced > abatement algorithm..=20 >=20 > [LM] The issue if when you have more than one algo (let say 2). There is = no way for the reporting node to indicate the algo to use with the OLR sent= in the answer using the OC-Feature-Vector. The only info that you could ha= ve is "use either one or the other". This we can fix (and I personally would like to fix). The reporting node announces in its OC-Feature-Vector the selected common algorithm for the sent OLR. We had this at some point of time, btw. [LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY = be used (when present) to indicate the algo to use, algo part of the common= algos between the reporting node and the reacting node. > The simpliest way would be to define a new AVP when you want to support m= ore than the default algo. If you want to rely on the same OLR with another= algo, you should have a way to indicate the algo to use with the given OLR. I recall there was a strong arguments against algorithm types in OLRs.. [LM] I was not proposing such idea :) - Jouni >=20 >=20 >> It would be purely optional to send the Supported-Features AVP along wit= h the OC-OLR AVP. >=20 > It is already today if you only support the default, right. >=20 > [LM] Right. No issue here. >=20 > -----Message d'origine----- > De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag= es >=20 >=20 > On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote: >=20 >> I think that there is actually an issue here but the proposed way to sol= ve it is not the correct one. >=20 > Agree. >=20 >> The initial idea was to be able to use the same overload report with sev= eral algorithms. So the OLR was somehow only meaningful along with the OC-F= eature-Vector AVP. >=20 > The initial idea was to go on lines of RFC5447. >=20 >> But because the OC-Feature-Vector AVP is defined as a set of flags, it i= s not possible to say that this OLR is to be used with only one given algo = when more than one is defined (as the bit flags will advertize 1 AND 2 for = 2 supported algos). So the OC-Feature-Vector cannot be used to indicate the= abatement to perform. >=20 > My intention was always allow: >=20 > client announces ABC > server supports BCD > server announced only e.g. C since it is common > alternatively server announced nothing and then the default applies >=20 >> As the syntax of the OC-Feature-Vector is adapted to advertize supported= algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP= for the reduction algo (default) and a new dedicated report AVP must be cr= eated when a new algo is introduced. In this way, the OC-OLR is self-explic= it. >=20 > Bah. OLR should work for additional abatement algorithms > IF we agree that the OLR is align with the announced > abatement algorithm..=20 >=20 >> It would be purely optional to send the Supported-Features AVP along wit= h the OC-OLR AVP. >=20 > It is already today if you only support the default, right. >=20 > - Jouni >=20 >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 >> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48 >> =C0 : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #30: OC-Supported-Features AVP in answer messages >>=20 >> #30: OC-Supported-Features AVP in answer messages >>=20 >> According to the current feature advertisement/negotiation mechanism in >> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP >> in answer messages to indicate their supported OC features to the reacti= ng >> DOIC endpoint. >> The author of this document believes that the best a reacting node can = do >> with such information is to ignore it, and therefore proposes to allow >> reporting nodes not to insert OC-Supported-Features AVPs in answer >> messages. >> Currently only one feature is defined (OLR_DEFAULT_ALGO). >> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other >> feature is only interested in receiving/not receiving OC-OLR AVPs from >> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates >> support of OLR_DEFAULT_ALGO by the reporting DOIC endpoint; not receivi= ng >> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons: >>=20 >> a) There is no overload >> b) DOIC is not supported >>=20 >> The reacting DOIC endpoint does not need to differentiate between these >> two cases as the behavior (do not throttle) is the same in both cases. >> The -01 draft says in clause 4.1: >> If there is no single matching >> capability the reacting node MUST act as if it does not implement >> DOIC and cease inserting any DOIC related AVPs into any Diameter >> messages with this specific reacting node. >>=20 >> This however is inconsistent. >> The reacting node that ceases sending DOIC related AVPs would never >> recognize when the server is upgraded to support DOIC. >> Subsequent requests (not including DOIC related AVPs) may take a differe= nt >> path towards the server and on that path there may be an agent that >> supports DOIC (with a match of supported features) and could take the ro= le >> of the reporting DOIC endpoint; but the agent cannot take this role since >> the reacting node (although supporting DOIC) ceased sending of OC- >> Supported-Features AVPs. >> In summary: As long as no extension feature is defined within draft-iet= f- >> dime-ovli (i.e. never, since extensions will be defined in other >> drafts), there is no need for draft-ietf-dime-ovli to mandate or even >> describe inclusion of OC-Supported-Features AVP in answer messages. >>=20 >> --=20 >> --------------------------------------+-------------------------- >> Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-docdt-dime-ovli | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------------+-------------------------- >>=20 >> Ticket URL: >> dime >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jean-jacques.trottin@alcatel-lucent.com Mon Feb 10 04:55:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C401A0606 for ; Mon, 10 Feb 2014 04:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbVRVtO1HHvw for ; Mon, 10 Feb 2014 04:55:43 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD601A0828 for ; Mon, 10 Feb 2014 04:55:42 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1ACteHn018009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Feb 2014 06:55:42 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1ACtdAx014031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Feb 2014 13:55:40 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 13:55:40 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIcx34wrZRRvx1EKFdFq4TjstmpqmsICAgAAE6ICAABUugIACvZWAgAAwCoCAADL/AIAEjBxA Date: Mon, 10 Feb 2014 12:55:40 +0000 Message-ID: References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 12:55:46 -0000 Dear all I share Ulrich and MCruz views, - Host OLR based control applies to requests where Destination Host is know= n=20 - Realm OLR based control applies to requests where Destination Host is not= known (only the Destination realm). I think it is simple, otherwise as MCruz indicated it complicates; e.g abou= t the Ulrich's example where the Host S1 is not overloaded but the realm is= overloaded. the client will not receive Host OLR reports from host S1 (so = no explicit traffic reduction requested by S1), but according to Lionel com= ment, I understand client will have to throttle the requests sent to S1 ac= cording to realm OLR, so how to avoid this. JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 17:15 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Dear all, I am in favor of the proposal made by Ulrich in the sequence diagram he pro= vided. ---- As a summary: Consequently the reacting node will receive realm type OLRs from the agent = and host type OLRs from the servers. The received realm type OLR will be relevant for the reacting node when sen= ding/throttling realm type requests; the received host type OLR will be rel= evant for the reacting node when sending/throttling host type request= s. ----- It may occur though, that a Client has only received Realm type OLR, and th= en it has to send a request to one specific host, then the Client will not = apply any restriction, but as soon as the response is received back, Client= will update Host type OLR. Same will apply when only Host type OLR has be= en received by Client. The alternative will be to always send back from an Agent both Host OLR plu= s Realm OLR, but I do not think this is necessary and may complicate the so= lution. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: viernes, 07 de febrero de 2014 14:13 To: ext Jouni Korhonen Cc: dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 07, 2014 11:21 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > I better like Lionel's approach, but even that is not ok in the unlikely = extreme case where we have two servers in a realm, S1 is not overloaded at = all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh= ould a client do a 25% throttling when sending host type requests to the no= t at all overloaded S1? > What is wrong with letting the client > -not throttle host-type requests to S1, > -throttle host type request to S2 with 50% and > -throttle realm type requests wit 25%? Isn't this what Lionel said below? no it is not I am OK with Lionel's "wording" here. - Jouni > =20 > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@= orange.com > Sent: Wednesday, February 05, 2014 4:14 PM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > I tend to agree except that I would reverse the logic as for the routing = principles: the Destination-host takes precedence when present over Destina= tion-Realm. So the realm abatement is applied in any case except if there i= s an explicit report for the destination-host. > =20 > Lioenl > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > It makes more sense to me for a realm report to apply to all requests tar= geted for that realm, independent the type of request. This implies that i= t would apply to requests that also have a Destination-Host specified. >=20 > If this is the definition of a realm report then we need to specify the i= nteraction between realm reports and host reports. >=20 > I propose that throttling would occur on the realm first and the host sec= ond. If a message targetted for the host is throttled as a result of realm= overload then that throttled message would count as part of the reduction = needed to address the host overload. Messages to the host that survive rea= lm abatement would then be candidates for host overload. >=20 > Steve >=20 > On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: > The case "Realm" as described below raises another question: is it prohib= ited for a realm to only rely on a global overload report for the whole rea= lm, whatever the nodes inside this realm? > If not, only OLR with the report type "realm" would be received by the re= acting node. And the reduction indicated in the OLR will apply always for t= he realm, whatever the presence of Destination-host AVP in the request... e= xcept if an explicit report with the type "Host" as been received for this = destination-host. > =20 > Does it make sense? > =20 > Lionel > =20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #34: Semantics of OC-Report-Type AVP > =20 > #34: Semantics of OC-Report-Type AVP > =20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: > =20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its valu= e > matches the value of the Origin-Host AVP of the received messag= e > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > =20 > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > _______________________________________________ > 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 lionel.morand@orange.com Mon Feb 10 05:25:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3475F1A082D for ; Mon, 10 Feb 2014 05:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2Z8KNkFBc4S for ; Mon, 10 Feb 2014 05:25:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AD8B61A05FD for ; Mon, 10 Feb 2014 05:25:27 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BE5A222C1EE; Mon, 10 Feb 2014 14:25:26 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0589927C0A2; Mon, 10 Feb 2014 14:24:49 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 14:24:48 +0100 From: To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIcx3K95DWDMaH0qQEyVc/ebDNpqmsICAgAAE6ICAABUugIACvZWAgAAwCoCAADL/AIAEjBxAgAAJU7A= Date: Mon, 10 Feb 2014 13:24:48 +0000 Message-ID: <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 13:25:33 -0000 I disagree and my proposal was somehow misunderstood. I don't see the issue to have the following sequence: - If the reacting node has received an indication only for Realm traffic Re= duction, apply Realm reduction is for any message, with Destination-Realm a= nd with/without Destination-Host - If the reacting node has received an indication only for host traffic red= uction, apply host reduction for messages containing a Destination-Host. No= reduction for messages with only a Destination-Realm. - If the reacting node has received both an indication for host traffic and= for realm traffic reduction, only the realm reduction will apply for messa= ges with only the Destination-Realm AVP and only the host reduction will ap= ply for messages with the Destination-Host AVP (and the Destination-Realm A= VP). In other words, as said earlier, the Host reduction prevails over realm red= uction when the overloaded host is inside an overloaded realm and the react= ing has received info about both type of overload. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: lundi 10 f=E9vrier 2014 13:56 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Dear all I share Ulrich and MCruz views, - Host OLR based control applies to requests where Destination Host is know= n=20 - Realm OLR based control applies to requests where Destination Host is not= known (only the Destination realm). I think it is simple, otherwise as MCruz indicated it complicates; e.g abou= t the Ulrich's example where the Host S1 is not overloaded but the realm is= overloaded. the client will not receive Host OLR reports from host S1 (so = no explicit traffic reduction requested by S1), but according to Lionel com= ment, I understand client will have to throttle the requests sent to S1 ac= cording to realm OLR, so how to avoid this. JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 17:15 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Dear all, I am in favor of the proposal made by Ulrich in the sequence diagram he pro= vided. ---- As a summary: Consequently the reacting node will receive realm type OLRs from the agent = and host type OLRs from the servers. The received realm type OLR will be relevant for the reacting node when sen= ding/throttling realm type requests; the received host type OLR will be rel= evant for the reacting node when sending/throttling host type request= s. ----- It may occur though, that a Client has only received Realm type OLR, and th= en it has to send a request to one specific host, then the Client will not = apply any restriction, but as soon as the response is received back, Client= will update Host type OLR. Same will apply when only Host type OLR has be= en received by Client. The alternative will be to always send back from an Agent both Host OLR plu= s Realm OLR, but I do not think this is necessary and may complicate the so= lution. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: viernes, 07 de febrero de 2014 14:13 To: ext Jouni Korhonen Cc: dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 07, 2014 11:21 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > I better like Lionel's approach, but even that is not ok in the unlikely = extreme case where we have two servers in a realm, S1 is not overloaded at = all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh= ould a client do a 25% throttling when sending host type requests to the no= t at all overloaded S1? > What is wrong with letting the client > -not throttle host-type requests to S1, > -throttle host type request to S2 with 50% and > -throttle realm type requests wit 25%? Isn't this what Lionel said below? no it is not I am OK with Lionel's "wording" here. - Jouni >=20=20 >=20=20 >=20=20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@= orange.com > Sent: Wednesday, February 05, 2014 4:14 PM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >=20=20 > I tend to agree except that I would reverse the logic as for the routing = principles: the Destination-host takes precedence when present over Destina= tion-Realm. So the realm abatement is applied in any case except if there i= s an explicit report for the destination-host. >=20=20 > Lioenl >=20=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >=20=20 > It makes more sense to me for a realm report to apply to all requests tar= geted for that realm, independent the type of request. This implies that i= t would apply to requests that also have a Destination-Host specified. >=20 > If this is the definition of a realm report then we need to specify the i= nteraction between realm reports and host reports. >=20 > I propose that throttling would occur on the realm first and the host sec= ond. If a message targetted for the host is throttled as a result of realm= overload then that throttled message would count as part of the reduction = needed to address the host overload. Messages to the host that survive rea= lm abatement would then be candidates for host overload. >=20 > Steve >=20 > On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: > The case "Realm" as described below raises another question: is it prohib= ited for a realm to only rely on a global overload report for the whole rea= lm, whatever the nodes inside this realm? > If not, only OLR with the report type "realm" would be received by the re= acting node. And the reduction indicated in the OLR will apply always for t= he realm, whatever the presence of Destination-host AVP in the request... e= xcept if an explicit report with the type "Host" as been received for this = destination-host. >=20=20 > Does it make sense? >=20=20 > Lionel >=20=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #34: Semantics of OC-Report-Type AVP >=20=20 > #34: Semantics of OC-Report-Type AVP >=20=20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: >=20=20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. >=20=20 >=20=20 >=20=20 > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > _______________________________________________ > 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From lionel.morand@orange.com Mon Feb 10 05:47:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C78F1A02C9 for ; Mon, 10 Feb 2014 05:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZTDFwJcPqQS for ; Mon, 10 Feb 2014 05:47:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 95DD41A0835 for ; Mon, 10 Feb 2014 05:47:49 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4033D22C551; Mon, 10 Feb 2014 14:47:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1A9D927C087; Mon, 10 Feb 2014 14:47:49 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 14:47:48 +0100 From: To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR Thread-Index: AQHPJLlGaYcs5B7+bkSRJFt4wCbOs5quglmQ Date: Mon, 10 Feb 2014 13:47:47 +0000 Message-ID: <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> In-Reply-To: <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 13:47:53 -0000 I would add, maybe even before the format (NTP time based), that the real r= equirements for the sequence-number are: - Globally/eternally unique - increase monotonically over time, including over a reboot (as remind by S= teve)=20 The NTP time based type is just a guidance provided by the draft on how to = generate sequence numbers with such properties. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: samedi 8 f=E9vrier 2014 11:33 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich) Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O= C-OLR Sounds acceptable. Would the following then work for all: o clarify that once the overload report expires there is no reason to remember anything about it o the sequence number would be similar to session-id.. based=20 on the NTP time + any vendor specific data to make it=20 "globally and eternally unique". - Jouni On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Steve, >=20=20 > sounds like an acceptable proposal which allows to come back to sync afte= r OLR expiry. > This requires however an update of clause 5.5.2 to clearly state > Once the overload report expires there is no reason to remember anything = about it and the next overload report received could, conceivably have any = value.=20 >=20 >=20=20 > Ulrich >=20=20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Thursday, February 06, 2014 4:50 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within = OC-OLR >=20=20 > A couple of things -=20 >=20 > The requirement is that the sequence number increase monotonically over t= ime, including over a reboot. Use of NTP time is one way of doing this but= is not the only way. Someone could, for instance, use a time stamp to set= the sequence number for the first overload report sent after a reboot and = then increment the sequence number value by one for each subsequent overloa= d report sent. This actually has better properties than an NTP time stamp = as it would take much longer to roll over. One could also create a global = sequence number service that is not tied to time and have a Diameter server= query that global sequence number server after each reboot. >=20 > We also have a duration timer on overload reports. This gives us one way= to reset. It should only be required to remember the sequence number of a= n active overload report. Once the overload report expires there is no rea= son to remember anything about it and the next overload report received cou= ld, conceivably have any value.=20 >=20 > The requirement we need is similar to the session-id in the base Diameter= specification. The wording there is -- "The Session-Id MUST be globally a= nd eternally unique". We just need eternally as the spacial differentiatio= n is based on the context of the message carrying the overload report. >=20 > It would be perfectly valid for the DOIC draft to suggest the use of NTP = timestamps to populate the sequence number but it should be worded in a sim= ilar fashion as the Diameter base RFC -- The Session-Id includes a mandator= y portion and an implementation-defined portion; a recommended format for t= he implementation-defined portion is outlined below ..." >=20 > Steve >=20 > On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > I cannot understand what is the problem with mandating timestamp. > But I can see interoperability problems with the current definition: >=20=20 > Assume the sender sends sequence numbers > 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3, ... 3, 4, 4, ... 4, 5,....=20 > but the receicer for any reason receives=20 > 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3, ... 3, 4, 4, ... 4, 5,....=20 > The receiver would accept > 1, 1, ... 1, 2, 2, ... 2, 3, 30000 > and then silently discards > 3, ... 3, 4, 4, ... 4, 5,.... 4, 5, ....=20 > with no way to come back to sync. >=20=20 > Are we sure that this cannot happen? >=20=20 > Mandating timestamp for sequence number generation at the sender and plau= sibility checking (i.e. received value must be between stored value and tim= e of reception) for the receiver may not be the only way to solve the probl= em. But in the moment I don't see another way. >=20=20 > Ulrich >=20=20 >=20=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell > Sent: Wednesday, February 05, 2014 4:57 PM > To: ext lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within = OC-OLR >=20=20 > My point is, we have an interop requirement that the sequence number alwa= ys increases over time scope. We do not have the interop requirement that t= he sequence number be implemented as a time stamp. A time stamp is probably= a good way to meet the interop requirements, but it is not, in itself, an= interop requirement. >=20=20 > On Feb 5, 2014, at 9:53 AM, wrote: >=20=20 > Not sure to understand: if there is a kind of "interop requirement", it i= s a case for a "MUST". > We are not violating anything. >=20=20 > Reporting and reacting nodes will just rely on the Diameter interfaces to= know how to handle the received sequence-number. So any MUST on the format= of the sequence-number is acceptable if it avoids interop issues. >=20=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47 > =C0 : MORAND Lionel IMT/OLN > Cc : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O= C-OLR >=20=20 > I concur with Steve on this one. Using a time stamp is a good way to meet= the requirements, but it's not our job to normatively state an implementat= ion. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Se= ction 6 of 2119 includes the following: >=20=20 > "In particular, [normative requirements] MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) " >=20=20 > The only appropriate reason to require a timestamp would be if we expecte= d peers to interpret the field as a point in time. OTOH, it would be perfec= tly reasonable to state the actual interop requirements, then add a non-nor= mative (probably indented) paragraph suggesting that a timestamp is a good = way to do this. >=20=20 > On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: >=20=20 > I think the out-of-sync failover described by Ulrich is a good use case t= o mandate a specific semantic. >=20=20 > Is there any specific NOT to mandate the use of NTP timestamps if it is a= simple way to solve the possible issues and please everyone? >=20=20 > Lionel >=20=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O= C-OLR >=20=20 > How the sequence number is implemented is an implementation decision. Th= ere is no reason to mandate that is be an NTP timestamp. That should be in= cluded only as one way of addressing the requirement. >=20=20 > Steve >=20=20 > On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: > I also agree. >=20=20 > Regards, > Nirav. >=20=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@oran= ge.com > Sent: Tuesday, February 04, 2014 11:50 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within = OC-OLR >=20=20 > The existing wording seems actually fuzzy. > If it is "like an NTP timestamp", be proud and say it loud! >=20=20 > In summary: ok with the proposal if it clarifies this handling of this se= quence-number. >=20=20 > Lionel >=20=20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] > Envoy=E9 : mardi 4 f=E9vrier 2014 09:50 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >=20=20 > #32: Sequence-Number Time-Stamp values within OC-OLR >=20=20 > The -01 draft says in clause 4.4: > From the functionality point of view, the OC-Sequence-Number AVP MUST > be used as a non-volatile increasing counter between two overload > control endpoints (neglecting the fact that the contents of the AVP > is a 64-bit NTP timestamp [RFC5905]). The sequence number is only > required to be unique between two overload control endpoints. > Sequence numbers are treated in uni-directional manner, i.e. two > sequence numbers on each direction between two endpoints are not > related or correlated. >=20=20 > When generating sequence numbers, the new sequence number MUST be > greater than any sequence number previously seen between two > endpoints within a time window that tolerates the wraparound of the > NTP timestamp (i.e. approximately 68 years). >=20=20 >=20=20 > With this mechanism it is difficult to get back to sync once you are out = of sync (for whatever reason). > It is proposed to mandate that the Sequence Number is a real 64-bit NTP = timestamp (RFC5905) indicating the point in time when the OLR was created, = and to mandate that OLRs with a time stamp higher than time of reception = must be ignored by the reacting node. >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20=20 > _______________________________________________ > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From srdonovan@usdonovans.com Mon Feb 10 05:58:44 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040591A0843 for ; Mon, 10 Feb 2014 05:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmQKoA-W-WjM for ; Mon, 10 Feb 2014 05:58:40 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBD71A02C9 for ; Mon, 10 Feb 2014 05:58:40 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57319 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCrMX-0004Z3-V6 for dime@ietf.org; Mon, 10 Feb 2014 05:57:33 -0800 Message-ID: <52F8DB0C.3000603@usdonovans.com> Date: Mon, 10 Feb 2014 07:58:36 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dime@ietf.org References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------080907050901030809020508" X-OutGoing-Spam-Status: No, score=-2.9 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 Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 13:58:44 -0000 This is a multi-part message in MIME format. --------------080907050901030809020508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit +1 On 2/10/14 7:47 AM, lionel.morand@orange.com wrote: > I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are: > > - Globally/eternally unique > - increase monotonically over time, including over a reboot (as remind by Steve) > > The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen > Envoyé : samedi 8 février 2014 11:33 > À : Wiehe, Ulrich (NSN - DE/Munich) > Cc : dime@ietf.org > Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR > > > Sounds acceptable. Would the following then work for all: > > o clarify that once the overload report expires there is no > reason to remember anything about it > o the sequence number would be similar to session-id.. based > on the NTP time + any vendor specific data to make it > "globally and eternally unique". > > - Jouni > > > > On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> Steve, >> >> sounds like an acceptable proposal which allows to come back to sync after OLR expiry. >> This requires however an update of clause 5.5.2 to clearly state >> Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. >> >> >> Ulrich >> >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Thursday, February 06, 2014 4:50 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> A couple of things - >> >> The requirement is that the sequence number increase monotonically over time, including over a reboot. Use of NTP time is one way of doing this but is not the only way. Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent. This actually has better properties than an NTP time stamp as it would take much longer to roll over. One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot. >> >> We also have a duration timer on overload reports. This gives us one way to reset. It should only be required to remember the sequence number of an active overload report. Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. >> >> The requirement we need is similar to the session-id in the base Diameter specification. The wording there is -- "The Session-Id MUST be globally and eternally unique". We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report. >> >> It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..." >> >> Steve >> >> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> I cannot understand what is the problem with mandating timestamp. >> But I can see interoperability problems with the current definition: >> >> Assume the sender sends sequence numbers >> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3, ... 3, 4, 4, ... 4, 5,.... >> but the receicer for any reason receives >> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3, ... 3, 4, 4, ... 4, 5,.... >> The receiver would accept >> 1, 1, ... 1, 2, 2, ... 2, 3, 30000 >> and then silently discards >> 3, ... 3, 4, 4, ... 4, 5,.... 4, 5, .... >> with no way to come back to sync. >> >> Are we sure that this cannot happen? >> >> Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way. >> >> Ulrich >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell >> Sent: Wednesday, February 05, 2014 4:57 PM >> To: ext lionel.morand@orange.com >> Cc: dime@ietf.org >> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to meet the interop requirements, but it is not, in itself, an interop requirement. >> >> On Feb 5, 2014, at 9:53 AM, wrote: >> >> Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST". >> We are not violating anything. >> >> Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues. >> >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@nostrum.com] >> Envoyé : mercredi 5 février 2014 16:47 >> À : MORAND Lionel IMT/OLN >> Cc : Steve Donovan; dime@ietf.org >> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following: >> >> "In particular, [normative requirements] MUST only be used where it is >> actually required for interoperation or to limit behavior which has >> potential for causing harm (e.g., limiting retransmisssions) " >> >> The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this. >> >> On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote: >> >> I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic. >> >> Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone? >> >> Lionel >> >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoyé : mercredi 5 février 2014 15:34 >> À : dime@ietf.org >> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> How the sequence number is implemented is an implementation decision. There is no reason to mandate that is be an NTP timestamp. That should be included only as one way of addressing the requirement. >> >> Steve >> >> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: >> I also agree. >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com >> Sent: Tuesday, February 04, 2014 11:50 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> The existing wording seems actually fuzzy. >> If it is "like an NTP timestamp", be proud and say it loud! >> >> In summary: ok with the proposal if it clarifies this handling of this sequence-number. >> >> Lionel >> >> -----Message d'origine----- >> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] >> Envoyé : mardi 4 février 2014 09:50 >> À : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org >> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> #32: Sequence-Number Time-Stamp values within OC-OLR >> >> The -01 draft says in clause 4.4: >> From the functionality point of view, the OC-Sequence-Number AVP MUST >> be used as a non-volatile increasing counter between two overload >> control endpoints (neglecting the fact that the contents of the AVP >> is a 64-bit NTP timestamp [RFC5905]). The sequence number is only >> required to be unique between two overload control endpoints. >> Sequence numbers are treated in uni-directional manner, i.e. two >> sequence numbers on each direction between two endpoints are not >> related or correlated. >> >> When generating sequence numbers, the new sequence number MUST be >> greater than any sequence number previously seen between two >> endpoints within a time window that tolerates the wraparound of the >> NTP timestamp (i.e. approximately 68 years). >> >> >> With this mechanism it is difficult to get back to sync once you are out of sync (for whatever reason). >> It is proposed to mandate that the Sequence Number is a real 64-bit NTP timestamp (RFC5905) indicating the point in time when the OLR was created, and to mandate that OLRs with a time stamp higher than time of reception must be ignored by the reacting node. >> >> >> _________________________________________________________________________________________________________________________ >> >> 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. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> >> _________________________________________________________________________________________________________________________ >> >> 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. >> >> _______________________________________________ >> 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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------080907050901030809020508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1
On 2/10/14 7:47 AM, lionel.morand@orange.com wrote:
I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are:

- Globally/eternally unique
- increase monotonically over time, including over a reboot (as remind by Steve) 

The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoyé : samedi 8 février 2014 11:33
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


Sounds acceptable. Would the following then work for all:

o clarify that once the overload report expires there is no
  reason to remember anything about it
o the sequence number would be similar to session-id.. based 
  on the NTP time + any vendor specific data to make it 
  "globally and eternally unique".

- Jouni



On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:


Steve,
 
sounds like an acceptable proposal which allows to come back to sync after OLR expiry.
This requires however an update of clause 5.5.2 to clearly state
Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 

 
Ulrich
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 06, 2014 4:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
A couple of things - 

The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.

We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 

The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.

It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."

Steve

On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
I cannot understand what is the problem with mandating timestamp.
But I can see interoperability problems with the current definition:
 
Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.
 
Are we sure that this cannot happen?
 
Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.
 
Ulrich
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, February 05, 2014 4:57 PM
To: ext lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.
 
On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:
 
Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
We are not violating anything.
 
Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] 
Envoyé : mercredi 5 février 2014 16:47
À : MORAND Lionel IMT/OLN
Cc : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:
 
"In particular, [normative requirements] MUST only be used where it is
  actually required for interoperation or to limit behavior which has
  potential for causing harm (e.g., limiting retransmisssions)  "
 
The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.
 
On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
 
I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.
 
Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:34
À : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.
 
Steve
 
On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
I also agree.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 11:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
The existing wording seems actually fuzzy.
If it is "like an NTP timestamp", be proud and say it loud!
 
In summary: ok with the proposal if it clarifies this handling of this sequence-number.
 
Lionel
 
-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:50
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
#32: Sequence-Number Time-Stamp values within OC-OLR
 
The -01 draft says in clause 4.4:
   From the functionality point of view, the OC-Sequence-Number AVP MUST
   be used as a non-volatile increasing counter between two overload
   control endpoints (neglecting the fact that the contents of the AVP
   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
   required to be unique between two overload control endpoints.
   Sequence numbers are treated in uni-directional manner, i.e. two
   sequence numbers on each direction between two endpoints are not
   related or correlated.
 
   When generating sequence numbers, the new sequence number MUST be
   greater than any sequence number previously seen between two
   endpoints within a time window that tolerates the wraparound of the
   NTP timestamp (i.e. approximately 68 years).
 
 
With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.
 
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
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

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

_________________________________________________________________________________________________________________________

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.

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

--------------080907050901030809020508-- From jean-jacques.trottin@alcatel-lucent.com Mon Feb 10 06:00:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DC01A02C9 for ; Mon, 10 Feb 2014 06:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16MSoVxa1R4W for ; Mon, 10 Feb 2014 06:00:16 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id BB9211A02CE for ; Mon, 10 Feb 2014 06:00:16 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1AE0CUl009826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Feb 2014 08:00:16 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AE06kW027341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Feb 2014 15:00:11 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 15:00:10 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Thread-Index: AQHPIcx34wrZRRvx1EKFdFq4TjstmpqmsICAgAAE6ICAABUugIACvZWAgAAwCoCAADL/AIAEjBxA///7RACAABhCgA== Date: Mon, 10 Feb 2014 14:00:09 +0000 Message-ID: References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se> <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.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: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 14:00:20 -0000 Hi Lionel=20 Please see in line -----Message d'origine----- De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Envoy=E9=A0: lundi 10 f=E9vrier 2014 14:25 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet=A0: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP I disagree and my proposal was somehow misunderstood. I don't see the issue to have the following sequence: - If the reacting node has received an indication only for Realm traffic Re= duction, apply Realm reduction is for any message, with Destination-Realm a= nd with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; = coming back to Ulrich example, Host S1 is not overloaded, so reacting node = has not received Host reduction OLR for S1. But as there is a realm reduct= ion, reacting node will reduce traffic with destination Host S1. =20 - If the reacting node has received an indication only for host traffic red= uction, apply host reduction for messages containing a Destination-Host. No= reduction for messages with only a Destination-Realm. [JJ] OK =20 - If the reacting node has received both an indication for host traffic and= for realm traffic reduction, only the realm reduction will apply for messa= ges with only the Destination-Realm AVP and only the host reduction will ap= ply for messages with the Destination-Host AVP (and the Destination-Realm A= VP). [JJ] OK, Host reduction prevails In other words, as said earlier, the Host reduction prevails over realm red= uction when the overloaded host is inside an overloaded realm and the react= ing has received info about both type of overload. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: lundi 10 f=E9vrier 2014 13:56 =C0=A0: dime@= ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Dear all I share Ulrich and MCruz views, - Host OLR based control applies to requests where Destination Host is know= n - Realm OLR based control applies to requests where Destination Host is not= known (only the Destination realm). I think it is simple, otherwise as MCruz indicated it complicates; e.g abou= t the Ulrich's example where the Host S1 is not overloaded but the realm is= overloaded. the client will not receive Host OLR reports from host S1 (so = no explicit traffic reduction requested by S1), but according to Lionel com= ment, I understand client will have to throttle the requests sent to S1 ac= cording to realm OLR, so how to avoid this. JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 17:15 =C0=A0: dime@ietf.org Objet= =A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP Dear all, I am in favor of the proposal made by Ulrich in the sequence diagram he pro= vided. ---- As a summary: Consequently the reacting node will receive realm type OLRs from the agent = and host type OLRs from the servers. The received realm type OLR will be relevant for the reacting node when sen= ding/throttling realm type requests; the received host type OLR will be rel= evant for the reacting node when sending/throttling host type request= s. ----- It may occur though, that a Client has only received Realm type OLR, and th= en it has to send a request to one specific host, then the Client will not = apply any restriction, but as soon as the response is received back, Client= will update Host type OLR. Same will apply when only Host type OLR has be= en received by Client. The alternative will be to always send back from an Agent both Host OLR plu= s Realm OLR, but I do not think this is necessary and may complicate the so= lution. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: viernes, 07 de febrero de 2014 14:13 To: ext Jouni Korhonen Cc: dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] Sent: Friday, February 07, 2014 11:21 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > I better like Lionel's approach, but even that is not ok in the unlikely = extreme case where we have two servers in a realm, S1 is not overloaded at = all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh= ould a client do a 25% throttling when sending host type requests to the no= t at all overloaded S1? > What is wrong with letting the client > -not throttle host-type requests to S1, > -throttle host type request to S2 with 50% and > -throttle realm type requests wit 25%? Isn't this what Lionel said below? no it is not I am OK with Lionel's "wording" here. - Jouni > =20 > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@= orange.com > Sent: Wednesday, February 05, 2014 4:14 PM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > I tend to agree except that I would reverse the logic as for the routing = principles: the Destination-host takes precedence when present over Destina= tion-Realm. So the realm abatement is applied in any case except if there i= s an explicit report for the destination-host. > =20 > Lioenl > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 > =C0 : dime@ietf.org > Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > =20 > It makes more sense to me for a realm report to apply to all requests tar= geted for that realm, independent the type of request. This implies that i= t would apply to requests that also have a Destination-Host specified. >=20 > If this is the definition of a realm report then we need to specify the i= nteraction between realm reports and host reports. >=20 > I propose that throttling would occur on the realm first and the host sec= ond. If a message targetted for the host is throttled as a result of realm= overload then that throttled message would count as part of the reduction = needed to address the host overload. Messages to the host that survive rea= lm abatement would then be candidates for host overload. >=20 > Steve >=20 > On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: > The case "Realm" as described below raises another question: is it prohib= ited for a realm to only rely on a global overload report for the whole rea= lm, whatever the nodes inside this realm? > If not, only OLR with the report type "realm" would be received by the re= acting node. And the reduction indicated in the OLR will apply always for t= he realm, whatever the presence of Destination-host AVP in the request... e= xcept if an explicit report with the type "Host" as been received for this = destination-host. > =20 > Does it make sense? > =20 > Lionel > =20 > -----Message d'origine----- > De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20 > Envoy=E9 : mardi 4 f=E9vrier 2014 09:55 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : [dime] #34: Semantics of OC-Report-Type AVP > =20 > #34: Semantics of OC-Report-Type AVP > =20 > Text in clause 4.6 does not fully explain to which requests overload > treatment of a given report type applies. > Proposal: > =20 > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > a) The Destination-Host AVP is present in the request and its valu= e > matches the value of the Origin-Host AVP of the received messag= e > that contained the OC-OLR AVP. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > =20 > 1 A realm report. The overload treatment should apply to > requests for which all of the following conditions are true: > a) The Destination-Host AVP is absent in the request. > b) The value of the Destination-Realm AVP in the request matches t= he > value of the Origin-Realm AVP of the received message > that contained the OC-OLR AVP. > c) The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > =20 > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > _______________________________________________ > 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From srdonovan@usdonovans.com Mon Feb 10 06:39:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255641A0307 for ; Mon, 10 Feb 2014 06:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MWRI3Dqk9cu for ; Mon, 10 Feb 2014 06:39:25 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id C0F421A0845 for ; Mon, 10 Feb 2014 06:39:25 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57384 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCrzv-00088m-2p; Mon, 10 Feb 2014 06:38:17 -0800 Message-ID: <52F8E495.8010404@usdonovans.com> Date: Mon, 10 Feb 2014 08:39:17 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------000506070801010902020600" X-OutGoing-Spam-Status: No, score=-2.9 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 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 14:39:29 -0000 This is a multi-part message in MIME format. --------------000506070801010902020600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I think we have agreement that a realm report applies to all traffic targeted for that realm, independent of the presence or absence of the destination-host avp. Is that correct? I don't agree with Lionel's proposal. The realm overload report should take precedence over the host overload report. My reasoning is as follows: - There is something responsible for tracking the health of the realm. Call it the "realm overload authority". The health of the realm can be based on a number of factors including the health of individual servers, individual agents and the network connecting Diameter entities. - When this "realm overload authority" determines that the IP network is congested, for instance, it would instruct agents or servers to send realm overload reports with the expectation that the overall traffic sent to the realm as a whole will be reduced. In this scenario, the fact that the realm is overloaded takes precedence over the health of the servers. As such, it is likely that requests targeted for a healthy server will be throttled. I propose the logic should be as follows: For all requests: If there is a realm overload report that applies to the request: Apply realm based trottling logic to that request If there is a host overload report that applies to the request: Apply host based throttling logic to that request Note that this also requires the ability to put realm overload reports in any answer message, not just answers to requests that did not contain a destination-host AVP. Steve On 2/10/14 5:30 AM, lionel.morand@orange.com wrote: > No it was not my intention and it is why it was written "except" :) > > The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied. > > Is it clearer? > > Lioenl > > -----Message d'origine----- > De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Envoyé : dimanche 9 février 2014 13:46 > À : Wiehe, Ulrich (NSN - DE/Munich) > Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org > Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP > > > On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Friday, February 07, 2014 11:21 AM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >> >> >> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> >>> I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1? >>> What is wrong with letting the client >>> -not throttle host-type requests to S1, >>> -throttle host type request to S2 with 50% and >>> -throttle realm type requests wit 25%? >> Isn't this what Lionel said below? >> no it is not > > Ok, maybe I misread the "realm abatement is applied in any case > except if there is an explicit report for the destination-host"? > > If this means the realm abatement is still applied after applying > the host abatement, then I agree it is not the same you said. > > - Jouni > > >> I am OK with Lionel's >> "wording" here. >> >> - Jouni >> >>> >>> >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com >>> Sent: Wednesday, February 05, 2014 4:14 PM >>> To: Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >>> >>> I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host. >>> >>> Lioenl >>> >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>> Envoyé : mercredi 5 février 2014 15:56 >>> À : dime@ietf.org >>> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP >>> >>> It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request. This implies that it would apply to requests that also have a Destination-Host specified. >>> >>> If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports. >>> >>> I propose that throttling would occur on the realm first and the host second. If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload. Messages to the host that survive realm abatement would then be candidates for host overload. >>> >>> Steve >>> >>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote: >>> The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm? >>> If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host. >>> >>> Does it make sense? >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] >>> Envoyé : mardi 4 février 2014 09:55 >>> À : MORAND Lionel IMT/OLN >>> Cc : dime@ietf.org >>> Objet : [dime] #34: Semantics of OC-Report-Type AVP >>> >>> #34: Semantics of OC-Report-Type AVP >>> >>> Text in clause 4.6 does not fully explain to which requests overload >>> treatment of a given report type applies. >>> Proposal: >>> >>> 0 A host report. The overload treatment should apply to requests >>> for which all of the following conditions are true: >>> a) The Destination-Host AVP is present in the request and its value >>> matches the value of the Origin-Host AVP of the received message >>> that contained the OC-OLR AVP. >>> b) The value of the Destination-Realm AVP in the request matches the >>> value of the Origin-Realm AVP of the received message >>> that contained the OC-OLR AVP. >>> c) The value of the Application-ID in the Diameter Header of the >>> request matches the value of the Application-ID of the Diameter >>> Header of the received message that contained the OC-OLR AVP. >>> >>> >>> >>> 1 A realm report. The overload treatment should apply to >>> requests for which all of the following conditions are true: >>> a) The Destination-Host AVP is absent in the request. >>> b) The value of the Destination-Realm AVP in the request matches the >>> value of the Origin-Realm AVP of the received message >>> that contained the OC-OLR AVP. >>> c) The value of the Application-ID in the Diameter Header of the >>> request matches the value of the Application-ID of the Diameter >>> Header of the received message that contained the OC-OLR AVP. >>> >>> >>> _________________________________________________________________________________________________________________________ >>> >>> 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. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > 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. > > --------------000506070801010902020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think we have agreement that a realm report applies to all traffic targeted for that realm, independent of the presence or absence of the destination-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should take precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Call it the "realm overload authority".  The health of the realm can be based on a number of factors including the health of individual servers, individual agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is congested, for instance, it would instruct agents or servers to send realm overload reports with the expectation that the overall traffic sent to the realm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence over the health of the servers.  As such, it is likely that requests targeted for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in any answer message, not just answers to requests that did not contain a destination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:
No it was not my intention and it is why it was written "except" :)

The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.

Is it clearer?

Lioenl 

-----Message d'origine-----
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Envoyé : dimanche 9 février 2014 13:46
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:


I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
What is wrong with letting the client
-not throttle host-type requests to S1,
-throttle host type request to S2 with 50% and
-throttle realm type requests wit 25%?

Isn't this what Lionel said below?
<Ulrich> no it is not</Ulrich>


Ok, maybe I misread the "realm abatement is applied in any case
except if there is an explicit report for the destination-host"?

If this means the realm abatement is still applied after applying
the host abatement, then I agree it is not the same you said.

- Jouni



I am OK with Lionel's
"wording" here.

- Jouni




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com
Sent: Wednesday, February 05, 2014 4:14 PM
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

Lioenl

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:56
À : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

Steve

On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

Does it make sense?

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
Envoyé : mardi 4 février 2014 09:55
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #34: Semantics of OC-Report-Type AVP

#34: Semantics of OC-Report-Type AVP

Text in clause 4.6  does not fully explain to which requests overload
treatment of a given report type applies.
Proposal:

   0  A host report.  The overload treatment should apply to requests
      for which all of the following conditions are true:
      a) The Destination-Host AVP is present in the request and its value
         matches the value of the Origin-Host AVP of the received message
         that contained the OC-OLR AVP.
      b) The value of the Destination-Realm AVP in the request matches the
         value of the Origin-Realm AVP of the received message
         that contained the OC-OLR AVP.
      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.



   1  A realm report.  The overload treatment should apply to
      requests for which all of the following conditions are true:
      a) The Destination-Host AVP is absent in the request.
      b) The value of the Destination-Realm AVP in the request matches the
         value of the Origin-Realm AVP of the received message
         that contained the OC-OLR AVP.
      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.


_________________________________________________________________________________________________________________________

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.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


      

      

_________________________________________________________________________________________________________________________

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.




    

    

  


--------------000506070801010902020600--

From srdonovan@usdonovans.com  Mon Feb 10 06:43:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5FF1A0814 for ; Mon, 10 Feb 2014 06:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 IjByEpbPKk76 for ; Mon, 10 Feb 2014 06:43:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB3A1A02E1 for ; Mon, 10 Feb 2014 06:43:52 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57396 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCs4K-0004oq-DE for dime@ietf.org; Mon, 10 Feb 2014 06:42:45 -0800
Message-ID: <52F8E5A7.6030902@usdonovans.com>
Date: Mon, 10 Feb 2014 08:43:51 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 14:43:53 -0000

>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
> No need for this since we agreed that DOIC implicitly always refers 
> to the application on which the DOIC AVPs are carried in.
> yes, we agreed on that, so c) is correct and it does not harm to keep c)
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way
for the application-id
in the answer message to be different than the application-id in the
request message without
breaking Diameter.


From srdonovan@usdonovans.com  Mon Feb 10 07:07:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5001A0886 for ; Mon, 10 Feb 2014 07:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.919
X-Spam-Level: 
X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAt_5bDK7eZ6 for ; Mon, 10 Feb 2014 07:07:37 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id DD5251A0877 for ; Mon, 10 Feb 2014 07:07:36 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57436 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCsRH-0002Lw-Pv for dime@ietf.org; Mon, 10 Feb 2014 07:06:29 -0800
Message-ID: <52F8EB36.9050501@usdonovans.com>
Date: Mon, 10 Feb 2014 09:07:34 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------030801040003040208050301"
X-OutGoing-Spam-Status: No, score=-1.9
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
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 15:07:45 -0000

This is a multi-part message in MIME format.
--------------030801040003040208050301
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I'll attempt to summarize where we are on this.  If this is agreed to
then the necessary changes would be made to the -01 draft.  Some of this
is already in the draft, some of it will require changes.

- The draft already makes it optional for the reporting node to include
the OC-Supported-Features AVP in answer messages - No change required here.

- A reporting node must choose the overload abatement algorithm to be
sent to a reacting node from the set of abatement algorithms included in
the OC-Supported-Features AVP received in the request message.

- If the reporting node sends an OC-OLR AVP and there is no
OC-Supported-Features AVP then the abatement algorithm used by the
reacting node must be loss.

- The reporting node may include the OC-Supported-Features AVP with the
loss algorithm indicated in the OC-Feature-Vector AVP.

- If the reporting node wants the reacting node to apply an algorithm
other then loss, the reacting node must include the
OC-Supported-Features AVP with a single algorithm indicated in the
OC-Feature-Vector AVP.

- New abatement algorithm extensions may use and extend the existing
OC-OLR AVP.  The new algorithms may also create a new overload report
AVP if that makes the most sense.

- The loss algorithm is and always will be the mandatory to implement
algorithm.  Or it will be until a new RFC is published that changes the
mandatory to implement algorithm.

Steve

On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:
>
> -----Message d'origine-----
> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Envoyé : lundi 10 février 2014 12:24
> À : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
>
> On Feb 10, 2014, at 1:15 PM,  wrote:
>
>> Hi Jouni,
>>
>>> As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.
>> Bah. OLR should work for additional abatement algorithms
>> IF we agree that the OLR is align with the announced
>> abatement algorithm.. 
>>
>> [LM] The issue if when you have more than one algo (let say 2). There is no way for the reporting node to indicate the algo to use with the OLR sent in the answer using the OC-Feature-Vector. The only info that you could have is "use either one or the other".
> This we can fix (and I personally would like to fix). The reporting node
> announces in its OC-Feature-Vector the selected common algorithm for the
> sent OLR. We had this at some point of time, btw.
>
> [LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY be used (when present) to indicate the algo to use, algo part of the common algos between the reporting node and the reacting node.
>
>> The simpliest way would be to define a new AVP when you want to support more than the default algo. If you want to rely on the same OLR with another algo, you should have a way to indicate the algo to use with the given OLR.
> I recall there was a strong arguments against algorithm types in OLRs..
>
> [LM] I was not proposing such idea :)
>
> - Jouni
>
>>
>>> It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.
>> It is already today if you only support the default, right.
>>
>> [LM] Right. No issue here.
>>
>> -----Message d'origine-----
>> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>> Envoyé : vendredi 7 février 2014 11:04
>> À : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>>
>>
>> On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:
>>
>>> I think that there is actually an issue here but the proposed way to solve it is not the correct one.
>> Agree.
>>
>>> The initial idea was to be able to use the same overload report with several algorithms. So the OLR was somehow only meaningful along with the OC-Feature-Vector AVP.
>> The initial idea was to go on lines of RFC5447.
>>
>>> But because the OC-Feature-Vector AVP is defined as a set of flags, it is not possible to say that this OLR is to be used with only one given algo when more than one is defined (as the bit flags will advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to indicate the abatement to perform.
>> My intention was always allow:
>>
>>  client announces  ABC
>>  server supports    BCD
>>  server announced only  e.g. C since it is common
>>  alternatively server announced nothing and then the default applies
>>
>>> As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.
>> Bah. OLR should work for additional abatement algorithms
>> IF we agree that the OLR is align with the announced
>> abatement algorithm.. 
>>
>>> It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.
>> It is already today if you only support the default, right.
>>
>> - Jouni
>>
>>> Lionel 
>>>
>>> -----Message d'origine-----
>>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
>>> Envoyé : mardi 4 février 2014 09:48
>>> À : MORAND Lionel IMT/OLN
>>> Cc : dime@ietf.org
>>> Objet : [dime] #30: OC-Supported-Features AVP in answer messages
>>>
>>> #30: OC-Supported-Features AVP in answer messages
>>>
>>> According to the current feature advertisement/negotiation mechanism in
>>> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP
>>> in answer messages to indicate their supported OC features to the reacting
>>> DOIC endpoint.
>>> The author of this document believes that  the best a reacting node can do
>>> with such information is to ignore it, and therefore proposes to allow
>>> reporting nodes not to insert OC-Supported-Features AVPs in answer
>>> messages.
>>> Currently only one feature is defined (OLR_DEFAULT_ALGO).
>>> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other
>>> feature is only interested in receiving/not receiving OC-OLR AVPs from
>>> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
>>> support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving
>>> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:
>>>
>>> a) There is no overload
>>> b) DOIC is not supported
>>>
>>> The reacting DOIC endpoint does not need to differentiate between these
>>> two cases as the behavior (do not throttle) is the same in both cases.
>>> The -01 draft says in  clause 4.1:
>>>   If there is no single matching
>>>   capability the reacting node MUST act as if it does not implement
>>>   DOIC and cease inserting any DOIC related AVPs into any Diameter
>>>   messages with this specific reacting node.
>>>
>>> This however is inconsistent.
>>> The reacting node that ceases sending DOIC related AVPs would never
>>> recognize when the server is upgraded to support DOIC.
>>> Subsequent requests (not including DOIC related AVPs) may take a different
>>> path towards the server and on that path there may be an agent that
>>> supports DOIC (with a match of supported features) and could take the role
>>> of the reporting DOIC endpoint; but the agent cannot take this role since
>>> the reacting node (although supporting DOIC) ceased sending of OC-
>>> Supported-Features AVPs.
>>> In summary: As long as no extension feature is defined within  draft-ietf-
>>> dime-ovli  (i.e. never, since extensions will  be defined in other
>>> drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
>>> describe inclusion of OC-Supported-Features AVP in answer messages.
>>>
>>> -- 
>>> --------------------------------------+--------------------------
>>> Reporter:  lionel.morand@orange.com  |      Owner:  Ulrich Wiehe
>>>    Type:  defect                    |     Status:  new
>>> Priority:  major                     |  Milestone:
>>> Component:  draft-docdt-dime-ovli     |    Version:
>>> Severity:  Active WG Document        |   Keywords:
>>> --------------------------------------+--------------------------
>>>
>>> Ticket URL: 
>>> dime 
>>>
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------030801040003040208050301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I'll attempt to summarize
      where we are on this.  If this is agreed to then the necessary
      changes would be made to the -01 draft.  Some of this is already
      in the draft, some of it will require changes.

      

      - The draft already makes it optional for the reporting node to
      include the OC-Supported-Features AVP in answer messages - No
      change required here.

    

    - A reporting node must choose the overload
        abatement algorithm to be sent to a reacting node from the set
        of abatement algorithms included in the OC-Supported-Features
        AVP received in the request message.

        

      - If the reporting node sends an OC-OLR AVP and there is no
      OC-Supported-Features AVP then the abatement algorithm used by the
      reacting node must be loss.

      

      - The reporting node may include the OC-Supported-Features AVP
      with the loss algorithm indicated in the OC-Feature-Vector AVP.

      

      - If the reporting node wants the reacting node to apply an
      algorithm other then loss, the reacting node must include the
      OC-Supported-Features AVP with a single algorithm indicated in the
      OC-Feature-Vector AVP. 

      

      - New abatement algorithm extensions may use and extend the
      existing OC-OLR AVP.  The new algorithms may also create a new
      overload report AVP if that makes the most sense.

      

      - The loss algorithm is and always will be the mandatory to
      implement algorithm.  Or it will be until a new RFC is published
      that changes the mandatory to implement algorithm.

      

      Steve 

      

    
    
On 2/10/14 5:36 AM,
      lionel.morand@orange.com wrote:

    

    

      

-----Message d'origine-----
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Envoyé : lundi 10 février 2014 12:24
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages


On Feb 10, 2014, at 1:15 PM, <lionel.morand@orange.com> wrote:



      

        
Hi Jouni,



        

          
As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.


        

        
Bah. OLR should work for additional abatement algorithms
IF we agree that the OLR is align with the announced
abatement algorithm.. 

[LM] The issue if when you have more than one algo (let say 2). There is no way for the reporting node to indicate the algo to use with the OLR sent in the answer using the OC-Feature-Vector. The only info that you could have is "use either one or the other".


      

      
This we can fix (and I personally would like to fix). The reporting node
announces in its OC-Feature-Vector the selected common algorithm for the
sent OLR. We had this at some point of time, btw.

[LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY be used (when present) to indicate the algo to use, algo part of the common algos between the reporting node and the reacting node.



      

        
The simpliest way would be to define a new AVP when you want to support more than the default algo. If you want to rely on the same OLR with another algo, you should have a way to indicate the algo to use with the given OLR.


      

      
I recall there was a strong arguments against algorithm types in OLRs..

[LM] I was not proposing such idea :)

- Jouni



      

        



        

          
It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.


        

        
It is already today if you only support the default, right.

[LM] Right. No issue here.

-----Message d'origine-----
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Envoyé : vendredi 7 février 2014 11:04
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages


On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:



        

          
I think that there is actually an issue here but the proposed way to solve it is not the correct one.


        

        
Agree.



        

          
The initial idea was to be able to use the same overload report with several algorithms. So the OLR was somehow only meaningful along with the OC-Feature-Vector AVP.


        

        
The initial idea was to go on lines of RFC5447.



        

          
But because the OC-Feature-Vector AVP is defined as a set of flags, it is not possible to say that this OLR is to be used with only one given algo when more than one is defined (as the bit flags will advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to indicate the abatement to perform.


        

        
My intention was always allow:

 client announces  ABC
 server supports    BCD
 server announced only  e.g. C since it is common
 alternatively server announced nothing and then the default applies



        

          
As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.


        

        
Bah. OLR should work for additional abatement algorithms
IF we agree that the OLR is align with the announced
abatement algorithm.. 



        

          
It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.


        

        
It is already today if you only support the default, right.

- Jouni



        

          
Lionel 

-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
Envoyé : mardi 4 février 2014 09:48
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #30: OC-Supported-Features AVP in answer messages

#30: OC-Supported-Features AVP in answer messages

According to the current feature advertisement/negotiation mechanism in
the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP
in answer messages to indicate their supported OC features to the reacting
DOIC endpoint.
The author of this document believes that  the best a reacting node can do
with such information is to ignore it, and therefore proposes to allow
reporting nodes not to insert OC-Supported-Features AVPs in answer
messages.
Currently only one feature is defined (OLR_DEFAULT_ALGO).
A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other
feature is only interested in receiving/not receiving OC-OLR AVPs from
reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving
an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:

a) There is no overload
b) DOIC is not supported

The reacting DOIC endpoint does not need to differentiate between these
two cases as the behavior (do not throttle) is the same in both cases.
The -01 draft says in  clause 4.1:
  If there is no single matching
  capability the reacting node MUST act as if it does not implement
  DOIC and cease inserting any DOIC related AVPs into any Diameter
  messages with this specific reacting node.

This however is inconsistent.
The reacting node that ceases sending DOIC related AVPs would never
recognize when the server is upgraded to support DOIC.
Subsequent requests (not including DOIC related AVPs) may take a different
path towards the server and on that path there may be an agent that
supports DOIC (with a match of supported features) and could take the role
of the reporting DOIC endpoint; but the agent cannot take this role since
the reacting node (although supporting DOIC) ceased sending of OC-
Supported-Features AVPs.
In summary: As long as no extension feature is defined within  draft-ietf-
dime-ovli  (i.e. never, since extensions will  be defined in other
drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
describe inclusion of OC-Supported-Features AVP in answer messages.

-- 
--------------------------------------+--------------------------
Reporter:  lionel.morand@orange.com  |      Owner:  Ulrich Wiehe
   Type:  defect                    |     Status:  new
Priority:  major                     |  Milestone:
Component:  draft-docdt-dime-ovli     |    Version:
Severity:  Active WG Document        |   Keywords:
--------------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>
dime <http://tools.ietf.org/wg/dime/>


_________________________________________________________________________________________________________________________

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.

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


        

        

_________________________________________________________________________________________________________________________

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.

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



    

    

  


--------------030801040003040208050301--

From srdonovan@usdonovans.com  Mon Feb 10 07:17:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5063B1A0327 for ; Mon, 10 Feb 2014 07:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 ytHWeC4n7IzY for ; Mon, 10 Feb 2014 07:17:35 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id DDFE01A031B for ; Mon, 10 Feb 2014 07:17:35 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57465 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCsax-0007f8-Ck for dime@ietf.org; Mon, 10 Feb 2014 07:16:28 -0800
Message-ID: <52F8ED8E.5090403@usdonovans.com>
Date: Mon, 10 Feb 2014 09:17:34 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2254@DEMUMBX014.nsn-intra.net> <18813_1391619270_52F26CC6_18813_5166_1_6B7134B31289DC4FAF731D844122B36E487640@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #35: additional report types are proposed
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 15:17:38 -0000

+1 on adding an agent behavior sub-section to section 5.5 and that it
should capture Ulrich's wording that an agent must be able to
differentiate OLRs and the resulting abatement on a per client basis.

Steve

On 2/10/14 5:09 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi all  
>
> I also agree with Lionel and Nirav. As Ulrich proposes, I also think good to have a clarification and the hereafter proposed sentence from Ulrich in agent behavior (when acting on behalf of the client) is OK for me:
> "When an agent receives an OLR in response to a request initiated by a client not supporting DOIC, this agent, acting on behalf of the client, needs to (or MUST) bind the received OLR to the origin-host in the request of the client".
>
> JJacques
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
> Envoyé : mercredi 5 février 2014 17:55
> À : Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@ietf.org
> Objet : Re: [Dime] [dime] #35: additional report types are proposed
>
> If I'm correct, the following condition:
>
>        d) The values of the Origin-Host and Origin-Realm AVPs in the  request
>           match the values of the Destination-Host and Destination-Realm
>           AVPs respectively of the received message that contained the OC-
>           OLR AVP.
>
> is not correct as the message containing the OC-OLR AVP is an answer and there is Destination-Host or Destination-Realm AVPs in an answer.
>
> If you want to clarify something, it can be in the section describing the agent behavior. And such clarification will be that when an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client (no need of the origin-realm).
>
> Lionel
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mercredi 5 février 2014 17:43 À : MORAND Lionel IMT/OLN; ext Nirav Salot (nsalot); dime@ietf.org Objet : RE: [Dime] [dime] #35: additional report types are proposed
>
> Even if some feel this is implicit, it should not harm to add the d) condition explicitly please.
>
> -----Original Message-----
> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: Wednesday, February 05, 2014 4:08 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot); dime@ietf.org
> Subject: RE: [Dime] [dime] #35: additional report types are proposed
>
> Isn't it implicit?
> An answer is sent to the origin-host of the corresponding request. The agent is not the targeting point of the answer and is not supposed to be the reacting node. Now if an agent wants to act on behalf a client not supporting the DOCI mechanism at the application, this agent will have to maintain a binding for this client. This requirement is not bound to the overload control mechanism but to any function provides by the agent on behalf of downstream clients. 
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mercredi 5 février 2014 10:32 À : ext Nirav Salot (nsalot); MORAND Lionel IMT/OLN; dime@ietf.org Objet : RE: [Dime] [dime] #35: additional report types are proposed
>
> Nirav,
> ... and this natural requirement is missing from the current draft.
>
> To address this requirement we could replace the descriptions for report types 0 and 1 with the decriptions of my proposed report types 2 and 3 respectively.
>
> As a consquence, however, the agent in the given example configuration would have to store always OLRs per client even when S wants all clients to do the same throttling. Would that be acceptable?
>
> Ulrich
>
>
> -----Original Message-----
> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
> Sent: Wednesday, February 05, 2014 10:03 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com; dime@ietf.org
> Subject: RE: [Dime] [dime] #35: additional report types are proposed
>
> Ulrich,
>
> I do not think so.
> If we believe that there should be host-specific OLR and if we want to support the model when the agent acts as reacting node (on behalf of the client(s)), then the agents are naturally required to store OLR per client/host behind the agent (based on the destination-host AVP in the answer message).
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> Sent: Wednesday, February 05, 2014 2:24 PM
> To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org
> Subject: RE: [Dime] [dime] #35: additional report types are proposed
>
> Hi Lionel, Nirav,
>
> your argument only holds in configurations where the client is the reacting node.
>
> In a configuration like this
>
>
> +-------+
> | C1    |          +------+
> |       |----------|  A   |               +------+
> +-------+          |      |               | S    |
>                    |      |---------------|      |
> +-------+          |      |               +------+
> | C2    |----------|      |
> |       |          +------+
> +-------+
> where clients C1 and C2 do not support DOIC and the same agent A takes the role of the reacting node on behalf of both C1 and C2 the situation is different. According to the current version of the draft this will result in big mess with frequent replacements of OLRs in A when e.g. S requests a 50% reduction from C1 and 0% reduction from C2. 
>
> Best regards
> Ulrich
>
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
> Sent: Wednesday, February 05, 2014 5:50 AM
> To: lionel.morand@orange.com; dime@ietf.org
> Subject: Re: [Dime] [dime] #35: additional report types are proposed
>
> Same view as Lionel below.
> New report types seem more confusing than adding value.
>
> The reporting node knows the host which is going to receive the message (and hence report within the message) and hence it can generate "host specific" report and it insert into the message.
> No need to define new report types for achieving this.
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
> Sent: Tuesday, February 04, 2014 10:48 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #35: additional report types are proposed
>
> I don't see the added-value of these new report types.
> In any case the reporting node will decide which reduction value to send to each node and the reacting node will behave accordingly to the value received in the OLR. So what is the point to say "this value applies to you only"?
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoyé : mardi 4 février 2014 16:39 À : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] [dime] #35: additional report types are proposed
>
> #35: additional report types are proposed
>
> Description changed by lionel.morand@orange-ftgroup.com:
>
> Old description:
>
>> With regard to Overload Mitigation Differentiation per Client (#33) 
>> two additional report types are proposed:
>>
>>    2  A host per client report.  The overload treatment should apply to
>>       requests for which all of the following conditions are true:
>>       a) The Destination-Host AVP is present in the request and its value
>>          matches the value of the Origin-Host AVP of the received message
>>          that contained the OC-OLR AVP.
>>       b) The value of the Destination-Realm AVP in the request matches 
>> the
>>          value of the Origin-Realm AVP of the received message
>>          that contained the OC-OLR AVP.
>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
>>       d) The values of the Origin-Host and Origin-Realm AVPs in the 
>> request
>>          match the values of the Destination-Host and Destination-Realm
>>          AVPs respectively of the received message that contained the OC-
>>          OLR AVP.
>>
>>    3  A realm per client report.  The overload treatment should apply to
>>       requests for which all of the following conditions are true:
>>       a) The Destination-Host AVP is absent in the request.
>>       b) The value of the Destination-Realm AVP in the request matches 
>> the
>>          value of the Origin-Realm AVP of the received message
>>          that contained the OC-OLR AVP.
>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
>>       d) The values of the Origin-Host and Origin-Realm AVPs in the 
>> request
>>          match the values of the Destination-Host and Destination-Realm
>>          AVPs respectively of the received message that contained the OC-
>>          OLR AVP.
> New description:
>
>  The -01 draft does not address the 3GPP requirement to allow reporting  DOIC endpoints to request different amount of load reduction from  different clients (see TR 29.809 clause 6.4.7).
>  Since 3GPP is the main consumer of DOIC it is proposed to address this  requirement by adding two new report types.
>  two additional report types are proposed:
>
>     2  A host per client report.  The overload treatment should apply to
>        requests for which all of the following conditions are true:
>        a) The Destination-Host AVP is present in the request and its value
>           matches the value of the Origin-Host AVP of the received message
>           that contained the OC-OLR AVP.
>        b) The value of the Destination-Realm AVP in the request matches the
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
>        d) The values of the Origin-Host and Origin-Realm AVPs in the  request
>           match the values of the Destination-Host and Destination-Realm
>           AVPs respectively of the received message that contained the OC-
>           OLR AVP.
>
>     3  A realm per client report.  The overload treatment should apply to
>        requests for which all of the following conditions are true:
>        a) The Destination-Host AVP is absent in the request.
>        b) The value of the Destination-Realm AVP in the request matches the
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
>        d) The values of the Origin-Host and Origin-Realm AVPs in the  request
>           match the values of the Destination-Host and Destination-Realm
>           AVPs respectively of the received message that contained the OC-
>           OLR AVP.
>
> --
>


From srdonovan@usdonovans.com  Mon Feb 10 07:25:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028331A086E for ; Mon, 10 Feb 2014 07:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-GAEpstoyXr for ; Mon, 10 Feb 2014 07:25:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id C88391A0327 for ; Mon, 10 Feb 2014 07:25:24 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57481 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCsiF-00019h-61; Mon, 10 Feb 2014 07:24:14 -0800
Message-ID: <52F8EF51.1010209@usdonovans.com>
Date: Mon, 10 Feb 2014 09:25:05 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Jouni Korhonen , dime@ietf.org
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030306000304050207010904"
X-OutGoing-Spam-Status: No, score=-2.9
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
Cc: ben@nostrum.com, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 15:25:34 -0000

This is a multi-part message in MIME format.
--------------030306000304050207010904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

+1

Do we have agreement to make this change?

Steve

On 2/10/14 5:12 AM, Jouni Korhonen wrote:
> On Feb 7, 2014, at 11:54 PM, dime issue tracker  wrote:
>
>> #45: Why is a validity duration of 0 disallowed?
>>
>> Section 4.5 disallows a validity duration of zero. Why do we want to
>> disallow that? It would allow a quick way of ending any existing overload
>> condition without worrying about the semantics of the abatement algorithm.
>> (We currently use a reduction percentage of zero to end an overload
>> condition--but that's specific to the loss algorithm and might not make
>> sense for all future ones.)
> Right. Avoiding two ways of ending overload condition was the reason.
> I am OK to have validity duration 0 as an additional method ending the
> overload condition based on the reasoning above.
>
> - Jouni
>
>
>
>> Note that setting an expiration time to zero is the standard way of
>> removing state in several other protocols (e.g. SIP).
>>
>> -- 
>> -------------------------+-------------------------------------------------
>> Reporter:               |      Owner:  draft-docdt-dime-
>>  ben@nostrum.com        |  ovli@tools.ietf.org
>>     Type:  defect       |     Status:  new
>> Priority:  minor        |  Milestone:
>> Component:  draft-       |    Version:  1.0
>>  docdt-dime-ovli        |   Keywords:
>> Severity:  Active WG    |
>>  Document               |
>> -------------------------+-------------------------------------------------
>>
>> Ticket URL: 
>> dime 
>>
>


--------------030306000304050207010904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

      

      Do we have agreement to make this change?

      

      Steve

      

    
    
On 2/10/14 5:12 AM, Jouni Korhonen
      wrote:

    

    

      
On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wrote:



      

        
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)


      

      
Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

- Jouni





      

        
Note that setting an expiration time to zero is the standard way of
removing state in several other protocols (e.g. SIP).

-- 
-------------------------+-------------------------------------------------
Reporter:               |      Owner:  draft-docdt-dime-
 ben@nostrum.com        |  ovli@tools.ietf.org
    Type:  defect       |     Status:  new
Priority:  minor        |  Milestone:
Component:  draft-       |    Version:  1.0
 docdt-dime-ovli        |   Keywords:
Severity:  Active WG    |
 Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/45>
dime <http://tools.ietf.org/wg/dime/>



      

      



    

    

  


--------------030306000304050207010904--

From jean-jacques.trottin@alcatel-lucent.com  Mon Feb 10 07:45:05 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9239A1A0334 for ; Mon, 10 Feb 2014 07:45:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o84LG8bdDucy for ; Mon, 10 Feb 2014 07:45:01 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id E5BBB1A02E1 for ; Mon, 10 Feb 2014 07:45:00 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1AFiwiC004236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Feb 2014 09:44:59 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AFiu2r031929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Feb 2014 16:44:58 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 16:44:57 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPIbybCAijuwdnOUWT6I7GO6C9KJqpg7UAgATK34CAAAJegIAAA4kAgAA67wCAABnXYA==
Date: Mon, 10 Feb 2014 15:44:56 +0000
Message-ID: 
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com>
In-Reply-To: <52F8EB36.9050501@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202663CA4FR712WXCHMBA11z_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 15:45:05 -0000

--_000_E194C2E18676714DACA9C3A2516265D202663CA4FR712WXCHMBA11z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve

Thanks to have summarize this topic. I agree with your various statements t=
hat reflect in particular my own comments.

About mandatory for the default (loss) algorithm, effectively we  need this=
 for interoperability. Cannot it be stated in the draft? Future RFCs will h=
ave to be compatible with this .

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 10 f=E9vrier 2014 16:08
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I'll attempt to summarize where we are on this.  If this is agreed to then =
the necessary changes would be made to the -01 draft.  Some of this is alre=
ady in the draft, some of it will require changes.

- The draft already makes it optional for the reporting node to include the=
 OC-Supported-Features AVP in answer messages - No change required here.

- A reporting node must choose the overload abatement algorithm to be sent =
to a reacting node from the set of abatement algorithms included in the OC-=
Supported-Features AVP received in the request message.

- If the reporting node sends an OC-OLR AVP and there is no OC-Supported-Fe=
atures AVP then the abatement algorithm used by the reacting node must be l=
oss.

- The reporting node may include the OC-Supported-Features AVP with the los=
s algorithm indicated in the OC-Feature-Vector AVP.

- If the reporting node wants the reacting node to apply an algorithm other=
 then loss, the reacting node must include the OC-Supported-Features AVP wi=
th a single algorithm indicated in the OC-Feature-Vector AVP.

- New abatement algorithm extensions may use and extend the existing OC-OLR=
 AVP.  The new algorithms may also create a new overload report AVP if that=
 makes the most sense.

- The loss algorithm is and always will be the mandatory to implement algor=
ithm.  Or it will be until a new RFC is published that changes the mandator=
y to implement algorithm.

Steve
On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:





-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : lundi 10 f=E9vrier 2014 12:24

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages





On Feb 10, 2014, at 1:15 PM,  wrote:



Hi Jouni,



As the syntax of the OC-Feature-Vector is adapted to advertize supported al=
gos, it could be easier to clarify that the OC-OLR AVP is THE report AVP fo=
r the reduction algo (default) and a new dedicated report AVP must be creat=
ed when a new algo is introduced. In this way, the OC-OLR is self-explicit.



Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced

abatement algorithm..



[LM] The issue if when you have more than one algo (let say 2). There is no=
 way for the reporting node to indicate the algo to use with the OLR sent i=
n the answer using the OC-Feature-Vector. The only info that you could have=
 is "use either one or the other".



This we can fix (and I personally would like to fix). The reporting node

announces in its OC-Feature-Vector the selected common algorithm for the

sent OLR. We had this at some point of time, btw.



[LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY =
be used (when present) to indicate the algo to use, algo part of the common=
 algos between the reporting node and the reacting node.



The simpliest way would be to define a new AVP when you want to support mor=
e than the default algo. If you want to rely on the same OLR with another a=
lgo, you should have a way to indicate the algo to use with the given OLR.



I recall there was a strong arguments against algorithm types in OLRs..



[LM] I was not proposing such idea :)



- Jouni







It would be purely optional to send the Supported-Features AVP along with t=
he OC-OLR AVP.



It is already today if you only support the default, right.



[LM] Right. No issue here.



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages





On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:



I think that there is actually an issue here but the proposed way to solve =
it is not the correct one.



Agree.



The initial idea was to be able to use the same overload report with severa=
l algorithms. So the OLR was somehow only meaningful along with the OC-Feat=
ure-Vector AVP.



The initial idea was to go on lines of RFC5447.



But because the OC-Feature-Vector AVP is defined as a set of flags, it is n=
ot possible to say that this OLR is to be used with only one given algo whe=
n more than one is defined (as the bit flags will advertize 1 AND 2 for 2 s=
upported algos). So the OC-Feature-Vector cannot be used to indicate the ab=
atement to perform.



My intention was always allow:



 client announces  ABC

 server supports    BCD

 server announced only  e.g. C since it is common

 alternatively server announced nothing and then the default applies



As the syntax of the OC-Feature-Vector is adapted to advertize supported al=
gos, it could be easier to clarify that the OC-OLR AVP is THE report AVP fo=
r the reduction algo (default) and a new dedicated report AVP must be creat=
ed when a new algo is introduced. In this way, the OC-OLR is self-explicit.



Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced

abatement algorithm..



It would be purely optional to send the Supported-Features AVP along with t=
he OC-OLR AVP.



It is already today if you only support the default, right.



- Jouni





Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:48

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #30: OC-Supported-Features AVP in answer messages



#30: OC-Supported-Features AVP in answer messages



According to the current feature advertisement/negotiation mechanism in

the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP

in answer messages to indicate their supported OC features to the reacting

DOIC endpoint.

The author of this document believes that  the best a reacting node can do

with such information is to ignore it, and therefore proposes to allow

reporting nodes not to insert OC-Supported-Features AVPs in answer

messages.

Currently only one feature is defined (OLR_DEFAULT_ALGO).

A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other

feature is only interested in receiving/not receiving OC-OLR AVPs from

reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates

support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving

an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:



a) There is no overload

b) DOIC is not supported



The reacting DOIC endpoint does not need to differentiate between these

two cases as the behavior (do not throttle) is the same in both cases.

The -01 draft says in  clause 4.1:

  If there is no single matching

  capability the reacting node MUST act as if it does not implement

  DOIC and cease inserting any DOIC related AVPs into any Diameter

  messages with this specific reacting node.



This however is inconsistent.

The reacting node that ceases sending DOIC related AVPs would never

recognize when the server is upgraded to support DOIC.

Subsequent requests (not including DOIC related AVPs) may take a different

path towards the server and on that path there may be an agent that

supports DOIC (with a match of supported features) and could take the role

of the reporting DOIC endpoint; but the agent cannot take this role since

the reacting node (although supporting DOIC) ceased sending of OC-

Supported-Features AVPs.

In summary: As long as no extension feature is defined within  draft-ietf-

dime-ovli  (i.e. never, since extensions will  be defined in other

drafts), there is no need for draft-ietf-dime-ovli  to mandate or even

describe inclusion of OC-Supported-Features AVP in answer messages.



--

--------------------------------------+--------------------------

Reporter:  lionel.morand@orange.com  |    =
  Owner:  Ulrich Wiehe

   Type:  defect                    |     Status:  new

Priority:  major                     |  Milestone:

Component:  draft-docdt-dime-ovli     |    Version:

Severity:  Active WG Document        |   Keywords:

--------------------------------------+--------------------------



Ticket URL: 

dime 





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_E194C2E18676714DACA9C3A2516265D202663CA4FR712WXCHMBA11z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve


 <=
/p>

Thanks to have summarize =
this topic. I agree with your various statements that reflect in particular=
 my own comments.


 <=
/p>

About mandatory for the d=
efault (loss) algorithm, effectively we  need this for interoperabilit=
y. Cannot it be stated in the draft? Future RFCs will have to
 be compatible with this .


 <=
/p>

Best regards


 <=
/p>

JJacques   


 <=
/p>

 <=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 10 f=E9vrier 2014 16:08

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in ans=
wer messages






 


I'll attempt to summa=
rize where we are on this.  If this is agreed to then the necessary ch=
anges would be made to the -01 draft.  Some of this is already in the =
draft, some of it will require changes.



- The draft already makes it optional for the reporting node to include the=
 OC-Supported-Features AVP in answer messages - No change required here.


- A reporting node must choose the overlo=
ad abatement algorithm to be sent to a reacting node from the set of abatem=
ent algorithms included in the OC-Supported-Features AVP received in the re=
quest message.



- If the reporting node sends an OC-OLR AVP and there is no OC-Suppo=
rted-Features AVP then the abatement algorithm used by the reacting node mu=
st be loss.



- The reporting node may include the OC-Supported-Features AVP with the los=
s algorithm indicated in the OC-Feature-Vector AVP.



- If the reporting node wants the reacting node to apply an algorithm other=
 then loss, the reacting node must include the OC-Supported-Features AVP wi=
th a single algorithm indicated in the OC-Feature-Vector AVP.




- New abatement algorithm extensions may use and extend the existing OC-OLR=
 AVP.  The new algorithms may also create a new overload report AVP if=
 that makes the most sense.



- The loss algorithm is and always will be the mandatory to implement algor=
ithm.  Or it will be until a new RFC is published that changes the man=
datory to implement algorithm.



Steve 




On 2/10/14 5:36 AM, 
lionel.morand@orange.com wrote:






 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : lundi 10 f=E9vrier 2014 12:24


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org


Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answe=
r messages


 


 


On Feb 10, 2014, at 1:15 PM, <lionel.morand@orange.com> wrote:


 




Hi Jouni,


 




As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.




 


Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced


abatement algorithm.. 


 


[LM] The issue if when you have more than one algo (let say 2). There =
is no way for the reporting node to indicate the algo to use with the OLR s=
ent in the answer using the OC-Feature-Vector. The only info that you could=
 have is "use either one or the other".




 


This we can fix (and I personally would like to fix). The reporting no=
de


announces in its OC-Feature-Vector the selected common algorithm for t=
he


sent OLR. We had this at some point of time, btw.


 


[LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector=
 MAY be used (when present) to indicate the algo to use, algo part of the c=
ommon algos between the reporting node and the reacting node.

 




The simpliest way would be to define a new AVP when you want to suppor=
t more than the default algo. If you want to rely on the same OLR with anot=
her algo, you should have a way to indicate the algo to use with the given =
OLR.




 


I recall there was a strong arguments against algorithm types in OLRs.=
.


 


[LM] I was not proposing such idea :)


 


- Jouni


 




 


 




It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.




 


It is already today if you only support the default, right.=



 


[LM] Right. No issue here.


 


-----Message d'origine-----


De : Jouni Korhonen [mailto:=
jouni.nospam@gmail.com] 


Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer mes=
sages


 


 


On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:


 




I think that there is actually an issue here but the proposed way to s=
olve it is not the correct one.




 


Agree.


 




The initial idea was to be able to use the same overload report with s=
everal algorithms. So the OLR was somehow only meaningful along with the OC=
-Feature-Vector AVP.




 


The initial idea was to go on lines of RFC5447.


 




But because the OC-Feature-Vector AVP is defined as a set of flags, it=
 is not possible to say that this OLR is to be used with only one given alg=
o when more than one is defined (as the bit flags will advertize 1 AND 2 fo=
r 2 supported algos). So the OC-Feature-Vector cannot be used to indicate t=
he abatement to perform.




 


My intention was always allow:


 


 client announces  ABC


 server supports    BCD


 server announced only  e.g. C since it is common

 alternatively server announced nothing and then the default applies


 




As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.




 


Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced


abatement algorithm.. 


 




It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.




 


It is already today if you only support the default, right.=



 


- Jouni


 




 


Lionel 


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:48


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #30: OC-Supported-Features AVP in answer messages<=
/o:p>


 


#30: OC-Supported-Features AVP in answer messages


 


According to the current feature advertisement/negotiation mechanism i=
n


the -01 draft reporting DOIC endpoint insert an OC-Supported-Features =
AVP


in answer messages to indicate their supported OC features to the reac=
ting


DOIC endpoint.


The author of this document believes that  the best a reacting no=
de can do


with such information is to ignore it, and therefore proposes to allow=



reporting nodes not to insert OC-Supported-Features AVPs in answer


messages.


Currently only one feature is defined (OLR_DEFAULT_ALGO).

A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no ot=
her


feature is only interested in receiving/not receiving OC-OLR AVPs from=



reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates=



support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not =
receiving


an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:


 


a) There is no overload


b) DOIC is not supported


 


The reacting DOIC endpoint does not need to differentiate between thes=
e


two cases as the behavior (do not throttle) is the same in both cases.=



The -01 draft says in  clause 4.1:


  If there is no single matching


  capability the reacting node MUST act as if it does not impleme=
nt


  DOIC and cease inserting any DOIC related AVPs into any Diamete=
r


  messages with this specific reacting node.


 


This however is inconsistent.


The reacting node that ceases sending DOIC related AVPs would never


recognize when the server is upgraded to support DOIC.

Subsequent requests (not including DOIC related AVPs) may take a diffe=
rent


path towards the server and on that path there may be an agent that


supports DOIC (with a match of supported features) and could take the =
role


of the reporting DOIC endpoint; but the agent cannot take this role si=
nce


the reacting node (although supporting DOIC) ceased sending of OC-


Supported-Features AVPs.


In summary: As long as no extension feature is defined within  dr=
aft-ietf-


dime-ovli  (i.e. never, since extensions will  be defined in=
 other


drafts), there is no need for draft-ietf-dime-ovli  to mandate or=
 even


describe inclusion of OC-Supported-Features AVP in answer messages.


 


-- 


--------------------------------------+--------------------------<=
o:p>


Reporter:  lionel.mor=
and@orange.com  |      Owner:  Ulric=
h Wiehe


   Type:  defect      &nb=
sp;            =
 |     Status:  new


Priority:  major        &=
nbsp;            |&n=
bsp; Milestone:


Component:  draft-docdt-dime-ovli     | =
   Version:


Severity:  Active WG Document      =
  |   Keywords:


--------------------------------------+--------------------------<=
o:p>


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>


dime <http://tools.ietf.=
org/wg/dime/>


 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


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 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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_E194C2E18676714DACA9C3A2516265D202663CA4FR712WXCHMBA11z_--


From ben@nostrum.com  Mon Feb 10 07:53:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548AE1A06E3 for ; Mon, 10 Feb 2014 07:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upJpnRdXj9xn for ; Mon, 10 Feb 2014 07:53:34 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB8671A06DD for ; Mon, 10 Feb 2014 07:53:33 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1AFrQsr086948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 09:53:28 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 10 Feb 2014 09:53:26 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> 
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 15:53:36 -0000

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  =
wrote:

>=20
> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>=20
>> #45: Why is a validity duration of 0 disallowed?
>>=20
>> Section 4.5 disallows a validity duration of zero. Why do we want to
>> disallow that? It would allow a quick way of ending any existing =
overload
>> condition without worrying about the semantics of the abatement =
algorithm.
>> (We currently use a reduction percentage of zero to end an overload
>> condition--but that's specific to the loss algorithm and might not =
make
>> sense for all future ones.)
>=20
> Right. Avoiding two ways of ending overload condition was the reason.
> I am OK to have validity duration 0 as an additional method ending the
> overload condition based on the reasoning above.
>=20

I would go further and make duration 0 the _preferred_ way, for two =
reasons:

1) It's algorithm independent. (reduction-percentage of 0 is specific to =
algorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.



From srdonovan@usdonovans.com  Mon Feb 10 07:57:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111061A06ED for ; Mon, 10 Feb 2014 07:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH6alis88GDy for ; Mon, 10 Feb 2014 07:57:01 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id DD38A1A084A for ; Mon, 10 Feb 2014 07:57:01 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57551 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCtD2-0004RS-QE; Mon, 10 Feb 2014 07:55:53 -0800
Message-ID: <52F8F6C7.5060505@usdonovans.com>
Date: Mon, 10 Feb 2014 09:56:55 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <52F02C62.70600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------000904040004060102010700"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 15:57:06 -0000

This is a multi-part message in MIME format.
--------------000904040004060102010700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

We are dealing with two different definitions of endpoints.  Ulrich
diagram is all wrong when using my definition of endpoints.  Ulrich's
diagram is correct when using Ulrich's definition of endpoints.

The basic difference between the two definitions is when an agent
becomes an endpoint.

In my definition an agent that supports DOIC is an endpoint for all
transactions.

In Ulrich's definition an agent is only an endpoint if it needs to be
either a reporting node (in the case that is is acting as a server front
end or reporting realm overload) or a reacting node (when it is doing
abatement for an non supporting client).

I think that the behavior of Diameter clients and servers are the same
for both of these definitions, but we still don't have enough behavior
definition to say for sure.

I'm not ready to say which approach is better, especially when factoring
extensions to DOIC.  Maybe we can have a discussion on this topic in London.

Steve

On 2/4/14 7:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> please find comments inline.
>
> Regards
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Tuesday, February 04, 2014 12:55 AM
> To: dime@ietf.org
> Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange
>
> All,
>
> I believe that the current DOIC Endpoint behavior definition is not sufficiently defined, especially for agents.
>  I agree. 
>
> There was also a change introduced in the -01 version of the draft that implies that there can be a DOIC association that goes through a DOIC enabled agent.  This was not  how I understood endpoints.
>  same with me   The original diagrams showed a DOIC agent as terminating an endpoint that came to it.    I suspect there were different assumptions that lead to clearly different interpretations.  
>
> I propose that we return to the original diagrams and add the wording below on how DOC agents behave.  One way to look at this is that DOC agents act as back-to-back DOC endpoints.  I intentionally don't say back-to-back Diameter endpoints because this does not impact anything except the handling of DOIC related AVPs.
>
> Note that I don't believe this requires any changes to Diameter clients or servers.  I also don't believe this requires any changes to the contents of the DOIC related AVPs but there is an open question as to whether there is a need to indicate when a OC-Supported-Features AVP is generated or modified by an agent.
>
> I propose to add the following section to the section on capabilities announcement.  I'll send a separate email proposing text to section 5.5 on how DOC agents are to behave. 
>
> Regards,
>
> Steve
>
> -----
>
> 5.3.1 DOC Agent handling of DOIC capability exchange.
>
> A DOC agent is defined as a Diameter agent that supports the DOIC extension.
>  A Diameter agent that supports the DOIC extension is not necessarily taking the role of a reacting DOIC endpoint.
> It only takes the role of a reacting DOIC endpoint when receiving a request that does not contain an OC-Supported-Features AVP.
> Similarily a Diameter agent that supports the DOIC extensions is not necessarily taking the role of a reporting DOIC endpoint.
> It only takes the role of a reporting DOIC endpoint when receiving a realm type request (not containing a destination host) that contains an OC-Supported-Features AVP while it is configured to act as a reporting DOIC endpoint for that realm. 
>
> A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension
>  and decided to take the role of a reacting DOIC endpoint and/or reporting DOIC endpoint .
>
> An downstream DOIC Association is defined as the association between the DOIC supporting Diameter entity that sends a Diameter request message to a DOC agent and the DOC agent.
>
> A upstream DOIC Association is defined as the association between a DOC agent and the Diameter entity to which the DOC agent sends the Diameter request message.  The following illustrated the upstream and downstream concepts.
>
>   DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node
>   Direction of request message for a transaction ----->
>   Direction of answer message for a transaction <-----
>  this depends on the point of view: one node's downstream DOIC association is another node's upstream DOIC association. 
>  The general case is:
>
> +---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
> | client  |      | A1      |     | A2     |     | A3     |                          | A4     |                | server |
> | no DOIC |      | no DOIC |     | DOIC   |     | DOIC   |                          | DOIC   |                | DOIC   |
> | support |      | support |     | support|     | support|                          | support|                | support| 
> +---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
>     |                 |              |              |                                 |                             |
>     |                 |              |<---DOIC association 1------------------------->|<-------DOIC association 2-->|
>     |                 |              |              |                                 |                             |
>     |                 |              |<-----------------DOIC association 3----------------------------------------->|
>     |                 |              |              |                                 |                             |
>     |                 |              |              |                                 |                             |
>     |----1.xxR------->|---2.xxR----->|              |                                 |                             |
>     |                 |              |---3.xxR----->|----4.xxR----------------------->|                             |
>     |                 |              |              |                                 |--------5.xxR--------------->| 
>     |                 |              |              |                                 |<-------6.xxA----------------|
>     |                 |              |<--8.xxA------|<---7.xxA------------------------|                             |
>     |<---10.xxA-------|<--9.xxA------|              |                                 |                             |
>     |                 |              |              |                                 |                             |
>     |                 |              |              |                                 |                             |
>     |                 |              |              |                                 |                             |
>     |                 |              |              |                                 |                             |
>     |----11.xxR------>|---12.xxR---->|              |                                 |                             |
>     |                 |              |---13.xxR---->|-----14.xxR--------------------->|-------15.xxR--------------->|
>     |                 |              |              |                                 |                             |
>     |                 |              |<---18.xxA----|<----17.xxA----------------------|<-----16.xxA-----------------|
>     |<---20.xxA-------|<---19.xxA----|              |                                 |                             |
>     |                 |              |              |                                 |                             |
> DOIC association 1 is for realm type requests; 
> DOIC association 2 is for request for which A4 selects the server
> DOIC association 3 is for host type requests
>
> 1. the client that does not support DOIC sends 1.xxR (realm type request not containing destination host) to the next hop; 1.xxR does not contain an OC-Supported-Features AVP
> 2. the agent A1 that does not support DOIC forwards the request to the next hop; 2.xxR still dos not contain an OC-Supported-Feature AVP.
> 3. the agent A2 that supports DOIC decides to take the role of a reacting endpoint; it inserts an OC-Supported-Features AVP into 3.xxR indicating support of features 1 and 2 (in this example).
> 4. agent A3, although it supports DOIC, does not take the role of a reacting endpoint (because 3.xxR contains an OC-Supported-Features AVP); it also does not take the role of a reporting endpoint since it is not configured to act as reporting endpoint for the destination realm received in 3.xxR; 4.xxR (unmodified) is sent to the next hop.
> 5. agent A4 is configured to take the role of the reporting endpoint for the realm. It therefore removes the OC-Supported-Features AVP reveived in 4.xxR and inserts its own supported features (in this example features 1 and 3) in 5.xxR. A4 also selects the server to which 5.xxR is sent.
> 6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA including an OLR1 (host type) requesting a feature 3 specific traffic reduction (e.g. window size 20). 
> 7. A4 calculates the overall realm overload level, removes the received OLR1 and adds its own calculated realm type OLR2 (e.g. a feature 1 specific traffic reduction of 50%-loss) to 7.xxA. A4 stores OLR1 for later use.
> 8. A3 not taking any DOIC role forwards the answer unmodified.
> 9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores OLR2 for later use.
> 10. A1 not supporting DOIC is transparent.
> 11. client sends a new request 11.xxR (containing destination host as learnd from 10.xxA; no OC-Supported-Features AVP included.
> 12. A1 is transparent.
> 13. A2 decides to take the role of the reacting endpoint and includes again its supported features 1 and 2 in OC-Supported-Features AVO sent within 13.xxR.
> 14. A3 is transparent
> 15. A4 is transparent for host type requests that contain an OC-Supported-Features AVP.
> 16. server returns 16.xxA including a host type OLR3 requesting a feature 1 specific traffic reduction of e.g. 30%-loss.
> 17. A4 is transparent
> 18. A3 is transparent
> 19. A2 stores OLR3 for later use and may remove OLR3 when sending 19.xxA.
> 20. client receives 20.xxA.
> 
>
> Four scenarios must be supported:
>
>   - Scenario 1 - There is both an upstream and downstream DOIC association.
>  for example see A4 in the figure above 
>   - Scenario 2 - There is no upstream DOIC association
>  do you mean "There is a downstream DOIC association but no upstream DOIC association"? Not covered in the figure above. 
>   - Scenario 3 - There is no downstream DOIC association
>  do you mean "There is an upstream DOIC association but no downstream DOIC association"? for example see A2 in the figure above  
>   - Scenario 4 - No DOIC association in either direction
>  for example see A3 in the figure above 
>
> Scenario 1 - Both upstream and downstream DOIC associations
>
> Request message handling:
>
> A DOC agent that receives a request that contains the OC-Supported-Features AVP must act as an endpoint for the downstream DOIC association.
>  NO! see A3 receiving 3.xxR or 13.xxR (this may not be scenario 1, but how does the agent know which scenario applies?)
>
> If the DOC agent relays or proxies the request message then the agent must include an OC-Supported-Features AVP in the relayed message.  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.
> There cannot be more than one OC-Supported-Features AVPs in one request. An agent that inserts an OC-Supported-Features AVP must remove the received OC-Supported-Features AVP (see A4 when sending 5.xxR). The inserted OC-Supported Features AVP shall indicate the features the inserting node supports, not more, not less
>
> If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent must modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported-Features AVP must be included in the relayed request message.
>
>   Note: any DOIC extension must define the changes needed to the OC-Feature-Vector AVP and any additional AVPs that need to be added to the OC-Supported-Features AVP as part of the capabilities advertisement for that feature.
>
> Question: Should there be an indication that the contents of the OC-Supported-Features AVP was changed?
>  no. for what reason? 
>
> Question: Will this work when end-to-end security is introduced?  Would adding a separate OC-Supported-Features AVP be better, especially when end-to-end security is considered?
>  what is the issue? 
>
> Answer message handling:
>
> When an agent receives the  answer message that corresponds to the above request message
>  i.e. the request message into which the agent has inserted its OC-Supported-Features AVP 
> , the agent must act as the DOIC endpoint for the upstream DOIC association.  
>
> If the DOC agent relays or proxies the answer message then the agent must include an OC-Supported-Features AVP in the relayed message.
>  OC-Supported-Features AVP in answer messages is an open issue 
>   The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.
>
> If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent should modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported Features AVP must be included in the relayed answer message.
>
> Scenario 2 - No downstream DOIC association with an upstream association
>  wasn't that scenario 3? 
>
> In this case a request is received that does not contain an OC-Supported-Features AVP.
>
> Request message handling:
>
> If a DOC agent receives a request that does NOT contain an OC-Supported-Features AVP then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The new OC-Supported-Features AVP must be included in the relayed/proxied request message.
>
> The agent will then become the reacting DOIC endpoint for the upstream DOIC association that results from the transaction.  
>
> Note: Section x.x.x defines agent behavior when it is the reacting node for a DOIC association.
>
> Answer message handling
>
> In this case the answer message will contain an OC-Supported-Features AVP.  The DOC agent must store the advertised capabilities for use when the DOC agent reacts to an overload report from the upstream Diameter node.
>
> The DOC agent should remove the OC-Supported-Features AVP from the answer message before relaying/proxying the answer message.  
>
> Scenario 3 - Downstream DOC association with no upstream DOIC association
>  wasn't this scenario 2? 
>
> In this case a OC-Supported-Features AVP is received in the request from the downstream Diameter entity but no OC-Supported-Features AVP is received in the answer message received from the upstream Diameter entity.  In this case the agent must act as the reporting DOIC endpoint for the downstream DOIC association.
>  this is totally new to me. Where does this come from? If a server does not support DOIC it cannot request load reduction from a downstream agent. The downstream agent (even if it would detect the DOIC-non-support of the server) cannot request load reduction from further downstream nodes on behalf of the server 
>
> Request message handling:
>
> Request message handling is the same as for scenario 1.
>
> Answer message handling:
>
> If a DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that includes an upstream DOC association then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The generation of this OC-Supported-Features AVP must also follow the rules specified in section 5.3.2.  The new OC-Supported-Features AVP must be included in the relayed/proxied the answer message.
>
> Scenario 4 - No upstream association and no downstream association
>
> Request message handling:
>
> The request message handling in this case is the same as scenario 2.
>
> Answer message handling:
>
> If the DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that does not include a downstream DOC association then the agent must NOT generate an OC-Supported-Features AVP.  The DOC Agent must relay/proxy the answer message with no DOIC related change.
>
>  the open issue seems to be: How can an agent determine which scenario is applicable? Let me try:
> An agent that does not support DOIC is always in scenario 4 (no upstream DOIC association, no downstream DOIC association).
> For an agent that supports DOIC:
> When receiving a request that does not contain an OC-Supported-Features AVP the agent is in scenario 3 or 4 (no downstream DOIC association). Whether its 3 or 4 depends on whether or not an OLR is received in the corresponding answer.
> When receiving a host type request (a request that contains a Destination-Host AVP) that contains an OC-Supported-Feature AVP the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association)
> When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured to act as reporting node for that realm, the agent is scenario 1 or 2 (there is a downstream DOIC association). Whether its 1 or 2 depends on whether or not an OLR is received in the corresponding answer.
> When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured not to act as reporting node for that realm, the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association). 
>
>
>
>
>
>


--------------000904040004060102010700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    We are dealing with two
      different definitions of endpoints.  Ulrich diagram is all wrong
      when using my definition of endpoints.  Ulrich's diagram is
      correct when using Ulrich's definition of endpoints.

      

      The basic difference between the two definitions is when an agent
      becomes an endpoint.

      

      In my definition an agent that supports DOIC is an endpoint for
      all transactions.

      

      In Ulrich's definition an agent is only an endpoint if it needs to
      be either a reporting node (in the case that is is acting as a
      server front end or reporting realm overload) or a reacting node
      (when it is doing abatement for an non supporting client).

      

      I think that the behavior of Diameter clients and servers are the
      same for both of these definitions, but we still don't have enough
      behavior definition to say for sure.

      

      I'm not ready to say which approach is better, especially when
      factoring extensions to DOIC.  Maybe we can have a discussion on
      this topic in London.

      

      Steve

      

    
    
On 2/4/14 7:43 AM, Wiehe, Ulrich (NSN -
      DE/Munich) wrote:

    

    

      
Steve,

please find comments inline.

Regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 04, 2014 12:55 AM
To: dime@ietf.org
Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange

All,

I believe that the current DOIC Endpoint behavior definition is not sufficiently defined, especially for agents.
<Ulrich> I agree. </Ulrich>

There was also a change introduced in the -01 version of the draft that implies that there can be a DOIC association that goes through a DOIC enabled agent.  This was not  how I understood endpoints.
<Ulrich> same with me </Ulrich>  The original diagrams showed a DOIC agent as terminating an endpoint that came to it.    I suspect there were different assumptions that lead to clearly different interpretations.  

I propose that we return to the original diagrams and add the wording below on how DOC agents behave.  One way to look at this is that DOC agents act as back-to-back DOC endpoints.  I intentionally don't say back-to-back Diameter endpoints because this does not impact anything except the handling of DOIC related AVPs.

Note that I don't believe this requires any changes to Diameter clients or servers.  I also don't believe this requires any changes to the contents of the DOIC related AVPs but there is an open question as to whether there is a need to indicate when a OC-Supported-Features AVP is generated or modified by an agent.

I propose to add the following section to the section on capabilities announcement.  I'll send a separate email proposing text to section 5.5 on how DOC agents are to behave. 

Regards,

Steve

-----

5.3.1 DOC Agent handling of DOIC capability exchange.

A DOC agent is defined as a Diameter agent that supports the DOIC extension.
<Ulrich> A Diameter agent that supports the DOIC extension is not necessarily taking the role of a reacting DOIC endpoint.
It only takes the role of a reacting DOIC endpoint when receiving a request that does not contain an OC-Supported-Features AVP.
Similarily a Diameter agent that supports the DOIC extensions is not necessarily taking the role of a reporting DOIC endpoint.
It only takes the role of a reporting DOIC endpoint when receiving a realm type request (not containing a destination host) that contains an OC-Supported-Features AVP while it is configured to act as a reporting DOIC endpoint for that realm. </Ulrich>

A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension
<Ulrich> and decided to take the role of a reacting DOIC endpoint and/or reporting DOIC endpoint </Ulrich>.

An downstream DOIC Association is defined as the association between the DOIC supporting Diameter entity that sends a Diameter request message to a DOC agent and the DOC agent.

A upstream DOIC Association is defined as the association between a DOC agent and the Diameter entity to which the DOC agent sends the Diameter request message.  The following illustrated the upstream and downstream concepts.

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node
  Direction of request message for a transaction ----->
  Direction of answer message for a transaction <-----
<Ulrich> this depends on the point of view: one node's downstream DOIC association is another node's upstream DOIC association. </Ulrich>
<Ulrich> The general case is:

+---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
| client  |      | A1      |     | A2     |     | A3     |                          | A4     |                | server |
| no DOIC |      | no DOIC |     | DOIC   |     | DOIC   |                          | DOIC   |                | DOIC   |
| support |      | support |     | support|     | support|                          | support|                | support| 
+---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
    |                 |              |              |                                 |                             |
    |                 |              |<---DOIC association 1------------------------->|<-------DOIC association 2-->|
    |                 |              |              |                                 |                             |
    |                 |              |<-----------------DOIC association 3----------------------------------------->|
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |----1.xxR------->|---2.xxR----->|              |                                 |                             |
    |                 |              |---3.xxR----->|----4.xxR----------------------->|                             |
    |                 |              |              |                                 |--------5.xxR--------------->| 
    |                 |              |              |                                 |<-------6.xxA----------------|
    |                 |              |<--8.xxA------|<---7.xxA------------------------|                             |
    |<---10.xxA-------|<--9.xxA------|              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |----11.xxR------>|---12.xxR---->|              |                                 |                             |
    |                 |              |---13.xxR---->|-----14.xxR--------------------->|-------15.xxR--------------->|
    |                 |              |              |                                 |                             |
    |                 |              |<---18.xxA----|<----17.xxA----------------------|<-----16.xxA-----------------|
    |<---20.xxA-------|<---19.xxA----|              |                                 |                             |
    |                 |              |              |                                 |                             |
DOIC association 1 is for realm type requests; 
DOIC association 2 is for request for which A4 selects the server
DOIC association 3 is for host type requests

1. the client that does not support DOIC sends 1.xxR (realm type request not containing destination host) to the next hop; 1.xxR does not contain an OC-Supported-Features AVP
2. the agent A1 that does not support DOIC forwards the request to the next hop; 2.xxR still dos not contain an OC-Supported-Feature AVP.
3. the agent A2 that supports DOIC decides to take the role of a reacting endpoint; it inserts an OC-Supported-Features AVP into 3.xxR indicating support of features 1 and 2 (in this example).
4. agent A3, although it supports DOIC, does not take the role of a reacting endpoint (because 3.xxR contains an OC-Supported-Features AVP); it also does not take the role of a reporting endpoint since it is not configured to act as reporting endpoint for the destination realm received in 3.xxR; 4.xxR (unmodified) is sent to the next hop.
5. agent A4 is configured to take the role of the reporting endpoint for the realm. It therefore removes the OC-Supported-Features AVP reveived in 4.xxR and inserts its own supported features (in this example features 1 and 3) in 5.xxR. A4 also selects the server to which 5.xxR is sent.
6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA including an OLR1 (host type) requesting a feature 3 specific traffic reduction (e.g. window size 20). 
7. A4 calculates the overall realm overload level, removes the received OLR1 and adds its own calculated realm type OLR2 (e.g. a feature 1 specific traffic reduction of 50%-loss) to 7.xxA. A4 stores OLR1 for later use.
8. A3 not taking any DOIC role forwards the answer unmodified.
9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores OLR2 for later use.
10. A1 not supporting DOIC is transparent.
11. client sends a new request 11.xxR (containing destination host as learnd from 10.xxA; no OC-Supported-Features AVP included.
12. A1 is transparent.
13. A2 decides to take the role of the reacting endpoint and includes again its supported features 1 and 2 in OC-Supported-Features AVO sent within 13.xxR.
14. A3 is transparent
15. A4 is transparent for host type requests that contain an OC-Supported-Features AVP.
16. server returns 16.xxA including a host type OLR3 requesting a feature 1 specific traffic reduction of e.g. 30%-loss.
17. A4 is transparent
18. A3 is transparent
19. A2 stores OLR3 for later use and may remove OLR3 when sending 19.xxA.
20. client receives 20.xxA.
</Ulrich>

Four scenarios must be supported:

  - Scenario 1 - There is both an upstream and downstream DOIC association.
<Ulrich> for example see A4 in the figure above </Ulrich>
  - Scenario 2 - There is no upstream DOIC association
<Ulrich> do you mean "There is a downstream DOIC association but no upstream DOIC association"? Not covered in the figure above. </Ulrich>
  - Scenario 3 - There is no downstream DOIC association
<Ulrich> do you mean "There is an upstream DOIC association but no downstream DOIC association"? for example see A2 in the figure above </Ulrich> 
  - Scenario 4 - No DOIC association in either direction
<Ulrich> for example see A3 in the figure above </Ulrich>

Scenario 1 - Both upstream and downstream DOIC associations

Request message handling:

A DOC agent that receives a request that contains the OC-Supported-Features AVP must act as an endpoint for the downstream DOIC association.
<Ulrich> NO! see A3 receiving 3.xxR or 13.xxR (this may not be scenario 1, but how does the agent know which scenario applies?)</Ulrich>

If the DOC agent relays or proxies the request message then the agent must include an OC-Supported-Features AVP in the relayed message.  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.
<Ulrich>There cannot be more than one OC-Supported-Features AVPs in one request. An agent that inserts an OC-Supported-Features AVP must remove the received OC-Supported-Features AVP (see A4 when sending 5.xxR). The inserted OC-Supported Features AVP shall indicate the features the inserting node supports, not more, not less</Ulrich>

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent must modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported-Features AVP must be included in the relayed request message.

  Note: any DOIC extension must define the changes needed to the OC-Feature-Vector AVP and any additional AVPs that need to be added to the OC-Supported-Features AVP as part of the capabilities advertisement for that feature.

Question: Should there be an indication that the contents of the OC-Supported-Features AVP was changed?
<Ulrich> no. for what reason? </Ulrich>

Question: Will this work when end-to-end security is introduced?  Would adding a separate OC-Supported-Features AVP be better, especially when end-to-end security is considered?
<Ulrich> what is the issue? </Ulrich>

Answer message handling:

When an agent receives the  answer message that corresponds to the above request message
<Ulrich> i.e. the request message into which the agent has inserted its OC-Supported-Features AVP </Ulrich>
, the agent must act as the DOIC endpoint for the upstream DOIC association.  

If the DOC agent relays or proxies the answer message then the agent must include an OC-Supported-Features AVP in the relayed message.
<Ulrich> OC-Supported-Features AVP in answer messages is an open issue </Ulrich>
  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent should modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported Features AVP must be included in the relayed answer message.

Scenario 2 - No downstream DOIC association with an upstream association
<Ulrich> wasn't that scenario 3? </Ulrich>

In this case a request is received that does not contain an OC-Supported-Features AVP.

Request message handling:

If a DOC agent receives a request that does NOT contain an OC-Supported-Features AVP then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The new OC-Supported-Features AVP must be included in the relayed/proxied request message.

The agent will then become the reacting DOIC endpoint for the upstream DOIC association that results from the transaction.  

Note: Section x.x.x defines agent behavior when it is the reacting node for a DOIC association.

Answer message handling

In this case the answer message will contain an OC-Supported-Features AVP.  The DOC agent must store the advertised capabilities for use when the DOC agent reacts to an overload report from the upstream Diameter node.

The DOC agent should remove the OC-Supported-Features AVP from the answer message before relaying/proxying the answer message.  

Scenario 3 - Downstream DOC association with no upstream DOIC association
<Ulrich> wasn't this scenario 2? </Ulrich>

In this case a OC-Supported-Features AVP is received in the request from the downstream Diameter entity but no OC-Supported-Features AVP is received in the answer message received from the upstream Diameter entity.  In this case the agent must act as the reporting DOIC endpoint for the downstream DOIC association.
<Ulrich> this is totally new to me. Where does this come from? If a server does not support DOIC it cannot request load reduction from a downstream agent. The downstream agent (even if it would detect the DOIC-non-support of the server) cannot request load reduction from further downstream nodes on behalf of the server </Ulrich>

Request message handling:

Request message handling is the same as for scenario 1.

Answer message handling:

If a DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that includes an upstream DOC association then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The generation of this OC-Supported-Features AVP must also follow the rules specified in section 5.3.2.  The new OC-Supported-Features AVP must be included in the relayed/proxied the answer message.

Scenario 4 - No upstream association and no downstream association

Request message handling:

The request message handling in this case is the same as scenario 2.

Answer message handling:

If the DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that does not include a downstream DOC association then the agent must NOT generate an OC-Supported-Features AVP.  The DOC Agent must relay/proxy the answer message with no DOIC related change.

<Ulrich> the open issue seems to be: How can an agent determine which scenario is applicable? Let me try:
An agent that does not support DOIC is always in scenario 4 (no upstream DOIC association, no downstream DOIC association).
For an agent that supports DOIC:
When receiving a request that does not contain an OC-Supported-Features AVP the agent is in scenario 3 or 4 (no downstream DOIC association). Whether its 3 or 4 depends on whether or not an OLR is received in the corresponding answer.
When receiving a host type request (a request that contains a Destination-Host AVP) that contains an OC-Supported-Feature AVP the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association)
When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured to act as reporting node for that realm, the agent is scenario 1 or 2 (there is a downstream DOIC association). Whether its 1 or 2 depends on whether or not an OLR is received in the corresponding answer.
When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured not to act as reporting node for that realm, the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association). </Ulrich>








    

    

  


--------------000904040004060102010700--


From srdonovan@usdonovans.com  Mon Feb 10 07:57:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82081A0694 for ; Mon, 10 Feb 2014 07:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3YDGkjYkrgy for ; Mon, 10 Feb 2014 07:57:50 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 019A41A0105 for ; Mon, 10 Feb 2014 07:57:50 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57562 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCtDs-0005Xn-VB for dime@ietf.org; Mon, 10 Feb 2014 07:56:42 -0800
Message-ID: <52F8F6FB.4070306@usdonovans.com>
Date: Mon, 10 Feb 2014 09:57:47 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080306040407020508060802"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 15:57:53 -0000

This is a multi-part message in MIME format.
--------------080306040407020508060802
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I agree it needs to be stated in the draft.

Steve

On 2/10/14 9:44 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi Steve
>
>  
>
> Thanks to have summarize this topic. I agree with your various
> statements that reflect in particular my own comments.
>
>  
>
> About mandatory for the default (loss) algorithm, effectively we  need
> this for interoperability. Cannot it be stated in the draft? Future
> RFCs will have to be compatible with this .
>
>  
>
> Best regards
>
>  
>
> JJacques   
>
>  
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* lundi 10 février 2014 16:08
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer
> messages
>
>  
>
> I'll attempt to summarize where we are on this.  If this is agreed to
> then the necessary changes would be made to the -01 draft.  Some of
> this is already in the draft, some of it will require changes.
>
> - The draft already makes it optional for the reporting node to
> include the OC-Supported-Features AVP in answer messages - No change
> required here.
>
> - A reporting node must choose the overload abatement algorithm to be
> sent to a reacting node from the set of abatement algorithms included
> in the OC-Supported-Features AVP received in the request message.
>
> - If the reporting node sends an OC-OLR AVP and there is no
> OC-Supported-Features AVP then the abatement algorithm used by the
> reacting node must be loss.
>
> - The reporting node may include the OC-Supported-Features AVP with
> the loss algorithm indicated in the OC-Feature-Vector AVP.
>
> - If the reporting node wants the reacting node to apply an algorithm
> other then loss, the reacting node must include the
> OC-Supported-Features AVP with a single algorithm indicated in the
> OC-Feature-Vector AVP.
>
> - New abatement algorithm extensions may use and extend the existing
> OC-OLR AVP.  The new algorithms may also create a new overload report
> AVP if that makes the most sense.
>
> - The loss algorithm is and always will be the mandatory to implement
> algorithm.  Or it will be until a new RFC is published that changes
> the mandatory to implement algorithm.
>
> Steve
>
> On 2/10/14 5:36 AM, lionel.morand@orange.com
>  wrote:
>
>      
>
>      
>
>     -----Message d'origine-----
>
>     De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>     Envoyé : lundi 10 février 2014 12:24
>
>     À : MORAND Lionel IMT/OLN
>
>     Cc : dime@ietf.org 
>
>     Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
>      
>
>      
>
>     On Feb 10, 2014, at 1:15 PM,   wrote:
>
>      
>
>         Hi Jouni,
>
>          
>
>             As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.
>
>          
>
>         Bah. OLR should work for additional abatement algorithms
>
>         IF we agree that the OLR is align with the announced
>
>         abatement algorithm.. 
>
>          
>
>         [LM] The issue if when you have more than one algo (let say 2). There is no way for the reporting node to indicate the algo to use with the OLR sent in the answer using the OC-Feature-Vector. The only info that you could have is "use either one or the other".
>
>      
>
>     This we can fix (and I personally would like to fix). The reporting node
>
>     announces in its OC-Feature-Vector the selected common algorithm for the
>
>     sent OLR. We had this at some point of time, btw.
>
>      
>
>     [LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY be used (when present) to indicate the algo to use, algo part of the common algos between the reporting node and the reacting node.
>
>      
>
>         The simpliest way would be to define a new AVP when you want to support more than the default algo. If you want to rely on the same OLR with another algo, you should have a way to indicate the algo to use with the given OLR.
>
>      
>
>     I recall there was a strong arguments against algorithm types in OLRs..
>
>      
>
>     [LM] I was not proposing such idea :)
>
>      
>
>     - Jouni
>
>      
>
>          
>
>          
>
>             It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.
>
>          
>
>         It is already today if you only support the default, right.
>
>          
>
>         [LM] Right. No issue here.
>
>          
>
>         -----Message d'origine-----
>
>         De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Envoyé : vendredi 7 février 2014 11:04
>
>         À : MORAND Lionel IMT/OLN
>
>         Cc : dime@ietf.org 
>
>         Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
>          
>
>          
>
>         On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com  wrote:
>
>          
>
>             I think that there is actually an issue here but the proposed way to solve it is not the correct one.
>
>          
>
>         Agree.
>
>          
>
>             The initial idea was to be able to use the same overload report with several algorithms. So the OLR was somehow only meaningful along with the OC-Feature-Vector AVP.
>
>          
>
>         The initial idea was to go on lines of RFC5447.
>
>          
>
>             But because the OC-Feature-Vector AVP is defined as a set of flags, it is not possible to say that this OLR is to be used with only one given algo when more than one is defined (as the bit flags will advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to indicate the abatement to perform.
>
>          
>
>         My intention was always allow:
>
>          
>
>          client announces  ABC
>
>          server supports    BCD
>
>          server announced only  e.g. C since it is common
>
>          alternatively server announced nothing and then the default applies
>
>          
>
>             As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.
>
>          
>
>         Bah. OLR should work for additional abatement algorithms
>
>         IF we agree that the OLR is align with the announced
>
>         abatement algorithm.. 
>
>          
>
>             It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.
>
>          
>
>         It is already today if you only support the default, right.
>
>          
>
>         - Jouni
>
>          
>
>              
>
>             Lionel 
>
>              
>
>             -----Message d'origine-----
>
>             De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
>
>             Envoyé : mardi 4 février 2014 09:48
>
>             À : MORAND Lionel IMT/OLN
>
>             Cc : dime@ietf.org 
>
>             Objet : [dime] #30: OC-Supported-Features AVP in answer messages
>
>              
>
>             #30: OC-Supported-Features AVP in answer messages
>
>              
>
>             According to the current feature advertisement/negotiation mechanism in
>
>             the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP
>
>             in answer messages to indicate their supported OC features to the reacting
>
>             DOIC endpoint.
>
>             The author of this document believes that  the best a reacting node can do
>
>             with such information is to ignore it, and therefore proposes to allow
>
>             reporting nodes not to insert OC-Supported-Features AVPs in answer
>
>             messages.
>
>             Currently only one feature is defined (OLR_DEFAULT_ALGO).
>
>             A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other
>
>             feature is only interested in receiving/not receiving OC-OLR AVPs from
>
>             reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
>
>             support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving
>
>             an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:
>
>              
>
>             a) There is no overload
>
>             b) DOIC is not supported
>
>              
>
>             The reacting DOIC endpoint does not need to differentiate between these
>
>             two cases as the behavior (do not throttle) is the same in both cases.
>
>             The -01 draft says in  clause 4.1:
>
>               If there is no single matching
>
>               capability the reacting node MUST act as if it does not implement
>
>               DOIC and cease inserting any DOIC related AVPs into any Diameter
>
>               messages with this specific reacting node.
>
>              
>
>             This however is inconsistent.
>
>             The reacting node that ceases sending DOIC related AVPs would never
>
>             recognize when the server is upgraded to support DOIC.
>
>             Subsequent requests (not including DOIC related AVPs) may take a different
>
>             path towards the server and on that path there may be an agent that
>
>             supports DOIC (with a match of supported features) and could take the role
>
>             of the reporting DOIC endpoint; but the agent cannot take this role since
>
>             the reacting node (although supporting DOIC) ceased sending of OC-
>
>             Supported-Features AVPs.
>
>             In summary: As long as no extension feature is defined within  draft-ietf-
>
>             dime-ovli  (i.e. never, since extensions will  be defined in other
>
>             drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
>
>             describe inclusion of OC-Supported-Features AVP in answer messages.
>
>              
>
>             -- 
>
>             --------------------------------------+--------------------------
>
>             Reporter:  lionel.morand@orange.com   |      Owner:  Ulrich Wiehe
>
>                Type:  defect                    |     Status:  new
>
>             Priority:  major                     |  Milestone:
>
>             Component:  draft-docdt-dime-ovli     |    Version:
>
>             Severity:  Active WG Document        |   Keywords:
>
>             --------------------------------------+--------------------------
>
>              
>
>             Ticket URL:  
>
>             dime  
>
>              
>
>              
>
>             _________________________________________________________________________________________________________________________
>
>              
>
>             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.
>
>              
>
>             _______________________________________________
>
>             DiME mailing list
>
>             DiME@ietf.org 
>
>             https://www.ietf.org/mailman/listinfo/dime
>
>          
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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.
>
>      
>
>     _______________________________________________
>
>     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


--------------080306040407020508060802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I agree it needs to be
      stated in the draft.

      

      Steve

      

    
    
On 2/10/14 9:44 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi
            Steve

        
 

        
Thanks
            to have summarize this topic. I agree with your various
            statements that reflect in particular my own comments.

        
 

        
About
            mandatory for the default (loss) algorithm, effectively we
             need this for interoperability. Cannot it be stated in the
            draft? Future RFCs will have to be compatible with this .

        
 

        
Best
            regards

        
 

        
JJacques
              

        
 

        
 

        
 

        

          

            
De :
                DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : lundi 10 février 2014 16:08

                À : dime@ietf.org

                Objet : Re: [Dime] [dime] #30:
                OC-Supported-Features AVP in answer messages

          

        

        
 

        
I'll attempt
          to summarize where we are on this.  If this is agreed to then
          the necessary changes would be made to the -01 draft.  Some of
          this is already in the draft, some of it will require changes.

          

          - The draft already makes it optional for the reporting node
          to include the OC-Supported-Features AVP in answer messages -
          No change required here.

          

          - A reporting node must choose
            the overload abatement algorithm to be sent to a reacting
            node from the set of abatement algorithms included in the
            OC-Supported-Features AVP received in the request message.

            

          - If the reporting node sends an OC-OLR AVP and there
          is no OC-Supported-Features AVP then the abatement algorithm
          used by the reacting node must be loss.

          

          - The reporting node may include the OC-Supported-Features AVP
          with the loss algorithm indicated in the OC-Feature-Vector
          AVP.

          

          - If the reporting node wants the reacting node to apply an
          algorithm other then loss, the reacting node must include the
          OC-Supported-Features AVP with a single algorithm indicated in
          the OC-Feature-Vector AVP.
          

          

          - New abatement algorithm extensions may use and extend the
          existing OC-OLR AVP.  The new algorithms may also create a new
          overload report AVP if that makes the most sense.

          

          - The loss algorithm is and always will be the mandatory to
          implement algorithm.  Or it will be until a new RFC is
          published that changes the mandatory to implement algorithm.

          

          Steve 

        

          
On 2/10/14 5:36 AM, 
              lionel.morand@orange.com wrote:

        

        

          
 

          
 

          
-----Message d'origine-----

          
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

          
Envoyé : lundi 10 février 2014 12:24

          
À : MORAND Lionel IMT/OLN

          
Cc : dime@ietf.org

          
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

          
 

          
 

          
On Feb 10, 2014, at 1:15 PM, <lionel.morand@orange.com> wrote:

          
 

          

            
Hi Jouni,

            
 

            

              
As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.

            

            
 

            
Bah. OLR should work for additional abatement algorithms

            
IF we agree that the OLR is align with the announced

            
abatement algorithm.. 

            
 

            
[LM] The issue if when you have more than one algo (let say 2). There is no way for the reporting node to indicate the algo to use with the OLR sent in the answer using the OC-Feature-Vector. The only info that you could have is "use either one or the other".

          

          
 

          
This we can fix (and I personally would like to fix). The reporting node

          
announces in its OC-Feature-Vector the selected common algorithm for the

          
sent OLR. We had this at some point of time, btw.

          
 

          
[LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY be used (when present) to indicate the algo to use, algo part of the common algos between the reporting node and the reacting node.

          
 

          

            
The simpliest way would be to define a new AVP when you want to support more than the default algo. If you want to rely on the same OLR with another algo, you should have a way to indicate the algo to use with the given OLR.

          

          
 

          
I recall there was a strong arguments against algorithm types in OLRs..

          
 

          
[LM] I was not proposing such idea :)

          
 

          
- Jouni

          
 

          

            
 

            
 

            

              
It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.

            

            
 

            
It is already today if you only support the default, right.

            
 

            
[LM] Right. No issue here.

            
 

            
-----Message d'origine-----

            
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

            
Envoyé : vendredi 7 février 2014 11:04

            
À : MORAND Lionel IMT/OLN

            
Cc : dime@ietf.org

            
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

            
 

            
 

            
On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:

            
 

            

              
I think that there is actually an issue here but the proposed way to solve it is not the correct one.

            

            
 

            
Agree.

            
 

            

              
The initial idea was to be able to use the same overload report with several algorithms. So the OLR was somehow only meaningful along with the OC-Feature-Vector AVP.

            

            
 

            
The initial idea was to go on lines of RFC5447.

            
 

            

              
But because the OC-Feature-Vector AVP is defined as a set of flags, it is not possible to say that this OLR is to be used with only one given algo when more than one is defined (as the bit flags will advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to indicate the abatement to perform.

            

            
 

            
My intention was always allow:

            
 

            
 client announces  ABC

            
 server supports    BCD

            
 server announced only  e.g. C since it is common

            
 alternatively server announced nothing and then the default applies

            
 

            

              
As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.

            

            
 

            
Bah. OLR should work for additional abatement algorithms

            
IF we agree that the OLR is align with the announced

            
abatement algorithm.. 

            
 

            

              
It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.

            

            
 

            
It is already today if you only support the default, right.

            
 

            
- Jouni

            
 

            

              
 

              
Lionel 

              
 

              
-----Message d'origine-----

              
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 

              
Envoyé : mardi 4 février 2014 09:48

              
À : MORAND Lionel IMT/OLN

              
Cc : dime@ietf.org

              
Objet : [dime] #30: OC-Supported-Features AVP in answer messages

              
 

              
#30: OC-Supported-Features AVP in answer messages

              
 

              
According to the current feature advertisement/negotiation mechanism in

              
the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP

              
in answer messages to indicate their supported OC features to the reacting

              
DOIC endpoint.

              
The author of this document believes that  the best a reacting node can do

              
with such information is to ignore it, and therefore proposes to allow

              
reporting nodes not to insert OC-Supported-Features AVPs in answer

              
messages.

              
Currently only one feature is defined (OLR_DEFAULT_ALGO).

              
A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other

              
feature is only interested in receiving/not receiving OC-OLR AVPs from

              
reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates

              
support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving

              
an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:

              
 

              
a) There is no overload

              
b) DOIC is not supported

              
 

              
The reacting DOIC endpoint does not need to differentiate between these

              
two cases as the behavior (do not throttle) is the same in both cases.

              
The -01 draft says in  clause 4.1:

              
  If there is no single matching

              
  capability the reacting node MUST act as if it does not implement

              
  DOIC and cease inserting any DOIC related AVPs into any Diameter

              
  messages with this specific reacting node.

              
 

              
This however is inconsistent.

              
The reacting node that ceases sending DOIC related AVPs would never

              
recognize when the server is upgraded to support DOIC.

              
Subsequent requests (not including DOIC related AVPs) may take a different

              
path towards the server and on that path there may be an agent that

              
supports DOIC (with a match of supported features) and could take the role

              
of the reporting DOIC endpoint; but the agent cannot take this role since

              
the reacting node (although supporting DOIC) ceased sending of OC-

              
Supported-Features AVPs.

              
In summary: As long as no extension feature is defined within  draft-ietf-

              
dime-ovli  (i.e. never, since extensions will  be defined in other

              
drafts), there is no need for draft-ietf-dime-ovli  to mandate or even

              
describe inclusion of OC-Supported-Features AVP in answer messages.

              
 

              
-- 

              
--------------------------------------+--------------------------

              
Reporter:  lionel.morand@orange.com  |      Owner:  Ulrich Wiehe

              
   Type:  defect                    |     Status:  new

              
Priority:  major                     |  Milestone:

              
Component:  draft-docdt-dime-ovli     |    Version:

              
Severity:  Active WG Document        |   Keywords:

              
--------------------------------------+--------------------------

              
 

              
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>

              
dime <http://tools.ietf.org/wg/dime/>

              
 

              
 

              
_________________________________________________________________________________________________________________________

              
 

              
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.

              
 

              
_______________________________________________

              
DiME mailing list

              
DiME@ietf.org

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

            

            
 

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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.

          
 

          
_______________________________________________

          
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


    

    

  


--------------080306040407020508060802--


From jouni.nospam@gmail.com  Mon Feb 10 08:07:05 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A715F1A086D for ; Mon, 10 Feb 2014 08:07:05 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVko3YF8wojF for ; Mon, 10 Feb 2014 08:07:02 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1C1A0320 for ; Mon, 10 Feb 2014 08:07:01 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id pv20so5018579lab.30 for ; Mon, 10 Feb 2014 08:07:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZUlF+u8CTDIwP21tnaP/+51JSoLxtNCo29WHmdbhkFw=; b=X4ZnAyNg2HGDFuLM4MZnN5wAKhZ3vbGpaNfZUgjNapfH1NiVUiZFXtzwjFuSXgvPMu UnJ8QsxB6hdxQJc0B1s6LyXBCfPwuUr5P61ATy+fPH1A403Dk0mP4FJDgYpUlmrOlEUM WgOk8DSr9ex+teZ+bMrDQHhI5YLjyPG+AWzCtREfQVfc9LZOfIKjBObnqQNxfMz571tu nZJBJy2lMK1uG3RIPM1GSZ9ai0XGHgVNnirhZ+zgAHs2EuIzxiJXQJh7iiDjHKda8oO/ iCx2q7waucq5GwzW6NknTV1YRx0/bA9Lu0WuKs5l72JIoHtZ+rv2MhX0Gb1PZrm/3paz Z4vQ==
X-Received: by 10.112.90.5 with SMTP id bs5mr748279lbb.66.1392048420954; Mon, 10 Feb 2014 08:07:00 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id 10sm22917544lan.5.2014.02.10.08.06.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 08:06:57 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>
Date: Mon, 10 Feb 2014 18:06:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:07:05 -0000

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:

>=20
> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  =
wrote:
>=20
>>=20
>> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>>=20
>>> #45: Why is a validity duration of 0 disallowed?
>>>=20
>>> Section 4.5 disallows a validity duration of zero. Why do we want to
>>> disallow that? It would allow a quick way of ending any existing =
overload
>>> condition without worrying about the semantics of the abatement =
algorithm.
>>> (We currently use a reduction percentage of zero to end an overload
>>> condition--but that's specific to the loss algorithm and might not =
make
>>> sense for all future ones.)
>>=20
>> Right. Avoiding two ways of ending overload condition was the reason.
>> I am OK to have validity duration 0 as an additional method ending =
the
>> overload condition based on the reasoning above.
>>=20
>=20
> I would go further and make duration 0 the _preferred_ way, for two =
reasons:
>=20
> 1) It's algorithm independent. (reduction-percentage of 0 is specific =
to algorithms that use reduction percentage.)
>=20
> 2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.
>=20
>=20


From srdonovan@usdonovans.com  Mon Feb 10 08:20:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA5E1A017E for ; Mon, 10 Feb 2014 08:20:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.919
X-Spam-Level: 
X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhwhY8tgKEn2 for ; Mon, 10 Feb 2014 08:20:39 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 77B561A06E0 for ; Mon, 10 Feb 2014 08:20:39 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57598 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCtZw-0005CR-TK for dime@ietf.org; Mon, 10 Feb 2014 08:19:31 -0800
Message-ID: <52F8FC53.4070508@usdonovans.com>
Date: Mon, 10 Feb 2014 10:20:35 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------020201040103020006010206"
X-OutGoing-Spam-Status: No, score=-1.9
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
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:20:46 -0000

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

I agree with both Maria Cruz and Nirav. :-)

I suggest that we have wording saying the recommended approach is to
include the overload report in all response messages for the reasons
listed by Maria Cruz. 

I also suggest that we include Nirav's proposal that if a reporting node
knows that a reacting node has already received an overload report then
it may choose to not send it again.  I don't think we need to including
anything about how the reporting node knows but we should include
wording about networks architectures that make it difficult to know. 
The case of agents acting as reacting nodes for non supporting clients
being one example.

We also need to make sure that the recommended approach is not precluded
by Nirav's proposal.

I propose the following normative wording, which can be supplemented by
Maria Cruz's reasons for recommending that the overload report is always
included.

-----

A reporting node MUST ensure that all reacting nodes receive new
overload reports.

It is recommended that a reporting node include overload reports in all
answer messages sent to reacting nodes. 

Note - the reporting node may also include the overload report in answer
messages sent to non reacting nodes if that is more efficient.  The
overload report will just be ignored by a Diameter node that does not
support DOIC.

A reporting node MAY choose to not send an overload report to a reacting
node if it can guarantee that the reacting node already has received the
overload report.

Note - the only sure way, without proprietary mechanisms, to know that a
reacting node has received an overload report is when the reacting node
is a client and there is no agent between the client and the reporting node.


On 2/10/14 3:52 AM, Maria Cruz Bartolome wrote:
> Hello Nirav,
>
> Any solution should balance different factors, efficiency could be discussed from different perspectives, but first we need to assure the mechanism we are defining is providing valid OLR to reacting nodes.
>
> Your proposed text  
> " Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP."
>
> If the reporting is not aware about whether or not overload report is provided to the reacting node, and it decides (since it is a "may") to do not send the OLR again, then overload mitigation mechanism will not work in case OLR was not properly received by corresponding potential reacting nodes. And we need to note that "reacting nodes" could be not only the client, but ANY agent used for routing (not only when the agent is providing service to a Realm, but when it is reacting on behalf of a non-supporting client). 
> Then, on one hand it is not simple to know when reacting nodes have valid OLR info (as explained below), but if OLR is not sent again (as per your proposed "may") then one or multiple reacting nodes do not have the required OLR, then overload mitigation will not work.
>
> Therefore, in my opinion, the simplest way to provide required information is to provide OLR in ALL answers.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com] 
> Sent: lunes, 10 de febrero de 2014 10:42
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> But Maria-Cruz,
>
> How can we say that "including the OLR in all the answer messages is simple and efficient?"
> It is simple for sure but not efficient. 
>
> A slightly different wording from what I proposed earlier is, When the reporting node has a new overload report that needs to be provided to a reacting node (by updating the earlier provided overload report or by providing the overload report for the first time), it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
> Sent: Monday, February 10, 2014 3:03 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Nirav, all,
>
> I think we should define an accurate and robust solution, as efficient and simple as possible.
> I understand your proposal as a pure "may", but leaving it up to implementation does not assure reacting node has valid OLR information, what is basic for this mechanism to work. 
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
> Sent: lunes, 10 de febrero de 2014 10:12
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Maria-Cruz,
>
> I fully agree with you on "sending OLR in ALL answers has some important advantages".
> And we are not trying to prevent it - at least that is my intention. 
> But the main question is, are we trying to prevent any other possible implementation, which may be smarter and can avoid including redundant OLR in all the answer message?
>
> Most probably, the very first implementation of overload control will include OLR in all the answer messages.
> But at the same time, I do not want to restrict the developers which can come up with some nice tweaks and tricks to avoid sending the same information in every message. And this is where we need to be careful and avoid putting such restrictions in protocol definition. 
> What do you think?
>
> This also the reason I was suggesting loose description of when to include OLR (from the reporting node point of view).
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
> Sent: Friday, February 07, 2014 8:57 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Hello Ulrich, Nirav,
>
> I agree with Ulrich that the text provided by Nirav is just a MAY, and whether or not the server sends an OLR in all answers shall not be just a MAY.
>
> On the other hand, criteria provided by Ulrich on when OLR has to be sent requires the server has some knowledge:
> a) the reporting node knows that the reacting node has already got the latest OLR
> b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire
> c) otherwise
>
> Reporting node must have some knowledge about OLR reception/status in reacting node. How does server acquire this knowledge? 
> Take into account as well that a "reacting" node may be both an Agent (in case it provides service to a realm or acting on behalf of a non-supporting client)  and a Client. In the case of Agents, in fact the Server may not even know if this is going to act as a reacting node or just transparently, in fact, the server does not need to have any knowledge about what agents in the chain to the final Client.
>
> Therefore, I definitely think that sending OLR in ALL answers has some important advantages:
> -	state-less implementation (transaction or session) is simpler,
> -	the server does not need to determine whether or not to send an OL to a reacting node
> -	the server does not need to bother whether an reacting node has already received an OLR or whether this OLR is still valid (has not expired).
> -	sending an additional AVP is not processing consuming, in comparison with required above checks (if this is not sent). 
> 	In fact, in an overload situation, the easiest and least complex is to send information out to all affected/applicable nodes, 
> 	and the latter should take care to take appropriate actions  
> -	more robust solution, as no need to cater for all the checks on the need to send information,  for situations where an answer message is lost,  …
>
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
> Sent: viernes, 07 de febrero de 2014 10:59
> To: ext Nirav Salot (nsalot); ext lionel.morand@orange.com; ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Nirav,
>
> I'm afraid your proposed text does not reflect the intention.
>
> "when it wants to provide/update....it shall include..." translates to "...it may include...".
>
> "in other cases" in the given context translates to "when it does not want to provide/update..."
>
>
> We have the following cases:
> a) the reporting node knows that the reacting node has already got the latest OLR
> b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire
> c) otherwise
>
> in case a) the reporting node may or may not replay the OLR in case b) the reporting node may or may not upddate the reacting node with the latest OLR in case c) the reporting node MUST include the OLR in the answer (the reporting node does not know whether this is a replay or an update)
>
> Ulrich
>
>
> -----Original Message-----
> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
> Sent: Thursday, February 06, 2014 4:49 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Steve Donovan; dime@ietf.org
> Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Ulrich,
>
> It seems we all are on same page but probably the proposed wording below is not the best.
> How about the following.
>
> When the reporting node wants to provide new overload report or wants to update the earlier provided overload report towards a reacting node, it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> Sent: Thursday, February 06, 2014 3:57 PM
> To: ext lionel.morand@orange.com; Nirav Salot (nsalot); ext Steve Donovan; dime@ietf.org
> Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Nirav, Lionel,
>
> I can understand Nirav's concern (although violating REQ10) and hop it is addressed by the modified principle 2':
>
> 2'. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got reasonable overload control information (e.g. the latest OLR, which may be an OLR requesting traffic reduction or an OLR indicating "no overload", or an old  but soon expiring OLR when the reporting node is not overloaded); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.
>
> I don't agree with Lionels do-what-you-want approach. Overload control will not work when we allow the reporting node not to update reacting nodes, which are not (sufficiantly) aware of the current overload status, with up to date OLRs.
>
> Ulrich  
>
>
>
> -----Original Message-----
> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: Thursday, February 06, 2014 10:20 AM
> To: Nirav Salot (nsalot); Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
> Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoyé : jeudi 6 février 2014 10:08 À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Ulrich,
>
> I am not sure about forcing this behavior on reporting node "otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP."
> The reporting node may simply not include OLR assuming that the earlier provided OLR will expire and the reacting node will stop throttling the traffic.
>
> [LM] Agree. In other words, it is not deemed required for the default mechanism described in this draft. How and when the reporting node decides to include the OLR in the answer may depend on the application or on the implementation. At least, it is my current understanding.
>
> As we had discussed earlier, there is no need for the reporting node to explicitly stop throttling at each reacting node at the same time. In other words, the reporting node can allow the natural expiry of the OLR to facilitate slow ramp of the signaling traffic towards it.
>
> [LM] Agree
>
> There may be other cases, e.g. when the reporting node knows that the last overload situation ended long time back in the past, there is no need for it to include OLR if currently there is no overload condition.
>
> [LM] Agree
>
> Rest of the principles below are fine with me.
>
> [LM] Agree
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> Sent: Thursday, February 06, 2014 2:23 PM
> To: ext Steve Donovan; Nirav Salot (nsalot); dime@ietf.org
> Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Actually we seem to agree on two principles:
> 1. Lack of OLR means "no change"
> 2. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got the latest OLR (which may be an OLR requesting traffic reduction or an OLR indicating "no overload"); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.
>
> Can people please confirm.
>
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Wednesday, February 05, 2014 4:35 PM
> To: Nirav Salot (nsalot); dime@ietf.org
> Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
> Agreed.  To restate -- lack of an overload report does not change the current overload state for the host or realm.  If there is a currently active overload report then it continues to apply until it either times out or is explicitly changed with a new overload report.  If there is no currently active overload report then lack of an overload report implies there is no overload for the host and realm.
>
> Steve
> On 2/5/14 9:19 AM, Nirav Salot (nsalot) wrote:
> I agree with Steve except the part "shouldn’t lack of OLR be interpreted as not overloaded?"
>  
> We had some discussion sometime back and thought that it is reasonable to not mandate the server to include the OLR in every answer message. E.g. when the server is capable of tracking what is sent to which client and hence wants to avoid sending information which is redundant. But this is optional implementation and at the same time need not be prohibited from protocol point of view.
>  
> So basically, the lack of OLR should not affect the previously received OLR at the reacting node. The reacting node can continue to react based on older OLR until the expiry of the validity-period or when the explicit OLR with "0" overload-metric is received.
> In my view, this allows for flexible implementation at the reporting node and sound handling of OLR at the reacting node.
>  
> Regards,
> Nirav.
>  
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: Wednesday, February 05, 2014 8:00 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>  
> inline
> On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).
> SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?
>
>
>  
>  
> Other criteria like REQ18 or REQ13 do not seem to matter.
> SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.
>
>
>  
>  
> For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?
> SRD> That is the purpose of the sequence number.
>
>
>  
>  
>  
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
> Sent: Wednesday, February 05, 2014 5:27 AM
> To: lionel.morand@orange.com; dime@ietf.org
> Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>  
> I share the same opinion as Lionel.
>  
> Regards,
> Nirav.
>  
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
> Sent: Tuesday, February 04, 2014 9:07 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>  
> I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 
> So the options would be:
> 1- OC-OLR AVP in every answer
> 2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.
>  
> If there is no other criterion, the option 1 seems the best approach.
>  
> Lionel
>  
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
> Envoyé : mardi 4 février 2014 09:49
> À : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>  
> #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>  
>  It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number
>  (TimeStamp) of the OLR according to which the throttling (which was
>  survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.
>  Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.
>  The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).
>  The feedback mechanism also allows to address REQ 18 from RFC 7068.
>  In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.
>  
>  
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> 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


--------------020201040103020006010206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I agree with both Maria
      Cruz and Nirav. :-)

      

      I suggest that we have wording saying the recommended approach is
      to include the overload report in all response messages for the
      reasons listed by Maria Cruz.  

      

      I also suggest that we include Nirav's proposal that if a
      reporting node knows that a reacting node has already received an
      overload report then it may choose to not send it again.  I don't
      think we need to including anything about how the reporting node
      knows but we should include wording about networks architectures
      that make it difficult to know.  The case of agents acting as
      reacting nodes for non supporting clients being one example.

    

    We also need to make sure that the
        recommended approach is not precluded by Nirav's proposal.

        

        I propose the following normative wording, which can be
        supplemented by Maria Cruz's reasons for recommending that the
        overload report is always included.

        

        -----

        

        A reporting node MUST ensure that all reacting nodes receive new
        overload reports.

        

        It is recommended that a reporting node include overload reports
        in all answer messages sent to reacting nodes.  

        

        Note - the reporting node may also include the overload report
        in answer messages sent to non reacting nodes if that is more
        efficient.  The overload report will just be ignored by a
        Diameter node that does not support DOIC.

        

        A reporting node MAY choose to not send an overload report to a
        reacting node if it can guarantee that the reacting node already
        has received the overload report.

        

        Note - the only sure way, without proprietary mechanisms, to
        know that a reacting node has received an overload report is
        when the reacting node is a client and there is no agent between
        the client and the reporting node.

        

      

    
    
On 2/10/14 3:52 AM, Maria Cruz
      Bartolome wrote:

    

    

      
Hello Nirav,

Any solution should balance different factors, efficiency could be discussed from different perspectives, but first we need to assure the mechanism we are defining is providing valid OLR to reacting nodes.

Your proposed text  
" Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP."

If the reporting is not aware about whether or not overload report is provided to the reacting node, and it decides (since it is a "may") to do not send the OLR again, then overload mitigation mechanism will not work in case OLR was not properly received by corresponding potential reacting nodes. And we need to note that "reacting nodes" could be not only the client, but ANY agent used for routing (not only when the agent is providing service to a Realm, but when it is reacting on behalf of a non-supporting client). 
Then, on one hand it is not simple to know when reacting nodes have valid OLR info (as explained below), but if OLR is not sent again (as per your proposed "may") then one or multiple reacting nodes do not have the required OLR, then overload mitigation will not work.

Therefore, in my opinion, the simplest way to provide required information is to provide OLR in ALL answers.

Best regards
/MCruz

-----Original Message-----
From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com] 
Sent: lunes, 10 de febrero de 2014 10:42
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

But Maria-Cruz,

How can we say that "including the OLR in all the answer messages is simple and efficient?"
It is simple for sure but not efficient. 

A slightly different wording from what I proposed earlier is, When the reporting node has a new overload report that needs to be provided to a reacting node (by updating the earlier provided overload report or by providing the overload report for the first time), it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Monday, February 10, 2014 3:03 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Nirav, all,

I think we should define an accurate and robust solution, as efficient and simple as possible.
I understand your proposal as a pure "may", but leaving it up to implementation does not assure reacting node has valid OLR information, what is basic for this mechanism to work. 

Best regards
/MCruz

-----Original Message-----
From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: lunes, 10 de febrero de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Maria-Cruz,

I fully agree with you on "sending OLR in ALL answers has some important advantages".
And we are not trying to prevent it - at least that is my intention. 
But the main question is, are we trying to prevent any other possible implementation, which may be smarter and can avoid including redundant OLR in all the answer message?

Most probably, the very first implementation of overload control will include OLR in all the answer messages.
But at the same time, I do not want to restrict the developers which can come up with some nice tweaks and tricks to avoid sending the same information in every message. And this is where we need to be careful and avoid putting such restrictions in protocol definition. 
What do you think?

This also the reason I was suggesting loose description of when to include OLR (from the reporting node point of view).

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Friday, February 07, 2014 8:57 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Hello Ulrich, Nirav,

I agree with Ulrich that the text provided by Nirav is just a MAY, and whether or not the server sends an OLR in all answers shall not be just a MAY.

On the other hand, criteria provided by Ulrich on when OLR has to be sent requires the server has some knowledge:
a) the reporting node knows that the reacting node has already got the latest OLR
b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire
c) otherwise

Reporting node must have some knowledge about OLR reception/status in reacting node. How does server acquire this knowledge? 
Take into account as well that a "reacting" node may be both an Agent (in case it provides service to a realm or acting on behalf of a non-supporting client)  and a Client. In the case of Agents, in fact the Server may not even know if this is going to act as a reacting node or just transparently, in fact, the server does not need to have any knowledge about what agents in the chain to the final Client.

Therefore, I definitely think that sending OLR in ALL answers has some important advantages:
-	state-less implementation (transaction or session) is simpler,
-	the server does not need to determine whether or not to send an OL to a reacting node
-	the server does not need to bother whether an reacting node has already received an OLR or whether this OLR is still valid (has not expired).
-	sending an additional AVP is not processing consuming, in comparison with required above checks (if this is not sent). 
	In fact, in an overload situation, the easiest and least complex is to send information out to all affected/applicable nodes, 
	and the latter should take care to take appropriate actions  
-	more robust solution, as no need to cater for all the checks on the need to send information,  for situations where an answer message is lost,  …


Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 10:59
To: ext Nirav Salot (nsalot); ext lionel.morand@orange.com; ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Nirav,

I'm afraid your proposed text does not reflect the intention.

"when it wants to provide/update....it shall include..." translates to "...it may include...".

"in other cases" in the given context translates to "when it does not want to provide/update..."


We have the following cases:
a) the reporting node knows that the reacting node has already got the latest OLR
b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire
c) otherwise

in case a) the reporting node may or may not replay the OLR in case b) the reporting node may or may not upddate the reacting node with the latest OLR in case c) the reporting node MUST include the OLR in the answer (the reporting node does not know whether this is a replay or an update)

Ulrich


-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Thursday, February 06, 2014 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Ulrich,

It seems we all are on same page but probably the proposed wording below is not the best.
How about the following.

When the reporting node wants to provide new overload report or wants to update the earlier provided overload report towards a reacting node, it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Thursday, February 06, 2014 3:57 PM
To: ext lionel.morand@orange.com; Nirav Salot (nsalot); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Nirav, Lionel,

I can understand Nirav's concern (although violating REQ10) and hop it is addressed by the modified principle 2':

2'. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got reasonable overload control information (e.g. the latest OLR, which may be an OLR requesting traffic reduction or an OLR indicating "no overload", or an old  but soon expiring OLR when the reporting node is not overloaded); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.

I don't agree with Lionels do-what-you-want approach. Overload control will not work when we allow the reporting node not to update reacting nodes, which are not (sufficiantly) aware of the current overload status, with up to date OLRs.

Ulrich  



-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, February 06, 2014 10:20 AM
To: Nirav Salot (nsalot); Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling



-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoyé : jeudi 6 février 2014 10:08 À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Ulrich,

I am not sure about forcing this behavior on reporting node "otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP."
The reporting node may simply not include OLR assuming that the earlier provided OLR will expire and the reacting node will stop throttling the traffic.

[LM] Agree. In other words, it is not deemed required for the default mechanism described in this draft. How and when the reporting node decides to include the OLR in the answer may depend on the application or on the implementation. At least, it is my current understanding.

As we had discussed earlier, there is no need for the reporting node to explicitly stop throttling at each reacting node at the same time. In other words, the reporting node can allow the natural expiry of the OLR to facilitate slow ramp of the signaling traffic towards it.

[LM] Agree

There may be other cases, e.g. when the reporting node knows that the last overload situation ended long time back in the past, there is no need for it to include OLR if currently there is no overload condition.

[LM] Agree

Rest of the principles below are fine with me.

[LM] Agree

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Thursday, February 06, 2014 2:23 PM
To: ext Steve Donovan; Nirav Salot (nsalot); dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Actually we seem to agree on two principles:
1. Lack of OLR means "no change"
2. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got the latest OLR (which may be an OLR requesting traffic reduction or an OLR indicating "no overload"); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.

Can people please confirm.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, February 05, 2014 4:35 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Agreed.  To restate -- lack of an overload report does not change the current overload state for the host or realm.  If there is a currently active overload report then it continues to apply until it either times out or is explicitly changed with a new overload report.  If there is no currently active overload report then lack of an overload report implies there is no overload for the host and realm.

Steve
On 2/5/14 9:19 AM, Nirav Salot (nsalot) wrote:
I agree with Steve except the part "shouldn’t lack of OLR be interpreted as not overloaded?"
 
We had some discussion sometime back and thought that it is reasonable to not mandate the server to include the OLR in every answer message. E.g. when the server is capable of tracking what is sent to which client and hence wants to avoid sending information which is redundant. But this is optional implementation and at the same time need not be prohibited from protocol point of view.
 
So basically, the lack of OLR should not affect the previously received OLR at the reacting node. The reacting node can continue to react based on older OLR until the expiry of the validity-period or when the explicit OLR with "0" overload-metric is received.
In my view, this allows for flexible implementation at the reporting node and sound handling of OLR at the reacting node.
 
Regards,
Nirav.
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, February 05, 2014 8:00 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
inline
On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).
SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?


 
 
Other criteria like REQ18 or REQ13 do not seem to matter.
SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.


 
 
For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?
SRD> That is the purpose of the sequence number.


 
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
Sent: Wednesday, February 05, 2014 5:27 AM
To: lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
I share the same opinion as Lionel.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 9:07 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 
So the options would be:
1- OC-OLR AVP in every answer
2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.
 
If there is no other criterion, the option 1 seems the best approach.
 
Lionel
 
-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:49
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
 It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number
 (TimeStamp) of the OLR according to which the throttling (which was
 survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.
 Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.
 The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).
 The feedback mechanism also allows to address REQ 18 from RFC 7068.
 In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.
 
 

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

_________________________________________________________________________________________________________________________

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.

_______________________________________________
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


    

    

  


--------------020201040103020006010206--


From ben@nostrum.com  Mon Feb 10 08:24:19 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9FE1A0870 for ; Mon, 10 Feb 2014 08:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFMWga7WwUxQ for ; Mon, 10 Feb 2014 08:24:18 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E611C1A017E for ; Mon, 10 Feb 2014 08:24:17 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1AGO9wo088249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 10:24:10 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 10 Feb 2014 10:24:08 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> 
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:24:19 -0000

On Feb 10, 2014, at 5:16 AM, Jouni Korhonen  =
wrote:

>=20
> My reasoning for explicit termination was that knowing the =
implementation
> folks they will let overload conditions expire unless advised =
otherwise.
> And having unnecessary stuff hanging around waiting for a cleanup is =
not
> a good thing in general. But I am open here for other options..
>=20

I think it's reasonable to say that a reporting node should terminate an =
overload condition in a timely manner. But if it's about to expire =
anyway, then expiration might be just as timely as an explicit report.=20=


And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.


From ben@nostrum.com  Mon Feb 10 08:25:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BA51A06D3 for ; Mon, 10 Feb 2014 08:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziws4jmEZT2U for ; Mon, 10 Feb 2014 08:25:20 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0A01A0622 for ; Mon, 10 Feb 2014 08:25:20 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1AGO9wp088249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 10:25:13 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 10 Feb 2014 10:25:13 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com> 
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:25:21 -0000

Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen  =
wrote:

>=20
> Ben,
>=20
> Propose some text and we can see how it fits in.
>=20
> - Jouni
>=20
>=20
> On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:
>=20
>>=20
>> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  =
wrote:
>>=20
>>>=20
>>> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>>>=20
>>>> #45: Why is a validity duration of 0 disallowed?
>>>>=20
>>>> Section 4.5 disallows a validity duration of zero. Why do we want =
to
>>>> disallow that? It would allow a quick way of ending any existing =
overload
>>>> condition without worrying about the semantics of the abatement =
algorithm.
>>>> (We currently use a reduction percentage of zero to end an overload
>>>> condition--but that's specific to the loss algorithm and might not =
make
>>>> sense for all future ones.)
>>>=20
>>> Right. Avoiding two ways of ending overload condition was the =
reason.
>>> I am OK to have validity duration 0 as an additional method ending =
the
>>> overload condition based on the reasoning above.
>>>=20
>>=20
>> I would go further and make duration 0 the _preferred_ way, for two =
reasons:
>>=20
>> 1) It's algorithm independent. (reduction-percentage of 0 is specific =
to algorithms that use reduction percentage.)
>>=20
>> 2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.
>>=20
>>=20
>=20


From srdonovan@usdonovans.com  Mon Feb 10 08:37:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908C01A07EE for ; Mon, 10 Feb 2014 08:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqD7jX6R9nn2 for ; Mon, 10 Feb 2014 08:37:28 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id E77DB1A0882 for ; Mon, 10 Feb 2014 08:37:28 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57624 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCtq9-0003DA-T4; Mon, 10 Feb 2014 08:36:17 -0800
Message-ID: <52F90040.6020909@usdonovans.com>
Date: Mon, 10 Feb 2014 10:37:20 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: lionel.morand@orange.com, "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" ,  "ben@nostrum.com" 
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> <8933_1391878974_52F6633D_8933_14099_1_6B7134B31289DC4FAF731D844122B36E49395B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <8933_1391878974_52F6633D_8933_14099_1_6B7134B31289DC4FAF731D844122B36E49395B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------040501080404040709090903"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #41: Need better overview
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:37:30 -0000

This is a multi-part message in MIME format.
--------------040501080404040709090903
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I think the way to handle this issue in the issue tracker is to assign
it to one of the authors and that author would then be responsible for
generating overview text.

Steve

On 2/8/14 11:02 AM, lionel.morand@orange.com wrote:
> Hi Ben,
>
> Any proposal?
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
> Envoyé : vendredi 7 février 2014 21:55
> À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
> Cc : dime@ietf.org
> Objet : [Dime] [dime] #41: Need better overview
>
> #41: Need better overview
>
>  The overview is short on explanation. We need a high level, non-normative
>  "how it works" description of the mechanism, including roles,
>  responsibilities, associations, and information flows. This doesn't need
>  too much detail (e.g. message and AVP definitions belong elsewhere.)
>
>  Some of the information in the endpoint architecture section would be
>  better off here.
>


--------------040501080404040709090903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I think the way to handle
      this issue in the issue tracker is to assign it to one of the
      authors and that author would then be responsible for generating
      overview text.

      

      Steve

      

    
    
On 2/8/14 11:02 AM,
      lionel.morand@orange.com wrote:

    

    

      
Hi Ben,

Any proposal?

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : vendredi 7 février 2014 21:55
À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Cc : dime@ietf.org
Objet : [Dime] [dime] #41: Need better overview

#41: Need better overview

 The overview is short on explanation. We need a high level, non-normative
 "how it works" description of the mechanism, including roles,
 responsibilities, associations, and information flows. This doesn't need
 too much detail (e.g. message and AVP definitions belong elsewhere.)

 Some of the information in the endpoint architecture section would be
 better off here.



    

    

  


--------------040501080404040709090903--

From ben@nostrum.com  Mon Feb 10 08:39:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC2E1A0885 for ; Mon, 10 Feb 2014 08:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wx1KSq8Xg77 for ; Mon, 10 Feb 2014 08:39:12 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 061941A06F2 for ; Mon, 10 Feb 2014 08:39:10 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1AGd5U3088892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 10:39:07 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <52F90040.6020909@usdonovans.com>
Date: Mon, 10 Feb 2014 10:39:05 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> <8933_1391878974_52F6633D_8933_14099_1_6B7134B31289DC4FAF731D844122B36E49395B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F90040.6020909@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #41: Need better overview
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:39:13 -0000

I can volunteer for that, with the caveat that it probably won't happen =
before the IETF89 draft deadline.

On Feb 10, 2014, at 10:37 AM, Steve Donovan  =
wrote:

> I think the way to handle this issue in the issue tracker is to assign =
it to one of the authors and that author would then be responsible for =
generating overview text.
>=20
> Steve
>=20
> On 2/8/14 11:02 AM, lionel.morand@orange.com wrote:
>> Hi Ben,
>>=20
>> Any proposal?
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : DiME [
>> mailto:dime-bounces@ietf.org
>> ] De la part de dime issue tracker
>> Envoy=E9 : vendredi 7 f=E9vrier 2014 21:55
>> =C0 :=20
>> draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
>>=20
>> Cc :=20
>> dime@ietf.org
>>=20
>> Objet : [Dime] [dime] #41: Need better overview
>>=20
>> #41: Need better overview
>>=20
>>  The overview is short on explanation. We need a high level, =
non-normative
>>  "how it works" description of the mechanism, including roles,
>>  responsibilities, associations, and information flows. This doesn't =
need
>>  too much detail (e.g. message and AVP definitions belong elsewhere.)
>>=20
>>  Some of the information in the endpoint architecture section would =
be
>>  better off here.
>>=20
>>=20
>=20


From srdonovan@usdonovans.com  Mon Feb 10 08:39:16 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94B71A0889 for ; Mon, 10 Feb 2014 08:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODQTPloWK4_4 for ; Mon, 10 Feb 2014 08:39:15 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 429E71A0885 for ; Mon, 10 Feb 2014 08:39:15 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57630 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCtrx-0005t1-3H; Mon, 10 Feb 2014 08:38:07 -0800
Message-ID: <52F900AF.6020201@usdonovans.com>
Date: Mon, 10 Feb 2014 10:39:11 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com
References: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org>
In-Reply-To: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------090304080400090909040708"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #39: Definition of Diameter Routing
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:39:17 -0000

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

I agree with Ben, I don't see the need to include this definition.

Steve

On 2/7/14 2:41 PM, dime issue tracker wrote:
> #39: Definition of Diameter Routing
>
>  Do we need this definition? Diameter routing should be fully defined by
>  the base specification.
>
>  But if we do, I think the phrase "non-adjacent nodes" in the first
>  sentence is misleading. Destination-Realm is also used to route between
>  adjacent nodes, at least until you reach the node responsible for the
>  ream+application. We should also include Application-Id.
>


--------------090304080400090909040708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    I agree with Ben, I don't
      see the need to include this definition.

      

      Steve

      

    
    
On 2/7/14 2:41 PM, dime issue tracker
      wrote:

    

    

      
#39: Definition of Diameter Routing

 Do we need this definition? Diameter routing should be fully defined by
 the base specification.

 But if we do, I think the phrase "non-adjacent nodes" in the first
 sentence is misleading. Destination-Realm is also used to route between
 adjacent nodes, at least until you reach the node responsible for the
 ream+application. We should also include Application-Id.



    

    

  


--------------090304080400090909040708--

From lionel.morand@orange.com  Mon Feb 10 08:43:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A06F1A06DC for ; Mon, 10 Feb 2014 08:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVq7_V0ldLdy for ; Mon, 10 Feb 2014 08:42:55 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 55D341A0339 for ; Mon, 10 Feb 2014 08:42:54 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 5FE473B4397; Mon, 10 Feb 2014 17:42:53 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 476BF38408C; Mon, 10 Feb 2014 17:42:53 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 17:42:52 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPJnwSEYTiJsmmjEaFp2atqlYEO5qurnQQ
Date: Mon, 10 Feb 2014 16:42:52 +0000
Message-ID: <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com>
In-Reply-To: <52F8FC53.4070508@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E497B0APEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.83016
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:43:02 -0000

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

SSdtIGZpbmUgd2l0aCBhIHJlY29tbWVuZGF0aW9uLg0KDQpCdXQgSSBoYXZlIGEgZ2VuZXJhbCBj
b21tZW50OiB3aGVuIGEgTUFZIG9yIGV2ZW4gYSBTSE9VTEQgYXBwbHksIGl0IGRvZXMgbm90IG1l
YW4gdGhhdCBpdCBpcyBOT1QgdXAgdG8gdGhlIG5vZGUgdG8gZG8gb3Igbm90IHRvIGRvIHNvbWV0
aGluZy4gSXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIG9ubHkgYW4gaW1wbGVtZW50YXRpb24g
b3B0aW9uLg0KRm9yIGluc3RhbmNlLCBvdmVyIGEgZ2l2ZW4gaW50ZXJmYWNlLCB0aGUgcmVsYXRl
ZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkgdGhhdCBzb21lIHN0YXRlcyBhcmUgbWFpbnRhaW5lZCBi
eSB0aGUgc2VydmVyLiBBbmQgaXQgY291bGQgYmUgZGVjaWRlZCB0byBhZGQgc29tZSBvdmVybG9h
ZCByZWxhdGVkIGluZm8gaW4gc3VjaCBzdGF0ZXMuIEZvciBpbnN0YW5jZSBhZ2FpbiwgdGhlIG5v
ZGUgY2FuIHVzZSB0aGlzIHN0YXRlIHRvIGtub3cgaWYgYSByZW1vdGUgbm9kZSBoYXZlIGJlZW4g
bm90aWZpZWQgb3Igbm90IGZvciBpbnN0YW5jZS4gQW5kIGluIHN1Y2ggYSBjYXNlLCB0aGUgc2Vy
dmVyIGRvZXMgbm90IG5lZWQgdG8gaW5jbHVkZSBhbiBPTFIgaW4gZWFjaCBtZXNzYWdlLiBJdCBp
cyBqdXN0IGZvciBpbGx1c3RyYXRpb24uIFRoZSBwb2ludCBpcyB0aGF0IHlvdSBtYXkgaGF2ZSBz
b21lIGNhc2VzIGZvciB3aGljaCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtaWdodCBub3QgYmUg
cmVxdWlyZWQuDQoNCkkgYWdyZWUgdGhhdCBoYXZpbmcgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIg
aXMgZmluZeKApiBidXQgaXQgc2hvdWxkIGJlIG5vdCBtYW5kYXRvcnkgaW4gYWxsIGNhc2VzIEkg
dGhpbmsuIFNvIE9LIGZvciBhICJTSE9VTEQiIG9yICJSRUNPTU1FTkRFRCIuDQoNClJlZ2FyZHMs
DQoNCkxpb25lbA0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERl
IGxhIHBhcnQgZGUgU3RldmUgRG9ub3Zhbg0KRW52b3nDqSA6IGx1bmRpIDEwIGbDqXZyaWVyIDIw
MTQgMTc6MjENCsOAIDogZGltZUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBhZ3JlZSB3aXRoIGJvdGggTWFy
aWEgQ3J1eiBhbmQgTmlyYXYuIDotKQ0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBoYXZlIHdvcmRpbmcg
c2F5aW5nIHRoZSByZWNvbW1lbmRlZCBhcHByb2FjaCBpcyB0byBpbmNsdWRlIHRoZSBvdmVybG9h
ZCByZXBvcnQgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQg
YnkgTWFyaWEgQ3J1ei4NCg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBpbmNsdWRlIE5pcmF2J3Mg
cHJvcG9zYWwgdGhhdCBpZiBhIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgYSByZWFjdGluZyBu
b2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IG1heSBj
aG9vc2UgdG8gbm90IHNlbmQgaXQgYWdhaW4uICBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gaW5j
bHVkaW5nIGFueXRoaW5nIGFib3V0IGhvdyB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgYnV0IHdl
IHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0dXJlcyB0aGF0
IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuICBUaGUgY2FzZSBvZiBhZ2VudHMgYWN0aW5nIGFz
IHJlYWN0aW5nIG5vZGVzIGZvciBub24gc3VwcG9ydGluZyBjbGllbnRzIGJlaW5nIG9uZSBleGFt
cGxlLg0KDQpXZSBhbHNvIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlY29tbWVuZGVkIGFw
cHJvYWNoIGlzIG5vdCBwcmVjbHVkZWQgYnkgTmlyYXYncyBwcm9wb3NhbC4NCg0KSSBwcm9wb3Nl
IHRoZSBmb2xsb3dpbmcgbm9ybWF0aXZlIHdvcmRpbmcsIHdoaWNoIGNhbiBiZSBzdXBwbGVtZW50
ZWQgYnkgTWFyaWEgQ3J1eidzIHJlYXNvbnMgZm9yIHJlY29tbWVuZGluZyB0aGF0IHRoZSBvdmVy
bG9hZCByZXBvcnQgaXMgYWx3YXlzIGluY2x1ZGVkLg0KDQotLS0tLQ0KDQpBIHJlcG9ydGluZyBu
b2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJs
b2FkIHJlcG9ydHMuDQoNCkl0IGlzIHJlY29tbWVuZGVkIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBp
bmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIHJl
YWN0aW5nIG5vZGVzLg0KDQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1
ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVh
Y3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4gIFRoZSBvdmVybG9hZCByZXBv
cnQgd2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qg
c3VwcG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQg
YW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVl
IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2Fk
IHJlcG9ydC4NCg0KTm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5
IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFu
IG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFu
ZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcg
bm9kZS4NCg0KT24gMi8xMC8xNCAzOjUyIEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZToN
Cg0KSGVsbG8gTmlyYXYsDQoNCg0KDQpBbnkgc29sdXRpb24gc2hvdWxkIGJhbGFuY2UgZGlmZmVy
ZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291bGQgYmUgZGlzY3Vzc2VkIGZyb20gZGlmZmVyZW50
IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQgdG8gYXNzdXJlIHRoZSBtZWNoYW5pc20g
d2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGluZyB2YWxpZCBPTFIgdG8gcmVhY3Rpbmcgbm9kZXMu
DQoNCg0KDQpZb3VyIHByb3Bvc2VkIHRleHQNCg0KIiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNh
c2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3Zl
cmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRo
ZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8g
dGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KDQoNCg0K
SWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3Zlcmxv
YWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRl
cyAoc2luY2UgaXQgaXMgYSAibWF5IikgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhl
biBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xS
IHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVh
Y3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNv
dWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGlu
ZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFs
bSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcg
Y2xpZW50KS4NCg0KVGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93IHdo
ZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJlbG93
KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQgIm1h
eSIpIHRoZW4gb25lIG9yIG11bHRpcGxlIHJlYWN0aW5nIG5vZGVzIGRvIG5vdCBoYXZlIHRoZSBy
ZXF1aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlvbiB3aWxsIG5vdCB3b3JrLg0KDQoN
Cg0KVGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUg
cmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuDQoN
Cg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5j
b21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDINCg0KVG86IE1h
cmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0K
DQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcNCg0KDQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQoNCg0KSG93IGNhbiB3ZSBzYXkgdGhhdCAi
aW5jbHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMgaXMgc2ltcGxlIGFu
ZCBlZmZpY2llbnQ/Ig0KDQpJdCBpcyBzaW1wbGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQu
DQoNCg0KDQpBIHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2Vk
IGVhcmxpZXIgaXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCBy
ZXBvcnQgdGhhdCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVw
ZGF0aW5nIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRp
bmcgdGhlIG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNs
dWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3Vw
cG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5v
ZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92
aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRl
IHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQoNClNlbnQ6IE1v
bmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMzowMyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWls
dG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpOaXJhdiwgYWxsLA0KDQoNCg0KSSB0aGlu
ayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVm
ZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KDQpJIHVuZGVyc3RhbmQgeW91ciBwcm9w
b3NhbCBhcyBhIHB1cmUgIm1heSIsIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9u
IGRvZXMgbm90IGFzc3VyZSByZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24s
IHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuDQoNCg0KDQpCZXN0IHJl
Z2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9t
OiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6
IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6MTINCg0KVG86IE1hcmlhIENydXogQmFy
dG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBS
RTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoN
Ck1hcmlhLUNydXosDQoNCg0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91IG9uICJzZW5kaW5nIE9M
UiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlcyIuDQoNCkFuZCB3
ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBteSBpbnRl
bnRpb24uDQoNCkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2
ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0
ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dl
ciBtZXNzYWdlPw0KDQoNCg0KTW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50
YXRpb24gb2Ygb3ZlcmxvYWQgY29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5z
d2VyIG1lc3NhZ2VzLg0KDQpCdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byBy
ZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0
d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGlu
IGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBh
bmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9u
Lg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KDQoNClRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2Fz
IHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJv
bSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuDQoNCg0KDQpSZWdhcmRzLA0KDQpO
aXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRv
bG9tZQ0KDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE0NCg0KVG86IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSGVsbG8gVWxy
aWNoLCBOaXJhdiwNCg0KDQoNCkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBwcm92
aWRlZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNlcnZl
ciBzZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVkuDQoN
Cg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdo
ZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xl
ZGdlOg0KDQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9k
ZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCg0KYikgdGhlIHJlcG9ydGluZyBub2Rl
IGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQg
a25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29v
biBleHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoNCg0KDQpSZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUg
c29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9k
ZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBrbm93bGVkZ2U/DQoNClRha2UgaW50byBh
Y2NvdW50IGFzIHdlbGwgdGhhdCBhICJyZWFjdGluZyIgbm9kZSBtYXkgYmUgYm90aCBhbiBBZ2Vu
dCAoaW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2aWNlIHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJl
aGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkgIGFuZCBhIENsaWVudC4gSW4gdGhlIGNh
c2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhp
cyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRs
eSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRn
ZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC4NCg0K
DQoNClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxM
IGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXM6DQoNCi0gc3RhdGUtbGVzcyBp
bXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikgaXMgc2ltcGxlciwNCg0KLSB0
aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNl
bmQgYW4gT0wgdG8gYSByZWFjdGluZyBub2RlDQoNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVk
IHRvIGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQg
YW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJl
ZCkuDQoNCi0gc2VuZGluZyBhbiBhZGRpdGlvbmFsIEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25z
dW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMg
aXMgbm90IHNlbnQpLg0KDQogIEluIGZhY3QsIGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwgdGhl
IGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQgdG8g
YWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsDQoNCiAgYW5kIHRoZSBsYXR0ZXIgc2hvdWxk
IHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMNCg0KLSBtb3JlIHJvYnVzdCBz
b2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVja3Mgb24gdGhlIG5l
ZWQgdG8gc2VuZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBt
ZXNzYWdlIGlzIGxvc3QsICDigKYNCg0KDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoN
Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUv
TXVuaWNoKQ0KDQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTkNCg0K
VG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgZXh0IFN0ZXZlIERvbm92YW47IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsDQoN
Cg0KDQpJJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBp
bnRlbnRpb24uDQoNCg0KDQoid2hlbiBpdCB3YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBz
aGFsbCBpbmNsdWRlLi4uIiB0cmFuc2xhdGVzIHRvICIuLi5pdCBtYXkgaW5jbHVkZS4uLiIuDQoN
Cg0KDQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8g
IndoZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQoNCg0KDQpX
ZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6DQoNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93
cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0K
DQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qg
d2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBn
b3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KDQpjKSBvdGhlcndpc2UNCg0KDQoNCmlu
IGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xS
IGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhl
IHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRp
bmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5n
IG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRl
KQ0KDQoNCg0KVWxyaWNoDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K
RnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0N
Cg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkgUE0NCg0KVG86IFdpZWhl
LCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208
bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1l
QGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtk
aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl
c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNClVscmljaCwNCg0K
DQoNCkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJv
cG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuDQoNCkhvdyBhYm91dCB0aGUgZm9s
bG93aW5nLg0KDQoNCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBu
ZXcgb3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRl
ZCBvdmVybG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1
ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBw
b3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9k
ZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcg
bm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3Zp
ZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUg
dGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3Vw
cG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N
dW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBG
ZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNDQoNClRvOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2Uu
Y29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBOaXJhdiBTYWxvdCAobnNhbG90
KTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KTmlyYXYsIExpb25lbCwNCg0KDQoNCkkgY2FuIHVuZGVyc3RhbmQgTmly
YXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRk
cmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lwbGUgMic6DQoNCg0KDQoyJy4gdGhlIHJlcG9y
dGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lk
ZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250
YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhl
IHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29udHJv
bCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9MUiBy
ZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVy
bG9hZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24gZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9ydGlu
ZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBh
d2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVk
IG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGlj
aCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KSSBkb24ndCBh
Z3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29u
dHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0
byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdh
cmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy4N
Cg0KDQoNClVscmljaA0KDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
DQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5k
QG9yYW5nZS5jb20+IFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KDQpTZW50OiBU
aHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NCg0KVG86IE5pcmF2IFNhbG90IChu
c2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3Zh
bjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQoNCg0K
DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52
b3nDqSA6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCA6IFdpZWhlLCBVbHJpY2ggKE5T
TiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpk
aW1lQGlldGYub3JnPiBPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P
bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp
dmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KVWxyaWNoLA0KDQoNCg0KSSBhbSBub3Qgc3VyZSBhYm91
dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5l
LiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdo
ZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMg
dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4i
DQoNClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWlu
ZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0
aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZmaWMuDQoNCg0KDQpbTE1dIEFn
cmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRl
ZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhl
IHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIg
bWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9uLiBB
dCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLg0KDQoNCg0KQXMgd2UgaGFk
IGRpc2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5v
ZGUgdG8gZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0
IHRoZSBzYW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFs
bG93IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1w
IG9mIHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0Lg0KDQoNCg0KW0xNXSBBZ3JlZQ0K
DQoNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBu
b2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcgdGlt
ZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0byBpbmNsdWRlIE9M
UiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9uLg0KDQoNCg0KW0xN
XSBBZ3JlZQ0KDQoNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRo
IG1lLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5
LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNDQoNClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoN
ClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQoNCg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxlczoN
Cg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSINCg0KMi4gdGhlIHJlcG9ydGluZyBu
b2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3Qg
dG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQg
YW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUgYW4g
T0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgIm5v
IG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSBy
ZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1Qg
cmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFu
IE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZp
cm0uDQoNCg0KDQpVbHJpY2gNCg0KDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KDQpTZW50OiBXZWRuZXNk
YXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3Qp
OyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkFncmVl
ZC4gIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hh
bmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS4gIElm
IHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250
aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5
IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCByZXBvcnQuICBJZiB0aGVyZSBpcyBubyBjdXJy
ZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVw
b3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS4N
Cg0KDQoNClN0ZXZlDQoNCk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3
cm90ZToNCg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQg
bGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KDQoNCg0KV2Ug
aGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMg
cmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBp
biBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBv
ZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0
byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMg
aXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3Qg
YmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuDQoNCg0KDQpTbyBiYXNp
Y2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSBy
ZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBj
b250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0
aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBvdmVy
bG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQoNCkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBm
bGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhh
bmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KDQoNClJlZ2FyZHMsDQoNCk5p
cmF2Lg0KDQoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwg
MjAxNCA4OjAwIFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0K
DQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcNCg0KDQoNCmlubGluZQ0KDQpPbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCg0KT2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9y
dGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2Fn
ZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBP
Qy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMg
cmVxdWVzdGVkKS4NCg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/ICBTaG91bGRu
J3QgbGFjayBvZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0K
DQoNCg0KDQoNCg0KDQpPdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBz
ZWVtIHRvIG1hdHRlci4NCg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2
ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFuIG92
ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29yaywg
cG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4NCg0KDQoNCg0K
DQoNCg0KDQoNCkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZl
ZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2Vk
dXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcg
b2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0
b28gbWlzcyBhIG5ldyBPTFI/DQoNClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2Vx
dWVuY2UgbnVtYmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJy
dWFyeSAwNSwgMjAxNCA1OjI3IEFNDQoNClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVA
aWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P
bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp
dmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSSBzaGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExpb25l
bC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFu
Z2UuY29tPg0KDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQoNClRv
OiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkkgdW5k
ZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg
RE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLg0KDQpTbyB0aGUgb3B0aW9u
cyB3b3VsZCBiZToNCg0KMS0gT0MtT0xSIEFWUCBpbiBldmVyeSBhbnN3ZXINCg0KMi0gT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGlu
IHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhl
IGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQoNCg0KSWYgdGhlcmUgaXMgbm8gb3RoZXIg
Y3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQoNCg0KDQpM
aW9uZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IGRpbWUgaXNz
dWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0KDQpFbnZv
ecOpIDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5DQoNCsOAIDogTU9SQU5EIExpb25lbCBJ
TVQvT0xODQoNCkNjIDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KT2Jq
ZXQgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQojMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCiBJdCBoYXMgYmVlbiBwcm9wb3Nl
ZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMgIHRv
IGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0
ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQoNCiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGlu
ZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQoNCiBzdXJ2aXZlZCkgaXMgcGVy
Zm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyAg
dGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuICBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVz
ZSB0aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBh
IG5lZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRl
c3QgT0xSLg0KDQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1
bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQ
cyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCBjYW5ub3Qg
a25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5n
ICB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGlu
Zy4NCg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBh
bGxvd3MgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3Qg
aW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZyAgRE9JQyBlbmRwb2ludCAo
Y2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQoNCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFs
c28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQoNCiBJbiBzdW1tYXJ5
IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIHRvICBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcuDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRv
OkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZGltZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50
ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw
cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0
ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz
YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxl
IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj
dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5l
IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l
IG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l
bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo
YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl
ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k
IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1h
eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl
IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1F
IG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QN
Cg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5v
cmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1F
QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUN
Cg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u
dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0
IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz
YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy
LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z
aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu
dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z
YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g
TWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m
aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg
YnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp
dGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl
cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu
ZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v
dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y
IGZhbHNpZmllZC4KVGhhbmsgeW91LgoK

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN
CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg
NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl
LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBT
aW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpUaW1lczsNCglwYW5vc2UtMToyIDIgNiAzIDUgNCA1IDIgMyA0O30NCi8qIFN0
eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y
bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpi
bGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIi
Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlBy
Zm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBI
VE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWls
U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg
NzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+SSdtIGZpbmUgd2l0aCBhIHJlY29tbWVuZGF0aW9uLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBoYXZlIGEgZ2VuZXJhbCBjb21tZW50
OiB3aGVuIGEgTUFZIG9yIGV2ZW4gYSBTSE9VTEQgYXBwbHksIGl0IGRvZXMgbm90IG1lYW4gdGhh
dCBpdCBpcyBOT1QgdXAgdG8gdGhlIG5vZGUgdG8gZG8gb3Igbm90IHRvIGRvIHNvbWV0aGluZy4g
SXQNCiBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRp
b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFu
Y2UsIG92ZXIgYSBnaXZlbiBpbnRlcmZhY2UsIHRoZSByZWxhdGVkIHNwZWNpZmljYXRpb24gY2Fu
IHNheSB0aGF0IHNvbWUgc3RhdGVzIGFyZSBtYWludGFpbmVkIGJ5IHRoZSBzZXJ2ZXIuIEFuZCBp
dCBjb3VsZCBiZSBkZWNpZGVkDQogdG8gYWRkIHNvbWUgb3ZlcmxvYWQgcmVsYXRlZCBpbmZvIGlu
IHN1Y2ggc3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBz
dGF0ZSB0byBrbm93IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBm
b3IgaW5zdGFuY2UuIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVk
IHRvIGluY2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVzc2FnZS4gSXQgaXMganVzdCBmb3INCiBpbGx1
c3RyYXRpb24uIFRoZSBwb2ludCBpcyB0aGF0IHlvdSBtYXkgaGF2ZSBzb21lIGNhc2VzIGZvciB3
aGljaCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtaWdodCBub3QgYmUgcmVxdWlyZWQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBoYXZpbmcgdGhlIE9M
UiBpbiBldmVyeSBhbnN3ZXIgaXMgZmluZeKApiBidXQgaXQgc2hvdWxkIGJlIG5vdCBtYW5kYXRv
cnkgaW4gYWxsIGNhc2VzIEkgdGhpbmsuIFNvIE9LIGZvciBhICZxdW90O1NIT1VMRCZxdW90OyBv
ciAmcXVvdDtSRUNPTU1FTkRFRCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVs
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgW21haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBTdGV2ZSBEb25vdmFu
PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGx1bmRpIDEwIGbDqXZyaWVyIDIwMTQgMTc6MjE8
YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5PYmo8L2I+PC9zcGFu
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPmV0Jm5ic3A7
Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+
IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
bw0KIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij5JIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4g
Oi0pPGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNheWluZyB0aGUg
cmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlu
IGFsbCByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5IE1hcmlhIENy
dXouJm5ic3A7DQo8YnI+DQo8YnI+DQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmly
YXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0
aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQg
bWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4mbmJzcDsgSSBkb24ndCB0aGluayB3ZSBu
ZWVkIHRvIGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtu
b3dzDQogYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0
ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuJm5ic3A7IFRoZSBjYXNlIG9m
IGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVu
dHMgYmVpbmcgb25lIGV4YW1wbGUuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XZSBhbHNvIG5lZWQgdG8gbWFr
ZSBzdXJlIHRoYXQgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIG5vdCBwcmVjbHVkZWQgYnkg
TmlyYXYncyBwcm9wb3NhbC48YnI+DQo8YnI+DQpJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBub3Jt
YXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBNYXJpYSBDcnV6J3Mg
cmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHdh
eXMgaW5jbHVkZWQuPGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2Rl
IE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2Fk
IHJlcG9ydHMuPGJyPg0KPGJyPg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBu
b2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQg
dG8gcmVhY3Rpbmcgbm9kZXMuJm5ic3A7DQo8YnI+DQo8YnI+DQpOb3RlIC0gdGhlIHJlcG9ydGlu
ZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVz
c2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVu
dC4mbmJzcDsgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERp
YW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuPGJyPg0KPGJyPg0KQSByZXBv
cnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBh
IHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2Rl
IGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuPGJyPg0KPGJyPg0KTm90
ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRv
IGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9y
dCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBh
Z2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcgbm9kZS48YnI+DQo8YnI+
DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
Mi8xMC8xNCAzOjUyIEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPkhlbGxvIE5pcmF2LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFueSBzb2x1dGlvbiBzaG91bGQgYmFsYW5jZSBk
aWZmZXJlbnQgZmFjdG9ycywgZWZmaWNpZW5jeSBjb3VsZCBiZSBkaXNjdXNzZWQgZnJvbSBkaWZm
ZXJlbnQgcGVyc3BlY3RpdmVzLCBidXQgZmlyc3Qgd2UgbmVlZCB0byBhc3N1cmUgdGhlIG1lY2hh
bmlzbSB3ZSBhcmUgZGVmaW5pbmcgaXMgcHJvdmlkaW5nIHZhbGlkIE9MUiB0byByZWFjdGluZyBu
b2Rlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5Zb3VyIHByb3Bvc2VkIHRleHQmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7
IEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5v
ZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRl
ZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRo
ZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUC4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5JZiB0aGUgcmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3
aGV0aGVyIG9yIG5vdCBvdmVybG9hZCByZXBvcnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5n
IG5vZGUsIGFuZCBpdCBkZWNpZGVzIChzaW5jZSBpdCBpcyBhICZxdW90O21heSZxdW90OykgdG8g
ZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hh
bmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQg
YnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRv
IG5vdGUgdGhhdCAmcXVvdDtyZWFjdGluZyBub2RlcyZxdW90OyBjb3VsZCBiZSBub3Qgb25seSB0
aGUgY2xpZW50LCBidXQgQU5ZIGFnZW50IHVzZWQgZm9yIHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4g
dGhlIGFnZW50IGlzIHByb3ZpZGluZyBzZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlz
IHJlYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkuIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPlRoZW4sIG9uIG9uZSBoYW5kIGl0IGlzIG5vdCBzaW1wbGUgdG8ga25v
dyB3aGVuIHJlYWN0aW5nIG5vZGVzIGhhdmUgdmFsaWQgT0xSIGluZm8gKGFzIGV4cGxhaW5lZCBi
ZWxvdyksIGJ1dCBpZiBPTFIgaXMgbm90IHNlbnQgYWdhaW4gKGFzIHBlciB5b3VyIHByb3Bvc2Vk
ICZxdW90O21heSZxdW90OykgdGhlbiBvbmUgb3IgbXVsdGlwbGUgcmVhY3Rpbmcgbm9kZXMgZG8g
bm90IGhhdmUgdGhlIHJlcXVpcmVkIE9MUiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIHdpbGwg
bm90IHdvcmsuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+VGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3Zp
ZGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMu
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QmVz
dCByZWdhcmRzPG86cD48L286cD48L3ByZT4NCjxwcmU+L01DcnV6PG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBb
PGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29t
PC9hPl0gPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogbHVuZXMsIDEwIGRlIGZlYnJlcm8g
ZGUgMjAxNCAxMDo0MjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBNYXJpYSBDcnV6IEJhcnRv
bG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86
cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+QnV0IE1hcmlhLUNydXosPG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SG93IGNhbiB3ZSBzYXkgdGhhdCAmcXVv
dDtpbmNsdWRpbmcgdGhlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcyBpcyBzaW1wbGUg
YW5kIGVmZmljaWVudD8mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JdCBpcyBzaW1wbGUg
Zm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkEgc2xpZ2h0bHkgZGlmZmVyZW50IHdvcmRpbmcgZnJv
bSB3aGF0IEkgcHJvcG9zZWQgZWFybGllciBpcywgV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaGFz
IGEgbmV3IG92ZXJsb2FkIHJlcG9ydCB0aGF0IG5lZWRzIHRvIGJlIHByb3ZpZGVkIHRvIGEgcmVh
Y3Rpbmcgbm9kZSAoYnkgdXBkYXRpbmcgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVw
b3J0IG9yIGJ5IHByb3ZpZGluZyB0aGUgb3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUgZmlyc3QgdGlt
ZSksIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3Qg
Y29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3Bv
bmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3
aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9y
dCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5n
IG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0
IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86cD48L286cD48L3By
ZT4NCjxwcmU+TmlyYXYuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5t
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmlhIENydXog
QmFydG9sb21lPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogTW9uZGF5LCBGZWJydWFyeSAx
MCwgMjAxNCAzOjAzIFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
Pk5pcmF2LCBhbGwsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+SSB0aGluayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qg
c29sdXRpb24sIGFzIGVmZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPkkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEgcHVyZSAmcXVvdDtt
YXkmcXVvdDssIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFz
c3VyZSByZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFz
aWMgZm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPi9NQ3J1ejxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxw
cmU+RnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0bzpuc2Fsb3RAY2lz
Y28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3ByZT4NCjxw
cmU+U2VudDogbHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxMDoxMjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVA
aWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVj
dDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TWFyaWEt
Q3J1eiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5JIGZ1bGx5IGFncmVlIHdpdGggeW91IG9uICZxdW90O3NlbmRpbmcgT0xSIGluIEFMTCBhbnN3
ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPkFuZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhh
dCBpcyBteSBpbnRlbnRpb24uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJ1dCB0aGUgbWFpbiBx
dWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBp
bXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRp
bmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk1vc3QgcHJvYmFibHksIHRo
ZSB2ZXJ5IGZpcnN0IGltcGxlbWVudGF0aW9uIG9mIG92ZXJsb2FkIGNvbnRyb2wgd2lsbCBpbmNs
dWRlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5CdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2
ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNr
cyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2Uu
IEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGlu
ZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGFsc28gdGhlIHJlYXNvbiBJIHdhcyBzdWdn
ZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVkZSBPTFIgKGZyb20gdGhl
IHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86cD48L286cD48L3ByZT4NCjxw
cmU+TmlyYXYuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5G
cm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9s
b21lPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwNywgMjAx
NCA4OjU3IFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1l
QGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1Ympl
Y3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkhlbGxv
IFVscmljaCwgTmlyYXYsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+SSBhZ3JlZSB3aXRoIFVscmljaCB0aGF0IHRoZSB0ZXh0IHByb3ZpZGVkIGJ5
IE5pcmF2IGlzIGp1c3QgYSBNQVksIGFuZCB3aGV0aGVyIG9yIG5vdCB0aGUgc2VydmVyIHNlbmRz
IGFuIE9MUiBpbiBhbGwgYW5zd2VycyBzaGFsbCBub3QgYmUganVzdCBhIE1BWS48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiB0aGUgb3RoZXIg
aGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBz
ZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdlOjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBu
b2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3
YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdv
dCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Yykg
b3RoZXJ3aXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+UmVwb3J0aW5nIG5vZGUgbXVzdCBoYXZlIHNvbWUga25vd2xlZGdlIGFib3V0IE9MUiBy
ZWNlcHRpb24vc3RhdHVzIGluIHJlYWN0aW5nIG5vZGUuIEhvdyBkb2VzIHNlcnZlciBhY3F1aXJl
IHRoaXMga25vd2xlZGdlPyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UYWtlIGludG8gYWNjb3Vu
dCBhcyB3ZWxsIHRoYXQgYSAmcXVvdDtyZWFjdGluZyZxdW90OyBub2RlIG1heSBiZSBib3RoIGFu
IEFnZW50IChpbiBjYXNlIGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8gYSByZWFsbSBvciBhY3Rpbmcg
b24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KSZuYnNwOyBhbmQgYSBDbGllbnQu
IEluIHRoZSBjYXNlIG9mIEFnZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBr
bm93IGlmIHRoaXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRy
YW5zcGFyZW50bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFu
eSBrbm93bGVkZ2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBD
bGllbnQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+VGhlcmVmb3JlLCBJIGRlZmluaXRlbHkgdGhpbmsgdGhhdCBzZW5kaW5nIE9MUiBpbiBBTEwg
YW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlczo8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4tIHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNlc3Npb24p
IGlzIHNpbXBsZXIsPG86cD48L286cD48L3ByZT4NCjxwcmU+LSB0aGUgc2VydmVyIGRvZXMgbm90
IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFj
dGluZyBub2RlPG86cD48L286cD48L3ByZT4NCjxwcmU+LSB0aGUgc2VydmVyIGRvZXMgbm90IG5l
ZWQgdG8gYm90aGVyIHdoZXRoZXIgYW4gcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSByZWNlaXZl
ZCBhbiBPTFIgb3Igd2hldGhlciB0aGlzIE9MUiBpcyBzdGlsbCB2YWxpZCAoaGFzIG5vdCBleHBp
cmVkKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIHNlbmRpbmcgYW4gYWRkaXRpb25hbCBBVlAg
aXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29uIHdpdGggcmVxdWlyZWQg
YWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7IEluIGZhY3QsIGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwgdGhlIGVhc2llc3Qg
YW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVj
dGVkL2FwcGxpY2FibGUgbm9kZXMsIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBhbmQg
dGhlIGxhdHRlciBzaG91bGQgdGFrZSBjYXJlIHRvIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9ucyZu
YnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIG1vcmUgcm9idXN0IHNvbHV0aW9uLCBhcyBu
byBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhlIGNoZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5kIGlu
Zm9ybWF0aW9uLCZuYnNwOyBmb3Igc2l0dWF0aW9ucyB3aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBp
cyBsb3N0LCZuYnNwOyDigKY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5CZXN0IHJlZ2FyZHM8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4vTUNydXo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg
T2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PlNlbnQ6IHZpZXJuZXMsIDA3IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo1OTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCA8YSBocmVmPSJtYWls
dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+
OyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TmlyYXYsPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSdtIGFmcmFpZCB5b3VyIHBy
b3Bvc2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGUgaW50ZW50aW9uLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90O3doZW4gaXQgd2Fu
dHMgdG8gcHJvdmlkZS91cGRhdGUuLi4uaXQgc2hhbGwgaW5jbHVkZS4uLiZxdW90OyB0cmFuc2xh
dGVzIHRvICZxdW90Oy4uLml0IG1heSBpbmNsdWRlLi4uJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90O2luIG90aGVyIGNhc2Vz
JnF1b3Q7IGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7d2hlbiBpdCBk
b2VzIG5vdCB3YW50IHRvIHByb3ZpZGUvdXBkYXRlLi4uJnF1b3Q7PG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+V2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhh
cyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmIpIHRo
ZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEg
dGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBP
TFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Yykgb3RoZXJ3
aXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
aW4gY2FzZSBhKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBP
TFIgaW4gY2FzZSBiKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0
aGUgcmVhY3Rpbmcgbm9kZSB3aXRoIHRoZSBsYXRlc3QgT0xSIGluIGNhc2UgYykgdGhlIHJlcG9y
dGluZyBub2RlIE1VU1QgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRp
bmcgbm9kZSBkb2VzIG5vdCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIHJlcGxheSBvciBhbiB1cGRh
dGUpPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
VWxyaWNoPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkg
WzxhIGhyZWY9Im1haWx0bzpuc2Fsb3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNv
bTwvYT5dPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2
LCAyMDE0IDQ6NDkgUE08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKTsgZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IGV4dCBTdGV2ZSBEb25vdmFuOyA8
YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5VbHJpY2gsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+SXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0IHBy
b2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5Ib3cgYWJvdXQgdGhlIGZvbGxvd2luZy48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5XaGVuIHRoZSByZXBvcnRpbmcg
bm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBk
YXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rp
bmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVx
dWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29y
cmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBl
LmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQg
cmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBv
cnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJl
cXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UmVnYXJkcyw8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5OaXJhdi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgWzxhIGhyZWY9
Im1haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbSI+bWFpbHRvOnVscmljaC53aWVoZUBuc24uY29t
PC9hPl08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYs
IDIwMTQgMzo1NyBQTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBleHQgPGEgaHJlZj0ibWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9h
PjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWls
dG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5OaXJhdiwgTGlvbmVsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2
aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBw
cmluY2lwbGUgMic6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+MicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zlcmxv
YWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2Ug
dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBp
ZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFz
b25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIs
IHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBP
TFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVybG9hZCZxdW90Oywgb3IgYW4gb2xkJm5ic3A7IGJ1
dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3Zlcmxv
YWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRp
bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJu
IGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5JIGRvbid0IGFncmVlIHdpdGggTGlvbmVscyBkby13aGF0LXlvdS13
YW50IGFwcHJvYWNoLiBPdmVybG9hZCBjb250cm9sIHdpbGwgbm90IHdvcmsgd2hlbiB3ZSBhbGxv
dyB0aGUgcmVwb3J0aW5nIG5vZGUgbm90IHRvIHVwZGF0ZSByZWFjdGluZyBub2Rlcywgd2hpY2gg
YXJlIG5vdCAoc3VmZmljaWFudGx5KSBhd2FyZSBvZiB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0
dXMsIHdpdGggdXAgdG8gZGF0ZSBPTFJzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlVscmljaCZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IGV4dCA8YSBocmVmPSJtYWlsdG86bGlv
bmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+IFs8YSBo
cmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5tYWlsdG86bGlvbmVsLm1vcmFu
ZEBvcmFuZ2UuY29tPC9hPl08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBUaHVyc2RheSwg
RmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBT
dGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9y
ZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t
LS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EZSZuYnNwOzogRGlNRSBbPGEgaHJlZj0ibWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5d
IERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nDqSZuYnNwOzogamV1ZGkg
NiBmw6l2cmllciAyMDE0IDEwOjA4IMOAJm5ic3A7OiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N
dW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmci
PmRpbWVAaWV0Zi5vcmc8L2E+IE9iamV0Jm5ic3A7OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5VbHJpY2gsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRo
aXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgJnF1b3Q7b3RoZXJ3aXNlIChpLmUuIGlmIGl0
IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBv
dmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1
ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiZxdW90Ozxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBp
bmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4
cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZm
aWMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
W0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9y
IHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3
aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUg
YW5zd2VyIG1heSBkZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRh
dGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BcyB3ZSBoYWQgZGlz
Y3Vzc2VkIGVhcmxpZXIsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0
byBleHBsaWNpdGx5IHN0b3AgdGhyb3R0bGluZyBhdCBlYWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhl
IHNhbWUgdGltZS4gSW4gb3RoZXIgd29yZHMsIHRoZSByZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cg
dGhlIG5hdHVyYWwgZXhwaXJ5IG9mIHRoZSBPTFIgdG8gZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2Yg
dGhlIHNpZ25hbGluZyB0cmFmZmljIHRvd2FyZHMgaXQuPG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+W0xNXSBBZ3JlZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZXJlIG1heSBiZSBvdGhlciBj
YXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92
ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUg
aXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5v
IG92ZXJsb2FkIGNvbmRpdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5bTE1dIEFncmVlPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+UmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUg
ZmluZSB3aXRoIG1lLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5pcmF2Ljxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogV2llaGUs
IFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbPGEgaHJlZj0ibWFpbHRvOnVscmljaC53aWVoZUBu
c24uY29tIj5tYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb208L2E+XTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNPG86cD48L286
cD48L3ByZT4NCjxwcmU+VG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBTYWxvdCAobnNhbG90
KTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+QWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNp
cGxlczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4xLiBMYWNrIG9mIE9MUiBtZWFucyAmcXVvdDtu
byBjaGFuZ2UmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4yLiB0aGUgcmVwb3J0aW5nIG5v
ZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0
byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBh
biBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rp
bmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgdGhlIGxhdGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBP
TFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAmcXVv
dDtubyBvdmVybG9hZCZxdW90Oyk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUu
Li4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBu
b3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29u
dGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DYW4gcGVvcGxlIHBsZWFzZSBjb25maXJt
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlVs
cmljaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92
YW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAy
MDE0IDQ6MzUgUE08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogTmlyYXYgU2Fsb3QgKG5zYWxv
dCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPkFncmVlZC4mbmJzcDsgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFu
IG92ZXJsb2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3Rh
dGUgZm9yIHRoZSBob3N0IG9yIHJlYWxtLiZuYnNwOyBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBh
Y3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0
IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3Zl
cmxvYWQgcmVwb3J0LiZuYnNwOyBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJs
b2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUg
aXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5TdGV2ZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZTo8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5JIGFncmVlIHdpdGggU3RldmUgZXhjZXB0IHRoZSBwYXJ0ICZx
dW90O3Nob3VsZG7igJl0IGxhY2sgb2YgT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9h
ZGVkPyZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0
aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRl
IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlz
IGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVu
Y2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQu
IEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1l
IG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3LjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvIGJhc2lj
YWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3VsZCBub3QgYWZmZWN0IHRoZSBwcmV2aW91c2x5IHJl
Y2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4gVGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNv
bnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVyIE9MUiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRo
ZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUgZXhwbGljaXQgT0xSIHdpdGggJnF1b3Q7MCZx
dW90OyBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+
SW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0IHRo
ZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFjdGlu
ZyBub2RlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPlJlZ2FyZHMsPG86cD48L286cD48L3ByZT4NCjxwcmU+TmlyYXYuPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogRGlNRSBbPGEgaHJl
Zj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuPG86cD48L286cD48L3ByZT4NCjxw
cmU+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNPG86cD48L286cD48
L3ByZT4NCjxwcmU+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYu
b3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt
ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlubGluZTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPk9uIDIvNS8xNCA3OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdy
b3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBv
cnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3Nh
Z2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4g
T0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlz
IHJlcXVlc3RlZCkuPG86cD48L286cD48L3ByZT4NCjxwcmU+U1JEJmd0OyBXaHkgaW4gZXZlcnkg
YW5zd2VyIG1lc3NhZ2U/Jm5ic3A7IFNob3VsZG4ndCBsYWNrIG9mIGFuIE9MUiBiZSBpbnRlcnBy
ZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PdGhl
ciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5TUkQmZ3Q7IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBvcnQg
aW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcg
YW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sgZm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlzIGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3
b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRo
YXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2lu
Z2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3Vs
ZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmlt
aXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5p
bWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/PG86cD48L286cD48L3ByZT4NCjxwcmU+
U1JEJmd0OyBUaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+LS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBEaU1F
IFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQg
NToyNyBBTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiA8YSBocmVmPSJtYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyA8YSBocmVm
PSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5JIHNoYXJlIHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86cD48L286
cD48L3ByZT4NCjxwcmU+TmlyYXYuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIDxhIGhy
ZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBUdWVzZGF5LCBGZWJydWFyeSAw
NCwgMjAxNCA5OjA3IFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5TbyB0aGUgb3B0aW9ucyB3b3VsZCBiZTo8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4xLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICYjNDM7
IE9DLU9MUiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBl
cmZvcm1lZCBieSB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgdGhlcmUgaXMgbm8gb3Ro
ZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+TGlvbmVsPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+LS0tLS1N
ZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RGUmbmJzcDs6IGRp
bWUgaXNzdWUgdHJhY2tlciBbPGEgaHJlZj0ibWFpbHRvOnRyYWMmIzQzO2RpbWVAdHJhYy50b29s
cy5pZXRmLm9yZyI+bWFpbHRvOnRyYWMmIzQzO2RpbWVAdHJhYy50b29scy5pZXRmLm9yZzwvYT5d
PG86cD48L286cD48L3ByZT4NCjxwcmU+RW52b3nDqSZuYnNwOzogbWFyZGkgNCBmw6l2cmllciAy
MDE0IDA5OjQ5PG86cD48L286cD48L3ByZT4NCjxwcmU+w4AmbmJzcDs6IE1PUkFORCBMaW9uZWwg
SU1UL09MTjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86
ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5P
YmpldCZuYnNwOzogW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4g
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMmbmJzcDsgdG8gYmUgaW5jbHVk
ZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
Jm5ic3A7IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhl
IFNlcXVlbmNlLU51bWJlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAoVGltZVN0YW1wKSBvZiB0
aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzPG86cD48
L286cD48L3ByZT4NCjxwcmU+IHN1cnZpdmVkKSBpcyBwZXJmb3JtZWQuIEFic2VuY2Ugb2YgdGhp
cyBBVlAgaW5kaWNhdGVzIHRoYXQgY3VycmVudGx5IG5vJm5ic3A7IHRocm90dGxpbmcgaXMgcGVy
Zm9ybWVkLiZuYnNwOyBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzJm5ic3A7
IGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCB0
byB1cGRhdGUgdGhlJm5ic3A7IHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0
IE9MUi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1l
Y2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSZuYnNwOyByZXBvcnRpbmcg
bm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5n
IERPSUMmbmJzcDsgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9J
QyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyZuYnNwOyB0aGUgcmlnaHQgdGhpbmcgd2l0aCBy
ZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1c3RuZXNzIGFzIGl0IGFsbG93
cyB0aGUgcmVwb3J0aW5nIERPSUMmbmJzcDsgZW5kcG9pbnQgdG8gZGV0ZWN0IGFuZCBjb3JyZWN0
IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmcmbmJzcDsgRE9JQyBlbmRw
b2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuPG86cD48L286cD48L3ByZT4NCjxwcmU+
IFRoZSBmZWVkYmFjayBtZWNoYW5pc20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJv
bSBSRkMgNzA2OC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gSW4gc3VtbWFyeSBpdCBpcyBwcm9w
b3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0byZuYnNw
OyBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcu
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh
IGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5D
ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv
cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv
bmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp
b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg
c2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj
ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz
IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug
bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2Fn
ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxk
IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg
aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn
ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBt
YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2
ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9h
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9kaW1lPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+RGlNRSBtYWls
aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRm
Lm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg
aHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86
cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EaU1FIG1haWxpbmcgbGlzdDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPFBSRT5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl
cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2
ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv
cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs
ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl
cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw
dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg
c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK
VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs
IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK
dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1
dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl
IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp
ZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_6B7134B31289DC4FAF731D844122B36E497B0APEXCVZYM13corpora_--

From srdonovan@usdonovans.com  Mon Feb 10 08:43:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6492F1A0339 for ; Mon, 10 Feb 2014 08:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjimlxd-HyW6 for ; Mon, 10 Feb 2014 08:43:22 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 093E01A07EE for ; Mon, 10 Feb 2014 08:43:22 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57632 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCtvw-0003G4-02; Mon, 10 Feb 2014 08:42:14 -0800
Message-ID: <52F901A6.2030803@usdonovans.com>
Date: Mon, 10 Feb 2014 10:43:18 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: lionel.morand@orange.com, "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" ,  "ben@nostrum.com" 
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------010309000201010405070803"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:43:27 -0000

This is a multi-part message in MIME format.
--------------010309000201010405070803
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I would think this would be a general policy.

Steve

On 2/8/14 10:37 AM, lionel.morand@orange.com wrote:
> Hi Ben,
>
> OK with this statement.
> But if it is agreed, would it mean that the same consideration should apply for the OC-Validity-Duration AVP values?
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
> Envoyé : vendredi 7 février 2014 23:05
> À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
> Cc : dime@ietf.org
> Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be ignored
>
> #47: reduction percentages greater than 100 should be ignored
>
>  Section 4.7 says " [Reduction-Percentage] Values greater than 100 are
>  interpreted as 100."
>
>  An OLR with an invalid value should be ignored. An invalid value indicates
>  incorrect behavior on the part of the sender. In this case, it's not safe
>  to assume we know what the sender really intended.
>


--------------010309000201010405070803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I would think this would
      be a general policy.

      

      Steve

      

    
    
On 2/8/14 10:37 AM,
      lionel.morand@orange.com wrote:

    

    

      
Hi Ben,

OK with this statement.
But if it is agreed, would it mean that the same consideration should apply for the OC-Validity-Duration AVP values?

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : vendredi 7 février 2014 23:05
À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Cc : dime@ietf.org
Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be ignored

#47: reduction percentages greater than 100 should be ignored

 Section 4.7 says " [Reduction-Percentage] Values greater than 100 are
 interpreted as 100."

 An OLR with an invalid value should be ignored. An invalid value indicates
 incorrect behavior on the part of the sender. In this case, it's not safe
 to assume we know what the sender really intended.



    

    

  


--------------010309000201010405070803--

From lionel.morand@orange.com  Mon Feb 10 08:46:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFDB1A06E4 for ; Mon, 10 Feb 2014 08:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv437r5RknzS for ; Mon, 10 Feb 2014 08:46:25 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5E51A06E5 for ; Mon, 10 Feb 2014 08:46:24 -0800 (PST)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 4B1553B45A4; Mon, 10 Feb 2014 17:46:24 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 323CFC808B; Mon, 10 Feb 2014 17:46:24 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 17:46:23 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPJnjfI2eMVok1YUekD6SIQxQX6pqushTg
Date: Mon, 10 Feb 2014 16:46:23 +0000
Message-ID: <30449_1392050784_52F90260_30449_13393_1_6B7134B31289DC4FAF731D844122B36E497B94@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com>  <52F8F6FB.4070306@usdonovans.com>
In-Reply-To: <52F8F6FB.4070306@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E497B94PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.140315
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:46:32 -0000

--_000_6B7134B31289DC4FAF731D844122B36E497B94PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you for the summary.

I'm fine with all the bullets! :)

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 10 f=E9vrier 2014 16:58
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree it needs to be stated in the draft.

Steve
On 2/10/14 9:44 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi Steve

Thanks to have summarize this topic. I agree with your various statements t=
hat reflect in particular my own comments.

About mandatory for the default (loss) algorithm, effectively we  need this=
 for interoperability. Cannot it be stated in the draft? Future RFCs will h=
ave to be compatible with this .

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 10 f=E9vrier 2014 16:08
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I'll attempt to summarize where we are on this.  If this is agreed to then =
the necessary changes would be made to the -01 draft.  Some of this is alre=
ady in the draft, some of it will require changes.

- The draft already makes it optional for the reporting node to include the=
 OC-Supported-Features AVP in answer messages - No change required here.

- A reporting node must choose the overload abatement algorithm to be sent =
to a reacting node from the set of abatement algorithms included in the OC-=
Supported-Features AVP received in the request message.

- If the reporting node sends an OC-OLR AVP and there is no OC-Supported-Fe=
atures AVP then the abatement algorithm used by the reacting node must be l=
oss.

- The reporting node may include the OC-Supported-Features AVP with the los=
s algorithm indicated in the OC-Feature-Vector AVP.

- If the reporting node wants the reacting node to apply an algorithm other=
 then loss, the reacting node must include the OC-Supported-Features AVP wi=
th a single algorithm indicated in the OC-Feature-Vector AVP.

- New abatement algorithm extensions may use and extend the existing OC-OLR=
 AVP.  The new algorithms may also create a new overload report AVP if that=
 makes the most sense.

- The loss algorithm is and always will be the mandatory to implement algor=
ithm.  Or it will be until a new RFC is published that changes the mandator=
y to implement algorithm.

Steve
On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:





-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : lundi 10 f=E9vrier 2014 12:24

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages





On Feb 10, 2014, at 1:15 PM,  wrote:



Hi Jouni,



As the syntax of the OC-Feature-Vector is adapted to advertize supported al=
gos, it could be easier to clarify that the OC-OLR AVP is THE report AVP fo=
r the reduction algo (default) and a new dedicated report AVP must be creat=
ed when a new algo is introduced. In this way, the OC-OLR is self-explicit.



Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced

abatement algorithm..



[LM] The issue if when you have more than one algo (let say 2). There is no=
 way for the reporting node to indicate the algo to use with the OLR sent i=
n the answer using the OC-Feature-Vector. The only info that you could have=
 is "use either one or the other".



This we can fix (and I personally would like to fix). The reporting node

announces in its OC-Feature-Vector the selected common algorithm for the

sent OLR. We had this at some point of time, btw.



[LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY =
be used (when present) to indicate the algo to use, algo part of the common=
 algos between the reporting node and the reacting node.



The simpliest way would be to define a new AVP when you want to support mor=
e than the default algo. If you want to rely on the same OLR with another a=
lgo, you should have a way to indicate the algo to use with the given OLR.



I recall there was a strong arguments against algorithm types in OLRs..



[LM] I was not proposing such idea :)



- Jouni







It would be purely optional to send the Supported-Features AVP along with t=
he OC-OLR AVP.



It is already today if you only support the default, right.



[LM] Right. No issue here.



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages





On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:



I think that there is actually an issue here but the proposed way to solve =
it is not the correct one.



Agree.



The initial idea was to be able to use the same overload report with severa=
l algorithms. So the OLR was somehow only meaningful along with the OC-Feat=
ure-Vector AVP.



The initial idea was to go on lines of RFC5447.



But because the OC-Feature-Vector AVP is defined as a set of flags, it is n=
ot possible to say that this OLR is to be used with only one given algo whe=
n more than one is defined (as the bit flags will advertize 1 AND 2 for 2 s=
upported algos). So the OC-Feature-Vector cannot be used to indicate the ab=
atement to perform.



My intention was always allow:



 client announces  ABC

 server supports    BCD

 server announced only  e.g. C since it is common

 alternatively server announced nothing and then the default applies



As the syntax of the OC-Feature-Vector is adapted to advertize supported al=
gos, it could be easier to clarify that the OC-OLR AVP is THE report AVP fo=
r the reduction algo (default) and a new dedicated report AVP must be creat=
ed when a new algo is introduced. In this way, the OC-OLR is self-explicit.



Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced

abatement algorithm..



It would be purely optional to send the Supported-Features AVP along with t=
he OC-OLR AVP.



It is already today if you only support the default, right.



- Jouni





Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:48

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #30: OC-Supported-Features AVP in answer messages



#30: OC-Supported-Features AVP in answer messages



According to the current feature advertisement/negotiation mechanism in

the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP

in answer messages to indicate their supported OC features to the reacting

DOIC endpoint.

The author of this document believes that  the best a reacting node can do

with such information is to ignore it, and therefore proposes to allow

reporting nodes not to insert OC-Supported-Features AVPs in answer

messages.

Currently only one feature is defined (OLR_DEFAULT_ALGO).

A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other

feature is only interested in receiving/not receiving OC-OLR AVPs from

reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates

support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving

an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:



a) There is no overload

b) DOIC is not supported



The reacting DOIC endpoint does not need to differentiate between these

two cases as the behavior (do not throttle) is the same in both cases.

The -01 draft says in  clause 4.1:

  If there is no single matching

  capability the reacting node MUST act as if it does not implement

  DOIC and cease inserting any DOIC related AVPs into any Diameter

  messages with this specific reacting node.



This however is inconsistent.

The reacting node that ceases sending DOIC related AVPs would never

recognize when the server is upgraded to support DOIC.

Subsequent requests (not including DOIC related AVPs) may take a different

path towards the server and on that path there may be an agent that

supports DOIC (with a match of supported features) and could take the role

of the reporting DOIC endpoint; but the agent cannot take this role since

the reacting node (although supporting DOIC) ceased sending of OC-

Supported-Features AVPs.

In summary: As long as no extension feature is defined within  draft-ietf-

dime-ovli  (i.e. never, since extensions will  be defined in other

drafts), there is no need for draft-ietf-dime-ovli  to mandate or even

describe inclusion of OC-Supported-Features AVP in answer messages.



--

--------------------------------------+--------------------------

Reporter:  lionel.morand@orange.com  |    =
  Owner:  Ulrich Wiehe

   Type:  defect                    |     Status:  new

Priority:  major                     |  Milestone:

Component:  draft-docdt-dime-ovli     |    Version:

Severity:  Active WG Document        |   Keywords:

--------------------------------------+--------------------------



Ticket URL: 

dime 





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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


___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E497B94PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Thank you =
for the summary.


 =
;


I'm fine w=
ith all the bullets!
J


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 10 f=E9vrier 2014 16:58

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in ans=
wer messages






 


I agree it needs to b=
e stated in the draft.



Steve




On 2/10/14 9:44 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES) wrote:






Hi Steve


 <=
/p>

Thanks to have summarize =
this topic. I agree with your various statements that reflect in particular=
 my own comments.


 <=
/p>

About mandatory for the d=
efault (loss) algorithm, effectively we  need this for interoperabilit=
y. Cannot it be stated in the draft? Future RFCs will have to
 be compatible with this .


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques   


 <=
/p>

 <=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 10 f=E9vrier 2014 16:08

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in ans=
wer messages






 


I'll attempt to summa=
rize where we are on this.  If this is agreed to then the necessary ch=
anges would be made to the -01 draft.  Some of this is already in the =
draft, some of it will require changes.



- The draft already makes it optional for the reporting node to include the=
 OC-Supported-Features AVP in answer messages - No change required here.



- A reporti=
ng node must choose the overload abatement algorithm to be sent to a reacti=
ng node from the set of abatement algorithms included in the OC-Supported-F=
eatures AVP received in the request message.



- If the reporting node sends an OC-OLR AVP and there is no OC-Suppo=
rted-Features AVP then the abatement algorithm used by the reacting node mu=
st be loss.



- The reporting node may include the OC-Supported-Features AVP with the los=
s algorithm indicated in the OC-Feature-Vector AVP.



- If the reporting node wants the reacting node to apply an algorithm other=
 then loss, the reacting node must include the OC-Supported-Features AVP wi=
th a single algorithm indicated in the OC-Feature-Vector AVP.




- New abatement algorithm extensions may use and extend the existing OC-OLR=
 AVP.  The new algorithms may also create a new overload report AVP if=
 that makes the most sense.



- The loss algorithm is and always will be the mandatory to implement algor=
ithm.  Or it will be until a new RFC is published that changes the man=
datory to implement algorithm.



Steve 




On 2/10/14 5:36 AM, 
lionel.morand@orange.com wrote:






 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : lundi 10 f=E9vrier 2014 12:24


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org


Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answe=
r messages


 


 


On Feb 10, 2014, at 1:15 PM, <lionel.morand@orange.com> wrote:


 




Hi Jouni,


 




As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.




 


Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced


abatement algorithm.. 


 


[LM] The issue if when you have more than one algo (let say 2). There =
is no way for the reporting node to indicate the algo to use with the OLR s=
ent in the answer using the OC-Feature-Vector. The only info that you could=
 have is "use either one or the other".




 


This we can fix (and I personally would like to fix). The reporting no=
de


announces in its OC-Feature-Vector the selected common algorithm for t=
he


sent OLR. We had this at some point of time, btw.


 


[LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector=
 MAY be used (when present) to indicate the algo to use, algo part of the c=
ommon algos between the reporting node and the reacting node.

 




The simpliest way would be to define a new AVP when you want to suppor=
t more than the default algo. If you want to rely on the same OLR with anot=
her algo, you should have a way to indicate the algo to use with the given =
OLR.




 


I recall there was a strong arguments against algorithm types in OLRs.=
.


 


[LM] I was not proposing such idea :)


 


- Jouni


 




 


 




It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.




 


It is already today if you only support the default, right.=



 


[LM] Right. No issue here.


 


-----Message d'origine-----


De : Jouni Korhonen [mailto:=
jouni.nospam@gmail.com] 


Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer mes=
sages


 


 


On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:


 




I think that there is actually an issue here but the proposed way to s=
olve it is not the correct one.




 


Agree.


 




The initial idea was to be able to use the same overload report with s=
everal algorithms. So the OLR was somehow only meaningful along with the OC=
-Feature-Vector AVP.




 


The initial idea was to go on lines of RFC5447.


 




But because the OC-Feature-Vector AVP is defined as a set of flags, it=
 is not possible to say that this OLR is to be used with only one given alg=
o when more than one is defined (as the bit flags will advertize 1 AND 2 fo=
r 2 supported algos). So the OC-Feature-Vector cannot be used to indicate t=
he abatement to perform.




 


My intention was always allow:


 


 client announces  ABC


 server supports    BCD


 server announced only  e.g. C since it is common


 alternatively server announced nothing and then the default applies


 




As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.




 


Bah. OLR should work for additional abatement algorithms

IF we agree that the OLR is align with the announced


abatement algorithm.. 


 




It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.




 


It is already today if you only support the default, right.=



 


- Jouni


 




 


Lionel 


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:48


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #30: OC-Supported-Features AVP in answer messages<=
/o:p>


 


#30: OC-Supported-Features AVP in answer messages


 


According to the current feature advertisement/negotiation mechanism i=
n


the -01 draft reporting DOIC endpoint insert an OC-Supported-Features =
AVP


in answer messages to indicate their supported OC features to the reac=
ting


DOIC endpoint.


The author of this document believes that  the best a reacting no=
de can do


with such information is to ignore it, and therefore proposes to allow=



reporting nodes not to insert OC-Supported-Features AVPs in answer


messages.


Currently only one feature is defined (OLR_DEFAULT_ALGO).

A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no ot=
her


feature is only interested in receiving/not receiving OC-OLR AVPs from=



reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates=



support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not =
receiving


an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:


 


a) There is no overload


b) DOIC is not supported


 


The reacting DOIC endpoint does not need to differentiate between thes=
e


two cases as the behavior (do not throttle) is the same in both cases.=



The -01 draft says in  clause 4.1:


  If there is no single matching


  capability the reacting node MUST act as if it does not impleme=
nt


  DOIC and cease inserting any DOIC related AVPs into any Diamete=
r


  messages with this specific reacting node.


 


This however is inconsistent.


The reacting node that ceases sending DOIC related AVPs would never


recognize when the server is upgraded to support DOIC.


Subsequent requests (not including DOIC related AVPs) may take a diffe=
rent


path towards the server and on that path there may be an agent that


supports DOIC (with a match of supported features) and could take the =
role


of the reporting DOIC endpoint; but the agent cannot take this role si=
nce


the reacting node (although supporting DOIC) ceased sending of OC-


Supported-Features AVPs.


In summary: As long as no extension feature is defined within  dr=
aft-ietf-


dime-ovli  (i.e. never, since extensions will  be defined in=
 other


drafts), there is no need for draft-ietf-dime-ovli  to mandate or=
 even


describe inclusion of OC-Supported-Features AVP in answer messages.


 


-- 


--------------------------------------+--------------------------<=
o:p>


Reporter:  lionel.mor=
and@orange.com  |      Owner:  Ulric=
h Wiehe


   Type:  defect      &nb=
sp;            =
 |     Status:  new


Priority:  major        &=
nbsp;            |&n=
bsp; Milestone:


Component:  draft-docdt-dime-ovli     | =
   Version:


Severity:  Active WG Document      =
  |   Keywords:


--------------------------------------+--------------------------<=
o:p>


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>


dime <http://tools.ietf.=
org/wg/dime/>


 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


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 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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E497B94PEXCVZYM13corpora_--


From ben@nostrum.com  Mon Feb 10 08:50:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9842F1A0860 for ; Mon, 10 Feb 2014 08:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2hVDRt5gANo for ; Mon, 10 Feb 2014 08:50:23 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A72FD1A06E4 for ; Mon, 10 Feb 2014 08:50:17 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1AGoEAK089471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 10:50:16 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Mon, 10 Feb 2014 10:50:14 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: "ext lionel.morand@orange.com" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:50:25 -0000

On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:

> Hi Ben,
>=20
> OK with this statement.
> But if it is agreed, would it mean that the same consideration should =
apply for the OC-Validity-Duration AVP values?
>=20

I'm not sure I follow the question. Is it possible to send an invalid =
OC-Validity-Duration value?

> Lionel
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue =
tracker
> Envoy=E9 : vendredi 7 f=E9vrier 2014 23:05
> =C0 : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
> Cc : dime@ietf.org
> Objet : [Dime] [dime] #47: reduction percentages greater than 100 =
should be ignored
>=20
> #47: reduction percentages greater than 100 should be ignored
>=20
> Section 4.7 says " [Reduction-Percentage] Values greater than 100 are
> interpreted as 100."
>=20
> An OLR with an invalid value should be ignored. An invalid value =
indicates
> incorrect behavior on the part of the sender. In this case, it's not =
safe
> to assume we know what the sender really intended.
>=20
> --=20
> =
-------------------------+------------------------------------------------=
-
> Reporter:               |      Owner:  draft-docdt-dime-
>  ben@nostrum.com        |  ovli@tools.ietf.org
>     Type:  defect       |     Status:  new
> Priority:  minor        |  Milestone:
> Component:  draft-       |    Version:  1.0
>  docdt-dime-ovli        |   Keywords:
> Severity:  Active WG    |
>  Document               |
> =
-------------------------+------------------------------------------------=
-
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20


From lionel.morand@orange.com  Mon Feb 10 08:59:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088961A06F9 for ; Mon, 10 Feb 2014 08:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymfc24FC9Cg3 for ; Mon, 10 Feb 2014 08:59:18 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA981A06F6 for ; Mon, 10 Feb 2014 08:59:17 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5679422C449; Mon, 10 Feb 2014 17:59:16 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3B4AE4C099; Mon, 10 Feb 2014 17:59:16 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 17:59:15 +0100
From: 
To: Steve Donovan , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPJm3gK95DWDMaH0qQEyVc/ebDNpqus3kw
Date: Mon, 10 Feb 2014 16:59:14 +0000
Message-ID: <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com>
In-Reply-To: <52F8E495.8010404@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E497C2BPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:59:26 -0000

--_000_6B7134B31289DC4FAF731D844122B36E497C2BPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve,

In your example, if an agent has a better knowledge than the server, the Ho=
st type OLR should not be sent unmodified in forwarded answers, or even rem=
oved as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than=
 the reduction needed for a node. S1 is not overload, S2 is 50% overload, t=
he realm (S1+S2) is overloaded 25%. So only the reduction for the Host shou=
ld apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between=
 the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : lundi 10 f=E9vrier 2014 15:39
=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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_6B7134B31289DC4FAF731D844122B36E497C2BPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve,


 <=
/p>

In your ex=
ample, if an agent has a better knowledge than the server, the Host type OL=
R should not be sent unmodified in forwarded answers, or even
 removed as irrelevant.


 =
;


And in a n=
ormal case, the reduction for the realm will be likely lower than the reduc=
tion needed for a node. S1 is not overload, S2 is 50% overload,
 the realm (S1+S2) is overloaded 25%. So only the reduction for the Hos=
t should apply, why the host-type should prevail over realm-type OLR.<=
/o:p>


 =
;


By the way=
, in your proposed logic, it is not clear if the relation between the first=
 and the second conditions is an "IF NOT".



 =
;


Lionel


 =
;






De :=
 Steve Donovan [mailto:srdonovan@usdonovans.co=
m]


Envoy=E9 : lundi 10 f=E9vrier 2014 15:39

=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN=
 - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
o:p>






 


I think we have agree=
ment that a realm report applies to all traffic targeted for that realm, in=
dependent of the presence or absence of the destination-host avp.  Is =
that correct?



I don't agree with Lionel's proposal.  The realm overload report shoul=
d take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was written "except&q=
uot; :)


 


The abatement for the Realm applies when NO explicit reduction is requ=
ested for a specific node of this realm. In such a case i.e. when an OLR is=
 received for a specific node inside a realm for which a reduction also app=
lies, *ONLY* the reduction requested for the node applied.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext lionel.morand@oran=
ge.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




I better like Lionel's approach, but even that is not ok in the unlike=
ly extreme case where we have two servers in a realm, S1 is not overloaded =
at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why=
 should a client do a 25% throttling when sending host type requests to the=
 not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?


<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is applied in any case


except if there is an explicit report for the destination-host"?<=
o:p>


 


If this means the realm abatement is still applied after applying=



the host abatement, then I agree it is not the same you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; dime@ietf.org<=
o:p>


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


I tend to agree except that I would reverse the logic as for the routi=
ng principles: the Destination-host takes precedence when present over Dest=
ination-Realm. So the realm abatement is applied in any case except if ther=
e is an explicit report for the destination-host.


 


Lioenl


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


It makes more sense to me for a realm report to apply to all requests =
targeted for that realm, independent the type of request.  This implie=
s that it would apply to requests that also have a Destination-Host specifi=
ed.


 


If this is the definition of a realm report then we need to specify th=
e interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm first and the host =
second.  If a message targetted for the host is throttled as a result =
of realm overload then that throttled message would count as part of the re=
duction needed to address the host overload.  Messages to the host tha=
t survive realm abatement would then be candidates for host overload.<=
/o:p>


 


Steve


 


On 2/4/14 11:12 AM, lionel=
.morand@orange.com wrote:


The case "Realm" as described below raises another question:=
 is it prohibited for a realm to only rely on a global overload report for =
the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm" would be recei=
ved by the reacting node. And the reduction indicated in the OLR will apply=
 always for the realm, whatever the presence of Destination-host AVP in the=
 request... except if an explicit report with the type "Host" as =
been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to which requests over=
load


treatment of a given report type applies.


Proposal:


 


   0  A host report.  The overload treatment shoul=
d apply to requests


      for which all of the following conditio=
ns are true:


      a) The Destination-Host AVP is present =
in the request and its value


         matches the value of =
the Origin-Host AVP of the received message


         that contained the OC=
-OLR AVP.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overload treatment shou=
ld apply to


      requests for which all of the following=
 conditions are true:


      a) The Destination-Host AVP is absent i=
n the request.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


______________________________________________________________________=
___________________________________________________


 


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.


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


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_6B7134B31289DC4FAF731D844122B36E497C2BPEXCVZYM13corpora_--

From srdonovan@usdonovans.com  Mon Feb 10 08:59:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180721A07EE for ; Mon, 10 Feb 2014 08:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRIDNuiQ3SHo for ; Mon, 10 Feb 2014 08:59:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 762B31A06F6 for ; Mon, 10 Feb 2014 08:59:27 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57662 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCuBU-0001II-Lv for dime@ietf.org; Mon, 10 Feb 2014 08:58:20 -0800
Message-ID: <52F9056B.6010405@usdonovans.com>
Date: Mon, 10 Feb 2014 10:59:23 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030603050400030703090109"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 16:59:30 -0000

This is a multi-part message in MIME format.
--------------030603050400030703090109
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

It is possible, the range defined is zero to 24 hours.  I think the text
is correct as it says that a value out of this range should be ignored.

Steve

On 2/10/14 10:50 AM, Ben Campbell wrote:
> On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:
>
>> Hi Ben,
>>
>> OK with this statement.
>> But if it is agreed, would it mean that the same consideration should apply for the OC-Validity-Duration AVP values?
>>
> I'm not sure I follow the question. Is it possible to send an invalid OC-Validity-Duration value?
>
>> Lionel
>>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
>> Envoyé : vendredi 7 février 2014 23:05
>> À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
>> Cc : dime@ietf.org
>> Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be ignored
>>
>> #47: reduction percentages greater than 100 should be ignored
>>
>> Section 4.7 says " [Reduction-Percentage] Values greater than 100 are
>> interpreted as 100."
>>
>> An OLR with an invalid value should be ignored. An invalid value indicates
>> incorrect behavior on the part of the sender. In this case, it's not safe
>> to assume we know what the sender really intended.
>>
>> -- 
>> -------------------------+-------------------------------------------------
>> Reporter:               |      Owner:  draft-docdt-dime-
>>  ben@nostrum.com        |  ovli@tools.ietf.org
>>     Type:  defect       |     Status:  new
>> Priority:  minor        |  Milestone:
>> Component:  draft-       |    Version:  1.0
>>  docdt-dime-ovli        |   Keywords:
>> Severity:  Active WG    |
>>  Document               |
>> -------------------------+-------------------------------------------------
>>
>> Ticket URL: 
>> dime 
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------030603050400030703090109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    It is possible, the range
      defined is zero to 24 hours.  I think the text is correct as it
      says that a value out of this range should be ignored.

      

      Steve

      

    
    
On 2/10/14 10:50 AM, Ben Campbell
      wrote:

    

    

      
On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:



      

        
Hi Ben,

OK with this statement.
But if it is agreed, would it mean that the same consideration should apply for the OC-Validity-Duration AVP values?



      

      
I'm not sure I follow the question. Is it possible to send an invalid OC-Validity-Duration value?



      

        
Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : vendredi 7 février 2014 23:05
À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Cc : dime@ietf.org
Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be ignored

#47: reduction percentages greater than 100 should be ignored

Section 4.7 says " [Reduction-Percentage] Values greater than 100 are
interpreted as 100."

An OLR with an invalid value should be ignored. An invalid value indicates
incorrect behavior on the part of the sender. In this case, it's not safe
to assume we know what the sender really intended.

-- 
-------------------------+-------------------------------------------------
Reporter:               |      Owner:  draft-docdt-dime-
 ben@nostrum.com        |  ovli@tools.ietf.org
    Type:  defect       |     Status:  new
Priority:  minor        |  Milestone:
Component:  draft-       |    Version:  1.0
 docdt-dime-ovli        |   Keywords:
Severity:  Active WG    |
 Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/47>
dime <http://tools.ietf.org/wg/dime/>

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

_________________________________________________________________________________________________________________________

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.



      

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



    

    

  


--------------030603050400030703090109--

From srdonovan@usdonovans.com  Mon Feb 10 09:03:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8BC1A07E5 for ; Mon, 10 Feb 2014 09:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWXHVNPloMXC for ; Mon, 10 Feb 2014 09:03:20 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id B3D5C1A0835 for ; Mon, 10 Feb 2014 09:03:18 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57663 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCuFF-0006dm-0q; Mon, 10 Feb 2014 09:02:09 -0800
Message-ID: <52F90653.6040104@usdonovans.com>
Date: Mon, 10 Feb 2014 11:03:15 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org>
In-Reply-To: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------050609050003080305030500"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:03:24 -0000

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

My sense from recent discussions is that the lifetime of the
OC-Supported-Feature AVP is assumed to be one transaction.  This means
that the AVP must be included in all request messages sent by a reacting
node.

Steve

On 2/7/14 4:19 PM, dime issue tracker wrote:
> #49: capabilities announcement mechanism needs to be rethought
>
>  The capabilities announcement mechanism needs serious rethought.
>  Specifically, the lifetime of the state associated with a capabilities
>  announcement is unclear. It does not make sense to tie that lifetime to
>  Diameter session lifetimes, unless we expect to have different capability
>  sets for different sessions. (and it doesn't help at all for non-session
>  applications or pseudo-sessions.)
>
>  I think we either need to mandate that the capabilities are stateless,
>  that is, must be included in every request, and any OLR in a response must
>  match the OC-Supported-Features from the corresponding request.
>  Otherwise, we need a way to activate and deactivate the set associated
>  with a capabilities set.
>
>  (This is a side effect of allowing DOIC to cross non-supporting agents. If
>  we didn't allow that, we could make DOIC support and capabilites
>  negotiation happen as part of the CAR exchange. )
>


--------------050609050003080305030500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    My sense from recent
      discussions is that the lifetime of the OC-Supported-Feature AVP
      is assumed to be one transaction.  This means that the AVP must be
      included in all request messages sent by a reacting node.

      

      Steve

      

    
    
On 2/7/14 4:19 PM, dime issue tracker
      wrote:

    

    

      
#49: capabilities announcement mechanism needs to be rethought

 The capabilities announcement mechanism needs serious rethought.
 Specifically, the lifetime of the state associated with a capabilities
 announcement is unclear. It does not make sense to tie that lifetime to
 Diameter session lifetimes, unless we expect to have different capability
 sets for different sessions. (and it doesn't help at all for non-session
 applications or pseudo-sessions.)

 I think we either need to mandate that the capabilities are stateless,
 that is, must be included in every request, and any OLR in a response must
 match the OC-Supported-Features from the corresponding request.
 Otherwise, we need a way to activate and deactivate the set associated
 with a capabilities set.

 (This is a side effect of allowing DOIC to cross non-supporting agents. If
 we didn't allow that, we could make DOIC support and capabilites
 negotiation happen as part of the CAR exchange. )



    

    

  


--------------050609050003080305030500--

From srdonovan@usdonovans.com  Mon Feb 10 09:06:20 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94C1A06DE for ; Mon, 10 Feb 2014 09:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-CpKZOUzzSv for ; Mon, 10 Feb 2014 09:06:19 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 178041A0500 for ; Mon, 10 Feb 2014 09:06:19 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57674 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCuIB-0003nH-C5; Mon, 10 Feb 2014 09:05:11 -0800
Message-ID: <52F9070A.8080608@usdonovans.com>
Date: Mon, 10 Feb 2014 11:06:18 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com
References: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org>
In-Reply-To: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------010300030806050906000501"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #43: Overstated guidance on session-ending requests.
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:06:20 -0000

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

Section 3.1.4 is not normative and says:

The following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document.
Exact behavior regarding throttling must be defined per application.

Do you think we need further clarification that application designers
should reflect that local policy applies?

Steve


On 2/7/14 3:34 PM, dime issue tracker wrote:
> #43: Overstated guidance on session-ending requests.
>
>  In section 3.1.4, under "Intra-Session Requests" indicates that session
>  ending requests should be throttled less aggressively. While I agree
>  that's a good idea in general, I think that's a mater of local policy, and
>  not up to DOIC to specify.
>
>  It would be better to indicate that prioritization under overload is up to
>  local policy, and list prioritizing of session-ending requests as an
>  example of a potential local policy.
>


--------------010300030806050906000501
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Section 3.1.4 is not
      normative and says:

    
      
    
    
The following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document.
Exact behavior regarding throttling must be defined per application.

    Do you think we need
      further clarification that application designers should reflect
      that local policy applies?

      

      Steve

      

      

    
    
On 2/7/14 3:34 PM, dime issue tracker
      wrote:

    

    

      
#43: Overstated guidance on session-ending requests.

 In section 3.1.4, under "Intra-Session Requests" indicates that session
 ending requests should be throttled less aggressively. While I agree
 that's a good idea in general, I think that's a mater of local policy, and
 not up to DOIC to specify.

 It would be better to indicate that prioritization under overload is up to
 local policy, and list prioritizing of session-ending requests as an
 example of a potential local policy.



    

    

  


--------------010300030806050906000501--

From srdonovan@usdonovans.com  Mon Feb 10 09:06:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECCB1A06DE for ; Mon, 10 Feb 2014 09:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiFP548tc3oJ for ; Mon, 10 Feb 2014 09:06:57 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8F61A0500 for ; Mon, 10 Feb 2014 09:06:57 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57679 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCuIm-0004p9-DU; Mon, 10 Feb 2014 09:05:50 -0800
Message-ID: <52F9072F.3040507@usdonovans.com>
Date: Mon, 10 Feb 2014 11:06:55 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com
References: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org>
In-Reply-To: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------080704010108070206080205"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #37: Inconsistent name and abbreviation
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:06:59 -0000

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

I vote for DOIC, as I have already used it in extension drafts.

Steve

On 2/7/14 2:31 PM, dime issue tracker wrote:
> #37: Inconsistent name and abbreviation
>
>  The introduction refers to the mechanism as Diameter Overload Control
>  (DOC). Elsewhere it's Diameter Overload Information Conveyance (DOIC). We
>  need to pick one and stick with it.
>


--------------080704010108070206080205
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    I vote for DOIC, as I
      have already used it in extension drafts.

      

      Steve

      

    
    
On 2/7/14 2:31 PM, dime issue tracker
      wrote:

    

    

      
#37: Inconsistent name and abbreviation

 The introduction refers to the mechanism as Diameter Overload Control
 (DOC). Elsewhere it's Diameter Overload Information Conveyance (DOIC). We
 need to pick one and stick with it.



    

    

  


--------------080704010108070206080205--

From srdonovan@usdonovans.com  Mon Feb 10 09:07:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB71A0500 for ; Mon, 10 Feb 2014 09:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CNu1_PwtEAj for ; Mon, 10 Feb 2014 09:07:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id CF2881A06DE for ; Mon, 10 Feb 2014 09:07:52 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57682 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCuJb-0006NV-Vd; Mon, 10 Feb 2014 09:06:45 -0800
Message-ID: <52F90762.4080508@usdonovans.com>
Date: Mon, 10 Feb 2014 11:07:46 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Jouni Korhonen , lionel.morand@orange.com
References: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org> <26607_1391620178_52F27052_26607_6697_1_6B7134B31289DC4FAF731D844122B36E4876CC@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030504070300070304080708"
X-OutGoing-Spam-Status: No, score=-2.9
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
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #28: Report type support in capabilities?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:07:56 -0000

This is a multi-part message in MIME format.
--------------030504070300070304080708
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I'm sold.

Steve
On 2/7/14 4:23 AM, Jouni Korhonen wrote:
> Agree.
>
> On Feb 5, 2014, at 7:09 PM, lionel.morand@orange.com wrote:
>
>> The default mechanism implies that a client will be able to manage both types of report. Therefore there is no need at this stage IMHO.
>>
>> In future, if there is a need to explicitly indicate which report type a node support, it may be a hint for defining different capabilities/algos. And this new capability will be described a new companion document.
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
>> Envoyé : vendredi 31 janvier 2014 23:16
>> À : draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
>> Cc : dime@ietf.org
>> Objet : [Dime] [dime] #28: Report type support in capabilities?
>>
>> #28: Report type support in capabilities?
>>
>> This applies to draft-ietf-dime-ovli
>>
>> This is more of a question than an issue.
>>
>> We currently only include the abatement algorithm in the OC-Feature-Vector
>> AVP.  The question is whether we should expand it to include support for
>> the host(server) report and realm report.
>>
>> The reason for the question is that the agent overload extension will
>> likely include an indicator in the OC-Feature-Vector of support for the
>> peer report type.
>>
>> -- 
>> -------------------------------------+-------------------------------------
>> Reporter:                           |      Owner:  draft-docdt-dime-
>>  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
>>     Type:  defect                   |     Status:  new
>> Priority:  minor                    |  Milestone:
>> Component:  draft-docdt-dime-ovli    |    Version:
>> Severity:  Submitted WG Document    |   Keywords:
>> -------------------------------------+-------------------------------------
>>
>> Ticket URL: 
>> dime 
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


--------------030504070300070304080708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I'm sold.

      

      Steve

    
    
On 2/7/14 4:23 AM, Jouni Korhonen
      wrote:

    

    

      
Agree.

On Feb 5, 2014, at 7:09 PM, lionel.morand@orange.com wrote:



      

        
The default mechanism implies that a client will be able to manage both types of report. Therefore there is no need at this stage IMHO.

In future, if there is a need to explicitly indicate which report type a node support, it may be a hint for defining different capabilities/algos. And this new capability will be described a new companion document.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : vendredi 31 janvier 2014 23:16
À : draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc : dime@ietf.org
Objet : [Dime] [dime] #28: Report type support in capabilities?

#28: Report type support in capabilities?

This applies to draft-ietf-dime-ovli

This is more of a question than an issue.

We currently only include the abatement algorithm in the OC-Feature-Vector
AVP.  The question is whether we should expand it to include support for
the host(server) report and realm report.

The reason for the question is that the agent overload extension will
likely include an indicator in the OC-Feature-Vector of support for the
peer report type.

-- 
-------------------------------------+-------------------------------------
Reporter:                           |      Owner:  draft-docdt-dime-
 srdonovan@usdonovans.com           |  ovli@tools.ietf.org
    Type:  defect                   |     Status:  new
Priority:  minor                    |  Milestone:
Component:  draft-docdt-dime-ovli    |    Version:
Severity:  Submitted WG Document    |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/28>
dime <http://tools.ietf.org/wg/dime/>

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

_________________________________________________________________________________________________________________________

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.

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


      

      



    

    

  


--------------030504070300070304080708--

From srdonovan@usdonovans.com  Mon Feb 10 09:11:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E31A0500 for ; Mon, 10 Feb 2014 09:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdMk-KAO6lzw for ; Mon, 10 Feb 2014 09:10:55 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id C42B51A01DA for ; Mon, 10 Feb 2014 09:10:53 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57684 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCuMb-0002q6-6q; Mon, 10 Feb 2014 09:09:46 -0800
Message-ID: <52F9081C.8040204@usdonovans.com>
Date: Mon, 10 Feb 2014 11:10:52 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Jouni Korhonen 
References: <52F0EB22.8090804@usdonovans.com> <80E5E47E-9AD1-432F-9CA5-BA7D3D73D894@gmail.com>
In-Reply-To: <80E5E47E-9AD1-432F-9CA5-BA7D3D73D894@gmail.com>
Content-Type: multipart/alternative; boundary="------------020100070905010001030009"
X-OutGoing-Spam-Status: No, score=-2.9
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
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC endpoint behavior - Agent Overload Report handling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:11:01 -0000

This is a multi-part message in MIME format.
--------------020100070905010001030009
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This is part of the need for a definition of endpoints.  I will wait to
reply until we have resolved that question.

Steve

On 2/7/14 3:45 AM, Jouni Korhonen wrote:
> Comments inline:
>
> On Feb 4, 2014, at 3:29 PM, Steve Donovan  wrote:
>
>> The following wording is proposed to be added to section 5.5 on Overload Report Processing.
>>
>> This goes along with the proposed wording for agent involvement in capability exchange.
>>
>> The most important piece of behavior proposed is for the case when the agent is a back-to-back DOIC association agent as illustrated here:
>>
>>   DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node
>>
>> In this case, it is proposed that when the DOC agent receives a host or realm overload report the DOC agent simply passes it on without taking further action.  The goal being to do the overload abatement as close to the source of the request as possible.
>>
>> The text isn't perfect yet, but I wanted to get the basic behavior proposal across.
>>
>> Regards,
>>
>> Steve
>>
>> 5.5.4 Agent Considerations
>>
>> As discussed in section x.x.x, agents can take on the role of reporting node and reacting node.
>>
>> Agent as reporting node
>>
>> A DOC agent will take on the role of a reporting node any time that there is a downstream DOIC association.
>>
>> For the report types supporting in this document, an agent should only originate an overload report in two cases:
>>
>> - When the agent is acting as overload authority for a set of servers.  In this case, requests are sent to the destination-host of the agent and the agent is responsible for reporting on the overload state when the server farm represented by that destination-host value is entering an overloaded condition.
> Makes sense and is inline what I originally thought.
>
>> - When the agent is acting as overload authority for a realm.  In this case, the agent is responsible for inserting realm based overload reports into answer messages from servers in that realm.
> Ok.
>
>> Agent as reacting node
>>
>> An agent will take on the role of a reacting node whenever there is an upstream DOIC association.  In this case, the agent will be reacting to host overload reports.
>>
>> The behavior of the agent acting as a reacting node depends on whether or not there is a downstream association.
>>
>> If there is a downstream DOIC association then the DOC agent should pass any overload report on to the downstream Diameter node without taking any further action.
>>
>>   Note: This is based on the assumption that it is best to handle the overload instance as close to the source of the Diameter transaction as possible.
>>
>>   Note: This is not a must because there could be operator specific policies that result in handling of the overload condition in the agent.
> I kind of agree Ulrich's concern here. If the two
> associations have different supported features some
> modifications may be needed on the OLRs. However, I
> also think the "the DOC agent should pass any" is
> enough to cover the case Ulrich points at, assuming
> we note the case where downstream and upstream
> associations have different capabilities.
>
>> If there is no downstream DOIC association then the DOC agent is responsible for handling the overload condition.  In this case the DOC agent must throttle requests targeted for the host or realm indicated in the overload report.  The method used should be consistent with the considerations outlined in section 5.5.2.
> Ok.
>
> - Jouni
>
>> When a request message is selected for throttling, the DOC agent must generate the appropriate error response message.
>>
>> Editors note: the error message to be sent is TBD.
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


--------------020100070905010001030009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    This is part of the need
      for a definition of endpoints.  I will wait to reply until we have
      resolved that question.

      

      Steve

      

    
    
On 2/7/14 3:45 AM, Jouni Korhonen
      wrote:

    

    

      
Comments inline:

On Feb 4, 2014, at 3:29 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
The following wording is proposed to be added to section 5.5 on Overload Report Processing.

This goes along with the proposed wording for agent involvement in capability exchange.

The most important piece of behavior proposed is for the case when the agent is a back-to-back DOIC association agent as illustrated here:

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node

In this case, it is proposed that when the DOC agent receives a host or realm overload report the DOC agent simply passes it on without taking further action.  The goal being to do the overload abatement as close to the source of the request as possible.

The text isn't perfect yet, but I wanted to get the basic behavior proposal across.

Regards,

Steve

5.5.4 Agent Considerations

As discussed in section x.x.x, agents can take on the role of reporting node and reacting node.

Agent as reporting node

A DOC agent will take on the role of a reporting node any time that there is a downstream DOIC association.

For the report types supporting in this document, an agent should only originate an overload report in two cases:

- When the agent is acting as overload authority for a set of servers.  In this case, requests are sent to the destination-host of the agent and the agent is responsible for reporting on the overload state when the server farm represented by that destination-host value is entering an overloaded condition.


      

      
Makes sense and is inline what I originally thought.



      

        
- When the agent is acting as overload authority for a realm.  In this case, the agent is responsible for inserting realm based overload reports into answer messages from servers in that realm.


      

      
Ok.



      

        
Agent as reacting node

An agent will take on the role of a reacting node whenever there is an upstream DOIC association.  In this case, the agent will be reacting to host overload reports.

The behavior of the agent acting as a reacting node depends on whether or not there is a downstream association.

If there is a downstream DOIC association then the DOC agent should pass any overload report on to the downstream Diameter node without taking any further action.

  Note: This is based on the assumption that it is best to handle the overload instance as close to the source of the Diameter transaction as possible.

  Note: This is not a must because there could be operator specific policies that result in handling of the overload condition in the agent.


      

      
I kind of agree Ulrich's concern here. If the two
associations have different supported features some
modifications may be needed on the OLRs. However, I
also think the "the DOC agent should pass any" is
enough to cover the case Ulrich points at, assuming
we note the case where downstream and upstream
associations have different capabilities.



      

        
If there is no downstream DOIC association then the DOC agent is responsible for handling the overload condition.  In this case the DOC agent must throttle requests targeted for the host or realm indicated in the overload report.  The method used should be consistent with the considerations outlined in section 5.5.2.


      

      
Ok.

- Jouni



      

        
When a request message is selected for throttling, the DOC agent must generate the appropriate error response message.

Editors note: the error message to be sent is TBD.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


      

      



    

    

  


--------------020100070905010001030009--

From lionel.morand@orange.com  Mon Feb 10 09:12:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C221A03BF for ; Mon, 10 Feb 2014 09:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A925YWsSh9o7 for ; Mon, 10 Feb 2014 09:12:26 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3CC1A06F4 for ; Mon, 10 Feb 2014 09:12:26 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id E8D393746F3; Mon, 10 Feb 2014 18:12:25 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id CC977180056; Mon, 10 Feb 2014 18:12:25 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 18:12:25 +0100
From: 
To: Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] [dime] #41: Need better overview
Thread-Index: AQHPJn5lT5DxkanaU024JqRTea0JVZqun3iAgAAXEdA=
Date: Mon, 10 Feb 2014 17:12:24 +0000
Message-ID: <7078_1392052345_52F90879_7078_18362_1_6B7134B31289DC4FAF731D844122B36E497CEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> <8933_1391878974_52F6633D_8933_14099_1_6B7134B31289DC4FAF731D844122B36E49395B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F90040.6020909@usdonovans.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.83016
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #41: Need better overview
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:12:29 -0000

I would like to clarify this point.

Now, it is a WG document and not anymore an individual submission.
So we need someone to edit the document but anyone can propose a text for d=
iscussion to modify/update the draft.

I don't think that it is need to formally assign the issue someone responsi=
ble for updating thedraft. We just need to converge as soon as possible on =
a text via the mailing list.

Lionel


-----Message d'origine-----
De=A0: Ben Campbell [mailto:ben@nostrum.com]=20
Envoy=E9=A0: lundi 10 f=E9vrier 2014 17:39
=C0=A0: Steve Donovan
Cc=A0: MORAND Lionel IMT/OLN; dime@ietf.org; draft-docdt-dime-ovli@tools.ie=
tf.org
Objet=A0: Re: [Dime] [dime] #41: Need better overview

I can volunteer for that, with the caveat that it probably won't happen bef=
ore the IETF89 draft deadline.

On Feb 10, 2014, at 10:37 AM, Steve Donovan  wrot=
e:

> I think the way to handle this issue in the issue tracker is to assign it=
 to one of the authors and that author would then be responsible for genera=
ting overview text.
>=20
> Steve
>=20
> On 2/8/14 11:02 AM, lionel.morand@orange.com wrote:
>> Hi Ben,
>>=20
>> Any proposal?
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : DiME [
>> mailto:dime-bounces@ietf.org
>> ] De la part de dime issue tracker
>> Envoy=E9 : vendredi 7 f=E9vrier 2014 21:55
>> =C0 :=20
>> draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
>>=20
>> Cc :=20
>> dime@ietf.org
>>=20
>> Objet : [Dime] [dime] #41: Need better overview
>>=20
>> #41: Need better overview
>>=20
>>  The overview is short on explanation. We need a high level, non-normati=
ve
>>  "how it works" description of the mechanism, including roles,
>>  responsibilities, associations, and information flows. This doesn't need
>>  too much detail (e.g. message and AVP definitions belong elsewhere.)
>>=20
>>  Some of the information in the endpoint architecture section would be
>>  better off here.
>>=20
>>=20
>=20


___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From lionel.morand@orange.com  Mon Feb 10 09:14:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403DD1A0322 for ; Mon, 10 Feb 2014 09:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDpk13npaw1b for ; Mon, 10 Feb 2014 09:14:43 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 98ED81A0105 for ; Mon, 10 Feb 2014 09:14:43 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id C4EC0C0A85; Mon, 10 Feb 2014 18:14:42 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A18C0158079; Mon, 10 Feb 2014 18:14:42 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 18:14:42 +0100
From: 
To: Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] [dime] #39: Definition of Diameter Routing
Thread-Index: AQHPJEUGqbnG5Xa8gUiUuN1o70Nx0ZqqMZ8AgAFjT7CAAylhgA==
Date: Mon, 10 Feb 2014 17:14:41 +0000
Message-ID: <32584_1392052482_52F90902_32584_4735_1_6B7134B31289DC4FAF731D844122B36E497D21@PEXCVZYM13.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.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.101514
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #39: Definition of Diameter Routing
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:14:48 -0000

Hi Steve,

If I'm correct, the right ticket content is the following one.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com
Envoy=E9=A0: samedi 8 f=E9vrier 2014 18:00
=C0=A0: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Objet=A0: Re: [Dime] [dime] #39: Definition of Diameter Routing

Hi Ben,

The "XXX" refers to Diameter application designers.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoy=E9=A0: vendredi 7 f=E9vrier 2014 21:45
=C0=A0: draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #39: Definition of Diameter Routing

#39: Definition of Diameter Routing


Comment (by ben@nostrum.com):

 (Oops, sent to soon). The last sentence says "It is possible to enhance
 the routing decision with application-level knowledge..." The passive
 voice obscures the responsibility. What actor may do this? (I suggest
 recasting the sentence as "XXX may enhance..."

--=20
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 

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

___________________________________________________________________________=
______________________________________________

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.

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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From srdonovan@usdonovans.com  Mon Feb 10 09:24:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C41C1A0835 for ; Mon, 10 Feb 2014 09:24:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wSlG8-kltKK for ; Mon, 10 Feb 2014 09:24:30 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id C70021A0406 for ; Mon, 10 Feb 2014 09:24:30 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57697 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCuZg-0006mR-Qh for dime@ietf.org; Mon, 10 Feb 2014 09:23:23 -0800
Message-ID: <52F90B46.4060708@usdonovans.com>
Date: Mon, 10 Feb 2014 11:24:22 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> <78300994-0C77-47B5-B28E-D03048916AF3@gmail.com>
In-Reply-To: <78300994-0C77-47B5-B28E-D03048916AF3@gmail.com>
Content-Type: multipart/alternative; boundary="------------010404000907080006000006"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:24:36 -0000

This is a multi-part message in MIME format.
--------------010404000907080006000006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

If we agree that the lifetime of the OC-Supported-Features capability
advertisement is a single transaction then the utility of the sequence
number is reduced. 

My reason for pushing for having the sequence number originally was
based on the assumption that the capability advertised by a reacting
node was semi permanent.  While there might be no earthly use, the
heavenly use was to decrease the work for reporting nodes needing to
parse the AVP on every request received. 

It is still the case that the OC-Supported-Features AVP contents will
almost never change.  The contents of the AVP will also become more
complex as new extensions are defined.  The value of the sequence number
is to allow a reporting node to save the advertisement and not parse the
full content of the AVP unless the sequence number changes. 

I still think there is enough value in the reduced work on a reporting
node to keep the sequence number.

Steve

On 2/7/14 2:01 AM, Jouni Korhonen wrote:
> Finally catching up with these.. see inline.
>
>
> On Feb 4, 2014, at 10:46 AM, dime issue tracker  wrote:
>
>> #29: OC-Sequence-Number in OC-Supported-Features
>>
>> According to the current definition of the OC-Supported-Features AVP in
>> the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence-
>> Number AVP.
>> The author of this document believes that OC-Sequence-Number within OC-
>> Supported-Feature is  not needed, is useless and could be misleading and
>> therefore proposes to remove OC-Sequence-Number from OC-Supported-Feature.
>>
>> The -01 draft says in clause 4.1:
>>    The OC-Sequence-Number AVP is used to indicate whether the contents
>>    of the OC-Supported-Features AVP has changed since last time the node
>>    included the OC-Supported-Features AVP (see Section 4.4).  Although
>>    sending the OC-Sequence-Number AVP is mandatory in the OC-Supported-
>>    Features AVP, the receiving node MAY always choose to ignore the
>>    sequence number if it can determine the feature support changes
>>    otherwise.
>>
>> The text seems to imply that the reporting DOIC endpoint, when receiving
>> an application request message that contains an OC-Supported-Features AVP,
>> needs to determine whether a feature support change occured (either by
>> checking the value of the received sequence-number (probably) against a
>> stored value, or by other unspecified means). However,  this is not
>> correct. The reporting DOIC endpoint may  ignore the sequence-number even
>> if it cannot determine whether or not a feature support change occured:
>> The reporting DOIC endpoint simply takes the value of the OC-Feature-
>> Vector as received in the request  into account (if absent the default
>> value applies) when processing the request.  There is no need for the
>> reporting DOIC endpoint to know whether a previous request contained the
>> same or a different value in OC-Feature-Vector, i.e. whether there was a
>> recent change.
> This is true for the current default algorithm. May not be true in the
> future. Note, in IETF space versioning Diameter applications is not that
> straight forward as in 3GPP, thus I would rather have forward looking
> solution, even if that in places would mean "placeholder" AVPs.
>
>> It has been argued that the reporting DOIC endpoint may (optionally)
>> benefit from the presence of a Sequence-Number within OC-Supported-
>> Features: The reporting DOIC endpoint may have stored the Sequence-Number
>> and Feature-Vector as received in a previous request, and when receiving a
>> new request the reporting DOIC endpoint would compare the received
>> Sequence-Number from the new request  with the stored Sequence-Number;  If
>> they match (i.e. no change of supported features occured) the reporting
>> DOIC endpoint would ignore the received Feature-Vector from the new
>> request and use the stored Feature-Vector for further processing; if they
>> don't match (i.e. a change of supported features occured), the reporting
>> DOIC endpoint would update the stored Sequence-Number and Feature-Vector
>> with the received values from the new request and use the updated Feature-
>> Vector for further processing. While it is debatable whether the described
>> usecase is reasonable, the following issues have not been addressed:
>> In configurations where the client does not support DOIC, an agent (A1) on
>> a path from client to reporting DOIC endpoint (e.g. server) may take the
>> role of a reacting DOIC endpoint and insert an OC-Supported-Features AVP
>> in the (first) request message indicating its supported features.  A
>> subsequent request message sent from the same client to the same server
>> may take another path on which another agent (A2) takes the role of the
>> reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP in
>> the subsequent request message indicating its supported features (which
>> may be different from A1's supported features but may have the same
>> sequence number).  Since the reporting DOIC endpoint (e.g.server) - when
> Since seq-no is NTP time, this would not happen, excluding cases
> where clocks either in A1 or A2 are wrong. But that is a different
> issue then..
>
>> receiving the subsequent request - cannot know whether the the reacting
>> DOIC endpoint that inserted the OC-Supported-Features AVP in the
>> subsequent request is identical to or different from the reacting DOIC
>> endpoint that inserted the OC-Supported-Features AVP in the first request,
> Right.
>
>> it may frequently occure that the reporting DOIC endpoint receives request
>> messages containing an OC-Supported-Features AVP with a Sequence-Number
>> valuelower than the stored value (which may be interpreted as error), or
>> equal to the stored value but with a different associated Feature Vector,
>> or higher than the stored value but unmodified Feature Vector.
> See the above comment on the NPT.
>
>> In summary, the Sequence-Number within OC-Supported-Features is of no
>> earthly use since the reporting DOIC endpoint cannot associate a received
>> Sequence-Number (within OC-Supported-Features) with the identity of the
>> reacting DOIC endpoint that sent the Sequence-Number.  Even when such
>> association was possible by enhancing the OC-Supported-Features AVP with
>> the Diameter Identity of the reacting DOIC endpoint that generated the
>> Sequence-Number,  it would still simply not be needed as the reporting
>> DOIC endpoint can base its processing on the received Feature-Vector
>> (rather than on a stored Feature Vector).
> I buy the reasoning for the lack of binding between the reacting node
> identity and the supported features AVP.
>
> However, we should not assume that _all_ implementations will behave
> as expected above i.e. not storing the feature vector.
>
>> It is therefore proposed to remove the OC-Sequence-Number AVP from the OC-
>> Supported Features AVP.
> I have no (more) strong view here. If folks are OK to remove
> the seq-no, so be it.
>
> - Jouni
>
>
>
>> -- 
>> ----------------------------------------------+--------------------------
>> Reporter:  lionel.morand@orange-ftgroup.com  |      Owner:  Ulrich Wiehe
>>     Type:  defect                            |     Status:  new
>> Priority:  major                             |  Milestone:
>> Component:  draft-docdt-dime-ovli             |    Version:  2.0
>> Severity:  Active WG Document                |   Keywords:
>> ----------------------------------------------+--------------------------
>>
>> Ticket URL: 
>> 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
>


--------------010404000907080006000006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    If we agree that the
      lifetime of the OC-Supported-Features capability advertisement is
      a single transaction then the utility of the sequence number is
      reduced.  

      

      My reason for pushing for having the sequence number originally
      was based on the assumption that the capability advertised by a
      reacting node was semi permanent.  While there might be no earthly
      use, the heavenly use was to decrease the work for reporting nodes
      needing to parse the AVP on every request received.  

      

      It is still the case that the OC-Supported-Features AVP contents
      will almost never change.  The contents of the AVP will also
      become more complex as new extensions are defined.  The value of
      the sequence number is to allow a reporting node to save the
      advertisement and not parse the full content of the AVP unless the
      sequence number changes.  

      

      I still think there is enough value in the reduced work on a
      reporting node to keep the sequence number.

      

      Steve

      

    
    
On 2/7/14 2:01 AM, Jouni Korhonen
      wrote:

    

    

      
Finally catching up with these.. see inline.


On Feb 4, 2014, at 10:46 AM, dime issue tracker <trac+dime@trac.tools.ietf.org> wrote:



      

        
#29: OC-Sequence-Number in OC-Supported-Features

According to the current definition of the OC-Supported-Features AVP in
the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence-
Number AVP.
The author of this document believes that OC-Sequence-Number within OC-
Supported-Feature is  not needed, is useless and could be misleading and
therefore proposes to remove OC-Sequence-Number from OC-Supported-Feature.

The -01 draft says in clause 4.1:
   The OC-Sequence-Number AVP is used to indicate whether the contents
   of the OC-Supported-Features AVP has changed since last time the node
   included the OC-Supported-Features AVP (see Section 4.4).  Although
   sending the OC-Sequence-Number AVP is mandatory in the OC-Supported-
   Features AVP, the receiving node MAY always choose to ignore the
   sequence number if it can determine the feature support changes
   otherwise.

The text seems to imply that the reporting DOIC endpoint, when receiving
an application request message that contains an OC-Supported-Features AVP,
needs to determine whether a feature support change occured (either by
checking the value of the received sequence-number (probably) against a
stored value, or by other unspecified means). However,  this is not
correct. The reporting DOIC endpoint may  ignore the sequence-number even
if it cannot determine whether or not a feature support change occured:
The reporting DOIC endpoint simply takes the value of the OC-Feature-
Vector as received in the request  into account (if absent the default
value applies) when processing the request.  There is no need for the
reporting DOIC endpoint to know whether a previous request contained the
same or a different value in OC-Feature-Vector, i.e. whether there was a
recent change.


      

      
This is true for the current default algorithm. May not be true in the
future. Note, in IETF space versioning Diameter applications is not that
straight forward as in 3GPP, thus I would rather have forward looking
solution, even if that in places would mean "placeholder" AVPs.



      

        
It has been argued that the reporting DOIC endpoint may (optionally)
benefit from the presence of a Sequence-Number within OC-Supported-
Features: The reporting DOIC endpoint may have stored the Sequence-Number
and Feature-Vector as received in a previous request, and when receiving a
new request the reporting DOIC endpoint would compare the received
Sequence-Number from the new request  with the stored Sequence-Number;  If
they match (i.e. no change of supported features occured) the reporting
DOIC endpoint would ignore the received Feature-Vector from the new
request and use the stored Feature-Vector for further processing; if they
don't match (i.e. a change of supported features occured), the reporting
DOIC endpoint would update the stored Sequence-Number and Feature-Vector
with the received values from the new request and use the updated Feature-
Vector for further processing. While it is debatable whether the described
usecase is reasonable, the following issues have not been addressed:
In configurations where the client does not support DOIC, an agent (A1) on
a path from client to reporting DOIC endpoint (e.g. server) may take the
role of a reacting DOIC endpoint and insert an OC-Supported-Features AVP
in the (first) request message indicating its supported features.  A
subsequent request message sent from the same client to the same server
may take another path on which another agent (A2) takes the role of the
reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP in
the subsequent request message indicating its supported features (which
may be different from A1's supported features but may have the same
sequence number).  Since the reporting DOIC endpoint (e.g.server) - when


      

      
Since seq-no is NTP time, this would not happen, excluding cases
where clocks either in A1 or A2 are wrong. But that is a different
issue then..



      

        
receiving the subsequent request - cannot know whether the the reacting
DOIC endpoint that inserted the OC-Supported-Features AVP in the
subsequent request is identical to or different from the reacting DOIC
endpoint that inserted the OC-Supported-Features AVP in the first request,


      

      
Right.



      

        
it may frequently occure that the reporting DOIC endpoint receives request
messages containing an OC-Supported-Features AVP with a Sequence-Number
valuelower than the stored value (which may be interpreted as error), or
equal to the stored value but with a different associated Feature Vector,
or higher than the stored value but unmodified Feature Vector.


      

      
See the above comment on the NPT.



      

        
In summary, the Sequence-Number within OC-Supported-Features is of no
earthly use since the reporting DOIC endpoint cannot associate a received
Sequence-Number (within OC-Supported-Features) with the identity of the
reacting DOIC endpoint that sent the Sequence-Number.  Even when such
association was possible by enhancing the OC-Supported-Features AVP with
the Diameter Identity of the reacting DOIC endpoint that generated the
Sequence-Number,  it would still simply not be needed as the reporting
DOIC endpoint can base its processing on the received Feature-Vector
(rather than on a stored Feature Vector).


      

      
I buy the reasoning for the lack of binding between the reacting node
identity and the supported features AVP.

However, we should not assume that _all_ implementations will behave
as expected above i.e. not storing the feature vector.



      

        
It is therefore proposed to remove the OC-Sequence-Number AVP from the OC-
Supported Features AVP.


      

      
I have no (more) strong view here. If folks are OK to remove
the seq-no, so be it.

- Jouni





      

        
-- 
----------------------------------------------+--------------------------
Reporter:  lionel.morand@orange-ftgroup.com  |      Owner:  Ulrich Wiehe
    Type:  defect                            |     Status:  new
Priority:  major                             |  Milestone:
Component:  draft-docdt-dime-ovli             |    Version:  2.0
Severity:  Active WG Document                |   Keywords:
----------------------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/29>
dime <http://tools.ietf.org/wg/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



    

    

  


--------------010404000907080006000006--

From lionel.morand@orange.com  Mon Feb 10 09:24:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2831A0835 for ; Mon, 10 Feb 2014 09:24:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DFO6CkWvUXt for ; Mon, 10 Feb 2014 09:24:42 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CC7261A0840 for ; Mon, 10 Feb 2014 09:24:41 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1CAD33B409F; Mon, 10 Feb 2014 18:24:41 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E7F4827C094; Mon, 10 Feb 2014 18:24:40 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 18:24:40 +0100
From: 
To: Steve Donovan , "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" 
Thread-Topic: [Dime] [dime] #37: Inconsistent name and abbreviation
Thread-Index: AQHPJoKE9K+sodI+LkSRBIAnBPeUc5quvL+Q
Date: Mon, 10 Feb 2014 17:24:39 +0000
Message-ID: <19541_1392053081_52F90B58_19541_2843_1_6B7134B31289DC4FAF731D844122B36E497DD4@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org> <52F9072F.3040507@usdonovans.com>
In-Reply-To: <52F9072F.3040507@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E497DD4PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.150316
Subject: Re: [Dime] [dime] #37: Inconsistent name and abbreviation
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:24:48 -0000

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

T2sgd2l0aCB0aGUgaXNzdWUgYW5kIEknbSBmaW5lIHdpdGggIkRPSUMiLg0KDQpMaW9uZWwNCg0K
RGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0
ZXZlIERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAxMCBmw6l2cmllciAyMDE0IDE4OjA3DQrDgCA6
IGRpbWVAaWV0Zi5vcmc7IGRyYWZ0LWRvY2R0LWRpbWUtb3ZsaUB0b29scy5pZXRmLm9yZzsgYmVu
QG5vc3RydW0uY29tDQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzNzogSW5jb25zaXN0ZW50
IG5hbWUgYW5kIGFiYnJldmlhdGlvbg0KDQpJIHZvdGUgZm9yIERPSUMsIGFzIEkgaGF2ZSBhbHJl
YWR5IHVzZWQgaXQgaW4gZXh0ZW5zaW9uIGRyYWZ0cy4NCg0KU3RldmUNCk9uIDIvNy8xNCAyOjMx
IFBNLCBkaW1lIGlzc3VlIHRyYWNrZXIgd3JvdGU6DQoNCiMzNzogSW5jb25zaXN0ZW50IG5hbWUg
YW5kIGFiYnJldmlhdGlvbg0KDQoNCg0KIFRoZSBpbnRyb2R1Y3Rpb24gcmVmZXJzIHRvIHRoZSBt
ZWNoYW5pc20gYXMgRGlhbWV0ZXIgT3ZlcmxvYWQgQ29udHJvbA0KDQogKERPQykuIEVsc2V3aGVy
ZSBpdCdzIERpYW1ldGVyIE92ZXJsb2FkIEluZm9ybWF0aW9uIENvbnZleWFuY2UgKERPSUMpLiBX
ZQ0KDQogbmVlZCB0byBwaWNrIG9uZSBhbmQgc3RpY2sgd2l0aCBpdC4NCg0KDQoNCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
CgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp
bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50
IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz
YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog
bGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw
aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli
bGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg
Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y
IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhl
eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv
cmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv
ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu
ClRoYW5rIHlvdS4KCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN
CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg
NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl
LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBT
aW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6
bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv
SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2lu
OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUHJmb3JtYXRIVE1M
Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZv
bnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0
aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcw
Ljg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIg
dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5PayB3aXRoIHRoZSBpc3N1ZSBhbmQgSSdtIGZpbmUgd2l0aCAmcXVvdDtET0lDJnF1
b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC
NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZu
YnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl
eHQiPiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBk
ZTwvYj4gU3RldmUgRG9ub3Zhbjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAxMCBm
w6l2cmllciAyMDE0IDE4OjA3PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBkaW1lQGlldGYub3JnOyBk
cmFmdC1kb2NkdC1kaW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7IGJlbkBub3N0cnVtLmNvbTxicj4N
CjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzM3OiBJbmNvbnNpc3RlbnQg
bmFtZSBhbmQgYWJicmV2aWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHZvdGUgZm9yIERPSUMs
IGFzIEkgaGF2ZSBhbHJlYWR5IHVzZWQgaXQgaW4gZXh0ZW5zaW9uIGRyYWZ0cy48YnI+DQo8YnI+
DQpTdGV2ZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIv
Ny8xNCAyOjMxIFBNLCBkaW1lIGlzc3VlIHRyYWNrZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT4jMzc6IEluY29uc2lzdGVudCBuYW1lIGFuZCBhYmJyZXZpYXRpb248bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gVGhlIGlu
dHJvZHVjdGlvbiByZWZlcnMgdG8gdGhlIG1lY2hhbmlzbSBhcyBEaWFtZXRlciBPdmVybG9hZCBD
b250cm9sPG86cD48L286cD48L3ByZT4NCjxwcmU+IChET0MpLiBFbHNld2hlcmUgaXQncyBEaWFt
ZXRlciBPdmVybG9hZCBJbmZvcm1hdGlvbiBDb252ZXlhbmNlIChET0lDKS4gV2U8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gbmVlZCB0byBwaWNrIG9uZSBhbmQgc3RpY2sgd2l0aCBpdC48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxQUkU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p
ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg
ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg
YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl
dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1
ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1
c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls
aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj
aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs
YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp
YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs
c2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_6B7134B31289DC4FAF731D844122B36E497DD4PEXCVZYM13corpora_--

From jgunn6@csc.com  Mon Feb 10 09:28:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627911A06DE; Mon, 10 Feb 2014 09:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oF-l-5LBRcv; Mon, 10 Feb 2014 09:28:54 -0800 (PST)
Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC31A0886; Mon, 10 Feb 2014 09:28:40 -0800 (PST)
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-4.tower-85.messagelabs.com!1392053319!23566083!1
X-Originating-IP: [20.137.2.88]
X-StarScan-Received: 
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3469 invoked from network); 10 Feb 2014 17:28:39 -0000
Received: from amer-mta102.csc.com (HELO amer-mta112.csc.com) (20.137.2.88) by server-4.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Feb 2014 17:28:39 -0000
Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta112.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s1AHSaRG020004; Mon, 10 Feb 2014 12:28:38 -0500
In-Reply-To: <52F9070A.8080608@usdonovans.com>
References: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> <52F9070A.8080608@usdonovans.com>
To: Steve Donovan 
MIME-Version: 1.0
X-KeepSent: F2B8EE96:0C737690-85257C7B:005FE05B; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012
From: Janet P Gunn 
Message-ID: 
Date: Mon, 10 Feb 2014 12:28:36 -0500
X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 02/10/2014 12:28:38 PM, Serialize complete at 02/10/2014 12:28:38 PM
Content-Type: multipart/alternative; boundary="=_alternative 0060030585257C7B_="
Cc: DiME , ben@nostrum.com, dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #43: Overstated guidance on session-ending	requests.
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:28:58 -0000

This is a multipart message in MIME format.
--=_alternative 0060030585257C7B_=
Content-Type: text/plain; charset="US-ASCII"

I agree.

"Throttling session ending  requests less aggressively" should be an 
example of local policy.

Janet

"DiME"  wrote on 02/10/2014 12:06:18 PM:

> From: Steve Donovan 
> To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com
> Date: 02/10/2014 12:06 PM
> Subject: Re: [Dime] [dime] #43: Overstated guidance on session-
> ending requests.
> Sent by: "DiME" 
> 
> Section 3.1.4 is not normative and says:
> The following list of request treatment regarding throttling is provided
> as guidelines for application designers when implementing the
> Diameter overload control mechanism described in this document.
> Exact behavior regarding throttling must be defined per application.
> Do you think we need further clarification that application 
> designers should reflect that local policy applies?
> 
> Steve
> 

> On 2/7/14 3:34 PM, dime issue tracker wrote:
> #43: Overstated guidance on session-ending requests.
> 
>  In section 3.1.4, under "Intra-Session Requests" indicates that session
>  ending requests should be throttled less aggressively. While I agree
>  that's a good idea in general, I think that's a mater of local policy, 
and
>  not up to DOIC to specify.
> 
>  It would be better to indicate that prioritization under overload is up 
to
>  local policy, and list prioritizing of session-ending requests as an
>  example of a potential local policy.
> 

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

--=_alternative 0060030585257C7B_=
Content-Type: text/html; charset="US-ASCII"



I agree.



"Throttling session ending  requests
less aggressively" should be an example of local policy.



Janet



"DiME" <dime-bounces@ietf.org> wrote
on 02/10/2014 12:06:18 PM:



> From: Steve Donovan <srdonovan@usdonovans.com>

> To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org,
ben@nostrum.com

> Date: 02/10/2014 12:06 PM

> Subject: Re: [Dime] [dime] #43: Overstated guidance
on session-

> ending requests.

> Sent by: "DiME" <dime-bounces@ietf.org>

> 

> Section 3.1.4 is not normative and says:

> The following list of request treatment regarding
throttling is provided

> as guidelines for application designers when
implementing the

> Diameter overload control mechanism described
in this document.

> Exact behavior regarding throttling must be defined
per application.

> Do you think we need further clarification that
application 

> designers should reflect that local policy applies?

> 

> Steve

> 



> On 2/7/14 3:34 PM, dime issue tracker wrote:

> #43: Overstated guidance on session-ending requests.

> 

>  In section 3.1.4, under "Intra-Session Requests" indicates
that session

>  ending requests should be throttled less aggressively. While
I agree

>  that's a good idea in general, I think that's a mater of local
policy, and

>  not up to DOIC to specify.

> 

>  It would be better to indicate that prioritization under overload
is up to

>  local policy, and list prioritizing of session-ending requests
as an

>  example of a potential local policy.

> 



> _______________________________________________

> DiME mailing list

> DiME@ietf.org

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


--=_alternative 0060030585257C7B_=--

From lionel.morand@orange.com  Mon Feb 10 09:29:47 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579131A089C for ; Mon, 10 Feb 2014 09:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qsai81HvphZ for ; Mon, 10 Feb 2014 09:29:44 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5901A08A2 for ; Mon, 10 Feb 2014 09:29:31 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 140E2264164; Mon, 10 Feb 2014 18:29:31 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id EA0124C096; Mon, 10 Feb 2014 18:29:30 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 18:29:30 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
Thread-Index: AQHPJoAruj9LEm1MaECVcDyzWc3D5pqupSGAgAAYKmA=
Date: Mon, 10 Feb 2014 17:29:30 +0000
Message-ID: <10970_1392053371_52F90C7A_10970_2992_1_6B7134B31289DC4FAF731D844122B36E497E39@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F9056B.6010405@usdonovans.com>
In-Reply-To: <52F9056B.6010405@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E497E39PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.150316
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:29:47 -0000

--_000_6B7134B31289DC4FAF731D844122B36E497E39PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve,

About the OC-Validity-Reduction AVP values greater than 24 hours, it is sai=
d that the default value 5s applies.

I was therefore wondering if it should be also considered as an error and t=
herefore discarded. It is a real open question. Not an issue per se as I'm =
fine with the existing text. I was reacting on the reason for change explai=
ned by Ben.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 10 f=E9vrier 2014 17:59
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #47: reduction percentages greater than 100 shoul=
d be ignored

It is possible, the range defined is zero to 24 hours.  I think the text is=
 correct as it says that a value out of this range should be ignored.

Steve
On 2/10/14 10:50 AM, Ben Campbell wrote:



On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:



Hi Ben,



OK with this statement.

But if it is agreed, would it mean that the same consideration should apply=
 for the OC-Validity-Duration AVP values?





I'm not sure I follow the question. Is it possible to send an invalid OC-Va=
lidity-Duration value?



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker

Envoy=E9 : vendredi 7 f=E9vrier 2014 23:05

=C0 : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com

Cc : dime@ietf.org

Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be=
 ignored



#47: reduction percentages greater than 100 should be ignored



Section 4.7 says " [Reduction-Percentage] Values greater than 100 are

interpreted as 100."



An OLR with an invalid value should be ignored. An invalid value indicates

incorrect behavior on the part of the sender. In this case, it's not safe

to assume we know what the sender really intended.



--

-------------------------+-------------------------------------------------

Reporter:               |      Owner:  draft-docdt-dime-

 ben@nostrum.com        |  ovli@tools.ietf.org

    Type:  defect       |     Status:  new

Priority:  minor        |  Milestone:

Component:  draft-       |    Version:  1.0

 docdt-dime-ovli        |   Keywords:

Severity:  Active WG    |

 Document               |

-------------------------+-------------------------------------------------



Ticket URL: 

dime 



_______________________________________________

DiME mailing list

DiME@ietf.org

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



___________________________________________________________________________=
______________________________________________



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.





_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E497E39PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve,<=
o:p>


 =
;


About the =
OC-Validity-Reduction AVP values greater than 24 hours, it is said that the=
 default value 5s applies.


 =
;


I was ther=
efore wondering if it should be also considered as an error and therefore d=
iscarded. It is a real open question. Not an issue per se
 as I'm fine with the existing text. I was reacting on the reason for chang=
e explained by Ben.


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 10 f=E9vrier 2014 17:59

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #47: reduction percentages greater th=
an 100 should be ignored






 


It is possible, the r=
ange defined is zero to 24 hours.  I think the text is correct as it s=
ays that a value out of this range should be ignored.



Steve




On 2/10/14 10:50 AM, Ben Campbell wrote:<=
/p>





 


On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


OK with this statement.


But if it is agreed, would it mean that the same consideration should =
apply for the OC-Validity-Duration AVP values?


 




 


I'm not sure I follow the question. Is it possible to send an invalid =
OC-Validity-Duration value?


 




Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de dime issue tracker


Envoy=E9 : vendredi 7 f=E9vrier 2014 23:05


=C0 : draft-do=
cdt-dime-ovli@tools.ietf.org; ben@no=
strum.com


Cc : dime@ietf.org

Objet : [Dime] [dime] #47: reduction percentages greater than 100 shou=
ld be ignored


 


#47: reduction percentages greater than 100 should be ignored


 


Section 4.7 says " [Reduction-Percentage] Values greater than 100=
 are


interpreted as 100."


 


An OLR with an invalid value should be ignored. An invalid value indic=
ates


incorrect behavior on the part of the sender. In this case, it's not s=
afe


to assume we know what the sender really intended.


 


-- 


-------------------------+----------------------------------------=
---------


Reporter:          &=
nbsp;    |      Owner:  draft-=
docdt-dime-


 ben@nostrum.com  &nb=
sp;     |  =
ovli@tools.ietf.org


    Type:  defect     &nb=
sp; |     Status:  new


Priority:  minor        | =
; Milestone:


Component:  draft-       | &nb=
sp;  Version:  1.0


 docdt-dime-ovli        | &nbs=
p; Keywords:


Severity:  Active WG    |


 Document          &=
nbsp;    |


-------------------------+----------------------------------------=
---------


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/47>


dime <http://tools.ietf.=
org/wg/dime/>


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E497E39PEXCVZYM13corpora_--

From lionel.morand@orange.com  Mon Feb 10 09:31:47 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F81A06DE for ; Mon, 10 Feb 2014 09:31:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edFMfnxQrCge for ; Mon, 10 Feb 2014 09:31:44 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 43DD81A0884 for ; Mon, 10 Feb 2014 09:31:38 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CE4F722C41B; Mon, 10 Feb 2014 18:31:37 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AA24A238093; Mon, 10 Feb 2014 18:31:37 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 18:31:37 +0100
From: 
To: Steve Donovan , "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" 
Thread-Topic: [Dime] [dime] #43: Overstated guidance on session-ending requests.
Thread-Index: AQHPJoJymuKCvd0AIkyv9yl+wTFlTpquvqWg
Date: Mon, 10 Feb 2014 17:31:36 +0000
Message-ID: <6150_1392053497_52F90CF9_6150_15734_1_6B7134B31289DC4FAF731D844122B36E497E5B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> <52F9070A.8080608@usdonovans.com>
In-Reply-To: <52F9070A.8080608@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E497E5BPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.83914
Subject: Re: [Dime] [dime] #43: Overstated guidance on session-ending	requests.
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:31:48 -0000

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

SGkgU3RldmUsIEJlbiwNCg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIHRoYXQgd2UgaGF2ZSB0aGUgdGV4
dCBpbiBpbnRyb2R1Y3Rpb24gaXMgY2xlYXIgZW5vdWdoIHRvIGF2b2lkIGFtYmlndWl0eS4NCg0K
UmVnYXJkcywNCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2ZSBEb25vdmFuDQpFbnZvecOpIDogbHVuZGkgMTAgZsOp
dnJpZXIgMjAxNCAxODowNg0Kw4AgOiBkaW1lQGlldGYub3JnOyBkcmFmdC1kb2NkdC1kaW1lLW92
bGlAdG9vbHMuaWV0Zi5vcmc7IGJlbkBub3N0cnVtLmNvbQ0KT2JqZXQgOiBSZTogW0RpbWVdIFtk
aW1lXSAjNDM6IE92ZXJzdGF0ZWQgZ3VpZGFuY2Ugb24gc2Vzc2lvbi1lbmRpbmcgcmVxdWVzdHMu
DQoNClNlY3Rpb24gMy4xLjQgaXMgbm90IG5vcm1hdGl2ZSBhbmQgc2F5czoNCg0KVGhlIGZvbGxv
d2luZyBsaXN0IG9mIHJlcXVlc3QgdHJlYXRtZW50IHJlZ2FyZGluZyB0aHJvdHRsaW5nIGlzIHBy
b3ZpZGVkDQoNCmFzIGd1aWRlbGluZXMgZm9yIGFwcGxpY2F0aW9uIGRlc2lnbmVycyB3aGVuIGlt
cGxlbWVudGluZyB0aGUNCg0KRGlhbWV0ZXIgb3ZlcmxvYWQgY29udHJvbCBtZWNoYW5pc20gZGVz
Y3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCkV4YWN0IGJlaGF2aW9yIHJlZ2FyZGluZyB0aHJv
dHRsaW5nIG11c3QgYmUgZGVmaW5lZCBwZXIgYXBwbGljYXRpb24uDQpEbyB5b3UgdGhpbmsgd2Ug
bmVlZCBmdXJ0aGVyIGNsYXJpZmljYXRpb24gdGhhdCBhcHBsaWNhdGlvbiBkZXNpZ25lcnMgc2hv
dWxkIHJlZmxlY3QgdGhhdCBsb2NhbCBwb2xpY3kgYXBwbGllcz8NCg0KU3RldmUNCg0KT24gMi83
LzE0IDM6MzQgUE0sIGRpbWUgaXNzdWUgdHJhY2tlciB3cm90ZToNCg0KIzQzOiBPdmVyc3RhdGVk
IGd1aWRhbmNlIG9uIHNlc3Npb24tZW5kaW5nIHJlcXVlc3RzLg0KDQoNCg0KIEluIHNlY3Rpb24g
My4xLjQsIHVuZGVyICJJbnRyYS1TZXNzaW9uIFJlcXVlc3RzIiBpbmRpY2F0ZXMgdGhhdCBzZXNz
aW9uDQoNCiBlbmRpbmcgcmVxdWVzdHMgc2hvdWxkIGJlIHRocm90dGxlZCBsZXNzIGFnZ3Jlc3Np
dmVseS4gV2hpbGUgSSBhZ3JlZQ0KDQogdGhhdCdzIGEgZ29vZCBpZGVhIGluIGdlbmVyYWwsIEkg
dGhpbmsgdGhhdCdzIGEgbWF0ZXIgb2YgbG9jYWwgcG9saWN5LCBhbmQNCg0KIG5vdCB1cCB0byBE
T0lDIHRvIHNwZWNpZnkuDQoNCg0KDQogSXQgd291bGQgYmUgYmV0dGVyIHRvIGluZGljYXRlIHRo
YXQgcHJpb3JpdGl6YXRpb24gdW5kZXIgb3ZlcmxvYWQgaXMgdXAgdG8NCg0KIGxvY2FsIHBvbGlj
eSwgYW5kIGxpc3QgcHJpb3JpdGl6aW5nIG9mIHNlc3Npb24tZW5kaW5nIHJlcXVlc3RzIGFzIGFu
DQoNCiBleGFtcGxlIG9mIGEgcG90ZW50aWFsIGxvY2FsIHBvbGljeS4NCg0KDQoNCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
CgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp
bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50
IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz
YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog
bGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw
aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli
bGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg
Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y
IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhl
eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv
cmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv
ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu
ClRoYW5rIHlvdS4KCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN
CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg
NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl
LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBT
aW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6
bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv
SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2lu
OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUHJmb3JtYXRIVE1M
Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZv
bnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0
aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcw
Ljg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIg
dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFN0
ZXZlLCBCZW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIFN0ZXZlIHRoYXQg
d2UgaGF2ZSB0aGUgdGV4dCBpbiBpbnRyb2R1Y3Rpb24gaXMgY2xlYXIgZW5vdWdoIHRvIGF2b2lk
IGFtYmlndWl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g
RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+
IFN0ZXZlIERvbm92YW48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTAgZsOpdnJp
ZXIgMjAxNCAxODowNjxicj4NCjxiPsOAJm5ic3A7OjwvYj4gZGltZUBpZXRmLm9yZzsgZHJhZnQt
ZG9jZHQtZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyBiZW5Abm9zdHJ1bS5jb208YnI+DQo8Yj5P
YmpldCZuYnNwOzo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICM0MzogT3ZlcnN0YXRlZCBndWlkYW5j
ZSBvbiBzZXNzaW9uLWVuZGluZyByZXF1ZXN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDMuMS40IGlzIG5vdCBub3JtYXRpdmUgYW5kIHNh
eXM6PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJMQzQ1NiI+DQo8cHJlPlRoZSBmb2xsb3dpbmcg
bGlzdCBvZiByZXF1ZXN0IHRyZWF0bWVudCByZWdhcmRpbmcgdGhyb3R0bGluZyBpcyBwcm92aWRl
ZDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXYgaWQ9IkxDNDU3Ij4NCjxwcmU+YXMgZ3Vp
ZGVsaW5lcyBmb3IgYXBwbGljYXRpb24gZGVzaWduZXJzIHdoZW4gaW1wbGVtZW50aW5nIHRoZTxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXYgaWQ9IkxDNDU4Ij4NCjxwcmU+RGlhbWV0ZXIg
b3ZlcmxvYWQgY29udHJvbCBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuPG86
cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdiBpZD0iTEM0NTkiPg0KPHByZT5FeGFjdCBiZWhh
dmlvciByZWdhcmRpbmcgdGhyb3R0bGluZyBtdXN0IGJlIGRlZmluZWQgcGVyIGFwcGxpY2F0aW9u
LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+RG8geW91IHRoaW5rIHdlIG5lZWQgZnVydGhlciBjbGFyaWZp
Y2F0aW9uIHRoYXQgYXBwbGljYXRpb24gZGVzaWduZXJzIHNob3VsZCByZWZsZWN0IHRoYXQgbG9j
YWwgcG9saWN5IGFwcGxpZXM/PGJyPg0KPGJyPg0KU3RldmU8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzcvMTQgMzozNCBQTSwgZGlt
ZSBpc3N1ZSB0cmFja2VyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+IzQz
OiBPdmVyc3RhdGVkIGd1aWRhbmNlIG9uIHNlc3Npb24tZW5kaW5nIHJlcXVlc3RzLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiBJbiBzZWN0aW9u
IDMuMS40LCB1bmRlciAmcXVvdDtJbnRyYS1TZXNzaW9uIFJlcXVlc3RzJnF1b3Q7IGluZGljYXRl
cyB0aGF0IHNlc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gZW5kaW5nIHJlcXVlc3RzIHNo
b3VsZCBiZSB0aHJvdHRsZWQgbGVzcyBhZ2dyZXNzaXZlbHkuIFdoaWxlIEkgYWdyZWU8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4gdGhhdCdzIGEgZ29vZCBpZGVhIGluIGdlbmVyYWwsIEkgdGhpbmsg
dGhhdCdzIGEgbWF0ZXIgb2YgbG9jYWwgcG9saWN5LCBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gbm90IHVwIHRvIERPSUMgdG8gc3BlY2lmeS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gSXQgd291bGQgYmUgYmV0dGVyIHRvIGluZGljYXRl
IHRoYXQgcHJpb3JpdGl6YXRpb24gdW5kZXIgb3ZlcmxvYWQgaXMgdXAgdG88bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4gbG9jYWwgcG9saWN5LCBhbmQgbGlzdCBwcmlvcml0aXppbmcgb2Ygc2Vzc2lv
bi1lbmRpbmcgcmVxdWVzdHMgYXMgYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gZXhhbXBsZSBv
ZiBhIHBvdGVudGlhbCBsb2NhbCBwb2xpY3kuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg
c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m
aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk
aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh
dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn
ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM
ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u
LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl
IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv
cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg
ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls
cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg
aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BS
RT48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_6B7134B31289DC4FAF731D844122B36E497E5BPEXCVZYM13corpora_--

From srdonovan@usdonovans.com  Mon Feb 10 09:52:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E761A03BF for ; Mon, 10 Feb 2014 09:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.781
X-Spam-Level: *
X-Spam-Status: No, score=1.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2okmYdVwlPE for ; Mon, 10 Feb 2014 09:52:18 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id 2F10F1A03A5 for ; Mon, 10 Feb 2014 09:52:18 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57745 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCv0b-00048Z-4n; Mon, 10 Feb 2014 09:51:09 -0800
Message-ID: <52F911CB.3070207@usdonovans.com>
Date: Mon, 10 Feb 2014 11:52:11 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: lionel.morand@orange.com, Jouni Korhonen ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------040707010701040301010001"
X-OutGoing-Spam-Status: No, score=-1.9
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
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:52:22 -0000

This is a multi-part message in MIME format.
--------------040707010701040301010001
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Lionel,

Why would the reduction for the realm be less than servers.  It is
perfectly valid for a realm overload report to ask for a reduction when
there are no servers in overload.  This could happen in the case I
mentioned where the realm overload report is triggered by layer 3
congestion.

Clearly realm overload will be significantly influenced by server
overload, but that isn't the only consideration.

My logic was not quite correct, but for a different reason.  There is no
reason to do the host throttling if the request has already been
throttled by the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host
overload report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm
abatement algorithm and input that into the server abatement algorithm. 
This might look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the
destination-host AVP
  If the request has not already been throttled and there is a host
overload report that applies to the request:
    If host credits exist for the host indicated in the destination-host
AVP:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request

Steve

On 2/10/14 10:59 AM, lionel.morand@orange.com wrote:
>
> Hi Steve,
>
>  
>
> In your example, if an agent has a better knowledge than the server,
> the Host type OLR should not be sent unmodified in forwarded answers,
> or even removed as irrelevant.
>
>  
>
> And in a normal case, the reduction for the realm will be likely lower
> than the reduction needed for a node. S1 is not overload, S2 is 50%
> overload, the realm (S1+S2) is overloaded 25%. So only the reduction
> for the Host should apply, why the host-type should prevail over
> realm-type OLR.
>
>  
>
> By the way, in your proposed logic, it is not clear if the relation
> between the first and the second conditions is an "IF NOT".
>
>  
>
> Lionel
>
>  
>
> *De :*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Envoyé :* lundi 10 février 2014 15:39
> *À :* MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN -
> DE/Munich)
> *Cc :* dime@ietf.org
> *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> I think we have agreement that a realm report applies to all traffic
> targeted for that realm, independent of the presence or absence of the
> destination-host avp.  Is that correct?
>
> I don't agree with Lionel's proposal.  The realm overload report
> should take precedence over the host overload report.
>
> My reasoning is as follows:
>
> - There is something responsible for tracking the health of the
> realm.  Call it the "realm overload authority".  The health of the
> realm can be based on a number of factors including the health of
> individual servers, individual agents and the network connecting
> Diameter entities.
>
> - When this "realm overload authority" determines that the IP network
> is congested, for instance, it would instruct agents or servers to
> send realm overload reports with the expectation that the overall
> traffic sent to the realm as a whole will be reduced.
>
> In this scenario, the fact that the realm is overloaded takes
> precedence over the health of the servers.  As such, it is likely that
> requests targeted for a healthy server will be throttled.
>
> I propose the logic should be as follows:
>
> For all requests:
>   If there is a realm overload report that applies to the request:
>     Apply realm based trottling logic to that request
>   If there is a host overload report that applies to the request:
>     Apply host based throttling logic to that request
>
> Note that this also requires the ability to put realm overload reports
> in any answer message, not just answers to requests that did not
> contain a destination-host AVP.
>
> Steve
>
> On 2/10/14 5:30 AM, lionel.morand@orange.com
>  wrote:
>
>     No it was not my intention and it is why it was written "except" :)
>
>      
>
>     The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.
>
>      
>
>     Is it clearer?
>
>      
>
>     Lioenl 
>
>      
>
>     -----Message d'origine-----
>
>     De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>     Envoyé : dimanche 9 février 2014 13:46
>
>     À : Wiehe, Ulrich (NSN - DE/Munich)
>
>     Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org 
>
>     Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>      
>
>     On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>      
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Sent: Friday, February 07, 2014 11:21 AM
>
>         To: Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc: ext lionel.morand@orange.com ; Steve Donovan; dime@ietf.org 
>
>         Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>          
>
>          
>
>         On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>          
>
>             I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>
>             What is wrong with letting the client
>
>             -not throttle host-type requests to S1,
>
>             -throttle host type request to S2 with 50% and
>
>             -throttle realm type requests wit 25%?
>
>          
>
>         Isn't this what Lionel said below?
>
>          no it is not
>
>      
>
>      
>
>     Ok, maybe I misread the "realm abatement is applied in any case
>
>     except if there is an explicit report for the destination-host"?
>
>      
>
>     If this means the realm abatement is still applied after applying
>
>     the host abatement, then I agree it is not the same you said.
>
>      
>
>     - Jouni
>
>      
>
>      
>
>         I am OK with Lionel's
>
>         "wording" here.
>
>          
>
>         - Jouni
>
>          
>
>              
>
>              
>
>              
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com 
>
>             Sent: Wednesday, February 05, 2014 4:14 PM
>
>             To: Steve Donovan; dime@ietf.org 
>
>             Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>              
>
>             I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.
>
>              
>
>             Lioenl
>
>              
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>
>             Envoyé : mercredi 5 février 2014 15:56
>
>             À : dime@ietf.org 
>
>             Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>              
>
>             It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.
>
>              
>
>             If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.
>
>              
>
>             I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.
>
>              
>
>             Steve
>
>              
>
>             On 2/4/14 11:12 AM, lionel.morand@orange.com  wrote:
>
>             The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
>
>             If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.
>
>              
>
>             Does it make sense?
>
>              
>
>             Lionel
>
>              
>
>             -----Message d'origine-----
>
>             De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
>
>             Envoyé : mardi 4 février 2014 09:55
>
>             À : MORAND Lionel IMT/OLN
>
>             Cc : dime@ietf.org 
>
>             Objet : [dime] #34: Semantics of OC-Report-Type AVP
>
>              
>
>             #34: Semantics of OC-Report-Type AVP
>
>              
>
>             Text in clause 4.6  does not fully explain to which requests overload
>
>             treatment of a given report type applies.
>
>             Proposal:
>
>              
>
>                0  A host report.  The overload treatment should apply to requests
>
>                   for which all of the following conditions are true:
>
>                   a) The Destination-Host AVP is present in the request and its value
>
>                      matches the value of the Origin-Host AVP of the received message
>
>                      that contained the OC-OLR AVP.
>
>                   b) The value of the Destination-Realm AVP in the request matches the
>
>                      value of the Origin-Realm AVP of the received message
>
>                      that contained the OC-OLR AVP.
>
>                   c) The value of the Application-ID in the Diameter Header of the
>
>                      request matches the value of the Application-ID of the Diameter
>
>                      Header of the received message that contained the OC-OLR AVP.
>
>              
>
>              
>
>              
>
>                1  A realm report.  The overload treatment should apply to
>
>                   requests for which all of the following conditions are true:
>
>                   a) The Destination-Host AVP is absent in the request.
>
>                   b) The value of the Destination-Realm AVP in the request matches the
>
>                      value of the Origin-Realm AVP of the received message
>
>                      that contained the OC-OLR AVP.
>
>                   c) The value of the Application-ID in the Diameter Header of the
>
>                      request matches the value of the Application-ID of the Diameter
>
>                      Header of the received message that contained the OC-OLR AVP.
>
>              
>
>              
>
>             _________________________________________________________________________________________________________________________
>
>              
>
>             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.
>
>             _______________________________________________
>
>             DiME mailing list
>
>             DiME@ietf.org 
>
>             https://www.ietf.org/mailman/listinfo/dime
>
>          
>
>      
>
>      
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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.


--------------040707010701040301010001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Lionel,

      

      Why would the reduction for the realm be less than servers.  It is
      perfectly valid for a realm overload report to ask for a reduction
      when there are no servers in overload.  This could happen in the
      case I mentioned where the realm overload report is triggered by
      layer 3 congestion.

      

      Clearly realm overload will be significantly influenced by server
      overload, but that isn't the only consideration.

      

      My logic was not quite correct, but for a different reason.  There
      is no reason to do the host throttling if the request has already
      been throttled by the realm report.

      It should be as follows:

    

      For all requests:

        If there is a realm overload report that applies to the request:

          Apply realm based throttling logic to that request

        If the request has not already been throttled and there is a
      host overload report that applies to the request:

          Apply host based throttling logic to that request

      

      One improvement would be to remember the host throttled by the
      realm abatement algorithm and input that into the server abatement
      algorithm.  This might look something like the following:

    

    
        For all requests:

          If there is a realm overload report that applies to the
        request:

            Apply realm based throttling logic to that request

            If request is throttled:

              Increment host credit by one for the host indicated in the
        destination-host AVP

          If the request has not already been throttled and there is a
        host overload report that applies to the request:

            If host credits exist for the host indicated in the
        destination-host AVP:

              Decrement host credit by one

            else:

              Apply host based throttling logic to that request

      

      Steve

      

    
    
On 2/10/14 10:59 AM,
      lionel.morand@orange.com wrote:

    

    

      
      
      
      

        
Hi
            Steve,

        
 

        
In your example, if an agent has a better
            knowledge than the server, the Host type OLR should not be
            sent unmodified in forwarded answers, or even removed as
            irrelevant.

        
 

        
And in a normal case, the reduction for the
            realm will be likely lower than the reduction needed for a
            node. S1 is not overload, S2 is 50% overload, the realm
            (S1+S2) is overloaded 25%. So only the reduction for the
            Host should apply, why the host-type should prevail over
            realm-type OLR.

        
 

        
By the way, in your proposed logic, it is not
            clear if the relation between the first and the second
            conditions is an "IF NOT".
            

        
 

        
Lionel

        
 

        

          

            
De :
                Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Envoyé : lundi 10 février 2014 15:39

                À : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe,
                Ulrich (NSN - DE/Munich)

                Cc : dime@ietf.org

                Objet : Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
I think we
          have agreement that a realm report applies to all traffic
          targeted for that realm, independent of the presence or
          absence of the destination-host avp.  Is that correct?

          

          I don't agree with Lionel's proposal.  The realm overload
          report should take precedence over the host overload report.

          

          My reasoning is as follows:

          

          - There is something responsible for tracking the health of
          the realm.  Call it the "realm overload authority".  The
          health of the realm can be based on a number of factors
          including the health of individual servers, individual agents
          and the network connecting Diameter entities.

          

          - When this "realm overload authority" determines that the IP
          network is congested, for instance, it would instruct agents
          or servers to send realm overload reports with the expectation
          that the overall traffic sent to the realm as a whole will be
          reduced.

          

          In this scenario, the fact that the realm is overloaded takes
          precedence over the health of the servers.  As such, it is
          likely that requests targeted for a healthy server will be
          throttled.

          

          I propose the logic should be as follows:

          

          For all requests:

            If there is a realm overload report that applies to the
          request:

              Apply realm based trottling logic to that request

            If there is a host overload report that applies to the
          request:

              Apply host based throttling logic to that request

          

          Note that this also requires the ability to put realm overload
          reports in any answer message, not just answers to requests
          that did not contain a destination-host AVP.

          

          Steve

        

          
On 2/10/14 5:30 AM, 
              lionel.morand@orange.com wrote:

        

        

          
No it was not my intention and it is why it was written "except" :)

          
 

          
The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.

          
 

          
Is it clearer?

          
 

          
Lioenl 

          
 

          
-----Message d'origine-----

          
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

          
Envoyé : dimanche 9 février 2014 13:46

          
À : Wiehe, Ulrich (NSN - DE/Munich)

          
Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

          
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

          
 

          
 

          
On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

          
 

          

            
 

            
 

            
-----Original Message-----

            
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

            
Sent: Friday, February 07, 2014 11:21 AM

            
To: Wiehe, Ulrich (NSN - DE/Munich)

            
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org

            
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

            
 

            
 

            
On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

            
 

            

              
I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?

              
What is wrong with letting the client

              
-not throttle host-type requests to S1,

              
-throttle host type request to S2 with 50% and

              
-throttle realm type requests wit 25%?

            

            
 

            
Isn't this what Lionel said below?

            
<Ulrich> no it is not</Ulrich>

          

          
 

          
 

          
Ok, maybe I misread the "realm abatement is applied in any case

          
except if there is an explicit report for the destination-host"?

          
 

          
If this means the realm abatement is still applied after applying

          
the host abatement, then I agree it is not the same you said.

          
 

          
- Jouni

          
 

          
 

          

            
I am OK with Lionel's

            
"wording" here.

            
 

            
- Jouni

            
 

            

              
 

              
 

              
 

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com

              
Sent: Wednesday, February 05, 2014 4:14 PM

              
To: Steve Donovan; dime@ietf.org

              
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

              
 

              
I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

              
 

              
Lioenl

              
 

              
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

              
Envoyé : mercredi 5 février 2014 15:56

              
À : dime@ietf.org

              
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

              
 

              
It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

              
 

              
If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

              
 

              
I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

              
 

              
Steve

              
 

              
On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

              
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?

              
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

              
 

              
Does it make sense?

              
 

              
Lionel

              
 

              
-----Message d'origine-----

              
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 

              
Envoyé : mardi 4 février 2014 09:55

              
À : MORAND Lionel IMT/OLN

              
Cc : dime@ietf.org

              
Objet : [dime] #34: Semantics of OC-Report-Type AVP

              
 

              
#34: Semantics of OC-Report-Type AVP

              
 

              
Text in clause 4.6  does not fully explain to which requests overload

              
treatment of a given report type applies.

              
Proposal:

              
 

              
   0  A host report.  The overload treatment should apply to requests

              
      for which all of the following conditions are true:

              
      a) The Destination-Host AVP is present in the request and its value

              
         matches the value of the Origin-Host AVP of the received message

              
         that contained the OC-OLR AVP.

              
      b) The value of the Destination-Realm AVP in the request matches the

              
         value of the Origin-Realm AVP of the received message

              
         that contained the OC-OLR AVP.

              
      c) The value of the Application-ID in the Diameter Header of the

              
         request matches the value of the Application-ID of the Diameter

              
         Header of the received message that contained the OC-OLR AVP.

              
 

              
 

              
 

              
   1  A realm report.  The overload treatment should apply to

              
      requests for which all of the following conditions are true:

              
      a) The Destination-Host AVP is absent in the request.

              
      b) The value of the Destination-Realm AVP in the request matches the

              
         value of the Origin-Realm AVP of the received message

              
         that contained the OC-OLR AVP.

              
      c) The value of the Application-ID in the Diameter Header of the

              
         request matches the value of the Application-ID of the Diameter

              
         Header of the received message that contained the OC-OLR AVP.

              
 

              
 

              
_________________________________________________________________________________________________________________________

              
 

              
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.

              
_______________________________________________

              
DiME mailing list

              
DiME@ietf.org

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

            

            
 

          

          
 

          
 

          
_________________________________________________________________________________________________________________________

          
 

          
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.


    

    

  


--------------040707010701040301010001--


From srdonovan@usdonovans.com  Mon Feb 10 09:58:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F001A07EB for ; Mon, 10 Feb 2014 09:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtVvGl_wlRcz for ; Mon, 10 Feb 2014 09:58:46 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.0.129]) by ietfa.amsl.com (Postfix) with ESMTP id DF6CE1A0326 for ; Mon, 10 Feb 2014 09:58:46 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57785 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCv6w-0005DF-1D; Mon, 10 Feb 2014 09:57:39 -0800
Message-ID: <52F91354.4090101@usdonovans.com>
Date: Mon, 10 Feb 2014 11:58:44 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: lionel.morand@orange.com, "dime@ietf.org" 
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F9056B.6010405@usdonovans.com> <10970_1392053371_52F90C7A_10970_2992_1_6B7134B31289DC4FAF731D844122B36E497E39@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <10970_1392053371_52F90C7A_10970_2992_1_6B7134B31289DC4FAF731D844122B36E497E39@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------060800060106010605070901"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 17:58:50 -0000

This is a multi-part message in MIME format.
--------------060800060106010605070901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I agree that a clarification is needed on what it means to be "treated
as is the OC-Validity-Duration AVP was not present".  It would e better
to say:

  "Invalid validity duration values are given the default value". Steve

On 2/10/14 11:29 AM, lionel.morand@orange.com wrote:
>
> Hi Steve,
>
>  
>
> About the OC-Validity-Reduction AVP values greater than 24 hours, it
> is said that the default value 5s applies.
>
>  
>
> I was therefore wondering if it should be also considered as an error
> and therefore discarded. It is a real open question. Not an issue per
> se as I'm fine with the existing text. I was reacting on the reason
> for change explained by Ben.
>
>  
>
> Regards,
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* lundi 10 février 2014 17:59
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] [dime] #47: reduction percentages greater than
> 100 should be ignored
>
>  
>
> It is possible, the range defined is zero to 24 hours.  I think the
> text is correct as it says that a value out of this range should be
> ignored.
>
> Steve
>
> On 2/10/14 10:50 AM, Ben Campbell wrote:
>
>      
>
>     On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com  wrote:
>
>      
>
>         Hi Ben,
>
>          
>
>         OK with this statement.
>
>         But if it is agreed, would it mean that the same consideration should apply for the OC-Validity-Duration AVP values?
>
>          
>
>      
>
>     I'm not sure I follow the question. Is it possible to send an invalid OC-Validity-Duration value?
>
>      
>
>         Lionel
>
>          
>
>         -----Message d'origine-----
>
>         De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
>
>         Envoyé : vendredi 7 février 2014 23:05
>
>         À : draft-docdt-dime-ovli@tools.ietf.org ; ben@nostrum.com 
>
>         Cc : dime@ietf.org 
>
>         Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be ignored
>
>          
>
>         #47: reduction percentages greater than 100 should be ignored
>
>          
>
>         Section 4.7 says " [Reduction-Percentage] Values greater than 100 are
>
>         interpreted as 100."
>
>          
>
>         An OLR with an invalid value should be ignored. An invalid value indicates
>
>         incorrect behavior on the part of the sender. In this case, it's not safe
>
>         to assume we know what the sender really intended.
>
>          
>
>         -- 
>
>         -------------------------+-------------------------------------------------
>
>         Reporter:               |      Owner:  draft-docdt-dime-
>
>          ben@nostrum.com         |  ovli@tools.ietf.org 
>
>             Type:  defect       |     Status:  new
>
>         Priority:  minor        |  Milestone:
>
>         Component:  draft-       |    Version:  1.0
>
>          docdt-dime-ovli        |   Keywords:
>
>         Severity:  Active WG    |
>
>          Document               |
>
>         -------------------------+-------------------------------------------------
>
>          
>
>         Ticket URL:  
>
>         dime  
>
>          
>
>         _______________________________________________
>
>         DiME mailing list
>
>         DiME@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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.
>
>          
>
>      
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>  
>
> _________________________________________________________________________________________________________________________
>
> 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.


--------------060800060106010605070901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I agree that a
      clarification is needed on what it means to be "treated as is the
      OC-Validity-Duration AVP was not present".  It would e better to
      say:

      

      
    
    
  "Invalid validity duration values are given the default value".

Steve



    
On 2/10/14 11:29 AM,
      lionel.morand@orange.com wrote:

    

    

      
      
      
      

        
Hi Steve,

        
 

        
About the OC-Validity-Reduction AVP values
            greater than 24 hours, it is said that the default value 5s
            applies.

        
 

        
I was therefore wondering if it should be also
            considered as an error and therefore discarded. It is a real
            open question. Not an issue per se as I'm fine with the
            existing text. I was reacting on the reason for change
            explained by Ben.

        
 

        
Regards,

        
 

        
Lionel

        
 

        

          

            
De :
                DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : lundi 10 février 2014 17:59

                À : dime@ietf.org

                Objet : Re: [Dime] [dime] #47: reduction
                percentages greater than 100 should be ignored

          

        

        
 

        
It is
          possible, the range defined is zero to 24 hours.  I think the
          text is correct as it says that a value out of this range
          should be ignored.

          

          Steve

        

          
On 2/10/14 10:50 AM, Ben Campbell wrote:

        

        

          
 

          
On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:

          
 

          

            
Hi Ben,

            
 

            
OK with this statement.

            
But if it is agreed, would it mean that the same consideration should apply for the OC-Validity-Duration AVP values?

            
 

          

          
 

          
I'm not sure I follow the question. Is it possible to send an invalid OC-Validity-Duration value?

          
 

          

            
Lionel

            
 

            
-----Message d'origine-----

            
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker

            
Envoyé : vendredi 7 février 2014 23:05

            
À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com

            
Cc : dime@ietf.org

            
Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be ignored

            
 

            
#47: reduction percentages greater than 100 should be ignored

            
 

            
Section 4.7 says " [Reduction-Percentage] Values greater than 100 are

            
interpreted as 100."

            
 

            
An OLR with an invalid value should be ignored. An invalid value indicates

            
incorrect behavior on the part of the sender. In this case, it's not safe

            
to assume we know what the sender really intended.

            
 

            
-- 

            
-------------------------+-------------------------------------------------

            
Reporter:               |      Owner:  draft-docdt-dime-

            
 ben@nostrum.com        |  ovli@tools.ietf.org

            
    Type:  defect       |     Status:  new

            
Priority:  minor        |  Milestone:

            
Component:  draft-       |    Version:  1.0

            
 docdt-dime-ovli        |   Keywords:

            
Severity:  Active WG    |

            
 Document               |

            
-------------------------+-------------------------------------------------

            
 

            
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/47>

            
dime <http://tools.ietf.org/wg/dime/>

            
 

            
_______________________________________________

            
DiME mailing list

            
DiME@ietf.org

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

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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.

            
 

          

          
 

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

          
 

        

        
 

      

      
_________________________________________________________________________________________________________________________

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.


    

    

  


--------------060800060106010605070901--

From lionel.morand@orange.com  Mon Feb 10 10:45:19 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EA41A07EC for ; Mon, 10 Feb 2014 10:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LLWLmlRhhJ6 for ; Mon, 10 Feb 2014 10:45:15 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D91A0412 for ; Mon, 10 Feb 2014 10:45:14 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E1EB022C437; Mon, 10 Feb 2014 19:45:13 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C7D1D238091; Mon, 10 Feb 2014 19:45:13 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 19:45:13 +0100
From: 
To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , Steve Donovan 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPJojSK95DWDMaH0qQEyVc/ebDNpqu02V3
Date: Mon, 10 Feb 2014 18:45:13 +0000
Message-ID: <6150_1392057913_52F91E39_6150_18518_1_3tsn6b4h6c5tsypoe2hug1hm.1392057602168@email.android.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <52F911CB.3070207@usdonovans.com>
In-Reply-To: <52F911CB.3070207@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_3tsn6b4h6c5tsypoe2hug1hm1392057602168emailandroidcom_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.9.83914
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 18:45:20 -0000

--_000_3tsn6b4h6c5tsypoe2hug1hm1392057602168emailandroidcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

What about my comment on the fact that irrelevant host report in presence o=
f a realm reporting agent should not be forwarded?

Lionel

Envoy=E9 depuis mon Sony Xperia SP d'Orange

Steve Donovan  a =E9crit :



Lionel,

Why would the reduction for the realm be less than servers.  It is perfectl=
y valid for a realm overload report to ask for a reduction when there are n=
o servers in overload.  This could happen in the case I mentioned where the=
 realm overload report is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.

My logic was not quite correct, but for a different reason.  There is no re=
ason to do the host throttling if the request has already been throttled by=
 the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  This mig=
ht look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the destinatio=
n-host AVP
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    If host credits exist for the host indicated in the destination-host AV=
P:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request

Steve

On 2/10/14 10:59 AM, lionel.morand@orange.com wrote:
Hi Steve,

In your example, if an agent has a better knowledge than the server, the Ho=
st type OLR should not be sent unmodified in forwarded answers, or even rem=
oved as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than=
 the reduction needed for a node. S1 is not overload, S2 is 50% overload, t=
he realm (S1+S2) is overloaded 25%. So only the reduction for the Host shou=
ld apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between=
 the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : lundi 10 f=E9vrier 2014 15:39
=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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.



___________________________________________________________________________=
______________________________________________

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_3tsn6b4h6c5tsypoe2hug1hm1392057602168emailandroidcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







What about my comment on the fact that irrelevant host report i=
n presence of a realm reporting agent should not be forwarded?

Lionel

Envoy=E9 depuis mon Sony Xperia SP d'Orange

Steve Donovan <srdonovan@usdonovans.com> a =E9crit :




Lionel,



Why would the reduction for the realm be less than servers.  It is per=
fectly valid for a realm overload report to ask for a reduction when there =
are no servers in overload.  This could happen in the case I mentioned=
 where the realm overload report is triggered
 by layer 3 congestion.



Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.



My logic was not quite correct, but for a different reason.  There is =
no reason to do the host throttling if the request has already been throttl=
ed by the realm report.

It should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    Apply host based throttling logic to that request



One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  Thi=
s might look something like the following:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

    If request is throttled:

      Increment host credit by one for the host indicat=
ed in the destination-host AVP

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    If host credits exist for the host indicated in the dest=
ination-host AVP:

      Decrement host credit by one

    else:

      Apply host based throttling logic to that request=




Steve





On 2/10/14 10:59 AM, 
lionel.morand@orange.com wrote:








Hi Steve,


 


In your =
example, if an agent has a better knowledge than the server, the Host type =
OLR should not be sent unmodified in forwarded answers, or
 even removed as irrelevant.


 


And in a=
 normal case, the reduction for the realm will be likely lower than the red=
uction needed for a node. S1 is not overload, S2 is 50% overload,
 the realm (S1+S2) is overloaded 25%. So only the reduction for the Hos=
t should apply, why the host-type should prevail over realm-type OLR.


 


By the w=
ay, in your proposed logic, it is not clear if the relation between the fir=
st and the second conditions is an "IF NOT".



 


Lionel


 






De : Steve Donovan [mailto:srdonovan@usdonova=
ns.com]


Envoy=E9 : lundi 10 f=E9vrier 2014 15:39

=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN=
 - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I think we have agree=
ment that a realm report applies to all traffic targeted for that realm, in=
dependent of the presence or absence of the destination-host avp.  Is =
that correct?



I don't agree with Lionel's proposal.  The realm overload report shoul=
d take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was written "except&q=
uot; :)


 


The abatement for the Realm applies when NO explicit reduction is requ=
ested for a specific node of this realm. In such a case i.e. when an OLR is=
 received for a specific node inside a realm for which a reduction also app=
lies, *ONLY* the reduction requested for the node applied.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext lionel.morand@oran=
ge.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




I better like Lionel's approach, but even that is not ok in the unlike=
ly extreme case where we have two servers in a realm, S1 is not overloaded =
at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why=
 should a client do a 25% throttling when sending host type requests to the=
 not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?


<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?<=
/pre>

 


If this means the realm abatement is still applied after applying


the host abatement, then I agree it is not the same you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; dime@ietf.org<=
/pre>

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


I tend to agree except that I would reverse the logic as for the routi=
ng principles: the Destination-host takes precedence when present over Dest=
ination-Realm. So the realm abatement is applied in any case except if ther=
e is an explicit report for the destination-host.


 


Lioenl


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


It makes more sense to me for a realm report to apply to all requests =
targeted for that realm, independent the type of request.  This implie=
s that it would apply to requests that also have a Destination-Host specifi=
ed.


 


If this is the definition of a realm report then we need to specify th=
e interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm first and the host =
second.  If a message targetted for the host is throttled as a result =
of realm overload then that throttled message would count as part of the re=
duction needed to address the host overload.  Messages to the host tha=
t survive realm abatement would then be candidates for host overload.


 


Steve


 


On 2/4/14 11:12 AM, lionel=
.morand@orange.com wrote:


The case "Realm" as described below raises another question:=
 is it prohibited for a realm to only rely on a global overload report for =
the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm" would be recei=
ved by the reacting node. And the reduction indicated in the OLR will apply=
 always for the realm, whatever the presence of Destination-host AVP in the=
 request... except if an explicit report with the type "Host" as =
been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org


Objet : [dime] #34: Semantics of OC-Report-Type AVP


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to which requests over=
load


treatment of a given report type applies.


Proposal:


 


   0  A host report.  The overload treatment shoul=
d apply to requests


      for which all of the following conditio=
ns are true:


      a) The Destination-Host AVP is present =
in the request and its value


         matches the value of =
the Origin-Host AVP of the received message


         that contained the OC=
-OLR AVP.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overload treatment shou=
ld apply to


      requests for which all of the following=
 conditions are true:


      a) The Destination-Host AVP is absent i=
n the request.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


______________________________________________________________________=
___________________________________________________


 


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.<=
/pre>

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.


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


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.<=
/pre>

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.









______________________________________________________________________=
___________________________________________________

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_3tsn6b4h6c5tsypoe2hug1hm1392057602168emailandroidcom_--


From jouni.nospam@gmail.com  Mon Feb 10 14:12:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4034B1A08A8 for ; Mon, 10 Feb 2014 14:12:50 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03uiFEI8CtyZ for ; Mon, 10 Feb 2014 14:12:48 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18C1A03D6 for ; Mon, 10 Feb 2014 14:12:47 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id l4so5247100lbv.38 for ; Mon, 10 Feb 2014 14:12:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ODu2QJDcKems63N/ZyITgjR28fA1LyDpTL2BzrIJc4w=; b=E8g1lOPQ4WIcEBf01gRC+sJ2wajdWhQb3QJaBMVwEj6XE6u+xaC2TkIbm4VLln9p1g vs/ScfK/fJaQ9XgYawz1DmbRzONF/BmgUer5/q2U+vWh3D+zQG/ff4N2NUUn3lYmp8Zc Dq8W7W5+6+ucwju+0SirEA9uml/6bZIIv+ZXdFw1RZL6Uk8+LfRC7pMAn38K+wjvLcQm 2LIiDRUaJFs+jhTeErPASColaAlmLxqKXAUgc48tTKHLFPe5TeIvfTJGtZQKG2BXGGIX 0tATS7RChtgbFromR7TdZIugV0+1Sz+yp8KhCfJJKsZ9vGfN/+4Oy5ztSrqvWXnElF2C li7A==
X-Received: by 10.112.142.230 with SMTP id rz6mr22559493lbb.0.1392070367075; Mon, 10 Feb 2014 14:12:47 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id t5sm24260585lat.6.2014.02.10.14.12.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 14:12:43 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com>
Date: Tue, 11 Feb 2014 00:12:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 22:12:50 -0000

Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell  wrote:

> Okay. Does that mean we should assign the issue to me in the tracker?
>=20
> On Feb 10, 2014, at 10:06 AM, Jouni Korhonen  =
wrote:
>=20
>>=20
>> Ben,
>>=20
>> Propose some text and we can see how it fits in.
>>=20
>> - Jouni
>>=20
>>=20
>> On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:
>>=20
>>>=20
>>> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  =
wrote:
>>>=20
>>>>=20
>>>> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>>>>=20
>>>>> #45: Why is a validity duration of 0 disallowed?
>>>>>=20
>>>>> Section 4.5 disallows a validity duration of zero. Why do we want =
to
>>>>> disallow that? It would allow a quick way of ending any existing =
overload
>>>>> condition without worrying about the semantics of the abatement =
algorithm.
>>>>> (We currently use a reduction percentage of zero to end an =
overload
>>>>> condition--but that's specific to the loss algorithm and might not =
make
>>>>> sense for all future ones.)
>>>>=20
>>>> Right. Avoiding two ways of ending overload condition was the =
reason.
>>>> I am OK to have validity duration 0 as an additional method ending =
the
>>>> overload condition based on the reasoning above.
>>>>=20
>>>=20
>>> I would go further and make duration 0 the _preferred_ way, for two =
reasons:
>>>=20
>>> 1) It's algorithm independent. (reduction-percentage of 0 is =
specific to algorithms that use reduction percentage.)
>>>=20
>>> 2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.
>>>=20
>>>=20
>>=20
>=20


From jouni.nospam@gmail.com  Mon Feb 10 14:15:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C871A03D6 for ; Mon, 10 Feb 2014 14:15:32 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvGvGnZPe-h4 for ; Mon, 10 Feb 2014 14:15:29 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id A7A931A0336 for ; Mon, 10 Feb 2014 14:15:28 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id w7so5193240lbi.21 for ; Mon, 10 Feb 2014 14:15:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vwHGg/nTv4qQVuaac9wIsxANY6t8ofcZqWaHDppyx8o=; b=rjUZxW4tJR7qLNpQJFcz++OCUUQyc4oTgbhO6zxrSPojMz7ulUmbf5N3P2OBVr64Vl HEdC/juzO80bEMfaGghmBN0vUbxqB5OAC5AxjtesG761ZxoRJ5RhiE2fmAxzZJlc3mhh 2elxq6Da0yDlODMMelxS1ahpqMGPNWWFOmj8B6K0hewYsUZHcwF9mwcteGCHtaHbyfWN 3u+VMLSD4S3dgFwwGgpa0Y2MUW9zSz6SpUnAijVFL6uUulQVbQuAg29zHpjpcTFG15Wb wevHlcG5YqnEd30oltdUeE/Di7uujdbEWDTrquEbjq8fXjfpLImGNOpnUOmMqXy/CDBD vc0w==
X-Received: by 10.112.170.234 with SMTP id ap10mr20235963lbc.23.1392070527709;  Mon, 10 Feb 2014 14:15:27 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id 10sm24284701lan.5.2014.02.10.14.15.23 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 14:15:23 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <30449_1392050784_52F90260_30449_13393_1_6B7134B31289DC4FAF731D844122B36E497B94@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Tue, 11 Feb 2014 00:15:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <12D14ECE-5B44-4A54-9E04-1AEE25B11449@gmail.com>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com>  <52F8F6FB.4070306@usdonovans.com> <30449_1392050784_52F90260_30449_13393_1_6B7134B31289DC4FAF731D844122B36E497B94@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: lionel.morand@orange.com
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 22:15:32 -0000

+1

On Feb 10, 2014, at 6:46 PM, lionel.morand@orange.com wrote:

> Thank you for the summary.
> =20
> I'm fine with all the bullets! J
> =20
> Lionel
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : lundi 10 f=E9vrier 2014 16:58
> =C0 : dime@ietf.org
> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
> =20
> I agree it needs to be stated in the draft.
>=20
> Steve
>=20
> On 2/10/14 9:44 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi Steve
> =20
> Thanks to have summarize this topic. I agree with your various =
statements that reflect in particular my own comments.
> =20
> About mandatory for the default (loss) algorithm, effectively we  need =
this for interoperability. Cannot it be stated in the draft? Future RFCs =
will have to be compatible with this .
> =20
> Best regards
> =20
> JJacques  =20
> =20
> =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : lundi 10 f=E9vrier 2014 16:08
> =C0 : dime@ietf.org
> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
> =20
> I'll attempt to summarize where we are on this.  If this is agreed to =
then the necessary changes would be made to the -01 draft.  Some of this =
is already in the draft, some of it will require changes.
>=20
> - The draft already makes it optional for the reporting node to =
include the OC-Supported-Features AVP in answer messages - No change =
required here.
>=20
> - A reporting node must choose the overload abatement algorithm to be =
sent to a reacting node from the set of abatement algorithms included in =
the OC-Supported-Features AVP received in the request message.
>=20
> - If the reporting node sends an OC-OLR AVP and there is no =
OC-Supported-Features AVP then the abatement algorithm used by the =
reacting node must be loss.
>=20
> - The reporting node may include the OC-Supported-Features AVP with =
the loss algorithm indicated in the OC-Feature-Vector AVP.
>=20
> - If the reporting node wants the reacting node to apply an algorithm =
other then loss, the reacting node must include the =
OC-Supported-Features AVP with a single algorithm indicated in the =
OC-Feature-Vector AVP.=20
>=20
> - New abatement algorithm extensions may use and extend the existing =
OC-OLR AVP.  The new algorithms may also create a new overload report =
AVP if that makes the most sense.
>=20
> - The loss algorithm is and always will be the mandatory to implement =
algorithm.  Or it will be until a new RFC is published that changes the =
mandatory to implement algorithm.
>=20
> Steve
>=20
> On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:
> =20
> =20
> -----Message d'origine-----
> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Envoy=E9 : lundi 10 f=E9vrier 2014 12:24
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
> =20
> =20
> On Feb 10, 2014, at 1:15 PM,  wrote:
> =20
> Hi Jouni,
> =20
> As the syntax of the OC-Feature-Vector is adapted to advertize =
supported algos, it could be easier to clarify that the OC-OLR AVP is =
THE report AVP for the reduction algo (default) and a new dedicated =
report AVP must be created when a new algo is introduced. In this way, =
the OC-OLR is self-explicit.
> =20
> Bah. OLR should work for additional abatement algorithms
> IF we agree that the OLR is align with the announced
> abatement algorithm..=20
> =20
> [LM] The issue if when you have more than one algo (let say 2). There =
is no way for the reporting node to indicate the algo to use with the =
OLR sent in the answer using the OC-Feature-Vector. The only info that =
you could have is "use either one or the other".
> =20
> This we can fix (and I personally would like to fix). The reporting =
node
> announces in its OC-Feature-Vector the selected common algorithm for =
the
> sent OLR. We had this at some point of time, btw.
> =20
> [LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector =
MAY be used (when present) to indicate the algo to use, algo part of the =
common algos between the reporting node and the reacting node.
> =20
> The simpliest way would be to define a new AVP when you want to =
support more than the default algo. If you want to rely on the same OLR =
with another algo, you should have a way to indicate the algo to use =
with the given OLR.
> =20
> I recall there was a strong arguments against algorithm types in =
OLRs..
> =20
> [LM] I was not proposing such idea :)
> =20
> - Jouni
> =20
> =20
> =20
> It would be purely optional to send the Supported-Features AVP along =
with the OC-OLR AVP.
> =20
> It is already today if you only support the default, right.
> =20
> [LM] Right. No issue here.
> =20
> -----Message d'origine-----
> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
> =20
> =20
> On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:
> =20
> I think that there is actually an issue here but the proposed way to =
solve it is not the correct one.
> =20
> Agree.
> =20
> The initial idea was to be able to use the same overload report with =
several algorithms. So the OLR was somehow only meaningful along with =
the OC-Feature-Vector AVP.
> =20
> The initial idea was to go on lines of RFC5447.
> =20
> But because the OC-Feature-Vector AVP is defined as a set of flags, it =
is not possible to say that this OLR is to be used with only one given =
algo when more than one is defined (as the bit flags will advertize 1 =
AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to =
indicate the abatement to perform.
> =20
> My intention was always allow:
> =20
>  client announces  ABC
>  server supports    BCD
>  server announced only  e.g. C since it is common
>  alternatively server announced nothing and then the default applies
> =20
> As the syntax of the OC-Feature-Vector is adapted to advertize =
supported algos, it could be easier to clarify that the OC-OLR AVP is =
THE report AVP for the reduction algo (default) and a new dedicated =
report AVP must be created when a new algo is introduced. In this way, =
the OC-OLR is self-explicit.
> =20
> Bah. OLR should work for additional abatement algorithms
> IF we agree that the OLR is align with the announced
> abatement algorithm..=20
> =20
> It would be purely optional to send the Supported-Features AVP along =
with the OC-OLR AVP.
> =20
> It is already today if you only support the default, right.
> =20
> - Jouni
> =20
> =20
> Lionel=20
> =20
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20
> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #30: OC-Supported-Features AVP in answer messages
> =20
> #30: OC-Supported-Features AVP in answer messages
> =20
> According to the current feature advertisement/negotiation mechanism =
in
> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features =
AVP
> in answer messages to indicate their supported OC features to the =
reacting
> DOIC endpoint.
> The author of this document believes that  the best a reacting node =
can do
> with such information is to ignore it, and therefore proposes to allow
> reporting nodes not to insert OC-Supported-Features AVPs in answer
> messages.
> Currently only one feature is defined (OLR_DEFAULT_ALGO).
> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no =
other
> feature is only interested in receiving/not receiving OC-OLR AVPs from
> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
> support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not =
receiving
> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:
> =20
> a) There is no overload
> b) DOIC is not supported
> =20
> The reacting DOIC endpoint does not need to differentiate between =
these
> two cases as the behavior (do not throttle) is the same in both cases.
> The -01 draft says in  clause 4.1:
>   If there is no single matching
>   capability the reacting node MUST act as if it does not implement
>   DOIC and cease inserting any DOIC related AVPs into any Diameter
>   messages with this specific reacting node.
> =20
> This however is inconsistent.
> The reacting node that ceases sending DOIC related AVPs would never
> recognize when the server is upgraded to support DOIC.
> Subsequent requests (not including DOIC related AVPs) may take a =
different
> path towards the server and on that path there may be an agent that
> supports DOIC (with a match of supported features) and could take the =
role
> of the reporting DOIC endpoint; but the agent cannot take this role =
since
> the reacting node (although supporting DOIC) ceased sending of OC-
> Supported-Features AVPs.
> In summary: As long as no extension feature is defined within  =
draft-ietf-
> dime-ovli  (i.e. never, since extensions will  be defined in other
> drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
> describe inclusion of OC-Supported-Features AVP in answer messages.
> =20
> --=20
> --------------------------------------+--------------------------
> Reporter:  lionel.morand@orange.com  |      Owner:  Ulrich Wiehe
>    Type:  defect                    |     Status:  new
> Priority:  major                     |  Milestone:
> Component:  draft-docdt-dime-ovli     |    Version:
> Severity:  Active WG Document        |   Keywords:
> --------------------------------------+--------------------------
> =20
> Ticket URL: 
> dime 
> =20
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> =20
> =20
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Mon Feb 10 14:27:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880681A0605 for ; Mon, 10 Feb 2014 14:27:28 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhDBnojVZ5cX for ; Mon, 10 Feb 2014 14:27:25 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE71A05F2 for ; Mon, 10 Feb 2014 14:27:24 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id q8so5411675lbi.28 for ; Mon, 10 Feb 2014 14:27:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EtQ2UZiLKnGDbQDFOWGfcWiBthNNAEvl4BujrLHH+Ik=; b=QpdjdOqKzxKNN9ALlctZoHKXNb4hkA5ruOxz0BF4lAjl+WLW68bTawMLe1XFemHAeF ipP+c6cqRIum13PKKcV7GCo8d94ho5cQADXt6HpJN4cDc5SDxngvCgIG6+6xDAawQSKj 8rLbiNY4Yh7DutpgL5tKJrCHDUMGeZAkApVomB1d+XWoOl0F6bJN8tfLajGWCK7QsxhB rR+n7v8obLSNTdKnpS0f1XOONHCuu/PItjdv4yLaaTWiBNYiyEsyWoSL8fPo05g6F7Qh BIU7mz77MKcWcJH+Xrr5mqkZrcQpeHuK6Fed1vap5u4Bi0KPM0e8RO1BS23w5k1I97Sj 6llQ==
X-Received: by 10.152.164.166 with SMTP id yr6mr23804287lab.1.1392071244005; Mon, 10 Feb 2014 14:27:24 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id l4sm17246861lbd.15.2014.02.10.14.27.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 14:27:20 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <52F90653.6040104@usdonovans.com>
Date: Tue, 11 Feb 2014 00:27:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com>
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Cc: ben@nostrum.com, dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 22:27:28 -0000

Basically yes.. however, if there are other DOIC AVPs in the=20
request, then the absence of the OC-Supported-Features is
interpreted as support for the default abatement algorithm.
We should have that behaviour in both requests and answers.

- Jouni

On Feb 10, 2014, at 7:03 PM, Steve Donovan  =
wrote:

> My sense from recent discussions is that the lifetime of the =
OC-Supported-Feature AVP is assumed to be one transaction.  This means =
that the AVP must be included in all request messages sent by a reacting =
node.
>=20
> Steve
>=20
> On 2/7/14 4:19 PM, dime issue tracker wrote:
>> #49: capabilities announcement mechanism needs to be rethought
>>=20
>>  The capabilities announcement mechanism needs serious rethought.
>>  Specifically, the lifetime of the state associated with a =
capabilities
>>  announcement is unclear. It does not make sense to tie that lifetime =
to
>>  Diameter session lifetimes, unless we expect to have different =
capability
>>  sets for different sessions. (and it doesn't help at all for =
non-session
>>  applications or pseudo-sessions.)
>>=20
>>  I think we either need to mandate that the capabilities are =
stateless,
>>  that is, must be included in every request, and any OLR in a =
response must
>>  match the OC-Supported-Features from the corresponding request.
>>  Otherwise, we need a way to activate and deactivate the set =
associated
>>  with a capabilities set.
>>=20
>>  (This is a side effect of allowing DOIC to cross non-supporting =
agents. If
>>  we didn't allow that, we could make DOIC support and capabilites
>>  negotiation happen as part of the CAR exchange. )
>>=20
>>=20
>=20


From ben@nostrum.com  Mon Feb 10 14:51:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F097C1A08AA for ; Mon, 10 Feb 2014 14:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbI1QDUJTzoM for ; Mon, 10 Feb 2014 14:51:04 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 004FD1A0488 for ; Mon, 10 Feb 2014 14:51:03 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1AMovAo005018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 16:50:59 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com>
Date: Mon, 10 Feb 2014 16:50:56 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 22:51:06 -0000

It would be easier to implement if there was a single AVP that indicated =
support (or lack of support by its absence), rather than having more =
than one, any of which indicate support.

On Feb 10, 2014, at 4:27 PM, Jouni Korhonen  =
wrote:

>=20
> Basically yes.. however, if there are other DOIC AVPs in the=20
> request, then the absence of the OC-Supported-Features is
> interpreted as support for the default abatement algorithm.
> We should have that behaviour in both requests and answers.
>=20
> - Jouni
>=20
> On Feb 10, 2014, at 7:03 PM, Steve Donovan  =
wrote:
>=20
>> My sense from recent discussions is that the lifetime of the =
OC-Supported-Feature AVP is assumed to be one transaction.  This means =
that the AVP must be included in all request messages sent by a reacting =
node.
>>=20
>> Steve
>>=20
>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>> #49: capabilities announcement mechanism needs to be rethought
>>>=20
>>> The capabilities announcement mechanism needs serious rethought.
>>> Specifically, the lifetime of the state associated with a =
capabilities
>>> announcement is unclear. It does not make sense to tie that lifetime =
to
>>> Diameter session lifetimes, unless we expect to have different =
capability
>>> sets for different sessions. (and it doesn't help at all for =
non-session
>>> applications or pseudo-sessions.)
>>>=20
>>> I think we either need to mandate that the capabilities are =
stateless,
>>> that is, must be included in every request, and any OLR in a =
response must
>>> match the OC-Supported-Features from the corresponding request.
>>> Otherwise, we need a way to activate and deactivate the set =
associated
>>> with a capabilities set.
>>>=20
>>> (This is a side effect of allowing DOIC to cross non-supporting =
agents. If
>>> we didn't allow that, we could make DOIC support and capabilites
>>> negotiation happen as part of the CAR exchange. )
>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Feb 10 15:55:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8D1A0705 for ; Mon, 10 Feb 2014 15:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level: 
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoQmvMq154fI for ; Mon, 10 Feb 2014 15:55:48 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6FE1A070B for ; Mon, 10 Feb 2014 15:55:48 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ANteeJ007724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 17:55:42 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF4B147D-6EA8-47CB-B315-5D6E96241844"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>
Date: Mon, 10 Feb 2014 17:55:39 -0600
Message-Id: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 23:55:50 -0000

--Apple-Mail=_CF4B147D-6EA8-47CB-B315-5D6E96241844
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

So, here's some proposed text. (intentionally ignoring the related =
discussion about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 =
hours) MUST NOT be used. Invalid validity duration values are treated as =
if the OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity =
duration values are treated as if the OC-Validity-Duration AVP were not =
present. A value of zero (0) indicates that an existing overload =
condition has ended and that the reporting node is in a stable =
condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one =
hundred (100).  Values greater than 100 are interpreted as 100.  The =
value of 100 means that no traffic is expected, i.e. the reporting node =
is under a severe load and ceases to process any new messages. The =
Reduction-Percentage AVP MUST be present in an overload report that uses =
the default abatement algorithm.

Note that there is no zero (0) value defined for the =
Reduction-Percentage AVP. A zero value would logically indicate that no =
overload abatement is requested. Instead, reporting nodes use a =
OC-Validity-Duration AVP value of zero (0) to indicate the end of an =
overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen  =
wrote:

> Just post it here.
>=20
>=20
>=20
> On Feb 10, 2014, at 6:25 PM, Ben Campbell  wrote:
>=20
>> Okay. Does that mean we should assign the issue to me in the tracker?
>>=20
>> On Feb 10, 2014, at 10:06 AM, Jouni Korhonen  =
wrote:
>>=20
>>>=20
>>> Ben,
>>>=20
>>> Propose some text and we can see how it fits in.
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>> On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:
>>>=20
>>>>=20
>>>> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen =
 wrote:
>>>>=20
>>>>>=20
>>>>> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>>>>>=20
>>>>>> #45: Why is a validity duration of 0 disallowed?
>>>>>>=20
>>>>>> Section 4.5 disallows a validity duration of zero. Why do we want =
to
>>>>>> disallow that? It would allow a quick way of ending any existing =
overload
>>>>>> condition without worrying about the semantics of the abatement =
algorithm.
>>>>>> (We currently use a reduction percentage of zero to end an =
overload
>>>>>> condition--but that's specific to the loss algorithm and might =
not make
>>>>>> sense for all future ones.)
>>>>>=20
>>>>> Right. Avoiding two ways of ending overload condition was the =
reason.
>>>>> I am OK to have validity duration 0 as an additional method ending =
the
>>>>> overload condition based on the reasoning above.
>>>>>=20
>>>>=20
>>>> I would go further and make duration 0 the _preferred_ way, for two =
reasons:
>>>>=20
>>>> 1) It's algorithm independent. (reduction-percentage of 0 is =
specific to algorithms that use reduction percentage.)
>>>>=20
>>>> 2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.
>>>>=20
>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--Apple-Mail=_CF4B147D-6EA8-47CB-B315-5D6E96241844
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


So, here's some proposed =
text. (intentionally ignoring the related discussion about handling =
invalid values):

Section 4.5, first paragraph, =
last 2 =
sentences:

Old:

Validity=
 duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) =
MUST NOT be used. Invalid validity duration values are treated as if the =
OC-Validity-Duration AVP were not =
present.

New:

Validity =
duration values above 86400 MUST NOT be used. Invalid validity duration =
values are treated as if the OC-Validity-Duration AVP were not present. =
A value of zero (0) indicates that an existing overload condition has =
ended and that the reporting node is in a stable =
condition.

Section 4.7, 2nd =
paragraph:

Old:

&nb=
sp;The value of the Reduction-Percentage AVP is between one (1) and one =
hundred (100).  Values greater than 100 are interpreted as 100. =
 The value of 100 means that no traffic is expected, i.e. the =
reporting node is under a severe load and ceases to process any new =
messages. The Reduction-Percentage AVP MUST be present in an overload =
report that uses the default abatement =
algorithm.

Note that there is no zero =
(0) value defined for the Reduction-Percentage AVP. A zero value would =
logically indicate that no overload abatement is requested. Instead, =
reporting nodes use a OC-Validity-Duration AVP value of zero (0) to =
indicate the end of an overload condition. [Section =
4.5]



=




On Feb 10, 2014, at 4:12 PM, Jouni =
Korhonen <jouni.nospam@gmail.com> =
wrote:

Just post it =
here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> =
wrote:

Okay. Does that mean we should =
assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 =
AM, Jouni Korhonen <jouni.nospam@gmail.com> =
wrote:


Ben,

Propose some =
text and we can see how it fits in.

- Jouni


On Feb 10, =
2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> =
wrote:


On Feb 10, 2014, at 5:12 AM, =
Jouni Korhonen <jouni.nospam@gmail.com> =
wrote:


On Feb 7, 2014, at 11:54 PM, =
dime issue tracker <trac+dime@trac.tools.ietf.or=
g> wrote:

#45: Why is a validity =
duration of 0 disallowed?

Section 4.5 disallows a validity =
duration of zero. Why do we want to
disallow that? It would allow a =
quick way of ending any existing overload
condition without worrying =
about the semantics of the abatement algorithm.
(We currently use a =
reduction percentage of zero to end an overload
condition--but that's =
specific to the loss algorithm and might not make
sense for all =
future ones.)

Right. Avoiding two ways of ending =
overload condition was the reason.
I am OK to have validity duration =
0 as an additional method ending the
overload condition based on the =
reasoning above.


I would go further and make =
duration 0 the _preferred_ way, for two reasons:

1) It's =
algorithm independent. (reduction-percentage of 0 is specific to =
algorithms that use reduction percentage.)

2) Explicit signaling =
of the end of an overload condition becomes semantically identical to =
the expiration of an overload condition. This allows a simpler =
implementation.




=

_______________________________________________
DiME mailing =
list
DiME@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/dime

=

--Apple-Mail=_CF4B147D-6EA8-47CB-B315-5D6E96241844--


From ben@nostrum.com  Mon Feb 10 16:14:37 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6121A066E for ; Mon, 10 Feb 2014 16:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5PZnTkAfYcO for ; Mon, 10 Feb 2014 16:14:34 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 63AD21A06FA for ; Mon, 10 Feb 2014 16:14:34 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1B0EUEw008425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 18:14:33 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <52F8EB36.9050501@usdonovans.com>
Date: Mon, 10 Feb 2014 18:14:29 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 00:14:37 -0000

I don't quite agree with where I think this thread is going, on two =
points:

1) I want the reacting node to be able to learn if a (potentially) =
reporting node supports DOIC, even when that node is not in overload. I =
don't want to specify any particular behavior for that knowledge, but I =
suspect implementations may want to treat DOIC compliant servers in some =
way differently than they do non-DOIC servers. For example, I might have =
a configured rate limit for non-DOIC peers, but use a higher (or no) =
limit for peers that are known to support DOIC (and can thus speak for =
themselves.)

2) It's clumsy to have to look at an external (to OC-OLR) AVP to find =
out the algorithm. I think the actual algorithm for a particular report =
should be indicated in OC-OLR, not OC-Supported-Features at the root of =
the message.


Now, separate from those points, I think we should consider whether it's =
okay for a reporting nodes to switch algorithms mid-stream, vs pick an =
algorithm and stick with it. Right now, I think we effectively allow a =
reporting node to send an OLR for one algorithm in one answer, then =
another algorithm in the next, even for the same reacting node. If so, =
we need to define what it means when that happens.

For example, if I receive an OLR with the "loss" algorithm, and another =
with the "rate" algorithm from the same server, does the second replace =
the first? Do I now have two overload state entries that I need to =
"stack"?

Thanks!

Ben.

On Feb 10, 2014, at 9:07 AM, Steve Donovan  =
wrote:

> I'll attempt to summarize where we are on this.  If this is agreed to =
then the necessary changes would be made to the -01 draft.  Some of this =
is already in the draft, some of it will require changes.
>=20
> - The draft already makes it optional for the reporting node to =
include the OC-Supported-Features AVP in answer messages - No change =
required here.
>=20
> - A reporting node must choose the overload abatement algorithm to be =
sent to a reacting node from the set of abatement algorithms included in =
the OC-Supported-Features AVP received in the request message.
>=20
> - If the reporting node sends an OC-OLR AVP and there is no =
OC-Supported-Features AVP then the abatement algorithm used by the =
reacting node must be loss.
>=20
> - The reporting node may include the OC-Supported-Features AVP with =
the loss algorithm indicated in the OC-Feature-Vector AVP.
>=20
> - If the reporting node wants the reacting node to apply an algorithm =
other then loss, the reacting node must include the =
OC-Supported-Features AVP with a single algorithm indicated in the =
OC-Feature-Vector AVP.=20
>=20
> - New abatement algorithm extensions may use and extend the existing =
OC-OLR AVP.  The new algorithms may also create a new overload report =
AVP if that makes the most sense.
>=20
> - The loss algorithm is and always will be the mandatory to implement =
algorithm.  Or it will be until a new RFC is published that changes the =
mandatory to implement algorithm.
>=20
> Steve=20
>=20
> On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:
>>=20
>> -----Message d'origine-----
>> De : Jouni Korhonen [
>> mailto:jouni.nospam@gmail.com
>> ]=20
>> Envoy=E9 : lundi 10 f=E9vrier 2014 12:24
>> =C0 : MORAND Lionel IMT/OLN
>> Cc :=20
>> dime@ietf.org
>>=20
>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
>>=20
>>=20
>> On Feb 10, 2014, at 1:15 PM,=20
>> 
>>  wrote:
>>=20
>>=20
>>> Hi Jouni,
>>>=20
>>>=20
>>>> As the syntax of the OC-Feature-Vector is adapted to advertize =
supported algos, it could be easier to clarify that the OC-OLR AVP is =
THE report AVP for the reduction algo (default) and a new dedicated =
report AVP must be created when a new algo is introduced. In this way, =
the OC-OLR is self-explicit.
>>>>=20
>>> Bah. OLR should work for additional abatement algorithms
>>> IF we agree that the OLR is align with the announced
>>> abatement algorithm..=20
>>>=20
>>> [LM] The issue if when you have more than one algo (let say 2). =
There is no way for the reporting node to indicate the algo to use with =
the OLR sent in the answer using the OC-Feature-Vector. The only info =
that you could have is "use either one or the other".
>>>=20
>> This we can fix (and I personally would like to fix). The reporting =
node
>> announces in its OC-Feature-Vector the selected common algorithm for =
the
>> sent OLR. We had this at some point of time, btw.
>>=20
>> [LM] Acceptable! So in answer including the OLR, the =
OC-Feature-Vector MAY be used (when present) to indicate the algo to =
use, algo part of the common algos between the reporting node and the =
reacting node.
>>=20
>>=20
>>> The simpliest way would be to define a new AVP when you want to =
support more than the default algo. If you want to rely on the same OLR =
with another algo, you should have a way to indicate the algo to use =
with the given OLR.
>>>=20
>> I recall there was a strong arguments against algorithm types in =
OLRs..
>>=20
>> [LM] I was not proposing such idea :)
>>=20
>> - Jouni
>>=20
>>=20
>>>=20
>>>> It would be purely optional to send the Supported-Features AVP =
along with the OC-OLR AVP.
>>>>=20
>>> It is already today if you only support the default, right.
>>>=20
>>> [LM] Right. No issue here.
>>>=20
>>> -----Message d'origine-----
>>> De : Jouni Korhonen [
>>> mailto:jouni.nospam@gmail.com
>>> ]=20
>>> Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04
>>> =C0 : MORAND Lionel IMT/OLN
>>> Cc :=20
>>> dime@ietf.org
>>>=20
>>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
>>>=20
>>>=20
>>> On Feb 4, 2014, at 5:01 PM,=20
>>> lionel.morand@orange.com
>>>  wrote:
>>>=20
>>>=20
>>>> I think that there is actually an issue here but the proposed way =
to solve it is not the correct one.
>>>>=20
>>> Agree.
>>>=20
>>>=20
>>>> The initial idea was to be able to use the same overload report =
with several algorithms. So the OLR was somehow only meaningful along =
with the OC-Feature-Vector AVP.
>>>>=20
>>> The initial idea was to go on lines of RFC5447.
>>>=20
>>>=20
>>>> But because the OC-Feature-Vector AVP is defined as a set of flags, =
it is not possible to say that this OLR is to be used with only one =
given algo when more than one is defined (as the bit flags will =
advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector =
cannot be used to indicate the abatement to perform.
>>>>=20
>>> My intention was always allow:
>>>=20
>>>  client announces  ABC
>>>  server supports    BCD
>>>  server announced only  e.g. C since it is common
>>>  alternatively server announced nothing and then the default applies
>>>=20
>>>=20
>>>> As the syntax of the OC-Feature-Vector is adapted to advertize =
supported algos, it could be easier to clarify that the OC-OLR AVP is =
THE report AVP for the reduction algo (default) and a new dedicated =
report AVP must be created when a new algo is introduced. In this way, =
the OC-OLR is self-explicit.
>>>>=20
>>> Bah. OLR should work for additional abatement algorithms
>>> IF we agree that the OLR is align with the announced
>>> abatement algorithm..=20
>>>=20
>>>=20
>>>> It would be purely optional to send the Supported-Features AVP =
along with the OC-OLR AVP.
>>>>=20
>>> It is already today if you only support the default, right.
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>> Lionel=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : dime issue tracker [
>>>> mailto:trac+dime@trac.tools.ietf.org
>>>> ]=20
>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : [dime] #30: OC-Supported-Features AVP in answer messages
>>>>=20
>>>> #30: OC-Supported-Features AVP in answer messages
>>>>=20
>>>> According to the current feature advertisement/negotiation =
mechanism in
>>>> the -01 draft reporting DOIC endpoint insert an =
OC-Supported-Features AVP
>>>> in answer messages to indicate their supported OC features to the =
reacting
>>>> DOIC endpoint.
>>>> The author of this document believes that  the best a reacting node =
can do
>>>> with such information is to ignore it, and therefore proposes to =
allow
>>>> reporting nodes not to insert OC-Supported-Features AVPs in answer
>>>> messages.
>>>> Currently only one feature is defined (OLR_DEFAULT_ALGO).
>>>> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no =
other
>>>> feature is only interested in receiving/not receiving OC-OLR AVPs =
from
>>>> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly =
indicates
>>>> support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not =
receiving
>>>> an OC-OLR-AVP from the reporting DOIC endpoint may have two =
reasons:
>>>>=20
>>>> a) There is no overload
>>>> b) DOIC is not supported
>>>>=20
>>>> The reacting DOIC endpoint does not need to differentiate between =
these
>>>> two cases as the behavior (do not throttle) is the same in both =
cases.
>>>> The -01 draft says in  clause 4.1:
>>>>   If there is no single matching
>>>>   capability the reacting node MUST act as if it does not implement
>>>>   DOIC and cease inserting any DOIC related AVPs into any Diameter
>>>>   messages with this specific reacting node.
>>>>=20
>>>> This however is inconsistent.
>>>> The reacting node that ceases sending DOIC related AVPs would never
>>>> recognize when the server is upgraded to support DOIC.
>>>> Subsequent requests (not including DOIC related AVPs) may take a =
different
>>>> path towards the server and on that path there may be an agent that
>>>> supports DOIC (with a match of supported features) and could take =
the role
>>>> of the reporting DOIC endpoint; but the agent cannot take this role =
since
>>>> the reacting node (although supporting DOIC) ceased sending of OC-
>>>> Supported-Features AVPs.
>>>> In summary: As long as no extension feature is defined within  =
draft-ietf-
>>>> dime-ovli  (i.e. never, since extensions will  be defined in other
>>>> drafts), there is no need for draft-ietf-dime-ovli  to mandate or =
even
>>>> describe inclusion of OC-Supported-Features AVP in answer messages.
>>>>=20
>>>> --=20
>>>> --------------------------------------+--------------------------
>>>> Reporter: =20
>>>> lionel.morand@orange.com
>>>>   |      Owner:  Ulrich Wiehe
>>>>    Type:  defect                    |     Status:  new
>>>> Priority:  major                     |  Milestone:
>>>> Component:  draft-docdt-dime-ovli     |    Version:
>>>> Severity:  Active WG Document        |   Keywords:
>>>> --------------------------------------+--------------------------
>>>>=20
>>>> Ticket URL:=20
>>>> 
>>>>=20
>>>> dime=20
>>>> 
>>>>=20
>>>>=20
>>>>=20
>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>> they should not be distributed, used or copied without =
authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =
__________________________________________________________________________=
_______________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>>=20
>> 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


From srdonovan@usdonovans.com  Mon Feb 10 22:36:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0781A08C2 for ; Mon, 10 Feb 2014 22:36:10 -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
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 p1AjqR1j5V8G for ; Mon, 10 Feb 2014 22:36:09 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 33BC91A0699 for ; Mon, 10 Feb 2014 22:36:09 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59164 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WD0Ez-0005Hu-Iw; Mon, 10 Feb 2014 15:26:19 -0800
Message-ID: <52F9605C.7000504@usdonovans.com>
Date: Mon, 10 Feb 2014 17:27:24 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Jouni Korhonen 
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com>
In-Reply-To: <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com>
Content-Type: multipart/alternative; boundary="------------080901070408020301050604"
X-OutGoing-Spam-Status: No, score=-2.9
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
Cc: ben@nostrum.com, dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 06:36:11 -0000

This is a multi-part message in MIME format.
--------------080901070408020301050604
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

It has been my assumption that the OC-OLR AVP would only be allowed in
answer messages.  Is this the consensus?

Steve

On 2/10/14 4:27 PM, Jouni Korhonen wrote:
> Basically yes.. however, if there are other DOIC AVPs in the 
> request, then the absence of the OC-Supported-Features is
> interpreted as support for the default abatement algorithm.
> We should have that behaviour in both requests and answers.
>
> - Jouni
>
> On Feb 10, 2014, at 7:03 PM, Steve Donovan  wrote:
>
>> My sense from recent discussions is that the lifetime of the OC-Supported-Feature AVP is assumed to be one transaction.  This means that the AVP must be included in all request messages sent by a reacting node.
>>
>> Steve
>>
>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>> #49: capabilities announcement mechanism needs to be rethought
>>>
>>>  The capabilities announcement mechanism needs serious rethought.
>>>  Specifically, the lifetime of the state associated with a capabilities
>>>  announcement is unclear. It does not make sense to tie that lifetime to
>>>  Diameter session lifetimes, unless we expect to have different capability
>>>  sets for different sessions. (and it doesn't help at all for non-session
>>>  applications or pseudo-sessions.)
>>>
>>>  I think we either need to mandate that the capabilities are stateless,
>>>  that is, must be included in every request, and any OLR in a response must
>>>  match the OC-Supported-Features from the corresponding request.
>>>  Otherwise, we need a way to activate and deactivate the set associated
>>>  with a capabilities set.
>>>
>>>  (This is a side effect of allowing DOIC to cross non-supporting agents. If
>>>  we didn't allow that, we could make DOIC support and capabilites
>>>  negotiation happen as part of the CAR exchange. )
>>>
>>>
>


--------------080901070408020301050604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    It has been my assumption
      that the OC-OLR AVP would only be allowed in answer messages.  Is
      this the consensus?

      

      Steve

      

    
    
On 2/10/14 4:27 PM, Jouni Korhonen
      wrote:

    

    

      
Basically yes.. however, if there are other DOIC AVPs in the 
request, then the absence of the OC-Supported-Features is
interpreted as support for the default abatement algorithm.
We should have that behaviour in both requests and answers.

- Jouni

On Feb 10, 2014, at 7:03 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
My sense from recent discussions is that the lifetime of the OC-Supported-Feature AVP is assumed to be one transaction.  This means that the AVP must be included in all request messages sent by a reacting node.

Steve

On 2/7/14 4:19 PM, dime issue tracker wrote:


        

          
#49: capabilities announcement mechanism needs to be rethought

 The capabilities announcement mechanism needs serious rethought.
 Specifically, the lifetime of the state associated with a capabilities
 announcement is unclear. It does not make sense to tie that lifetime to
 Diameter session lifetimes, unless we expect to have different capability
 sets for different sessions. (and it doesn't help at all for non-session
 applications or pseudo-sessions.)

 I think we either need to mandate that the capabilities are stateless,
 that is, must be included in every request, and any OLR in a response must
 match the OC-Supported-Features from the corresponding request.
 Otherwise, we need a way to activate and deactivate the set associated
 with a capabilities set.

 (This is a side effect of allowing DOIC to cross non-supporting agents. If
 we didn't allow that, we could make DOIC support and capabilites
 negotiation happen as part of the CAR exchange. )




        

        

      

      



    

    

  


--------------080901070408020301050604--


From jouni.nospam@gmail.com  Mon Feb 10 22:45:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC7E1A0355 for ; Mon, 10 Feb 2014 22:45:28 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am-D27c-GaxU for ; Mon, 10 Feb 2014 22:45:26 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4A79F1A07AF for ; Mon, 10 Feb 2014 22:45:26 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id ec20so5509902lab.37 for ; Mon, 10 Feb 2014 22:45:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P1hWbbbh+0baTJItYu2iugS5K0xiL2Oud8NBw3IK6K4=; b=k2iEpaCL44d4LxoRPATyXHKliiSRdKLb9U6lC9rCwr3hZbtvfLe0N9OnS1rTdeRw5z DTLbMih1ZsE8Fb+hqmmQsSE1vKmGNd2LhqqlBiSl/q+7Vsg3Mnla0MOQ8iTDEGCELU4Z GtAR/2+2rpU6OpMkUlQTAJACpDIaWCNX0b8o7b6vAKZ0BNX4sSqcndAqrbpNZQR6TF9d d1ThaahVKQUgM25RF4I/p8vvK/m3qGZBe6UaAZJY0wjjrFoyDxriNoJ9JLyTpU6RFcFq u+3/mXKgo2eN26tZQEP0NlkcRhmNKfDhgu6vGeEpHWaYWH2jXvzs8E4y3unFYZhTOjJr zaYQ==
X-Received: by 10.112.125.225 with SMTP id mt1mr4966206lbb.35.1392101125259; Mon, 10 Feb 2014 22:45:25 -0800 (PST)
Received: from [10.37.135.244] ([77.95.242.69]) by mx.google.com with ESMTPSA id e1sm26047786laa.8.2014.02.10.22.45.23 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 22:45:24 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <52F9605C.7000504@usdonovans.com>
Date: Tue, 11 Feb 2014 08:45:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com>
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com> <52F9605C.7000504@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Cc: ben@nostrum.com, dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 06:45:28 -0000

Your assumption is correct. "Other DOIC AVPs" is a future thing.
Currently we have no other DOIC AVPs for requests. It is just I
asking the same semantics for the OC-Supported-Features for both
directions.

- Jouni


On Feb 11, 2014, at 1:27 AM, Steve Donovan  =
wrote:

> It has been my assumption that the OC-OLR AVP would only be allowed in =
answer messages.  Is this the consensus?
>=20
> Steve
>=20
> On 2/10/14 4:27 PM, Jouni Korhonen wrote:
>> Basically yes.. however, if there are other DOIC AVPs in the=20
>> request, then the absence of the OC-Supported-Features is
>> interpreted as support for the default abatement algorithm.
>> We should have that behaviour in both requests and answers.
>>=20
>> - Jouni
>>=20
>> On Feb 10, 2014, at 7:03 PM, Steve Donovan=20
>> 
>>  wrote:
>>=20
>>=20
>>> My sense from recent discussions is that the lifetime of the =
OC-Supported-Feature AVP is assumed to be one transaction.  This means =
that the AVP must be included in all request messages sent by a reacting =
node.
>>>=20
>>> Steve
>>>=20
>>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>>=20
>>>> #49: capabilities announcement mechanism needs to be rethought
>>>>=20
>>>>  The capabilities announcement mechanism needs serious rethought.
>>>>  Specifically, the lifetime of the state associated with a =
capabilities
>>>>  announcement is unclear. It does not make sense to tie that =
lifetime to
>>>>  Diameter session lifetimes, unless we expect to have different =
capability
>>>>  sets for different sessions. (and it doesn't help at all for =
non-session
>>>>  applications or pseudo-sessions.)
>>>>=20
>>>>  I think we either need to mandate that the capabilities are =
stateless,
>>>>  that is, must be included in every request, and any OLR in a =
response must
>>>>  match the OC-Supported-Features from the corresponding request.
>>>>  Otherwise, we need a way to activate and deactivate the set =
associated
>>>>  with a capabilities set.
>>>>=20
>>>>  (This is a side effect of allowing DOIC to cross non-supporting =
agents. If
>>>>  we didn't allow that, we could make DOIC support and capabilites
>>>>  negotiation happen as part of the CAR exchange. )
>>>>=20
>>>>=20
>>>>=20
>>=20
>=20


From jouni.nospam@gmail.com  Mon Feb 10 23:37:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64921A03B5 for ; Mon, 10 Feb 2014 23:37:10 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f9XtsViQwzW for ; Mon, 10 Feb 2014 23:37:07 -0800 (PST)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id DFDC91A0769 for ; Mon, 10 Feb 2014 23:37:06 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id c6so5544144lan.38 for ; Mon, 10 Feb 2014 23:37:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ILLjLdLlEB32vMFrfV7md4ZiUXiZPA0EEQS4oTfPz4M=; b=tpOcO8ayc2TMU4h0sxf5t8/su7WfXYlNu/IoZUnwc8O23kfpWF96JhOirHcRfVfg3A yySe7oCfONo/XqaGUREfgUO4g7CZ0WnUHC2NkzKD4ojS7aoc0nBl0U333A6FPRVfsIND hc+5kssfJDVBeqJQEspfin6njYjt3kEAQOG/GSNC5j6FVm5SS3/COFMHIr/a8frB8j2/ ap3gZJ/JufnRczKfq4M8zoP2cPuJG/bENqnf5Y+06YYn9IoVrDoeQRWBZd2nFB0epUP9 /G0MpzamE/vvlMKalhYPl0iaAakcrJxP9qFy7fnhppAGBHMkQ+MhdNC43327gAc05QaN N3HQ==
X-Received: by 10.112.164.5 with SMTP id ym5mr285686lbb.48.1392104225839; Mon, 10 Feb 2014 23:37:05 -0800 (PST)
Received: from [192.168.250.217] ([194.100.71.98]) by mx.google.com with ESMTPSA id y2sm26237547lal.10.2014.02.10.23.37.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 23:37:05 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com>
Date: Tue, 11 Feb 2014 08:50:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9864EA44-A22D-4C4F-9A4C-55B826AB1699@gmail.com>
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com> <52F9605C.7000504@usdonovans.com> <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Cc: ben@nostrum.com, dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 07:37:11 -0000

Forgot to say that this is of course debatable. My preference
is/was to have the same behavior both directions but won't be
persistent on that.

- Jouni

On Feb 11, 2014, at 8:45 AM, Jouni Korhonen  =
wrote:

>=20
> Your assumption is correct. "Other DOIC AVPs" is a future thing.
> Currently we have no other DOIC AVPs for requests. It is just I
> asking the same semantics for the OC-Supported-Features for both
> directions.
>=20
> - Jouni
>=20
>=20
> On Feb 11, 2014, at 1:27 AM, Steve Donovan  =
wrote:
>=20
>> It has been my assumption that the OC-OLR AVP would only be allowed =
in answer messages.  Is this the consensus?
>>=20
>> Steve
>>=20
>> On 2/10/14 4:27 PM, Jouni Korhonen wrote:
>>> Basically yes.. however, if there are other DOIC AVPs in the=20
>>> request, then the absence of the OC-Supported-Features is
>>> interpreted as support for the default abatement algorithm.
>>> We should have that behaviour in both requests and answers.
>>>=20
>>> - Jouni
>>>=20
>>> On Feb 10, 2014, at 7:03 PM, Steve Donovan=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> My sense from recent discussions is that the lifetime of the =
OC-Supported-Feature AVP is assumed to be one transaction.  This means =
that the AVP must be included in all request messages sent by a reacting =
node.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>>>=20
>>>>> #49: capabilities announcement mechanism needs to be rethought
>>>>>=20
>>>>> The capabilities announcement mechanism needs serious rethought.
>>>>> Specifically, the lifetime of the state associated with a =
capabilities
>>>>> announcement is unclear. It does not make sense to tie that =
lifetime to
>>>>> Diameter session lifetimes, unless we expect to have different =
capability
>>>>> sets for different sessions. (and it doesn't help at all for =
non-session
>>>>> applications or pseudo-sessions.)
>>>>>=20
>>>>> I think we either need to mandate that the capabilities are =
stateless,
>>>>> that is, must be included in every request, and any OLR in a =
response must
>>>>> match the OC-Supported-Features from the corresponding request.
>>>>> Otherwise, we need a way to activate and deactivate the set =
associated
>>>>> with a capabilities set.
>>>>>=20
>>>>> (This is a side effect of allowing DOIC to cross non-supporting =
agents. If
>>>>> we didn't allow that, we could make DOIC support and capabilites
>>>>> negotiation happen as part of the CAR exchange. )
>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>>=20
>=20


From ulrich.wiehe@nsn.com  Tue Feb 11 01:37:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CCB1A0564 for ; Tue, 11 Feb 2014 01:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJcGRXEwQZd3 for ; Tue, 11 Feb 2014 01:37:21 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD111A0086 for ; Tue, 11 Feb 2014 01:37:20 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9bIZV024556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 10:37:19 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9bIj4009124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:37:18 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 10:37:18 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 10:37:18 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPI+1LK95DWDMaH0qQEyVc/ebDNpqpv0FwgATFJ4CAAUePcA==
Date: Tue, 11 Feb 2014 09:37:18 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B29A1@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> <52F8E5A7.6030902@usdonovans.com>
In-Reply-To: <52F8E5A7.6030902@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1784
X-purgate-ID: 151667::1392111439-00001A6F-0D9147F4/0-0/0-0
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 09:37:24 -0000

Steve,

I do not agree.

e.g.=20
1. reacting node sends Request with application ID =3D x to reporting node
2. reporting node sends back answer (containing an OLR) with application ID=
 =3D x
3. reacting node now may very well send  a new request with application ID =
=3D y to the reporting node without breaking any Diameter rules.=20
The new request sent in step 3 is NOT subject to throttling according to th=
e OLR received in step 2.
I hope this is not contentious.
In order to provide a complete list of conditions to say when an OLR of a g=
iven type applies to a new request, we should not let c) go by the board.

Ulrich


=20


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 10, 2014 3:44 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
> No need for this since we agreed that DOIC implicitly always refers=20
> to the application on which the DOIC AVPs are carried in.
> yes, we agreed on that, so c) is correct and it does not harm to =
keep c)
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way
for the application-id
in the answer message to be different than the application-id in the
request message without
breaking Diameter.

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


From ulrich.wiehe@nsn.com  Tue Feb 11 01:44:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18081A07CD for ; Tue, 11 Feb 2014 01:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO2XyXoSyQSV for ; Tue, 11 Feb 2014 01:44:18 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E082F1A0914 for ; Tue, 11 Feb 2014 01:43:54 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9hqj4014628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 10:43:52 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9hqkO028694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:43:52 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 10:43:52 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 10:43:51 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "lionel.morand@orange.com" , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUIACsQCAgAA/36CAAw1bAIABfVQAgAA0qoCAAU82sA==
Date: Tue, 11 Feb 2014 09:43:51 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B29B9@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com>
In-Reply-To: <52F8E495.8010404@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B29B9DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 32456
X-purgate-ID: 151667::1392111832-000025D0-983A691E/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 09:44:23 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B29B9DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, February 10, 2014 3:39 PM
To: lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munic=
h)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?
 NO, again:

..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% ov=
erloaded, and the aggregated realm overload is 25%. Why should a client do =
a 25% throttling when sending host type requests to the not at all overload=
ed S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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_5BCBA1FC2B7F0B4C9D935572D9000668151B29B9DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

 <=
/p>





From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Monday, February 10, 2014 3:39 PM

To: lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN - D=
E/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


I think we have agree=
ment that a realm report applies to all traffic targeted for that realm, in=
dependent of the presence or absence of the destination-host avp.  Is =
that correct?


<Ulrich> NO, again:<=
/b>


..we have two servers in a realm, S1 is not overl=
oaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25=
%. Why should a client do a 25% throttling when sending host type requests =
to the not at all overloaded S1?


What is wrong with letting the client<=
/span>


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?=



</Ulrich>


=




I don't agree with Lionel's proposal.  The realm overload repor=
t should take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was written "except&q=
uot; :)


 


The abatement for the Realm applies when NO explicit reduction is requ=
ested for a specific node of this realm. In such a case i.e. when an OLR is=
 received for a specific node inside a realm for which a reduction also app=
lies, *ONLY* the reduction requested for the node applied.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext lionel.morand@oran=
ge.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




I better like Lionel's approach, but even that is not ok in the unlike=
ly extreme case where we have two servers in a realm, S1 is not overloaded =
at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why=
 should a client do a 25% throttling when sending host type requests to the=
 not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?


<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is applied in any case


except if there is an explicit report for the destination-host"?<=
o:p>


 


If this means the realm abatement is still applied after applying=



the host abatement, then I agree it is not the same you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; dime@ietf.org<=
o:p>


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


I tend to agree except that I would reverse the logic as for the routi=
ng principles: the Destination-host takes precedence when present over Dest=
ination-Realm. So the realm abatement is applied in any case except if ther=
e is an explicit report for the destination-host.


 


Lioenl


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


It makes more sense to me for a realm report to apply to all requests =
targeted for that realm, independent the type of request.  This implie=
s that it would apply to requests that also have a Destination-Host specifi=
ed.


 


If this is the definition of a realm report then we need to specify th=
e interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm first and the host =
second.  If a message targetted for the host is throttled as a result =
of realm overload then that throttled message would count as part of the re=
duction needed to address the host overload.  Messages to the host tha=
t survive realm abatement would then be candidates for host overload.<=
/o:p>


 


Steve


 


On 2/4/14 11:12 AM, lionel=
.morand@orange.com wrote:


The case "Realm" as described below raises another question:=
 is it prohibited for a realm to only rely on a global overload report for =
the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm" would be recei=
ved by the reacting node. And the reduction indicated in the OLR will apply=
 always for the realm, whatever the presence of Destination-host AVP in the=
 request... except if an explicit report with the type "Host" as =
been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to which requests over=
load


treatment of a given report type applies.


Proposal:


 


   0  A host report.  The overload treatment shoul=
d apply to requests


      for which all of the following conditio=
ns are true:


      a) The Destination-Host AVP is present =
in the request and its value


         matches the value of =
the Origin-Host AVP of the received message


         that contained the OC=
-OLR AVP.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overload treatment shou=
ld apply to


      requests for which all of the following=
 conditions are true:


      a) The Destination-Host AVP is absent i=
n the request.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


______________________________________________________________________=
___________________________________________________


 


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.


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B29B9DEMUMBX014nsnin_--


From ulrich.wiehe@nsn.com  Tue Feb 11 01:55:12 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057191A0920 for ; Tue, 11 Feb 2014 01:55:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D31CIB6sZNce for ; Tue, 11 Feb 2014 01:55:04 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 393FA1A07CD for ; Tue, 11 Feb 2014 01:55:03 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9t0uC006027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 10:55:00 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9t0rG005962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:55:00 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 10:55:00 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 10:55:00 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "lionel.morand@orange.com" , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUIACsQCAgAA/36CAAw1bAIABfVQAgAA0qoCAACcaAIAADsuAgAEbR1A=
Date: Tue, 11 Feb 2014 09:54:59 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B29D6@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com>
In-Reply-To: <52F911CB.3070207@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B29D6DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 43351
X-purgate-ID: 151667::1392112501-000025D0-C968DFE4/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 09:55:12 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B29D6DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, February 10, 2014 6:52 PM
To: lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munic=
h)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

Why would the reduction for the realm be less than servers.  It is perfectl=
y valid for a realm overload report to ask for a reduction when there are n=
o servers in overload.
 I don't think so
  This could happen in the case I mentioned where the realm overload report=
 is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.
 all considerations other than server overload are (or should be) o=
ut of scope. (May be covered by agent overload control)

My logic was not quite correct, but for a different reason.  There is no re=
ason to do the host throttling if the request has already been throttled by=
 the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  This mig=
ht look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the destinatio=
n-host AVP
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    If host credits exist for the host indicated in the destination-host AV=
P:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request
 sounds quite complicated
Steve
On 2/10/14 10:59 AM, lionel.morand@orange.com wrote:
Hi Steve,

In your example, if an agent has a better knowledge than the server, the Ho=
st type OLR should not be sent unmodified in forwarded answers, or even rem=
oved as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than=
 the reduction needed for a node. S1 is not overload, S2 is 50% overload, t=
he realm (S1+S2) is overloaded 25%. So only the reduction for the Host shou=
ld apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between=
 the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : lundi 10 f=E9vrier 2014 15:39
=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich=
)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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_5BCBA1FC2B7F0B4C9D935572D9000668151B29D6DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

 <=
/p>





From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Monday, February 10, 2014 6:52 PM

To: lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN - D=
E/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


Lionel,



Why would the reduction for the realm be less than servers.  It is per=
fectly valid for a realm overload report to ask for a reduction when there =
are no servers in overload.=



<Ulrich> I don’t think so</Ulrich=
>


=
  This could happen in the case I mentioned where the realm overload r=
eport is triggered by layer 3 congestion.



Clearly realm overload will be significantly influenced by server ov=
erload, but that isn't the only consideration.


<Ulrich> all considerations other than ser=
ver overload are (or should be) out of scope. (May be covered by agent
 overload control)</Ulrich>



My logic was not quite correct, but for a different reason.  Th=
ere is no reason to do the host throttling if the request has already been =
throttled by the realm report.

It should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    Apply host based throttling logic to that request



One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm. 
This might look something like the following:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

    If request is throttled:

      Increment host credit by one for the host indicat=
ed in the destination-host AVP

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    If host credits exist for the host indicated in the dest=
ination-host AVP:

      Decrement host credit by one

    else:

      Apply host based throttling logic to that request=


<Ulrich> so=
unds quite complicated</Ulrich>
Steve




On 2/10/14 10:59 AM, 
lionel.morand@orange.com wrote:






Hi Steve,


 <=
/p>

In your ex=
ample, if an agent has a better knowledge than the server, the Host type OL=
R should not be sent unmodified in forwarded answers, or even
 removed as irrelevant.


 


And in a n=
ormal case, the reduction for the realm will be likely lower than the reduc=
tion needed for a node. S1 is not overload, S2 is 50% overload,
 the realm (S1+S2) is overloaded 25%. So only the reduction for the Hos=
t should apply, why the host-type should prevail over realm-type OLR.


 


By the way=
, in your proposed logic, it is not clear if the relation between the first=
 and the second conditions is an "IF NOT".



 


Lionel


 






De :=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Envoy=E9 : lundi 10 f=E9vrier 2014 15:39

=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN=
 - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I think we have agree=
ment that a realm report applies to all traffic targeted for that realm, in=
dependent of the presence or absence of the destination-host avp.  Is =
that correct?



I don't agree with Lionel's proposal.  The realm overload report shoul=
d take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was written "except&q=
uot; :)


 


The abatement for the Realm applies when NO explicit reduction is requ=
ested for a specific node of this realm. In such a case i.e. when an OLR is=
 received for a specific node inside a realm for which a reduction also app=
lies, *ONLY* the reduction requested for the node applied.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext lionel.morand@oran=
ge.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




I better like Lionel's approach, but even that is not ok in the unlike=
ly extreme case where we have two servers in a realm, S1 is not overloaded =
at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why=
 should a client do a 25% throttling when sending host type requests to the=
 not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?


<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is applied in any case


except if there is an explicit report for the destination-host"?<=
o:p>


 


If this means the realm abatement is still applied after applying=



the host abatement, then I agree it is not the same you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; dime@ietf.org<=
o:p>


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


I tend to agree except that I would reverse the logic as for the routi=
ng principles: the Destination-host takes precedence when present over Dest=
ination-Realm. So the realm abatement is applied in any case except if ther=
e is an explicit report for the destination-host.


 


Lioenl


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


It makes more sense to me for a realm report to apply to all requests =
targeted for that realm, independent the type of request.  This implie=
s that it would apply to requests that also have a Destination-Host specifi=
ed.


 


If this is the definition of a realm report then we need to specify th=
e interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm first and the host =
second.  If a message targetted for the host is throttled as a result =
of realm overload then that throttled message would count as part of the re=
duction needed to address the host overload.  Messages to the host tha=
t survive realm abatement would then be candidates for host overload.<=
/o:p>


 


Steve


 


On 2/4/14 11:12 AM, lionel=
.morand@orange.com wrote:


The case "Realm" as described below raises another question:=
 is it prohibited for a realm to only rely on a global overload report for =
the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm" would be recei=
ved by the reacting node. And the reduction indicated in the OLR will apply=
 always for the realm, whatever the presence of Destination-host AVP in the=
 request... except if an explicit report with the type "Host" as =
been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to which requests over=
load


treatment of a given report type applies.


Proposal:


 


   0  A host report.  The overload treatment shoul=
d apply to requests


      for which all of the following conditio=
ns are true:


      a) The Destination-Host AVP is present =
in the request and its value


         matches the value of =
the Origin-Host AVP of the received message


         that contained the OC=
-OLR AVP.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overload treatment shou=
ld apply to


      requests for which all of the following=
 conditions are true:


      a) The Destination-Host AVP is absent i=
n the request.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


______________________________________________________________________=
___________________________________________________


 


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.


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


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 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.




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B29D6DEMUMBX014nsnin_--


From nsalot@cisco.com  Tue Feb 11 01:57:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1B51A06BA for ; Tue, 11 Feb 2014 01:57:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgbcG8aYHPQl for ; Tue, 11 Feb 2014 01:57:48 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id D0A3A1A07CD for ; Tue, 11 Feb 2014 01:57:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43141; q=dns/txt; s=iport; t=1392112667; x=1393322267; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cLhTXNFd03tpEfb9xwdZqrCICs/xYsRpzsddwTVP4rk=; b=cmvX/Wrt1zJj8q2VG/Evb00Ih6JgrIYorBBROWIzXd+hbqy17jF6sFZT +Cd3DyS6jN/p/8vUiNaOm24gmpQWrVl4bQ16WPj18gxb8vHFu8H+oG3kQ 3OznYY5qMe1vBWJSq6TKZBq30nfKswCklxcw5g0eQSEcmj4+UDjKyuXhs Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAIDz+VKtJXG8/2dsb2JhbABZgkhEOFe+ZYENFnSCJQEBAQQBAQEXE0EEBwwEAgEIDgMEAQELFgEGByEGCxQJCAIEAQ0FCIdpAxENwFUNh2UTBIxfgTgRAR8GByAEBgECBIMegRQEiRCNLo5JhUODLYFxOQ
X-IronPort-AV: E=Sophos;i="4.95,824,1384300800"; d="scan'208,217";a="19500045"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 11 Feb 2014 09:57:45 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1B9vjLD031392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 09:57:45 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 03:57:45 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , "lionel.morand@orange.com" , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIcxPiNHLS9yLA0ansvPW8F8mkpqnJdmAgAAE6ICAABUugIACvZWAgAAwCoCAAx0wAIABfVUAgAA0qYCAACcaAIAADsyAgACoxCA=
Date: Tue, 11 Feb 2014 09:57:44 +0000
Message-ID: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com>
In-Reply-To: <52F911CB.3070207@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.140.48]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6973Bxmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 09:57:57 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6973Bxmbrcdx10ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

I don't understand one aspect.
Why should the request be throttled with realm report when the request is t=
argeted to a particular host within the realm.
Can this request be routed to another host in that realm? If not, the reque=
st should be subjected to the throttling based on the host report.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Monday, February 10, 2014 11:22 PM
To: lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munic=
h)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

Why would the reduction for the realm be less than servers.  It is perfectl=
y valid for a realm overload report to ask for a reduction when there are n=
o servers in overload.  This could happen in the case I mentioned where the=
 realm overload report is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.

My logic was not quite correct, but for a different reason.  There is no re=
ason to do the host throttling if the request has already been throttled by=
 the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  This mig=
ht look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the destinatio=
n-host AVP
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    If host credits exist for the host indicated in the destination-host AV=
P:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request

Steve
On 2/10/14 10:59 AM, lionel.morand@orange.com wrote:
Hi Steve,

In your example, if an agent has a better knowledge than the server, the Ho=
st type OLR should not be sent unmodified in forwarded answers, or even rem=
oved as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than=
 the reduction needed for a node. S1 is not overload, S2 is 50% overload, t=
he realm (S1+S2) is overloaded 25%. So only the reduction for the Host shou=
ld apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between=
 the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : lundi 10 f=E9vrier 2014 15:39
=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich=
)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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_A9CA33BB78081F478946E4F34BF9AAA014D6973Bxmbrcdx10ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,



 <=
/p>

I don’t understand =
one aspect.


Why should the request be=
 throttled with realm report when the request is targeted to a particular h=
ost within the realm.


Can this request be route=
d to another host in that realm? If not, the request should be subjected to=
 the throttling based on the host report.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





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

Sent: Monday, February 10, 2014 11:22 PM

To: lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN - D=
E/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


Lionel,



Why would the reduction for the realm be less than servers.  It is per=
fectly valid for a realm overload report to ask for a reduction when there =
are no servers in overload.  This could happen in the case I mentioned=
 where the realm overload report is triggered
 by layer 3 congestion.



Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.



My logic was not quite correct, but for a different reason.  There is =
no reason to do the host throttling if the request has already been throttl=
ed by the realm report.

It should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    Apply host based throttling logic to that request



One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  Thi=
s might look something like the following:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

    If request is throttled:

      Increment host credit by one for the host indicat=
ed in the destination-host AVP

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    If host credits exist for the host indicated in the dest=
ination-host AVP:

      Decrement host credit by one

    else:

      Apply host based throttling logic to that request=




Steve




On 2/10/14 10:59 AM, 
lionel.morand@orange.com wrote:






Hi Steve,


 <=
/p>

In your example, if an ag=
ent has a better knowledge than the server, the Host type OLR should not be=
 sent unmodified in forwarded answers, or even removed as
 irrelevant.


 <=
/p>

And in a normal case, the=
 reduction for the realm will be likely lower than the reduction needed for=
 a node. S1 is not overload, S2 is 50% overload, the realm
 (S1+S2) is overloaded 25%. So only the reduction for the Host should a=
pply, why the host-type should prevail over realm-type OLR.


 <=
/p>

By the way, in your propo=
sed logic, it is not clear if the relation between the first and the second=
 conditions is an "IF NOT".



 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Envoy=E9 : lundi 10 f=E9vrier 2014 15:39

=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN=
 - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I think we have agree=
ment that a realm report applies to all traffic targeted for that realm, in=
dependent of the presence or absence of the destination-host avp.  Is =
that correct?



I don't agree with Lionel's proposal.  The realm overload report shoul=
d take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was written "except&q=
uot; :)


 


The abatement for the Realm applies when NO explicit reduction is requ=
ested for a specific node of this realm. In such a case i.e. when an OLR is=
 received for a specific node inside a realm for which a reduction also app=
lies, *ONLY* the reduction requested for the node applied.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext lionel.morand@oran=
ge.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




I better like Lionel's approach, but even that is not ok in the unlike=
ly extreme case where we have two servers in a realm, S1 is not overloaded =
at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why=
 should a client do a 25% throttling when sending host type requests to the=
 not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?


<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is applied in any case


except if there is an explicit report for the destination-host"?<=
o:p>


 


If this means the realm abatement is still applied after applying=



the host abatement, then I agree it is not the same you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; dime@ietf.org<=
o:p>


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


I tend to agree except that I would reverse the logic as for the routi=
ng principles: the Destination-host takes precedence when present over Dest=
ination-Realm. So the realm abatement is applied in any case except if ther=
e is an explicit report for the destination-host.


 


Lioenl


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


It makes more sense to me for a realm report to apply to all requests =
targeted for that realm, independent the type of request.  This implie=
s that it would apply to requests that also have a Destination-Host specifi=
ed.


 


If this is the definition of a realm report then we need to specify th=
e interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm first and the host =
second.  If a message targetted for the host is throttled as a result =
of realm overload then that throttled message would count as part of the re=
duction needed to address the host overload.  Messages to the host tha=
t survive realm abatement would then be candidates for host overload.<=
/o:p>


 


Steve


 


On 2/4/14 11:12 AM, lionel=
.morand@orange.com wrote:


The case "Realm" as described below raises another question:=
 is it prohibited for a realm to only rely on a global overload report for =
the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm" would be recei=
ved by the reacting node. And the reduction indicated in the OLR will apply=
 always for the realm, whatever the presence of Destination-host AVP in the=
 request... except if an explicit report with the type "Host" as =
been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to which requests over=
load


treatment of a given report type applies.


Proposal:


 


   0  A host report.  The overload treatment shoul=
d apply to requests


      for which all of the following conditio=
ns are true:


      a) The Destination-Host AVP is present =
in the request and its value


         matches the value of =
the Origin-Host AVP of the received message


         that contained the OC=
-OLR AVP.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overload treatment shou=
ld apply to


      requests for which all of the following=
 conditions are true:


      a) The Destination-Host AVP is absent i=
n the request.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


______________________________________________________________________=
___________________________________________________


 


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.


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


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 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.




 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D6973Bxmbrcdx10ciscoc_--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:03:05 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5036E1A0929 for ; Tue, 11 Feb 2014 02:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O95-aOeFlW-q for ; Tue, 11 Feb 2014 02:02:59 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEDD1A092A for ; Tue, 11 Feb 2014 02:02:58 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-47-52f9f551b886
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.08.04249.155F9F25; Tue, 11 Feb 2014 11:02:57 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:02:56 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #47: reduction percentages greater than 100 should be ignored
Thread-Index: Ac8nEG6T5cysM6EUSQCr5zWfIBoZ5w==
Date: Tue, 11 Feb 2014 10:02:56 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772E11@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209772E11ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvjW7g159BBiufaFvM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPnPW9kLPm9jrNh5lbeBccUCxi5GTg4JAROJxrlb2SFsMYkL 99azgdhCAkcYJR5tTepi5AKylzBK3J5+hAUkwSZgJ3Hp9AumLkYODhEBZYnTvxxAwsICURIn G6cyg9giAtESLa/2MkHYehJrZpxjBbFZBFQlvm3tAKvhFfCVmPj/D9guRqC930+tAatnFhCX uPVkPhPEPQISS/acZ4awRSVePv7HCmErSSy6/RmqPl9iVssbJoiZghInZz5hmcAoNAvJqFlI ymYhKYOI60ncmDqFDcLWlli28DUzhK0rMePfIRZk8QWM7KsYOYpTi5Ny040MNjECA//glt8W Oxgv/7U5xCjNwaIkzvvxrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZ/+8OuxXUXfwkZ HJqSEdQtbHaj+eTtDY++6llelfA6f32a4C9ThUbNbquMOfWSJ1akJy6JmfYycINb4kPf/IeX Hlv1WC+dHDNf+setCXXT15vf+vWV733dvzO/uL56r70oOLe1IFZ2zsOrr93iD7MwFL/6eXJu RGpCi3emrPy0VxHsv49yZxsrsRRnJBpqMRcVJwIArdpsikoCAAA=
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:03:06 -0000

--_000_087A34937E64E74E848732CFF8354B9209772E11ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,

Once we have defined a default value for the Validity-Duration, I think it =
is important to do not discard overload report with an invalid value, but u=
se default one.
Take into account reception of a valid OLR by a client is important, and if=
 discarded we should assure that a new valid OLR is received.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 18:59
To: lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 shou=
ld be ignored

I agree that a clarification is needed on what it means to be "treated as i=
s the OC-Validity-Duration AVP was not present".  It would e better to say:

  "Invalid validity duration values are given the default value".



Steve


On 2/10/14 11:29 AM, lionel.morand@orange.com wrote:
Hi Steve,

About the OC-Validity-Reduction AVP values greater than 24 hours, it is sai=
d that the default value 5s applies.

I was therefore wondering if it should be also considered as an error and t=
herefore discarded. It is a real open question. Not an issue per se as I'm =
fine with the existing text. I was reacting on the reason for change explai=
ned by Ben.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 10 f=E9vrier 2014 17:59
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #47: reduction percentages greater than 100 shoul=
d be ignored

It is possible, the range defined is zero to 24 hours.  I think the text is=
 correct as it says that a value out of this range should be ignored.

Steve
On 2/10/14 10:50 AM, Ben Campbell wrote:



On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:



Hi Ben,



OK with this statement.

But if it is agreed, would it mean that the same consideration should apply=
 for the OC-Validity-Duration AVP values?





I'm not sure I follow the question. Is it possible to send an invalid OC-Va=
lidity-Duration value?



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker

Envoy=E9 : vendredi 7 f=E9vrier 2014 23:05

=C0 : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com

Cc : dime@ietf.org

Objet : [Dime] [dime] #47: reduction percentages greater than 100 should be=
 ignored



#47: reduction percentages greater than 100 should be ignored



Section 4.7 says " [Reduction-Percentage] Values greater than 100 are

interpreted as 100."



An OLR with an invalid value should be ignored. An invalid value indicates

incorrect behavior on the part of the sender. In this case, it's not safe

to assume we know what the sender really intended.



--

-------------------------+-------------------------------------------------

Reporter:               |      Owner:  draft-docdt-dime-

 ben@nostrum.com        |  ovli@tools.ietf.org

    Type:  defect       |     Status:  new

Priority:  minor        |  Milestone:

Component:  draft-       |    Version:  1.0

 docdt-dime-ovli        |   Keywords:

Severity:  Active WG    |

 Document               |

-------------------------+-------------------------------------------------



Ticket URL: 

dime 



_______________________________________________

DiME mailing list

DiME@ietf.org

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



___________________________________________________________________________=
______________________________________________



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.





_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________



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_087A34937E64E74E848732CFF8354B9209772E11ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello all,


 <=
/p>

Once we have defined a de=
fault value for the Validity-Duration, I think it is important to do not di=
scard overload report with an invalid value, but use default
 one.


Take into account recepti=
on of a valid OLR by a client is important, and if discarded we should assu=
re that a new valid OLR is received.



 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





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

Sent: lunes, 10 de febrero de 2014 18:59

To: lionel.morand@orange.com; dime@ietf.org

Subject: Re: [Dime] [dime] #47: reduction percentages greater than 1=
00 should be ignored






 


I agree that a clarif=
ication is needed on what it means to be "treated as is the OC-Validit=
y-Duration AVP was not present".  It would e better to say:<=
/o:p>




  "Invalid validity duration values are give=
n the default value".


 


Steve


 






On 2/10/14 11:29 AM, 
lionel.morand@orange.com wrote:






Hi Steve,


 <=
/p>

About the OC-Validity-Red=
uction AVP values greater than 24 hours, it is said that the default value =
5s applies.


 <=
/p>

I was therefore wondering=
 if it should be also considered as an error and therefore discarded. It is=
 a real open question. Not an issue per se as I'm fine with
 the existing text. I was reacting on the reason for change explained by Be=
n.


 <=
/p>

Regards,


 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 10 f=E9vrier 2014 17:59

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #47: reduction percentages greater th=
an 100 should be ignored






 


It is possible, the r=
ange defined is zero to 24 hours.  I think the text is correct as it s=
ays that a value out of this range should be ignored.



Steve




On 2/10/14 10:50 AM, Ben Campbell wrote:<=
/p>





 


On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


OK with this statement.


But if it is agreed, would it mean that the same consideration should =
apply for the OC-Validity-Duration AVP values?


 




 


I'm not sure I follow the question. Is it possible to send an invalid =
OC-Validity-Duration value?


 




Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de dime issue tracker


Envoy=E9 : vendredi 7 f=E9vrier 2014 23:05


=C0 : draft-do=
cdt-dime-ovli@tools.ietf.org; ben@no=
strum.com


Cc : dime@ietf.org

Objet : [Dime] [dime] #47: reduction percentages greater than 100 shou=
ld be ignored


 


#47: reduction percentages greater than 100 should be ignored


 


Section 4.7 says " [Reduction-Percentage] Values greater than 100=
 are


interpreted as 100."


 


An OLR with an invalid value should be ignored. An invalid value indic=
ates


incorrect behavior on the part of the sender. In this case, it's not s=
afe


to assume we know what the sender really intended.


 


-- 


-------------------------+----------------------------------------=
---------


Reporter:          &=
nbsp;    |      Owner:  draft-=
docdt-dime-


 ben@nostrum.com  &nb=
sp;     |  =
ovli@tools.ietf.org


    Type:  defect     &nb=
sp; |     Status:  new


Priority:  minor        | =
; Milestone:


Component:  draft-       | &nb=
sp;  Version:  1.0


 docdt-dime-ovli        | &nbs=
p; Keywords:


Severity:  Active WG    |


 Document          &=
nbsp;    |


-------------------------+----------------------------------------=
---------


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/47>


dime <http://tools.ietf.=
org/wg/dime/>


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 


______________________________________________________________________=
___________________________________________________


 


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.




 






--_000_087A34937E64E74E848732CFF8354B9209772E11ESESSMB101erics_--


From lionel.morand@orange.com  Tue Feb 11 02:07:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2BC1A092C for ; Tue, 11 Feb 2014 02:07:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANvMviIjfqzQ for ; Tue, 11 Feb 2014 02:06:52 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7A51A092F for ; Tue, 11 Feb 2014 02:06:51 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 38D9622C65A; Tue, 11 Feb 2014 11:06:50 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 19F022380DD; Tue, 11 Feb 2014 11:06:50 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 11:06:48 +0100
From: 
To: Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPJr46nxbg/VMhP0+Nj88X4tUoB5qvz1dQ
Date: Tue, 11 Feb 2014 10:06:47 +0000
Message-ID: <28236_1392113210_52F9F63A_28236_134_5_6B7134B31289DC4FAF731D844122B36E4999E8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com>
In-Reply-To: <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:07:01 -0000

On 1), the reacting node will know that the server is DOIC-enabled when rec=
eiving the Supported-Features AVP, whatever the content of this AVP. When n=
o OLR is sent, I think that there is nothing preventing a reporting node to=
 announce all

On 2), honestly, I don't see the need for trying to keep a single AVP for a=
ll the possible abatements, especially if we are saying that the overload c=
ontrol is defined per application.
I think that there is value to try to reuse the same algo across applicatio=
n but not so try to reuse the same AVP across algos.

I do not foresee 1000 different algos defined for Diameter systems. And if =
it is, defining one OC-OLR AVP per algo is not an issue. We are not running=
 out of AVP codes. The AVP code itself is sufficient to indicate the algo t=
o use i.e. "this is an overload report for algo x". And each application wi=
ll explain anyhow how to use this overload report.

The main conclusions would be to be able to:
- Get rid of the OC-Supported-Features AVP in answer containing an OC-OLR A=
VP.
- get rid of the sequence number in the OC-Supported-Feature AVP in all the=
 requests and in the answer when the OC-Supported-features AVP is including=
 for capabilities discovery.

Regards,

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoy=E9=A0: mardi 11 f=E9vrier 2014 01:14
=C0=A0: Steve Donovan
Cc=A0: dime@ietf.org list
Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es

I don't quite agree with where I think this thread is going, on two points:

1) I want the reacting node to be able to learn if a (potentially) reportin=
g node supports DOIC, even when that node is not in overload. I don't want =
to specify any particular behavior for that knowledge, but I suspect implem=
entations may want to treat DOIC compliant servers in some way differently =
than they do non-DOIC servers. For example, I might have a configured rate =
limit for non-DOIC peers, but use a higher (or no) limit for peers that are=
 known to support DOIC (and can thus speak for themselves.)

2) It's clumsy to have to look at an external (to OC-OLR) AVP to find out t=
he algorithm. I think the actual algorithm for a particular report should b=
e indicated in OC-OLR, not OC-Supported-Features at the root of the message.


Now, separate from those points, I think we should consider whether it's ok=
ay for a reporting nodes to switch algorithms mid-stream, vs pick an algori=
thm and stick with it. Right now, I think we effectively allow a reporting =
node to send an OLR for one algorithm in one answer, then another algorithm=
 in the next, even for the same reacting node. If so, we need to define wha=
t it means when that happens.

For example, if I receive an OLR with the "loss" algorithm, and another wit=
h the "rate" algorithm from the same server, does the second replace the fi=
rst? Do I now have two overload state entries that I need to "stack"?

Thanks!

Ben.

On Feb 10, 2014, at 9:07 AM, Steve Donovan  wrote:

> I'll attempt to summarize where we are on this.  If this is agreed to the=
n the necessary changes would be made to the -01 draft.  Some of this is al=
ready in the draft, some of it will require changes.
>=20
> - The draft already makes it optional for the reporting node to include t=
he OC-Supported-Features AVP in answer messages - No change required here.
>=20
> - A reporting node must choose the overload abatement algorithm to be sen=
t to a reacting node from the set of abatement algorithms included in the O=
C-Supported-Features AVP received in the request message.
>=20
> - If the reporting node sends an OC-OLR AVP and there is no OC-Supported-=
Features AVP then the abatement algorithm used by the reacting node must be=
 loss.
>=20
> - The reporting node may include the OC-Supported-Features AVP with the l=
oss algorithm indicated in the OC-Feature-Vector AVP.
>=20
> - If the reporting node wants the reacting node to apply an algorithm oth=
er then loss, the reacting node must include the OC-Supported-Features AVP =
with a single algorithm indicated in the OC-Feature-Vector AVP.=20
>=20
> - New abatement algorithm extensions may use and extend the existing OC-O=
LR AVP.  The new algorithms may also create a new overload report AVP if th=
at makes the most sense.
>=20
> - The loss algorithm is and always will be the mandatory to implement alg=
orithm.  Or it will be until a new RFC is published that changes the mandat=
ory to implement algorithm.
>=20
> Steve=20
>=20
> On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:
>>=20
>> -----Message d'origine-----
>> De : Jouni Korhonen [
>> mailto:jouni.nospam@gmail.com
>> ]=20
>> Envoy=E9 : lundi 10 f=E9vrier 2014 12:24
>> =C0 : MORAND Lionel IMT/OLN
>> Cc :=20
>> dime@ietf.org
>>=20
>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messa=
ges
>>=20
>>=20
>> On Feb 10, 2014, at 1:15 PM,=20
>> 
>>  wrote:
>>=20
>>=20
>>> Hi Jouni,
>>>=20
>>>=20
>>>> As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.
>>>>=20
>>> Bah. OLR should work for additional abatement algorithms
>>> IF we agree that the OLR is align with the announced
>>> abatement algorithm..=20
>>>=20
>>> [LM] The issue if when you have more than one algo (let say 2). There i=
s no way for the reporting node to indicate the algo to use with the OLR se=
nt in the answer using the OC-Feature-Vector. The only info that you could =
have is "use either one or the other".
>>>=20
>> This we can fix (and I personally would like to fix). The reporting node
>> announces in its OC-Feature-Vector the selected common algorithm for the
>> sent OLR. We had this at some point of time, btw.
>>=20
>> [LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector M=
AY be used (when present) to indicate the algo to use, algo part of the com=
mon algos between the reporting node and the reacting node.
>>=20
>>=20
>>> The simpliest way would be to define a new AVP when you want to support=
 more than the default algo. If you want to rely on the same OLR with anoth=
er algo, you should have a way to indicate the algo to use with the given O=
LR.
>>>=20
>> I recall there was a strong arguments against algorithm types in OLRs..
>>=20
>> [LM] I was not proposing such idea :)
>>=20
>> - Jouni
>>=20
>>=20
>>>=20
>>>> It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.
>>>>=20
>>> It is already today if you only support the default, right.
>>>=20
>>> [LM] Right. No issue here.
>>>=20
>>> -----Message d'origine-----
>>> De : Jouni Korhonen [
>>> mailto:jouni.nospam@gmail.com
>>> ]=20
>>> Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04
>>> =C0 : MORAND Lionel IMT/OLN
>>> Cc :=20
>>> dime@ietf.org
>>>=20
>>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer mess=
ages
>>>=20
>>>=20
>>> On Feb 4, 2014, at 5:01 PM,=20
>>> lionel.morand@orange.com
>>>  wrote:
>>>=20
>>>=20
>>>> I think that there is actually an issue here but the proposed way to s=
olve it is not the correct one.
>>>>=20
>>> Agree.
>>>=20
>>>=20
>>>> The initial idea was to be able to use the same overload report with s=
everal algorithms. So the OLR was somehow only meaningful along with the OC=
-Feature-Vector AVP.
>>>>=20
>>> The initial idea was to go on lines of RFC5447.
>>>=20
>>>=20
>>>> But because the OC-Feature-Vector AVP is defined as a set of flags, it=
 is not possible to say that this OLR is to be used with only one given alg=
o when more than one is defined (as the bit flags will advertize 1 AND 2 fo=
r 2 supported algos). So the OC-Feature-Vector cannot be used to indicate t=
he abatement to perform.
>>>>=20
>>> My intention was always allow:
>>>=20
>>>  client announces  ABC
>>>  server supports    BCD
>>>  server announced only  e.g. C since it is common
>>>  alternatively server announced nothing and then the default applies
>>>=20
>>>=20
>>>> As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.
>>>>=20
>>> Bah. OLR should work for additional abatement algorithms
>>> IF we agree that the OLR is align with the announced
>>> abatement algorithm..=20
>>>=20
>>>=20
>>>> It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.
>>>>=20
>>> It is already today if you only support the default, right.
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>> Lionel=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : dime issue tracker [
>>>> mailto:trac+dime@trac.tools.ietf.org
>>>> ]=20
>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : [dime] #30: OC-Supported-Features AVP in answer messages
>>>>=20
>>>> #30: OC-Supported-Features AVP in answer messages
>>>>=20
>>>> According to the current feature advertisement/negotiation mechanism in
>>>> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features =
AVP
>>>> in answer messages to indicate their supported OC features to the reac=
ting
>>>> DOIC endpoint.
>>>> The author of this document believes that  the best a reacting node ca=
n do
>>>> with such information is to ignore it, and therefore proposes to allow
>>>> reporting nodes not to insert OC-Supported-Features AVPs in answer
>>>> messages.
>>>> Currently only one feature is defined (OLR_DEFAULT_ALGO).
>>>> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no ot=
her
>>>> feature is only interested in receiving/not receiving OC-OLR AVPs from
>>>> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
>>>> support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not recei=
ving
>>>> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:
>>>>=20
>>>> a) There is no overload
>>>> b) DOIC is not supported
>>>>=20
>>>> The reacting DOIC endpoint does not need to differentiate between these
>>>> two cases as the behavior (do not throttle) is the same in both cases.
>>>> The -01 draft says in  clause 4.1:
>>>>   If there is no single matching
>>>>   capability the reacting node MUST act as if it does not implement
>>>>   DOIC and cease inserting any DOIC related AVPs into any Diameter
>>>>   messages with this specific reacting node.
>>>>=20
>>>> This however is inconsistent.
>>>> The reacting node that ceases sending DOIC related AVPs would never
>>>> recognize when the server is upgraded to support DOIC.
>>>> Subsequent requests (not including DOIC related AVPs) may take a diffe=
rent
>>>> path towards the server and on that path there may be an agent that
>>>> supports DOIC (with a match of supported features) and could take the =
role
>>>> of the reporting DOIC endpoint; but the agent cannot take this role si=
nce
>>>> the reacting node (although supporting DOIC) ceased sending of OC-
>>>> Supported-Features AVPs.
>>>> In summary: As long as no extension feature is defined within  draft-i=
etf-
>>>> dime-ovli  (i.e. never, since extensions will  be defined in other
>>>> drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
>>>> describe inclusion of OC-Supported-Features AVP in answer messages.
>>>>=20
>>>> --=20
>>>> --------------------------------------+--------------------------
>>>> Reporter:=20=20
>>>> lionel.morand@orange.com
>>>>   |      Owner:  Ulrich Wiehe
>>>>    Type:  defect                    |     Status:  new
>>>> Priority:  major                     |  Milestone:
>>>> Component:  draft-docdt-dime-ovli     |    Version:
>>>> Severity:  Active WG Document        |   Keywords:
>>>> --------------------------------------+--------------------------
>>>>=20
>>>> Ticket URL:=20
>>>> 
>>>>=20
>>>> dime=20
>>>> 
>>>>=20
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________________________________=
__________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations conf=
identielles 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 message=
s electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme=
 ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or privileged=
 information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>=20
>> ________________________________________________________________________=
_________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations confi=
dentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r=
ecu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages=
 electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>>=20
>> 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

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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From ulrich.wiehe@nsn.com  Tue Feb 11 02:13:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8681A06B4 for ; Tue, 11 Feb 2014 02:13:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_4U2Tn-My5f for ; Tue, 11 Feb 2014 02:13:38 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 204AC1A0724 for ; Tue, 11 Feb 2014 02:13:37 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1BAD81A016086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 11:13:08 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1BAD86F012651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 11:13:08 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 11:13:08 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 11:13:08 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP
Thread-Index: AQHPIyiVRE2I9DZb40+FeQWO0toHL5qoSuqAgAAqeQCAANvNAIAABVqAgAABgQCAAC0EgIAACU8AgAShATCAAaz7oA==
Date: Tue, 11 Feb 2014 10:13:07 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2A1F@DEMUMBX014.nsn-intra.net>
References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 14693
X-purgate-ID: 151667::1392113589-000025D0-0ED93526/0-0/0-0
Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:13:43 -0000

Let's use "validity duration" and "expiry time", and avoid "validity time"

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, February 10, 2014 9:59 AM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP

Hi all

I agree to enhance the wording so by starting  from the new Lionel's wordin=
g.

My comment is that we have  to clearly distinguish the "validity duration" =
given  by the OC-Validity-Duration AVP (eg 10 s) from the "validity time" (=
absolute value) at the end of which  the received OLR is no more applicable=
.
- If the reacting node receives a new sequence number at T1 and a validity =
duration of 10s, this will determine a validity time eg of T1+ 10s where th=
e received OLR is applicable.
- If later at T2, it receives another OLR with the Same sequence number,  t=
he validity time remains unchanged at  T1+10s (as stated in Lionel's propos=
al), this allows to ignore the OLRs with the same sequence number.
- If at T3, the reacting node receives another OLR with a new  sequence num=
ber and with the same value, 10 s, (or a new value, eg 15s)  for validity d=
uration,  the validity time becomes  T3+10s (or T3+15s). So we can have sit=
uations where the sequence number is changed but the other content of OC-OL=
R AVP (reduction%, validity duration) itself has not changed: the effect is=
 only to shift the validity time in the reacting node.
Do you share  all this understanding?=20

So in the description, to be careful between validity duration and validity=
 time that  may confuse.

Best regards

JJacques=20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: vendredi 7 f=E9vrier 2014 11:53
=C0=A0: lionel.morand@orange.com
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #36: OC-Validity-Duration AVP


OK by me.

- JOuni

On Feb 7, 2014, at 12:19 PM,  wrote:

> Hi Maria Cruz,
>=20
> I'm fine with the proposed clarification.
> My point is that some parts belong to the handling of the OLR itself and =
some other to the definition of the Validity duration.
>=20
> Here is a proposal for clarification. Let me know if it covers your conce=
rn.
>=20
> Regards,
>=20
> Lionel
>=20
> *******************
>=20
> 4.3. OC-OLR AVP
>=20
> [skip]
>=20
>   The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.
>   It is possible to replay the same OC-OLR AVP multiple times between
>   the overload control endpoints, however, when the OC-OLR AVP content
>   changes or sending endpoint otherwise wants the receiving endpoint to
>   update its overload control information, then the OC-Sequence-Number
>   AVP MUST contain a new greater value than the previously received.
>   The receiver SHOULD discard an OC-OLR AVP with a sequence number that
>   is less than previously received one.
>=20
> [New]
>=20
>   The OC-Validity-Duration AVP indicates the validity time of the overloa=
d
>   report associated with a specific sequence number, measured after recep=
tion
>   of the OC-OLR AVP. The validity time MUST NOT be updated after receptio=
n=20
>   of subsequent OC-OLR AVPs with the same sequence number. The default va=
lue
>   for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds).  When th=
e=20
>   OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default =
value
>   applies.
>=20
> [Skip]
>=20
> 4.5. OC-Validity-Duration AVP
>=20
> OLD:
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and describes the number of seconds the "new and fresh" OC-OLR AVP
>   and its content is valid since the reception of the new OC-OLR AVP.
>   The default value for the OC-Validity-Duration AVP value is 5 (i.e.,
>   5 seconds).  When the OC-Validity-Duration AVP is not present in the
>   OC-OLR AVP, the default value applies.  Validity duration values 0
>   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
>   Invalid validity duration values are treated as if the OC-Validity-
>   Duration AVP were not present.
>=20
>=20
> NEW:
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and indicates in seconds the validity time of the overload report.
>   The number of seconds is measured after reception of the first=20
>   OC-OLR AVP with a given value of OC-Sequence-Number AVP.=20
>   The default value for the OC-Validity-Duration AVP is 5 (i.e.,
>   5 seconds).  When the OC-Validity-Duration AVP is not present in the
>   OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values =
0
>   (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used.
>   When invalid values are used, the default value for the OC-Validity-Dur=
ation
>   AVP applies.
>=20
>=20
>=20
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20
> Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 08:38 =C0 : dime@ietf.org=
=20
> Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP
>=20
> Hello Lionel, all,
>=20
> I would like to clarify what  "new and fresh", or even only "new" OC-OLR =
AVP mean in the text.
> It should be understood that it does not refer to the new (latest) receiv=
ed AVP, but just the one that contains (potentially) new values, what only =
happens for a new Sequence Number. In that line is the proposed text I prov=
ided.
>=20
> Best regards
> /MCruz
>=20
> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: viernes, 07 de febrero de 2014 8:33
> To: dime@ietf.org; Maria Cruz Bartolome
> Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP
>=20
> Hi,
>=20
> My point is just to say that we should make the difference between the de=
finition and the use of the AVP.
>=20
> And about the clarification, I would say that it is rather about how to p=
opulate the OC-OLR AVP or when a new sequence number should be used.
>=20
> Regards,
>=20
> Lionel
>=20
> Envoy=E9 depuis mon Sony Xperia SP d'Orange
>=20
> Maria Cruz Bartolome  a =E9crit :
>=20
>=20
> Thanks Lionel,
> The comment equally applies in order to clarify when the Validity-Duratio=
n should include a new value.
>=20
> Now:
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and describes the number of seconds the "new and fresh" OC-OLR AVP
>   and its content is valid since the reception of the new OC-OLR AVP.
>=20
> Proposal:
>    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>    and describes the number of seconds the OC-OLR AVP and its content is
>    valid in relation to the reception of the first OC-OLR AVP with a
>    specific sequence number. For a given sequence number, the
>    OC-Validity-Duration shall always carry the same value.
>=20
>=20
> Best regards
> /MCruz
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20
> lionel.morand@orange.com
> Sent: jueves, 06 de febrero de 2014 19:07
> To: Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP
>=20
> Hi Maria Cruz,
>=20
> Hi Maria Cruz, Steve,
>=20
> Be careful! The reference you are using seems to be odd.
>=20
> The current text in the draft says:
>=20
> 4.5. OC-Validity-Duration AVP
>=20
>=20
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and describes the number of seconds the "new and fresh" OC-OLR AVP
>   and its content is valid since the reception of the new OC-OLR AVP.
>   The default value for the OC-Validity-Duration AVP value is 5 (i.e.,
>   5 seconds).  When the OC-Validity-Duration AVP is not present in the
>   OC-OLR AVP, the default value applies.  Validity duration values 0
>   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
>   Invalid validity duration values are treated as if the OC-Validity-
>   Duration AVP were not present.
>=20
>   A timeout of the overload report has specific concerns that need to
>   be taken into account by the endpoint acting on the earlier received
>   overload report(s).  Section 4.7 discusses the impacts of timeout in
>   the scope of the traffic abatement algorithms.
>=20
>   As a general guidance for implementations it is RECOMMENDED never to
>   let any overload report to timeout.  Following to this rule, an
>   overload endpoint should explicitly signal the end of overload
>   condition and not rely on the expiration of the validity time of the
>   overload report in the reacting node.  This leaves no need for the
>   reacting node to reason or guess the overload condition of the
>   reporting node.
>=20
> I think that the definition of the OC-Validity-Duration AVP should remain=
 independent of the notion of Sequence-Number.
> The sequence number does not change the value of the OC-Validity-Duration=
 AVP. It indicates that the OLR has to be updated or not. And if it is, a n=
ew duration will be there (either implicit or explicit with the OC-Validity=
-Duration AVP).
>=20
> So if something needs to be clarified (I haven't checked), it should be i=
n the handling of the OLR.
>=20
> Regards,
>=20
> Lionel
>=20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
> Envoy=E9 : jeudi 6 f=E9vrier 2014 16:35 =C0 : dime@ietf.org Objet : Re:=20
> [Dime] [dime] #36: OC-Validity-Duration AVP
>=20
> This change looks pretty straight forward to me.  I'll add it to the -02 =
version of the draft unless I hear objections soon.
>=20
> Steve
> On 2/6/14 4:44 AM, dime issue tracker wrote:
> #36: OC-Validity-Duration AVP
>=20
> In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when=
  the OC-Validity-Duration AVP needs to be updated is ambiguous.
>=20
> Now:
>    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>    and describes the number of seconds the OC-OLR AVP and its content is
>    valid since the reception of the new OC-OLR AVP (as indicated by the
>    OC-Sequence-Number AVP).
>=20
> Proposal:
>    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>    and describes the number of seconds the OC-OLR AVP and its content is
>    valid in relation to the reception of the first OC-OLR AVP with a
>    specific sequence number. For a given sequence number, the
>    OC-Validity-Duration shall always carry the same value.
>=20
>=20
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles d'alteration, Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci=
.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> 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
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles d'alteration, Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci=
.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> 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 nsalot@cisco.com  Tue Feb 11 02:20:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7063B1A092A for ; Tue, 11 Feb 2014 02:20:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lgUTJ998Nzn for ; Tue, 11 Feb 2014 02:20:37 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 57E1A1A093C for ; Tue, 11 Feb 2014 02:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=106396; q=dns/txt; s=iport; t=1392114031; x=1393323631; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nXdMLurqWxhuxs94urq63rvvMeo/uEZ116NLvldVgHI=; b=Sg/5E32NqbvIh1s6+Lv3q/N1X9v7IpsHxocjs41zb++53LWP2x0rTB66 /ELQvRvlf/5E0vX8wBYUNDm7pLh1Dn4R8/VwrlAps9anCNCyfMhE/+7ET aOhJVebHZVJipm88FKZ/qYZPIeFbbFPsrnE7TYzvpq8omFw2aKV/dreie k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFAB/5+VKtJV2a/2dsb2JhbABZgkhEOFeDAbtkGHUWdIIlAQEBBAEBAQsMAQgKOAkXBAIBCBEEAQELCwsBAgQDAgICJQsUCQgCBAESCBOHag2oL6AhEwSOFxEBHxYXCgEGBIJlNYEUBJRBjkWHRIFvgT6BaAcCFyI
X-IronPort-AV: E=Sophos;i="4.95,825,1384300800";  d="scan'208,217";a="303224202"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 11 Feb 2014 10:20:29 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1BAKTX0007307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:20:29 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 04:20:29 -0600
From: "Nirav Salot (nsalot)" 
To: "lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg
Date: Tue, 11 Feb 2014 10:20:29 +0000
Message-ID: 
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.140.48]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6978Axmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:20:45 -0000

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

SSBhbSBhbHNvIGZpbmUgd2l0aCBTdGV2ZSdzIHByb3Bvc2VkIHdvcmRpbmcgdG8gcmVjb21tZW5k
IHRoZSBpbmNsdXNpb24gb2YgT0xSIGJ1dCB0byBub3QgbWFuZGF0ZSBpdC4NCg0KSSBhbSBub3Qg
c3VyZSBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNz
YXJ5IHRvIGFkZCBpdC4NCk5vdGUgLSB0aGUgb25seSBzdXJlIHdheSwgd2l0aG91dCBwcm9wcmll
dGFyeSBtZWNoYW5pc21zLCB0byBrbm93IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZl
ZCBhbiBvdmVybG9hZCByZXBvcnQgaXMgd2hlbiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIGNsaWVu
dCBhbmQgdGhlcmUgaXMgbm8gYWdlbnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0
aW5nIG5vZGUuDQoNCkkgcHJlZmVyIHRvIHJlbW92ZSBpdCBzaW5jZSBJIGRvIG5vdCBzZWUgYXMg
dmFsdWUgYWRkaXRpb24uDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAxMDoxMyBQTQ0KVG86IFN0ZXZl
IERvbm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJJ20gZmluZSB3aXRoIGEgcmVjb21tZW5k
YXRpb24uDQoNCkJ1dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1lbnQ6IHdoZW4gYSBNQVkgb3IgZXZl
biBhIFNIT1VMRCBhcHBseSwgaXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIE5PVCB1cCB0byB0
aGUgbm9kZSB0byBkbyBvciBub3QgdG8gZG8gc29tZXRoaW5nLiBJdCBkb2VzIG5vdCBtZWFuIHRo
YXQgaXQgaXMgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRpb24uDQpGb3IgaW5zdGFuY2UsIG92
ZXIgYSBnaXZlbiBpbnRlcmZhY2UsIHRoZSByZWxhdGVkIHNwZWNpZmljYXRpb24gY2FuIHNheSB0
aGF0IHNvbWUgc3RhdGVzIGFyZSBtYWludGFpbmVkIGJ5IHRoZSBzZXJ2ZXIuIEFuZCBpdCBjb3Vs
ZCBiZSBkZWNpZGVkIHRvIGFkZCBzb21lIG92ZXJsb2FkIHJlbGF0ZWQgaW5mbyBpbiBzdWNoIHN0
YXRlcy4gRm9yIGluc3RhbmNlIGFnYWluLCB0aGUgbm9kZSBjYW4gdXNlIHRoaXMgc3RhdGUgdG8g
a25vdyBpZiBhIHJlbW90ZSBub2RlIGhhdmUgYmVlbiBub3RpZmllZCBvciBub3QgZm9yIGluc3Rh
bmNlLiBBbmQgaW4gc3VjaCBhIGNhc2UsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBpbmNs
dWRlIGFuIE9MUiBpbiBlYWNoIG1lc3NhZ2UuIEl0IGlzIGp1c3QgZm9yIGlsbHVzdHJhdGlvbi4g
VGhlIHBvaW50IGlzIHRoYXQgeW91IG1heSBoYXZlIHNvbWUgY2FzZXMgZm9yIHdoaWNoIHRoZSBP
TFIgaW4gZXZlcnkgYW5zd2VyIG1pZ2h0IG5vdCBiZSByZXF1aXJlZC4NCg0KSSBhZ3JlZSB0aGF0
IGhhdmluZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l4oCmIGJ1dCBpdCBzaG91bGQg
YmUgbm90IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4gU28gT0sgZm9yIGEgIlNIT1VM
RCIgb3IgIlJFQ09NTUVOREVEIi4NCg0KUmVnYXJkcywNCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBb
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2ZSBEb25vdmFu
DQpFbnZvecOpIDogbHVuZGkgMTAgZsOpdnJpZXIgMjAxNCAxNzoyMQ0Kw4AgOiBkaW1lQGlldGYu
b3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBhZ3JlZSB3aXRoIGJvdGggTWFyaWEg
Q3J1eiBhbmQgTmlyYXYuIDotKQ0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBoYXZlIHdvcmRpbmcgc2F5
aW5nIHRoZSByZWNvbW1lbmRlZCBhcHByb2FjaCBpcyB0byBpbmNsdWRlIHRoZSBvdmVybG9hZCBy
ZXBvcnQgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQgYnkg
TWFyaWEgQ3J1ei4NCg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBpbmNsdWRlIE5pcmF2J3MgcHJv
cG9zYWwgdGhhdCBpZiBhIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgYSByZWFjdGluZyBub2Rl
IGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IG1heSBjaG9v
c2UgdG8gbm90IHNlbmQgaXQgYWdhaW4uICBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gaW5jbHVk
aW5nIGFueXRoaW5nIGFib3V0IGhvdyB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgYnV0IHdlIHNo
b3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0dXJlcyB0aGF0IG1h
a2UgaXQgZGlmZmljdWx0IHRvIGtub3cuICBUaGUgY2FzZSBvZiBhZ2VudHMgYWN0aW5nIGFzIHJl
YWN0aW5nIG5vZGVzIGZvciBub24gc3VwcG9ydGluZyBjbGllbnRzIGJlaW5nIG9uZSBleGFtcGxl
Lg0KDQpXZSBhbHNvIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlY29tbWVuZGVkIGFwcHJv
YWNoIGlzIG5vdCBwcmVjbHVkZWQgYnkgTmlyYXYncyBwcm9wb3NhbC4NCg0KSSBwcm9wb3NlIHRo
ZSBmb2xsb3dpbmcgbm9ybWF0aXZlIHdvcmRpbmcsIHdoaWNoIGNhbiBiZSBzdXBwbGVtZW50ZWQg
YnkgTWFyaWEgQ3J1eidzIHJlYXNvbnMgZm9yIHJlY29tbWVuZGluZyB0aGF0IHRoZSBvdmVybG9h
ZCByZXBvcnQgaXMgYWx3YXlzIGluY2x1ZGVkLg0KDQotLS0tLQ0KDQpBIHJlcG9ydGluZyBub2Rl
IE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2Fk
IHJlcG9ydHMuDQoNCkl0IGlzIHJlY29tbWVuZGVkIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNs
dWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIHJlYWN0
aW5nIG5vZGVzLg0KDQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUg
dGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rp
bmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4gIFRoZSBvdmVybG9hZCByZXBvcnQg
d2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qgc3Vw
cG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4g
b3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRo
YXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJl
cG9ydC4NCg0KTm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1l
Y2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92
ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0
aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcgbm9k
ZS4NCk9uIDIvMTAvMTQgMzo1MiBBTSwgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgd3JvdGU6DQoNCkhl
bGxvIE5pcmF2LA0KDQoNCg0KQW55IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBm
YWN0b3JzLCBlZmZpY2llbmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJz
cGVjdGl2ZXMsIGJ1dCBmaXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFy
ZSBkZWZpbmluZyBpcyBwcm92aWRpbmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLg0KDQoN
Cg0KWW91ciBwcm9wb3NlZCB0ZXh0DQoNCiIgQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywg
ZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2Fk
IHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVw
b3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSBy
ZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINCg0KDQoNCklmIHRo
ZSByZXBvcnRpbmcgaXMgbm90IGF3YXJlIGFib3V0IHdoZXRoZXIgb3Igbm90IG92ZXJsb2FkIHJl
cG9ydCBpcyBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgYW5kIGl0IGRlY2lkZXMgKHNp
bmNlIGl0IGlzIGEgIm1heSIpIHRvIGRvIG5vdCBzZW5kIHRoZSBPTFIgYWdhaW4sIHRoZW4gb3Zl
cmxvYWQgbWl0aWdhdGlvbiBtZWNoYW5pc20gd2lsbCBub3Qgd29yayBpbiBjYXNlIE9MUiB3YXMg
bm90IHByb3Blcmx5IHJlY2VpdmVkIGJ5IGNvcnJlc3BvbmRpbmcgcG90ZW50aWFsIHJlYWN0aW5n
IG5vZGVzLiBBbmQgd2UgbmVlZCB0byBub3RlIHRoYXQgInJlYWN0aW5nIG5vZGVzIiBjb3VsZCBi
ZSBub3Qgb25seSB0aGUgY2xpZW50LCBidXQgQU5ZIGFnZW50IHVzZWQgZm9yIHJvdXRpbmcgKG5v
dCBvbmx5IHdoZW4gdGhlIGFnZW50IGlzIHByb3ZpZGluZyBzZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1
dCB3aGVuIGl0IGlzIHJlYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVu
dCkuDQoNClRoZW4sIG9uIG9uZSBoYW5kIGl0IGlzIG5vdCBzaW1wbGUgdG8ga25vdyB3aGVuIHJl
YWN0aW5nIG5vZGVzIGhhdmUgdmFsaWQgT0xSIGluZm8gKGFzIGV4cGxhaW5lZCBiZWxvdyksIGJ1
dCBpZiBPTFIgaXMgbm90IHNlbnQgYWdhaW4gKGFzIHBlciB5b3VyIHByb3Bvc2VkICJtYXkiKSB0
aGVuIG9uZSBvciBtdWx0aXBsZSByZWFjdGluZyBub2RlcyBkbyBub3QgaGF2ZSB0aGUgcmVxdWly
ZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gd2lsbCBub3Qgd29yay4NCg0KDQoNClRo
ZXJlZm9yZSwgaW4gbXkgb3BpbmlvbiwgdGhlIHNpbXBsZXN0IHdheSB0byBwcm92aWRlIHJlcXVp
cmVkIGluZm9ybWF0aW9uIGlzIHRvIHByb3ZpZGUgT0xSIGluIEFMTCBhbnN3ZXJzLg0KDQoNCg0K
QmVzdCByZWdhcmRzDQoNCi9NQ3J1eg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0K
DQpTZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyDQoNClRvOiBNYXJpYSBD
cnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3Vi
amVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQoNCg0KDQpCdXQgTWFyaWEtQ3J1eiwNCg0KDQoNCkhvdyBjYW4gd2Ugc2F5IHRoYXQgImluY2x1
ZGluZyB0aGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZm
aWNpZW50PyINCg0KSXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1dCBub3QgZWZmaWNpZW50Lg0KDQoN
Cg0KQSBzbGlnaHRseSBkaWZmZXJlbnQgd29yZGluZyBmcm9tIHdoYXQgSSBwcm9wb3NlZCBlYXJs
aWVyIGlzLCBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBoYXMgYSBuZXcgb3ZlcmxvYWQgcmVwb3J0
IHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gYSByZWFjdGluZyBub2RlIChieSB1cGRhdGlu
ZyB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgb3IgYnkgcHJvdmlkaW5nIHRo
ZSBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hhbGwgaW5jbHVkZSBP
TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBB
ZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2Rl
IGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQg
dG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUg
T0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KDQpTZW50OiBNb25kYXks
IEZlYnJ1YXJ5IDEwLCAyMDE0IDM6MDMgUE0NCg0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRp
bWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsIGFsbCwNCg0KDQoNCkkgdGhpbmsgd2Ug
c2hvdWxkIGRlZmluZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0IHNvbHV0aW9uLCBhcyBlZmZpY2ll
bnQgYW5kIHNpbXBsZSBhcyBwb3NzaWJsZS4NCg0KSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwg
YXMgYSBwdXJlICJtYXkiLCBidXQgbGVhdmluZyBpdCB1cCB0byBpbXBsZW1lbnRhdGlvbiBkb2Vz
IG5vdCBhc3N1cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQgT0xSIGluZm9ybWF0aW9uLCB3aGF0
IGlzIGJhc2ljIGZvciB0aGlzIG1lY2hhbmlzbSB0byB3b3JrLg0KDQoNCg0KQmVzdCByZWdhcmRz
DQoNCi9NQ3J1eg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogTmly
YXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KDQpTZW50OiBsdW5l
cywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyDQoNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9t
ZTsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpNYXJp
YS1DcnV6LA0KDQoNCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSBvbiAic2VuZGluZyBPTFIgaW4g
QUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMiLg0KDQpBbmQgd2UgYXJl
IG5vdCB0cnlpbmcgdG8gcHJldmVudCBpdCAtIGF0IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9u
Lg0KDQpCdXQgdGhlIG1haW4gcXVlc3Rpb24gaXMsIGFyZSB3ZSB0cnlpbmcgdG8gcHJldmVudCBh
bnkgb3RoZXIgcG9zc2libGUgaW1wbGVtZW50YXRpb24sIHdoaWNoIG1heSBiZSBzbWFydGVyIGFu
ZCBjYW4gYXZvaWQgaW5jbHVkaW5nIHJlZHVuZGFudCBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVz
c2FnZT8NCg0KDQoNCk1vc3QgcHJvYmFibHksIHRoZSB2ZXJ5IGZpcnN0IGltcGxlbWVudGF0aW9u
IG9mIG92ZXJsb2FkIGNvbnRyb2wgd2lsbCBpbmNsdWRlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBt
ZXNzYWdlcy4NCg0KQnV0IGF0IHRoZSBzYW1lIHRpbWUsIEkgZG8gbm90IHdhbnQgdG8gcmVzdHJp
Y3QgdGhlIGRldmVsb3BlcnMgd2hpY2ggY2FuIGNvbWUgdXAgd2l0aCBzb21lIG5pY2UgdHdlYWtz
IGFuZCB0cmlja3MgdG8gYXZvaWQgc2VuZGluZyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBldmVy
eSBtZXNzYWdlLiBBbmQgdGhpcyBpcyB3aGVyZSB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYW5kIGF2
b2lkIHB1dHRpbmcgc3VjaCByZXN0cmljdGlvbnMgaW4gcHJvdG9jb2wgZGVmaW5pdGlvbi4NCg0K
V2hhdCBkbyB5b3UgdGhpbms/DQoNCg0KDQpUaGlzIGFsc28gdGhlIHJlYXNvbiBJIHdhcyBzdWdn
ZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVkZSBPTFIgKGZyb20gdGhl
IHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYu
DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUN
Cg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAwNywgMjAxNCA4OjU3IFBNDQoNClRvOiBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkhlbGxvIFVscmljaCwg
TmlyYXYsDQoNCg0KDQpJIGFncmVlIHdpdGggVWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQg
YnkgTmlyYXYgaXMganVzdCBhIE1BWSwgYW5kIHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2Vu
ZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNoYWxsIG5vdCBiZSBqdXN0IGEgTUFZLg0KDQoNCg0K
T24gdGhlIG90aGVyIGhhbmQsIGNyaXRlcmlhIHByb3ZpZGVkIGJ5IFVscmljaCBvbiB3aGVuIE9M
UiBoYXMgdG8gYmUgc2VudCByZXF1aXJlcyB0aGUgc2VydmVyIGhhcyBzb21lIGtub3dsZWRnZToN
Cg0KYSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFz
IGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQoNCmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBu
b3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dz
IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhw
aXJlDQoNCmMpIG90aGVyd2lzZQ0KDQoNCg0KUmVwb3J0aW5nIG5vZGUgbXVzdCBoYXZlIHNvbWUg
a25vd2xlZGdlIGFib3V0IE9MUiByZWNlcHRpb24vc3RhdHVzIGluIHJlYWN0aW5nIG5vZGUuIEhv
dyBkb2VzIHNlcnZlciBhY3F1aXJlIHRoaXMga25vd2xlZGdlPw0KDQpUYWtlIGludG8gYWNjb3Vu
dCBhcyB3ZWxsIHRoYXQgYSAicmVhY3RpbmciIG5vZGUgbWF5IGJlIGJvdGggYW4gQWdlbnQgKGlu
IGNhc2UgaXQgcHJvdmlkZXMgc2VydmljZSB0byBhIHJlYWxtIG9yIGFjdGluZyBvbiBiZWhhbGYg
b2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpICBhbmQgYSBDbGllbnQuIEluIHRoZSBjYXNlIG9m
IEFnZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBrbm93IGlmIHRoaXMgaXMg
Z29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRyYW5zcGFyZW50bHksIGlu
IGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFueSBrbm93bGVkZ2UgYWJv
dXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBDbGllbnQuDQoNCg0KDQpU
aGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0aGluayB0aGF0IHNlbmRpbmcgT0xSIGluIEFMTCBhbnN3
ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzOg0KDQotIHN0YXRlLWxlc3MgaW1wbGVt
ZW50YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNlc3Npb24pIGlzIHNpbXBsZXIsDQoNCi0gdGhlIHNl
cnZlciBkb2VzIG5vdCBuZWVkIHRvIGRldGVybWluZSB3aGV0aGVyIG9yIG5vdCB0byBzZW5kIGFu
IE9MIHRvIGEgcmVhY3Rpbmcgbm9kZQ0KDQotIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBi
b3RoZXIgd2hldGhlciBhbiByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9M
UiBvciB3aGV0aGVyIHRoaXMgT0xSIGlzIHN0aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLg0K
DQotIHNlbmRpbmcgYW4gYWRkaXRpb25hbCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5n
LCBpbiBjb21wYXJpc29uIHdpdGggcmVxdWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5v
dCBzZW50KS4NCg0KICBJbiBmYWN0LCBpbiBhbiBvdmVybG9hZCBzaXR1YXRpb24sIHRoZSBlYXNp
ZXN0IGFuZCBsZWFzdCBjb21wbGV4IGlzIHRvIHNlbmQgaW5mb3JtYXRpb24gb3V0IHRvIGFsbCBh
ZmZlY3RlZC9hcHBsaWNhYmxlIG5vZGVzLA0KDQogIGFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtl
IGNhcmUgdG8gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb25zDQoNCi0gbW9yZSByb2J1c3Qgc29sdXRp
b24sIGFzIG5vIG5lZWQgdG8gY2F0ZXIgZm9yIGFsbCB0aGUgY2hlY2tzIG9uIHRoZSBuZWVkIHRv
IHNlbmQgaW5mb3JtYXRpb24sICBmb3Igc2l0dWF0aW9ucyB3aGVyZSBhbiBhbnN3ZXIgbWVzc2Fn
ZSBpcyBsb3N0LCAg4oCmDQoNCg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCi9NQ3J1eg0KDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmlj
aCkNCg0KU2VudDogdmllcm5lcywgMDcgZGUgZmVicmVybyBkZSAyMDE0IDEwOjU5DQoNClRvOiBl
eHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk5pcmF2LA0KDQoNCg0K
SSdtIGFmcmFpZCB5b3VyIHByb3Bvc2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGUgaW50ZW50
aW9uLg0KDQoNCg0KIndoZW4gaXQgd2FudHMgdG8gcHJvdmlkZS91cGRhdGUuLi4uaXQgc2hhbGwg
aW5jbHVkZS4uLiIgdHJhbnNsYXRlcyB0byAiLi4uaXQgbWF5IGluY2x1ZGUuLi4iLg0KDQoNCg0K
ImluIG90aGVyIGNhc2VzIiBpbiB0aGUgZ2l2ZW4gY29udGV4dCB0cmFuc2xhdGVzIHRvICJ3aGVu
IGl0IGRvZXMgbm90IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUuLi4iDQoNCg0KDQoNCg0KV2UgaGF2
ZSB0aGUgZm9sbG93aW5nIGNhc2VzOg0KDQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhh
dCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCg0KYikg
dGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQg
YSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFu
IE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoNCg0KDQppbiBjYXNl
IGEpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCByZXBsYXkgdGhlIE9MUiBpbiBj
YXNlIGIpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCB1cGRkYXRlIHRoZSByZWFj
dGluZyBub2RlIHdpdGggdGhlIGxhdGVzdCBPTFIgaW4gY2FzZSBjKSB0aGUgcmVwb3J0aW5nIG5v
ZGUgTVVTVCBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9ydGluZyBub2Rl
IGRvZXMgbm90IGtub3cgd2hldGhlciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0ZSkNCg0K
DQoNClVscmljaA0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206
IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNl
bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA0OjQ5IFBNDQoNClRvOiBXaWVoZSwgVWxy
aWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0
bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRm
Lm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpVbHJpY2gsDQoNCg0KDQpJ
dCBzZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUgcGFnZSBidXQgcHJvYmFibHkgdGhlIHByb3Bvc2Vk
IHdvcmRpbmcgYmVsb3cgaXMgbm90IHRoZSBiZXN0Lg0KDQpIb3cgYWJvdXQgdGhlIGZvbGxvd2lu
Zy4NCg0KDQoNCldoZW4gdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUgbmV3IG92
ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3Zl
cmxvYWQgcmVwb3J0IHRvd2FyZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNsdWRlIE9M
UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFk
ZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg
aXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0
byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBP
TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNo
KSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVicnVh
cnkgMDYsIDIwMTQgMzo1NyBQTQ0KDQpUbzogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxt
YWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4
dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpT
dWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcNCg0KDQoNCk5pcmF2LCBMaW9uZWwsDQoNCg0KDQpJIGNhbiB1bmRlcnN0YW5kIE5pcmF2J3Mg
Y29uY2VybiAoYWx0aG91Z2ggdmlvbGF0aW5nIFJFUTEwKSBhbmQgaG9wIGl0IGlzIGFkZHJlc3Nl
ZCBieSB0aGUgbW9kaWZpZWQgcHJpbmNpcGxlIDInOg0KDQoNCg0KMicuIHRoZSByZXBvcnRpbmcg
bm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90
IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVk
IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFj
dGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5m
b3JtYXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVz
dGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQi
LCBvciBhbiBvbGQgIGJ1dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9k
ZSBpcyBub3Qgb3ZlcmxvYWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUu
Li4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBu
b3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29u
dGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNCkkgZG9uJ3QgYWdyZWUg
d2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJsb2FkIGNvbnRyb2wg
d2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBk
YXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50bHkpIGF3YXJlIG9m
IHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRlIE9MUnMuDQoNCg0K
DQpVbHJpY2gNCg0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJv
bTogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFu
Z2UuY29tPiBbbWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbV0NCg0KU2VudDogVGh1cnNk
YXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDEwOjIwIEFNDQoNClRvOiBOaXJhdiBTYWxvdCAobnNhbG90
KTsgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KDQoNCg0KDQot
LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95w6kg
OiBqZXVkaSA2IGbDqXZyaWVyIDIwMTQgMTA6MDggw4AgOiBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBp
ZXRmLm9yZz4gT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KDQoNClVscmljaCwNCg0KDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgZm9y
Y2luZyB0aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2RlICJvdGhlcndpc2UgKGkuZS4gaWYg
aXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVy
IG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJl
cXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KDQpU
aGUgcmVwb3J0aW5nIG5vZGUgbWF5IHNpbXBseSBub3QgaW5jbHVkZSBPTFIgYXNzdW1pbmcgdGhh
dCB0aGUgZWFybGllciBwcm92aWRlZCBPTFIgd2lsbCBleHBpcmUgYW5kIHRoZSByZWFjdGluZyBu
b2RlIHdpbGwgc3RvcCB0aHJvdHRsaW5nIHRoZSB0cmFmZmljLg0KDQoNCg0KW0xNXSBBZ3JlZS4g
SW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0
IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3aGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyIG1heSBk
ZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVh
c3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4NCg0KDQoNCkFzIHdlIGhhZCBkaXNj
dXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRv
IGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5nIGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUg
c2FtZSB0aW1lLiBJbiBvdGhlciB3b3JkcywgdGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0
aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9MUiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0
aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJkcyBpdC4NCg0KDQoNCltMTV0gQWdyZWUNCg0KDQoN
ClRoZXJlIG1heSBiZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBr
bm93cyB0aGF0IHRoZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFj
ayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYg
Y3VycmVudGx5IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi4NCg0KDQoNCltMTV0gQWdy
ZWUNCg0KDQoNClJlc3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVsb3cgYXJlIGZpbmUgd2l0aCBtZS4N
Cg0KDQoNCltMTV0gQWdyZWUNCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVu
aWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVi
cnVhcnkgMDYsIDIwMTQgMjoyMyBQTQ0KDQpUbzogZXh0IFN0ZXZlIERvbm92YW47IE5pcmF2IFNh
bG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJq
ZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN
Cg0KDQoNCkFjdHVhbGx5IHdlIHNlZW0gdG8gYWdyZWUgb24gdHdvIHByaW5jaXBsZXM6DQoNCjEu
IExhY2sgb2YgT0xSIG1lYW5zICJubyBjaGFuZ2UiDQoNCjIuIHRoZSByZXBvcnRpbmcgbm9kZSAo
bm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJl
dHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBu
b2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiBy
ZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVy
bG9hZCIpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0
aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVy
biBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1T
dXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCg0KDQpDYW4gcGVvcGxlIHBsZWFzZSBjb25maXJtLg0K
DQoNCg0KVWxyaWNoDQoNCg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NCg0KU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAwNSwgMjAxNCA0OjM1IFBNDQoNClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGlt
ZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpBZ3JlZWQuICBU
byByZXN0YXRlIC0tIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGRvZXMgbm90IGNoYW5nZSB0
aGUgY3VycmVudCBvdmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhvc3Qgb3IgcmVhbG0uICBJZiB0aGVy
ZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVz
IHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFu
Z2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LiAgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5
IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBp
bXBsaWVzIHRoZXJlIGlzIG5vIG92ZXJsb2FkIGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uDQoNCg0K
DQpTdGV2ZQ0KDQpPbiAyLzUvMTQgOToxOSBBTSwgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6
DQoNCkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQgInNob3VsZG7igJl0IGxhY2sg
b2YgT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPyINCg0KDQoNCldlIGhhZCBz
b21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNv
bmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZl
cnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJh
Y2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZv
aWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9w
dGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHBy
b2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3Lg0KDQoNCg0KU28gYmFzaWNhbGx5
LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2
ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGlu
dWUgdG8gcmVhY3QgYmFzZWQgb24gb2xkZXIgT0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZh
bGlkaXR5LXBlcmlvZCBvciB3aGVuIHRoZSBleHBsaWNpdCBPTFIgd2l0aCAiMCIgb3ZlcmxvYWQt
bWV0cmljIGlzIHJlY2VpdmVkLg0KDQpJbiBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3IgZmxleGli
bGUgaW1wbGVtZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBoYW5kbGlu
ZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4N
Cg0KDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBTdGV2ZSBEb25vdmFuDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQg
ODowMCBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3Vi
amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQoNCg0KDQppbmxpbmUNCg0KT24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAt
IERFL011bmljaCkgd3JvdGU6DQoNCk9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBvcnRpbmcg
bm9kZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHRo
YXQgY29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4gT0MtU3Vw
cG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlzIHJlcXVl
c3RlZCkuDQoNClNSRD4gV2h5IGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlPyAgU2hvdWxkbid0IGxh
Y2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCg0KDQoN
Cg0KDQoNCg0KT3RoZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0
byBtYXR0ZXIuDQoNClNSRD4gUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBh
bnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9h
ZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVu
dGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5nIE9MUnMuDQoNCg0KDQoNCg0KDQoN
Cg0KDQpGb3IgbXkgY2xhcmlmaWNhdGlvbjogSSBndWVzcyB0aGF0IHRoZSByZWFjdGluZyBub2Rl
IGlzIG5vdCByZXF1aXJlZCB0byBwcm9jZXNzIGV2ZXJ5IHNpbmdsZSBPTFIgcmVjZWl2ZWQgKG1v
c3Qgd2lsbCBiZSByZXBsYXlzIGFueXdheSkuIFdoYXQgd291bGQgYmUgdGhlIHByb2NlZHVyZSBp
biB0aGUgcmVhY3Rpbmcgbm9kZSBpbiBvcmRlciB0byBtaW5pbWl6ZSBwcm9jZXNzaW5nIG9mIHJl
cGxheWVkIE9MUnMgYW5kIGF0IHRoZSBzYW1lIHRpbWUgbWluaW1pemUgdGhlIHJpc2sgdG9vIG1p
c3MgYSBuZXcgT0xSPw0KDQpTUkQ+IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNl
IG51bWJlci4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkg
MDUsIDIwMTQgNToyNyBBTQ0KDQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzps
aW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYu
b3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KDQoNCkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuDQoN
Cg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bT4NCg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTQ0KDQpUbzogZGlt
ZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpJIHVuZGVyc3Rh
bmQgdGhhdCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIERPRVMg
Tk9UIGluc2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4NCg0KU28gdGhlIG9wdGlvbnMgd291
bGQgYmU6DQoNCjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyDQoNCjItIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICsgT0MtT0xSIEFWUCBpbiBzb21l
IGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGll
bnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4NCg0KDQoNCklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRl
cmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KDQoNCg0KTGlvbmVs
DQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCg0KRGUgOiBkaW1lIGlzc3VlIHRy
YWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCg0KRW52b3nDqSA6
IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo0OQ0KDQrDgCA6IE1PUkFORCBMaW9uZWwgSU1UL09M
Tg0KDQpDYyA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNCk9iamV0IDog
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQogSXQgaGFzIGJlZW4gcHJvcG9zZWQgdG8g
ZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0aGF0IGlzICB0byBiZSBp
bmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhl
IFNlcXVlbmNlLU51bWJlcg0KDQogKFRpbWVTdGFtcCkgb2YgdGhlIE9MUiBhY2NvcmRpbmcgdG8g
d2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdhcw0KDQogc3Vydml2ZWQpIGlzIHBlcmZvcm1l
ZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm8gIHRocm90
dGxpbmcgaXMgcGVyZm9ybWVkLiAgUmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhp
cyAgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVk
IHRvIHVwZGF0ZSB0aGUgIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0IE9M
Ui4NCg0KIEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5pc20gd291bGQgcmVzdWx0IGlu
IHRoZSBuZWVkIGZvciB0aGUgIHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4g
ZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9JQyAgZW5kcG9pbnQgY2Fubm90IGtub3cg
d2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyAgdGhl
IHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRocm90dGxpbmcvbm90IHRocm90dGxpbmcuDQoN
CiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dz
IHRoZSByZXBvcnRpbmcgRE9JQyAgZW5kcG9pbnQgdG8gZGV0ZWN0IGFuZCBjb3JyZWN0IGluYXBw
cm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmcgIERPSUMgZW5kcG9pbnQgKGNhdXNl
ZCBieSB3aGF0ZXZlciByZWFzb24pLg0KDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFs
bG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4Lg0KDQogSW4gc3VtbWFyeSBpdCBp
cyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0
byAgYmUgdXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
Lg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1F
QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUN
Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl
dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls
ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91
IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw
YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy
dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p
cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0
ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm
YWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt
YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h
eSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz
ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2
ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl
dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUg
YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu
IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWls
aW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRp
TUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1h
aWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRm
Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj
b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg
ZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w
aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl
cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1
aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx
dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRv
dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91
IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz
IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg
bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl
ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k
IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1h
eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl
IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6
MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z
b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs
b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsN
Cgljb2xvcjpibGFjazt9DQpwLlByZm9ybWF0SFRNTCwgbGkuUHJmb3JtYXRIVE1MLCBkaXYuUHJm
b3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJbXNvLXN0
eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg
TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2Fy
DQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMyNDQwNjE7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOmJsYWNrO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBhbSBhbHNvIGZpbmUgd2l0
aCBTdGV2ZSdzIHByb3Bvc2VkIHdvcmRpbmcgdG8gcmVjb21tZW5kIHRoZSBpbmNsdXNpb24gb2Yg
T0xSIGJ1dCB0byBub3QgbWFuZGF0ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkkgYW0gbm90IHN1cmUgYWJvdXQg
dGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBhZGQg
aXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTpUaW1lcyI+Tm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5
LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5n
IG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGlu
ZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGll
bnQNCiBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIHByZWZlciB0byByZW1vdmUgaXQgc2lu
Y2UgSSBkbyBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNl
c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE08YnI+
DQo8Yj5Ubzo8L2I+IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkknbSBmaW5lIHdpdGggYSByZWNvbW1l
bmRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1lbnQ6IHdoZW4gYSBN
QVkgb3IgZXZlbiBhIFNIT1VMRCBhcHBseSwgaXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIE5P
VCB1cCB0byB0aGUgbm9kZSB0byBkbyBvciBub3QgdG8gZG8gc29tZXRoaW5nLiBJdCBkb2VzIG5v
dCBtZWFuDQogdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGluc3RhbmNlLCBvdmVyIGEgZ2l2ZW4gaW50ZXJm
YWNlLCB0aGUgcmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkgdGhhdCBzb21lIHN0YXRlcyBh
cmUgbWFpbnRhaW5lZCBieSB0aGUgc2VydmVyLiBBbmQgaXQgY291bGQgYmUgZGVjaWRlZCB0byBh
ZGQgc29tZSBvdmVybG9hZA0KIHJlbGF0ZWQgaW5mbyBpbiBzdWNoIHN0YXRlcy4gRm9yIGluc3Rh
bmNlIGFnYWluLCB0aGUgbm9kZSBjYW4gdXNlIHRoaXMgc3RhdGUgdG8ga25vdyBpZiBhIHJlbW90
ZSBub2RlIGhhdmUgYmVlbiBub3RpZmllZCBvciBub3QgZm9yIGluc3RhbmNlLiBBbmQgaW4gc3Vj
aCBhIGNhc2UsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBpbmNsdWRlIGFuIE9MUiBpbiBl
YWNoIG1lc3NhZ2UuIEl0IGlzIGp1c3QgZm9yIGlsbHVzdHJhdGlvbi4gVGhlIHBvaW50DQogaXMg
dGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9MUiBpbiBldmVyeSBh
bnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGhhdmlu
ZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l4oCmIGJ1dCBpdCBzaG91bGQgYmUgbm90
IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4gU28gT0sgZm9yIGEgJnF1b3Q7U0hPVUxE
JnF1b3Q7IG9yICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkxpb25lbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k
b3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8
L2I+IFN0ZXZlIERvbm92YW48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTAgZsOp
dnJpZXIgMjAxNCAxNzoyMTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRp
bWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqPC9iPjwvc3Bhbj48Yj48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ZXQm
bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbw0KIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz
cGFuIGxhbmc9IkZSIj5JIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0p
PGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNheWluZyB0aGUgcmVj
b21tZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFs
bCByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5IE1hcmlhIENydXou
Jm5ic3A7DQo8YnI+DQo8YnI+DQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYn
cyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0aW5n
IG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5
IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4mbmJzcDsgSSBkb24ndCB0aGluayB3ZSBuZWVk
IHRvIGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtub3dz
DQogYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0
dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuJm5ic3A7IFRoZSBjYXNlIG9mIGFn
ZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMg
YmVpbmcgb25lIGV4YW1wbGUuPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1mYW1pbHk6VGltZXMiPldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUg
cmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2Fs
Ljxicj4NCjxicj4NCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSB3b3JkaW5nLCB3
aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFzb25zIGZvciByZWNv
bW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBpbmNsdWRlZC48YnI+
DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhh
dCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy48YnI+DQo8
YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVy
bG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rl
cy4mbmJzcDsNCjxicj4NCjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28g
aW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5v
biByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNwOyBUaGUgb3Zl
cmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0
IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1BWSBj
aG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBp
ZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVj
ZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48YnI+DQo8YnI+DQpOb3RlIC0gdGhlIG9ubHkgc3Vy
ZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVh
Y3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJl
YWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhl
IGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkZSIj5PbiAyLzEwLzE0IDM6NTIgQU0sIE1hcmlhIENydXogQmFydG9sb21lIHdyb3RlOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5IZWxs
byBOaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QW55IHNv
bHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2llbmN5IGNvdWxk
IGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBmaXJzdCB3ZSBu
ZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBwcm92aWRpbmcg
dmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5Zb3VyIHByb3Bvc2VkIHRleHQmbmJzcDsgPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mcXVvdDsgQWRkaXRpb25hbGx5LCBpbiBvdGhl
ciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhl
IG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2Rl
LCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2Us
IHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiZxdW90
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB0aGUgcmVwb3J0
aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3aGV0aGVyIG9yIG5vdCBvdmVybG9hZCByZXBvcnQgaXMg
cHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIGFuZCBpdCBkZWNpZGVzIChzaW5jZSBpdCBp
cyBhICZxdW90O21heSZxdW90OykgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBv
dmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdh
cyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rp
bmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAmcXVvdDtyZWFjdGluZyBub2RlcyZx
dW90OyBjb3VsZCBiZSBub3Qgb25seSB0aGUgY2xpZW50LCBidXQgQU5ZIGFnZW50IHVzZWQgZm9y
IHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4gdGhlIGFnZW50IGlzIHByb3ZpZGluZyBzZXJ2aWNlIHRv
IGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlzIHJlYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBw
b3J0aW5nIGNsaWVudCkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+VGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93IHdoZW4gcmVh
Y3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0
IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQgJnF1b3Q7bWF5
JnF1b3Q7KSB0aGVuIG9uZSBvciBtdWx0aXBsZSByZWFjdGluZyBub2RlcyBkbyBub3QgaGF2ZSB0
aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gd2lsbCBub3Qgd29yay48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhlcmVmb3JlLCBpbiBt
eSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWlyZWQgaW5mb3JtYXRp
b24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90
KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28u
Y29tPC9hPl0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5T
ZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJ1dCBNYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Ib3cgY2FuIHdlIHNheSB0aGF0ICZxdW90O2luY2x1
ZGluZyB0aGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZm
aWNpZW50PyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+SXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1dCBub3QgZWZmaWNpZW50LiA8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QSBzbGlnaHRseSBkaWZmZXJlbnQgd29yZGlu
ZyBmcm9tIHdoYXQgSSBwcm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVuIHRoZSByZXBvcnRpbmcgbm9k
ZSBoYXMgYSBuZXcgb3ZlcmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8g
YSByZWFjdGluZyBub2RlIChieSB1cGRhdGluZyB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9h
ZCByZXBvcnQgb3IgYnkgcHJvdmlkaW5nIHRoZSBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSBmaXJz
dCB0aW1lKSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVx
dWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29y
cmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBl
LmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQg
cmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBv
cnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJl
cXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IERpTUUgWzxhIGhyZWY9Im1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIw
MTQgMzowMyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk5pcmF2LCBhbGwsPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgdGhpbmsgd2Ugc2hvdWxkIGRlZmluZSBhbiBh
Y2N1cmF0ZSBhbmQgcm9idXN0IHNvbHV0aW9uLCBhcyBlZmZpY2llbnQgYW5kIHNpbXBsZSBhcyBw
b3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkg
dW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEgcHVyZSAmcXVvdDttYXkmcXVvdDssIGJ1dCBs
ZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3VyZSByZWFjdGluZyBu
b2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVj
aGFuaXNtIHRvIHdvcmsuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+RnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0bzpu
c2Fsb3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBsdW5lcywgMTAgZGUgZmVi
cmVybyBkZSAyMDE0IDEwOjEyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5UbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll
dGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPk1hcmlhLUNydXosPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PkkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ugb24gJnF1b3Q7c2VuZGluZyBPTFIgaW4gQUxMIGFuc3dl
cnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMmcXVvdDsuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BbmQgd2UgYXJlIG5vdCB0cnlpbmcgdG8gcHJl
dmVudCBpdCAtIGF0IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9uLiA8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywg
YXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlv
biwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50
IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5Nb3N0IHByb2JhYmx5LCB0aGUgdmVyeSBmaXJzdCBpbXBsZW1lbnRh
dGlvbiBvZiBvdmVybG9hZCBjb250cm9sIHdpbGwgaW5jbHVkZSBPTFIgaW4gYWxsIHRoZSBhbnN3
ZXIgbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5CdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2
ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNr
cyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2Uu
IEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGlu
ZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLiA8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPldoYXQgZG8geW91IHRoaW5rPzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIGFsc28gdGhlIHJlYXNv
biBJIHdhcyBzdWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVkZSBP
TFIgKGZyb20gdGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBEaU1FIFs8YSBocmVmPSJt
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
PC9hPl0gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAy
MDE0IDg6NTcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PlRvOiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1YmplY3Q6IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5IZWxsbyBVbHJpY2gsIE5pcmF2LDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVlIHdpdGggVWxyaWNo
IHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1BWSwgYW5kIHdoZXRo
ZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNoYWxsIG5v
dCBiZSBqdXN0IGEgTUFZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5PbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4g
T0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdl
OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSkgdGhlIHJl
cG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290
IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5iKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBu
b3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhh
cyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Yykgb3RoZXJ3aXNlPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlcG9ydGluZyBub2RlIG11c3QgaGF2ZSBzb21lIGtub3ds
ZWRnZSBhYm91dCBPTFIgcmVjZXB0aW9uL3N0YXR1cyBpbiByZWFjdGluZyBub2RlLiBIb3cgZG9l
cyBzZXJ2ZXIgYWNxdWlyZSB0aGlzIGtub3dsZWRnZT8gPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UYWtlIGludG8gYWNjb3VudCBhcyB3ZWxsIHRoYXQgYSAm
cXVvdDtyZWFjdGluZyZxdW90OyBub2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChpbiBjYXNlIGl0
IHByb3ZpZGVzIHNlcnZpY2UgdG8gYSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9u
LXN1cHBvcnRpbmcgY2xpZW50KSZuYnNwOyBhbmQgYSBDbGllbnQuIEluIHRoZSBjYXNlIG9mIEFn
ZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBrbm93IGlmIHRoaXMgaXMgZ29p
bmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRyYW5zcGFyZW50bHksIGluIGZh
Y3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFueSBrbm93bGVkZ2UgYWJvdXQg
d2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBDbGllbnQuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRo
aW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFk
dmFudGFnZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4t
IHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNlc3Npb24pIGlzIHNp
bXBsZXIsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tIHRo
ZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gc2Vu
ZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhlciB3aGV0
aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9yIHdoZXRo
ZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tIHNlbmRpbmcgYW4gYWRkaXRpb25h
bCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29uIHdpdGggcmVx
dWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgSW4gZmFjdCwgaW4gYW4gb3Zl
cmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxleCBpcyB0byBzZW5k
IGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBub2RlcywgPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgYW5kIHRoZSBs
YXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMmbmJzcDsg
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tIG1vcmUgcm9i
dXN0IHNvbHV0aW9uLCBhcyBubyBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhlIGNoZWNrcyBvbiB0
aGUgbmVlZCB0byBzZW5kIGluZm9ybWF0aW9uLCZuYnNwOyBmb3Igc2l0dWF0aW9ucyB3aGVyZSBh
biBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCZuYnNwOyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u
IEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiB2aWVybmVzLCAwNyBkZSBmZWJy
ZXJvIGRlIDIwMTQgMTA6NTk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPlRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCA8YSBocmVmPSJtYWlsdG86
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBl
eHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0
Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5T
dWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TmlyYXYsPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkknbSBhZnJhaWQgeW91ciBwcm9w
b3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+JnF1b3Q7d2hlbiBpdCB3YW50cyB0byBwcm92aWRl
L3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uJnF1b3Q7IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7
Li4uaXQgbWF5IGluY2x1ZGUuLi4mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPiZxdW90O2luIG90aGVyIGNhc2VzJnF1b3Q7IGluIHRoZSBnaXZlbiBjb250
ZXh0IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7d2hlbiBpdCBkb2VzIG5vdCB3YW50IHRvIHByb3ZpZGUv
dXBkYXRlLi4uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+V2Ug
aGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5iKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90
IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0
aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGly
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Yykgb3RoZXJ3
aXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmluIGNhc2UgYSkg
dGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2Ug
YikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5n
IG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBN
VVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9l
cyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5VbHJpY2g8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogZXh0IE5pcmF2IFNh
bG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2NvLmNvbSI+bWFpbHRvOm5z
YWxvdEBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkgUE08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBXaWVoZSwgVWxyaWNo
IChOU04gLSBERS9NdW5pY2gpOyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jh
bmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0ZXZlIERvbm92YW47
IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+SXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0
IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkhvdyBhYm91dCB0aGUg
Zm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5XaGVu
IHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQg
b3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0
b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3Bv
bnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwg
dG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGlu
IG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBp
ZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5n
IG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNw
b25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IFdp
ZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgWzxhIGhyZWY9Im1haWx0bzp1bHJpY2gud2ll
aGVAbnNuLmNvbSI+bWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tPC9hPl08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFy
eSAwNiwgMjAxNCAzOjU3IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5UbzogZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20i
Pmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQg
U3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5v
cmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TdWJq
ZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TmlyYXYsIExpb25lbCw8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBjYW4gdW5kZXJzdGFu
ZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBp
cyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzo8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+MicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0
dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBh
biBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFs
cmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUu
Zy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmlj
IHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVybG9hZCZxdW90Oywg
b3IgYW4gb2xkJm5ic3A7IGJ1dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcg
bm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdh
cmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBv
ciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2gg
Y29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hh
dC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4g
d2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMs
IHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3Zlcmxv
YWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+VWxyaWNoJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+IFs8YSBocmVm
PSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5tYWlsdG86bGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBBTTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IE5pcmF2IFNhbG90IChuc2Fs
b3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3Zhbjsg
PGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RGUmbmJzcDs6IERpTUUgWzxhIGhy
ZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmc8L2E+XSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95w6kmbmJz
cDs6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCZuYnNwOzogV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1l
QGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPiBPYmpldCZuYnNwOzogUmU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+SSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Ig
b24gcmVwb3J0aW5nIG5vZGUgJnF1b3Q7b3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2Fy
ZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9y
IG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBj
b250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiZxdW90OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhlIHJlcG9ydGluZyBub2RlIG1heSBz
aW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQg
T0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGlu
ZyB0aGUgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
W0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9y
IHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3
aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUg
YW5zd2VyIG1heSBkZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRh
dGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJs
aWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRs
eSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUu
IEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFs
IGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxp
bmcgdHJhZmZpYyB0b3dhcmRzIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5bTE1dIEFncmVlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPlRoZXJlIG1heSBiZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9k
ZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUg
YmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIg
aWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+W0xNXSBBZ3JlZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5SZXN0IG9mIHRoZSBwcmluY2lwbGVzIGJlbG93IGFy
ZSBmaW5lIHdpdGggbWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+UmVn
YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk5pcmF2
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbPGEgaHJlZj0ibWFpbHRv
OnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb208L2E+XTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogVGh1cnNk
YXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5z
YWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFjdHVhbGx5IHdlIHNlZW0gdG8gYWdy
ZWUgb24gdHdvIHByaW5jaXBsZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj4xLiBMYWNrIG9mIE9MUiBtZWFucyAmcXVvdDtubyBjaGFuZ2UmcXVvdDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjIuIHRoZSByZXBvcnRp
bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUg
bm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFp
bmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSBy
ZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJl
IGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5n
ICZxdW90O25vIG92ZXJsb2FkJnF1b3Q7KTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBh
d2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVk
IG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGlj
aCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DYW4gcGVvcGxlIHBsZWFzZSBjb25maXJtLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5VbHJpY2g8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5d
IE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA0
OjM1IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Ubzog
TmlyYXYgU2Fsb3QgKG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1l
QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFncmVlZC4m
bmJzcDsgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBkb2VzIG5vdCBj
aGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUgZm9yIHRoZSBob3N0IG9yIHJlYWxtLiZu
YnNwOyBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4g
aXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhw
bGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LiZuYnNwOyBJZiB0aGVy
ZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4g
b3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0
IGFuZCByZWFsbS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3Rl
dmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9uIDIvNS8x
NCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhl
IHBhcnQgJnF1b3Q7c2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90
IG92ZXJsb2FkZWQ/JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0aGF0
IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRlIHRo
ZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlzIGNh
cGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ug
d2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQuIEJ1
dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5l
ZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TbyBiYXNpY2FsbHksIHRoZSBsYWNr
IG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQg
dGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFj
dCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHktcGVy
aW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICZxdW90OzAmcXVvdDsgb3ZlcmxvYWQt
bWV0cmljIGlzIHJlY2VpdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+SW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0
aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRo
ZSByZWFjdGluZyBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IERp
TUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogV2VkbmVzZGF5LCBGZWJy
dWFyeSAwNSwgMjAxNCA4OjAwIFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5v
cmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TdWJq
ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+aW5saW5lPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PbiAyLzUvMTQgNzo1NyBBTSwg
V2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBv
cnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3Nh
Z2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4g
T0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlz
IHJlcXVlc3RlZCkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5TUkQmZ3Q7IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT8mbmJzcDsgU2hvdWxkbid0IGxh
Y2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5PdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRv
IG5vdCBzZWVtIHRvIG1hdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPlNSRCZndDsgUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBh
bnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9h
ZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVu
dGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5nIE9MUnMuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJl
YWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiBy
ZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUg
cHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nl
c3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUg
cmlzayB0b28gbWlzcyBhIG5ldyBPTFI/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5TUkQmZ3Q7IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNl
IG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTog
RGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxv
dCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFdl
ZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5k
QG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IERpTUUgWzxhIGhy
ZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jh
bmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIw
MTQgOTowNyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFs
IGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBP
TFIgaW4gZXZlcnkgYW5zd2VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPlNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+MS0gT0MtT0xSIEFWUCBpbiBldmVyeSBhbnN3ZXI8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjItIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICYjNDM7IE9DLU9MUiBBVlAgaW4g
c29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0aGUg
Y2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAx
IHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5MaW9uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5EZSZuYnNwOzogZGltZSBpc3N1ZSB0cmFja2VyIFs8YSBocmVm
PSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnIj5tYWlsdG86dHJhYyYj
NDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPkVudm95w6kmbmJzcDs6IG1hcmRpIDQgZsOpdnJpZXIgMjAx
NCAwOTo0OTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+w4Am
bmJzcDs6IE1PUkFORCBMaW9uZWwgSU1UL09MTjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3Jn
Ij5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+T2JqZXQmbmJzcDs6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+IzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMmbmJzcDsgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJl
YWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0Jm5ic3A7IHN1cnZp
dmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51
bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+IChUaW1l
U3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGlj
aCB3YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBzdXJ2
aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1
cnJlbnRseSBubyZuYnNwOyB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4mbmJzcDsgUmVwb3J0aW5n
IERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhpcyZuYnNwOyBpbmZvcm1hdGlvbiBpbiBvcmRlciB0
byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZSZuYnNwOyByZWFj
dGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1l
Y2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSZuYnNwOyByZXBvcnRpbmcg
bm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5n
IERPSUMmbmJzcDsgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9J
QyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyZuYnNwOyB0aGUgcmlnaHQgdGhpbmcgd2l0aCBy
ZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVz
IHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNwOyBlbmRwb2lu
dCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSBy
ZWFjdGluZyZuYnNwOyBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBUaGUgZmVlZGJh
Y2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjgu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gSW4gc3VtbWFy
eSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCB0byZuYnNwOyBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Im1haWx0bzpEaU1FQGll
dGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGll
Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll
bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2Vz
LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj
dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0
ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz
YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5n
ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl
LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh
aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv
dGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv
cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l
c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5rIHlvdS48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+
RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+
RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+
RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+
RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m
b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk
b25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRy
ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91
cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRl
dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh
Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRv
dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91
IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50
aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh
dzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hv
dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0
aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFs
dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt
b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6978Axmbrcdx10ciscoc_--


From nsalot@cisco.com  Tue Feb 11 02:23:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73D81A0943 for ; Tue, 11 Feb 2014 02:23:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.049
X-Spam-Level: 
X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKgmLsxwXtxv for ; Tue, 11 Feb 2014 02:23:17 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE9F1A0954 for ; Tue, 11 Feb 2014 02:23:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1777; q=dns/txt; s=iport; t=1392114180; x=1393323780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=25xesU7rsMbk0ISKTUSYk29i2riLlWLhZ9iHqXCAcSA=; b=KMZIz6V3s9umXgCyjKTd7aZCEwqdu7mdrB+q7cLsgXqTrOPvrO3hEcm7 W/ZREzix5rsA/wTWH4CapxeIyiS9J5KEwoeLSBuVsYgvXJAwZJft40nvX oc8IQi/cLxw7oSrIIh95pRX6b2dPc+jXw2xRlXH8j5qKhPZkyLZ1Bolxv w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAB/5+VKtJXG//2dsb2JhbABZgww4V75lgQ0WdIIlAQEBAwEBAQE3NAsMBAIBCBEEAQELFAkHIQYLFAkIAgQBDQUIh2kDCQgNwF4Nh2UTBIxfgWkxBwaDHoEUAQOWPo5JhUOBb4E+gio
X-IronPort-AV: E=Sophos;i="4.95,825,1384300800"; d="scan'208";a="303236432"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 11 Feb 2014 10:22:59 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1BAMxxg006609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:22:59 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 04:22:59 -0600
From: "Nirav Salot (nsalot)" 
To: Ben Campbell , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #46: Bad normative advice on not letting overload	reports expire
Thread-Index: AQHPJlGIdoxp4ZPGNkCdpdO55KBqgpqvEP0AgADIhpA=
Date: Tue, 11 Feb 2014 10:22:58 +0000
Message-ID: 
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>
In-Reply-To: <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.140.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dime@ietf.org list" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload	reports expire
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:23:19 -0000

Ben,

I resonate with your thinking below.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, February 10, 2014 9:54 PM
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overloa=
d reports expire


On Feb 10, 2014, at 5:16 AM, Jouni Korhonen  wrote:

>=20
> My reasoning for explicit termination was that knowing the=20
> implementation folks they will let overload conditions expire unless advi=
sed otherwise.
> And having unnecessary stuff hanging around waiting for a cleanup is=20
> not a good thing in general. But I am open here for other options..
>=20

I think it's reasonable to say that a reporting node should terminate an ov=
erload condition in a timely manner. But if it's about to expire anyway, th=
en expiration might be just as timely as an explicit report.=20

And of course, the definition of "timely" is somewhat a matter of policy. F=
or example, I can imagine an deployment that had a large number of clients =
using fairly short validity durations, and _never_ explicitly signaling an =
end to an overload condition. This adds a bit of a "slow-start" to the reco=
very, since different clients will expire the overload condition at differe=
nt times, and the load will ramp up gradually. I don't see anything wrong w=
ith that. Of course, it wouldn't work if one chose long validity durations,=
 or if the signaling of overload to different clients happened in close syn=
chronization.

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


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:24:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61521A093E for ; Tue, 11 Feb 2014 02:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3gmQ93m8Egc for ; Tue, 11 Feb 2014 02:24:02 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0D1A0945 for ; Tue, 11 Feb 2014 02:23:46 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-06-52f9fa313bd0
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.1C.04249.13AF9F25; Tue, 11 Feb 2014 11:23:45 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:23:44 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTA=
Date: Tue, 11 Feb 2014 10:23:43 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209772E88ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvja7hr59BBku2SlnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC/fVrEVrHnEVtH88CZTA+Of02xdjJwcEgImEgffX2eCsMUk LtxbDxYXEjjCKPF5VVIXIxeQvYRR4surJhaQBJuAncSl0y+AGjg4RASUJU7/cgAJCwuUS7y8 dIUZxBYRqJD4vPUSE0iviMAmRonnl18xgiRYBFQl/t6fywrSyyvgK/H2aAnE/BucEvv+fAFr 5gSK31uwAewgRqCDvp9aA2YzC4hL3HoyH+pQAYkle84zQ9iiEi8f/2OFsJUkFt3+DFWfLzFt 2n+wm3kFBCVOznzCMoFRZBaSUbOQlM1CUjYL6DxmAU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcW X8DIvoqRozi1OCk33chgEyMwVg5u+W2xg/HyX5tDjNIcLErivB/fOgcJCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYLwv+laqaLpBzJQCEbntKy9d0mvKLV7yo7f+kCHLvOSzmxxurV02xd+z ce6q/wtizXijzFnOZ/MGhXibM/3l+Lnu67ueDd4M3aJcP0y9ut2ms53akX1Ne8mHZUVf4g8+ iXZmSnsx9feHwh3dL6q2/zf1bmoKimi+Xcyd7aDd+s1xZny6zIJLp5VYijMSDbWYi4oTAU5h tDZjAgAA
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:24:10 -0000

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

SGVsbG8sDQoNCkkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGhpZ2hsaWdodCBjb21wbGV4aXR5
IGZvciB0aGUgc2VydmVyIHRvICDigJxndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBh
bHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0LuKAnQ0KSSB0aGluayB0aGlz
IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRlZCBieSBTdGV2ZS4NCg0KQ2hlZXJz
DQovTUNydXoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJl
cm8gZGUgMjAxNCAxMToyMA0KVG86IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgU3RldmUgRG9u
b3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgYW0gYWxzbyBmaW5lIHdpdGggU3RldmUncyBw
cm9wb3NlZCB3b3JkaW5nIHRvIHJlY29tbWVuZCB0aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQgdG8g
bm90IG1hbmRhdGUgaXQuDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0
LCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBhZGQgaXQuDQpOb3RlIC0gdGhlIG9u
bHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0
IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4g
dGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdl
ZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KDQpJIHByZWZlciB0byByZW1v
dmUgaXQgc2luY2UgSSBkbyBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KDQpSZWdhcmRzLA0K
TmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jh
bmdlLmNvbT4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE0NClRvOiBT
dGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVj
dDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN
CkknbSBmaW5lIHdpdGggYSByZWNvbW1lbmRhdGlvbi4NCg0KQnV0IEkgaGF2ZSBhIGdlbmVyYWwg
Y29tbWVudDogd2hlbiBhIE1BWSBvciBldmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5vdCBt
ZWFuIHRoYXQgaXQgaXMgTk9UIHVwIHRvIHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0byBkbyBzb21l
dGhpbmcuIEl0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9u
IG9wdGlvbi4NCkZvciBpbnN0YW5jZSwgb3ZlciBhIGdpdmVuIGludGVyZmFjZSwgdGhlIHJlbGF0
ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1haW50YWluZWQg
YnkgdGhlIHNlcnZlci4gQW5kIGl0IGNvdWxkIGJlIGRlY2lkZWQgdG8gYWRkIHNvbWUgb3Zlcmxv
YWQgcmVsYXRlZCBpbmZvIGluIHN1Y2ggc3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBu
b2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0byBrbm93IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVu
IG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5zdGFuY2UuIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNl
cnZlciBkb2VzIG5vdCBuZWVkIHRvIGluY2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVzc2FnZS4gSXQg
aXMganVzdCBmb3IgaWxsdXN0cmF0aW9uLiBUaGUgcG9pbnQgaXMgdGhhdCB5b3UgbWF5IGhhdmUg
c29tZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJl
IHJlcXVpcmVkLg0KDQpJIGFncmVlIHRoYXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2Vy
IGlzIGZpbmXigKYgYnV0IGl0IHNob3VsZCBiZSBub3QgbWFuZGF0b3J5IGluIGFsbCBjYXNlcyBJ
IHRoaW5rLiBTbyBPSyBmb3IgYSAiU0hPVUxEIiBvciAiUkVDT01NRU5ERUQiLg0KDQpSZWdhcmRz
LA0KDQpMaW9uZWwNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBE
ZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAxMCBmw6l2cmllciAy
MDE0IDE3OjIxDQrDgCA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpl
dCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQpJIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pDQoNCkkgc3VnZ2Vz
dCB0aGF0IHdlIGhhdmUgd29yZGluZyBzYXlpbmcgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlz
IHRvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMg
Zm9yIHRoZSByZWFzb25zIGxpc3RlZCBieSBNYXJpYSBDcnV6Lg0KDQpJIGFsc28gc3VnZ2VzdCB0
aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUg
a25vd3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3Zlcmxv
YWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4gIEkgZG9u
J3QgdGhpbmsgd2UgbmVlZCB0byBpbmNsdWRpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRoZSByZXBv
cnRpbmcgbm9kZSBrbm93cyBidXQgd2Ugc2hvdWxkIGluY2x1ZGUgd29yZGluZyBhYm91dCBuZXR3
b3JrcyBhcmNoaXRlY3R1cmVzIHRoYXQgbWFrZSBpdCBkaWZmaWN1bHQgdG8ga25vdy4gIFRoZSBj
YXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5n
IGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuDQoNCldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUg
dGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidz
IHByb3Bvc2FsLg0KDQpJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUgd29yZGluZywg
d2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBNYXJpYSBDcnV6J3MgcmVhc29ucyBmb3IgcmVj
b21tZW5kaW5nIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHdheXMgaW5jbHVkZWQuDQoN
Ci0tLS0tDQoNCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcg
bm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQg
dGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5z
d2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCk5vdGUgLSB0aGUgcmVwb3J0
aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBt
ZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNp
ZW50LiAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1l
dGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUg
TUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBu
b2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhh
cyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0KDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3
YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rp
bmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0
aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNs
aWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KT24gMi8xMC8xNCAzOjUyIEFNLCBNYXJpYSBD
cnV6IEJhcnRvbG9tZSB3cm90ZToNCg0KSGVsbG8gTmlyYXYsDQoNCg0KDQpBbnkgc29sdXRpb24g
c2hvdWxkIGJhbGFuY2UgZGlmZmVyZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291bGQgYmUgZGlz
Y3Vzc2VkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQgdG8g
YXNzdXJlIHRoZSBtZWNoYW5pc20gd2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGluZyB2YWxpZCBP
TFIgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCg0KDQpZb3VyIHByb3Bvc2VkIHRleHQNCg0KIiBBZGRp
dGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlz
IG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8g
dGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xS
IGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQt
RmVhdHVyZSBBVlAuIg0KDQoNCg0KSWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUgYWJvdXQg
d2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFjdGlu
ZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2UgaXQgaXMgYSAibWF5IikgdG8gZG8gbm90IHNl
bmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxs
IG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVz
cG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhh
dCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBBTlkg
YWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJvdmlk
aW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVoYWxm
IG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4NCg0KVGhlbiwgb24gb25lIGhhbmQgaXQgaXMg
bm90IHNpbXBsZSB0byBrbm93IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5m
byAoYXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMg
cGVyIHlvdXIgcHJvcG9zZWQgIm1heSIpIHRoZW4gb25lIG9yIG11bHRpcGxlIHJlYWN0aW5nIG5v
ZGVzIGRvIG5vdCBoYXZlIHRoZSByZXF1aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlv
biB3aWxsIG5vdCB3b3JrLg0KDQoNCg0KVGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2lt
cGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBP
TFIgaW4gQUxMIGFuc3dlcnMuDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBb
bWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRl
IDIwMTQgMTA6NDINCg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1h
aWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQoNCg0K
SG93IGNhbiB3ZSBzYXkgdGhhdCAiaW5jbHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIg
bWVzc2FnZXMgaXMgc2ltcGxlIGFuZCBlZmZpY2llbnQ/Ig0KDQpJdCBpcyBzaW1wbGUgZm9yIHN1
cmUgYnV0IG5vdCBlZmZpY2llbnQuDQoNCg0KDQpBIHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5n
IGZyb20gd2hhdCBJIHByb3Bvc2VkIGVhcmxpZXIgaXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2Rl
IGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQgdGhhdCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBh
IHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5nIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2Fk
IHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhlIG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0
IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1
ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3Jy
ZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUu
Zy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCBy
ZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9y
dGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVx
dWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2FyZHMs
DQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlN
RSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXog
QmFydG9sb21lDQoNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMzowMyBQTQ0KDQpU
bzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpOaXJh
diwgYWxsLA0KDQoNCg0KSSB0aGluayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCBy
b2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KDQpJ
IHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBhcyBhIHB1cmUgIm1heSIsIGJ1dCBsZWF2aW5nIGl0
IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3VyZSByZWFjdGluZyBub2RlIGhhcyB2
YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVjaGFuaXNtIHRv
IHdvcmsuDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxv
dEBjaXNjby5jb21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6MTIN
Cg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGll
dGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmcNCg0KDQoNCk1hcmlhLUNydXosDQoNCg0KDQpJIGZ1bGx5IGFncmVlIHdp
dGggeW91IG9uICJzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQg
YWR2YW50YWdlcyIuDQoNCkFuZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQg
bGVhc3QgdGhhdCBpcyBteSBpbnRlbnRpb24uDQoNCkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywg
YXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlv
biwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50
IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPw0KDQoNCg0KTW9zdCBwcm9iYWJseSwgdGhl
IHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Ygb3ZlcmxvYWQgY29udHJvbCB3aWxsIGluY2x1
ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzLg0KDQpCdXQgYXQgdGhlIHNhbWUgdGlt
ZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29t
ZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRo
ZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdl
IG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBp
biBwcm90b2NvbCBkZWZpbml0aW9uLg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KDQoNClRoaXMg
YWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hl
biB0byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2Ygdmlldyku
DQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAy
MDE0IDg6NTcgUE0NCg0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoN
ClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQoNCg0KSGVsbG8gVWxyaWNoLCBOaXJhdiwNCg0KDQoNCkkgYWdyZWUgd2l0aCBVbHJp
Y2ggdGhhdCB0aGUgdGV4dCBwcm92aWRlZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hl
dGhlciBvciBub3QgdGhlIHNlcnZlciBzZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwg
bm90IGJlIGp1c3QgYSBNQVkuDQoNCg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJv
dmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBz
ZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdlOg0KDQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3Mg
dGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCg0K
YikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdh
bnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290
IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoNCg0KDQpSZXBv
cnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlvbi9z
dGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBrbm93
bGVkZ2U/DQoNClRha2UgaW50byBhY2NvdW50IGFzIHdlbGwgdGhhdCBhICJyZWFjdGluZyIgbm9k
ZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAoaW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2aWNlIHRvIGEg
cmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkgIGFu
ZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIgbWF5
IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGluZyBub2Rl
IG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVk
IHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4gdG8g
dGhlIGZpbmFsIENsaWVudC4NCg0KDQoNClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRo
YXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFn
ZXM6DQoNCi0gc3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lv
bikgaXMgc2ltcGxlciwNCg0KLSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJtaW5l
IHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFjdGluZyBub2RlDQoNCi0gdGhl
IHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUg
aGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwg
dmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuDQoNCi0gc2VuZGluZyBhbiBhZGRpdGlvbmFsIEFWUCBp
cyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1aXJlZCBh
Ym92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLg0KDQogIEluIGZhY3QsIGluIGFuIG92
ZXJsb2FkIHNpdHVhdGlvbiwgdGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2Vu
ZCBpbmZvcm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsDQoNCiAg
YW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlv
bnMNCg0KLSBtb3JlIHJvYnVzdCBzb2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxs
IHRoZSBjaGVja3Mgb24gdGhlIG5lZWQgdG8gc2VuZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1YXRp
b25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlzIGxvc3QsICDigKYNCg0KDQoNCg0KDQpCZXN0
IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpG
cm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2ll
aGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKQ0KDQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJy
ZXJvIGRlIDIwMTQgMTA6NTkNCg0KVG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IGxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsg
ZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoN
ClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQoNCg0KTmlyYXYsDQoNCg0KDQpJJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBk
b2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24uDQoNCg0KDQoid2hlbiBpdCB3YW50cyB0byBw
cm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uIiB0cmFuc2xhdGVzIHRvICIuLi5p
dCBtYXkgaW5jbHVkZS4uLiIuDQoNCg0KDQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBj
b250ZXh0IHRyYW5zbGF0ZXMgdG8gIndoZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3Vw
ZGF0ZS4uLiINCg0KDQoNCg0KDQpXZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6DQoNCmEpIHRo
ZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5
IGdvdCB0aGUgbGF0ZXN0IE9MUg0KDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJs
b2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRo
ZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KDQpj
KSBvdGhlcndpc2UNCg0KDQoNCmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBt
YXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBv
ciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBp
biBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUg
YW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMg
YSByZXBsYXkgb3IgYW4gdXBkYXRlKQ0KDQoNCg0KVWxyaWNoDQoNCg0KDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWls
dG86bnNhbG90QGNpc2NvLmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0
IDQ6NDkgUE0NCg0KVG86IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGV4
dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpT
dWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcNCg0KDQoNClVscmljaCwNCg0KDQoNCkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdl
IGJ1dCBwcm9iYWJseSB0aGUgcHJvcG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3Qu
DQoNCkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLg0KDQoNCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5v
ZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0
ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5n
IG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVl
c3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJl
c3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5n
LiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJl
cG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0
aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1
ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KUmVnYXJkcywN
Cg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVo
ZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21d
DQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNDQoNClRvOiBleHQg
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+
OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8
bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsIExpb25lbCwNCg0KDQoN
CkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRpbmcgUkVR
MTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lwbGUgMic6
DQoNCg0KDQoyJy4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9h
ZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0
byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlm
IGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNv
bmFibGUgb3ZlcmxvYWQgY29udHJvbCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwg
d2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9M
UiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24gZXhwaXJpbmcg
T0xSIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNl
IChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0
ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3Bv
bnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUg
QVZQLg0KDQoNCg0KSSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Utd2FudCBh
cHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhl
IHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBu
b3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3
aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0KDQoNClVscmljaA0KDQoNCg0KDQoNCg0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+IFttYWlsdG86bGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0N
Cg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5p
Y2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9y
Zz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCg0KDQoNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpE
ZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmly
YXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nDqSA6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDD
gCA6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBk
aW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPiBPYmpldCA6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KVWxyaWNoLA0KDQoN
Cg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0aW5n
IG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRp
bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJu
IGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQoNClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5v
dCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxs
IGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRy
YWZmaWMuDQoNCg0KDQpbTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1l
ZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRy
YWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0
aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24g
dGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5k
aW5nLg0KDQoNCg0KQXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVk
IGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQg
ZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUg
cmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRv
IGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0
Lg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcu
IHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0
dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVk
IGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQg
Y29uZGl0aW9uLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxl
cyBiZWxvdyBhcmUgZmluZSB3aXRoIG1lLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVnYXJk
cywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5j
b21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNDQoNClRvOiBl
eHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8bWFp
bHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3Jl
ZSBvbiB0d28gcHJpbmNpcGxlczoNCg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSIN
Cg0KMi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9y
IG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1
ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlz
IGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3Qg
T0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3Ig
YW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBp
cyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zl
cmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVz
dHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNCkNh
biBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uDQoNCg0KDQpVbHJpY2gNCg0KDQoNCkZyb206IERpTUUg
W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9u
b3Zhbg0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE0NCg0KVG86
IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcNCg0KDQoNCkFncmVlZC4gIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9h
ZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0
aGUgaG9zdCBvciByZWFsbS4gIElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBvdmVybG9h
ZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVyIHRpbWVz
IG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCByZXBvcnQu
ICBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxh
Y2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9y
IHRoZSBob3N0IGFuZCByZWFsbS4NCg0KDQoNClN0ZXZlDQoNCk9uIDIvNS8xNCA5OjE5IEFNLCBO
aXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToNCg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0
aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92
ZXJsb2FkZWQ/Ig0KDQoNCg0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFu
ZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVy
IHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRo
ZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xp
ZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlz
IHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRo
ZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9m
IHZpZXcuDQoNCg0KDQpTbyBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFm
ZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRo
ZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIg
dW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxp
Y2l0IE9MUiB3aXRoICIwIiBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQoNCkluIG15IHZp
ZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0
aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4N
Cg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NCg0KU2VudDogV2Vk
bmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1h
aWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCmlubGluZQ0KDQpPbiAyLzUvMTQgNzo1
NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCg0KT2sgdGhlbiBs
ZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQ
IGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2Fn
ZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4g
bm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS4NCg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5z
d2VyIG1lc3NhZ2U/ICBTaG91bGRuJ3QgbGFjayBvZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMg
bm90IG92ZXJsb2FkZWQ/DQoNCg0KDQoNCg0KDQoNCg0KDQpPdGhlciBjcml0ZXJpYSBsaWtlIFJF
UTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci4NCg0KU1JEPiBSZXF1aXJpbmcgYW4g
b3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEz
LCBidXQgcmVxdWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50
aWFsIGFkZGl0aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNl
cnRpbmcgT0xScy4NCg0KDQoNCg0KDQoNCg0KDQoNCkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1
ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZl
cnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hh
dCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRv
IG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGlt
ZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/DQoNClNSRD4gVGhhdCBpcyB0
aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNCg0K
U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNDQoNClRvOiBsaW9uZWwu
bW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGRpbWVA
aWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSSBzaGFyZSB0aGUg
c2FtZSBvcGluaW9uIGFzIExpb25lbC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWls
dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPg0KDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAw
NCwgMjAxNCA5OjA3IFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcNCg0KDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hl
biB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5z
d2VyLg0KDQpTbyB0aGUgb3B0aW9ucyB3b3VsZCBiZToNCg0KMS0gT0MtT0xSIEFWUCBpbiBldmVy
eSBhbnN3ZXINCg0KMi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJl
cXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0
bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQoNCg0K
SWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJl
c3QgYXBwcm9hY2guDQoNCg0KDQpMaW9uZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt
LS0tLQ0KDQpEZSA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRv
b2xzLmlldGYub3JnXQ0KDQpFbnZvecOpIDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5DQoN
CsOAIDogTU9SQU5EIExpb25lbCBJTVQvT0xODQoNCkNjIDogZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NCg0KT2JqZXQgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCg0KDQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoN
CiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIHRoYXQgaXMgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVu
ZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBU
aGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQoNCiAoVGltZVN0YW1w
KSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2Fz
DQoNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRl
cyB0aGF0IGN1cnJlbnRseSBubyAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuICBSZXBvcnRpbmcg
RE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRl
Y3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3RpbmcgRE9JQyBl
bmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLg0KDQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNr
IG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVwb3J0aW5nIG5v
ZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBE
T0lDICBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBv
aW50IGlzIGFjdHVhbGx5IGRvaW5nICB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhy
b3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92
ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCB0
byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFj
dGluZyAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQoNCiBUaGUg
ZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZD
IDcwNjguDQoNCiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvICBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoN
CkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2Fn
ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z
IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBl
dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2
b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy
IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50
ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy
YXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug
YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVz
c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2
aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hv
dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0
aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht
ZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm
b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk
Lg0KDQpUaGFuayB5b3UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0
bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9y
Zz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGlu
ZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1F
QGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNl
cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk
ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUg
ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg
YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0K
YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl
cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh
dGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn
ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBt
ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy
aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhl
eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv
cmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh
YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz
aWZpZWQuDQoNClRoYW5rIHlvdS4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzOw0KCXBhbm9zZS0xOjIgMiA2IDMg
NSA0IDUgMiAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu
Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh
Y2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ
cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6
YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh
bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OmJsYWNrO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9y
bWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs
YWNrO30NCnAuUHJmb3JtYXRIVE1MLCBsaS5QcmZvcm1hdEhUTUwsIGRpdi5QcmZvcm1hdEhUTUwN
Cgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIjsNCgltc28tc3R5bGUtbGluazoi
UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2
MTt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl
OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ
bWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh
cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0
ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgaXQgaXMgaW1w
b3J0YW50IHRvIGhpZ2hsaWdodCBjb21wbGV4aXR5IGZvciB0aGUgc2VydmVyIHRvICZuYnNwO+KA
nDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5ndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZQ0K
IGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0NCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlbnRlbmNl
IGFkZGVkIGJ5IFN0ZXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93
dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp
bmRvd3RleHQiPiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5OaXJhdiBTYWxvdCAobnNhbG90KTxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0ZXMs
IDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyMDxicj4NCjxiPlRvOjwvYj4gbGlvbmVsLm1vcmFu
ZEBvcmFuZ2UuY29tOyBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIGFtIGFsc28gZmluZSB3aXRoIFN0
ZXZlJ3MgcHJvcG9zZWQgd29yZGluZyB0byByZWNvbW1lbmQgdGhlIGluY2x1c2lvbiBvZiBPTFIg
YnV0IHRvIG5vdCBtYW5kYXRlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBhbSBub3Qgc3VyZSBhYm91dCB0aGUg
Zm9sbG93aW5nIHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIGFkZCBpdC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7
Ij5Ob3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNt
cywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQg
cmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlz
IG5vIGFnZW50IGJldHdlZW4NCiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUuPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEi
PkkgcHJlZmVyIHRvIHJlbW92ZSBpdCBzaW5jZSBJIGRvIG5vdCBzZWUgYXMgdmFsdWUgYWRkaXRp
b24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMyNDQwNjEiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk5p
cmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi
PiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9h
Pjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEwOjEzIFBNPGJy
Pg0KPGI+VG86PC9iPiBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9y
ZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkknbSBmaW5lIHdpdGggYSByZWNvbW1lbmRhdGlvbi48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1
dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1lbnQ6IHdoZW4gYSBNQVkgb3IgZXZlbiBhIFNIT1VMRCBh
cHBseSwgaXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIE5PVCB1cCB0byB0aGUgbm9kZSB0byBk
byBvciBub3QgdG8gZG8gc29tZXRoaW5nLiBJdCBkb2VzIG5vdCBtZWFuDQogdGhhdCBpdCBpcyBv
bmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Rm9yIGluc3RhbmNlLCBvdmVyIGEgZ2l2ZW4gaW50ZXJmYWNlLCB0aGUgcmVsYXRlZCBzcGVj
aWZpY2F0aW9uIGNhbiBzYXkgdGhhdCBzb21lIHN0YXRlcyBhcmUgbWFpbnRhaW5lZCBieSB0aGUg
c2VydmVyLiBBbmQgaXQgY291bGQgYmUgZGVjaWRlZCB0byBhZGQgc29tZSBvdmVybG9hZA0KIHJl
bGF0ZWQgaW5mbyBpbiBzdWNoIHN0YXRlcy4gRm9yIGluc3RhbmNlIGFnYWluLCB0aGUgbm9kZSBj
YW4gdXNlIHRoaXMgc3RhdGUgdG8ga25vdyBpZiBhIHJlbW90ZSBub2RlIGhhdmUgYmVlbiBub3Rp
ZmllZCBvciBub3QgZm9yIGluc3RhbmNlLiBBbmQgaW4gc3VjaCBhIGNhc2UsIHRoZSBzZXJ2ZXIg
ZG9lcyBub3QgbmVlZCB0byBpbmNsdWRlIGFuIE9MUiBpbiBlYWNoIG1lc3NhZ2UuIEl0IGlzIGp1
c3QgZm9yIGlsbHVzdHJhdGlvbi4gVGhlIHBvaW50DQogaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29t
ZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJl
cXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGhhdmluZyB0aGUgT0xSIGluIGV2ZXJ5IGFu
c3dlciBpcyBmaW5l4oCmIGJ1dCBpdCBzaG91bGQgYmUgbm90IG1hbmRhdG9yeSBpbiBhbGwgY2Fz
ZXMgSSB0aGluay4gU28gT0sgZm9yIGEgJnF1b3Q7U0hPVUxEJnF1b3Q7IG9yICZxdW90O1JFQ09N
TUVOREVEJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbA0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w
cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1F
IFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IFN0ZXZlIERvbm92YW48YnI+
DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTAgZsOpdnJpZXIgMjAxNCAxNzoyMTxicj4N
CjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0
Zi5vcmc8L2E+PGJyPg0KPGI+T2JqPC9iPjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ZXQmbmJzcDs6PC9zcGFuPjwvYj48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbw0KIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVl
IHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pPGJyPg0KPGJyPg0KSSBzdWdnZXN0
IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNheWluZyB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMg
dG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFsbCByZXNwb25zZSBtZXNzYWdlcyBm
b3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5IE1hcmlhIENydXouJm5ic3A7DQo8YnI+DQo8YnI+DQpJ
IGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEg
cmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVj
ZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBp
dCBhZ2Fpbi4mbmJzcDsgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGluZyBhbnl0aGlu
ZyBhYm91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzDQogYnV0IHdlIHNob3VsZCBpbmNs
dWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlm
ZmljdWx0IHRvIGtub3cuJm5ic3A7IFRoZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rp
bmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuPGJy
Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUg
dGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidz
IHByb3Bvc2FsLjxicj4NCjxicj4NCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSB3
b3JkaW5nLCB3aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFzb25z
IGZvciByZWNvbW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBpbmNs
dWRlZC48YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBl
bnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0
cy48YnI+DQo8YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5j
bHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFj
dGluZyBub2Rlcy4mbmJzcDsNCjxicj4NCjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUg
bWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBz
ZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNw
OyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIg
bm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBu
b2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rp
bmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFk
eSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48YnI+DQo8YnI+DQpOb3RlIC0gdGhl
IG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0
aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdo
ZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJl
dHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBsYW5n
PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkZSIj5PbiAyLzEwLzE0IDM6NTIgQU0sIE1hcmlhIENydXogQmFydG9sb21l
IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5IZWxsbyBOaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+QW55IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2ll
bmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBm
aXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBw
cm92aWRpbmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Zb3VyIHByb3Bvc2VkIHRleHQmbmJzcDsgPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mcXVvdDsgQWRkaXRpb25hbGx5
LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdh
cmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFj
dGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUg
cmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUg
QVZQLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB0
aGUgcmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3aGV0aGVyIG9yIG5vdCBvdmVybG9hZCBy
ZXBvcnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIGFuZCBpdCBkZWNpZGVzIChz
aW5jZSBpdCBpcyBhICZxdW90O21heSZxdW90OykgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2Fp
biwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNh
c2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRp
YWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAmcXVvdDtyZWFjdGlu
ZyBub2RlcyZxdW90OyBjb3VsZCBiZSBub3Qgb25seSB0aGUgY2xpZW50LCBidXQgQU5ZIGFnZW50
IHVzZWQgZm9yIHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4gdGhlIGFnZW50IGlzIHByb3ZpZGluZyBz
ZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlzIHJlYWN0aW5nIG9uIGJlaGFsZiBvZiBh
IG5vbi1zdXBwb3J0aW5nIGNsaWVudCkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+VGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93
IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJl
bG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQg
JnF1b3Q7bWF5JnF1b3Q7KSB0aGVuIG9uZSBvciBtdWx0aXBsZSByZWFjdGluZyBub2RlcyBkbyBu
b3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gd2lsbCBu
b3Qgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhlcmVm
b3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWlyZWQg
aW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+L01DcnV6PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBOaXJhdiBTYWxv
dCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fs
b3RAY2lzY28uY29tPC9hPl0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5TZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogTWFyaWEgQ3J1eiBCYXJ0
b2xvbWU7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJ1dCBNYXJpYS1DcnV6LDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Ib3cgY2FuIHdlIHNheSB0aGF0ICZx
dW90O2luY2x1ZGluZyB0aGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBs
ZSBhbmQgZWZmaWNpZW50PyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+SXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1dCBub3QgZWZmaWNpZW50LiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QSBzbGlnaHRseSBkaWZmZXJl
bnQgd29yZGluZyBmcm9tIHdoYXQgSSBwcm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBoYXMgYSBuZXcgb3ZlcmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMgdG8gYmUgcHJv
dmlkZWQgdG8gYSByZWFjdGluZyBub2RlIChieSB1cGRhdGluZyB0aGUgZWFybGllciBwcm92aWRl
ZCBvdmVybG9hZCByZXBvcnQgb3IgYnkgcHJvdmlkaW5nIHRoZSBvdmVybG9hZCByZXBvcnQgZm9y
IHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0
byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJk
cyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVy
IGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUg
b3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUs
IHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwg
dG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IERpTUUgWzxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IE1vbmRheSwgRmVicnVh
cnkgMTAsIDIwMTQgMzowMyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3Jn
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVj
dDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk5pcmF2LCBhbGwsPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgdGhpbmsgd2Ugc2hvdWxkIGRl
ZmluZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0IHNvbHV0aW9uLCBhcyBlZmZpY2llbnQgYW5kIHNp
bXBsZSBhcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPkkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEgcHVyZSAmcXVvdDttYXkmcXVv
dDssIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3VyZSBy
ZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMgZm9y
IHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9
Im1haWx0bzpuc2Fsb3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBsdW5lcywg
MTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5UbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPk1hcmlhLUNydXosPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPkkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ugb24gJnF1b3Q7c2VuZGluZyBPTFIgaW4g
QUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMmcXVvdDsuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BbmQgd2UgYXJlIG5vdCB0cnlp
bmcgdG8gcHJldmVudCBpdCAtIGF0IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9uLiA8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJ1dCB0aGUgbWFpbiBxdWVz
dGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBs
ZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcg
cmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Nb3N0IHByb2JhYmx5LCB0aGUgdmVyeSBmaXJzdCBp
bXBsZW1lbnRhdGlvbiBvZiBvdmVybG9hZCBjb250cm9sIHdpbGwgaW5jbHVkZSBPTFIgaW4gYWxs
IHRoZSBhbnN3ZXIgbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5CdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmlj
dCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3Mg
YW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5
IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZv
aWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPldoYXQgZG8geW91IHRo
aW5rPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIGFsc28g
dGhlIHJlYXNvbiBJIHdhcyBzdWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8g
aW5jbHVkZSBPTFIgKGZyb20gdGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBEaU1FIFs8
YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBGcmlkYXksIEZlYnJ1
YXJ5IDA3LCAyMDE0IDg6NTcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPlRvOiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9y
ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1Ympl
Y3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5IZWxsbyBVbHJpY2gsIE5p
cmF2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVlIHdp
dGggVWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1BWSwg
YW5kIHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJz
IHNoYWxsIG5vdCBiZSBqdXN0IGEgTUFZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5PbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNo
IG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUg
a25vd2xlZGdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFs
cmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5iKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGku
ZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGlu
ZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Yykgb3RoZXJ3aXNlPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlcG9ydGluZyBub2RlIG11c3QgaGF2ZSBz
b21lIGtub3dsZWRnZSBhYm91dCBPTFIgcmVjZXB0aW9uL3N0YXR1cyBpbiByZWFjdGluZyBub2Rl
LiBIb3cgZG9lcyBzZXJ2ZXIgYWNxdWlyZSB0aGlzIGtub3dsZWRnZT8gPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UYWtlIGludG8gYWNjb3VudCBhcyB3ZWxs
IHRoYXQgYSAmcXVvdDtyZWFjdGluZyZxdW90OyBub2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChp
biBjYXNlIGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8gYSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxm
IG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KSZuYnNwOyBhbmQgYSBDbGllbnQuIEluIHRoZSBj
YXNlIG9mIEFnZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBrbm93IGlmIHRo
aXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRyYW5zcGFyZW50
bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFueSBrbm93bGVk
Z2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBDbGllbnQuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoZXJlZm9yZSwgSSBkZWZp
bml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1w
b3J0YW50IGFkdmFudGFnZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj4tIHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNlc3Np
b24pIGlzIHNpbXBsZXIsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj4tIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBu
b3QgdG8gc2VuZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJv
dGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xS
IG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tIHNlbmRpbmcgYW4g
YWRkaXRpb25hbCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29u
IHdpdGggcmVxdWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgSW4gZmFjdCwg
aW4gYW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxleCBp
cyB0byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBub2Rl
cywgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsg
YW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlv
bnMmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4t
IG1vcmUgcm9idXN0IHNvbHV0aW9uLCBhcyBubyBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhlIGNo
ZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5kIGluZm9ybWF0aW9uLCZuYnNwOyBmb3Igc2l0dWF0aW9u
cyB3aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCZuYnNwOyDigKY8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogRGlNRSBbPGEgaHJlZj0i
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
ZzwvYT5dIE9uIEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiB2aWVybmVzLCAw
NyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPlRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCA8YSBocmVm
PSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5j
b208L2E+OyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmci
PmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Tmly
YXYsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkknbSBhZnJhaWQg
eW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+JnF1b3Q7d2hlbiBpdCB3YW50cyB0
byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uJnF1b3Q7IHRyYW5zbGF0ZXMg
dG8gJnF1b3Q7Li4uaXQgbWF5IGluY2x1ZGUuLi4mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZxdW90O2luIG90aGVyIGNhc2VzJnF1b3Q7IGluIHRoZSBn
aXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7d2hlbiBpdCBkb2VzIG5vdCB3YW50IHRv
IHByb3ZpZGUvdXBkYXRlLi4uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+V2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5iKSB0aGUgcmVwb3J0aW5nIG5v
ZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFu
ZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBz
b29uIGV4cGlyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
Yykgb3RoZXJ3aXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmlu
IGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xS
IGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhl
IHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRp
bmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5n
IG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRl
KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5VbHJpY2g8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogZXh0
IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2NvLmNvbSI+
bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkg
UE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBXaWVo
ZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0ZXZl
IERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDog
UkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlVscmljaCw8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1l
IHBhZ2UgYnV0IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUg
YmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkhvdyBh
Ym91dCB0aGUgZm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5XaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVybG9h
ZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2Fk
IHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4g
dGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0
dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlv
bmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5v
dCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhl
IHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGlu
IHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVh
dHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2Fy
ZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgWzxhIGhyZWY9Im1haWx0bzp1
bHJpY2gud2llaGVAbnNuLmNvbSI+bWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tPC9hPl08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFRodXJzZGF5
LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5UbzogZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9y
YW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IE5pcmF2IFNhbG90IChuc2Fs
b3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRp
bWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TmlyYXYs
IExpb25lbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBjYW4g
dW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5k
IGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzo8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+MicuIHRoZSByZXBvcnRpbmcgbm9k
ZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRv
IHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFu
IE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGlu
ZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3Jt
YXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGlu
ZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVybG9h
ZCZxdW90Oywgb3IgYW4gb2xkJm5ic3A7IGJ1dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSBy
ZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBp
cyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zl
cmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVz
dHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBkb24ndCBhZ3JlZSB3aXRoIExpb25l
bHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3
b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rp
bmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJl
bnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VWxyaWNoJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IGV4dCA8YSBocmVmPSJtYWls
dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+
IFs8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5tYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBBTTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IE5pcmF2IFNh
bG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUg
RG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TdWJqZWN0OiBS
RTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RGUmbmJzcDs6IERp
TUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+XSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVu
dm95w6kmbmJzcDs6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCZuYnNwOzogV2llaGUs
IFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1h
aWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPiBPYmpldCZuYnNwOzogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMg
YmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgJnF1b3Q7b3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlz
IG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVy
bG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0
cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiZxdW90OzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhlIHJlcG9ydGluZyBu
b2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVhcmxpZXIg
cHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHN0b3Ag
dGhyb3R0bGluZyB0aGUgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+W0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVx
dWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4g
SG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9M
UiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBp
bXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgd2UgaGFkIGRpc2N1
c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8g
ZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBz
YW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRo
ZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRo
ZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5bTE1dIEFncmVlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPlRoZXJlIG1heSBiZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBs
b25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5j
bHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+W0xNXSBBZ3JlZTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5SZXN0IG9mIHRoZSBwcmluY2lwbGVz
IGJlbG93IGFyZSBmaW5lIHdpdGggbWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbPGEgaHJl
Zj0ibWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86dWxyaWNoLndpZWhlQG5zbi5j
b208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2Vu
dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE08bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYg
U2Fsb3QgKG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYu
b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3Vi
amVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFjdHVhbGx5IHdlIHNl
ZW0gdG8gYWdyZWUgb24gdHdvIHByaW5jaXBsZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj4xLiBMYWNrIG9mIE9MUiBtZWFucyAmcXVvdDtubyBjaGFuZ2Um
cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjIuIHRo
ZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1B
WSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hp
Y2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0
aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hp
Y2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBp
bmRpY2F0aW5nICZxdW90O25vIG92ZXJsb2FkJnF1b3Q7KTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0
IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBv
dmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1
ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DYW4gcGVvcGxlIHBsZWFzZSBjb25m
aXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5VbHJpY2g8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogRGlNRSBbPGEgaHJl
Zj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw
NSwgMjAxNCA0OjM1IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5UbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYu
b3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PkFncmVlZC4mbmJzcDsgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBk
b2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUgZm9yIHRoZSBob3N0IG9y
IHJlYWxtLiZuYnNwOyBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVw
b3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBvdXQg
b3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LiZuYnNw
OyBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxh
Y2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9y
IHRoZSBob3N0IGFuZCByZWFsbS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+U3RldmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
Pk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZTo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgYWdyZWUgd2l0aCBTdGV2ZSBl
eGNlcHQgdGhlIHBhcnQgJnF1b3Q7c2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0
ZWQgYXMgbm90IG92ZXJsb2FkZWQ/JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhv
dWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBp
bmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2Vy
dmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBh
bmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1
bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2Ft
ZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TbyBiYXNpY2FsbHks
IHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZl
ZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51
ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFs
aWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICZxdW90OzAmcXVvdDsg
b3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+SW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGlt
cGxlbWVudGF0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2Yg
T0xSIGF0IHRoZSByZWFjdGluZyBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3Zhbjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogV2VkbmVz
ZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRp
bWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+aW5saW5l
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PbiAyLzUvMTQg
Nzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZTo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9rIHRoZW4gbGV0J3Mgc3RhdGUg
dGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5z
d2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNv
bnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVk
dWN0aW9uIGlzIHJlcXVlc3RlZCkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5TUkQmZ3Q7IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT8mbmJzcDsgU2hv
dWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9y
IFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPlNSRCZndDsgUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBp
biBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBh
biBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdv
cmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5nIE9MUnMuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRo
YXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2lu
Z2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3Vs
ZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmlt
aXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5p
bWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TUkQmZ3Q7IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhl
IHNlcXVlbmNlIG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fs
b3QgKG5zYWxvdCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IDxhIGhyZWY9Im1haWx0bzpsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhy
ZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IERp
TUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogVHVlc2RheSwgRmVicnVh
cnkgMDQsIDIwMTQgOTowNyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3Jn
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVj
dDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgdW5kZXJzdGFuZCB0aGF0
IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5z
ZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPlNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+MS0gT0MtT0xSIEFWUCBpbiBldmVyeSBh
bnN3ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjItIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICYjNDM7IE9DLU9M
UiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1l
ZCBieSB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhl
IG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5MaW9uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5EZSZuYnNwOzogZGltZSBpc3N1ZSB0cmFja2Vy
IFs8YSBocmVmPSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnIj5tYWls
dG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkVudm95w6kmbmJzcDs6IG1hcmRpIDQgZsOp
dnJpZXIgMjAxNCAwOTo0OTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+w4AmbmJzcDs6IE1PUkFORCBMaW9uZWwgSU1UL09MTjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpkaW1l
QGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+T2JqZXQmbmJzcDs6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMmbmJzcDsgdG8gYmUgaW5jbHVkZWQg
YnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0Jm5i
c3A7IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhlIFNl
cXVlbmNlLU51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+IChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRs
aW5nICh3aGljaCB3YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRl
cyB0aGF0IGN1cnJlbnRseSBubyZuYnNwOyB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4mbmJzcDsg
UmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhpcyZuYnNwOyBpbmZvcm1hdGlvbiBp
biBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZSZu
YnNwOyByZWFjdGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gQWJzZW5jZSBvZiB0aGlzIGZl
ZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSZuYnNwOyBy
ZXBvcnRpbmcgbm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUg
cmVwb3J0aW5nIERPSUMmbmJzcDsgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVh
Y3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyZuYnNwOyB0aGUgcmlnaHQgdGhp
bmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNt
IGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNw
OyBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5n
IGJ5IHRoZSByZWFjdGluZyZuYnNwOyBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIg
cmVhc29uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBU
aGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20g
UkZDIDcwNjguPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4g
SW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCB0byZuYnNwOyBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Im1haWx0
bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBl
dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv
bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJl
IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz
IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEg
bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu
IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp
b24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl
dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg
bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt
YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls
IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi
bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp
ZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5r
IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBp
ZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBp
ZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBp
ZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBp
ZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p
ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg
ZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv
bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz
aWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSBs
J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g
TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv
biw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBk
ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk
ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g
Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj
dGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh
dXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMg
bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh
dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_087A34937E64E74E848732CFF8354B9209772E88ESESSMB101erics_--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:24:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF58A1A0957 for ; Tue, 11 Feb 2014 02:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma4j3pbIFIAT for ; Tue, 11 Feb 2014 02:24:51 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 58D501A093E for ; Tue, 11 Feb 2014 02:24:50 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-e4-52f9fa71774f
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.81.23809.17AF9F25; Tue, 11 Feb 2014 11:24:50 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:24:49 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #46: Bad normative advice on not letting overload	reports expire
Thread-Index: AQHPJlGIdoxp4ZPGNkCdpdO55KBqgpqvEP0AgADIhpCAAACxkA==
Date: Tue, 11 Feb 2014 10:24:49 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvjW7Rr59BBh/bBSzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxutVO9kKOoQqemb2MzUw/uLrYuTkkBAwkXjd/IgZwhaTuHBv PVsXIxeHkMAhRomXG+YyQzhLGCV+bj3JCFLFJmAncen0C6YuRg4OEQENiRUnMkHCwgKxEnfP zGEDsUUE4iQef9rPCmE7Sbx/spkJxGYRUJW4tOgL2BheAV+JzrMdYIuFBD4ySuxdLA9icwLF l7y4ClbDCHTQ91NrwHqZBcQlbj2ZzwRxqIDEkj3noY4WlXj5+B8rhK0ksej2Z6h6HYkFuz+x QdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGJkz03MzEkvN9rECAz7g1t+ q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYGR0lF9adUEny ZPHlT9+x8lcKo7WDksz3NkfRNztb8tVz/RZLa/y4YXz/fEWdnBhPU7j1Oj0ZthUGDEftbVac agtPv8mnkVa17AfflOVvdxzOu1lzj0Vgc4+PtbiG6AWn8kkMj1y445bvtdEsz3P55fnzkPxi D5uoywc3hyXZlDfZzv9udUCJpTgj0VCLuag4EQDvuWr7SQIAAA==
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload	reports expire
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:24:54 -0000

Ben, Nirav,

I follow same argumentation.
Regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: martes, 11 de febrero de 2014 11:23
To: Ben Campbell; Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overloa=
d reports expire

Ben,

I resonate with your thinking below.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, February 10, 2014 9:54 PM
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overloa=
d reports expire


On Feb 10, 2014, at 5:16 AM, Jouni Korhonen  wrote:

>=20
> My reasoning for explicit termination was that knowing the=20
> implementation folks they will let overload conditions expire unless advi=
sed otherwise.
> And having unnecessary stuff hanging around waiting for a cleanup is=20
> not a good thing in general. But I am open here for other options..
>=20

I think it's reasonable to say that a reporting node should terminate an ov=
erload condition in a timely manner. But if it's about to expire anyway, th=
en expiration might be just as timely as an explicit report.=20

And of course, the definition of "timely" is somewhat a matter of policy. F=
or example, I can imagine an deployment that had a large number of clients =
using fairly short validity durations, and _never_ explicitly signaling an =
end to an overload condition. This adds a bit of a "slow-start" to the reco=
very, since different clients will expire the overload condition at differe=
nt times, and the load will ramp up gradually. I don't see anything wrong w=
ith that. Of course, it wouldn't work if one chose long validity durations,=
 or if the signaling of overload to different clients happened in close syn=
chronization.

_______________________________________________
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 nsalot@cisco.com  Tue Feb 11 02:25:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0861A093E for ; Tue, 11 Feb 2014 02:25:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcfQzEPBQnPb for ; Tue, 11 Feb 2014 02:25:41 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2B1A06BC for ; Tue, 11 Feb 2014 02:25:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=114040; q=dns/txt; s=iport; t=1392114340; x=1393323940; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ggTKWhARe8TS2yAmu+vjCwDnnTgdqOVNiiim2AlMbww=; b=BlX5wUPZd1S2snb6S29x+mqu9kf61WsjHWyzTVpK1sjAKw6ofD4XH4Ys WMHWYatO6d/CyU7576hxFpRSPALMXJRGRHvlA3wlPVOYgcx8T3xSbmB/Z aC71piKAsY5AXud9YC2n0EqWHC+YRzJOmAl84Xao+fpCLr2ZwMFXK3OOj o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAJ35+VKtJXHB/2dsb2JhbABZgkpEOFWDA7lNGHYWAXSDfQEBAQQBAQELDAEICjgJFwQCAQgRBAEBCwsLAQIEAwICAiULFAkIAgQBEggTh2kNqBqZQhMEjjARAR8WFwoBBgSCZDWBEwSTcUKOPIc7gW2BPoFoBwIXIg
X-IronPort-AV: E=Sophos;i="4.95,825,1384300800";  d="scan'208,217";a="300230644"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 11 Feb 2014 10:25:39 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1BAPcxw025084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:25:38 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 04:25:38 -0600
From: "Nirav Salot (nsalot)" 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//PffggAHqb4CAAGRIIA==
Date: Tue, 11 Feb 2014 10:25:38 +0000
Message-ID: 
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.140.48]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D697CAxmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:25:49 -0000

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

SSBkbyBub3QgYWdyZWUgcmVnYXJkaW5nIHRoZSBjb21wbGV4aXR5IHNpbmNlIGl0IGlzIGhpZ2hs
eSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCkxldHMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24g
aW4gdGhlIHByb3RvY29sIGRlc2lnbi4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBEaU1F
IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBC
YXJ0b2xvbWUNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDM6NTQgUE0NClRvOiBk
aW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KSGVsbG8sDQoNCkkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRv
IGhpZ2hsaWdodCBjb21wbGV4aXR5IGZvciB0aGUgc2VydmVyIHRvICDigJxndWFyYW50ZWUgdGhh
dCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVw
b3J0LuKAnQ0KSSB0aGluayB0aGlzIGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRl
ZCBieSBTdGV2ZS4NCg0KQ2hlZXJzDQovTUNydXoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50
OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyMA0KVG86IGxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgU3RldmUgRG9ub3Zh
bjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJIGFtIGFsc28g
ZmluZSB3aXRoIFN0ZXZlJ3MgcHJvcG9zZWQgd29yZGluZyB0byByZWNvbW1lbmQgdGhlIGluY2x1
c2lvbiBvZiBPTFIgYnV0IHRvIG5vdCBtYW5kYXRlIGl0Lg0KDQpJIGFtIG5vdCBzdXJlIGFib3V0
IHRoZSBmb2xsb3dpbmcgdGV4dCwgaWYgaXQgaXMgYWJzb2x1dGVseSBuZWNlc3NhcnkgdG8gYWRk
IGl0Lg0KTm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hh
bmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJs
b2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVy
ZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcgbm9kZS4N
Cg0KSSBwcmVmZXIgdG8gcmVtb3ZlIGl0IHNpbmNlIEkgZG8gbm90IHNlZSBhcyB2YWx1ZSBhZGRp
dGlvbi4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0
bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAy
MDE0IDEwOjEzIFBNDQpUbzogU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGlt
ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P
bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp
dmVkIGEgdGhyb3R0bGluZw0KDQpJJ20gZmluZSB3aXRoIGEgcmVjb21tZW5kYXRpb24uDQoNCkJ1
dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1lbnQ6IHdoZW4gYSBNQVkgb3IgZXZlbiBhIFNIT1VMRCBh
cHBseSwgaXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIE5PVCB1cCB0byB0aGUgbm9kZSB0byBk
byBvciBub3QgdG8gZG8gc29tZXRoaW5nLiBJdCBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgb25s
eSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRpb24uDQpGb3IgaW5zdGFuY2UsIG92ZXIgYSBnaXZlbiBp
bnRlcmZhY2UsIHRoZSByZWxhdGVkIHNwZWNpZmljYXRpb24gY2FuIHNheSB0aGF0IHNvbWUgc3Rh
dGVzIGFyZSBtYWludGFpbmVkIGJ5IHRoZSBzZXJ2ZXIuIEFuZCBpdCBjb3VsZCBiZSBkZWNpZGVk
IHRvIGFkZCBzb21lIG92ZXJsb2FkIHJlbGF0ZWQgaW5mbyBpbiBzdWNoIHN0YXRlcy4gRm9yIGlu
c3RhbmNlIGFnYWluLCB0aGUgbm9kZSBjYW4gdXNlIHRoaXMgc3RhdGUgdG8ga25vdyBpZiBhIHJl
bW90ZSBub2RlIGhhdmUgYmVlbiBub3RpZmllZCBvciBub3QgZm9yIGluc3RhbmNlLiBBbmQgaW4g
c3VjaCBhIGNhc2UsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBpbmNsdWRlIGFuIE9MUiBp
biBlYWNoIG1lc3NhZ2UuIEl0IGlzIGp1c3QgZm9yIGlsbHVzdHJhdGlvbi4gVGhlIHBvaW50IGlz
IHRoYXQgeW91IG1heSBoYXZlIHNvbWUgY2FzZXMgZm9yIHdoaWNoIHRoZSBPTFIgaW4gZXZlcnkg
YW5zd2VyIG1pZ2h0IG5vdCBiZSByZXF1aXJlZC4NCg0KSSBhZ3JlZSB0aGF0IGhhdmluZyB0aGUg
T0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l4oCmIGJ1dCBpdCBzaG91bGQgYmUgbm90IG1hbmRh
dG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4gU28gT0sgZm9yIGEgIlNIT1VMRCIgb3IgIlJFQ09N
TUVOREVEIi4NCg0KUmVnYXJkcywNCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2ZSBEb25vdmFuDQpFbnZvecOpIDog
bHVuZGkgMTAgZsOpdnJpZXIgMjAxNCAxNzoyMQ0Kw4AgOiBkaW1lQGlldGYub3JnPG1haWx0bzpk
aW1lQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KSSBhZ3JlZSB3aXRoIGJvdGggTWFyaWEgQ3J1eiBhbmQgTmly
YXYuIDotKQ0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBoYXZlIHdvcmRpbmcgc2F5aW5nIHRoZSByZWNv
bW1lbmRlZCBhcHByb2FjaCBpcyB0byBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYWxs
IHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQgYnkgTWFyaWEgQ3J1ei4N
Cg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBpbmNsdWRlIE5pcmF2J3MgcHJvcG9zYWwgdGhhdCBp
ZiBhIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5
IHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IG1heSBjaG9vc2UgdG8gbm90IHNl
bmQgaXQgYWdhaW4uICBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gaW5jbHVkaW5nIGFueXRoaW5n
IGFib3V0IGhvdyB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgYnV0IHdlIHNob3VsZCBpbmNsdWRl
IHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmlj
dWx0IHRvIGtub3cuICBUaGUgY2FzZSBvZiBhZ2VudHMgYWN0aW5nIGFzIHJlYWN0aW5nIG5vZGVz
IGZvciBub24gc3VwcG9ydGluZyBjbGllbnRzIGJlaW5nIG9uZSBleGFtcGxlLg0KDQpXZSBhbHNv
IG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIG5vdCBw
cmVjbHVkZWQgYnkgTmlyYXYncyBwcm9wb3NhbC4NCg0KSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcg
bm9ybWF0aXZlIHdvcmRpbmcsIHdoaWNoIGNhbiBiZSBzdXBwbGVtZW50ZWQgYnkgTWFyaWEgQ3J1
eidzIHJlYXNvbnMgZm9yIHJlY29tbWVuZGluZyB0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQgaXMg
YWx3YXlzIGluY2x1ZGVkLg0KDQotLS0tLQ0KDQpBIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJl
IHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuDQoN
Ckl0IGlzIHJlY29tbWVuZGVkIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2Fk
IHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIHJlYWN0aW5nIG5vZGVzLg0K
DQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2Fk
IHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYg
dGhhdCBpcyBtb3JlIGVmZmljaWVudC4gIFRoZSBvdmVybG9hZCByZXBvcnQgd2lsbCBqdXN0IGJl
IGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBET0lDLg0K
DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVw
b3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0KTm90
ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRv
IGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9y
dCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBh
Z2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcgbm9kZS4NCk9uIDIvMTAv
MTQgMzo1MiBBTSwgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgd3JvdGU6DQoNCkhlbGxvIE5pcmF2LA0K
DQoNCg0KQW55IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZp
Y2llbmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1
dCBmaXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBp
cyBwcm92aWRpbmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLg0KDQoNCg0KWW91ciBwcm9w
b3NlZCB0ZXh0DQoNCiIgQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRo
ZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBh
bHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUg
bWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRh
aW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINCg0KDQoNCklmIHRoZSByZXBvcnRpbmcg
aXMgbm90IGF3YXJlIGFib3V0IHdoZXRoZXIgb3Igbm90IG92ZXJsb2FkIHJlcG9ydCBpcyBwcm92
aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgYW5kIGl0IGRlY2lkZXMgKHNpbmNlIGl0IGlzIGEg
Im1heSIpIHRvIGRvIG5vdCBzZW5kIHRoZSBPTFIgYWdhaW4sIHRoZW4gb3ZlcmxvYWQgbWl0aWdh
dGlvbiBtZWNoYW5pc20gd2lsbCBub3Qgd29yayBpbiBjYXNlIE9MUiB3YXMgbm90IHByb3Blcmx5
IHJlY2VpdmVkIGJ5IGNvcnJlc3BvbmRpbmcgcG90ZW50aWFsIHJlYWN0aW5nIG5vZGVzLiBBbmQg
d2UgbmVlZCB0byBub3RlIHRoYXQgInJlYWN0aW5nIG5vZGVzIiBjb3VsZCBiZSBub3Qgb25seSB0
aGUgY2xpZW50LCBidXQgQU5ZIGFnZW50IHVzZWQgZm9yIHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4g
dGhlIGFnZW50IGlzIHByb3ZpZGluZyBzZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlz
IHJlYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkuDQoNClRoZW4s
IG9uIG9uZSBoYW5kIGl0IGlzIG5vdCBzaW1wbGUgdG8ga25vdyB3aGVuIHJlYWN0aW5nIG5vZGVz
IGhhdmUgdmFsaWQgT0xSIGluZm8gKGFzIGV4cGxhaW5lZCBiZWxvdyksIGJ1dCBpZiBPTFIgaXMg
bm90IHNlbnQgYWdhaW4gKGFzIHBlciB5b3VyIHByb3Bvc2VkICJtYXkiKSB0aGVuIG9uZSBvciBt
dWx0aXBsZSByZWFjdGluZyBub2RlcyBkbyBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVu
IG92ZXJsb2FkIG1pdGlnYXRpb24gd2lsbCBub3Qgd29yay4NCg0KDQoNClRoZXJlZm9yZSwgaW4g
bXkgb3BpbmlvbiwgdGhlIHNpbXBsZXN0IHdheSB0byBwcm92aWRlIHJlcXVpcmVkIGluZm9ybWF0
aW9uIGlzIHRvIHByb3ZpZGUgT0xSIGluIEFMTCBhbnN3ZXJzLg0KDQoNCg0KQmVzdCByZWdhcmRz
DQoNCi9NQ3J1eg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogTmly
YXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KDQpTZW50OiBsdW5l
cywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyDQoNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9t
ZTsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpCdXQg
TWFyaWEtQ3J1eiwNCg0KDQoNCkhvdyBjYW4gd2Ugc2F5IHRoYXQgImluY2x1ZGluZyB0aGUgT0xS
IGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZmaWNpZW50PyINCg0K
SXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1dCBub3QgZWZmaWNpZW50Lg0KDQoNCg0KQSBzbGlnaHRs
eSBkaWZmZXJlbnQgd29yZGluZyBmcm9tIHdoYXQgSSBwcm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVu
IHRoZSByZXBvcnRpbmcgbm9kZSBoYXMgYSBuZXcgb3ZlcmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMg
dG8gYmUgcHJvdmlkZWQgdG8gYSByZWFjdGluZyBub2RlIChieSB1cGRhdGluZyB0aGUgZWFybGll
ciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgb3IgYnkgcHJvdmlkaW5nIHRoZSBvdmVybG9hZCBy
ZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJl
c3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFW
UCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHks
IGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2Fy
ZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0
aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBy
ZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBB
VlAuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEw
LCAyMDE0IDM6MDMgUE0NCg0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KTmlyYXYsIGFsbCwNCg0KDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGRlZmlu
ZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0IHNvbHV0aW9uLCBhcyBlZmZpY2llbnQgYW5kIHNpbXBs
ZSBhcyBwb3NzaWJsZS4NCg0KSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwgYXMgYSBwdXJlICJt
YXkiLCBidXQgbGVhdmluZyBpdCB1cCB0byBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBhc3N1cmUg
cmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQgT0xSIGluZm9ybWF0aW9uLCB3aGF0IGlzIGJhc2ljIGZv
ciB0aGlzIG1lY2hhbmlzbSB0byB3b3JrLg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCi9NQ3J1eg0K
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5z
YWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KDQpTZW50OiBsdW5lcywgMTAgZGUgZmVi
cmVybyBkZSAyMDE0IDEwOjEyDQoNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRm
Lm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpNYXJpYS1DcnV6LA0KDQoN
Cg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSBvbiAic2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMg
aGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMiLg0KDQpBbmQgd2UgYXJlIG5vdCB0cnlpbmcg
dG8gcHJldmVudCBpdCAtIGF0IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9uLg0KDQpCdXQgdGhl
IG1haW4gcXVlc3Rpb24gaXMsIGFyZSB3ZSB0cnlpbmcgdG8gcHJldmVudCBhbnkgb3RoZXIgcG9z
c2libGUgaW1wbGVtZW50YXRpb24sIHdoaWNoIG1heSBiZSBzbWFydGVyIGFuZCBjYW4gYXZvaWQg
aW5jbHVkaW5nIHJlZHVuZGFudCBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZT8NCg0KDQoN
Ck1vc3QgcHJvYmFibHksIHRoZSB2ZXJ5IGZpcnN0IGltcGxlbWVudGF0aW9uIG9mIG92ZXJsb2Fk
IGNvbnRyb2wgd2lsbCBpbmNsdWRlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcy4NCg0K
QnV0IGF0IHRoZSBzYW1lIHRpbWUsIEkgZG8gbm90IHdhbnQgdG8gcmVzdHJpY3QgdGhlIGRldmVs
b3BlcnMgd2hpY2ggY2FuIGNvbWUgdXAgd2l0aCBzb21lIG5pY2UgdHdlYWtzIGFuZCB0cmlja3Mg
dG8gYXZvaWQgc2VuZGluZyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBldmVyeSBtZXNzYWdlLiBB
bmQgdGhpcyBpcyB3aGVyZSB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYW5kIGF2b2lkIHB1dHRpbmcg
c3VjaCByZXN0cmljdGlvbnMgaW4gcHJvdG9jb2wgZGVmaW5pdGlvbi4NCg0KV2hhdCBkbyB5b3Ug
dGhpbms/DQoNCg0KDQpUaGlzIGFsc28gdGhlIHJlYXNvbiBJIHdhcyBzdWdnZXN0aW5nIGxvb3Nl
IGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVkZSBPTFIgKGZyb20gdGhlIHJlcG9ydGluZyBu
b2RlIHBvaW50IG9mIHZpZXcpLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNCg0KU2VudDogRnJp
ZGF5LCBGZWJydWFyeSAwNywgMjAxNCA4OjU3IFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0
bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkhlbGxvIFVscmljaCwgTmlyYXYsDQoNCg0K
DQpJIGFncmVlIHdpdGggVWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMg
anVzdCBhIE1BWSwgYW5kIHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGlu
IGFsbCBhbnN3ZXJzIHNoYWxsIG5vdCBiZSBqdXN0IGEgTUFZLg0KDQoNCg0KT24gdGhlIG90aGVy
IGhhbmQsIGNyaXRlcmlhIHByb3ZpZGVkIGJ5IFVscmljaCBvbiB3aGVuIE9MUiBoYXMgdG8gYmUg
c2VudCByZXF1aXJlcyB0aGUgc2VydmVyIGhhcyBzb21lIGtub3dsZWRnZToNCg0KYSkgdGhlIHJl
cG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290
IHRoZSBsYXRlc3QgT0xSDQoNCmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRl
ZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJl
YWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlDQoNCmMpIG90
aGVyd2lzZQ0KDQoNCg0KUmVwb3J0aW5nIG5vZGUgbXVzdCBoYXZlIHNvbWUga25vd2xlZGdlIGFi
b3V0IE9MUiByZWNlcHRpb24vc3RhdHVzIGluIHJlYWN0aW5nIG5vZGUuIEhvdyBkb2VzIHNlcnZl
ciBhY3F1aXJlIHRoaXMga25vd2xlZGdlPw0KDQpUYWtlIGludG8gYWNjb3VudCBhcyB3ZWxsIHRo
YXQgYSAicmVhY3RpbmciIG5vZGUgbWF5IGJlIGJvdGggYW4gQWdlbnQgKGluIGNhc2UgaXQgcHJv
dmlkZXMgc2VydmljZSB0byBhIHJlYWxtIG9yIGFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3Vw
cG9ydGluZyBjbGllbnQpICBhbmQgYSBDbGllbnQuIEluIHRoZSBjYXNlIG9mIEFnZW50cywgaW4g
ZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBrbm93IGlmIHRoaXMgaXMgZ29pbmcgdG8gYWN0
IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRyYW5zcGFyZW50bHksIGluIGZhY3QsIHRoZSBz
ZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFueSBrbm93bGVkZ2UgYWJvdXQgd2hhdCBhZ2Vu
dHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBDbGllbnQuDQoNCg0KDQpUaGVyZWZvcmUsIEkg
ZGVmaW5pdGVseSB0aGluayB0aGF0IHNlbmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21l
IGltcG9ydGFudCBhZHZhbnRhZ2VzOg0KDQotIHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRy
YW5zYWN0aW9uIG9yIHNlc3Npb24pIGlzIHNpbXBsZXIsDQoNCi0gdGhlIHNlcnZlciBkb2VzIG5v
dCBuZWVkIHRvIGRldGVybWluZSB3aGV0aGVyIG9yIG5vdCB0byBzZW5kIGFuIE9MIHRvIGEgcmVh
Y3Rpbmcgbm9kZQ0KDQotIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBib3RoZXIgd2hldGhl
ciBhbiByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBvciB3aGV0aGVy
IHRoaXMgT0xSIGlzIHN0aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLg0KDQotIHNlbmRpbmcg
YW4gYWRkaXRpb25hbCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJp
c29uIHdpdGggcmVxdWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4NCg0K
ICBJbiBmYWN0LCBpbiBhbiBvdmVybG9hZCBzaXR1YXRpb24sIHRoZSBlYXNpZXN0IGFuZCBsZWFz
dCBjb21wbGV4IGlzIHRvIHNlbmQgaW5mb3JtYXRpb24gb3V0IHRvIGFsbCBhZmZlY3RlZC9hcHBs
aWNhYmxlIG5vZGVzLA0KDQogIGFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNhcmUgdG8gdGFr
ZSBhcHByb3ByaWF0ZSBhY3Rpb25zDQoNCi0gbW9yZSByb2J1c3Qgc29sdXRpb24sIGFzIG5vIG5l
ZWQgdG8gY2F0ZXIgZm9yIGFsbCB0aGUgY2hlY2tzIG9uIHRoZSBuZWVkIHRvIHNlbmQgaW5mb3Jt
YXRpb24sICBmb3Igc2l0dWF0aW9ucyB3aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCAg
4oCmDQoNCg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCi9NQ3J1eg0KDQoNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkNCg0KU2VudDog
dmllcm5lcywgMDcgZGUgZmVicmVybyBkZSAyMDE0IDEwOjU5DQoNClRvOiBleHQgTmlyYXYgU2Fs
b3QgKG5zYWxvdCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbT47IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0
bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk5pcmF2LA0KDQoNCg0KSSdtIGFmcmFpZCB5
b3VyIHByb3Bvc2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGUgaW50ZW50aW9uLg0KDQoNCg0K
IndoZW4gaXQgd2FudHMgdG8gcHJvdmlkZS91cGRhdGUuLi4uaXQgc2hhbGwgaW5jbHVkZS4uLiIg
dHJhbnNsYXRlcyB0byAiLi4uaXQgbWF5IGluY2x1ZGUuLi4iLg0KDQoNCg0KImluIG90aGVyIGNh
c2VzIiBpbiB0aGUgZ2l2ZW4gY29udGV4dCB0cmFuc2xhdGVzIHRvICJ3aGVuIGl0IGRvZXMgbm90
IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUuLi4iDQoNCg0KDQoNCg0KV2UgaGF2ZSB0aGUgZm9sbG93
aW5nIGNhc2VzOg0KDQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rp
bmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCg0KYikgdGhlIHJlcG9ydGlu
ZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5n
KSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdp
bGwgc29vbiBleHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoNCg0KDQppbiBjYXNlIGEpIHRoZSByZXBv
cnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCByZXBsYXkgdGhlIE9MUiBpbiBjYXNlIGIpIHRoZSBy
ZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCB1cGRkYXRlIHRoZSByZWFjdGluZyBub2RlIHdp
dGggdGhlIGxhdGVzdCBPTFIgaW4gY2FzZSBjKSB0aGUgcmVwb3J0aW5nIG5vZGUgTVVTVCBpbmNs
dWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9ydGluZyBub2RlIGRvZXMgbm90IGtu
b3cgd2hldGhlciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0ZSkNCg0KDQoNClVscmljaA0K
DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IGV4dCBOaXJhdiBT
YWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IFRodXJzZGF5
LCBGZWJydWFyeSAwNiwgMjAxNCA0OjQ5IFBNDQoNClRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9y
YW5kQG9yYW5nZS5jb20+OyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpVbHJpY2gsDQoNCg0KDQpJdCBzZWVtcyB3ZSBh
bGwgYXJlIG9uIHNhbWUgcGFnZSBidXQgcHJvYmFibHkgdGhlIHByb3Bvc2VkIHdvcmRpbmcgYmVs
b3cgaXMgbm90IHRoZSBiZXN0Lg0KDQpIb3cgYWJvdXQgdGhlIGZvbGxvd2luZy4NCg0KDQoNCldo
ZW4gdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUgbmV3IG92ZXJsb2FkIHJlcG9y
dCBvciB3YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVwb3J0
IHRvd2FyZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVz
cG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQ
LCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwg
aW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJl
IGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rp
bmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJl
c3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFW
UC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCg0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVs
cmljaC53aWVoZUBuc24uY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQg
Mzo1NyBQTQ0KDQpUbzogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tPjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25v
dmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk5p
cmF2LCBMaW9uZWwsDQoNCg0KDQpJIGNhbiB1bmRlcnN0YW5kIE5pcmF2J3MgY29uY2VybiAoYWx0
aG91Z2ggdmlvbGF0aW5nIFJFUTEwKSBhbmQgaG9wIGl0IGlzIGFkZHJlc3NlZCBieSB0aGUgbW9k
aWZpZWQgcHJpbmNpcGxlIDInOg0KDQoNCg0KMicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0
dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBh
biBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFs
cmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUu
Zy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmlj
IHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiLCBvciBhbiBvbGQg
IGJ1dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3Zl
cmxvYWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBv
cnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0
dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNCkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxz
IGRvLXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29y
ayB3aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5n
IG5vZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50
IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRlIE9MUnMuDQoNCg0KDQpVbHJpY2gNCg0K
DQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogZXh0IGxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiBbbWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5
IDA2LCAyMDE0IDEwOjIwIEFNDQoNClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgV2llaGUsIFVs
cmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8
bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KDQoNCg0KDQotLS0tLU1lc3NhZ2Ug
ZCdvcmlnaW5lLS0tLS0NCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95w6kgOiBqZXVkaSA2IGbD
qXZyaWVyIDIwMTQgMTA6MDggw4AgOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBl
eHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4gT2Jq
ZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN
Cg0KDQoNClVscmljaCwNCg0KDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgZm9yY2luZyB0aGlzIGJl
aGF2aW9yIG9uIHJlcG9ydGluZyBub2RlICJvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3
YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQg
b3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNo
IGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KDQpUaGUgcmVwb3J0aW5n
IG5vZGUgbWF5IHNpbXBseSBub3QgaW5jbHVkZSBPTFIgYXNzdW1pbmcgdGhhdCB0aGUgZWFybGll
ciBwcm92aWRlZCBPTFIgd2lsbCBleHBpcmUgYW5kIHRoZSByZWFjdGluZyBub2RlIHdpbGwgc3Rv
cCB0aHJvdHRsaW5nIHRoZSB0cmFmZmljLg0KDQoNCg0KW0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29y
ZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBk
ZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBk
ZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhl
IGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15
IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4NCg0KDQoNCkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGll
ciwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkg
c3RvcCB0aHJvdHRsaW5nIGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJ
biBvdGhlciB3b3JkcywgdGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBl
eHBpcnkgb2YgdGhlIE9MUiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5n
IHRyYWZmaWMgdG93YXJkcyBpdC4NCg0KDQoNCltMTV0gQWdyZWUNCg0KDQoNClRoZXJlIG1heSBi
ZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRo
ZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFz
dCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRo
ZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi4NCg0KDQoNCltMTV0gQWdyZWUNCg0KDQoNClJl
c3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVsb3cgYXJlIGZpbmUgd2l0aCBtZS4NCg0KDQoNCltMTV0g
QWdyZWUNCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCg0KRnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRv
OnVscmljaC53aWVoZUBuc24uY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIw
MTQgMjoyMyBQTQ0KDQpUbzogZXh0IFN0ZXZlIERvbm92YW47IE5pcmF2IFNhbG90IChuc2Fsb3Qp
OyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkFjdHVh
bGx5IHdlIHNlZW0gdG8gYWdyZWUgb24gdHdvIHByaW5jaXBsZXM6DQoNCjEuIExhY2sgb2YgT0xS
IG1lYW5zICJubyBjaGFuZ2UiDQoNCjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdo
ZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIg
aW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkg
aGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRy
YWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIpOyBvdGhl
cndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5v
IG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4g
cmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVh
dHVyZSBBVlAuDQoNCg0KDQpDYW4gcGVvcGxlIHBsZWFzZSBjb25maXJtLg0KDQoNCg0KVWxyaWNo
DQoNCg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwg
MjAxNCA0OjM1IFBNDQoNClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZzxt
YWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpBZ3JlZWQuICBUbyByZXN0YXRlIC0t
IGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBv
dmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhvc3Qgb3IgcmVhbG0uICBJZiB0aGVyZSBpcyBhIGN1cnJl
bnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVu
dGlsIGl0IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBu
ZXcgb3ZlcmxvYWQgcmVwb3J0LiAgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5IGFjdGl2ZSBvdmVy
bG9hZCByZXBvcnQgdGhlbiBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBpbXBsaWVzIHRoZXJl
IGlzIG5vIG92ZXJsb2FkIGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uDQoNCg0KDQpTdGV2ZQ0KDQpP
biAyLzUvMTQgOToxOSBBTSwgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6DQoNCkkgYWdyZWUg
d2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQgInNob3VsZG7igJl0IGxhY2sgb2YgT0xSIGJlIGlu
dGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPyINCg0KDQoNCldlIGhhZCBzb21lIGRpc2N1c3Np
b24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90
IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1l
c3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBp
cyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBp
bmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxl
bWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJv
bSBwcm90b2NvbCBwb2ludCBvZiB2aWV3Lg0KDQoNCg0KU28gYmFzaWNhbGx5LCB0aGUgbGFjayBv
ZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRo
ZSByZWFjdGluZyBub2RlLiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3Qg
YmFzZWQgb24gb2xkZXIgT0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlv
ZCBvciB3aGVuIHRoZSBleHBsaWNpdCBPTFIgd2l0aCAiMCIgb3ZlcmxvYWQtbWV0cmljIGlzIHJl
Y2VpdmVkLg0KDQpJbiBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3IgZmxleGlibGUgaW1wbGVtZW50
YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBoYW5kbGluZyBvZiBPTFIgYXQg
dGhlIHJlYWN0aW5nIG5vZGUuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCkZyb206
IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBE
b25vdmFuDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODowMCBQTQ0KDQpU
bzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQppbmxp
bmUNCg0KT24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkg
d3JvdGU6DQoNCk9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBp
bnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9u
ZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1
cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlzIHJlcXVlc3RlZCkuDQoNClNS
RD4gV2h5IGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlPyAgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xS
IGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCg0KDQoNCg0KDQoNCg0KT3Ro
ZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQoN
ClNSRD4gUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBk
aXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8g
bG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3Nh
Z2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUg
ZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5nIE9MUnMuDQoNCg0KDQoNCg0KDQoNCg0KDQpGb3IgbXkg
Y2xhcmlmaWNhdGlvbjogSSBndWVzcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGlzIG5vdCByZXF1
aXJlZCB0byBwcm9jZXNzIGV2ZXJ5IHNpbmdsZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2lsbCBiZSBy
ZXBsYXlzIGFueXdheSkuIFdoYXQgd291bGQgYmUgdGhlIHByb2NlZHVyZSBpbiB0aGUgcmVhY3Rp
bmcgbm9kZSBpbiBvcmRlciB0byBtaW5pbWl6ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVkIE9MUnMg
YW5kIGF0IHRoZSBzYW1lIHRpbWUgbWluaW1pemUgdGhlIHJpc2sgdG9vIG1pc3MgYSBuZXcgT0xS
Pw0KDQpTUkQ+IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJlci4NCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBE
aU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2
IFNhbG90IChuc2Fsb3QpDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToy
NyBBTQ0KDQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5k
QG9yYW5nZS5jb20+OyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJq
ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN
Cg0KDQoNCkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuDQoNCg0KDQpSZWdhcmRz
LA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERp
TUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9y
YW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4NCg0KU2VudDog
VHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxt
YWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUg
cmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIERPRVMgTk9UIGluc2VydCB0
aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4NCg0KU28gdGhlIG9wdGlvbnMgd291bGQgYmU6DQoNCjEt
IE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyDQoNCjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVu
IHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8g
YmUgdXBkYXRlZC4NCg0KDQoNCklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhlIG9w
dGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KDQoNCg0KTGlvbmVsDQoNCg0KDQotLS0t
LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCg0KRGUgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21haWx0
bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10NCg0KRW52b3nDqSA6IG1hcmRpIDQgZsOp
dnJpZXIgMjAxNCAwOTo0OQ0KDQrDgCA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KDQpDYyA6IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNCk9iamV0IDogW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nDQoNCg0KDQogSXQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gZGVmaW5lIGFuIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0aGF0IGlzICB0byBiZSBpbmNsdWRlZCBieSB0
aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgIHN1cnZp
dmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51
bWJlcg0KDQogKFRpbWVTdGFtcCkgb2YgdGhlIE9MUiBhY2NvcmRpbmcgdG8gd2hpY2ggdGhlIHRo
cm90dGxpbmcgKHdoaWNoIHdhcw0KDQogc3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBv
ZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm8gIHRocm90dGxpbmcgaXMgcGVy
Zm9ybWVkLiAgUmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhpcyAgaW5mb3JtYXRp
b24gaW4gb3JkZXIgdG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0
aGUgIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0IE9MUi4NCg0KIEFic2Vu
Y2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5pc20gd291bGQgcmVzdWx0IGluIHRoZSBuZWVkIGZv
ciB0aGUgIHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkgYW5zd2Vy
IGFzIHRoZSByZXBvcnRpbmcgRE9JQyAgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUg
cmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyAgdGhlIHJpZ2h0IHRoaW5n
IHdpdGggcmVnYXJkIHRvIHRocm90dGxpbmcvbm90IHRocm90dGxpbmcuDQoNCiBUaGUgZmVlZGJh
Y2sgbWVjaGFuaXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRp
bmcgRE9JQyAgZW5kcG9pbnQgdG8gZGV0ZWN0IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhy
b3R0bGluZyBieSB0aGUgcmVhY3RpbmcgIERPSUMgZW5kcG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZl
ciByZWFzb24pLg0KDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0byBhZGRy
ZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4Lg0KDQogSW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0
byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0byAgYmUgdXNlZCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLg0KDQoNCg0KDQoN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpE
aU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0K
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu
aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l
IGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z
IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2
ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx
dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz
dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp
bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy
Y2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj
b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0
ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk
IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp
bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz
YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh
bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj
aGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0K
RGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8
bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGll
dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBt
YWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN
Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg
aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu
dCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0
b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls
bGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1
ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1
c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh
YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN
ZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu
IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl
Y3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj
b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz
IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz
IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk
LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp
ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6
MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z
b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs
b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsN
Cgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi
QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7
DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6
IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ
Y29sb3I6YmxhY2s7fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlByZm9ybWF0SFRNTCwgZGl2LlByZm9y
bWF0SFRNTA0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCW1zby1zdHls
ZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw
LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu
OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj5JIGRvIG5vdCBhZ3JlZSByZWdhcmRpbmcgdGhlIGNvbXBsZXhpdHkg
c2luY2UgaXQgaXMgaGlnaGx5IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj5MZXRzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90
b2NvbCBkZXNpZ24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl
eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k
b3d0ZXh0Ij4gRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs
ZiBPZiA8L2I+TWFyaWEgQ3J1eiBCYXJ0b2xvbWU8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg
RmVicnVhcnkgMTEsIDIwMTQgMzo1NCBQTTxicj4NCjxiPlRvOjwvYj4gZGltZUBpZXRmLm9yZzxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8sPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5JIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBoaWdobGlnaHQgY29tcGxleGl0eSBm
b3IgdGhlIHNlcnZlciB0byAmbmJzcDvigJw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LWZhbWlseTpUaW1lcyI+Z3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFk
eQ0KIGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Ljwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SSB0aGluayB0aGlzIGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRl
ZCBieSBTdGV2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0
ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5pcmF2IFNh
bG90IChuc2Fsb3QpPGJyPg0KPGI+U2VudDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAy
MDE0IDExOjIwPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBTdGV2ZSBEb25vdmFuOw0K
PGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIGFtIGFsc28gZmluZSB3
aXRoIFN0ZXZlJ3MgcHJvcG9zZWQgd29yZGluZyB0byByZWNvbW1lbmQgdGhlIGluY2x1c2lvbiBv
ZiBPTFIgYnV0IHRvIG5vdCBtYW5kYXRlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYx
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBhbSBub3Qgc3VyZSBhYm91
dCB0aGUgZm9sbG93aW5nIHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIGFk
ZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OlRpbWVzIj5Ob3RlIC0gdGhlIG9ubHkgc3VyZSB3
YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rp
bmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0
aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNs
aWVudA0KIGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkkgcHJlZmVyIHRvIHJlbW92ZSBpdCBz
aW5jZSBJIGRvIG5vdCBzZWUgYXMgdmFsdWUgYWRkaXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlZ2FyZHMs
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0N
CjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k
YXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEwOjEzIFBNPGJyPg0KPGI+VG86PC9iPiBTdGV2ZSBEb25v
dmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkknbSBmaW5lIHdp
dGggYSByZWNvbW1lbmRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1l
bnQ6IHdoZW4gYSBNQVkgb3IgZXZlbiBhIFNIT1VMRCBhcHBseSwgaXQgZG9lcyBub3QgbWVhbiB0
aGF0IGl0IGlzIE5PVCB1cCB0byB0aGUgbm9kZSB0byBkbyBvciBub3QgdG8gZG8gc29tZXRoaW5n
LiBJdCBkb2VzIG5vdCBtZWFuDQogdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9w
dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGluc3RhbmNlLCBvdmVyIGEg
Z2l2ZW4gaW50ZXJmYWNlLCB0aGUgcmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkgdGhhdCBz
b21lIHN0YXRlcyBhcmUgbWFpbnRhaW5lZCBieSB0aGUgc2VydmVyLiBBbmQgaXQgY291bGQgYmUg
ZGVjaWRlZCB0byBhZGQgc29tZSBvdmVybG9hZA0KIHJlbGF0ZWQgaW5mbyBpbiBzdWNoIHN0YXRl
cy4gRm9yIGluc3RhbmNlIGFnYWluLCB0aGUgbm9kZSBjYW4gdXNlIHRoaXMgc3RhdGUgdG8ga25v
dyBpZiBhIHJlbW90ZSBub2RlIGhhdmUgYmVlbiBub3RpZmllZCBvciBub3QgZm9yIGluc3RhbmNl
LiBBbmQgaW4gc3VjaCBhIGNhc2UsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBpbmNsdWRl
IGFuIE9MUiBpbiBlYWNoIG1lc3NhZ2UuIEl0IGlzIGp1c3QgZm9yIGlsbHVzdHJhdGlvbi4gVGhl
IHBvaW50DQogaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9M
UiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3Jl
ZSB0aGF0IGhhdmluZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l4oCmIGJ1dCBpdCBz
aG91bGQgYmUgbm90IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4gU28gT0sgZm9yIGEg
JnF1b3Q7U0hPVUxEJnF1b3Q7IG9yICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu
IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRl
IGxhIHBhcnQgZGU8L2I+IFN0ZXZlIERvbm92YW48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4g
bHVuZGkgMTAgZsOpdnJpZXIgMjAxNCAxNzoyMTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJl
Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqPC9i
Pjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu
ZG93dGV4dCI+ZXQmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbw0KIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFu
ZCBOaXJhdi4gOi0pPGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNh
eWluZyB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQg
cmVwb3J0IGluIGFsbCByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5
IE1hcmlhIENydXouJm5ic3A7DQo8YnI+DQo8YnI+DQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGlu
Y2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhh
dCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0
IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4mbmJzcDsgSSBkb24ndCB0
aGluayB3ZSBuZWVkIHRvIGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJlcG9ydGlu
ZyBub2RlIGtub3dzDQogYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29y
a3MgYXJjaGl0ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuJm5ic3A7IFRo
ZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0
aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6VGltZXMiPldlIGFsc28gbmVlZCB0byBtYWtlIHN1
cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJh
didzIHByb3Bvc2FsLjxicj4NCjxicj4NCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2
ZSB3b3JkaW5nLCB3aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFz
b25zIGZvciByZWNvbW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBp
bmNsdWRlZC48YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCkEgcmVwb3J0aW5nIG5vZGUgTVVT
VCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVw
b3J0cy48YnI+DQo8YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUg
aW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBy
ZWFjdGluZyBub2Rlcy4mbmJzcDsNCjxicj4NCjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5v
ZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdl
cyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZu
YnNwOyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0
ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGlu
ZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVh
Y3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxy
ZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48YnI+DQo8YnI+DQpOb3RlIC0g
dGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25v
dyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlz
IHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50
IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBs
YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkZSIj5PbiAyLzEwLzE0IDM6NTIgQU0sIE1hcmlhIENydXogQmFydG9s
b21lIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5IZWxsbyBOaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+QW55IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZp
Y2llbmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1
dCBmaXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBp
cyBwcm92aWRpbmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Zb3VyIHByb3Bvc2VkIHRleHQmbmJzcDsgPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mcXVvdDsgQWRkaXRpb25h
bGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qg
YXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSBy
ZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0
aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5J
ZiB0aGUgcmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3aGV0aGVyIG9yIG5vdCBvdmVybG9h
ZCByZXBvcnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIGFuZCBpdCBkZWNpZGVz
IChzaW5jZSBpdCBpcyBhICZxdW90O21heSZxdW90OykgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBh
Z2FpbiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGlu
IGNhc2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3Rl
bnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAmcXVvdDtyZWFj
dGluZyBub2RlcyZxdW90OyBjb3VsZCBiZSBub3Qgb25seSB0aGUgY2xpZW50LCBidXQgQU5ZIGFn
ZW50IHVzZWQgZm9yIHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4gdGhlIGFnZW50IGlzIHByb3ZpZGlu
ZyBzZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlzIHJlYWN0aW5nIG9uIGJlaGFsZiBv
ZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+VGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBr
bm93IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVk
IGJlbG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9z
ZWQgJnF1b3Q7bWF5JnF1b3Q7KSB0aGVuIG9uZSBvciBtdWx0aXBsZSByZWFjdGluZyBub2RlcyBk
byBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gd2ls
bCBub3Qgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhl
cmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWly
ZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+L01DcnV6PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBOaXJhdiBT
YWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpu
c2Fsb3RAY2lzY28uY29tPC9hPl0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5TZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogTWFyaWEgQ3J1eiBC
YXJ0b2xvbWU7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDog
UkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJ1dCBNYXJpYS1DcnV6LDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Ib3cgY2FuIHdlIHNheSB0aGF0
ICZxdW90O2luY2x1ZGluZyB0aGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNp
bXBsZSBhbmQgZWZmaWNpZW50PyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+SXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1dCBub3QgZWZmaWNpZW50LiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QSBzbGlnaHRseSBkaWZm
ZXJlbnQgd29yZGluZyBmcm9tIHdoYXQgSSBwcm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVuIHRoZSBy
ZXBvcnRpbmcgbm9kZSBoYXMgYSBuZXcgb3ZlcmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMgdG8gYmUg
cHJvdmlkZWQgdG8gYSByZWFjdGluZyBub2RlIChieSB1cGRhdGluZyB0aGUgZWFybGllciBwcm92
aWRlZCBvdmVybG9hZCByZXBvcnQgb3IgYnkgcHJvdmlkaW5nIHRoZSBvdmVybG9hZCByZXBvcnQg
Zm9yIHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNl
LCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93
YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90
aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0
aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5v
ZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25z
ZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IERpTUUg
WzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IE1vbmRheSwgRmVi
cnVhcnkgMTAsIDIwMTQgMzowMyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYu
b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3Vi
amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk5pcmF2LCBhbGwsPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgdGhpbmsgd2Ugc2hvdWxk
IGRlZmluZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0IHNvbHV0aW9uLCBhcyBlZmZpY2llbnQgYW5k
IHNpbXBsZSBhcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPkkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEgcHVyZSAmcXVvdDttYXkm
cXVvdDssIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3Vy
ZSByZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMg
Zm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhy
ZWY9Im1haWx0bzpuc2Fsb3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5d
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBsdW5l
cywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1h
aWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPk1hcmlhLUNydXosPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPkkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ugb24gJnF1b3Q7c2VuZGluZyBPTFIg
aW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMmcXVvdDsuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BbmQgd2UgYXJlIG5vdCB0
cnlpbmcgdG8gcHJldmVudCBpdCAtIGF0IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9uLiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkJ1dCB0aGUgbWFpbiBx
dWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBp
bXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRp
bmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Nb3N0IHByb2JhYmx5LCB0aGUgdmVyeSBmaXJz
dCBpbXBsZW1lbnRhdGlvbiBvZiBvdmVybG9hZCBjb250cm9sIHdpbGwgaW5jbHVkZSBPTFIgaW4g
YWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5CdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0
cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vh
a3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2
ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQg
YXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPldoYXQgZG8geW91
IHRoaW5rPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIGFs
c28gdGhlIHJlYXNvbiBJIHdhcyBzdWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4g
dG8gaW5jbHVkZSBPTFIgKGZyb20gdGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBEaU1F
IFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPlRvOiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRm
Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1
YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5IZWxsbyBVbHJpY2gs
IE5pcmF2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVl
IHdpdGggVWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1B
WSwgYW5kIHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3
ZXJzIHNoYWxsIG5vdCBiZSBqdXN0IGEgTUFZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5PbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxy
aWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNv
bWUga25vd2xlZGdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFz
IGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5iKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQg
KGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFj
dGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Yykgb3RoZXJ3aXNlPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlcG9ydGluZyBub2RlIG11c3QgaGF2
ZSBzb21lIGtub3dsZWRnZSBhYm91dCBPTFIgcmVjZXB0aW9uL3N0YXR1cyBpbiByZWFjdGluZyBu
b2RlLiBIb3cgZG9lcyBzZXJ2ZXIgYWNxdWlyZSB0aGlzIGtub3dsZWRnZT8gPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UYWtlIGludG8gYWNjb3VudCBhcyB3
ZWxsIHRoYXQgYSAmcXVvdDtyZWFjdGluZyZxdW90OyBub2RlIG1heSBiZSBib3RoIGFuIEFnZW50
IChpbiBjYXNlIGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8gYSByZWFsbSBvciBhY3Rpbmcgb24gYmVo
YWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KSZuYnNwOyBhbmQgYSBDbGllbnQuIEluIHRo
ZSBjYXNlIG9mIEFnZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBrbm93IGlm
IHRoaXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRyYW5zcGFy
ZW50bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFueSBrbm93
bGVkZ2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBDbGllbnQu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoZXJlZm9yZSwgSSBk
ZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUg
aW1wb3J0YW50IGFkdmFudGFnZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj4tIHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNl
c3Npb24pIGlzIHNpbXBsZXIsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj4tIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBv
ciBub3QgdG8gc2VuZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRv
IGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4g
T0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCku
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tIHNlbmRpbmcg
YW4gYWRkaXRpb25hbCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJp
c29uIHdpdGggcmVxdWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgSW4gZmFj
dCwgaW4gYW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxl
eCBpcyB0byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBu
b2RlcywgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJz
cDsgYW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFj
dGlvbnMmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij4tIG1vcmUgcm9idXN0IHNvbHV0aW9uLCBhcyBubyBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhl
IGNoZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5kIGluZm9ybWF0aW9uLCZuYnNwOyBmb3Igc2l0dWF0
aW9ucyB3aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCZuYnNwOyDigKY8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogRGlNRSBbPGEgaHJl
Zj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiB2aWVybmVz
LCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCA8YSBo
cmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5n
ZS5jb208L2E+OyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v
cmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
TmlyYXYsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkknbSBhZnJh
aWQgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+JnF1b3Q7d2hlbiBpdCB3YW50
cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uJnF1b3Q7IHRyYW5zbGF0
ZXMgdG8gJnF1b3Q7Li4uaXQgbWF5IGluY2x1ZGUuLi4mcXVvdDsuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZxdW90O2luIG90aGVyIGNhc2VzJnF1b3Q7IGluIHRo
ZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7d2hlbiBpdCBkb2VzIG5vdCB3YW50
IHRvIHByb3ZpZGUvdXBkYXRlLi4uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+V2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRo
YXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5iKSB0aGUgcmVwb3J0aW5n
IG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcp
IGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2ls
bCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+Yykgb3RoZXJ3aXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUg
T0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUg
dGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBv
cnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0
aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBk
YXRlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5VbHJpY2g8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTog
ZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2NvLmNv
bSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6
NDkgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0
ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3Jn
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVj
dDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlVscmljaCw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBz
YW1lIHBhZ2UgYnV0IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0
aGUgYmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkhv
dyBhYm91dCB0aGUgZm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5XaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVy
bG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJs
b2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIg
aW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRp
dGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlz
IG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8g
dGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xS
IGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQt
RmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJl
Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJh
di48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgWzxhIGhyZWY9Im1haWx0
bzp1bHJpY2gud2llaGVAbnNuLmNvbSI+bWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tPC9hPl08
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5k
QG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IE5pcmF2IFNhbG90IChu
c2Fsb3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmci
PmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Tmly
YXYsIExpb25lbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBj
YW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkg
YW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzo8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+MicuIHRoZSByZXBvcnRpbmcg
bm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90
IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVk
IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFj
dGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5m
b3JtYXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVz
dGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVy
bG9hZCZxdW90Oywgb3IgYW4gb2xkJm5ic3A7IGJ1dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRo
ZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBp
dCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIg
b3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVx
dWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBkb24ndCBhZ3JlZSB3aXRoIExp
b25lbHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5v
dCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVh
Y3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1
cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VWxyaWNoJm5ic3A7IDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IGV4dCA8YSBocmVmPSJt
YWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208
L2E+IFs8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5tYWlsdG86bGlv
bmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBB
TTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IE5pcmF2
IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3Rl
dmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8
L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TdWJqZWN0
OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t
LTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RGUmbmJzcDs6
IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3Qp
IEVudm95w6kmbmJzcDs6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCZuYnNwOzogV2ll
aGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9
Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPiBPYmpldCZuYnNwOzogUmU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRo
aXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgJnF1b3Q7b3RoZXJ3aXNlIChpLmUuIGlmIGl0
IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBv
dmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1
ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiZxdW90Ozxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhlIHJlcG9ydGlu
ZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVhcmxp
ZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHN0
b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+W0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQg
cmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFm
dC4gSG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhl
IE9MUiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRo
ZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGlu
Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgd2UgaGFkIGRp
c2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUg
dG8gZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRo
ZSBzYW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93
IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9m
IHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5bTE1dIEFncmVlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPlRoZXJlIG1heSBiZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSBy
ZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRl
ZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8g
aW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+W0xNXSBBZ3JlZTxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5SZXN0IG9mIHRoZSBwcmluY2lw
bGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbPGEg
aHJlZj0ibWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86dWxyaWNoLndpZWhlQG5z
bi5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE08bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFjdHVhbGx5IHdl
IHNlZW0gdG8gYWdyZWUgb24gdHdvIHByaW5jaXBsZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4xLiBMYWNrIG9mIE9MUiBtZWFucyAmcXVvdDtubyBjaGFu
Z2UmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjIu
IHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3Qp
IE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMg
d2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2Fy
ZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAo
d2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9M
UiBpbmRpY2F0aW5nICZxdW90O25vIG92ZXJsb2FkJnF1b3Q7KTsgb3RoZXJ3aXNlIChpLmUuIGlm
IGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhl
ciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byBy
ZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DYW4gcGVvcGxlIHBsZWFzZSBj
b25maXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5VbHJpY2g8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogRGlNRSBbPGEg
aHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFy
eSAwNSwgMjAxNCA0OjM1IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5UbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll
dGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPkFncmVlZC4mbmJzcDsgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9y
dCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUgZm9yIHRoZSBob3N0
IG9yIHJlYWxtLiZuYnNwOyBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQg
cmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBv
dXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LiZu
YnNwOyBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVu
IGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQg
Zm9yIHRoZSBob3N0IGFuZCByZWFsbS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+U3RldmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgYWdyZWUgd2l0aCBTdGV2
ZSBleGNlcHQgdGhlIHBhcnQgJnF1b3Q7c2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJw
cmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQg
dGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0
byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUg
c2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVu
dCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyBy
ZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUg
c2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2
aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TbyBiYXNpY2Fs
bHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNl
aXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250
aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUg
dmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICZxdW90OzAmcXVv
dDsgb3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+SW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxl
IGltcGxlbWVudGF0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcg
b2YgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3Zh
bjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogV2Vk
bmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmci
PmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+aW5s
aW5lPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PbiAyLzUv
MTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9rIHRoZW4gbGV0J3Mgc3Rh
dGUgdGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwg
YW5zd2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNo
IGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQg
cmVkdWN0aW9uIGlzIHJlcXVlc3RlZCkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5TUkQmZ3Q7IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT8mbmJzcDsg
U2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVk
PzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4
IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNSRCZndDsgUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9y
dCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmlu
ZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFs
IHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5nIE9MUnMuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNz
IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkg
c2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3
b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1p
bmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBt
aW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TUkQmZ3Q7IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2Yg
dGhlIHNlcXVlbmNlIG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4tLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYg
U2Fsb3QgKG5zYWxvdCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IDxhIGhyZWY9Im1haWx0bzps
aW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9u
ZWwuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206
IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogVHVlc2RheSwgRmVi
cnVhcnkgMDQsIDIwMTQgOTowNyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYu
b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3Vi
amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgdW5kZXJzdGFuZCB0
aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1Qg
aW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+MS0gT0MtT0xSIEFWUCBpbiBldmVy
eSBhbnN3ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjIt
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICYjNDM7IE9D
LU9MUiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZv
cm1lZCBieSB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwg
dGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5MaW9uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5EZSZuYnNwOzogZGltZSBpc3N1ZSB0cmFj
a2VyIFs8YSBocmVmPSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnIj5t
YWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkVudm95w6kmbmJzcDs6IG1hcmRpIDQg
ZsOpdnJpZXIgMjAxNCAwOTo0OTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+w4AmbmJzcDs6IE1PUkFORCBMaW9uZWwgSU1UL09MTjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpk
aW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+T2JqZXQmbmJzcDs6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4g
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMmbmJzcDsgdG8gYmUgaW5jbHVk
ZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
Jm5ic3A7IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhl
IFNlcXVlbmNlLU51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+IChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJv
dHRsaW5nICh3aGljaCB3YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGlj
YXRlcyB0aGF0IGN1cnJlbnRseSBubyZuYnNwOyB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4mbmJz
cDsgUmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhpcyZuYnNwOyBpbmZvcm1hdGlv
biBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRo
ZSZuYnNwOyByZWFjdGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gQWJzZW5jZSBvZiB0aGlz
IGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSZuYnNw
OyByZXBvcnRpbmcgbm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0
aGUgcmVwb3J0aW5nIERPSUMmbmJzcDsgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUg
cmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyZuYnNwOyB0aGUgcmlnaHQg
dGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBUaGUgZmVlZGJhY2sgbWVjaGFu
aXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZu
YnNwOyBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRs
aW5nIGJ5IHRoZSByZWFjdGluZyZuYnNwOyBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2
ZXIgcmVhc29uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZy
b20gUkZDIDcwNjguPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij4gSW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCB0byZuYnNwOyBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RGlNRSBtYWlsaW5nIGxpc3Q8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Im1h
aWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2Fn
ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z
IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBl
dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2
b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy
IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50
ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy
YXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug
YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh
dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk
LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt
YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs
aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh
bHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRo
YW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlN
RUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlN
RUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlN
RUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlN
RUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250
ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg
bmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh
dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs
ZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl
cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh
dGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9yYW5n
ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl
LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh
aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv
dGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFp
bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0
IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A9CA33BB78081F478946E4F34BF9AAA014D697CAxmbrcdx10ciscoc_--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:31:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E261A0947 for ; Tue, 11 Feb 2014 02:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReSH2f3Hd3JU for ; Tue, 11 Feb 2014 02:31:03 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4764F1A093E for ; Tue, 11 Feb 2014 02:31:01 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-53-52f9fbe46f70
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B5.DD.10875.4EBF9F25; Tue, 11 Feb 2014 11:31:01 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:31:00 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjw
Date: Tue, 11 Feb 2014 10:30:59 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209772EB3ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje7T3z+DDPbMZrWY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGa0/3jIWrJvOXvH4xCPGBsYL/9m6GDk5JARMJF59vcgEYYtJ XLi3HijOxSEkcIhRomv2XiYIZwmjxOZbX9lBqtgE7CQunX4BlODgEBFQljj9ywEkLCxQLvHy 0hVmEFtEoELi89ZLYL0iAvsYJR5vOQ+2gUVAVeLmlydgc3gFfCUWLboEteA+l8ST552MIAlO oMTBlz/AihiBTvp+ag1YM7OAuMStJ/OhThWQWLLnPDOELSrx8vE/VghbSWLR7c9Q9fkShx/3 sEEsE5Q4OfMJywRGkVlIRs1CUjYLSdksoN+YBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj +ypG9tzEzJz0csNNjMBoObjlt+4OxlPnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qB0bOATWk7781TunlMOTuzb606ciPu0ppt+gGHK14yecbvOfiuSN7CKkBi4ZtF L9j/7t+1RdPu3tY7s1o1Zh3LYzn7o/GAufPvyQobrtodzTnF/vlu0WPBxQa1xRyfWB5t+ijY xhF06VPBDl3NS8KF+qpr3Jab9lUl2/eu2TnLoKbUzFagbEablhJLcUaioRZzUXEiAO8NCIZk AgAA
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:31:12 -0000

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

RmluZSBOaXJhdiwgSSBhZ3JlZSB0aGlzIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLg0KTXkg
aW50ZW50aW9uIGlzIHRoYXQgYW55IHJlYWRlciByZWFsaXplcyB3aGF0IHRoaXMga25vd2xlZGdl
IGluIHRoZSBzZXJ2ZXIgaW1wbGllcyB3aGVuIHdlIHRhbGsgYWJvdXQgYWdlbnRzIGluIHRoZSBw
YXRoLiBUaGlzIGlzIHdoeSBJIHRoaW5rIHRoaXMgbm90ZSBpcyBoZWxwZnVsLg0KDQpSZWdhcmRz
DQovTUNydXoNCg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lz
Y28uY29tXQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjYNClRvOiBN
YXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgZG8gbm90IGFncmVl
IHJlZ2FyZGluZyB0aGUgY29tcGxleGl0eSBzaW5jZSBpdCBpcyBoaWdobHkgaW1wbGVtZW50YXRp
b24gc3BlY2lmaWMuDQpMZXRzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90b2Nv
bCBkZXNpZ24uDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50
OiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCAzOjU0IFBNDQpUbzogZGltZUBpZXRmLm9yZzxt
YWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpIZWxsbywNCg0KSSB0aGluayBpdCBpcyBpbXBv
cnRhbnQgdG8gaGlnaGxpZ2h0IGNvbXBsZXhpdHkgZm9yIHRoZSBzZXJ2ZXIgdG8gIOKAnGd1YXJh
bnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVy
bG9hZCByZXBvcnQu4oCdDQpJIHRoaW5rIHRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlbnRl
bmNlIGFkZGVkIGJ5IFN0ZXZlLg0KDQpDaGVlcnMNCi9NQ3J1eg0KDQpGcm9tOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmlyYXYgU2Fsb3QgKG5zYWxv
dCkNClNlbnQ6IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIwDQpUbzogbGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBTdGV2
ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDog
UmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkg
YW0gYWxzbyBmaW5lIHdpdGggU3RldmUncyBwcm9wb3NlZCB3b3JkaW5nIHRvIHJlY29tbWVuZCB0
aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQgdG8gbm90IG1hbmRhdGUgaXQuDQoNCkkgYW0gbm90IHN1
cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2Fy
eSB0byBhZGQgaXQuDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRh
cnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQg
YW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQg
YW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGlu
ZyBub2RlLg0KDQpJIHByZWZlciB0byByZW1vdmUgaXQgc2luY2UgSSBkbyBub3Qgc2VlIGFzIHZh
bHVlIGFkZGl0aW9uLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4NClNlbnQ6IE1vbmRheSwgRmVicnVh
cnkgMTAsIDIwMTQgMTA6MTMgUE0NClRvOiBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1h
aWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkknbSBmaW5lIHdpdGggYSByZWNvbW1lbmRhdGlv
bi4NCg0KQnV0IEkgaGF2ZSBhIGdlbmVyYWwgY29tbWVudDogd2hlbiBhIE1BWSBvciBldmVuIGEg
U0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgTk9UIHVwIHRvIHRoZSBu
b2RlIHRvIGRvIG9yIG5vdCB0byBkbyBzb21ldGhpbmcuIEl0IGRvZXMgbm90IG1lYW4gdGhhdCBp
dCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi4NCkZvciBpbnN0YW5jZSwgb3ZlciBh
IGdpdmVuIGludGVyZmFjZSwgdGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5IHRoYXQg
c29tZSBzdGF0ZXMgYXJlIG1haW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNvdWxkIGJl
IGRlY2lkZWQgdG8gYWRkIHNvbWUgb3ZlcmxvYWQgcmVsYXRlZCBpbmZvIGluIHN1Y2ggc3RhdGVz
LiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0byBrbm93
IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5zdGFuY2Uu
IEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGluY2x1ZGUg
YW4gT0xSIGluIGVhY2ggbWVzc2FnZS4gSXQgaXMganVzdCBmb3IgaWxsdXN0cmF0aW9uLiBUaGUg
cG9pbnQgaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9MUiBp
biBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLg0KDQpJIGFncmVlIHRoYXQgaGF2
aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIGlzIGZpbmXigKYgYnV0IGl0IHNob3VsZCBiZSBu
b3QgbWFuZGF0b3J5IGluIGFsbCBjYXNlcyBJIHRoaW5rLiBTbyBPSyBmb3IgYSAiU0hPVUxEIiBv
ciAiUkVDT01NRU5ERUQiLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KRGUgOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVu
dm95w6kgOiBsdW5kaSAxMCBmw6l2cmllciAyMDE0IDE3OjIxDQrDgCA6IGRpbWVAaWV0Zi5vcmc8
bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6
IGFuZCBOaXJhdi4gOi0pDQoNCkkgc3VnZ2VzdCB0aGF0IHdlIGhhdmUgd29yZGluZyBzYXlpbmcg
dGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIHRvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9y
dCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBieSBNYXJp
YSBDcnV6Lg0KDQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3Nh
bCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFz
IGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0
byBub3Qgc2VuZCBpdCBhZ2Fpbi4gIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBpbmNsdWRpbmcg
YW55dGhpbmcgYWJvdXQgaG93IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyBidXQgd2Ugc2hvdWxk
IGluY2x1ZGUgd29yZGluZyBhYm91dCBuZXR3b3JrcyBhcmNoaXRlY3R1cmVzIHRoYXQgbWFrZSBp
dCBkaWZmaWN1bHQgdG8ga25vdy4gIFRoZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rp
bmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuDQoN
CldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2gg
aXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLg0KDQpJIHByb3Bvc2UgdGhlIGZv
bGxvd2luZyBub3JtYXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBN
YXJpYSBDcnV6J3MgcmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJsb2FkIHJl
cG9ydCBpcyBhbHdheXMgaW5jbHVkZWQuDQoNCi0tLS0tDQoNCkEgcmVwb3J0aW5nIG5vZGUgTVVT
VCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVw
b3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUg
b3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcg
bm9kZXMuDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUg
b3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBu
b2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxs
IGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0
IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVy
bG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0
aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0
Lg0KDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFu
aXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3Zlcmxv
YWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJl
IGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0K
T24gMi8xMC8xNCAzOjUyIEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZToNCg0KSGVsbG8g
TmlyYXYsDQoNCg0KDQpBbnkgc29sdXRpb24gc2hvdWxkIGJhbGFuY2UgZGlmZmVyZW50IGZhY3Rv
cnMsIGVmZmljaWVuY3kgY291bGQgYmUgZGlzY3Vzc2VkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0
aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQgdG8gYXNzdXJlIHRoZSBtZWNoYW5pc20gd2UgYXJlIGRl
ZmluaW5nIGlzIHByb3ZpZGluZyB2YWxpZCBPTFIgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCg0KDQpZ
b3VyIHByb3Bvc2VkIHRleHQNCg0KIiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcu
IHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVw
b3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRp
bmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVl
c3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KDQoNCg0KSWYgdGhlIHJl
cG9ydGluZyBpcyBub3QgYXdhcmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0
IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2Ug
aXQgaXMgYSAibWF5IikgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9h
ZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3Qg
cHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9k
ZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxkIGJlIG5v
dCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9u
bHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdo
ZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4N
Cg0KVGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93IHdoZW4gcmVhY3Rp
bmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0IGlm
IE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQgIm1heSIpIHRoZW4g
b25lIG9yIG11bHRpcGxlIHJlYWN0aW5nIG5vZGVzIGRvIG5vdCBoYXZlIHRoZSByZXF1aXJlZCBP
TFIsIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlvbiB3aWxsIG5vdCB3b3JrLg0KDQoNCg0KVGhlcmVm
b3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWlyZWQg
aW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuDQoNCg0KDQpCZXN0
IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpG
cm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNl
bnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDINCg0KVG86IE1hcmlhIENydXog
QmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0
OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
DQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQoNCg0KSG93IGNhbiB3ZSBzYXkgdGhhdCAiaW5jbHVkaW5n
IHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMgaXMgc2ltcGxlIGFuZCBlZmZpY2ll
bnQ/Ig0KDQpJdCBpcyBzaW1wbGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuDQoNCg0KDQpB
IHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVhcmxpZXIg
aXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQgdGhh
dCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5nIHRo
ZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhlIG92
ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBp
biB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZl
YXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0
aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMg
bm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0
aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIg
aW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQoNClNlbnQ6IE1vbmRheSwgRmVi
cnVhcnkgMTAsIDIwMTQgMzowMyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBp
ZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpOaXJhdiwgYWxsLA0KDQoNCg0KSSB0aGluayB3ZSBzaG91
bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVudCBh
bmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KDQpJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBhcyBh
IHB1cmUgIm1heSIsIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90
IGFzc3VyZSByZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMg
YmFzaWMgZm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0K
L01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBT
YWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IGx1bmVzLCAx
MCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6MTINCg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBk
aW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk1hcmlhLUNy
dXosDQoNCg0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91IG9uICJzZW5kaW5nIE9MUiBpbiBBTEwg
YW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlcyIuDQoNCkFuZCB3ZSBhcmUgbm90
IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBteSBpbnRlbnRpb24uDQoN
CkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBv
dGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNh
biBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdl
Pw0KDQoNCg0KTW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Yg
b3ZlcmxvYWQgY29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3Nh
Z2VzLg0KDQpCdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0
aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5k
IHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1l
c3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQg
cHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLg0KDQpXaGF0
IGRvIHlvdSB0aGluaz8NCg0KDQoNClRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1Z2dlc3Rp
bmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUgcmVw
b3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KDQpT
ZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE0NCg0KVG86IGRpbWVAaWV0Zi5v
cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSGVsbG8gVWxyaWNoLCBOaXJh
diwNCg0KDQoNCkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBwcm92aWRlZCBieSBO
aXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNlcnZlciBzZW5kcyBh
biBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVkuDQoNCg0KDQpPbiB0
aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhh
cyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdlOg0KDQph
KSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxy
ZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBv
dmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhh
dCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUN
Cg0KYykgb3RoZXJ3aXNlDQoNCg0KDQpSZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93
bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRv
ZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBrbm93bGVkZ2U/DQoNClRha2UgaW50byBhY2NvdW50IGFz
IHdlbGwgdGhhdCBhICJyZWFjdGluZyIgbm9kZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAoaW4gY2Fz
ZSBpdCBwcm92aWRlcyBzZXJ2aWNlIHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBh
IG5vbi1zdXBwb3J0aW5nIGNsaWVudCkgIGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdl
bnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2lu
ZyB0byBhY3QgYXMgYSByZWFjdGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFj
dCwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3
aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC4NCg0KDQoNClRoZXJl
Zm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMg
aGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXM6DQoNCi0gc3RhdGUtbGVzcyBpbXBsZW1lbnRh
dGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikgaXMgc2ltcGxlciwNCg0KLSB0aGUgc2VydmVy
IGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wg
dG8gYSByZWFjdGluZyBub2RlDQoNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhl
ciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9y
IHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuDQoNCi0g
c2VuZGluZyBhbiBhZGRpdGlvbmFsIEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGlu
IGNvbXBhcmlzb24gd2l0aCByZXF1aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNl
bnQpLg0KDQogIEluIGZhY3QsIGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwgdGhlIGVhc2llc3Qg
YW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVj
dGVkL2FwcGxpY2FibGUgbm9kZXMsDQoNCiAgYW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2Fy
ZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMNCg0KLSBtb3JlIHJvYnVzdCBzb2x1dGlvbiwg
YXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVja3Mgb24gdGhlIG5lZWQgdG8gc2Vu
ZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlz
IGxvc3QsICDigKYNCg0KDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKQ0K
DQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTkNCg0KVG86IGV4dCBO
aXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5v
cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsDQoNCg0KDQpJJ20g
YWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24u
DQoNCg0KDQoid2hlbiBpdCB3YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNs
dWRlLi4uIiB0cmFuc2xhdGVzIHRvICIuLi5pdCBtYXkgaW5jbHVkZS4uLiIuDQoNCg0KDQoiaW4g
b3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gIndoZW4gaXQg
ZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQoNCg0KDQpXZSBoYXZlIHRo
ZSBmb2xsb3dpbmcgY2FzZXM6DQoNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRo
ZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0KDQpiKSB0aGUg
cmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRo
cm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xS
IHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KDQpjKSBvdGhlcndpc2UNCg0KDQoNCmluIGNhc2UgYSkg
dGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2Ug
YikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5n
IG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBN
VVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9l
cyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKQ0KDQoNCg0K
VWxyaWNoDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogZXh0
IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NCg0KU2VudDog
VGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkgUE0NCg0KVG86IFdpZWhlLCBVbHJpY2gg
KE5TTiAtIERFL011bmljaCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3Jn
PG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNClVscmljaCwNCg0KDQoNCkl0IHNl
ZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJvcG9zZWQgd29y
ZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuDQoNCkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLg0K
DQoNCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3Zlcmxv
YWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9h
ZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGlu
IHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVh
dHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRp
b25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBu
b3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRo
ZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBp
biB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZl
YXR1cmUgQVZQLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFtt
YWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAw
NiwgMjAxNCAzOjU3IFBNDQoNClRvOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0
bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0
ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1Ympl
Y3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQoNCg0KTmlyYXYsIExpb25lbCwNCg0KDQoNCkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25j
ZXJuIChhbHRob3VnaCB2aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5
IHRoZSBtb2RpZmllZCBwcmluY2lwbGUgMic6DQoNCg0KDQoyJy4gdGhlIHJlcG9ydGluZyBub2Rl
IChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8g
cmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4g
T0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29udHJvbCBpbmZvcm1h
dGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5n
IHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIsIG9y
IGFuIG9sZCAgYnV0IHNvb24gZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlz
IG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikg
dGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkg
TVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWlu
ZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KSSBkb24ndCBhZ3JlZSB3aXRo
IExpb25lbHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxs
IG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUg
cmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhl
IGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0KDQoNClVs
cmljaA0KDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBl
eHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20+IFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KDQpTZW50OiBUaHVyc2RheSwg
RmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBp
ZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQoNCg0KDQoNCi0tLS0t
TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nDqSA6IGpl
dWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCA6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011
bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYu
b3JnPiBPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KVWxyaWNoLA0KDQoNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5n
IHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBp
cyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zl
cmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVz
dHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQoNClRoZSBy
ZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRo
ZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUg
d2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZmaWMuDQoNCg0KDQpbTE1dIEFncmVlLiBJbiBv
dGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVj
aGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGlu
ZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVu
ZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwg
aXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLg0KDQoNCg0KQXMgd2UgaGFkIGRpc2N1c3Nl
ZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhw
bGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1l
IHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBu
YXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBz
aWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0Lg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KVGhl
cmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dz
IHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGlu
IHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJy
ZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9uLg0KDQoNCg0KW0xNXSBBZ3JlZQ0K
DQoNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1lLg0KDQoN
Cg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gp
IFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFy
eSAwNiwgMjAxNCAyOjIzIFBNDQoNClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3Qg
KG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6
IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoN
Cg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxlczoNCg0KMS4gTGFj
ayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSINCg0KMi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBt
YXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJu
IGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3Vw
cG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUg
YWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVl
c3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2Fk
Iik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcg
bm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFu
IE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uDQoNCg0K
DQpVbHJpY2gNCg0KDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1
YXJ5IDA1LCAyMDE0IDQ6MzUgUE0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkFncmVlZC4gIFRvIHJl
c3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBj
dXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS4gIElmIHRoZXJlIGlz
IGEgY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8g
YXBwbHkgdW50aWwgaXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQg
d2l0aCBhIG5ldyBvdmVybG9hZCByZXBvcnQuICBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0
aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxp
ZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS4NCg0KDQoNClN0
ZXZlDQoNCk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToNCg0K
SSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBP
TFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KDQoNCg0KV2UgaGFkIHNvbWUg
ZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJs
ZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBh
bnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2lu
ZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBz
ZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9u
YWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGli
aXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuDQoNCg0KDQpTbyBiYXNpY2FsbHksIHRo
ZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBP
TFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0
byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRp
dHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBvdmVybG9hZC1tZXRy
aWMgaXMgcmVjZWl2ZWQuDQoNCkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBp
bXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9m
IE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoN
Cg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IFN0ZXZlIERvbm92YW4NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAw
IFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0
OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
DQoNCmlubGluZQ0KDQpPbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUv
TXVuaWNoKSB3cm90ZToNCg0KT2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2Rl
cyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBj
b3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0
ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVk
KS4NCg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/ICBTaG91bGRuJ3QgbGFjayBv
ZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KDQoNCg0KDQoN
Cg0KDQpPdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1h
dHRlci4NCg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFuc3dl
ciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFuIG92ZXJsb2FkZWQg
bm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZl
cnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29yaywgcG90ZW50aWFs
bHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4NCg0KDQoNCg0KDQoNCg0KDQoN
CkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMg
bm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3
aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRo
ZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5
ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBh
IG5ldyBPTFI/DQoNClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVt
YmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN
CkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBl
eHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwg
MjAxNCA1OjI3IEFNDQoNClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbT47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KSSBzaGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExpb25lbC4NCg0KDQoN
ClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K
RnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPg0K
DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQoNClRvOiBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkkgdW5kZXJzdGFuZCB0
aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1Qg
aW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLg0KDQpTbyB0aGUgb3B0aW9ucyB3b3VsZCBi
ZToNCg0KMS0gT0MtT0xSIEFWUCBpbiBldmVyeSBhbnN3ZXINCg0KMi0gT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5z
d2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBu
ZWVkcyB0byBiZSB1cGRhdGVkLg0KDQoNCg0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9u
LCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQoNCg0KDQpMaW9uZWwNCg0K
DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IGRpbWUgaXNzdWUgdHJhY2tl
ciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0KDQpFbnZvecOpIDogbWFy
ZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5DQoNCsOAIDogTU9SQU5EIExpb25lbCBJTVQvT0xODQoN
CkNjIDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KT2JqZXQgOiBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQojMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZp
bmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMgIHRvIGJlIGluY2x1
ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2Vx
dWVuY2UtTnVtYmVyDQoNCiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGlj
aCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQoNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBB
YnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyAgdGhyb3R0bGlu
ZyBpcyBwZXJmb3JtZWQuICBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzICBp
bmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8g
dXBkYXRlIHRoZSAgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLg0K
DQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhl
IG5lZWQgZm9yIHRoZSAgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBldmVy
eSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0
aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nICB0aGUgcmln
aHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCg0KIFRo
ZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhl
IHJlcG9ydGluZyBET0lDICBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3By
aWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZyAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5
IHdoYXRldmVyIHJlYXNvbikuDQoNCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dz
IHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQoNCiBJbiBzdW1tYXJ5IGl0IGlzIHBy
b3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvICBi
ZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQoN
Cg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0
Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu
dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll
ZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w
aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl
cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl
IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz
IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl
c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp
ZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj
b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl
IHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv
ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0
aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0
aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRl
cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k
aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcg
bGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBp
ZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRv
OkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3Jn
Pg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl
bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu
ZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg
c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1
ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg
YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg
ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUg
cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs
c2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg
YmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs
ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJl
IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl
biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzOw0KCXBhbm9zZS0xOjIgMiA2IDMg
NSA0IDUgMiAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu
Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh
Y2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ
cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6
YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh
bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OmJsYWNrO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9y
bWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs
YWNrO30NCnAuUHJmb3JtYXRIVE1MLCBsaS5QcmZvcm1hdEhUTUwsIGRpdi5QcmZvcm1hdEhUTUwN
Cgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIjsNCgltc28tc3R5bGUtbGluazoi
UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2
MTt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0
IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkZpbmUgTmlyYXYsIEkgYWdyZWUgdGhpcyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgaW50ZW50aW9uIGlzIHRoYXQgYW55IHJlYWRl
ciByZWFsaXplcyB3aGF0IHRoaXMga25vd2xlZGdlIGluIHRoZSBzZXJ2ZXIgaW1wbGllcyB3aGVu
IHdlIHRhbGsgYWJvdXQgYWdlbnRzIGluIHRoZSBwYXRoLiBUaGlzIGlzIHdoeSBJIHRoaW5rIHRo
aXMgbm90ZSBpcyBoZWxwZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp
bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij4gTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28u
Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDEx
OjI2PGJyPg0KPGI+VG86PC9iPiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBkbyBub3Qg
YWdyZWUgcmVnYXJkaW5nIHRoZSBjb21wbGV4aXR5IHNpbmNlIGl0IGlzIGhpZ2hseSBpbXBsZW1l
bnRhdGlvbiBzcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TGV0cyBub3Qg
bWFrZSBhbnkgYXNzdW1wdGlvbiBpbiB0aGUgcHJvdG9jb2wgZGVzaWduLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVn
YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJpYSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNl
bnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCAzOjU0IFBNPGJyPg0KPGI+VG86PC9i
PiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gaGlnaGxpZ2h0IGNvbXBsZXhpdHkgZm9yIHRo
ZSBzZXJ2ZXIgdG8gJm5ic3A74oCcPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmd1YXJhbnRlZSB0aGF0
IHRoZSByZWFjdGluZyBub2RlDQogYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJl
cG9ydC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKA
nQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhpcyBpcyB0aGUgcHVy
cG9zZSBvZiB0aGUgc2VudGVuY2UgYWRkZWQgYnkgU3RldmUuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnM8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+
T24gQmVoYWxmIE9mIDwvYj5OaXJhdiBTYWxvdCAobnNhbG90KTxicj4NCjxiPlNlbnQ6PC9iPiBt
YXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyMDxicj4NCjxiPlRvOjwvYj4gPGEgaHJl
Zj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2Uu
Y29tPC9hPjsgU3RldmUgRG9ub3ZhbjsNCjxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5k
aW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzI0NDA2MSI+SSBhbSBhbHNvIGZpbmUgd2l0aCBTdGV2ZSdzIHByb3Bvc2VkIHdvcmRpbmcgdG8g
cmVjb21tZW5kIHRoZSBpbmNsdXNpb24gb2YgT0xSIGJ1dCB0byBub3QgbWFuZGF0ZSBpdC48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
NDQwNjEiPkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBh
YnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBhZGQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Tm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5
LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5n
IG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGlu
ZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuDQogdGhlIGNs
aWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIHByZWZlciB0byByZW1vdmUgaXQgc2lu
Y2UgSSBkbyBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8
Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5
LCBGZWJydWFyeSAxMCwgMjAxNCAxMDoxMyBQTTxicj4NCjxiPlRvOjwvYj4gU3RldmUgRG9ub3Zh
bjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JJ20gZmluZSB3aXRo
IGEgcmVjb21tZW5kYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBoYXZlIGEgZ2VuZXJhbCBjb21tZW50
OiB3aGVuIGEgTUFZIG9yIGV2ZW4gYSBTSE9VTEQgYXBwbHksIGl0IGRvZXMgbm90IG1lYW4gdGhh
dCBpdCBpcyBOT1QgdXAgdG8gdGhlIG5vZGUgdG8gZG8gb3Igbm90IHRvIGRvIHNvbWV0aGluZy4g
SXQgZG9lcyBub3QgbWVhbg0KIHRoYXQgaXQgaXMgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRp
b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgb3ZlciBhIGdp
dmVuIGludGVyZmFjZSwgdGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5IHRoYXQgc29t
ZSBzdGF0ZXMgYXJlIG1haW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNvdWxkIGJlIGRl
Y2lkZWQgdG8gYWRkIHNvbWUgb3ZlcmxvYWQNCiByZWxhdGVkIGluZm8gaW4gc3VjaCBzdGF0ZXMu
IEZvciBpbnN0YW5jZSBhZ2FpbiwgdGhlIG5vZGUgY2FuIHVzZSB0aGlzIHN0YXRlIHRvIGtub3cg
aWYgYSByZW1vdGUgbm9kZSBoYXZlIGJlZW4gbm90aWZpZWQgb3Igbm90IGZvciBpbnN0YW5jZS4g
QW5kIGluIHN1Y2ggYSBjYXNlLCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaW5jbHVkZSBh
biBPTFIgaW4gZWFjaCBtZXNzYWdlLiBJdCBpcyBqdXN0IGZvciBpbGx1c3RyYXRpb24uIFRoZSBw
b2ludA0KIGlzIHRoYXQgeW91IG1heSBoYXZlIHNvbWUgY2FzZXMgZm9yIHdoaWNoIHRoZSBPTFIg
aW4gZXZlcnkgYW5zd2VyIG1pZ2h0IG5vdCBiZSByZXF1aXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUg
dGhhdCBoYXZpbmcgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgaXMgZmluZeKApiBidXQgaXQgc2hv
dWxkIGJlIG5vdCBtYW5kYXRvcnkgaW4gYWxsIGNhc2VzIEkgdGhpbmsuIFNvIE9LIGZvciBhICZx
dW90O1NIT1VMRCZxdW90OyBvciAmcXVvdDtSRUNPTU1FTkRFRCZxdW90Oy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJl
Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5MaW9uZWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw
Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBs
YSBwYXJ0IGRlPC9iPiBTdGV2ZSBEb25vdmFuPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGx1
bmRpIDEwIGbDqXZyaWVyIDIwMTQgMTc6MjE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IDxhIGhyZWY9
Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPk9iajwvYj48
L3NwYW4+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv
d3RleHQiPmV0Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8NCiBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiI+SSBhZ3JlZSB3aXRoIGJvdGggTWFyaWEgQ3J1eiBhbmQg
TmlyYXYuIDotKTxicj4NCjxicj4NCkkgc3VnZ2VzdCB0aGF0IHdlIGhhdmUgd29yZGluZyBzYXlp
bmcgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIHRvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJl
cG9ydCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBieSBN
YXJpYSBDcnV6LiZuYnNwOw0KPGJyPg0KPGJyPg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBpbmNs
dWRlIE5pcmF2J3MgcHJvcG9zYWwgdGhhdCBpZiBhIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQg
YSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCB0
aGVuIGl0IG1heSBjaG9vc2UgdG8gbm90IHNlbmQgaXQgYWdhaW4uJm5ic3A7IEkgZG9uJ3QgdGhp
bmsgd2UgbmVlZCB0byBpbmNsdWRpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRoZSByZXBvcnRpbmcg
bm9kZSBrbm93cw0KIGJ1dCB3ZSBzaG91bGQgaW5jbHVkZSB3b3JkaW5nIGFib3V0IG5ldHdvcmtz
IGFyY2hpdGVjdHVyZXMgdGhhdCBtYWtlIGl0IGRpZmZpY3VsdCB0byBrbm93LiZuYnNwOyBUaGUg
Y2FzZSBvZiBhZ2VudHMgYWN0aW5nIGFzIHJlYWN0aW5nIG5vZGVzIGZvciBub24gc3VwcG9ydGlu
ZyBjbGllbnRzIGJlaW5nIG9uZSBleGFtcGxlLjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1
b3Q7Ij5XZSBhbHNvIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlY29tbWVuZGVkIGFwcHJv
YWNoIGlzIG5vdCBwcmVjbHVkZWQgYnkgTmlyYXYncyBwcm9wb3NhbC48YnI+DQo8YnI+DQpJIHBy
b3Bvc2UgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBs
ZW1lbnRlZCBieSBNYXJpYSBDcnV6J3MgcmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhl
IG92ZXJsb2FkIHJlcG9ydCBpcyBhbHdheXMgaW5jbHVkZWQuPGJyPg0KPGJyPg0KLS0tLS08YnI+
DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5v
ZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuPGJyPg0KPGJyPg0KSXQgaXMgcmVjb21t
ZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBh
bGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuJm5ic3A7DQo8YnI+DQo8
YnI+DQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJs
b2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMg
aWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4mbmJzcDsgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxs
IGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0
IERPSUMuPGJyPg0KPGJyPg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5k
IGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRl
ZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9h
ZCByZXBvcnQuPGJyPg0KPGJyPg0KTm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHBy
b3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJl
Y2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEg
Y2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBy
ZXBvcnRpbmcgbm9kZS48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+T24gMi8xMC8x
NCAzOjUyIEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SGVsbG8gTmlyYXYsPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFueSBzb2x1dGlvbiBzaG91bGQgYmFs
YW5jZSBkaWZmZXJlbnQgZmFjdG9ycywgZWZmaWNpZW5jeSBjb3VsZCBiZSBkaXNjdXNzZWQgZnJv
bSBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLCBidXQgZmlyc3Qgd2UgbmVlZCB0byBhc3N1cmUgdGhl
IG1lY2hhbmlzbSB3ZSBhcmUgZGVmaW5pbmcgaXMgcHJvdmlkaW5nIHZhbGlkIE9MUiB0byByZWFj
dGluZyBub2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+WW91
ciBwcm9wb3NlZCB0ZXh0Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+JnF1b3Q7IEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hl
biB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQg
aXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBu
b2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBj
b250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUg
YWJvdXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSBy
ZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2UgaXQgaXMgYSAmcXVvdDttYXkmcXVv
dDspIHRvIGRvIG5vdCBzZW5kIHRoZSBPTFIgYWdhaW4sIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlv
biBtZWNoYW5pc20gd2lsbCBub3Qgd29yayBpbiBjYXNlIE9MUiB3YXMgbm90IHByb3Blcmx5IHJl
Y2VpdmVkIGJ5IGNvcnJlc3BvbmRpbmcgcG90ZW50aWFsIHJlYWN0aW5nIG5vZGVzLiBBbmQgd2Ug
bmVlZCB0byBub3RlIHRoYXQgJnF1b3Q7cmVhY3Rpbmcgbm9kZXMmcXVvdDsgY291bGQgYmUgbm90
IG9ubHkgdGhlIGNsaWVudCwgYnV0IEFOWSBhZ2VudCB1c2VkIGZvciByb3V0aW5nIChub3Qgb25s
eSB3aGVuIHRoZSBhZ2VudCBpcyBwcm92aWRpbmcgc2VydmljZSB0byBhIFJlYWxtLCBidXQgd2hl
biBpdCBpcyByZWFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpLiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoZW4sIG9uIG9u
ZSBoYW5kIGl0IGlzIG5vdCBzaW1wbGUgdG8ga25vdyB3aGVuIHJlYWN0aW5nIG5vZGVzIGhhdmUg
dmFsaWQgT0xSIGluZm8gKGFzIGV4cGxhaW5lZCBiZWxvdyksIGJ1dCBpZiBPTFIgaXMgbm90IHNl
bnQgYWdhaW4gKGFzIHBlciB5b3VyIHByb3Bvc2VkICZxdW90O21heSZxdW90OykgdGhlbiBvbmUg
b3IgbXVsdGlwbGUgcmVhY3Rpbmcgbm9kZXMgZG8gbm90IGhhdmUgdGhlIHJlcXVpcmVkIE9MUiwg
dGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIHdpbGwgbm90IHdvcmsuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoZXJlZm9yZSwgaW4gbXkgb3BpbmlvbiwgdGhlIHNp
bXBsZXN0IHdheSB0byBwcm92aWRlIHJlcXVpcmVkIGluZm9ybWF0aW9uIGlzIHRvIHByb3ZpZGUg
T0xSIGluIEFMTCBhbnN3ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+RnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0
bzpuc2Fsb3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U2VudDogbHVuZXMsIDEwIGRl
IGZlYnJlcm8gZGUgMjAxNCAxMDo0MjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+VG86IE1hcmlhIENydXogQmFydG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGlt
ZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5CdXQgTWFyaWEtQ3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+SG93IGNhbiB3ZSBzYXkgdGhhdCAmcXVvdDtpbmNsdWRpbmcgdGhlIE9MUiBpbiBh
bGwgdGhlIGFuc3dlciBtZXNzYWdlcyBpcyBzaW1wbGUgYW5kIGVmZmljaWVudD8mcXVvdDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkl0IGlzIHNpbXBsZSBm
b3Igc3VyZSBidXQgbm90IGVmZmljaWVudC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPkEgc2xpZ2h0bHkgZGlmZmVyZW50IHdvcmRpbmcgZnJvbSB3aGF0IEkgcHJv
cG9zZWQgZWFybGllciBpcywgV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaGFzIGEgbmV3IG92ZXJs
b2FkIHJlcG9ydCB0aGF0IG5lZWRzIHRvIGJlIHByb3ZpZGVkIHRvIGEgcmVhY3Rpbmcgbm9kZSAo
YnkgdXBkYXRpbmcgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVwb3J0IG9yIGJ5IHBy
b3ZpZGluZyB0aGUgb3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUgZmlyc3QgdGltZSksIGl0IHNoYWxs
IGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBP
Qy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rp
bmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5
IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGlu
Y2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcg
T0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m
IE1hcmlhIENydXogQmFydG9sb21lPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDM6MDMgUE08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRvOiA8YSBocmVmPSJtYWls
dG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5OaXJhdiwgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5JIHRoaW5rIHdlIHNob3VsZCBkZWZpbmUgYW4gYWNjdXJhdGUgYW5kIHJvYnVz
dCBzb2x1dGlvbiwgYXMgZWZmaWNpZW50IGFuZCBzaW1wbGUgYXMgcG9zc2libGUuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JIHVuZGVyc3RhbmQgeW91ciBw
cm9wb3NhbCBhcyBhIHB1cmUgJnF1b3Q7bWF5JnF1b3Q7LCBidXQgbGVhdmluZyBpdCB1cCB0byBp
bXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBhc3N1cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQgT0xS
IGluZm9ybWF0aW9uLCB3aGF0IGlzIGJhc2ljIGZvciB0aGlzIG1lY2hhbmlzbSB0byB3b3JrLiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QmVzdCByZWdhcmRzPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4vTUNydXo8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206
IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2NvLmNvbSI+
bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+U2VudDogbHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxMDox
MjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IE1hcmlh
IENydXogQmFydG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRm
Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1
YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5NYXJpYS1DcnV6LDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JIGZ1bGx5IGFncmVlIHdp
dGggeW91IG9uICZxdW90O3NlbmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9y
dGFudCBhZHZhbnRhZ2VzJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+QW5kIHdlIGFyZSBub3QgdHJ5aW5nIHRvIHByZXZlbnQgaXQgLSBhdCBsZWFz
dCB0aGF0IGlzIG15IGludGVudGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5CdXQgdGhlIG1haW4gcXVlc3Rpb24gaXMsIGFyZSB3ZSB0cnlpbmcgdG8g
cHJldmVudCBhbnkgb3RoZXIgcG9zc2libGUgaW1wbGVtZW50YXRpb24sIHdoaWNoIG1heSBiZSBz
bWFydGVyIGFuZCBjYW4gYXZvaWQgaW5jbHVkaW5nIHJlZHVuZGFudCBPTFIgaW4gYWxsIHRoZSBh
bnN3ZXIgbWVzc2FnZT88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
TW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Ygb3ZlcmxvYWQg
Y29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QnV0IGF0IHRoZSBzYW1l
IHRpbWUsIEkgZG8gbm90IHdhbnQgdG8gcmVzdHJpY3QgdGhlIGRldmVsb3BlcnMgd2hpY2ggY2Fu
IGNvbWUgdXAgd2l0aCBzb21lIG5pY2UgdHdlYWtzIGFuZCB0cmlja3MgdG8gYXZvaWQgc2VuZGlu
ZyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBldmVyeSBtZXNzYWdlLiBBbmQgdGhpcyBpcyB3aGVy
ZSB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYW5kIGF2b2lkIHB1dHRpbmcgc3VjaCByZXN0cmljdGlv
bnMgaW4gcHJvdG9jb2wgZGVmaW5pdGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBhbHNvIHRoZSByZWFzb24gSSB3YXMgc3VnZ2VzdGlu
ZyBsb29zZSBkZXNjcmlwdGlvbiBvZiB3aGVuIHRvIGluY2x1ZGUgT0xSIChmcm9tIHRoZSByZXBv
cnRpbmcgbm9kZSBwb2ludCBvZiB2aWV3KS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNl
c0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP
ZiBNYXJpYSBDcnV6IEJhcnRvbG9tZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwNywgMjAxNCA4OjU3IFBNPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogPGEgaHJlZj0ibWFp
bHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+SGVsbG8gVWxyaWNoLCBOaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+SSBhZ3JlZSB3aXRoIFVscmljaCB0aGF0IHRoZSB0ZXh0IHBy
b3ZpZGVkIGJ5IE5pcmF2IGlzIGp1c3QgYSBNQVksIGFuZCB3aGV0aGVyIG9yIG5vdCB0aGUgc2Vy
dmVyIHNlbmRzIGFuIE9MUiBpbiBhbGwgYW5zd2VycyBzaGFsbCBub3QgYmUganVzdCBhIE1BWS48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+T24gdGhlIG90aGVyIGhh
bmQsIGNyaXRlcmlhIHByb3ZpZGVkIGJ5IFVscmljaCBvbiB3aGVuIE9MUiBoYXMgdG8gYmUgc2Vu
dCByZXF1aXJlcyB0aGUgc2VydmVyIGhhcyBzb21lIGtub3dsZWRnZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93
cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YikgdGhlIHJlcG9y
dGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRs
aW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0
IHdpbGwgc29vbiBleHBpcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPmMpIG90aGVyd2lzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5SZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJl
Y2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUg
dGhpcyBrbm93bGVkZ2U/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+VGFrZSBpbnRvIGFjY291bnQgYXMgd2VsbCB0aGF0IGEgJnF1b3Q7cmVhY3RpbmcmcXVv
dDsgbm9kZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAoaW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2aWNl
IHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVu
dCkmbmJzcDsgYW5kIGEgQ2xpZW50LiBJbiB0aGUgY2FzZSBvZiBBZ2VudHMsIGluIGZhY3QgdGhl
IFNlcnZlciBtYXkgbm90IGV2ZW4ga25vdyBpZiB0aGlzIGlzIGdvaW5nIHRvIGFjdCBhcyBhIHJl
YWN0aW5nIG5vZGUgb3IganVzdCB0cmFuc3BhcmVudGx5LCBpbiBmYWN0LCB0aGUgc2VydmVyIGRv
ZXMgbm90IG5lZWQgdG8gaGF2ZSBhbnkga25vd2xlZGdlIGFib3V0IHdoYXQgYWdlbnRzIGluIHRo
ZSBjaGFpbiB0byB0aGUgZmluYWwgQ2xpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5UaGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0aGluayB0aGF0IHNlbmRpbmcg
T0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LSBzdGF0ZS1sZXNzIGltcGxl
bWVudGF0aW9uICh0cmFuc2FjdGlvbiBvciBzZXNzaW9uKSBpcyBzaW1wbGVyLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LSB0aGUgc2VydmVyIGRvZXMgbm90
IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFj
dGluZyBub2RlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4t
IHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBib3RoZXIgd2hldGhlciBhbiByZWFjdGluZyBu
b2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBvciB3aGV0aGVyIHRoaXMgT0xSIGlzIHN0
aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+LSBzZW5kaW5nIGFuIGFkZGl0aW9uYWwgQVZQIGlzIG5vdCBwcm9j
ZXNzaW5nIGNvbnN1bWluZywgaW4gY29tcGFyaXNvbiB3aXRoIHJlcXVpcmVkIGFib3ZlIGNoZWNr
cyAoaWYgdGhpcyBpcyBub3Qgc2VudCkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+Jm5ic3A7IEluIGZhY3QsIGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwg
dGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQg
dG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7IGFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtl
IGNhcmUgdG8gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb25zJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LSBtb3JlIHJvYnVzdCBzb2x1dGlvbiwgYXMg
bm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVja3Mgb24gdGhlIG5lZWQgdG8gc2VuZCBp
bmZvcm1hdGlvbiwmbmJzcDsgZm9yIHNpdHVhdGlvbnMgd2hlcmUgYW4gYW5zd2VyIG1lc3NhZ2Ug
aXMgbG9zdCwmbmJzcDsg4oCmPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgV2llaGUs
IFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+U2VudDogdmllcm5lcywgMDcgZGUgZmVicmVybyBkZSAyMDE0IDEwOjU5
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogZXh0IE5p
cmF2IFNhbG90IChuc2Fsb3QpOyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jh
bmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0ZXZlIERvbm92YW47
IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk5pcmF2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5JJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5v
dCByZWZsZWN0IHRoZSBpbnRlbnRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPiZxdW90O3doZW4gaXQgd2FudHMgdG8gcHJvdmlkZS91cGRhdGUuLi4uaXQgc2hh
bGwgaW5jbHVkZS4uLiZxdW90OyB0cmFuc2xhdGVzIHRvICZxdW90Oy4uLml0IG1heSBpbmNsdWRl
Li4uJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mcXVv
dDtpbiBvdGhlciBjYXNlcyZxdW90OyBpbiB0aGUgZ2l2ZW4gY29udGV4dCB0cmFuc2xhdGVzIHRv
ICZxdW90O3doZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiZxdW90Ozxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPldlIGhhdmUgdGhlIGZvbGxvd2lu
ZyBjYXNlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEp
IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJl
YWR5IGdvdCB0aGUgbGF0ZXN0IE9MUjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+YikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQu
IGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcg
bm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmU8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmMpIG90aGVyd2lzZTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5pbiBjYXNlIGEpIHRoZSByZXBvcnRpbmcgbm9k
ZSBtYXkgb3IgbWF5IG5vdCByZXBsYXkgdGhlIE9MUiBpbiBjYXNlIGIpIHRoZSByZXBvcnRpbmcg
bm9kZSBtYXkgb3IgbWF5IG5vdCB1cGRkYXRlIHRoZSByZWFjdGluZyBub2RlIHdpdGggdGhlIGxh
dGVzdCBPTFIgaW4gY2FzZSBjKSB0aGUgcmVwb3J0aW5nIG5vZGUgTVVTVCBpbmNsdWRlIHRoZSBP
TFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9ydGluZyBub2RlIGRvZXMgbm90IGtub3cgd2hldGhl
ciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+VWxyaWNoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEg
aHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9h
Pl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFRo
dXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA0OjQ5IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UbzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNo
KTsgZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbTwvYT47IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86
ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5VbHJpY2gsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJv
cG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Ib3cgYWJvdXQgdGhlIGZvbGxvd2luZy48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+V2hlbiB0aGUgcmVwb3J0aW5nIG5v
ZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0
ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5n
IG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVl
c3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJl
c3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5n
LiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJl
cG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0
aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1
ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBXaWVoZSwgVWxyaWNoIChOU04g
LSBERS9NdW5pY2gpIFs8YSBocmVmPSJtYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb20iPm1haWx0
bzp1bHJpY2gud2llaGVAbnNuLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMzo1NyBQ
TTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IGV4dCA8
YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9y
YW5nZS5jb208L2E+OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZlIERvbm92YW47IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk5pcmF2LCBMaW9uZWwsPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJu
IChhbHRob3VnaCB2aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRo
ZSBtb2RpZmllZCBwcmluY2lwbGUgMic6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjInLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJs
b2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNl
IHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAg
aWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgcmVh
c29uYWJsZSBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0aW9uIChlLmcuIHRoZSBsYXRlc3QgT0xS
LCB3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4g
T0xSIGluZGljYXRpbmcgJnF1b3Q7bm8gb3ZlcmxvYWQmcXVvdDssIG9yIGFuIG9sZCZuYnNwOyBi
dXQgc29vbiBleHBpcmluZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJs
b2FkZWQpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0
aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVy
biBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1T
dXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdhbnQgYXBwcm9h
Y2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93IHRoZSByZXBv
cnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBhcmUgbm90IChz
dWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1
cCB0byBkYXRlIE9MUnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PlVscmljaCZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5Gcm9tOiBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbSI+bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT5dPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBUaHVyc2Rh
eSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPlRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgV2llaGUsIFVscmlj
aCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpk
aW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPkRlJm5ic3A7OiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEg
cGFydCBkZSBOaXJhdiBTYWxvdCAobnNhbG90KSBFbnZvecOpJm5ic3A7OiBqZXVkaSA2IGbDqXZy
aWVyIDIwMTQgMTA6MDggw4AmbmJzcDs6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7
IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBp
ZXRmLm9yZzwvYT4gT2JqZXQmbmJzcDs6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5VbHJpY2gsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkkg
YW0gbm90IHN1cmUgYWJvdXQgZm9yY2luZyB0aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2Rl
ICZxdW90O290aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRp
bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJu
IGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPlRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBpbmNsdWRl
IE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4cGlyZSBh
bmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZmaWMuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPltMTV0gQWdyZWUuIEluIG90
aGVyIHdvcmRzLCBpdCBpcyBub3QgZGVlbWVkIHJlcXVpcmVkIGZvciB0aGUgZGVmYXVsdCBtZWNo
YW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQuIEhvdyBhbmQgd2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgZGVjaWRlcyB0byBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciBtYXkgZGVwZW5k
IG9uIHRoZSBhcHBsaWNhdGlvbiBvciBvbiB0aGUgaW1wbGVtZW50YXRpb24uIEF0IGxlYXN0LCBp
dCBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8g
bmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5n
IGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3b3Jkcywg
dGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9M
UiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJk
cyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+W0xNXSBBZ3Jl
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGVyZSBtYXkgYmUg
b3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUg
bGFzdCBvdmVybG9hZCBzaXR1YXRpb24gZW5kZWQgbG9uZyB0aW1lIGJhY2sgaW4gdGhlIHBhc3Qs
IHRoZXJlIGlzIG5vIG5lZWQgZm9yIGl0IHRvIGluY2x1ZGUgT0xSIGlmIGN1cnJlbnRseSB0aGVy
ZSBpcyBubyBvdmVybG9hZCBjb25kaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+UmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1lLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5bTE1dIEFncmVlPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IFdpZWhlLCBV
bHJpY2ggKE5TTiAtIERFL011bmljaCkgWzxhIGhyZWY9Im1haWx0bzp1bHJpY2gud2llaGVAbnNu
LmNvbSI+bWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwg
MjAxNCAyOjIzIFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5UbzogZXh0IFN0ZXZlIERvbm92YW47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyA8YSBocmVmPSJt
YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5BY3R1YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmluY2lw
bGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+MS4gTGFj
ayBvZiBPTFIgbWVhbnMgJnF1b3Q7bm8gY2hhbmdlJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4yLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRl
ciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4g
T0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJl
YWR5IGhhcyBnb3QgdGhlIGxhdGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGlu
ZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVybG9h
ZCZxdW90Oyk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBv
cnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0
dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+Q2FuIHBlb3BsZSBwbGVhc2UgY29uZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+VWxyaWNoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgZXh0
IFN0ZXZlIERvbm92YW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IE5pcmF2IFNhbG90IChuc2Fs
b3QpOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1YmplY3Q6IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BZ3JlZWQuJm5ic3A7IFRvIHJlc3RhdGUg
LS0gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50
IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS4mbmJzcDsgSWYgdGhlcmUgaXMg
YSBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IGNvbnRpbnVlcyB0byBh
cHBseSB1bnRpbCBpdCBlaXRoZXIgdGltZXMgb3V0IG9yIGlzIGV4cGxpY2l0bHkgY2hhbmdlZCB3
aXRoIGEgbmV3IG92ZXJsb2FkIHJlcG9ydC4mbmJzcDsgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5
IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBp
bXBsaWVzIHRoZXJlIGlzIG5vIG92ZXJsb2FkIGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN0ZXZlPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PbiAyLzUvMTQgOToxOSBBTSwgTmlyYXYg
U2Fsb3QgKG5zYWxvdCkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5JIGFncmVlIHdpdGggU3RldmUgZXhjZXB0IHRoZSBwYXJ0ICZxdW90O3Nob3Vs
ZG7igJl0IGxhY2sgb2YgT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPyZxdW90
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5XZSBoYWQgc29tZSBk
aXNjdXNzaW9uIHNvbWV0aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhhdCBpdCBpcyByZWFzb25hYmxl
IHRvIG5vdCBtYW5kYXRlIHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFu
c3dlciBtZXNzYWdlLiBFLmcuIHdoZW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9mIHRyYWNraW5n
IHdoYXQgaXMgc2VudCB0byB3aGljaCBjbGllbnQgYW5kIGhlbmNlIHdhbnRzIHRvIGF2b2lkIHNl
bmRpbmcgaW5mb3JtYXRpb24gd2hpY2ggaXMgcmVkdW5kYW50LiBCdXQgdGhpcyBpcyBvcHRpb25h
bCBpbXBsZW1lbnRhdGlvbiBhbmQgYXQgdGhlIHNhbWUgdGltZSBuZWVkIG5vdCBiZSBwcm9oaWJp
dGVkIGZyb20gcHJvdG9jb2wgcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+U28gYmFzaWNhbGx5LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxkIG5v
dCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBub2Rl
LiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3QgYmFzZWQgb24gb2xkZXIg
T0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlvZCBvciB3aGVuIHRoZSBl
eHBsaWNpdCBPTFIgd2l0aCAmcXVvdDswJnF1b3Q7IG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZl
ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkluIG15IHZp
ZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0
aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+UmVnYXJkcyw8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk5pcmF2LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9h
Pl0gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODow
MCBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VG86IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmlubGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+T24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5T
TiAtIERFL011bmljaCkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5PayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1VU1Qg
aW5zZXJ0IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJlc3Bv
bmQgdG8gcmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0
dXJlcyBBVlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U1JEJmd0OyBXaHkgaW4g
ZXZlcnkgYW5zd2VyIG1lc3NhZ2U/Jm5ic3A7IFNob3VsZG4ndCBsYWNrIG9mIGFuIE9MUiBiZSBp
bnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+T3RoZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0
ZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TUkQmZ3Q7
IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0
bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sg
Zm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlz
IGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVu
c2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5G
b3IgbXkgY2xhcmlmaWNhdGlvbjogSSBndWVzcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGlzIG5v
dCByZXF1aXJlZCB0byBwcm9jZXNzIGV2ZXJ5IHNpbmdsZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2ls
bCBiZSByZXBsYXlzIGFueXdheSkuIFdoYXQgd291bGQgYmUgdGhlIHByb2NlZHVyZSBpbiB0aGUg
cmVhY3Rpbmcgbm9kZSBpbiBvcmRlciB0byBtaW5pbWl6ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVk
IE9MUnMgYW5kIGF0IHRoZSBzYW1lIHRpbWUgbWluaW1pemUgdGhlIHJpc2sgdG9vIG1pc3MgYSBu
ZXcgT0xSPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+U1JE
Jmd0OyBUaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyb206IERpTUUgWzxhIGhyZWY9Im1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5
IDA1LCAyMDE0IDU6MjcgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPlRvOiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9u
ZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+
ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JIHNo
YXJlIHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo
YWxmIE9mIDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDk6MDcgUE08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRvOiA8YSBocmVmPSJtYWls
dG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5JIHVuZGVyc3RhbmQgdGhhdCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4g
dGhlIHJlcG9ydGluZyBub2RlIERPRVMgTk9UIGluc2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dl
ci4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5TbyB0aGUg
b3B0aW9ucyB3b3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4yLSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gZXZlcnkgcmVxdWVzdCAmIzQzOyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4g
dGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBi
ZSB1cGRhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB0
aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0aGUgYmVzdCBh
cHByb2FjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+TGlvbmVs
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPi0tLS0tTWVzc2FnZSBk
J29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+RGUmbmJzcDs6IGRpbWUgaXNzdWUgdHJhY2tlciBbPGEgaHJlZj0ibWFpbHRvOnRyYWMmIzQz
O2RpbWVAdHJhYy50b29scy5pZXRmLm9yZyI+bWFpbHRvOnRyYWMmIzQzO2RpbWVAdHJhYy50b29s
cy5pZXRmLm9yZzwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5FbnZvecOpJm5ic3A7OiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDk8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPsOAJm5ic3A7OiBNT1JBTkQgTGlv
bmVsIElNVC9PTE48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
PkNjJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9iamV0Jm5i
c3A7OiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gSXQgaGFz
IGJlZW4gcHJvcG9zZWQgdG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCB0aGF0IGlzJm5ic3A7IHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBv
aW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCZuYnNwOyBzdXJ2aXZlZCBhIHRocm90dGxpbmcu
IFRoaXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBTZXF1ZW5jZS1OdW1iZXI8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiAoVGltZVN0YW1wKSBvZiB0aGUgT0xS
IGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gc3Vydml2ZWQpIGlzIHBlcmZvcm1l
ZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm8mbmJzcDsg
dGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuJm5ic3A7IFJlcG9ydGluZyBET0lDIGVuZHBvaW50cyBt
YXkgdXNlIHRoaXMmbmJzcDsgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0ZWN0IHdoZXRoZXIg
dGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGUmbmJzcDsgcmVhY3RpbmcgRE9JQyBlbmRwb2lu
dCB3aXRoIHRoZSBsYXRlc3QgT0xSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+IEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5pc20gd291bGQgcmVz
dWx0IGluIHRoZSBuZWVkIGZvciB0aGUmbmJzcDsgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1P
TFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDJm5ic3A7IGVuZHBv
aW50IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaXMgYWN0
dWFsbHkgZG9pbmcmbmJzcDsgdGhlIHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRocm90dGxp
bmcvbm90IHRocm90dGxpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj4gVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1c3RuZXNzIGFzIGl0
IGFsbG93cyB0aGUgcmVwb3J0aW5nIERPSUMmbmJzcDsgZW5kcG9pbnQgdG8gZGV0ZWN0IGFuZCBj
b3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmcmbmJzcDsgRE9J
QyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNv
IGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+IEluIHN1bW1hcnkgaXQgaXMgcHJvcG9zZWQg
dG8gZGVmaW5lIHRoZSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdG8mbmJzcDsgYmUg
dXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRm
Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl
bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp
ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv
cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg
ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly
ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl
cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy
ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz
aWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv
ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRo
ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo
b3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0
aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5
IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg
YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2UgZXQgc2Vz
IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl
bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv
aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l
c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl
IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz
IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0
ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk
IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp
YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo
aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg
bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg
b3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_087A34937E64E74E848732CFF8354B9209772EB3ESESSMB101erics_--


From ulrich.wiehe@nsn.com  Tue Feb 11 02:33:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD121A094C for ; Tue, 11 Feb 2014 02:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x8Q2Y5tQoS3 for ; Tue, 11 Feb 2014 02:32:58 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D340C1A0957 for ; Tue, 11 Feb 2014 02:32:57 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1BAWtfI021816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 11:32:55 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1BAWsXS000878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 11:32:55 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 11:32:54 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC Endpoint behavior -- Capability Exchange
Thread-Index: AQHPITtpNodjRHLeL0WcNoascGL9zpqk0C7AgAl5uQCAAZxaAA==
Date: Tue, 11 Feb 2014 10:32:53 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2A67@DEMUMBX014.nsn-intra.net>
References: <52F02C62.70600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B1E1B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097727F2@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097727F2@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/mixed; boundary="_002_5BCBA1FC2B7F0B4C9D935572D9000668151B2A67DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 27984
X-purgate-ID: 151667::1392114775-00001A6F-7819CDEA/0-0/0-0
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:33:03 -0000

--_002_5BCBA1FC2B7F0B4C9D935572D9000668151B2A67DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Maria Cruz,

please find the diagram attached.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 10, 2014 11:55 AM
To: dime@ietf.org
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange

Hello Ulrich et all,

As far as I can follow your comments on diagram, I tend to agree with your =
proposal, but I cannot fully follow this, since diagram is not properly rec=
eived.
Is it possible to provide diagram in another format that is not modified by=
 each one email configuration? I think this is very important for discussio=
n and agreement
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 04 de febrero de 2014 14:44
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange

Steve,

please find comments inline.

Regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 04, 2014 12:55 AM
To: dime@ietf.org
Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange

All,

I believe that the current DOIC Endpoint behavior definition is not suffici=
ently defined, especially for agents.
 I agree. 

There was also a change introduced in the -01 version of the draft that imp=
lies that there can be a DOIC association that goes through a DOIC enabled =
agent.=A0 This was not=A0 how I understood endpoints.
 same with me =A0 The original diagrams showed a DOIC agen=
t as terminating an endpoint that came to it.=A0=A0=A0 I suspect there were=
 different assumptions that lead to clearly different interpretations.=A0=20

I propose that we return to the original diagrams and add the wording below=
 on how DOC agents behave.=A0 One way to look at this is that DOC agents ac=
t as back-to-back DOC endpoints.=A0 I intentionally don't say back-to-back =
Diameter endpoints because this does not impact anything except the handlin=
g of DOIC related AVPs.

Note that I don't believe this requires any changes to Diameter clients or =
servers.=A0 I also don't believe this requires any changes to the contents =
of the DOIC related AVPs but there is an open question as to whether there =
is a need to indicate when a OC-Supported-Features AVP is generated or modi=
fied by an agent.

I propose to add the following section to the section on capabilities annou=
ncement.=A0 I'll send a separate email proposing text to section 5.5 on how=
 DOC agents are to behave.=20

Regards,

Steve

-----

5.3.1 DOC Agent handling of DOIC capability exchange.

A DOC agent is defined as a Diameter agent that supports the DOIC extension=
.
 A Diameter agent that supports the DOIC extension is not necessari=
ly taking the role of a reacting DOIC endpoint.
It only takes the role of a reacting DOIC endpoint when receiving a request=
 that does not contain an OC-Supported-Features AVP.
Similarily a Diameter agent that supports the DOIC extensions is not necess=
arily taking the role of a reporting DOIC endpoint.
It only takes the role of a reporting DOIC endpoint when receiving a realm =
type request (not containing a destination host) that contains an OC-Suppor=
ted-Features AVP while it is configured to act as a reporting DOIC endpoint=
 for that realm. 

A DOC node is defined as a Diameter client, Diameter server or Diameter age=
nt that supports the DOIC extension  and decided to take the role o=
f a reacting DOIC endpoint and/or reporting DOIC endpoint .

An downstream DOIC Association is defined as the association between the DO=
IC supporting Diameter entity that sends a Diameter request message to a DO=
C agent and the DOC agent.

A upstream DOIC Association is defined as the association between a DOC age=
nt and the Diameter entity to which the DOC agent sends the Diameter reques=
t message.=A0 The following illustrated the upstream and downstream concept=
s.

=A0 DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC a=
ssociation--> DOC=A0 node
=A0 Direction of request message for a transaction ----->
=A0 Direction of answer message for a transaction <-----  this depe=
nds on the point of view: one node's downstream DOIC association is another=
 node's upstream DOIC association.   The general case is:

+---------+      +---------+     +--------+     +--------+                 =
         +--------+                +--------+
| client  |      | A1      |     | A2     |     | A3     |                 =
         | A4     |                | server |
| no DOIC |      | no DOIC |     | DOIC   |     | DOIC   |                 =
         | DOIC   |                | DOIC   |
| support |      | support |     | support|     | support|                 =
         | support|                | support|=20
+---------+      +---------+     +--------+     +--------+                 =
         +--------+                +--------+
    |                 |              |              |                      =
           |                             |
    |                 |              |<---DOIC association 1---------------=
---------->|<-------DOIC association 2-->|
    |                 |              |              |                      =
           |                             |
    |                 |              |<-----------------DOIC association 3-=
---------------------------------------->|
    |                 |              |              |                      =
           |                             |
    |                 |              |              |                      =
           |                             |
    |----1.xxR------->|---2.xxR----->|              |                      =
           |                             |
    |                 |              |---3.xxR----->|----4.xxR-------------=
---------->|                             |
    |                 |              |              |                      =
           |--------5.xxR--------------->|=20
    |                 |              |              |                      =
           |<-------6.xxA----------------|
    |                 |              |<--8.xxA------|<---7.xxA-------------=
-----------|                             |
    |<---10.xxA-------|<--9.xxA------|              |                      =
           |                             |
    |                 |              |              |                      =
           |                             |
    |                 |              |              |                      =
           |                             |
    |                 |              |              |                      =
           |                             |
    |                 |              |              |                      =
           |                             |
    |----11.xxR------>|---12.xxR---->|              |                      =
           |                             |
    |                 |              |---13.xxR---->|-----14.xxR-----------=
---------->|-------15.xxR--------------->|
    |                 |              |              |                      =
           |                             |
    |                 |              |<---18.xxA----|<----17.xxA-----------=
-----------|<-----16.xxA-----------------|
    |<---20.xxA-------|<---19.xxA----|              |                      =
           |                             |
    |                 |              |              |                      =
           |                             |
DOIC association 1 is for realm type requests; DOIC association 2 is for re=
quest for which A4 selects the server DOIC association 3 is for host type r=
equests

1. the client that does not support DOIC sends 1.xxR (realm type request no=
t containing destination host) to the next hop; 1.xxR does not contain an O=
C-Supported-Features AVP 2. the agent A1 that does not support DOIC forward=
s the request to the next hop; 2.xxR still dos not contain an OC-Supported-=
Feature AVP.
3. the agent A2 that supports DOIC decides to take the role of a reacting e=
ndpoint; it inserts an OC-Supported-Features AVP into 3.xxR indicating supp=
ort of features 1 and 2 (in this example).
4. agent A3, although it supports DOIC, does not take the role of a reactin=
g endpoint (because 3.xxR contains an OC-Supported-Features AVP); it also d=
oes not take the role of a reporting endpoint since it is not configured to=
 act as reporting endpoint for the destination realm received in 3.xxR; 4.x=
xR (unmodified) is sent to the next hop.
5. agent A4 is configured to take the role of the reporting endpoint for th=
e realm. It therefore removes the OC-Supported-Features AVP reveived in 4.x=
xR and inserts its own supported features (in this example features 1 and 3=
) in 5.xxR. A4 also selects the server to which 5.xxR is sent.
6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA incl=
uding an OLR1 (host type) requesting a feature 3 specific traffic reduction=
 (e.g. window size 20).=20
7. A4 calculates the overall realm overload level, removes the received OLR=
1 and adds its own calculated realm type OLR2 (e.g. a feature 1 specific tr=
affic reduction of 50%-loss) to 7.xxA. A4 stores OLR1 for later use.
8. A3 not taking any DOIC role forwards the answer unmodified.
9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores OLR2=
 for later use.
10. A1 not supporting DOIC is transparent.
11. client sends a new request 11.xxR (containing destination host as learn=
d from 10.xxA; no OC-Supported-Features AVP included.
12. A1 is transparent.
13. A2 decides to take the role of the reacting endpoint and includes again=
 its supported features 1 and 2 in OC-Supported-Features AVO sent within 13=
.xxR.
14. A3 is transparent
15. A4 is transparent for host type requests that contain an OC-Supported-F=
eatures AVP.
16. server returns 16.xxA including a host type OLR3 requesting a feature 1=
 specific traffic reduction of e.g. 30%-loss.
17. A4 is transparent
18. A3 is transparent
19. A2 stores OLR3 for later use and may remove OLR3 when sending 19.xxA.
20. client receives 20.xxA.


Four scenarios must be supported:

=A0 - Scenario 1 - There is both an upstream and downstream DOIC associatio=
n.
 for example see A4 in the figure above 
=A0 - Scenario 2 - There is no upstream DOIC association  do you me=
an "There is a downstream DOIC association but no upstream DOIC association=
"? Not covered in the figure above. 
=A0 - Scenario 3 - There is no downstream DOIC association  do you =
mean "There is an upstream DOIC association but no downstream DOIC associat=
ion"? for example see A2 in the figure above 
=A0 - Scenario 4 - No DOIC association in either direction  for exa=
mple see A3 in the figure above 

Scenario 1 - Both upstream and downstream DOIC associations

Request message handling:

A DOC agent that receives a request that contains the OC-Supported-Features=
 AVP must act as an endpoint for the downstream DOIC association.
 NO! see A3 receiving 3.xxR or 13.xxR (this may not be scenario 1, =
but how does the agent know which scenario applies?)

If the DOC agent relays or proxies the request message then the agent must =
include an OC-Supported-Features AVP in the relayed message.=A0 The content=
s of the OC-Supported-Features AVP must include, at a minimum, all of the c=
ontent included in the received OC-Supported-Features AVP.=A0 If the agent =
does not support any additional features then the sent OC-Supported-Feature=
s AVP will remain the same as the received OC-Supported-Features AVP.
There cannot be more than one OC-Supported-Features AVPs in one req=
uest. An agent that inserts an OC-Supported-Features AVP must remove the re=
ceived OC-Supported-Features AVP (see A4 when sending 5.xxR). The inserted =
OC-Supported Features AVP shall indicate the features the inserting node su=
pports, not more, not less

If the agent supports DOIC features that are not indicated in the received =
OC-Supported-Features AVP then the agent must modify the OC-Supported-Featu=
res AVP to indicate support for those features.=A0 The modified OC-Supporte=
d-Features AVP must be included in the relayed request message.

=A0 Note: any DOIC extension must define the changes needed to the OC-Featu=
re-Vector AVP and any additional AVPs that need to be added to the OC-Suppo=
rted-Features AVP as part of the capabilities advertisement for that featur=
e.

Question: Should there be an indication that the contents of the OC-Support=
ed-Features AVP was changed?
 no. for what reason? 

Question: Will this work when end-to-end security is introduced?=A0 Would a=
dding a separate OC-Supported-Features AVP be better, especially when end-t=
o-end security is considered?
 what is the issue? 

Answer message handling:

When an agent receives the=A0 answer message that corresponds to the above =
request message  i.e. the request message into which the agent has =
inserted its OC-Supported-Features AVP  , the agent must act as th=
e DOIC endpoint for the upstream DOIC association.=A0=20

If the DOC agent relays or proxies the answer message then the agent must i=
nclude an OC-Supported-Features AVP in the relayed message.
 OC-Supported-Features AVP in answer messages is an open issue 
=A0 The contents of the OC-Supported-Features AVP must include, at a minimu=
m, all of the content included in the received OC-Supported-Features AVP.=
=A0 If the agent does not support any additional features then the sent OC-=
Supported-Features AVP will remain the same as the received OC-Supported-Fe=
atures AVP.

If the agent supports DOIC features that are not indicated in the received =
OC-Supported-Features AVP then the agent should modify the OC-Supported-Fea=
tures AVP to indicate support for those features.=A0 The modified OC-Suppor=
ted Features AVP must be included in the relayed answer message.

Scenario 2 - No downstream DOIC association with an upstream association  wasn't that scenario 3? 

In this case a request is received that does not contain an OC-Supported-Fe=
atures AVP.

Request message handling:

If a DOC agent receives a request that does NOT contain an OC-Supported-Fea=
tures AVP then the agent must generate an OC-Supported-Features AVP reflect=
ing the DOIC features supported by the DOC agent.=A0 The new OC-Supported-F=
eatures AVP must be included in the relayed/proxied request message.

The agent will then become the reacting DOIC endpoint for the upstream DOIC=
 association that results from the transaction.=A0=20

Note: Section x.x.x defines agent behavior when it is the reacting node for=
 a DOIC association.

Answer message handling

In this case the answer message will contain an OC-Supported-Features AVP.=
=A0 The DOC agent must store the advertised capabilities for use when the D=
OC agent reacts to an overload report from the upstream Diameter node.

The DOC agent should remove the OC-Supported-Features AVP from the answer m=
essage before relaying/proxying the answer message.=A0=20

Scenario 3 - Downstream DOC association with no upstream DOIC association <=
Ulrich> wasn't this scenario 2? 

In this case a OC-Supported-Features AVP is received in the request from th=
e downstream Diameter entity but no OC-Supported-Features AVP is received i=
n the answer message received from the upstream Diameter entity.=A0 In this=
 case the agent must act as the reporting DOIC endpoint for the downstream =
DOIC association.
 this is totally new to me. Where does this come from? If a server =
does not support DOIC it cannot request load reduction from a downstream ag=
ent. The downstream agent (even if it would detect the DOIC-non-support of =
the server) cannot request load reduction from further downstream nodes on =
behalf of the server 

Request message handling:

Request message handling is the same as for scenario 1.

Answer message handling:

If a DOC agent receives an answer message that does not contain an OC-Suppo=
rted-Features AVP for a transaction that includes an upstream DOC associati=
on then the agent must generate an OC-Supported-Features AVP reflecting the=
 DOIC features supported by the DOC agent.=A0 The generation of this OC-Sup=
ported-Features AVP must also follow the rules specified in section 5.3.2.=
=A0 The new OC-Supported-Features AVP must be included in the relayed/proxi=
ed the answer message.

Scenario 4 - No upstream association and no downstream association

Request message handling:

The request message handling in this case is the same as scenario 2.

Answer message handling:

If the DOC agent receives an answer message that does not contain an OC-Sup=
ported-Features AVP for a transaction that does not include a downstream DO=
C association then the agent must NOT generate an OC-Supported-Features AVP=
.=A0 The DOC Agent must relay/proxy the answer message with no DOIC related=
 change.

 the open issue seems to be: How can an agent determine which scena=
rio is applicable? Let me try:
An agent that does not support DOIC is always in scenario 4 (no upstream DO=
IC association, no downstream DOIC association).
For an agent that supports DOIC:
When receiving a request that does not contain an OC-Supported-Features AVP=
 the agent is in scenario 3 or 4 (no downstream DOIC association). Whether =
its 3 or 4 depends on whether or not an OLR is received in the correspondin=
g answer.
When receiving a host type request (a request that contains a Destination-H=
ost AVP) that contains an OC-Supported-Feature AVP the agent is in scenario=
 4 (no upstream DOIC association, no downstream DOIC association) When rece=
iving a realm type request (a request that does not contain a Destination-H=
ost AVP) that contains an OC-Supported-Feature AVP and the agent is configu=
red to act as reporting node for that realm, the agent is scenario 1 or 2 (=
there is a downstream DOIC association). Whether its 1 or 2 depends on whet=
her or not an OLR is received in the corresponding answer.
When receiving a realm type request (a request that does not contain a Dest=
ination-Host AVP) that contains an OC-Supported-Feature AVP and the agent i=
s configured not to act as reporting node for that realm, the agent is in s=
cenario 4 (no upstream DOIC association, no downstream DOIC association). <=
/Ulrich>





_______________________________________________
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

--_002_5BCBA1FC2B7F0B4C9D935572D9000668151B2A67DEMUMBX014nsnin_
Content-Type: text/plain; name="diagram.txt"
Content-Description: diagram.txt
Content-Disposition: attachment; filename="diagram.txt"; size=5850;
	creation-date="Tue, 11 Feb 2014 10:30:28 GMT";
	modification-date="Tue, 11 Feb 2014 10:30:28 GMT"
Content-Transfer-Encoding: base64

DQorLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0rICAgICArLS0tLS0tLS0rICAgICArLS0tLS0t
LS0rICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICst
LS0tLS0tLSsNCnwgY2xpZW50ICB8ICAgICAgfCBBMSAgICAgIHwgICAgIHwgQTIgICAgIHwgICAg
IHwgQTMgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQTQgICAgIHwgICAgICAgICAg
ICAgICAgfCBzZXJ2ZXIgfA0KfCBubyBET0lDIHwgICAgICB8IG5vIERPSUMgfCAgICAgfCBET0lD
ICAgfCAgICAgfCBET0lDICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCBET0lDICAgfCAg
ICAgICAgICAgICAgICB8IERPSUMgICB8DQp8IHN1cHBvcnQgfCAgICAgIHwgc3VwcG9ydCB8ICAg
ICB8IHN1cHBvcnR8ICAgICB8IHN1cHBvcnR8ICAgICAgICAgICAgICAgICAgICAgICAgICB8IHN1
cHBvcnR8ICAgICAgICAgICAgICAgIHwgc3VwcG9ydHwgDQorLS0tLS0tLS0tKyAgICAgICstLS0t
LS0tLS0rICAgICArLS0tLS0tLS0rICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAg
ICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICstLS0tLS0tLSsNCiAgICB8ICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAg
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHw8LS0tRE9JQyBhc3NvY2lhdGlvbiAxLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLT58PC0tLS0tLS1ET0lDIGFzc29jaWF0aW9uIDItLT58DQogICAg
fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0t
RE9JQyBhc3NvY2lhdGlvbiAzLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0+fA0KICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAg
IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwNCiAgICB8LS0tLTEueHhSLS0tLS0tLT58LS0tMi54eFItLS0tLT58ICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg
IHwtLS0zLnh4Ui0tLS0tPnwtLS0tNC54eFItLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwt
LS0tLS0tLTUueHhSLS0tLS0tLS0tLS0tLS0tPnwgDQogICAgfCAgICAgICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHw8LS0tLS0tLTYueHhBLS0tLS0tLS0tLS0tLS0tLXwNCiAgICB8ICAgICAgICAgICAgICAg
ICB8ICAgICAgICAgICAgICB8PC0tOC54eEEtLS0tLS18PC0tLTcueHhBLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHw8LS0tMTAueHhB
LS0tLS0tLXw8LS05Lnh4QS0tLS0tLXwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8
ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K
ICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8DQogICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwNCiAgICB8LS0tLTExLnh4Ui0tLS0tLT58LS0tMTIueHhSLS0tLT58ICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwtLS0x
My54eFItLS0tPnwtLS0tLTE0Lnh4Ui0tLS0tLS0tLS0tLS0tLS0tLS0tLT58LS0tLS0tLTE1Lnh4
Ui0tLS0tLS0tLS0tLS0tLT58DQogICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICB8PC0tLTE4Lnh4QS0tLS18PC0tLS0xNy54eEEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tfDwt
LS0tLTE2Lnh4QS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgIHw8LS0tMjAueHhBLS0tLS0tLXw8LS0t
MTkueHhBLS0tLXwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCkRPSUMgYXNzb2NpYXRpb24g
MSBpcyBmb3IgcmVhbG0gdHlwZSByZXF1ZXN0czsgRE9JQyBhc3NvY2lhdGlvbiAyIGlzIGZvciBy
ZXF1ZXN0IGZvciB3aGljaCBBNCBzZWxlY3RzIHRoZSBzZXJ2ZXIsIERPSUMNCiBhc3NvY2lhdGlv
biAzIGlzIGZvciBob3N0IHR5cGUgcmVxdWVzdHMNCg0KMS4gdGhlIGNsaWVudCB0aGF0IGRvZXMg
bm90IHN1cHBvcnQgRE9JQyBzZW5kcyAxLnh4UiAocmVhbG0gdHlwZSByZXF1ZXN0IG5vdCBjb250
YWluaW5nIGRlc3RpbmF0aW9uIGhvc3QpIHRvIHRoZSBuZXh0DQogaG9wOyAxLnh4UiBkb2VzIG5v
dCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgDQoyLiB0aGUgYWdlbnQgQTEg
dGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMgZm9yd2FyZHMgdGhlIHJlcXVlc3QgdG8gdGhlIG5l
eHQgaG9wOyAyLnh4UiBzdGlsbCBkb3Mgbm90IGNvbnRhaW4gYW4NCiBPQy1TdXBwb3J0ZWQtRmVh
dHVyZSBBVlAuDQozLiB0aGUgYWdlbnQgQTIgdGhhdCBzdXBwb3J0cyBET0lDIGRlY2lkZXMgdG8g
dGFrZSB0aGUgcm9sZSBvZiBhIHJlYWN0aW5nIGVuZHBvaW50OyBpdCBpbnNlcnRzIGFuIE9DLVN1
cHBvcnRlZC1GZWF0dXJlcw0KIEFWUCBpbnRvIDMueHhSIGluZGljYXRpbmcgc3VwcG9ydCBvZiBm
ZWF0dXJlcyAxIGFuZCAyIChpbiB0aGlzIGV4YW1wbGUpLg0KNC4gYWdlbnQgQTMsIGFsdGhvdWdo
IGl0IHN1cHBvcnRzIERPSUMsIGRvZXMgbm90IHRha2UgdGhlIHJvbGUgb2YgYSByZWFjdGluZyBl
bmRwb2ludCAoYmVjYXVzZSAzLnh4UiBjb250YWlucyBhbg0KIE9DLVN1cHBvcnRlZC1GZWF0dXJl
cyBBVlApOyBpdCBhbHNvIGRvZXMgbm90IHRha2UgdGhlIHJvbGUgb2YgYSByZXBvcnRpbmcgZW5k
cG9pbnQgc2luY2UgaXQgaXMgbm90IGNvbmZpZ3VyZWQgdG8gYWN0DQogYXMgcmVwb3J0aW5nIGVu
ZHBvaW50IGZvciB0aGUgZGVzdGluYXRpb24gcmVhbG0gcmVjZWl2ZWQgaW4gMy54eFI7IDQueHhS
ICh1bm1vZGlmaWVkKSBpcyBzZW50IHRvIHRoZSBuZXh0IGhvcC4NCjUuIGFnZW50IEE0IGlzIGNv
bmZpZ3VyZWQgdG8gdGFrZSB0aGUgcm9sZSBvZiB0aGUgcmVwb3J0aW5nIGVuZHBvaW50IGZvciB0
aGUgcmVhbG0uIEl0IHRoZXJlZm9yZSByZW1vdmVzIHRoZQ0KIE9DLVN1cHBvcnRlZC1GZWF0dXJl
cyBBVlAgcmV2ZWl2ZWQgaW4gNC54eFIgYW5kIGluc2VydHMgaXRzIG93biBzdXBwb3J0ZWQgZmVh
dHVyZXMgKGluIHRoaXMgZXhhbXBsZSBmZWF0dXJlcyAxIGFuZCAzKQ0KIGluIDUueHhSLiBBNCBh
bHNvIHNlbGVjdHMgdGhlIHNlcnZlciB0byB3aGljaCA1Lnh4UiBpcyBzZW50Lg0KNi4gdGhlIHNl
cnZlciAodGhhdCBzdXBwb3J0cyBET0lDIGUuZy4gZmVhdHVyZXMgMSBhbmQgMykgcmV0dXJucyA2
Lnh4QSBpbmNsdWRpbmcgYW4gT0xSMSAoaG9zdCB0eXBlKSByZXF1ZXN0aW5nIGENCiBmZWF0dXJl
IDMgc3BlY2lmaWMgdHJhZmZpYyByZWR1Y3Rpb24gKGUuZy4gd2luZG93IHNpemUgMjApLiANCjcu
IEE0IGNhbGN1bGF0ZXMgdGhlIG92ZXJhbGwgcmVhbG0gb3ZlcmxvYWQgbGV2ZWwsIHJlbW92ZXMg
dGhlIHJlY2VpdmVkIE9MUjEgYW5kIGFkZHMgaXRzIG93biBjYWxjdWxhdGVkIHJlYWxtIHR5cGUN
CiBPTFIyIChlLmcuIGEgZmVhdHVyZSAxIHNwZWNpZmljIHRyYWZmaWMgcmVkdWN0aW9uIG9mIDUw
JS1sb3NzKSB0byA3Lnh4QS4gQTQgc3RvcmVzIE9MUjEgZm9yIGxhdGVyIHVzZS4NCjguIEEzIG5v
dCB0YWtpbmcgYW55IERPSUMgcm9sZSBmb3J3YXJkcyB0aGUgYW5zd2VyIHVubW9kaWZpZWQuDQo5
LiBhZ2VudCBBMiBtYXkgcmVtb3ZlIHRoZSByZXZlaXZlZCBPTFIyIHdoZW4gc2VuZGluZyA5Lnh4
QS4gQTIgc3RvcmVzIE9MUjIgZm9yIGxhdGVyIHVzZS4NCjEwLiBBMSBub3Qgc3VwcG9ydGluZyBE
T0lDIGlzIHRyYW5zcGFyZW50Lg0KMTEuIGNsaWVudCBzZW5kcyBhIG5ldyByZXF1ZXN0IDExLnh4
UiAoY29udGFpbmluZyBkZXN0aW5hdGlvbiBob3N0IGFzIGxlYXJuZCBmcm9tIDEwLnh4QTsgbm8g
T0MtU3VwcG9ydGVkLUZlYXR1cmVzDQogQVZQIGluY2x1ZGVkLg0KMTIuIEExIGlzIHRyYW5zcGFy
ZW50Lg0KMTMuIEEyIGRlY2lkZXMgdG8gdGFrZSB0aGUgcm9sZSBvZiB0aGUgcmVhY3RpbmcgZW5k
cG9pbnQgYW5kIGluY2x1ZGVzIGFnYWluIGl0cyBzdXBwb3J0ZWQgZmVhdHVyZXMgMSBhbmQgMiBp
bg0KIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVk8gc2VudCB3aXRoaW4gMTMueHhSLg0KMTQuIEEz
IGlzIHRyYW5zcGFyZW50DQoxNS4gQTQgaXMgdHJhbnNwYXJlbnQgZm9yIGhvc3QgdHlwZSByZXF1
ZXN0cyB0aGF0IGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUC4NCjE2LiBzZXJ2
ZXIgcmV0dXJucyAxNi54eEEgaW5jbHVkaW5nIGEgaG9zdCB0eXBlIE9MUjMgcmVxdWVzdGluZyBh
IGZlYXR1cmUgMSBzcGVjaWZpYyB0cmFmZmljIHJlZHVjdGlvbiBvZiBlLmcuIDMwJS1sb3NzLg0K
MTcuIEE0IGlzIHRyYW5zcGFyZW50DQoxOC4gQTMgaXMgdHJhbnNwYXJlbnQNCjE5LiBBMiBzdG9y
ZXMgT0xSMyBmb3IgbGF0ZXIgdXNlIGFuZCBtYXkgcmVtb3ZlIE9MUjMgd2hlbiBzZW5kaW5nIDE5
Lnh4QS4NCjIwLiBjbGllbnQgcmVjZWl2ZXMgMjAueHhBLg0K

--_002_5BCBA1FC2B7F0B4C9D935572D9000668151B2A67DEMUMBX014nsnin_--


From lionel.morand@orange.com  Tue Feb 11 02:35:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E355E1A095D for ; Tue, 11 Feb 2014 02:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18jmDNzHow2J for ; Tue, 11 Feb 2014 02:35:49 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCBE1A07D5 for ; Tue, 11 Feb 2014 02:35:48 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 548EE374361; Tue, 11 Feb 2014 11:35:47 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 36F793840C9; Tue, 11 Feb 2014 11:35:47 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 11:35:46 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjw///bTtA=
Date: Tue, 11 Feb 2014 10:35:46 +0000
Message-ID: <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E499B60PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:35:57 -0000

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

QXQgbGVhc3QsIGl0IGlzIG5vdCAidGhlIG9ubHkgc3VyZSB3YXkiLg0KRm9yIGluc3RhbmNlLCBz
dWJzZXF1ZW50IG1lc3NhZ2VzIHBhcnQgb2YgdGhlIHNhbWUgc2Vzc2lvbiAob3IgcHNldWRvLXNl
c3Npb24pIGNvdWxkIGFsc28gYmUgdXNlZCBhcyBpbmRpY2F0aW9uIGZvciB0aGUgcmVwb3J0aW5n
IG5vZGUgdGhhdCB0aGUgT0xSIGhhcyBiZWVuIHJlY2VpdmVkIGJ5IHRoZSByZWFjdGluZyBub2Rl
IChiZXNpZGVzIHRoZSByZWNlcHRpb24gb2YgdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBpbiB0
aGUgcmVxdWVzdCkuDQpJdCBpcyB3aHkgSSB3YXMgc2F5aW5nIHRoYXQgdGhpcyBjYW4gYmUgZml4
ZWQgcGVyIGFwcGxpY2F0aW9uL3N5c3RlbS4NCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6IEJhcnRvbG9t
ZQ0KRW52b3nDqSA6IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTE6MzENCsOAIDogZGltZUBpZXRm
Lm9yZw0KT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcNCg0KRmluZSBOaXJhdiwgSSBhZ3JlZSB0aGlzIGlzIGltcGxlbWVudGF0aW9uIHNw
ZWNpZmljLg0KTXkgaW50ZW50aW9uIGlzIHRoYXQgYW55IHJlYWRlciByZWFsaXplcyB3aGF0IHRo
aXMga25vd2xlZGdlIGluIHRoZSBzZXJ2ZXIgaW1wbGllcyB3aGVuIHdlIHRhbGsgYWJvdXQgYWdl
bnRzIGluIHRoZSBwYXRoLiBUaGlzIGlzIHdoeSBJIHRoaW5rIHRoaXMgbm90ZSBpcyBoZWxwZnVs
Lg0KDQpSZWdhcmRzDQovTUNydXoNCg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0
bzpuc2Fsb3RAY2lzY28uY29tXQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQg
MTE6MjYNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDog
UkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkg
ZG8gbm90IGFncmVlIHJlZ2FyZGluZyB0aGUgY29tcGxleGl0eSBzaW5jZSBpdCBpcyBoaWdobHkg
aW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpMZXRzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGlu
IHRoZSBwcm90b2NvbCBkZXNpZ24uDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBb
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFy
dG9sb21lDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCAzOjU0IFBNDQpUbzogZGlt
ZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpIZWxsbywNCg0KSSB0aGlu
ayBpdCBpcyBpbXBvcnRhbnQgdG8gaGlnaGxpZ2h0IGNvbXBsZXhpdHkgZm9yIHRoZSBzZXJ2ZXIg
dG8gIOKAnGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2Vp
dmVkIHRoZSBvdmVybG9hZCByZXBvcnQu4oCdDQpJIHRoaW5rIHRoaXMgaXMgdGhlIHB1cnBvc2Ug
b2YgdGhlIHNlbnRlbmNlIGFkZGVkIGJ5IFN0ZXZlLg0KDQpDaGVlcnMNCi9NQ3J1eg0KDQpGcm9t
OiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmlyYXYg
U2Fsb3QgKG5zYWxvdCkNClNlbnQ6IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIw
DQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb20+OyBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nDQoNCkkgYW0gYWxzbyBmaW5lIHdpdGggU3RldmUncyBwcm9wb3NlZCB3b3JkaW5nIHRv
IHJlY29tbWVuZCB0aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQgdG8gbm90IG1hbmRhdGUgaXQuDQoN
CkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBhYnNvbHV0
ZWx5IG5lY2Vzc2FyeSB0byBhZGQgaXQuDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhv
dXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBo
YXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUg
aXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQg
dGhlIHJlcG9ydGluZyBub2RlLg0KDQpJIHByZWZlciB0byByZW1vdmUgaXQgc2luY2UgSSBkbyBu
b3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERp
TUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9y
YW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4NClNlbnQ6IE1v
bmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE0NClRvOiBTdGV2ZSBEb25vdmFuOyBkaW1l
QGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkknbSBmaW5lIHdpdGggYSBy
ZWNvbW1lbmRhdGlvbi4NCg0KQnV0IEkgaGF2ZSBhIGdlbmVyYWwgY29tbWVudDogd2hlbiBhIE1B
WSBvciBldmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgTk9U
IHVwIHRvIHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0byBkbyBzb21ldGhpbmcuIEl0IGRvZXMgbm90
IG1lYW4gdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi4NCkZvciBpbnN0
YW5jZSwgb3ZlciBhIGdpdmVuIGludGVyZmFjZSwgdGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBj
YW4gc2F5IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1haW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5k
IGl0IGNvdWxkIGJlIGRlY2lkZWQgdG8gYWRkIHNvbWUgb3ZlcmxvYWQgcmVsYXRlZCBpbmZvIGlu
IHN1Y2ggc3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBz
dGF0ZSB0byBrbm93IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBm
b3IgaW5zdGFuY2UuIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVk
IHRvIGluY2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVzc2FnZS4gSXQgaXMganVzdCBmb3IgaWxsdXN0
cmF0aW9uLiBUaGUgcG9pbnQgaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hp
Y2ggdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLg0KDQpJIGFn
cmVlIHRoYXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIGlzIGZpbmXigKYgYnV0IGl0
IHNob3VsZCBiZSBub3QgbWFuZGF0b3J5IGluIGFsbCBjYXNlcyBJIHRoaW5rLiBTbyBPSyBmb3Ig
YSAiU0hPVUxEIiBvciAiUkVDT01NRU5ERUQiLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KRGUg
OiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZl
IERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAxMCBmw6l2cmllciAyMDE0IDE3OjIxDQrDgCA6IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJIGFncmVlIHdpdGggYm90
aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pDQoNCkkgc3VnZ2VzdCB0aGF0IHdlIGhhdmUgd29y
ZGluZyBzYXlpbmcgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIHRvIGluY2x1ZGUgdGhlIG92
ZXJsb2FkIHJlcG9ydCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZWFzb25zIGxp
c3RlZCBieSBNYXJpYSBDcnV6Lg0KDQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmly
YXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0
aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQg
bWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4gIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0
byBpbmNsdWRpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyBi
dXQgd2Ugc2hvdWxkIGluY2x1ZGUgd29yZGluZyBhYm91dCBuZXR3b3JrcyBhcmNoaXRlY3R1cmVz
IHRoYXQgbWFrZSBpdCBkaWZmaWN1bHQgdG8ga25vdy4gIFRoZSBjYXNlIG9mIGFnZW50cyBhY3Rp
bmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25l
IGV4YW1wbGUuDQoNCldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5k
ZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLg0KDQpJIHBy
b3Bvc2UgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBs
ZW1lbnRlZCBieSBNYXJpYSBDcnV6J3MgcmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhl
IG92ZXJsb2FkIHJlcG9ydCBpcyBhbHdheXMgaW5jbHVkZWQuDQoNCi0tLS0tDQoNCkEgcmVwb3J0
aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcg
b3ZlcmxvYWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBu
b2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQg
dG8gcmVhY3Rpbmcgbm9kZXMuDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28g
aW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5v
biByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiAgVGhlIG92ZXJsb2Fk
IHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2Vz
IG5vdCBzdXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qg
c2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFy
YW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3Zl
cmxvYWQgcmVwb3J0Lg0KDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJp
ZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2
ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGll
bnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9y
dGluZyBub2RlLg0KT24gMi8xMC8xNCAzOjUyIEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90
ZToNCg0KSGVsbG8gTmlyYXYsDQoNCg0KDQpBbnkgc29sdXRpb24gc2hvdWxkIGJhbGFuY2UgZGlm
ZmVyZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291bGQgYmUgZGlzY3Vzc2VkIGZyb20gZGlmZmVy
ZW50IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQgdG8gYXNzdXJlIHRoZSBtZWNoYW5p
c20gd2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGluZyB2YWxpZCBPTFIgdG8gcmVhY3Rpbmcgbm9k
ZXMuDQoNCg0KDQpZb3VyIHByb3Bvc2VkIHRleHQNCg0KIiBBZGRpdGlvbmFsbHksIGluIG90aGVy
IGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUg
b3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUs
IHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwg
dG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KDQoN
Cg0KSWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3Zl
cmxvYWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVj
aWRlcyAoc2luY2UgaXQgaXMgYSAibWF5IikgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2Fpbiwg
dGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2Ug
T0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwg
cmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMi
IGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91
dGluZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBS
ZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRp
bmcgY2xpZW50KS4NCg0KVGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93
IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJl
bG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQg
Im1heSIpIHRoZW4gb25lIG9yIG11bHRpcGxlIHJlYWN0aW5nIG5vZGVzIGRvIG5vdCBoYXZlIHRo
ZSByZXF1aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlvbiB3aWxsIG5vdCB3b3JrLg0K
DQoNCg0KVGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3Zp
ZGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMu
DQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNj
by5jb21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDINCg0KVG86
IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcNCg0KDQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQoNCg0KSG93IGNhbiB3ZSBzYXkgdGhh
dCAiaW5jbHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMgaXMgc2ltcGxl
IGFuZCBlZmZpY2llbnQ/Ig0KDQpJdCBpcyBzaW1wbGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZpY2ll
bnQuDQoNCg0KDQpBIHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bv
c2VkIGVhcmxpZXIgaXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9h
ZCByZXBvcnQgdGhhdCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5
IHVwZGF0aW5nIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92
aWRpbmcgdGhlIG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBp
bmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0Mt
U3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5n
IG5vZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0
aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBw
cm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNs
dWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9D
LVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQoNClNlbnQ6
IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMzowMyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxt
YWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpOaXJhdiwgYWxsLA0KDQoNCg0KSSB0
aGluayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFz
IGVmZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KDQpJIHVuZGVyc3RhbmQgeW91ciBw
cm9wb3NhbCBhcyBhIHB1cmUgIm1heSIsIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0
aW9uIGRvZXMgbm90IGFzc3VyZSByZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRp
b24sIHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuDQoNCg0KDQpCZXN0
IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpG
cm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNl
bnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6MTINCg0KVG86IE1hcmlhIENydXog
QmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0
OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
DQoNCk1hcmlhLUNydXosDQoNCg0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91IG9uICJzZW5kaW5n
IE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlcyIuDQoNCkFu
ZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBteSBp
bnRlbnRpb24uDQoNCkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBw
cmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNt
YXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFu
c3dlciBtZXNzYWdlPw0KDQoNCg0KTW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVt
ZW50YXRpb24gb2Ygb3ZlcmxvYWQgY29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUg
YW5zd2VyIG1lc3NhZ2VzLg0KDQpCdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0
byByZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmlj
ZSB0d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9u
IGluIGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1
bCBhbmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0
aW9uLg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KDQoNClRoaXMgYWxzbyB0aGUgcmVhc29uIEkg
d2FzIHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAo
ZnJvbSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuDQoNCg0KDQpSZWdhcmRzLA0K
DQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUg
W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJh
cnRvbG9tZQ0KDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE0NCg0KVG86
IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSGVsbG8g
VWxyaWNoLCBOaXJhdiwNCg0KDQoNCkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBw
cm92aWRlZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNl
cnZlciBzZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVku
DQoNCg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9u
IHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25v
d2xlZGdlOg0KDQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcg
bm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCg0KYikgdGhlIHJlcG9ydGluZyBu
b2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBh
bmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwg
c29vbiBleHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoNCg0KDQpSZXBvcnRpbmcgbm9kZSBtdXN0IGhh
dmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcg
bm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBrbm93bGVkZ2U/DQoNClRha2UgaW50
byBhY2NvdW50IGFzIHdlbGwgdGhhdCBhICJyZWFjdGluZyIgbm9kZSBtYXkgYmUgYm90aCBhbiBB
Z2VudCAoaW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2aWNlIHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9u
IGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkgIGFuZCBhIENsaWVudC4gSW4gdGhl
IGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYg
dGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJl
bnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3ds
ZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC4N
Cg0KDQoNClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4g
QUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXM6DQoNCi0gc3RhdGUtbGVz
cyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikgaXMgc2ltcGxlciwNCg0K
LSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRv
IHNlbmQgYW4gT0wgdG8gYSByZWFjdGluZyBub2RlDQoNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBu
ZWVkIHRvIGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2
ZWQgYW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhw
aXJlZCkuDQoNCi0gc2VuZGluZyBhbiBhZGRpdGlvbmFsIEFWUCBpcyBub3QgcHJvY2Vzc2luZyBj
b25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRo
aXMgaXMgbm90IHNlbnQpLg0KDQogIEluIGZhY3QsIGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwg
dGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQg
dG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsDQoNCiAgYW5kIHRoZSBsYXR0ZXIgc2hv
dWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMNCg0KLSBtb3JlIHJvYnVz
dCBzb2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVja3Mgb24gdGhl
IG5lZWQgdG8gc2VuZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dl
ciBtZXNzYWdlIGlzIGxvc3QsICDigKYNCg0KDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6
DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0g
REUvTXVuaWNoKQ0KDQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTkN
Cg0KVG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IGxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgZXh0IFN0ZXZlIERvbm92YW47
IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYs
DQoNCg0KDQpJJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRo
ZSBpbnRlbnRpb24uDQoNCg0KDQoid2hlbiBpdCB3YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5p
dCBzaGFsbCBpbmNsdWRlLi4uIiB0cmFuc2xhdGVzIHRvICIuLi5pdCBtYXkgaW5jbHVkZS4uLiIu
DQoNCg0KDQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMg
dG8gIndoZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQoNCg0K
DQpXZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6DQoNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBr
bm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9M
Ug0KDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBu
b3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhh
cyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KDQpjKSBvdGhlcndpc2UNCg0KDQoN
CmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUg
T0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUg
dGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBv
cnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0
aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBk
YXRlKQ0KDQoNCg0KVWxyaWNoDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cg0KRnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNv
bV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkgUE0NCg0KVG86IFdp
ZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGV4dCBTdGV2ZSBEb25vdmFuOyBk
aW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNClVscmljaCwN
Cg0KDQoNCkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUg
cHJvcG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuDQoNCkhvdyBhYm91dCB0aGUg
Zm9sbG93aW5nLg0KDQoNCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlk
ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92
aWRlZCBvdmVybG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGlu
Y2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1T
dXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcg
bm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRp
bmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHBy
b3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1
ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0Mt
U3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5
LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNDQoNClRvOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFu
Z2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBOaXJhdiBTYWxvdCAobnNh
bG90KTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5v
cmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsIExpb25lbCwNCg0KDQoNCkkgY2FuIHVuZGVyc3RhbmQg
TmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMg
YWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lwbGUgMic6DQoNCg0KDQoyJy4gdGhlIHJl
cG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRl
Y2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBj
b250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29u
dHJvbCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9M
UiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBv
dmVybG9hZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24gZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9y
dGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5v
dCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9h
ZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3
aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KSSBkb24n
dCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQg
Y29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5v
dCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkg
YXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xS
cy4NCg0KDQoNClVscmljaA0KDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9y
YW5kQG9yYW5nZS5jb20+IFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KDQpTZW50
OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NCg0KVG86IE5pcmF2IFNhbG90
IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9u
b3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQoN
Cg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IERpTUUgW21haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkg
RW52b3nDqSA6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCA6IFdpZWhlLCBVbHJpY2gg
KE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0
bzpkaW1lQGlldGYub3JnPiBPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KVWxyaWNoLA0KDQoNCg0KSSBhbSBub3Qgc3VyZSBh
Ym91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAo
aS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVy
IHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25z
ZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFW
UC4iDQoNClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1
bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJl
YWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZmaWMuDQoNCg0KDQpbTE1d
IEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhl
IGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4g
dGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3
ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9u
LiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLg0KDQoNCg0KQXMgd2Ug
aGFkIGRpc2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5n
IG5vZGUgdG8gZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2Rl
IGF0IHRoZSBzYW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2Fu
IGFsbG93IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyBy
YW1wIG9mIHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0Lg0KDQoNCg0KW0xNXSBBZ3Jl
ZQ0KDQoNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGlu
ZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcg
dGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0byBpbmNsdWRl
IE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9uLg0KDQoNCg0K
W0xNXSBBZ3JlZQ0KDQoNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3
aXRoIG1lLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04g
LSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNDQoNClRvOiBleHQgU3RldmUgRG9ub3Zhbjsg
TmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxl
czoNCg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSINCg0KMi4gdGhlIHJlcG9ydGlu
ZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBu
b3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWlu
ZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJl
YWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUg
YW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcg
Im5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRo
ZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1V
U1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVk
IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNv
bmZpcm0uDQoNCg0KDQpVbHJpY2gNCg0KDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KDQpTZW50OiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fs
b3QpOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkFn
cmVlZC4gIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3Qg
Y2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS4g
IElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBj
b250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNp
dGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCByZXBvcnQuICBJZiB0aGVyZSBpcyBubyBj
dXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQg
cmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFs
bS4NCg0KDQoNClN0ZXZlDQoNCk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90
KSB3cm90ZToNCg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKA
mXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KDQoNCg0K
V2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQg
aXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9M
UiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJs
ZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50
cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRo
aXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBu
b3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuDQoNCg0KDQpTbyBi
YXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNs
eSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNh
biBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBv
ZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBv
dmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQoNCkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZv
ciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5k
IGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KDQoNClJlZ2FyZHMsDQoN
Ck5pcmF2Lg0KDQoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw
NSwgMjAxNCA4OjAwIFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcNCg0KDQoNCmlubGluZQ0KDQpPbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmlj
aCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCg0KT2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJl
cG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVz
c2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBh
biBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24g
aXMgcmVxdWVzdGVkKS4NCg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/ICBTaG91
bGRuJ3QgbGFjayBvZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoN
Cg0KDQoNCg0KDQoNCg0KDQpPdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5v
dCBzZWVtIHRvIG1hdHRlci4NCg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGlu
IGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFu
IG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29y
aywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4NCg0KDQoN
Cg0KDQoNCg0KDQoNCkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNl
aXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJv
Y2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Np
bmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlz
ayB0b28gbWlzcyBhIG5ldyBPTFI/DQoNClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUg
c2VxdWVuY2UgbnVtYmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNCg0KU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNDQoNClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208
bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRp
bWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSSBzaGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExp
b25lbC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tPg0KDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQoN
ClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkkg
dW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5v
ZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLg0KDQpTbyB0aGUgb3B0
aW9ucyB3b3VsZCBiZToNCg0KMS0gT0MtT0xSIEFWUCBpbiBldmVyeSBhbnN3ZXINCg0KMi0gT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQ
IGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkg
dGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQoNCg0KSWYgdGhlcmUgaXMgbm8gb3Ro
ZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQoNCg0K
DQpMaW9uZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IGRpbWUg
aXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0KDQpF
bnZvecOpIDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5DQoNCsOAIDogTU9SQU5EIExpb25l
bCBJTVQvT0xODQoNCkNjIDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0K
T2JqZXQgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQoj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCiBJdCBoYXMgYmVlbiBwcm9w
b3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMg
IHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRp
Y2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQoNCiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29y
ZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQoNCiBzdXJ2aXZlZCkgaXMg
cGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBu
byAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuICBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5
IHVzZSB0aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBp
cyBhIG5lZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBs
YXRlc3QgT0xSLg0KDQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCBy
ZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIg
QVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCBjYW5u
b3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRv
aW5nICB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0
bGluZy4NCg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0bmVzcyBhcyBp
dCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJl
Y3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZyAgRE9JQyBlbmRwb2lu
dCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQoNCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNt
IGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQoNCiBJbiBzdW1t
YXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIHRvICBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcuDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFp
bHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZGltZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv
aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv
dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBs
b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt
ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0
IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl
bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNs
aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv
cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u
IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli
dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg
YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxz
IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo
YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpE
aU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0K
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxp
c3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0
Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpE
aU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp
bWUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw
ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp
bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl
cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh
Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQg
bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs
ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRl
Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl
Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp
b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRp
c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlv
dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl
bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBl
bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0
aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlv
dS4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv
bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl
dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg
c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1
ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu
c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh
bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u
c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu
IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u
ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk
IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3
aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu
b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv
ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN
CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg
NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl
LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBT
aW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpUaW1lczsNCglwYW5vc2UtMToyIDIgNiAzIDUgNCA1IDIgMyA0O30NCi8qIFN0
eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y
bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpi
bGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIi
Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFj
azt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7
DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpz
cGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwg
Q2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3Jt
YXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFu
LlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVs
bGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7
fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZv
cm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk
Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ
Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5CYWxsb29uVGV4dCwgbGku
QmFsbG9vblRleHQsIGRpdi5CYWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU
ZXh0IjsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxv
b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250
LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYx
O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt
YWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1
cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi
Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94
bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXQgbGVhc3QsIGl0IGlzIG5vdCAmcXVvdDt0aGUgb25seSBz
dXJlIHdheSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkZvciBpbnN0YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdlcyBwYXJ0IG9mIHRoZSBzYW1lIHNlc3Np
b24gKG9yIHBzZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNvIGJlIHVzZWQgYXMgaW5kaWNhdGlvbiBm
b3IgdGhlIHJlcG9ydGluZyBub2RlIHRoYXQgdGhlDQogT0xSIGhhcyBiZWVuIHJlY2VpdmVkIGJ5
IHRoZSByZWFjdGluZyBub2RlIChiZXNpZGVzIHRoZSByZWNlcHRpb24gb2YgdGhlIE9DLVN1cHBv
cnRlZC1GZWF0dXJlcyBpbiB0aGUgcmVxdWVzdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5JdCBpcyB3aHkgSSB3YXMgc2F5aW5nIHRoYXQgdGhpcyBjYW4gYmUg
Zml4ZWQgcGVyIGFwcGxpY2F0aW9uL3N5c3RlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+TGlvbmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj
bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IE1hcmlhIENydXogQmFydG9sb21lPGJyPg0K
PGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTE6MzE8YnI+DQo8
Yj7DgCZuYnNwOzo8L2I+IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJl
OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmluZSBOaXJhdiwgSSBhZ3Jl
ZSB0aGlzIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgaW50ZW50aW9uIGlzIHRoYXQgYW55IHJlYWRlciByZWFs
aXplcyB3aGF0IHRoaXMga25vd2xlZGdlIGluIHRoZSBzZXJ2ZXIgaW1wbGllcyB3aGVuIHdlIHRh
bGsgYWJvdXQgYWdlbnRzIGluIHRoZSBwYXRoLiBUaGlzIGlzIHdoeSBJIHRoaW5rIHRoaXMNCiBu
b3RlIGlzIGhlbHBmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy
ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9NQ3J1ejxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFp
bHRvOm5zYWxvdEBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gbWFydGVzLCAxMSBkZSBm
ZWJyZXJvIGRlIDIwMTQgMTE6MjY8YnI+DQo8Yj5Ubzo8L2I+IE1hcmlhIENydXogQmFydG9sb21l
OyBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIGRvIG5vdCBh
Z3JlZSByZWdhcmRpbmcgdGhlIGNvbXBsZXhpdHkgc2luY2UgaXQgaXMgaGlnaGx5IGltcGxlbWVu
dGF0aW9uIHNwZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2
MSI+TGV0cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBpbiB0aGUgcHJvdG9jb2wgZGVzaWduLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5NYXJpYSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFy
eSAxMSwgMjAxNCAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86ZGltZUBp
ZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIGl0IGlz
IGltcG9ydGFudCB0byBoaWdobGlnaHQgY29tcGxleGl0eSBmb3IgdGhlIHNlcnZlciB0byAmbmJz
cDvigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7Ij5ndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3RpbmcNCiBub2RlIGFscmVh
ZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhpcyBpcyB0aGUgcHVy
cG9zZSBvZiB0aGUgc2VudGVuY2UgYWRkZWQgYnkgU3RldmUuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj
bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUg
WzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5OaXJhdiBTYWxvdCAobnNhbG90
KTxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyMDxi
cj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgU3RldmUgRG9ub3ZhbjsNCjxhIGhyZWY9Im1h
aWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzI0NDA2MSI+SSBhbSBhbHNvIGZpbmUgd2l0aCBTdGV2ZSdzIHByb3Bvc2VkIHdvcmRpbmcg
dG8gcmVjb21tZW5kIHRoZSBpbmNsdXNpb24gb2YgT0xSIGJ1dCB0byBub3QgbWFuZGF0ZSBpdC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBhbSBub3Qgc3VyZSBhYm91dCB0
aGUgZm9sbG93aW5nIHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIGFkZCBp
dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk5vdGUg
LSB0aGUgb25seSBzdXJlIHdheSwgd2l0aG91dCBwcm9wcmlldGFyeSBtZWNoYW5pc21zLCB0byBr
bm93IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBvcnQg
aXMgd2hlbiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIGNsaWVudCBhbmQgdGhlcmUgaXMgbm8gYWdl
bnQgYmV0d2VlbiB0aGUgY2xpZW50DQogYW5kIHRoZSByZXBvcnRpbmcgbm9kZS48L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBwcmVmZXIgdG8gcmVtb3ZlIGl0IHNp
bmNlIEkgZG8gbm90IHNlZSBhcyB2YWx1ZSBhZGRpdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERp
TUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+PGJy
Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE08YnI+DQo8
Yj5Ubzo8L2I+IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5k
aW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSdtIGZpbmUg
d2l0aCBhIHJlY29tbWVuZGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5CdXQgSSBoYXZlIGEgZ2VuZXJhbCBjb21tZW50OiB3aGVuIGEgTUFZIG9yIGV2ZW4gYSBTSE9V
TEQgYXBwbHksIGl0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBOT1QgdXAgdG8gdGhlIG5vZGUg
dG8gZG8gb3Igbm90IHRvIGRvIHNvbWV0aGluZy4gSXQNCiBkb2VzIG5vdCBtZWFuIHRoYXQgaXQg
aXMgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIG92ZXIgYSBnaXZlbiBpbnRlcmZhY2Us
IHRoZSByZWxhdGVkIHNwZWNpZmljYXRpb24gY2FuIHNheSB0aGF0IHNvbWUgc3RhdGVzIGFyZSBt
YWludGFpbmVkIGJ5IHRoZSBzZXJ2ZXIuIEFuZCBpdCBjb3VsZCBiZSBkZWNpZGVkDQogdG8gYWRk
IHNvbWUgb3ZlcmxvYWQgcmVsYXRlZCBpbmZvIGluIHN1Y2ggc3RhdGVzLiBGb3IgaW5zdGFuY2Ug
YWdhaW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0byBrbm93IGlmIGEgcmVtb3RlIG5v
ZGUgaGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5zdGFuY2UuIEFuZCBpbiBzdWNoIGEg
Y2FzZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGluY2x1ZGUgYW4gT0xSIGluIGVhY2gg
bWVzc2FnZS4gSXQgaXMganVzdCBmb3INCiBpbGx1c3RyYXRpb24uIFRoZSBwb2ludCBpcyB0aGF0
IHlvdSBtYXkgaGF2ZSBzb21lIGNhc2VzIGZvciB3aGljaCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dl
ciBtaWdodCBub3QgYmUgcmVxdWlyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgYWdyZWUgdGhhdCBoYXZpbmcgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgaXMgZmluZeKA
piBidXQgaXQgc2hvdWxkIGJlIG5vdCBtYW5kYXRvcnkgaW4gYWxsIGNhc2VzIEkgdGhpbmsuIFNv
IE9LIGZvciBhICZxdW90O1NIT1VMRCZxdW90OyBvciAmcXVvdDtSRUNPTU1FTkRFRCZxdW90Oy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJz
cDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwv
Yj4gU3RldmUgRG9ub3Zhbjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAxMCBmw6l2
cmllciAyMDE0IDE3OjIxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiA8YSBocmVmPSJtYWlsdG86ZGlt
ZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmo8L2I+PC9zcGFuPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPmV0Jm5ic3A7Ojwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbw0KIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij5JIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pPGJy
Pg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNheWluZyB0aGUgcmVjb21t
ZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFsbCBy
ZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5IE1hcmlhIENydXouJm5i
c3A7DQo8YnI+DQo8YnI+DQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBw
cm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0aW5nIG5v
ZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNo
b29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4mbmJzcDsgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRv
IGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzDQog
YnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0dXJl
cyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuJm5ic3A7IFRoZSBjYXNlIG9mIGFnZW50
cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVp
bmcgb25lIGV4YW1wbGUuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XZSBhbHNvIG5lZWQgdG8gbWFrZSBzdXJl
IHRoYXQgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIG5vdCBwcmVjbHVkZWQgYnkgTmlyYXYn
cyBwcm9wb3NhbC48YnI+DQo8YnI+DQpJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUg
d29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBNYXJpYSBDcnV6J3MgcmVhc29u
cyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHdheXMgaW5j
bHVkZWQuPGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1VU1Qg
ZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9y
dHMuPGJyPg0KPGJyPg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGlu
Y2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVh
Y3Rpbmcgbm9kZXMuJm5ic3A7DQo8YnI+DQo8YnI+DQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2Rl
IG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMg
c2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4mbmJz
cDsgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVy
IG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuPGJyPg0KPGJyPg0KQSByZXBvcnRpbmcg
bm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0
aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVh
ZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuPGJyPg0KPGJyPg0KTm90ZSAtIHRo
ZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cg
dGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3
aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBi
ZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcgbm9kZS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMi8xMC8xNCAzOjUyIEFNLCBN
YXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5IZWxsbyBOaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QW55
IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2llbmN5IGNv
dWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBmaXJzdCB3
ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBwcm92aWRp
bmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5Zb3VyIHByb3Bvc2VkIHRleHQmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4mcXVvdDsgQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3
aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9y
dCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5n
IG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0
IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiZxdW90OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5JZiB0aGUgcmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3aGV0
aGVyIG9yIG5vdCBvdmVybG9hZCByZXBvcnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5v
ZGUsIGFuZCBpdCBkZWNpZGVzIChzaW5jZSBpdCBpcyBhICZxdW90O21heSZxdW90OykgdG8gZG8g
bm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlz
bSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkg
Y29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5v
dGUgdGhhdCAmcXVvdDtyZWFjdGluZyBub2RlcyZxdW90OyBjb3VsZCBiZSBub3Qgb25seSB0aGUg
Y2xpZW50LCBidXQgQU5ZIGFnZW50IHVzZWQgZm9yIHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4gdGhl
IGFnZW50IGlzIHByb3ZpZGluZyBzZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlzIHJl
YWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkuIDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90
IHNpbXBsZSB0byBrbm93IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAo
YXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVy
IHlvdXIgcHJvcG9zZWQgJnF1b3Q7bWF5JnF1b3Q7KSB0aGVuIG9uZSBvciBtdWx0aXBsZSByZWFj
dGluZyBub2RlcyBkbyBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1p
dGlnYXRpb24gd2lsbCBub3Qgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhl
cmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWly
ZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5Gcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxv
dEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl0gPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAy
MDE0IDEwOjQyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogTWFy
aWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVj
dDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJ1dCBNYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5Ib3cgY2FuIHdlIHNheSB0aGF0ICZxdW90O2luY2x1ZGluZyB0aGUg
T0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZmaWNpZW50PyZx
dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXQgaXMgc2ltcGxl
IGZvciBzdXJlIGJ1dCBub3QgZWZmaWNpZW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+QSBzbGlnaHRseSBkaWZmZXJlbnQgd29yZGluZyBmcm9tIHdoYXQgSSBwcm9wb3NlZCBlYXJs
aWVyIGlzLCBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBoYXMgYSBuZXcgb3ZlcmxvYWQgcmVwb3J0
IHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gYSByZWFjdGluZyBub2RlIChieSB1cGRhdGlu
ZyB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgb3IgYnkgcHJvdmlkaW5nIHRo
ZSBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hhbGwgaW5jbHVkZSBP
TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBB
ZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2Rl
IGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQg
dG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUg
T0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2FyZHMsPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP
biBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPlNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMzowMyBQTTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2
LCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgdGhpbmsgd2Ugc2hvdWxkIGRl
ZmluZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0IHNvbHV0aW9uLCBhcyBlZmZpY2llbnQgYW5kIHNp
bXBsZSBhcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEgcHVyZSAmcXVvdDttYXkmcXVvdDssIGJ1
dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3VyZSByZWFjdGlu
ZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMg
bWVjaGFuaXNtIHRvIHdvcmsuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZXN0IHJl
Z2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi9NQ3J1ejxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogTmlyYXYgU2Fsb3QgKG5z
YWxvdCkgWzxhIGhyZWY9Im1haWx0bzpuc2Fsb3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNp
c2NvLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50
OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1h
aWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1h
cmlhLUNydXosPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgZnVsbHkgYWdyZWUgd2l0
aCB5b3Ugb24gJnF1b3Q7c2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0
YW50IGFkdmFudGFnZXMmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5BbmQgd2UgYXJlIG5vdCB0cnlpbmcgdG8gcHJldmVudCBpdCAtIGF0IGxlYXN0IHRoYXQg
aXMgbXkgaW50ZW50aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBv
dGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNh
biBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdl
PzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Nb3N0IHByb2JhYmx5LCB0aGUgdmVyeSBm
aXJzdCBpbXBsZW1lbnRhdGlvbiBvZiBvdmVybG9hZCBjb250cm9sIHdpbGwgaW5jbHVkZSBPTFIg
aW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5CdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmlj
dCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3Mg
YW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5
IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZv
aWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoYXQgZG8geW91IHRoaW5rPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIGFsc28gdGhlIHJlYXNvbiBJIHdhcyBz
dWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVkZSBPTFIgKGZyb20g
dGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1F
IFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBGcmlkYXksIEZlYnJ1YXJ5
IDA3LCAyMDE0IDg6NTcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlRvOiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5IZWxsbyBVbHJpY2gsIE5pcmF2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5JIGFncmVlIHdpdGggVWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmly
YXYgaXMganVzdCBhIE1BWSwgYW5kIHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4g
T0xSIGluIGFsbCBhbnN3ZXJzIHNoYWxsIG5vdCBiZSBqdXN0IGEgTUFZLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5PbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkg
VWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFz
IHNvbWUga25vd2xlZGdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFs
cmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5iKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9l
cyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2Rl
IGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+Yykgb3RoZXJ3aXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlJlcG9ydGluZyBub2RlIG11c3QgaGF2ZSBzb21lIGtub3dsZWRnZSBhYm91dCBPTFIg
cmVjZXB0aW9uL3N0YXR1cyBpbiByZWFjdGluZyBub2RlLiBIb3cgZG9lcyBzZXJ2ZXIgYWNxdWly
ZSB0aGlzIGtub3dsZWRnZT8gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5UYWtlIGludG8gYWNjb3VudCBhcyB3ZWxsIHRoYXQgYSAmcXVvdDtyZWFjdGluZyZxdW90OyBu
b2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChpbiBjYXNlIGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8g
YSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KSZu
YnNwOyBhbmQgYSBDbGllbnQuIEluIHRoZSBjYXNlIG9mIEFnZW50cywgaW4gZmFjdCB0aGUgU2Vy
dmVyIG1heSBub3QgZXZlbiBrbm93IGlmIHRoaXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rp
bmcgbm9kZSBvciBqdXN0IHRyYW5zcGFyZW50bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBu
b3QgbmVlZCB0byBoYXZlIGFueSBrbm93bGVkZ2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNo
YWluIHRvIHRoZSBmaW5hbCBDbGllbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRo
ZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dl
cnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4tIHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9u
IG9yIHNlc3Npb24pIGlzIHNpbXBsZXIsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4tIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBv
ciBub3QgdG8gc2VuZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhl
ciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9y
IHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIHNlbmRpbmcgYW4gYWRkaXRpb25h
bCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29uIHdpdGggcmVx
dWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgSW4gZmFjdCwgaW4gYW4gb3ZlcmxvYWQg
c2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxleCBpcyB0byBzZW5kIGluZm9y
bWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBub2RlcywgPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgYW5kIHRoZSBsYXR0ZXIgc2hvdWxk
IHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMmbmJzcDsgPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIG1vcmUgcm9idXN0IHNvbHV0aW9uLCBhcyBu
byBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhlIGNoZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5kIGlu
Zm9ybWF0aW9uLCZuYnNwOyBmb3Igc2l0dWF0aW9ucyB3aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBp
cyBsb3N0LCZuYnNwOyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZXN0IHJlZ2FyZHM8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl
aGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRlIDIw
MTQgMTA6NTk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBleHQg
TmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBleHQgU3RldmUgRG9ub3Zh
bjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtk
aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl
c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+TmlyYXYsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkknbSBhZnJh
aWQgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7d2hlbiBpdCB3YW50cyB0byBwcm92aWRl
L3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uJnF1b3Q7IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7
Li4uaXQgbWF5IGluY2x1ZGUuLi4mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PiZxdW90O2luIG90aGVyIGNhc2VzJnF1b3Q7IGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0
ZXMgdG8gJnF1b3Q7d2hlbiBpdCBkb2VzIG5vdCB3YW50IHRvIHByb3ZpZGUvdXBkYXRlLi4uJnF1
b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YSkgdGhlIHJlcG9ydGluZyBub2Rl
IGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3Qg
T0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5iKSB0aGUgcmVwb3J0
aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxp
bmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQg
d2lsbCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
Yykgb3RoZXJ3aXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmluIGNhc2UgYSkgdGhl
IHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikg
dGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5v
ZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNU
IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBu
b3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
RnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNp
c2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6
NDkgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBXaWVoZSwg
VWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3Jh
bmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0ZXZlIERv
bm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXQg
c2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3
b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5XaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBv
dmVybG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92
ZXJsb2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBP
TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBB
ZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2Rl
IGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQg
dG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUg
T0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2FyZHMsPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERF
L011bmljaCkgWzxhIGhyZWY9Im1haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbSI+bWFpbHRvOnVs
cmljaC53aWVoZUBuc24uY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogZXh0IDxhIGhyZWY9Im1haWx0bzps
aW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IE5p
cmF2IFNhbG90IChuc2Fsb3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRp
bWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYsIExp
b25lbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBjYW4gdW5kZXJzdGFuZCBOaXJh
didzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRy
ZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzo8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+MicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zlcmxv
YWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2Ug
dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBp
ZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFz
b25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIs
IHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBP
TFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVybG9hZCZxdW90Oywgb3IgYW4gb2xkJm5ic3A7IGJ1
dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3Zlcmxv
YWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRp
bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJu
IGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBkb24n
dCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQg
Y29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5v
dCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkg
YXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xS
cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNoJm5ic3A7IDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkZyb206IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2Uu
Y29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+IFs8YSBocmVmPSJtYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tIj5tYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPl08
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFRodXJzZGF5LCBG
ZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+VG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v
cmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGUmbmJzcDs6IERpTUUgWzxhIGhyZWY9Im1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95w6kmbmJzcDs6IGpl
dWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCZuYnNwOzogV2llaGUsIFVscmljaCAoTlNOIC0g
REUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYu
b3JnIj5kaW1lQGlldGYub3JnPC9hPiBPYmpldCZuYnNwOzogUmU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBhbSBub3Qgc3VyZSBh
Ym91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgJnF1b3Q7b3RoZXJ3
aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBt
YXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJl
c3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhl
IHJlcG9ydGluZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQg
dGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9k
ZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+W0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVx
dWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4g
SG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9M
UiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBp
bXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVy
LCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBz
dG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIElu
IG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4
cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcg
dHJhZmZpYyB0b3dhcmRzIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTE1dIEFn
cmVlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZXJlIG1heSBiZSBvdGhlciBjYXNl
cywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJs
b2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMg
bm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92
ZXJsb2FkIGNvbmRpdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W0xNXSBBZ3Jl
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZXN0IG9mIHRoZSBwcmluY2lwbGVzIGJl
bG93IGFyZSBmaW5lIHdpdGggbWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltMTV0g
QWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBb
PGEgaHJlZj0ibWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86dWxyaWNoLndpZWhl
QG5zbi5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2Vu
dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE08bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3Qg
KG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkFjdHVhbGx5IHdlIHNlZW0gdG8gYWdyZWUgb24gdHdvIHByaW5j
aXBsZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xLiBMYWNrIG9m
IE9MUiBtZWFucyAmcXVvdDtubyBjaGFuZ2UmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIg
b3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVz
cG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJl
IEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdv
dCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMg
cmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICZxdW90O25vIG92ZXJsb2FkJnF1b3Q7KTsg
b3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2Rl
IChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xS
IGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DYW4gcGVvcGxlIHBs
ZWFzZSBjb25maXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2g8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl
aGFsZiBPZiBleHQgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA0OjM1IFBNPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogTmlyYXYgU2Fsb3QgKG5zYWxv
dCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkFncmVlZC4mbmJzcDsgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92ZXJs
b2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUgZm9y
IHRoZSBob3N0IG9yIHJlYWxtLiZuYnNwOyBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUg
b3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhl
ciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQg
cmVwb3J0LiZuYnNwOyBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJl
cG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8g
b3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+U3RldmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9uIDIv
NS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBh
cnQgJnF1b3Q7c2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92
ZXJsb2FkZWQ/JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldlIGhhZCBzb21l
IGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFi
bGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkg
YW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tp
bmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQg
c2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlv
bmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hp
Yml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5TbyBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0
aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFj
dGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwg
dGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9M
UiB3aXRoICZxdW90OzAmcXVvdDsgb3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVkLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SW4gbXkgdmlldywgdGhpcyBhbGxvd3Mg
Zm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291
bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAx
NCA4OjAwIFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEg
aHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+aW5saW5lPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PbiAy
LzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZTo8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9rIHRoZW4gbGV0J3Mgc3RhdGUg
dGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5z
d2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNv
bnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVk
dWN0aW9uIGlzIHJlcXVlc3RlZCkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5TUkQmZ3Q7IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT8mbmJzcDsgU2hvdWxkbid0
IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PdGhlciBj
cml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNSRCZndDsgUmVxdWlyaW5nIGFuIG92
ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywg
YnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlh
bCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0
aW5nIE9MUnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZl
ZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2Vk
dXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcg
b2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0
b28gbWlzcyBhIG5ldyBPTFI/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5TUkQmZ3Q7IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJlci48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJv
bTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5z
YWxvdCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFdlZG5l
c2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+VG86IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll
dGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgc2hhcmUgdGhlIHNh
bWUgb3BpbmlvbiBhcyBMaW9uZWwuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2Fy
ZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgdW5k
ZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg
RE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLiA8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MS0gT0MtT0xSIEFWUCBpbiBldmVyeSBh
bnN3ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjItIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0ICYjNDM7IE9DLU9MUiBBVlAg
aW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0
aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1zIHRo
ZSBiZXN0IGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5MaW9uZWw8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EZSZuYnNwOzogZGltZSBpc3N1
ZSB0cmFja2VyIFs8YSBocmVmPSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYu
b3JnIj5tYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkVudm95w6kmbmJzcDs6IG1hcmRpIDQg
ZsOpdnJpZXIgMjAxNCAwOTo0OTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+w4AmbmJzcDs6IE1PUkFORCBMaW9uZWwgSU1UL09MTjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3Jn
Ij5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+T2JqZXQmbmJzcDs6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBJdCBoYXMgYmVlbiBwcm9wb3Nl
ZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMmbmJz
cDsgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0Jm5ic3A7IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAgd291
bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+IChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNo
IHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGlu
ZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyZuYnNwOyB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4m
bmJzcDsgUmVwb3J0aW5nIERPSUMgZW5kcG9pbnRzIG1heSB1c2UgdGhpcyZuYnNwOyBpbmZvcm1h
dGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRl
IHRoZSZuYnNwOyByZWFjdGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gQWJzZW5jZSBvZiB0aGlzIGZl
ZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSZuYnNwOyBy
ZXBvcnRpbmcgbm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUg
cmVwb3J0aW5nIERPSUMmbmJzcDsgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVh
Y3RpbmcgRE9JQyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZyZuYnNwOyB0aGUgcmlnaHQgdGhp
bmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJv
dmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNwOyBlbmRw
b2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRo
ZSByZWFjdGluZyZuYnNwOyBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29u
KS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBUaGUgZmVlZGJhY2sg
bWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gSW4gc3VtbWFyeSBpdCBpcyBw
cm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0byZu
YnNwOyBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWlsaW5n
IGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1h
aWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp
bWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu
dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll
ZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w
aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl
cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl
IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz
IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl
c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp
ZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhpcyBtZXNzYWdlIGFu
ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg
aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90
IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB5b3UgaGF2ZSByZWNlaXZl
ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0
ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v
dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y
IGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5r
IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBs
aXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWls
dG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBp
ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUg
bWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBo
cmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNlIG1lc3NhZ2UgZXQgc2VzIHBp
ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp
ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj
b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy
IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg
cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp
YmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl
IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv
bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl
ZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50aGV5IHNo
b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh
dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHlvdSBoYXZl
IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh
bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu
Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo
YW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8UFJFPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz
IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl
bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y
aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl
eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz
IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0
aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz
aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU
aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg
b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0
aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0
aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg
Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll
ZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_6B7134B31289DC4FAF731D844122B36E499B60PEXCVZYM13corpora_--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:38:16 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850551A0933 for ; Tue, 11 Feb 2014 02:38:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA1GE65CwpAE for ; Tue, 11 Feb 2014 02:38:15 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8983E1A07D5 for ; Tue, 11 Feb 2014 02:38:13 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-40-52f9fd94a763
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 8A.2B.04853.49DF9F25; Tue, 11 Feb 2014 11:38:13 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:38:12 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPJm6DlWmMf1mPE0uklIAv2DU+a5qv3NoQ
Date: Tue, 11 Feb 2014 10:38:12 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772ED3@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> <52F8E5A7.6030902@usdonovans.com>
In-Reply-To: <52F8E5A7.6030902@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvje7Uvz+DDE7bW8ztXcHmwOixZMlP pgDGKC6blNSczLLUIn27BK6Mlq2PmQvOcFdMvv6FtYFxKWcXIyeHhICJxJe2c0wQtpjEhXvr 2UBsIYETjBLdByO7GLmA7CWMEuvXfGIESbAJ2ElcOv0CqIGDQ0RAWeL0LweQsLCAvcTXG2eY QWwRAQeJNc9PskDYRhI9f+eAzWQRUJX42LGeHcTmFfCVmHfqIivE/MeMEhu27QKbySmgJ3G8 JQCkhhHonu+n1oDdxiwgLnHryXyoOwUkluw5zwxhi0q8fPyPFcJWklh0+zNUvY7Egt2f2CBs bYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxShanFhfnphsZ6OWm55bopRZl JhcX5+fpFaduYgTGxcEtv412MJ7cY3+IUZqDRUmc9zprTZCQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRtWPkh/X3Pyzp/dMmOrGJydTb/q1STgkxU3df05E2cNQjevPI6V+7ojjtdtrFj1b KP9svQ3/VR3G3UxdYREnz99me1R0MfOk/AJ+U3W1B5mW2zPq9Zz3lU3TucKwdaubpnfMLNNp Syqmmh5hEpQU+bq1g89Y8Ou0950SG3uChVbFbJCQsmbcrMRSnJFoqMVcVJwIAIHCVgNZAgAA
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:38:16 -0000

Steve,

I prefer this text to remain, as Ulrich proposed, since it clarifies.
It refers to new requests that need to match same application Id as in the =
answer that includes the OLR. (It does not refer to the answer of a request=
).
One endpoint can send requests for multiple applications, we have  not rest=
ricted this.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 15:44
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
> No need for this since we agreed that DOIC implicitly always refers to=20
> the application on which the DOIC AVPs are carried in.
> yes, we agreed on that, so c) is correct and it does not harm=20
> to keep c)
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way for t=
he application-id in the answer message to be different than the applicatio=
n-id in the request message without breaking Diameter.

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


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:42:37 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4A1A07D5 for ; Tue, 11 Feb 2014 02:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl6z1qYEWLYm for ; Tue, 11 Feb 2014 02:42:35 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD31A06BF for ; Tue, 11 Feb 2014 02:42:35 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-30-52f9fe9a302b
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FB.EF.10875.A9EF9F25; Tue, 11 Feb 2014 11:42:34 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:42:34 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPI+1LK95DWDMaH0qQEyVc/ebDNpqpv0FwgATFJ4CAAUePcIAAGAbg
Date: Tue, 11 Feb 2014 10:42:33 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772EE2@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> <52F8E5A7.6030902@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29A1@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B29A1@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje6sfz+DDGb/VbCY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRMf7mQsWCtYcfTwQaYGxl+8XYycHBICJhLnHp9kgrDFJC7c W8/WxcjFISRwiFHiz5EzUM4SRon5K2azglSxCdhJXDr9AqiDg0NEQFni9C8HkLCwgL3E1xtn mEFsEQEHiTXPT7JA2G4S+4++BFvAIqAqcX/vE7AxvAK+Et/WPgCzhQRWMknM/qwNYnMKBEhs mLgXrJ4R6KDvp9aA2cwC4hK3nsyHOlRAYsme88wQtqjEy8f/WCFsJYlFtz9D1etILNj9iQ3C 1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI3tuYmZOernhJkZg2B/c8lt3 B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBgbnW4XvCZHq5dj GQvznzNyF7KK+N7bMTI1hSZHzvZmT8mdO9tXNuiJSkDNnQ03kn05d+ZWP1Jt6r5Rs1J389qu XMNHb853fSy8z2v3Vz/mtM00tQdCMt+N7i+ZPUF1OUe15POFv98XXG4Q5YkQbZB0Ohy1Kjcr +YtMzEdFZxVfg6p8DwM+JZbijERDLeai4kQANlo5rEkCAAA=
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:42:38 -0000

Exact, I agree.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 11 de febrero de 2014 10:37
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Steve,

I do not agree.

e.g.=20
1. reacting node sends Request with application ID =3D x to reporting node =
2. reporting node sends back answer (containing an OLR) with application ID=
 =3D x 3. reacting node now may very well send  a new request with applicat=
ion ID =3D y to the reporting node without breaking any Diameter rules.=20
The new request sent in step 3 is NOT subject to throttling according to th=
e OLR received in step 2.
I hope this is not contentious.
In order to provide a complete list of conditions to say when an OLR of a g=
iven type applies to a new request, we should not let c) go by the board.

Ulrich


=20


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 10, 2014 3:44 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
> No need for this since we agreed that DOIC implicitly always refers to=20
> the application on which the DOIC AVPs are carried in.
> yes, we agreed on that, so c) is correct and it does not harm=20
> to keep c)
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way for t=
he application-id in the answer message to be different than the applicatio=
n-id in the request message without breaking Diameter.

_______________________________________________
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 maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:48:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D765B1A06C9 for ; Tue, 11 Feb 2014 02:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 7YuZbKVE04Zt for ; Tue, 11 Feb 2014 02:48:49 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A9A4F1A06BF for ; Tue, 11 Feb 2014 02:48:48 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-4e-52fa000f61a9
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 00.20.04249.F000AF25; Tue, 11 Feb 2014 11:48:47 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:48:47 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAlWmMf1mPE0uklIAv2DU+a5qmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDg
Date: Tue, 11 Feb 2014 10:48:46 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjS4/w68gg/PT9C3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxso1IgWN6RVf3r1mamBsCu5i5OSQEDCR+Hb5JTuELSZx4d56 NhBbSOAIo8SmgzpdjFxA9hJGiendf1lAEmwCdhKXTr9g6mLk4BARUJY4/csBJCwsYC/x9cYZ ZhBbRMBBYs3zkywQJXkS+/o9QcIsAqoS6z/fASvhFfCVeHb1LxPE+DZ2iaZPu1hBEpwCsRId a6eDFTEC3fP91BomEJtZQFzi1pP5TBB3Ckgs2XOeGcIWlXj5+B8rhK0ksej2Z6h6PYkbU6ew QdjaEssWvoZaLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYuQoTi1Oyk03MtjECAz6g1t+ W+xgvPzX5hCjNAeLkjjvx7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY719s1ZiacGSH QMnvA1GLesPWCX/OY7aYZimuyeA8+fEdDcX/h3lWrW7bxbf129VDPjMdDQL+zDFTis46LWQS dGzJ+yNMfKsLP33ezvBh1oHC/icBW82XrJxpaOq0vrg55bzpJX4mr95PNoXXVymstvqx/kSs TGWD3S2Tqy61q0IeLBFllJ54U4mlOCPRUIu5qDgRAH67UJ5IAgAA
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:48:53 -0000

Hello,
I agree with JJ:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host=20
[JJ] there may be a misunderstanding somewhere, so good to try to clarify; =
coming back to Ulrich example, Host S1 is not overloaded, so reacting node =
has not received Host reduction OLR for S1. But as there  is a realm reduct=
ion, reacting node will reduce traffic with destination Host S1.

[MCruz] And... if the request is sent to a Destination-Host, if there is an=
y applicable OLR, it will be received immediately in the answer, and will b=
e applicable from next request on.
Simple and robust in my opinion. Then, we do not need to evaluate whether w=
e have OLR for Realm and/or Host, and even check their validity & applicabi=
lity.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 15:00
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Lionel=20

Please see in line

-----Message d'origine-----
De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9=
=A0: lundi 10 f=E9vrier 2014 14:25 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES); dime@ietf.org Objet=A0: RE: [Dime] [dime] #34: Semantics of OC-Report=
-Type AVP

I disagree and my proposal was somehow misunderstood.

I don't see the issue to have the following sequence:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host [JJ] there may be a misunderstanding somew=
here, so good to try to clarify; coming back to Ulrich example, Host S1 is =
not overloaded, so reacting node has not received Host reduction OLR for S1=
. But as there  is a realm reduction, reacting node will reduce traffic wit=
h destination Host S1.
  =20
- If the reacting node has received an indication only for host traffic red=
uction, apply host reduction for messages containing a Destination-Host. No=
 reduction for messages with only a Destination-Realm.
[JJ] OK
=20
- If the reacting node has received both an indication for host traffic and=
 for realm traffic reduction, only the realm reduction will apply for messa=
ges with only the Destination-Realm AVP and only the host reduction will ap=
ply for messages with the Destination-Host AVP (and the Destination-Realm A=
VP).
[JJ] OK, Host reduction prevails

In other words, as said earlier, the Host reduction prevails over realm red=
uction when the overloaded host is inside an overloaded realm and the react=
ing has received info about both type of overload.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9=A0: lundi 10 f=E9vrier 2014 13:56 =C0=A0: dime@=
ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear  all

I share Ulrich and MCruz views,
- Host OLR based control applies to requests where Destination Host is know=
n
- Realm OLR based control applies to requests where Destination Host is not=
 known (only the Destination realm).

I think it is simple, otherwise as MCruz indicated it complicates; e.g abou=
t the Ulrich's example where the Host S1 is not overloaded but the realm is=
 overloaded. the client will not receive Host OLR reports from host S1 (so =
no explicit traffic reduction requested by S1), but according to Lionel com=
ment, I understand  client will have to throttle the requests sent to S1 ac=
cording to realm OLR, so how to avoid this.

JJacques

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 17:15 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear all,

I am in favor of the proposal made by Ulrich in the sequence diagram he pro=
vided.
----
As a summary:
Consequently the reacting node will receive realm type OLRs from the agent =
and host type OLRs from the servers.
The received realm type OLR will be relevant for the reacting node when sen=
ding/throttling realm type requests; the received host type OLR will be rel=
evant for the reacting node       when sending/throttling host type request=
s.
-----

It may occur though, that a Client has only received Realm type OLR, and th=
en it has to send a request to one specific host, then the Client will not =
apply any restriction, but as soon as the response is received back, Client=
 will update Host type OLR.  Same will apply when only Host type OLR has be=
en received by Client.
The alternative will be to always send back from an Agent both Host OLR plu=
s Realm OLR, but I do not think this is necessary and may complicate the so=
lution.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> I better like Lionel's approach, but even that is not ok in the unlikely =
extreme case where we have two servers in a realm, S1 is not overloaded at =
all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh=
ould a client do a 25% throttling when sending host type requests to the no=
t at all overloaded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1, -throttle host type request to=20
> S2 with 50% and -throttle realm type requests wit 25%?

Isn't this what Lionel said below?
 no it is not
 I am OK with Lionel's
"wording" here.

- Jouni

> =20
> =20
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
> lionel.morand@orange.com
> Sent: Wednesday, February 05, 2014 4:14 PM
> To: Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> I tend to agree except that I would reverse the logic as for the routing =
principles: the Destination-host takes precedence when present over Destina=
tion-Realm. So the realm abatement is applied in any case except if there i=
s an explicit report for the destination-host.
> =20
> Lioenl
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet : Re=
:=20
> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> It makes more sense to me for a realm report to apply to all requests tar=
geted for that realm, independent the type of request.  This implies that i=
t would apply to requests that also have a Destination-Host specified.
>=20
> If this is the definition of a realm report then we need to specify the i=
nteraction between realm reports and host reports.
>=20
> I propose that throttling would occur on the realm first and the host sec=
ond.  If a message targetted for the host is throttled as a result of realm=
 overload then that throttled message would count as part of the reduction =
needed to address the host overload.  Messages to the host that survive rea=
lm abatement would then be candidates for host overload.
>=20
> Steve
>=20
> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
> The case "Realm" as described below raises another question: is it prohib=
ited for a realm to only rely on a global overload report for the whole rea=
lm, whatever the nodes inside this realm?
> If not, only OLR with the report type "realm" would be received by the re=
acting node. And the reduction indicated in the OLR will apply always for t=
he realm, whatever the presence of Destination-host AVP in the request... e=
xcept if an explicit report with the type "Host" as been received for this =
destination-host.
> =20
> Does it make sense?
> =20
> Lionel
> =20
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #34: Semantics of OC-Report-Type AVP
> =20
> #34: Semantics of OC-Report-Type AVP
> =20
>  Text in clause 4.6  does not fully explain to which requests overload =20
> treatment of a given report type applies.
>  Proposal:
> =20
>     0  A host report.  The overload treatment should apply to requests
>        for which all of the following conditions are true:
>        a) The Destination-Host AVP is present in the request and its valu=
e
>           matches the value of the Origin-Host AVP of the received messag=
e
>           that contained the OC-OLR AVP.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
> =20
> =20
> =20
>     1  A realm report.  The overload treatment should apply to
>        requests for which all of the following conditions are true:
>        a) The Destination-Host AVP is absent in the request.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
> =20
> =20
> ______________________________________________________________________
> ___________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

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


From lionel.morand@orange.com  Tue Feb 11 02:50:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B2A1A07DD for ; Tue, 11 Feb 2014 02:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1OcFoCoWCtT for ; Tue, 11 Feb 2014 02:50:24 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id AE1941A06BF for ; Tue, 11 Feb 2014 02:50:23 -0800 (PST)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 69277190649; Tue, 11 Feb 2014 11:50:22 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 37122C80D0; Tue, 11 Feb 2014 11:50:21 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 11:50:20 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPI+1LK95DWDMaH0qQEyVc/ebDNpqpv0FwgATFJ4CAAUePcIAAGAbggAABmJA=
Date: Tue, 11 Feb 2014 10:50:19 +0000
Message-ID: <14115_1392115821_52FA006D_14115_2918_1_6B7134B31289DC4FAF731D844122B36E499C02@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> <52F8E5A7.6030902@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29A1@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772EE2@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772EE2@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.11.70017
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:50:25 -0000

I think that there is no contentious issue here :)
I think that Ulrich is right saying that the reacting node needs to take in=
to account the application-id to perform the abatement. Not when receiving =
the OLR... but when sending a new request.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:43
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Exact, I agree.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 11 de febrero de 2014 10:37
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Steve,

I do not agree.

e.g.=20
1. reacting node sends Request with application ID =3D x to reporting node =
2. reporting node sends back answer (containing an OLR) with application ID=
 =3D x 3. reacting node now may very well send  a new request with applicat=
ion ID =3D y to the reporting node without breaking any Diameter rules.=20
The new request sent in step 3 is NOT subject to throttling according to th=
e OLR received in step 2.
I hope this is not contentious.
In order to provide a complete list of conditions to say when an OLR of a g=
iven type applies to a new request, we should not let c) go by the board.

Ulrich


=20


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 10, 2014 3:44 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
> No need for this since we agreed that DOIC implicitly always refers to=20
> the application on which the DOIC AVPs are carried in.
> yes, we agreed on that, so c) is correct and it does not harm=20
> to keep c)
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way for t=
he application-id in the answer message to be different than the applicatio=
n-id in the request message without breaking Diameter.

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 02:51:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8E1A07DD for ; Tue, 11 Feb 2014 02:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdtHws_bMiQJ for ; Tue, 11 Feb 2014 02:51:50 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E61A06BF for ; Tue, 11 Feb 2014 02:51:48 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-28-52fa00c29fdb
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 22.41.10875.2C00AF25; Tue, 11 Feb 2014 11:51:47 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 11:51:46 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUIACsQCAgAA/36CAAw1bAIABfVQAgAA0qoCAACcaAIAADsuAgAEbR1CAABGXoA==
Date: Tue, 11 Feb 2014 10:51:46 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772F07@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29D6@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B29D6@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209772F07ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje5hhl9BBne3KFvM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL2fnjAVXGpnrujZfYGtgfHVBaYuRk4OCQETiX8rZzND2GIS F+6tZwOxhQQOMUq87xbsYuQCspcwSjz83cwCkmATsJO4dPoFUDMHh4iAssTpXw4gYWEBe4mv N86AzRERcJBY8/wkC4RdJ/F/7mR2EJtFQFXiyaVNYDavgK/E9Cft7BDzb7FLrJ5xkBUkwSkQ ILH/20+wZkagg76fWgN2KLOAuMStJ/OhjhaQWLLnPNTRohIvH/9jhbCVJBbd/gxVny/R+nQq 1DJBiZMzn7BMYBSZhWTULCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYzs uYmZOenlhpsYgbFycMtv3R2Mp86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAj EwenVAOj6CJpxp3LX4Yf9Z54aWeBUep9g6xNFWXzNv6/Y7RvpqbV2QbTBPn0p5kamz8nHYyR cTzs90LzbWLMy08KvKUc3Do3qz/ndzeUf95zI8T7iPa9yDXnfVZWyrxpzFy8pm43o9CP03Ka B+oWhW3UWeP4TUFYO1mSu35yTgvvwduv5dNeRj3p1V+mxFKckWioxVxUnAgAAARww2MCAAA=
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:51:57 -0000

--_000_087A34937E64E74E848732CFF8354B9209772F07ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,

I agree with Ulrich comments, since I agree on the basic approach as mentio=
ned already in this thread (inline with JJ comments as well):


- Host OLR based control applies to requests where Destination Host is know=
n

- Realm OLR based control applies to requests where Destination Host is not=
 known (only the Destination realm).

Best regards
/MCruz

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, February 10, 2014 6:52 PM
To: lionel.morand@orange.com; Jouni Korhon=
en; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

Why would the reduction for the realm be less than servers.  It is perfectl=
y valid for a realm overload report to ask for a reduction when there are n=
o servers in overload.
 I don't think so
  This could happen in the case I mentioned where the realm overload report=
 is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.
 all considerations other than server overload are (or should be) o=
ut of scope. (May be covered by agent overload control)

My logic was not quite correct, but for a different reason.  There is no re=
ason to do the host throttling if the request has already been throttled by=
 the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  This mig=
ht look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the destinatio=
n-host AVP
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    If host credits exist for the host indicated in the destination-host AV=
P:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request
 sounds quite complicated
Steve
On 2/10/14 10:59 AM, lionel.morand@orange.com wrote:
Hi Steve,

In your example, if an agent has a better knowledge than the server, the Ho=
st type OLR should not be sent unmodified in forwarded answers, or even rem=
oved as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than=
 the reduction needed for a node. S1 is not overload, S2 is 50% overload, t=
he realm (S1+S2) is overloaded 25%. So only the reduction for the Host shou=
ld apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between=
 the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : lundi 10 f=E9vrier 2014 15:39
=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich=
)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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_087A34937E64E74E848732CFF8354B9209772F07ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello all,


 

I agree with Ulrich commen=
ts, since I agree on the basic approach as mentioned already in this thread=
 (inline with JJ comments as well):


 

- Host OLR based control applies to requests wher=
e Destination Host is known


- Realm OLR based control applies to requests whe=
re Destination Host is not known (only the Destination realm).

 

Best regards


/MCruz

 






From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, February 10, 2014 6:52 PM

To: lionel.morand@orange=
.com; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


Lio=
nel,



Why would the reduction for the realm be less than servers.  It is per=
fectly valid for a realm overload report to ask for a reduction when there =
are no servers in overload.


<Ulrich> I don’t think so</Ulrich>=



  This could hap=
pen in the case I mentioned where the realm overload report is triggered by=
 layer 3 congestion.



Clearly realm overload will be significantly influenced b=
y server overload, but that isn't the only consideration.


<Ulrich> all considerations other than server overload ar=
e (or should be) out of scope. (May be covered by agent overload
 control)</Ulrich>



My logic was not quite correct, but for a different reason.  There is no reason to do the host throttling if the request has al=
ready been throttled by the realm report.

It should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    Apply host based throttling logic to that request



One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm. 
This might look something like the following:



For all req=
uests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

    If request is throttled:

      Increment host credit by one for the host indicat=
ed in the destination-host AVP

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    If host credits exist for the host indicated in the dest=
ination-host AVP:

      Decrement host credit by one

    else:

      Apply host based throttling logic to that request=


<Ulrich> sounds quite comp=
licated</Ulrich>

Steve




On 2/10/14 10:59 AM, 
lionel.morand@orange.com wrote:






Hi Steve,


 =



In your example, if an ag=
ent has a better knowledge than the server, the Host type OLR should not be=
 sent unmodified in forwarded answers, or even removed as
 irrelevant.


 


And in a normal case, the=
 reduction for the realm will be likely lower than the reduction needed for=
 a node. S1 is not overload, S2 is 50% overload, the realm
 (S1+S2) is overloaded 25%. So only the reduction for the Host should a=
pply, why the host-type should prevail over realm-type OLR.


 


By the way, in your propo=
sed logic, it is not clear if the relation between the first and the second=
 conditions is an "IF NOT".



 


Lionel


 






De =
: Steve Donovan [mailto:srdonovan@usdonovans.com]


Envoy=E9 : lundi 10 f=E9vrier 2014 15:39

=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN=
 - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I t=
hink we have agreement that a realm report applies to all traffic targeted =
for that realm, independent of the presence or absence of the destination-h=
ost avp.  Is that correct?



I don't agree with Lionel's proposal.  The realm overload report shoul=
d take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was writ=
ten "except" :)


 


The abatement for the Realm applies when NO explicit=
 reduction is requested for a specific node of this realm. In such a case i=
.e. when an OLR is received for a specific node inside a realm for which a =
reduction also applies, *ONLY* the reduction requested for the node applied=
.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46=



=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-=
Report-Type AVP


 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN=
 - DE/Munich)" <ulrich.wieh=
e@nsn.com> wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM<=
/span>


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext =
lionel.morand@orange.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Repo=
rt-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN=
 - DE/Munich)" <ulrich.wieh=
e@nsn.com> wrote:


 




I better like Lionel's approach, but even that is no=
t ok in the unlikely extreme case where we have two servers in a realm, S1 =
is not overloaded at all, S2 is 50% overloaded, and the aggregated realm ov=
erload is 25%. Why should a client do a 25% throttling when sending host ty=
pe requests to the not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and<=
/o:p>


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?=



<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is app=
lied in any case


except if there is an explicit report for the destin=
ation-host"?


 


If this means the realm abatement is still applied a=
fter applying


the host abatement, then I agree it is not the same =
you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; =
dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Repo=
rt-Type AVP


 


I tend to agree except that I would reverse the logi=
c as for the routing principles: the Destination-host takes precedence when=
 present over Destination-Realm. So the realm abatement is applied in any c=
ase except if there is an explicit report for the destination-host.


 


Lioenl


 


De : DiME [=
mailto:dime-bounces@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org=



Objet : Re: [Dime] [dime] #34: Semantics of OC-Repor=
t-Type AVP


 


It makes more sense to me for a realm report to appl=
y to all requests targeted for that realm, independent the type of request.=
  This implies that it would apply to requests that also have a Destin=
ation-Host specified.


 


If this is the definition of a realm report then we =
need to specify the interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm f=
irst and the host second.  If a message targetted for the host is thro=
ttled as a result of realm overload then that throttled message would count=
 as part of the reduction needed to address the host overload.  Messag=
es to the host that survive realm abatement would then be candidates for ho=
st overload.


 


Steve


 


On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:


The case "Realm" as described below raises=
 another question: is it prohibited for a realm to only rely on a global ov=
erload report for the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm&qu=
ot; would be received by the reacting node. And the reduction indicated in =
the OLR will apply always for the realm, whatever the presence of Destinati=
on-host AVP in the request... except if an explicit report with the type &q=
uot;Host" as been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org<=
/a>


Objet : [dime] #34: Semantics of OC-Report-Type AVP<=
o:p>


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to w=
hich requests overload


treatment of a given report type applies.=



Proposal:


 


   0  A host report.  The overlo=
ad treatment should apply to requests


      for which all of the =
following conditions are true:


      a) The Destination-Ho=
st AVP is present in the request and its value


         mat=
ches the value of the Origin-Host AVP of the received message


         tha=
t contained the OC-OLR AVP.


      b) The value of the D=
estination-Realm AVP in the request matches the


         val=
ue of the Origin-Realm AVP of the received message


         tha=
t contained the OC-OLR AVP.


      c) The value of the A=
pplication-ID in the Diameter Header of the


         req=
uest matches the value of the Application-ID of the Diameter


         Hea=
der of the received message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overl=
oad treatment should apply to


      requests for which al=
l of the following conditions are true:


      a) The Destination-Ho=
st AVP is absent in the request.


      b) The value of the D=
estination-Realm AVP in the request matches the


         val=
ue of the Origin-Realm AVP of the received message


         tha=
t contained the OC-OLR AVP.


      c) The value of the A=
pplication-ID in the Diameter Header of the


         req=
uest matches the value of the Application-ID of the Diameter


         Hea=
der of the received message that contained the OC-OLR AVP.


 


 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


_______________________________________________=



DiME mailing list


DiME@ietf.org


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




 




 


 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


 


 




 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.




 






--_000_087A34937E64E74E848732CFF8354B9209772F07ESESSMB101erics_--


From lionel.morand@orange.com  Tue Feb 11 02:56:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDA81A07DE for ; Tue, 11 Feb 2014 02:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycF7IA5KdOyt for ; Tue, 11 Feb 2014 02:56:52 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 903EA1A00AE for ; Tue, 11 Feb 2014 02:56:51 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id D298022C732; Tue, 11 Feb 2014 11:56:50 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AF10A4C09D; Tue, 11 Feb 2014 11:56:50 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 11:56:50 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDggAACzDA=
Date: Tue, 11 Feb 2014 10:56:49 +0000
Message-ID: <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.11.81814
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 10:56:55 -0000

Hi maria-cruz,

JJ agreed on the following approach:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host [JJ] there may be a misunderstanding somew=
here, so good to try to clarify; coming back to Ulrich example, Host S1 is =
not overloaded, so reacting node has not received Host reduction OLR for S1=
. But as there  is a realm reduction, reacting node will reduce traffic wit=
h destination Host S1.
=20=20=20
- If the reacting node has received an indication only for host traffic red=
uction, apply host reduction for messages containing a Destination-Host. No=
 reduction for messages with only a Destination-Realm.
[JJ] OK
=20
- If the reacting node has received both an indication for host traffic and=
 for realm traffic reduction, only the realm reduction will apply for messa=
ges with only the Destination-Realm AVP and only the host reduction will ap=
ply for messages with the Destination-Host AVP (and the Destination-Realm A=
VP).
[JJ] OK, Host reduction prevails

In other words, as said earlier, the Host reduction prevails over realm red=
uction when the overloaded host is inside an overloaded realm and the react=
ing has received info about both type of overload.

What is the issue with this approach?

Regards,

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:49
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hello,
I agree with JJ:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host=20
[JJ] there may be a misunderstanding somewhere, so good to try to clarify; =
coming back to Ulrich example, Host S1 is not overloaded, so reacting node =
has not received Host reduction OLR for S1. But as there  is a realm reduct=
ion, reacting node will reduce traffic with destination Host S1.

[MCruz] And... if the request is sent to a Destination-Host, if there is an=
y applicable OLR, it will be received immediately in the answer, and will b=
e applicable from next request on.
Simple and robust in my opinion. Then, we do not need to evaluate whether w=
e have OLR for Realm and/or Host, and even check their validity & applicabi=
lity.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 15:00
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Lionel=20

Please see in line

-----Message d'origine-----
De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9=
=A0: lundi 10 f=E9vrier 2014 14:25 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES); dime@ietf.org Objet=A0: RE: [Dime] [dime] #34: Semantics of OC-Report=
-Type AVP

I disagree and my proposal was somehow misunderstood.

I don't see the issue to have the following sequence:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host [JJ] there may be a misunderstanding somew=
here, so good to try to clarify; coming back to Ulrich example, Host S1 is =
not overloaded, so reacting node has not received Host reduction OLR for S1=
. But as there  is a realm reduction, reacting node will reduce traffic wit=
h destination Host S1.
=20=20=20
- If the reacting node has received an indication only for host traffic red=
uction, apply host reduction for messages containing a Destination-Host. No=
 reduction for messages with only a Destination-Realm.
[JJ] OK
=20
- If the reacting node has received both an indication for host traffic and=
 for realm traffic reduction, only the realm reduction will apply for messa=
ges with only the Destination-Realm AVP and only the host reduction will ap=
ply for messages with the Destination-Host AVP (and the Destination-Realm A=
VP).
[JJ] OK, Host reduction prevails

In other words, as said earlier, the Host reduction prevails over realm red=
uction when the overloaded host is inside an overloaded realm and the react=
ing has received info about both type of overload.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9=A0: lundi 10 f=E9vrier 2014 13:56 =C0=A0: dime@=
ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear  all

I share Ulrich and MCruz views,
- Host OLR based control applies to requests where Destination Host is known
- Realm OLR based control applies to requests where Destination Host is not=
 known (only the Destination realm).

I think it is simple, otherwise as MCruz indicated it complicates; e.g abou=
t the Ulrich's example where the Host S1 is not overloaded but the realm is=
 overloaded. the client will not receive Host OLR reports from host S1 (so =
no explicit traffic reduction requested by S1), but according to Lionel com=
ment, I understand  client will have to throttle the requests sent to S1 ac=
cording to realm OLR, so how to avoid this.

JJacques

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 17:15 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear all,

I am in favor of the proposal made by Ulrich in the sequence diagram he pro=
vided.
----
As a summary:
Consequently the reacting node will receive realm type OLRs from the agent =
and host type OLRs from the servers.
The received realm type OLR will be relevant for the reacting node when sen=
ding/throttling realm type requests; the received host type OLR will be rel=
evant for the reacting node       when sending/throttling host type request=
s.
-----

It may occur though, that a Client has only received Realm type OLR, and th=
en it has to send a request to one specific host, then the Client will not =
apply any restriction, but as soon as the response is received back, Client=
 will update Host type OLR.  Same will apply when only Host type OLR has be=
en received by Client.
The alternative will be to always send back from an Agent both Host OLR plu=
s Realm OLR, but I do not think this is necessary and may complicate the so=
lution.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> I better like Lionel's approach, but even that is not ok in the unlikely =
extreme case where we have two servers in a realm, S1 is not overloaded at =
all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh=
ould a client do a 25% throttling when sending host type requests to the no=
t at all overloaded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1, -throttle host type request to=20
> S2 with 50% and -throttle realm type requests wit 25%?

Isn't this what Lionel said below?
 no it is not
 I am OK with Lionel's
"wording" here.

- Jouni

>=20=20
>=20=20
>=20=20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
> lionel.morand@orange.com
> Sent: Wednesday, February 05, 2014 4:14 PM
> To: Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>=20=20
> I tend to agree except that I would reverse the logic as for the routing =
principles: the Destination-host takes precedence when present over Destina=
tion-Realm. So the realm abatement is applied in any case except if there i=
s an explicit report for the destination-host.
>=20=20
> Lioenl
>=20=20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet : Re=
:=20
> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>=20=20
> It makes more sense to me for a realm report to apply to all requests tar=
geted for that realm, independent the type of request.  This implies that i=
t would apply to requests that also have a Destination-Host specified.
>=20
> If this is the definition of a realm report then we need to specify the i=
nteraction between realm reports and host reports.
>=20
> I propose that throttling would occur on the realm first and the host sec=
ond.  If a message targetted for the host is throttled as a result of realm=
 overload then that throttled message would count as part of the reduction =
needed to address the host overload.  Messages to the host that survive rea=
lm abatement would then be candidates for host overload.
>=20
> Steve
>=20
> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
> The case "Realm" as described below raises another question: is it prohib=
ited for a realm to only rely on a global overload report for the whole rea=
lm, whatever the nodes inside this realm?
> If not, only OLR with the report type "realm" would be received by the re=
acting node. And the reduction indicated in the OLR will apply always for t=
he realm, whatever the presence of Destination-host AVP in the request... e=
xcept if an explicit report with the type "Host" as been received for this =
destination-host.
>=20=20
> Does it make sense?
>=20=20
> Lionel
>=20=20
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>=20=20
> #34: Semantics of OC-Report-Type AVP
>=20=20
>  Text in clause 4.6  does not fully explain to which requests overload=20=
=20
> treatment of a given report type applies.
>  Proposal:
>=20=20
>     0  A host report.  The overload treatment should apply to requests
>        for which all of the following conditions are true:
>        a) The Destination-Host AVP is present in the request and its value
>           matches the value of the Origin-Host AVP of the received message
>           that contained the OC-OLR AVP.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
>=20=20
>=20=20
>=20=20
>     1  A realm report.  The overload treatment should apply to
>        requests for which all of the following conditions are true:
>        a) The Destination-Host AVP is absent in the request.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
>=20=20
>=20=20
> ______________________________________________________________________
> ___________________________________________________
>=20=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From ulrich.wiehe@nsn.com  Tue Feb 11 03:32:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9F71A07DD for ; Tue, 11 Feb 2014 03:32:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFRIB1muRx_m for ; Tue, 11 Feb 2014 03:32:31 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8A1A0743 for ; Tue, 11 Feb 2014 03:32:29 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1BBWRGT004015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 12:32:27 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1BBWQRB025679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 12:32:27 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 12:32:26 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features
Thread-Index: AQHPJoT8YJYsHITJokaqYo5p3t3RPpqv5DWQ
Date: Tue, 11 Feb 2014 11:32:26 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2B12@DEMUMBX014.nsn-intra.net>
References: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> <78300994-0C77-47B5-B28E-D03048916AF3@gmail.com> <52F90B46.4060708@usdonovans.com>
In-Reply-To: <52F90B46.4060708@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2B12DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 28895
X-purgate-ID: 151667::1392118347-000025D0-F3C13AA8/0-0/0-0
Subject: Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 11:32:37 -0000

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

Steve,

the use case you are describing requires more than just a sequence number w=
ithin OC-Supported-Features. It also requires to add the Diameter identity =
of the reacting node (which inserted the OC-Supported-Features AVP)  to the=
 OC-Supported-Features AVP.

Even with this mechanism in place, reporting nodes still would need to pars=
e the OC-Supported-Features AVP to read Sequence-Number and Diameter Identi=
ty to check whether it is a replay. Also reporting nodes would need to main=
tain a database of reacting nodes.

Also, once a replay is detected, what is the benefit to process the stored =
Feature-Vector rather than the replayed Feature-Vector?

Overall the concept does not decrease work for reporting nodes and does not=
 provide any benefit.

Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 10, 2014 6:24 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features

If we agree that the lifetime of the OC-Supported-Features capability adver=
tisement is a single transaction then the utility of the sequence number is=
 reduced.

My reason for pushing for having the sequence number originally was based o=
n the assumption that the capability advertised by a reacting node was semi=
 permanent.  While there might be no earthly use, the heavenly use was to d=
ecrease the work for reporting nodes needing to parse the AVP on every requ=
est received.

It is still the case that the OC-Supported-Features AVP contents will almos=
t never change.  The contents of the AVP will also become more complex as n=
ew extensions are defined.  The value of the sequence number is to allow a =
reporting node to save the advertisement and not parse the full content of =
the AVP unless the sequence number changes.

I still think there is enough value in the reduced work on a reporting node=
 to keep the sequence number.

Steve
On 2/7/14 2:01 AM, Jouni Korhonen wrote:

Finally catching up with these.. see inline.





On Feb 4, 2014, at 10:46 AM, dime issue tracker  wrote:



#29: OC-Sequence-Number in OC-Supported-Features



According to the current definition of the OC-Supported-Features AVP in

the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence-

Number AVP.

The author of this document believes that OC-Sequence-Number within OC-

Supported-Feature is  not needed, is useless and could be misleading and

therefore proposes to remove OC-Sequence-Number from OC-Supported-Feature.



The -01 draft says in clause 4.1:

   The OC-Sequence-Number AVP is used to indicate whether the contents

   of the OC-Supported-Features AVP has changed since last time the node

   included the OC-Supported-Features AVP (see Section 4.4).  Although

   sending the OC-Sequence-Number AVP is mandatory in the OC-Supported-

   Features AVP, the receiving node MAY always choose to ignore the

   sequence number if it can determine the feature support changes

   otherwise.



The text seems to imply that the reporting DOIC endpoint, when receiving

an application request message that contains an OC-Supported-Features AVP,

needs to determine whether a feature support change occured (either by

checking the value of the received sequence-number (probably) against a

stored value, or by other unspecified means). However,  this is not

correct. The reporting DOIC endpoint may  ignore the sequence-number even

if it cannot determine whether or not a feature support change occured:

The reporting DOIC endpoint simply takes the value of the OC-Feature-

Vector as received in the request  into account (if absent the default

value applies) when processing the request.  There is no need for the

reporting DOIC endpoint to know whether a previous request contained the

same or a different value in OC-Feature-Vector, i.e. whether there was a

recent change.



This is true for the current default algorithm. May not be true in the

future. Note, in IETF space versioning Diameter applications is not that

straight forward as in 3GPP, thus I would rather have forward looking

solution, even if that in places would mean "placeholder" AVPs.



It has been argued that the reporting DOIC endpoint may (optionally)

benefit from the presence of a Sequence-Number within OC-Supported-

Features: The reporting DOIC endpoint may have stored the Sequence-Number

and Feature-Vector as received in a previous request, and when receiving a

new request the reporting DOIC endpoint would compare the received

Sequence-Number from the new request  with the stored Sequence-Number;  If

they match (i.e. no change of supported features occured) the reporting

DOIC endpoint would ignore the received Feature-Vector from the new

request and use the stored Feature-Vector for further processing; if they

don't match (i.e. a change of supported features occured), the reporting

DOIC endpoint would update the stored Sequence-Number and Feature-Vector

with the received values from the new request and use the updated Feature-

Vector for further processing. While it is debatable whether the described

usecase is reasonable, the following issues have not been addressed:

In configurations where the client does not support DOIC, an agent (A1) on

a path from client to reporting DOIC endpoint (e.g. server) may take the

role of a reacting DOIC endpoint and insert an OC-Supported-Features AVP

in the (first) request message indicating its supported features.  A

subsequent request message sent from the same client to the same server

may take another path on which another agent (A2) takes the role of the

reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP in

the subsequent request message indicating its supported features (which

may be different from A1's supported features but may have the same

sequence number).  Since the reporting DOIC endpoint (e.g.server) - when



Since seq-no is NTP time, this would not happen, excluding cases

where clocks either in A1 or A2 are wrong. But that is a different

issue then..



receiving the subsequent request - cannot know whether the the reacting

DOIC endpoint that inserted the OC-Supported-Features AVP in the

subsequent request is identical to or different from the reacting DOIC

endpoint that inserted the OC-Supported-Features AVP in the first request,



Right.



it may frequently occure that the reporting DOIC endpoint receives request

messages containing an OC-Supported-Features AVP with a Sequence-Number

valuelower than the stored value (which may be interpreted as error), or

equal to the stored value but with a different associated Feature Vector,

or higher than the stored value but unmodified Feature Vector.



See the above comment on the NPT.



In summary, the Sequence-Number within OC-Supported-Features is of no

earthly use since the reporting DOIC endpoint cannot associate a received

Sequence-Number (within OC-Supported-Features) with the identity of the

reacting DOIC endpoint that sent the Sequence-Number.  Even when such

association was possible by enhancing the OC-Supported-Features AVP with

the Diameter Identity of the reacting DOIC endpoint that generated the

Sequence-Number,  it would still simply not be needed as the reporting

DOIC endpoint can base its processing on the received Feature-Vector

(rather than on a stored Feature Vector).



I buy the reasoning for the lack of binding between the reacting node

identity and the supported features AVP.



However, we should not assume that _all_ implementations will behave

as expected above i.e. not storing the feature vector.



It is therefore proposed to remove the OC-Sequence-Number AVP from the OC-

Supported Features AVP.



I have no (more) strong view here. If folks are OK to remove

the seq-no, so be it.



- Jouni









--

----------------------------------------------+--------------------------

Reporter:  lionel.morand@orange-ftgroup.com  |      Owner:  Ulrich Wiehe

    Type:  defect                            |     Status:  new

Priority:  major                             |  Milestone:

Component:  draft-docdt-dime-ovli             |    Version:  2.0

Severity:  Active WG Document                |   Keywords:

----------------------------------------------+--------------------------



Ticket URL: 

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




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











Steve,<=
/p>

 <=
/p>

the use ca=
se you are describing requires more than just a sequence number within OC-S=
upported-Features. It also requires to add the Diameter identity
 of the reacting node (which inserted the OC-Supported-Features AVP)  =
to the OC-Supported-Features AVP.



 =
;


Even with =
this mechanism in place, reporting nodes still would need to parse the OC-S=
upported-Features AVP to read Sequence-Number and Diameter
 Identity to check whether it is a replay. Also reporting nodes would need =
to maintain a database of reacting nodes.



 =
;


Also, once=
 a replay is detected, what is the benefit to process the stored Feature-Ve=
ctor rather than the replayed Feature-Vector?


 =
;


Overall th=
e concept does not decrease work for reporting nodes and does not provide a=
ny benefit.


 =
;


Ulrich


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, February 10, 2014 6:24 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-F=
eatures






 


If we agree that the =
lifetime of the OC-Supported-Features capability advertisement is a single =
transaction then the utility of the sequence number is reduced. 




My reason for pushing for having the sequence number originally was based o=
n the assumption that the capability advertised by a reacting node was semi=
 permanent.  While there might be no earthly use, the heavenly use was=
 to decrease the work for reporting nodes
 needing to parse the AVP on every request received.  



It is still the case that the OC-Supported-Features AVP contents will almos=
t never change.  The contents of the AVP will also become more complex=
 as new extensions are defined.  The value of the sequence number is t=
o allow a reporting node to save the advertisement
 and not parse the full content of the AVP unless the sequence number chang=
es.  



I still think there is enough value in the reduced work on a reporting node=
 to keep the sequence number.



Steve




On 2/7/14 2:01 AM, Jouni Korhonen wrote:<=
/p>





Finally catching up with these.. see inline.


 


 


On Feb 4, 2014, at 10:46 AM, dime issue tracker <trac+dime@trac.tools.ietf.org> wrote:


 




#29: OC-Sequence-Number in OC-Supported-Features


 


According to the current definition of the OC-Supported-Features AVP i=
n


the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence-<=
o:p>


Number AVP.


The author of this document believes that OC-Sequence-Number within OC=
-


Supported-Feature is  not needed, is useless and could be mislead=
ing and


therefore proposes to remove OC-Sequence-Number from OC-Supported-Feat=
ure.


 


The -01 draft says in clause 4.1:


   The OC-Sequence-Number AVP is used to indicate whether th=
e contents


   of the OC-Supported-Features AVP has changed since last t=
ime the node


   included the OC-Supported-Features AVP (see Section 4.4).=
  Although


   sending the OC-Sequence-Number AVP is mandatory in the OC=
-Supported-


   Features AVP, the receiving node MAY always choose to ign=
ore the


   sequence number if it can determine the feature support c=
hanges


   otherwise.


 


The text seems to imply that the reporting DOIC endpoint, when receivi=
ng


an application request message that contains an OC-Supported-Features =
AVP,


needs to determine whether a feature support change occured (either by=



checking the value of the received sequence-number (probably) against =
a


stored value, or by other unspecified means). However,  this is n=
ot


correct. The reporting DOIC endpoint may  ignore the sequence-num=
ber even


if it cannot determine whether or not a feature support change occured=
:


The reporting DOIC endpoint simply takes the value of the OC-Feature-<=
o:p>


Vector as received in the request  into account (if absent the de=
fault


value applies) when processing the request.  There is no need for=
 the


reporting DOIC endpoint to know whether a previous request contained t=
he


same or a different value in OC-Feature-Vector, i.e. whether there was=
 a


recent change.




 


This is true for the current default algorithm. May not be true in the=



future. Note, in IETF space versioning Diameter applications is not th=
at


straight forward as in 3GPP, thus I would rather have forward looking<=
o:p>


solution, even if that in places would mean "placeholder" AV=
Ps.


 




It has been argued that the reporting DOIC endpoint may (optionally)


benefit from the presence of a Sequence-Number within OC-Supported-


Features: The reporting DOIC endpoint may have stored the Sequence-Num=
ber


and Feature-Vector as received in a previous request, and when receivi=
ng a


new request the reporting DOIC endpoint would compare the received


Sequence-Number from the new request  with the stored Sequence-Nu=
mber;  If


they match (i.e. no change of supported features occured) the reportin=
g


DOIC endpoint would ignore the received Feature-Vector from the new


request and use the stored Feature-Vector for further processing; if t=
hey


don't match (i.e. a change of supported features occured), the reporti=
ng


DOIC endpoint would update the stored Sequence-Number and Feature-Vect=
or


with the received values from the new request and use the updated Feat=
ure-


Vector for further processing. While it is debatable whether the descr=
ibed


usecase is reasonable, the following issues have not been addressed:


In configurations where the client does not support DOIC, an agent (A1=
) on


a path from client to reporting DOIC endpoint (e.g. server) may take t=
he


role of a reacting DOIC endpoint and insert an OC-Supported-Features A=
VP


in the (first) request message indicating its supported features. =
; A


subsequent request message sent from the same client to the same serve=
r


may take another path on which another agent (A2) takes the role of th=
e


reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP i=
n


the subsequent request message indicating its supported features (whic=
h


may be different from A1's supported features but may have the same


sequence number).  Since the reporting DOIC endpoint (e.g.server)=
 - when




 


Since seq-no is NTP time, this would not happen, excluding cases<=
/o:p>


where clocks either in A1 or A2 are wrong. But that is a different


issue then..


 




receiving the subsequent request - cannot know whether the the reactin=
g


DOIC endpoint that inserted the OC-Supported-Features AVP in the<=
/o:p>


subsequent request is identical to or different from the reacting DOIC=



endpoint that inserted the OC-Supported-Features AVP in the first requ=
est,




 


Right.


 




it may frequently occure that the reporting DOIC endpoint receives req=
uest


messages containing an OC-Supported-Features AVP with a Sequence-Numbe=
r


valuelower than the stored value (which may be interpreted as error), =
or


equal to the stored value but with a different associated Feature Vect=
or,


or higher than the stored value but unmodified Feature Vector.




 


See the above comment on the NPT.


 




In summary, the Sequence-Number within OC-Supported-Features is of no<=
o:p>


earthly use since the reporting DOIC endpoint cannot associate a recei=
ved


Sequence-Number (within OC-Supported-Features) with the identity of th=
e


reacting DOIC endpoint that sent the Sequence-Number.  Even when =
such


association was possible by enhancing the OC-Supported-Features AVP wi=
th


the Diameter Identity of the reacting DOIC endpoint that generated the=



Sequence-Number,  it would still simply not be needed as the repo=
rting


DOIC endpoint can base its processing on the received Feature-Vector


(rather than on a stored Feature Vector).




 


I buy the reasoning for the lack of binding between the reacting node<=
o:p>


identity and the supported features AVP.


 


However, we should not assume that _all_ implementations will behave


as expected above i.e. not storing the feature vector.

 




It is therefore proposed to remove the OC-Sequence-Number AVP from the=
 OC-


Supported Features AVP.




 


I have no (more) strong view here. If folks are OK to remove


the seq-no, so be it.


 


- Jouni


 


 


 




 


-- 


----------------------------------------------+-------------------=
-------


Reporter:  li=
onel.morand@orange-ftgroup.com  |      Ow=
ner:  Ulrich Wiehe


    Type:  defect     &nb=
sp;            =
          |   &=
nbsp; Status:  new


Priority:  major        &=
nbsp;           &nbs=
p;        |  Milestone:<=
/pre>

Component:  draft-docdt-dime-ovli     &n=
bsp;       |    Version: =
 2.0


Severity:  Active WG Document      =
          |   Keywor=
ds:


----------------------------------------------+-------------------=
-------


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/29>


dime <http://tools.ietf.=
org/wg/dime/>


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2B12DEMUMBX014nsnin_--


From srdonovan@usdonovans.com  Tue Feb 11 04:19:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F66E1A0825 for ; Tue, 11 Feb 2014 04:19:59 -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
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 yeRbTxYdeWaz for ; Tue, 11 Feb 2014 04:19:53 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 309E81A0281 for ; Tue, 11 Feb 2014 04:19:53 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60634 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDCJW-0005Za-LF; Tue, 11 Feb 2014 04:19:50 -0800
Message-ID: <52FA1561.8040807@usdonovans.com>
Date: Tue, 11 Feb 2014 06:19:45 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Nirav Salot (nsalot)" ,  "lionel.morand@orange.com" , Jouni Korhonen ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020307070101020101050002"
X-OutGoing-Spam-Status: No, score=-2.9
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
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:19:59 -0000

This is a multi-part message in MIME format.
--------------020307070101020101050002
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

The definition of a realm overload report is to decrease the total
number of requests sent to the realm.  The algorithm suggests one way of
achieving the reduction of traffic.  Other approaches could clearly be
taken, as long as the total amount of traffic to the realm is reduced.

Steve


On 2/11/14 3:57 AM, Nirav Salot (nsalot) wrote:
>
> Steve,
>
>  
>
> I don't understand one aspect.
>
> Why should the request be throttled with realm report when the request
> is targeted to a particular host within the realm.
>
> Can this request be routed to another host in that realm? If not, the
> request should be subjected to the throttling based on the host report.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* Monday, February 10, 2014 11:22 PM
> *To:* lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN -
> DE/Munich)
> *Cc:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> Lionel,
>
> Why would the reduction for the realm be less than servers.  It is
> perfectly valid for a realm overload report to ask for a reduction
> when there are no servers in overload.  This could happen in the case
> I mentioned where the realm overload report is triggered by layer 3
> congestion.
>
> Clearly realm overload will be significantly influenced by server
> overload, but that isn't the only consideration.
>
> My logic was not quite correct, but for a different reason.  There is
> no reason to do the host throttling if the request has already been
> throttled by the realm report.
> It should be as follows:
>
> For all requests:
>   If there is a realm overload report that applies to the request:
>     Apply realm based throttling logic to that request
>   If the request has not already been throttled and there is a host
> overload report that applies to the request:
>     Apply host based throttling logic to that request
>
> One improvement would be to remember the host throttled by the realm
> abatement algorithm and input that into the server abatement
> algorithm.  This might look something like the following:
>
> For all requests:
>   If there is a realm overload report that applies to the request:
>     Apply realm based throttling logic to that request
>     If request is throttled:
>       Increment host credit by one for the host indicated in the
> destination-host AVP
>   If the request has not already been throttled and there is a host
> overload report that applies to the request:
>     If host credits exist for the host indicated in the
> destination-host AVP:
>       Decrement host credit by one
>     else:
>       Apply host based throttling logic to that request
>
> Steve
>
> On 2/10/14 10:59 AM, lionel.morand@orange.com
>  wrote:
>
>     Hi Steve,
>
>      
>
>     In your example, if an agent has a better knowledge than the
>     server, the Host type OLR should not be sent unmodified in
>     forwarded answers, or even removed as irrelevant.
>
>      
>
>     And in a normal case, the reduction for the realm will be likely
>     lower than the reduction needed for a node. S1 is not overload, S2
>     is 50% overload, the realm (S1+S2) is overloaded 25%. So only the
>     reduction for the Host should apply, why the host-type should
>     prevail over realm-type OLR.
>
>      
>
>     By the way, in your proposed logic, it is not clear if the
>     relation between the first and the second conditions is an "IF NOT".
>
>      
>
>     Lionel
>
>      
>
>     *De :*Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Envoyé :* lundi 10 février 2014 15:39
>     *À :* MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN -
>     DE/Munich)
>     *Cc :* dime@ietf.org 
>     *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     I think we have agreement that a realm report applies to all
>     traffic targeted for that realm, independent of the presence or
>     absence of the destination-host avp.  Is that correct?
>
>     I don't agree with Lionel's proposal.  The realm overload report
>     should take precedence over the host overload report.
>
>     My reasoning is as follows:
>
>     - There is something responsible for tracking the health of the
>     realm.  Call it the "realm overload authority".  The health of the
>     realm can be based on a number of factors including the health of
>     individual servers, individual agents and the network connecting
>     Diameter entities.
>
>     - When this "realm overload authority" determines that the IP
>     network is congested, for instance, it would instruct agents or
>     servers to send realm overload reports with the expectation that
>     the overall traffic sent to the realm as a whole will be reduced.
>
>     In this scenario, the fact that the realm is overloaded takes
>     precedence over the health of the servers.  As such, it is likely
>     that requests targeted for a healthy server will be throttled.
>
>     I propose the logic should be as follows:
>
>     For all requests:
>       If there is a realm overload report that applies to the request:
>         Apply realm based trottling logic to that request
>       If there is a host overload report that applies to the request:
>         Apply host based throttling logic to that request
>
>     Note that this also requires the ability to put realm overload
>     reports in any answer message, not just answers to requests that
>     did not contain a destination-host AVP.
>
>     Steve
>
>     On 2/10/14 5:30 AM, lionel.morand@orange.com
>      wrote:
>
>         No it was not my intention and it is why it was written "except" :)
>
>          
>
>         The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.
>
>          
>
>         Is it clearer?
>
>          
>
>         Lioenl 
>
>          
>
>         -----Message d'origine-----
>
>         De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Envoyé : dimanche 9 février 2014 13:46
>
>         À : Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org 
>
>         Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>          
>
>          
>
>         On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>          
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>             Sent: Friday, February 07, 2014 11:21 AM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: ext lionel.morand@orange.com ; Steve Donovan; dime@ietf.org 
>
>             Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>              
>
>              
>
>             On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>              
>
>                 I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>
>                 What is wrong with letting the client
>
>                 -not throttle host-type requests to S1,
>
>                 -throttle host type request to S2 with 50% and
>
>                 -throttle realm type requests wit 25%?
>
>              
>
>             Isn't this what Lionel said below?
>
>              no it is not
>
>          
>
>          
>
>         Ok, maybe I misread the "realm abatement is applied in any case
>
>         except if there is an explicit report for the destination-host"?
>
>          
>
>         If this means the realm abatement is still applied after applying
>
>         the host abatement, then I agree it is not the same you said.
>
>          
>
>         - Jouni
>
>          
>
>          
>
>             I am OK with Lionel's
>
>             "wording" here.
>
>              
>
>             - Jouni
>
>              
>
>                  
>
>                  
>
>                  
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com 
>
>                 Sent: Wednesday, February 05, 2014 4:14 PM
>
>                 To: Steve Donovan; dime@ietf.org 
>
>                 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.
>
>                  
>
>                 Lioenl
>
>                  
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>
>                 Envoyé : mercredi 5 février 2014 15:56
>
>                 À : dime@ietf.org 
>
>                 Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.
>
>                  
>
>                 If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.
>
>                  
>
>                 I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.
>
>                  
>
>                 Steve
>
>                  
>
>                 On 2/4/14 11:12 AM, lionel.morand@orange.com  wrote:
>
>                 The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
>
>                 If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.
>
>                  
>
>                 Does it make sense?
>
>                  
>
>                 Lionel
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
>
>                 Envoyé : mardi 4 février 2014 09:55
>
>                 À : MORAND Lionel IMT/OLN
>
>                 Cc : dime@ietf.org 
>
>                 Objet : [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 Text in clause 4.6  does not fully explain to which requests overload
>
>                 treatment of a given report type applies.
>
>                 Proposal:
>
>                  
>
>                    0  A host report.  The overload treatment should apply to requests
>
>                       for which all of the following conditions are true:
>
>                       a) The Destination-Host AVP is present in the request and its value
>
>                          matches the value of the Origin-Host AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       b) The value of the Destination-Realm AVP in the request matches the
>
>                          value of the Origin-Realm AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       c) The value of the Application-ID in the Diameter Header of the
>
>                          request matches the value of the Application-ID of the Diameter
>
>                          Header of the received message that contained the OC-OLR AVP.
>
>                  
>
>                  
>
>                  
>
>                    1  A realm report.  The overload treatment should apply to
>
>                       requests for which all of the following conditions are true:
>
>                       a) The Destination-Host AVP is absent in the request.
>
>                       b) The value of the Destination-Realm AVP in the request matches the
>
>                          value of the Origin-Realm AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       c) The value of the Application-ID in the Diameter Header of the
>
>                          request matches the value of the Application-ID of the Diameter
>
>                          Header of the received message that contained the OC-OLR AVP.
>
>                  
>
>                  
>
>                 _________________________________________________________________________________________________________________________
>
>                  
>
>                 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.
>
>                 _______________________________________________
>
>                 DiME mailing list
>
>                 DiME@ietf.org 
>
>                 https://www.ietf.org/mailman/listinfo/dime
>
>              
>
>          
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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.
>
>  
>


--------------020307070101020101050002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    The definition of a realm overload report is to decrease the total
    number of requests sent to the realm.  The algorithm suggests one
    way of achieving the reduction of traffic.  Other approaches could
    clearly be taken, as long as the total amount of traffic to the
    realm is reduced.

    

    Steve

    

    

    
On 2/11/14 3:57 AM, Nirav Salot
      (nsalot) wrote:

    

    

      
      
      
      

        
Steve,
            

        
 

        
I
            don’t understand one aspect.

        
Why
            should the request be throttled with realm report when the
            request is targeted to a particular host within the realm.

        
Can
            this request be routed to another host in that realm? If
            not, the request should be subjected to the throttling based
            on the host report.

        
 

        
Regards,

        
Nirav.

        
 

        

          

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

                Sent: Monday, February 10, 2014 11:22 PM

                To: lionel.morand@orange.com; Jouni Korhonen;
                Wiehe, Ulrich (NSN - DE/Munich)

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
Lionel,

          

          Why would the reduction for the realm be less than servers. 
          It is perfectly valid for a realm overload report to ask for a
          reduction when there are no servers in overload.  This could
          happen in the case I mentioned where the realm overload report
          is triggered by layer 3 congestion.

          

          Clearly realm overload will be significantly influenced by
          server overload, but that isn't the only consideration.

          

          My logic was not quite correct, but for a different reason. 
          There is no reason to do the host throttling if the request
          has already been throttled by the realm report.

          It should be as follows:

          

          For all requests:

            If there is a realm overload report that applies to the
          request:

              Apply realm based throttling logic to that request

            If the request has not already been throttled and there is a
          host overload report that applies to the request:

              Apply host based throttling logic to that request

          

          One improvement would be to remember the host throttled by the
          realm abatement algorithm and input that into the server
          abatement algorithm.  This might look something like the
          following:

          

          For all requests:

              If there is a realm overload report that applies to the
            request:

                Apply realm based throttling logic to that request

                If request is throttled:

                  Increment host credit by one for the host indicated in
            the destination-host AVP

              If the request has not already been throttled and there is
            a host overload report that applies to the request:

                If host credits exist for the host indicated in the
            destination-host AVP:

                  Decrement host credit by one

                else:

                  Apply host based throttling logic to that request

          

          Steve

        

          
On 2/10/14 10:59 AM, 
              lionel.morand@orange.com wrote:

        

        

          
Hi
              Steve,

          
 

          
In
              your example, if an agent has a better knowledge than the
              server, the Host type OLR should not be sent unmodified in
              forwarded answers, or even removed as irrelevant.

          
 

          
And
              in a normal case, the reduction for the realm will be
              likely lower than the reduction needed for a node. S1 is
              not overload, S2 is 50% overload, the realm (S1+S2) is
              overloaded 25%. So only the reduction for the Host should
              apply, why the host-type should prevail over realm-type
              OLR.

          
 

          
By
              the way, in your proposed logic, it is not clear if the
              relation between the first and the second conditions is an
              "IF NOT".
            

          
 

          
Lionel

          
 

          

            

              
De :
                  Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Envoyé : lundi 10 février 2014 15:39

                  À : MORAND Lionel IMT/OLN; Jouni Korhonen;
                  Wiehe, Ulrich (NSN - DE/Munich)

                  Cc : dime@ietf.org

                  Objet : Re: [Dime] [dime] #34: Semantics of
                  OC-Report-Type AVP

            

          

          
 

          
I think we
            have agreement that a realm report applies to all traffic
            targeted for that realm, independent of the presence or
            absence of the destination-host avp.  Is that correct?

            

            I don't agree with Lionel's proposal.  The realm overload
            report should take precedence over the host overload report.

            

            My reasoning is as follows:

            

            - There is something responsible for tracking the health of
            the realm.  Call it the "realm overload authority".  The
            health of the realm can be based on a number of factors
            including the health of individual servers, individual
            agents and the network connecting Diameter entities.

            

            - When this "realm overload authority" determines that the
            IP network is congested, for instance, it would instruct
            agents or servers to send realm overload reports with the
            expectation that the overall traffic sent to the realm as a
            whole will be reduced.

            

            In this scenario, the fact that the realm is overloaded
            takes precedence over the health of the servers.  As such,
            it is likely that requests targeted for a healthy server
            will be throttled.

            

            I propose the logic should be as follows:

            

            For all requests:

              If there is a realm overload report that applies to the
            request:

                Apply realm based trottling logic to that request

              If there is a host overload report that applies to the
            request:

                Apply host based throttling logic to that request

            

            Note that this also requires the ability to put realm
            overload reports in any answer message, not just answers to
            requests that did not contain a destination-host AVP.

            

            Steve

          

            
On 2/10/14 5:30 AM, 
                lionel.morand@orange.com wrote:

          

          

            
No it was not my intention and it is why it was written "except" :)

            
 

            
The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.

            
 

            
Is it clearer?

            
 

            
Lioenl 

            
 

            
-----Message d'origine-----

            
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

            
Envoyé : dimanche 9 février 2014 13:46

            
À : Wiehe, Ulrich (NSN - DE/Munich)

            
Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

            
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

            
 

            
 

            
On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

            
 

            

              
 

              
 

              
-----Original Message-----

              
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

              
Sent: Friday, February 07, 2014 11:21 AM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org

              
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

              
 

              
 

              
On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

              
 

              

                
I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?

                
What is wrong with letting the client

                
-not throttle host-type requests to S1,

                
-throttle host type request to S2 with 50% and

                
-throttle realm type requests wit 25%?

              

              
 

              
Isn't this what Lionel said below?

              
<Ulrich> no it is not</Ulrich>

            

            
 

            
 

            
Ok, maybe I misread the "realm abatement is applied in any case

            
except if there is an explicit report for the destination-host"?

            
 

            
If this means the realm abatement is still applied after applying

            
the host abatement, then I agree it is not the same you said.

            
 

            
- Jouni

            
 

            
 

            

              
I am OK with Lionel's

              
"wording" here.

              
 

              
- Jouni

              
 

              

                
 

                
 

                
 

                
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com

                
Sent: Wednesday, February 05, 2014 4:14 PM

                
To: Steve Donovan; dime@ietf.org

                
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

                
 

                
Lioenl

                
 

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

                
Envoyé : mercredi 5 février 2014 15:56

                
À : dime@ietf.org

                
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

                
 

                
If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

                
 

                
I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

                
 

                
Steve

                
 

                
On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

                
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?

                
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

                
 

                
Does it make sense?

                
 

                
Lionel

                
 

                
-----Message d'origine-----

                
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 

                
Envoyé : mardi 4 février 2014 09:55

                
À : MORAND Lionel IMT/OLN

                
Cc : dime@ietf.org

                
Objet : [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
#34: Semantics of OC-Report-Type AVP

                
 

                
Text in clause 4.6  does not fully explain to which requests overload

                
treatment of a given report type applies.

                
Proposal:

                
 

                
   0  A host report.  The overload treatment should apply to requests

                
      for which all of the following conditions are true:

                
      a) The Destination-Host AVP is present in the request and its value

                
         matches the value of the Origin-Host AVP of the received message

                
         that contained the OC-OLR AVP.

                
      b) The value of the Destination-Realm AVP in the request matches the

                
         value of the Origin-Realm AVP of the received message

                
         that contained the OC-OLR AVP.

                
      c) The value of the Application-ID in the Diameter Header of the

                
         request matches the value of the Application-ID of the Diameter

                
         Header of the received message that contained the OC-OLR AVP.

                
 

                
 

                
 

                
   1  A realm report.  The overload treatment should apply to

                
      requests for which all of the following conditions are true:

                
      a) The Destination-Host AVP is absent in the request.

                
      b) The value of the Destination-Realm AVP in the request matches the

                
         value of the Origin-Realm AVP of the received message

                
         that contained the OC-OLR AVP.

                
      c) The value of the Application-ID in the Diameter Header of the

                
         request matches the value of the Application-ID of the Diameter

                
         Header of the received message that contained the OC-OLR AVP.

                
 

                
 

                
_________________________________________________________________________________________________________________________

                
 

                
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.

                
_______________________________________________

                
DiME mailing list

                
DiME@ietf.org

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

              

              
 

            

            
 

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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.

        

        
 

      

    

    

  


--------------020307070101020101050002--


From srdonovan@usdonovans.com  Tue Feb 11 04:22:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE501A0825 for ; Tue, 11 Feb 2014 04:22:54 -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
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 wPZ-C4fAE6Am for ; Tue, 11 Feb 2014 04:22:47 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 851971A081C for ; Tue, 11 Feb 2014 04:22:47 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60699 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDCMO-00020H-Cc for dime@ietf.org; Tue, 11 Feb 2014 04:22:47 -0800
Message-ID: <52FA1613.6070507@usdonovans.com>
Date: Tue, 11 Feb 2014 06:22:43 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29D6@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772F07@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772F07@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------040706080009000200020206"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:22:55 -0000

This is a multi-part message in MIME format.
--------------040706080009000200020206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

The we have disagreement on the definition of the Realm overload report.

Multiple times it has been said the that realm report applied to all
requests, independent of the content or presence of the destination-host
AVP.

A realm overload report is of limited value if it does not apply to all
traffic sent to the realm.  It is a needed tool to protect a realm from
a network wide issue that cannot be detected by just looking at the
overload status of individual servers.

Steve

On 2/11/14 4:51 AM, Maria Cruz Bartolome wrote:
>
> Hello all,
>
>  
>
> I agree with Ulrich comments, since I agree on the basic approach as
> mentioned already in this thread (inline with JJ comments as well):
>
>  
>
> - Host OLR based control applies to requests where Destination Host is
> known
>
> - Realm OLR based control applies to requests where Destination Host
> is not known (only the Destination realm).
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Monday, February 10, 2014 6:52 PM
> *To:* lionel.morand@orange.com ;
> Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
> *Cc:* dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> Lionel,
>
> Why would the reduction for the realm be less than servers.  It is
> perfectly valid for a realm overload report to ask for a reduction
> when there are no servers in overload.
>
> */ I don't think so/*
>
>   This could happen in the case I mentioned where the realm overload
> report is triggered by layer 3 congestion.
>
> Clearly realm overload will be significantly influenced by server
> overload, but that isn't the only consideration.
>
> */ all considerations other than server overload are (or
> should be) out of scope. (May be covered by agent overload
> control)/*
>
> My logic was not quite correct, but for a different reason.  There is
> no reason to do the host throttling if the request has already been
> throttled by the realm report.
> It should be as follows:
>
> For all requests:
>   If there is a realm overload report that applies to the request:
>     Apply realm based throttling logic to that request
>   If the request has not already been throttled and there is a host
> overload report that applies to the request:
>     Apply host based throttling logic to that request
>
> One improvement would be to remember the host throttled by the realm
> abatement algorithm and input that into the server abatement
> algorithm.  This might look something like the following:
>
> For all requests:
>   If there is a realm overload report that applies to the request:
>     Apply realm based throttling logic to that request
>     If request is throttled:
>       Increment host credit by one for the host indicated in the
> destination-host AVP
>   If the request has not already been throttled and there is a host
> overload report that applies to the request:
>     If host credits exist for the host indicated in the
> destination-host AVP:
>       Decrement host credit by one
>     else:
>       Apply host based throttling logic to that request
> */ sounds quite complicated/*
> Steve
>
> On 2/10/14 10:59 AM, lionel.morand@orange.com
>  wrote:
>
>     Hi Steve,
>
>      
>
>     In your example, if an agent has a better knowledge than the
>     server, the Host type OLR should not be sent unmodified in
>     forwarded answers, or even removed as irrelevant.
>
>      
>
>     And in a normal case, the reduction for the realm will be likely
>     lower than the reduction needed for a node. S1 is not overload, S2
>     is 50% overload, the realm (S1+S2) is overloaded 25%. So only the
>     reduction for the Host should apply, why the host-type should
>     prevail over realm-type OLR.
>
>      
>
>     By the way, in your proposed logic, it is not clear if the
>     relation between the first and the second conditions is an "IF NOT".
>
>      
>
>     Lionel
>
>      
>
>     *De :*Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Envoyé :* lundi 10 février 2014 15:39
>     *À :* MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN -
>     DE/Munich)
>     *Cc :* dime@ietf.org 
>     *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     I think we have agreement that a realm report applies to all
>     traffic targeted for that realm, independent of the presence or
>     absence of the destination-host avp.  Is that correct?
>
>     I don't agree with Lionel's proposal.  The realm overload report
>     should take precedence over the host overload report.
>
>     My reasoning is as follows:
>
>     - There is something responsible for tracking the health of the
>     realm.  Call it the "realm overload authority".  The health of the
>     realm can be based on a number of factors including the health of
>     individual servers, individual agents and the network connecting
>     Diameter entities.
>
>     - When this "realm overload authority" determines that the IP
>     network is congested, for instance, it would instruct agents or
>     servers to send realm overload reports with the expectation that
>     the overall traffic sent to the realm as a whole will be reduced.
>
>     In this scenario, the fact that the realm is overloaded takes
>     precedence over the health of the servers.  As such, it is likely
>     that requests targeted for a healthy server will be throttled.
>
>     I propose the logic should be as follows:
>
>     For all requests:
>       If there is a realm overload report that applies to the request:
>         Apply realm based trottling logic to that request
>       If there is a host overload report that applies to the request:
>         Apply host based throttling logic to that request
>
>     Note that this also requires the ability to put realm overload
>     reports in any answer message, not just answers to requests that
>     did not contain a destination-host AVP.
>
>     Steve
>
>     On 2/10/14 5:30 AM, lionel.morand@orange.com
>      wrote:
>
>         No it was not my intention and it is why it was written "except" :)
>
>          
>
>         The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.
>
>          
>
>         Is it clearer?
>
>          
>
>         Lioenl 
>
>          
>
>         -----Message d'origine-----
>
>         De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Envoyé : dimanche 9 février 2014 13:46
>
>         À : Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org 
>
>         Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>          
>
>          
>
>         On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>          
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>             Sent: Friday, February 07, 2014 11:21 AM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: ext lionel.morand@orange.com ; Steve Donovan; dime@ietf.org 
>
>             Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>              
>
>              
>
>             On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>              
>
>                 I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>
>                 What is wrong with letting the client
>
>                 -not throttle host-type requests to S1,
>
>                 -throttle host type request to S2 with 50% and
>
>                 -throttle realm type requests wit 25%?
>
>              
>
>             Isn't this what Lionel said below?
>
>              no it is not
>
>          
>
>          
>
>         Ok, maybe I misread the "realm abatement is applied in any case
>
>         except if there is an explicit report for the destination-host"?
>
>          
>
>         If this means the realm abatement is still applied after applying
>
>         the host abatement, then I agree it is not the same you said.
>
>          
>
>         - Jouni
>
>          
>
>          
>
>             I am OK with Lionel's
>
>             "wording" here.
>
>              
>
>             - Jouni
>
>              
>
>                  
>
>                  
>
>                  
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com 
>
>                 Sent: Wednesday, February 05, 2014 4:14 PM
>
>                 To: Steve Donovan; dime@ietf.org 
>
>                 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.
>
>                  
>
>                 Lioenl
>
>                  
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>
>                 Envoyé : mercredi 5 février 2014 15:56
>
>                 À : dime@ietf.org 
>
>                 Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.
>
>                  
>
>                 If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.
>
>                  
>
>                 I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.
>
>                  
>
>                 Steve
>
>                  
>
>                 On 2/4/14 11:12 AM, lionel.morand@orange.com  wrote:
>
>                 The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
>
>                 If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.
>
>                  
>
>                 Does it make sense?
>
>                  
>
>                 Lionel
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
>
>                 Envoyé : mardi 4 février 2014 09:55
>
>                 À : MORAND Lionel IMT/OLN
>
>                 Cc : dime@ietf.org 
>
>                 Objet : [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 Text in clause 4.6  does not fully explain to which requests overload
>
>                 treatment of a given report type applies.
>
>                 Proposal:
>
>                  
>
>                    0  A host report.  The overload treatment should apply to requests
>
>                       for which all of the following conditions are true:
>
>                       a) The Destination-Host AVP is present in the request and its value
>
>                          matches the value of the Origin-Host AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       b) The value of the Destination-Realm AVP in the request matches the
>
>                          value of the Origin-Realm AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       c) The value of the Application-ID in the Diameter Header of the
>
>                          request matches the value of the Application-ID of the Diameter
>
>                          Header of the received message that contained the OC-OLR AVP.
>
>                  
>
>                  
>
>                  
>
>                    1  A realm report.  The overload treatment should apply to
>
>                       requests for which all of the following conditions are true:
>
>                       a) The Destination-Host AVP is absent in the request.
>
>                       b) The value of the Destination-Realm AVP in the request matches the
>
>                          value of the Origin-Realm AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       c) The value of the Application-ID in the Diameter Header of the
>
>                          request matches the value of the Application-ID of the Diameter
>
>                          Header of the received message that contained the OC-OLR AVP.
>
>                  
>
>                  
>
>                 _________________________________________________________________________________________________________________________
>
>                  
>
>                 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.
>
>                 _______________________________________________
>
>                 DiME mailing list
>
>                 DiME@ietf.org 
>
>                 https://www.ietf.org/mailman/listinfo/dime
>
>              
>
>          
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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.
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------040706080009000200020206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    The we have disagreement
      on the definition of the Realm overload report.

      

      Multiple times it has been said the that realm report applied to
      all requests, independent of the content or presence of the
      destination-host AVP.

      

      A realm overload report is of limited value if it does not apply
      to all traffic sent to the realm.  It is a needed tool to protect
      a realm from a network wide issue that cannot be detected by just
      looking at the overload status of individual servers.

      

      Steve

      

    
    
On 2/11/14 4:51 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello
            all,

        
 

        
I
            agree with Ulrich comments, since I agree on the basic
            approach as mentioned already in this thread (inline with JJ
            comments as well):

        
 

        
- Host OLR based control applies to
          requests where Destination Host is known

        
- Realm OLR based control applies to
          requests where Destination Host is not known (only the
          Destination realm).

        
 

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: Monday, February 10, 2014 6:52 PM

                To: lionel.morand@orange.com;
                Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
Lionel,

            

            Why would the reduction for the realm be less than servers. 
            It is perfectly valid for a realm overload report to ask for
            a reduction when there are no servers in overload.

        
<Ulrich>
                I don’t think so</Ulrich>

        
  This could
          happen in the case I mentioned where the realm overload report
          is triggered by layer 3 congestion.

          

          Clearly realm overload will be significantly
            influenced by server overload, but that isn't the only
            consideration.

        
<Ulrich>
                all considerations other than server overload are (or
                should be) out of scope. (May be covered by agent
                overload control)</Ulrich>

          

          My logic was not quite correct, but for a different reason.  There is no reason to do the host throttling if
            the request has already been throttled by the realm report.

            It should be as follows:

            

            For all requests:

              If there is a realm overload report that applies to the
            request:

                Apply realm based throttling logic to that request

              If the request has not already been throttled and there is
            a host overload report that applies to the request:

                Apply host based throttling logic to that request

            

            One improvement would be to remember the host throttled by
            the realm abatement algorithm and input that into the server
            abatement algorithm. 
          This might look something like the following:

          

          For
            all requests:

              If there is a realm overload report that applies to the
            request:

                Apply realm based throttling logic to that request

                If request is throttled:

                  Increment host credit by one for the host indicated in
            the destination-host AVP

              If the request has not already been throttled and there is
            a host overload report that applies to the request:

                If host credits exist for the host indicated in the
            destination-host AVP:

                  Decrement host credit by one

                else:

                  Apply host based throttling logic to that request

          <Ulrich> sounds
                quite complicated</Ulrich>

          Steve

        

          
On 2/10/14 10:59 AM, 
                lionel.morand@orange.com wrote:

        

        

          
Hi Steve,

          
 

          
In
              your example, if an agent has a better knowledge than the
              server, the Host type OLR should not be sent unmodified in
              forwarded answers, or even removed as irrelevant.

          
 

          
And
              in a normal case, the reduction for the realm will be
              likely lower than the reduction needed for a node. S1 is
              not overload, S2 is 50% overload, the realm (S1+S2) is
              overloaded 25%. So only the reduction for the Host should
              apply, why the host-type should prevail over realm-type
              OLR.

          
 

          
By
              the way, in your proposed logic, it is not clear if the
              relation between the first and the second conditions is an
              "IF NOT".
            

          
 

          
Lionel

          
 

          

            

              
De : Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Envoyé : lundi 10 février 2014 15:39

                  À : MORAND Lionel IMT/OLN; Jouni Korhonen;
                  Wiehe, Ulrich (NSN - DE/Munich)

                  Cc : dime@ietf.org

                  Objet : Re: [Dime] [dime] #34: Semantics of
                  OC-Report-Type AVP

            

          

          
 

          
I think we have agreement that a realm report
              applies to all traffic targeted for that realm,
              independent of the presence or absence of the
              destination-host avp.  Is that correct?

              

              I don't agree with Lionel's proposal.  The realm overload
              report should take precedence over the host overload
              report.

              

              My reasoning is as follows:

              

              - There is something responsible for tracking the health
              of the realm.  Call it the "realm overload authority". 
              The health of the realm can be based on a number of
              factors including the health of individual servers,
              individual agents and the network connecting Diameter
              entities.

              

              - When this "realm overload authority" determines that the
              IP network is congested, for instance, it would instruct
              agents or servers to send realm overload reports with the
              expectation that the overall traffic sent to the realm as
              a whole will be reduced.

              

              In this scenario, the fact that the realm is overloaded
              takes precedence over the health of the servers.  As such,
              it is likely that requests targeted for a healthy server
              will be throttled.

              

              I propose the logic should be as follows:

              

              For all requests:

                If there is a realm overload report that applies to the
              request:

                  Apply realm based trottling logic to that request

                If there is a host overload report that applies to the
              request:

                  Apply host based throttling logic to that request

              

              Note that this also requires the ability to put realm
              overload reports in any answer message, not just answers
              to requests that did not contain a destination-host AVP.

              

              Steve

          

            
On 2/10/14 5:30 AM, 
                  lionel.morand@orange.com wrote:

          

          

            
No it was not my intention and it is why it was written "except" :)

            
 

            
The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.

            
 

            
Is it clearer?

            
 

            
Lioenl 

            
 

            
-----Message d'origine-----

            
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

            
Envoyé : dimanche 9 février 2014 13:46

            
À : Wiehe, Ulrich (NSN - DE/Munich)

            
Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

            
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

            
 

            
 

            
On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

            
 

            

              
 

              
 

              
-----Original Message-----

              
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

              
Sent: Friday, February 07, 2014 11:21 AM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org

              
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

              
 

              
 

              
On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

              
 

              

                
I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?

                
What is wrong with letting the client

                
-not throttle host-type requests to S1,

                
-throttle host type request to S2 with 50% and

                
-throttle realm type requests wit 25%?

              

              
 

              
Isn't this what Lionel said below?

              
<Ulrich> no it is not</Ulrich>

            

            
 

            
 

            
Ok, maybe I misread the "realm abatement is applied in any case

            
except if there is an explicit report for the destination-host"?

            
 

            
If this means the realm abatement is still applied after applying

            
the host abatement, then I agree it is not the same you said.

            
 

            
- Jouni

            
 

            
 

            

              
I am OK with Lionel's

              
"wording" here.

              
 

              
- Jouni

              
 

              

                
 

                
 

                
 

                
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com

                
Sent: Wednesday, February 05, 2014 4:14 PM

                
To: Steve Donovan; dime@ietf.org

                
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

                
 

                
Lioenl

                
 

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

                
Envoyé : mercredi 5 février 2014 15:56

                
À : dime@ietf.org

                
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

                
 

                
If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

                
 

                
I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

                
 

                
Steve

                
 

                
On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

                
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?

                
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

                
 

                
Does it make sense?

                
 

                
Lionel

                
 

                
-----Message d'origine-----

                
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 

                
Envoyé : mardi 4 février 2014 09:55

                
À : MORAND Lionel IMT/OLN

                
Cc : dime@ietf.org

                
Objet : [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
#34: Semantics of OC-Report-Type AVP

                
 

                
Text in clause 4.6  does not fully explain to which requests overload

                
treatment of a given report type applies.

                
Proposal:

                
 

                
   0  A host report.  The overload treatment should apply to requests

                
      for which all of the following conditions are true:

                
      a) The Destination-Host AVP is present in the request and its value

                
         matches the value of the Origin-Host AVP of the received message

                
         that contained the OC-OLR AVP.

                
      b) The value of the Destination-Realm AVP in the request matches the

                
         value of the Origin-Realm AVP of the received message

                
         that contained the OC-OLR AVP.

                
      c) The value of the Application-ID in the Diameter Header of the

                
         request matches the value of the Application-ID of the Diameter

                
         Header of the received message that contained the OC-OLR AVP.

                
 

                
 

                
 

                
   1  A realm report.  The overload treatment should apply to

                
      requests for which all of the following conditions are true:

                
      a) The Destination-Host AVP is absent in the request.

                
      b) The value of the Destination-Realm AVP in the request matches the

                
         value of the Origin-Realm AVP of the received message

                
         that contained the OC-OLR AVP.

                
      c) The value of the Application-ID in the Diameter Header of the

                
         request matches the value of the Application-ID of the Diameter

                
         Header of the received message that contained the OC-OLR AVP.

                
 

                
 

                
_________________________________________________________________________________________________________________________

                
 

                
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.

                
_______________________________________________

                
DiME mailing list

                
DiME@ietf.org

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

              

              
 

            

            
 

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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.

        

        
 

      

      

      

      

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


    

    

  


--------------040706080009000200020206--


From nsalot@cisco.com  Tue Feb 11 04:28:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981B21A0281 for ; Tue, 11 Feb 2014 04:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-ZDSfWb76g2 for ; Tue, 11 Feb 2014 04:28:02 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 117F31A081F for ; Tue, 11 Feb 2014 04:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51884; q=dns/txt; s=iport; t=1392121680; x=1393331280; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=l1aOxB7xq+Sg9lItUmz1TREfxRMTTM3jNXvpJLiqmt0=; b=idBMQ6Uy822GmJvgnomtiJWjN6tUQcsdU5SUJQF6J9mztgTtLFuqIqcA xU5GoCuqwCYQ5XNbA//2MDK/VNrLZ1LFk2HU4OZdtirQDi43QL2g5qY7k b1b0d9Fasf8u/xB1ixR/l42cqsASuL7L3L56XXjL+SAI44HM6/DJ16uar I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFADgW+lKtJV2a/2dsb2JhbABZgkhEOFe+ZYEQFnSCJQEBAQQBAQEXE0EEEwQCAQgRBAEBCxYBBgchBgsUCQgCBAESCIdpAxENwG0Nh2UTBIxfgTgRAR8GByAKAQIEgx6BFASJEI0ujkmFQ4MtgXE5
X-IronPort-AV: E=Sophos;i="4.95,825,1384300800";  d="scan'208,217";a="303067762"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Feb 2014 12:27:57 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1BCRvL6015975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 12:27:57 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 06:27:57 -0600
From: "Nirav Salot (nsalot)" 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIcxPiNHLS9yLA0ansvPW8F8mkpqnJdmAgAAE6ICAABUugIACvZWAgAAwCoCAAx0wAIABfVUAgAA0qYCAACcaAIAADsyAgAENAICAAA/eAP//tiwA
Date: Tue, 11 Feb 2014 12:27:57 +0000
Message-ID: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29D6@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772F07@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772F07@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.45.36]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6A9C1xmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:28:08 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6A9C1xmbrcdx10ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I share the below understanding from Maria-Cruz.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 4:22 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hello all,

I agree with Ulrich comments, since I agree on the basic approach as mentio=
ned already in this thread (inline with JJ comments as well):


- Host OLR based control applies to requests where Destination Host is know=
n

- Realm OLR based control applies to requests where Destination Host is not=
 known (only the Destination realm).

Best regards
/MCruz

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, February 10, 2014 6:52 PM
To: lionel.morand@orange.com; Jouni Korhon=
en; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

Why would the reduction for the realm be less than servers.  It is perfectl=
y valid for a realm overload report to ask for a reduction when there are n=
o servers in overload.
 I don't think so
  This could happen in the case I mentioned where the realm overload report=
 is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.
 all considerations other than server overload are (or should be) o=
ut of scope. (May be covered by agent overload control)

My logic was not quite correct, but for a different reason.  There is no re=
ason to do the host throttling if the request has already been throttled by=
 the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  This mig=
ht look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the destinatio=
n-host AVP
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    If host credits exist for the host indicated in the destination-host AV=
P:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request
 sounds quite complicated
Steve
On 2/10/14 10:59 AM, lionel.morand@orange.com wrote:
Hi Steve,

In your example, if an agent has a better knowledge than the server, the Ho=
st type OLR should not be sent unmodified in forwarded answers, or even rem=
oved as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than=
 the reduction needed for a node. S1 is not overload, S2 is 50% overload, t=
he realm (S1+S2) is overloaded 25%. So only the reduction for the Host shou=
ld apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between=
 the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : lundi 10 f=E9vrier 2014 15:39
=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich=
)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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_A9CA33BB78081F478946E4F34BF9AAA014D6A9C1xmbrcdx10ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I share the below underst=
anding from Maria-Cruz.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: Tuesday, February 11, 2014 4:22 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


Hello all,


 

I agree with Ulrich commen=
ts, since I agree on the basic approach as mentioned already in this thread=
 (inline with JJ comments as well):


 

- Host OLR based control applies to requests wher=
e Destination Host is known


- Realm OLR based control applies to requests whe=
re Destination Host is not known (only the Destination realm).

 

Best regards


/MCruz

 =







From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, February 10, 2014 6:52 PM

To: lionel.morand@orange=
.com; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP






 


Lio=
nel,



Why would the reduction for the realm be less than servers.  It is per=
fectly valid for a realm overload report to ask for a reduction when there =
are no servers in overload.


<Ulrich> I don’t think so</Ulrich>=



  This could hap=
pen in the case I mentioned where the realm overload report is triggered by=
 layer 3 congestion.



Clearly realm overload will be significantly influenced b=
y server overload, but that isn't the only consideration.=



<Ulrich> all considerations other than server overload ar=
e (or should be) out of scope. (May be covered by agent overload
 control)</Ulrich>



My logic was not quite correct, but for a different reason.  There is no reason to do the host throttling if the request has al=
ready been throttled by the realm report.

It should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    Apply host based throttling logic to that request



One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm. 
This might look something like the following:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

    If request is throttled:

      Increment host credit by one for the host indicat=
ed in the destination-host AVP

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    If host credits exist for the host indicated in the dest=
ination-host AVP:

      Decrement host credit by one

    else:

      Apply host based throttling logic to that request=


<Ulrich> sounds quite comp=
licated</Ulrich>

Steve




On 2/10/14 10:59 AM, 
lionel.morand@orange.com wrote:






Hi Steve,


 =



In your example, if an ag=
ent has a better knowledge than the server, the Host type OLR should not be=
 sent unmodified in forwarded answers, or even removed as
 irrelevant.


 <=
/p>

And in a normal case, the=
 reduction for the realm will be likely lower than the reduction needed for=
 a node. S1 is not overload, S2 is 50% overload, the realm
 (S1+S2) is overloaded 25%. So only the reduction for the Host should a=
pply, why the host-type should prevail over realm-type OLR.


 <=
/p>

By the way, in your propo=
sed logic, it is not clear if the relation between the first and the second=
 conditions is an "IF NOT".



 <=
/p>

Lionel<=
/p>

 <=
/p>





De =
: Steve Donovan [mailto:srdonovan@usdonovans.com]


Envoy=E9 : lundi 10 f=E9vrier 2014 15:39

=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN=
 - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I t=
hink we have agreement that a realm report applies to all traffic targeted =
for that realm, independent of the presence or absence of the destination-h=
ost avp.  Is that correct?



I don't agree with Lionel's proposal.  The realm overload report shoul=
d take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was writ=
ten "except" :)


 


The abatement for the Realm applies when NO explicit=
 reduction is requested for a specific node of this realm. In such a case i=
.e. when an OLR is received for a specific node inside a realm for which a =
reduction also applies, *ONLY* the reduction requested for the node applied=
.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-=
Report-Type AVP


 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN=
 - DE/Munich)" <ulrich.wieh=
e@nsn.com> wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM=



To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext =
lionel.morand@orange.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Repo=
rt-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN=
 - DE/Munich)" <ulrich.wieh=
e@nsn.com> wrote:


 




I better like Lionel's approach, but even that is no=
t ok in the unlikely extreme case where we have two servers in a realm, S1 =
is not overloaded at all, S2 is 50% overloaded, and the aggregated realm ov=
erload is 25%. Why should a client do a 25% throttling when sending host ty=
pe requests to the not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,<=
/o:p>


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?=



<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is app=
lied in any case


except if there is an explicit report for the destin=
ation-host"?


 


If this means the realm abatement is still applied a=
fter applying


the host abatement, then I agree it is not the same =
you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; =
dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Repo=
rt-Type AVP


 


I tend to agree except that I would reverse the logi=
c as for the routing principles: the Destination-host takes precedence when=
 present over Destination-Realm. So the realm abatement is applied in any c=
ase except if there is an explicit report for the destination-host.<=
o:p>


 


Lioenl


 


De : DiME [=
mailto:dime-bounces@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org=



Objet : Re: [Dime] [dime] #34: Semantics of OC-Repor=
t-Type AVP


 


It makes more sense to me for a realm report to appl=
y to all requests targeted for that realm, independent the type of request.=
  This implies that it would apply to requests that also have a Destin=
ation-Host specified.


 


If this is the definition of a realm report then we =
need to specify the interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm f=
irst and the host second.  If a message targetted for the host is thro=
ttled as a result of realm overload then that throttled message would count=
 as part of the reduction needed to address the host overload.  Messag=
es to the host that survive realm abatement would then be candidates for ho=
st overload.


 


Steve


 


On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:


The case "Realm" as described below raises=
 another question: is it prohibited for a realm to only rely on a global ov=
erload report for the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm&qu=
ot; would be received by the reacting node. And the reduction indicated in =
the OLR will apply always for the realm, whatever the presence of Destinati=
on-host AVP in the request... except if an explicit report with the type &q=
uot;Host" as been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55<=
/o:p>


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org<=
/a>


Objet : [dime] #34: Semantics of OC-Report-Type AVP<=
/span>


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to w=
hich requests overload


treatment of a given report type applies.


Proposal:


 


   0  A host report.  The overlo=
ad treatment should apply to requests


      for which all of the =
following conditions are true:


      a) The Destination-Ho=
st AVP is present in the request and its value


         mat=
ches the value of the Origin-Host AVP of the received message


         tha=
t contained the OC-OLR AVP.


      b) The value of the D=
estination-Realm AVP in the request matches the


         val=
ue of the Origin-Realm AVP of the received message


         tha=
t contained the OC-OLR AVP.


      c) The value of the A=
pplication-ID in the Diameter Header of the


         req=
uest matches the value of the Application-ID of the Diameter


         Hea=
der of the received message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overl=
oad treatment should apply to


      requests for which al=
l of the following conditions are true:


      a) The Destination-Ho=
st AVP is absent in the request.


      b) The value of the D=
estination-Realm AVP in the request matches the


         val=
ue of the Origin-Realm AVP of the received message


         tha=
t contained the OC-OLR AVP.


      c) The value of the A=
pplication-ID in the Diameter Header of the


         req=
uest matches the value of the Application-ID of the Diameter


         Hea=
der of the received message that contained the OC-OLR AVP.


 


 


____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


_______________________________________________


DiME mailing list


DiME@ietf.org


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




 




 


 


____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


 


 




 


____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.




 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D6A9C1xmbrcdx10ciscoc_--


From ulrich.wiehe@nsn.com  Tue Feb 11 04:32:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8B1A01DA for ; Tue, 11 Feb 2014 04:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E1kdcKTIXcn for ; Tue, 11 Feb 2014 04:32:43 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 18C881A0144 for ; Tue, 11 Feb 2014 04:32:42 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1BCWfTM012747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 13:32:41 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1BCWepa003758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 13:32:40 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 13:32:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 13:32:39 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen , Steve Donovan 
Thread-Topic: [Dime] [dime] #49: capabilities announcement mechanism needs to	be rethought
Thread-Index: AQHPJoINKwdZ2Wa3C0qSXjFg+cqv3ZqvALyAgAAQygCAAHpfgIAAa2iw
Date: Tue, 11 Feb 2014 12:32:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2BB2@DEMUMBX014.nsn-intra.net>
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com> <52F9605C.7000504@usdonovans.com> <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com>
In-Reply-To: <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3380
X-purgate-ID: 151667::1392121961-000025D0-3F88BC7A/0-0/0-0
Cc: "ben@nostrum.com" , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to	be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:32:46 -0000

I agree that OC-OLR AVPs are allowed only in answer messages.

But I do not agree with=20
>> if there are other DOIC AVPs in the=20
>> request, then the absence of the OC-Supported-Features is
>> interpreted as support for the default abatement algorithm.

"other DOIC AVPs" would be AVPs defined for future extensions. A reporting =
node that does not support any future extension would simply ignore "other =
DOIC AVPs" and would interprete the absence of OC-Supported-Features as "DO=
IC not supported by any downstream node".

Things are not symmetric.
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, February 11, 2014 7:45 AM
To: Steve Donovan
Cc: ben@nostrum.com; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs t=
o be rethought


Your assumption is correct. "Other DOIC AVPs" is a future thing.
Currently we have no other DOIC AVPs for requests. It is just I
asking the same semantics for the OC-Supported-Features for both
directions.

- Jouni


On Feb 11, 2014, at 1:27 AM, Steve Donovan  wrote=
:

> It has been my assumption that the OC-OLR AVP would only be allowed in an=
swer messages.  Is this the consensus?
>=20
> Steve
>=20
> On 2/10/14 4:27 PM, Jouni Korhonen wrote:
>> Basically yes.. however, if there are other DOIC AVPs in the=20
>> request, then the absence of the OC-Supported-Features is
>> interpreted as support for the default abatement algorithm.
>> We should have that behaviour in both requests and answers.
>>=20
>> - Jouni
>>=20
>> On Feb 10, 2014, at 7:03 PM, Steve Donovan=20
>> 
>>  wrote:
>>=20
>>=20
>>> My sense from recent discussions is that the lifetime of the OC-Support=
ed-Feature AVP is assumed to be one transaction.  This means that the AVP m=
ust be included in all request messages sent by a reacting node.
>>>=20
>>> Steve
>>>=20
>>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>>=20
>>>> #49: capabilities announcement mechanism needs to be rethought
>>>>=20
>>>>  The capabilities announcement mechanism needs serious rethought.
>>>>  Specifically, the lifetime of the state associated with a capabilitie=
s
>>>>  announcement is unclear. It does not make sense to tie that lifetime =
to
>>>>  Diameter session lifetimes, unless we expect to have different capabi=
lity
>>>>  sets for different sessions. (and it doesn't help at all for non-sess=
ion
>>>>  applications or pseudo-sessions.)
>>>>=20
>>>>  I think we either need to mandate that the capabilities are stateless=
,
>>>>  that is, must be included in every request, and any OLR in a response=
 must
>>>>  match the OC-Supported-Features from the corresponding request.
>>>>  Otherwise, we need a way to activate and deactivate the set associate=
d
>>>>  with a capabilities set.
>>>>=20
>>>>  (This is a side effect of allowing DOIC to cross non-supporting agent=
s. If
>>>>  we didn't allow that, we could make DOIC support and capabilites
>>>>  negotiation happen as part of the CAR exchange. )
>>>>=20
>>>>=20
>>>>=20
>>=20
>=20

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


From srdonovan@usdonovans.com  Tue Feb 11 04:33:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548031A0406 for ; Tue, 11 Feb 2014 04:33:31 -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
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 LbHLENMKM_fq for ; Tue, 11 Feb 2014 04:33:25 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 796601A01A8 for ; Tue, 11 Feb 2014 04:33:25 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60781 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDCWf-0002Jx-7A; Tue, 11 Feb 2014 04:33:24 -0800
Message-ID: <52FA1890.7020302@usdonovans.com>
Date: Tue, 11 Feb 2014 06:33:20 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "lionel.morand@orange.com" , Jouni Korhonen 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29D6@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B29D6@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------080507010502050101090005"
X-OutGoing-Spam-Status: No, score=-2.9
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
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:33:31 -0000

This is a multi-part message in MIME format.
--------------080507010502050101090005
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


On 2/11/14 3:54 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Monday, February 10, 2014 6:52 PM
> *To:* lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich (NSN -
> DE/Munich)
> *Cc:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> Lionel,
>
> Why would the reduction for the realm be less than servers.  It is
> perfectly valid for a realm overload report to ask for a reduction
> when there are no servers in overload.
>
> */ I don't think so/*
>
/* I do think so. */
>
> *//*
>
>   This could happen in the case I mentioned where the realm overload
> report is triggered by layer 3 congestion.
>
> Clearly realm overload will be significantly influenced by server
> overload, but that isn't the only consideration.
>
> */ all considerations other than server overload are (or
> should be) out of scope. (May be covered by agent overload
> control)/*
>
 I disagree. We are building tools for a service provider to
protect their network.  We aren't specifying how the status of a realm
is determined, we are giving the ability for a service provider to
protect the network in extreme conditions.  In addition, this has
nothing to do with agent overload.  Overload status of an agent would be
an input into realm overload status but the overload of an individual
agent cannot and should not be interpreted as overload of a realm.
>
>
> My logic was not quite correct, but for a different reason.  There is
> no reason to do the host throttling if the request has already been
> throttled by the realm report.
> It should be as follows:
>
> For all requests:
>   If there is a realm overload report that applies to the request:
>     Apply realm based throttling logic to that request
>   If the request has not already been throttled and there is a host
> overload report that applies to the request:
>     Apply host based throttling logic to that request
>
> One improvement would be to remember the host throttled by the realm
> abatement algorithm and input that into the server abatement
> algorithm.  This might look something like the following:
>
> For all requests:
>   If there is a realm overload report that applies to the request:
>     Apply realm based throttling logic to that request
>     If request is throttled:
>       Increment host credit by one for the host indicated in the
> destination-host AVP
>   If the request has not already been throttled and there is a host
> overload report that applies to the request:
>     If host credits exist for the host indicated in the
> destination-host AVP:
>       Decrement host credit by one
>     else:
>       Apply host based throttling logic to that request
> */ sounds quite complicated/*
>
srd> Looks pretty straight forward to me.  Even if it is complication,
so what?  We are talking about protecting a Diameter network from a
condition that can cause operators to lose a lot of money.  A little
complexity is acceptable.  This, of course, would not be normative.  The
normative definition would be that the reacting node must decrease
traffic to the realm by the requested reduction.  Applications can
define different reduction algorithms.  Implementations can take
different approaches.  This would just be the suggested approach.

> Steve
>
> On 2/10/14 10:59 AM, lionel.morand@orange.com
>  wrote:
>
>     Hi Steve,
>
>      
>
>     In your example, if an agent has a better knowledge than the
>     server, the Host type OLR should not be sent unmodified in
>     forwarded answers, or even removed as irrelevant.
>
>      
>
>     And in a normal case, the reduction for the realm will be likely
>     lower than the reduction needed for a node. S1 is not overload, S2
>     is 50% overload, the realm (S1+S2) is overloaded 25%. So only the
>     reduction for the Host should apply, why the host-type should
>     prevail over realm-type OLR.
>
>      
>
>     By the way, in your proposed logic, it is not clear if the
>     relation between the first and the second conditions is an "IF NOT".
>
>      
>
>     Lionel
>
>      
>
>     *De :*Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Envoyé :* lundi 10 février 2014 15:39
>     *À :* MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN -
>     DE/Munich)
>     *Cc :* dime@ietf.org 
>     *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     I think we have agreement that a realm report applies to all
>     traffic targeted for that realm, independent of the presence or
>     absence of the destination-host avp.  Is that correct?
>
>     I don't agree with Lionel's proposal.  The realm overload report
>     should take precedence over the host overload report.
>
>     My reasoning is as follows:
>
>     - There is something responsible for tracking the health of the
>     realm.  Call it the "realm overload authority".  The health of the
>     realm can be based on a number of factors including the health of
>     individual servers, individual agents and the network connecting
>     Diameter entities.
>
>     - When this "realm overload authority" determines that the IP
>     network is congested, for instance, it would instruct agents or
>     servers to send realm overload reports with the expectation that
>     the overall traffic sent to the realm as a whole will be reduced.
>
>     In this scenario, the fact that the realm is overloaded takes
>     precedence over the health of the servers.  As such, it is likely
>     that requests targeted for a healthy server will be throttled.
>
>     I propose the logic should be as follows:
>
>     For all requests:
>       If there is a realm overload report that applies to the request:
>         Apply realm based trottling logic to that request
>       If there is a host overload report that applies to the request:
>         Apply host based throttling logic to that request
>
>     Note that this also requires the ability to put realm overload
>     reports in any answer message, not just answers to requests that
>     did not contain a destination-host AVP.
>
>     Steve
>
>     On 2/10/14 5:30 AM, lionel.morand@orange.com
>      wrote:
>
>         No it was not my intention and it is why it was written "except" :)
>
>          
>
>         The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.
>
>          
>
>         Is it clearer?
>
>          
>
>         Lioenl 
>
>          
>
>         -----Message d'origine-----
>
>         De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Envoyé : dimanche 9 février 2014 13:46
>
>         À : Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org 
>
>         Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>          
>
>          
>
>         On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>          
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>             Sent: Friday, February 07, 2014 11:21 AM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: ext lionel.morand@orange.com ; Steve Donovan; dime@ietf.org 
>
>             Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>              
>
>              
>
>             On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>              
>
>                 I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>
>                 What is wrong with letting the client
>
>                 -not throttle host-type requests to S1,
>
>                 -throttle host type request to S2 with 50% and
>
>                 -throttle realm type requests wit 25%?
>
>              
>
>             Isn't this what Lionel said below?
>
>              no it is not
>
>          
>
>          
>
>         Ok, maybe I misread the "realm abatement is applied in any case
>
>         except if there is an explicit report for the destination-host"?
>
>          
>
>         If this means the realm abatement is still applied after applying
>
>         the host abatement, then I agree it is not the same you said.
>
>          
>
>         - Jouni
>
>          
>
>          
>
>             I am OK with Lionel's
>
>             "wording" here.
>
>              
>
>             - Jouni
>
>              
>
>                  
>
>                  
>
>                  
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com 
>
>                 Sent: Wednesday, February 05, 2014 4:14 PM
>
>                 To: Steve Donovan; dime@ietf.org 
>
>                 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.
>
>                  
>
>                 Lioenl
>
>                  
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>
>                 Envoyé : mercredi 5 février 2014 15:56
>
>                 À : dime@ietf.org 
>
>                 Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.
>
>                  
>
>                 If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.
>
>                  
>
>                 I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.
>
>                  
>
>                 Steve
>
>                  
>
>                 On 2/4/14 11:12 AM, lionel.morand@orange.com  wrote:
>
>                 The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
>
>                 If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.
>
>                  
>
>                 Does it make sense?
>
>                  
>
>                 Lionel
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
>
>                 Envoyé : mardi 4 février 2014 09:55
>
>                 À : MORAND Lionel IMT/OLN
>
>                 Cc : dime@ietf.org 
>
>                 Objet : [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                 Text in clause 4.6  does not fully explain to which requests overload
>
>                 treatment of a given report type applies.
>
>                 Proposal:
>
>                  
>
>                    0  A host report.  The overload treatment should apply to requests
>
>                       for which all of the following conditions are true:
>
>                       a) The Destination-Host AVP is present in the request and its value
>
>                          matches the value of the Origin-Host AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       b) The value of the Destination-Realm AVP in the request matches the
>
>                          value of the Origin-Realm AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       c) The value of the Application-ID in the Diameter Header of the
>
>                          request matches the value of the Application-ID of the Diameter
>
>                          Header of the received message that contained the OC-OLR AVP.
>
>                  
>
>                  
>
>                  
>
>                    1  A realm report.  The overload treatment should apply to
>
>                       requests for which all of the following conditions are true:
>
>                       a) The Destination-Host AVP is absent in the request.
>
>                       b) The value of the Destination-Realm AVP in the request matches the
>
>                          value of the Origin-Realm AVP of the received message
>
>                          that contained the OC-OLR AVP.
>
>                       c) The value of the Application-ID in the Diameter Header of the
>
>                          request matches the value of the Application-ID of the Diameter
>
>                          Header of the received message that contained the OC-OLR AVP.
>
>                  
>
>                  
>
>                 _________________________________________________________________________________________________________________________
>
>                  
>
>                 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.
>
>                 _______________________________________________
>
>                 DiME mailing list
>
>                 DiME@ietf.org 
>
>                 https://www.ietf.org/mailman/listinfo/dime
>
>              
>
>          
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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.
>
>  
>


--------------080507010502050101090005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 2/11/14 3:54 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
 

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Monday, February 10, 2014 6:52 PM

                To: lionel.morand@orange.com; Jouni Korhonen;
                Wiehe, Ulrich (NSN - DE/Munich)

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
Lionel,

          

          Why would the reduction for the realm be less than servers. 
          It is perfectly valid for a realm overload report to ask for a
          reduction when there are no servers in overload.

        
<Ulrich> I don’t think
                so</Ulrich>

      

    

    <srd> I do think so. 

    

      

        

        
  This could happen in the case I mentioned
            where the realm overload report is triggered by layer 3
            congestion.

            

          Clearly realm overload will be significantly influenced
          by server overload, but that isn't the only consideration.

        
<Ulrich> all considerations other
                than server overload are (or should be) out of scope.
                (May be covered by agent overload
                control)</Ulrich>

          

      

    

    <srd> I disagree. We are building tools for a service provider
    to protect their network.  We aren't specifying how the status of a
    realm is determined, we are giving the ability for a service
    provider to protect the network in extreme conditions.  In addition,
    this has nothing to do with agent overload.  Overload status of an
    agent would be an input into realm overload status but the overload
    of an individual agent cannot and should not be interpreted as
    overload of a realm.

    

      

        

            

            My logic was not quite correct, but for a different reason. 
          There is no reason to do the host throttling if the
          request has already been throttled by the realm report.

          It should be as follows:

          

          For all requests:

            If there is a realm overload report that applies to the
          request:

              Apply realm based throttling logic to that request

            If the request has not already been throttled and there is a
          host overload report that applies to the request:

              Apply host based throttling logic to that request

          

          One improvement would be to remember the host throttled by the
          realm abatement algorithm and input that into the server
          abatement algorithm. 
          This might look something like the
            following:

            

          For all requests:

              If there is a realm overload report that applies to the
            request:

                Apply realm based throttling logic to that request

                If request is throttled:

                  Increment host credit by one for the host indicated in
            the destination-host AVP

              If the request has not already been throttled and there is
            a host overload report that applies to the request:

                If host credits exist for the host indicated in the
            destination-host AVP:

                  Decrement host credit by one

                else:

                  Apply host based throttling logic to that request

          <Ulrich>
                sounds quite complicated</Ulrich>

          

      

    

    srd> Looks pretty straight forward to me.  Even if it is
    complication, so what?  We are talking about protecting a Diameter
    network from a condition that can cause operators to lose a lot of
    money.  A little complexity is acceptable.  This, of course, would
    not be normative.  The normative definition would be that the
    reacting node must decrease traffic to the realm by the requested
    reduction.  Applications can define different reduction algorithms. 
    Implementations can take different approaches.  This would just be
    the suggested approach.

    

    

      

        

            Steve

        

          
On 2/10/14 10:59 AM, 
              lionel.morand@orange.com wrote:

        

        

          
Hi
              Steve,

          
 

          
In your example, if an agent has a better
              knowledge than the server, the Host type OLR should not be
              sent unmodified in forwarded answers, or even removed as
              irrelevant.

          
 

          
And in a normal case, the reduction for the
              realm will be likely lower than the reduction needed for a
              node. S1 is not overload, S2 is 50% overload, the realm
              (S1+S2) is overloaded 25%. So only the reduction for the
              Host should apply, why the host-type should prevail over
              realm-type OLR.

          
 

          
By the way, in your proposed logic, it is not
              clear if the relation between the first and the second
              conditions is an "IF NOT".
            

          
 

          
Lionel

          
 

          

            

              
De :
                  Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Envoyé : lundi 10 février 2014 15:39

                  À : MORAND Lionel IMT/OLN; Jouni Korhonen;
                  Wiehe, Ulrich (NSN - DE/Munich)

                  Cc : dime@ietf.org

                  Objet : Re: [Dime] [dime] #34: Semantics of
                  OC-Report-Type AVP

            

          

          
 

          
I think we
            have agreement that a realm report applies to all traffic
            targeted for that realm, independent of the presence or
            absence of the destination-host avp.  Is that correct?

            

            I don't agree with Lionel's proposal.  The realm overload
            report should take precedence over the host overload report.

            

            My reasoning is as follows:

            

            - There is something responsible for tracking the health of
            the realm.  Call it the "realm overload authority".  The
            health of the realm can be based on a number of factors
            including the health of individual servers, individual
            agents and the network connecting Diameter entities.

            

            - When this "realm overload authority" determines that the
            IP network is congested, for instance, it would instruct
            agents or servers to send realm overload reports with the
            expectation that the overall traffic sent to the realm as a
            whole will be reduced.

            

            In this scenario, the fact that the realm is overloaded
            takes precedence over the health of the servers.  As such,
            it is likely that requests targeted for a healthy server
            will be throttled.

            

            I propose the logic should be as follows:

            

            For all requests:

              If there is a realm overload report that applies to the
            request:

                Apply realm based trottling logic to that request

              If there is a host overload report that applies to the
            request:

                Apply host based throttling logic to that request

            

            Note that this also requires the ability to put realm
            overload reports in any answer message, not just answers to
            requests that did not contain a destination-host AVP.

            

            Steve

          

            
On 2/10/14 5:30 AM, 
                lionel.morand@orange.com wrote:

          

          

            
No it was not my intention and it is why it was written "except" :)

            
 

            
The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.

            
 

            
Is it clearer?

            
 

            
Lioenl 

            
 

            
-----Message d'origine-----

            
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

            
Envoyé : dimanche 9 février 2014 13:46

            
À : Wiehe, Ulrich (NSN - DE/Munich)

            
Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

            
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

            
 

            
 

            
On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

            
 

            

              
 

              
 

              
-----Original Message-----

              
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

              
Sent: Friday, February 07, 2014 11:21 AM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org

              
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

              
 

              
 

              
On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

              
 

              

                
I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?

                
What is wrong with letting the client

                
-not throttle host-type requests to S1,

                
-throttle host type request to S2 with 50% and

                
-throttle realm type requests wit 25%?

              

              
 

              
Isn't this what Lionel said below?

              
<Ulrich> no it is not</Ulrich>

            

            
 

            
 

            
Ok, maybe I misread the "realm abatement is applied in any case

            
except if there is an explicit report for the destination-host"?

            
 

            
If this means the realm abatement is still applied after applying

            
the host abatement, then I agree it is not the same you said.

            
 

            
- Jouni

            
 

            
 

            

              
I am OK with Lionel's

              
"wording" here.

              
 

              
- Jouni

              
 

              

                
 

                
 

                
 

                
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com

                
Sent: Wednesday, February 05, 2014 4:14 PM

                
To: Steve Donovan; dime@ietf.org

                
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

                
 

                
Lioenl

                
 

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

                
Envoyé : mercredi 5 février 2014 15:56

                
À : dime@ietf.org

                
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

                
 

                
If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

                
 

                
I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

                
 

                
Steve

                
 

                
On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

                
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?

                
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

                
 

                
Does it make sense?

                
 

                
Lionel

                
 

                
-----Message d'origine-----

                
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 

                
Envoyé : mardi 4 février 2014 09:55

                
À : MORAND Lionel IMT/OLN

                
Cc : dime@ietf.org

                
Objet : [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
#34: Semantics of OC-Report-Type AVP

                
 

                
Text in clause 4.6  does not fully explain to which requests overload

                
treatment of a given report type applies.

                
Proposal:

                
 

                
   0  A host report.  The overload treatment should apply to requests

                
      for which all of the following conditions are true:

                
      a) The Destination-Host AVP is present in the request and its value

                
         matches the value of the Origin-Host AVP of the received message

                
         that contained the OC-OLR AVP.

                
      b) The value of the Destination-Realm AVP in the request matches the

                
         value of the Origin-Realm AVP of the received message

                
         that contained the OC-OLR AVP.

                
      c) The value of the Application-ID in the Diameter Header of the

                
         request matches the value of the Application-ID of the Diameter

                
         Header of the received message that contained the OC-OLR AVP.

                
 

                
 

                
 

                
   1  A realm report.  The overload treatment should apply to

                
      requests for which all of the following conditions are true:

                
      a) The Destination-Host AVP is absent in the request.

                
      b) The value of the Destination-Realm AVP in the request matches the

                
         value of the Origin-Realm AVP of the received message

                
         that contained the OC-OLR AVP.

                
      c) The value of the Application-ID in the Diameter Header of the

                
         request matches the value of the Application-ID of the Diameter

                
         Header of the received message that contained the OC-OLR AVP.

                
 

                
 

                
_________________________________________________________________________________________________________________________

                
 

                
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.

                
_______________________________________________

                
DiME mailing list

                
DiME@ietf.org

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

              

              
 

            

            
 

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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.

        

        
 

      

    

    

  


--------------080507010502050101090005--


From nsalot@cisco.com  Tue Feb 11 04:33:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A5A1A06E5 for ; Tue, 11 Feb 2014 04:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orVUfR6UciG8 for ; Tue, 11 Feb 2014 04:33:26 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D456B1A01DA for ; Tue, 11 Feb 2014 04:33:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47970; q=dns/txt; s=iport; t=1392122006; x=1393331606; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6A2TSib3SsJNWDriw0c3vmMgnlXpjRj4VQ2BMhXKuUA=; b=T2xup+K5AMNtCWr06qDUfoP0DgMnW+WyfE/hV5HA5CNf0aF2twzxDAUq DggY/LqTKj/qqR7FPlcxx9ktr5g3XyVFDiZAx80TEqEYsLMHbFUrlRLPQ m+VrSggiqLnQJyok3M3Rk/IqMTpRFvoAZOgETfQdU1pVPN/fPJ5PNAyXB k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAE8Y+lKtJV2Z/2dsb2JhbABZgkhEOFe+ZYEQFnSCJQEBAQQBAQEXE0EEBwwEAgEIDgMEAQELFgEGByEGCxQJCAIEAQ0FCIdpAxENwG0Nh2UTBIxfgTgRAR8GByAEBgECBIMegRQEiRCNLo5JhUODLYFxOQ
X-IronPort-AV: E=Sophos;i="4.95,825,1384300800";  d="scan'208,217";a="303284047"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 11 Feb 2014 12:33:23 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1BCXNG8010015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 12:33:23 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 06:33:22 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , "lionel.morand@orange.com" , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIcxPiNHLS9yLA0ansvPW8F8mkpqnJdmAgAAE6ICAABUugIACvZWAgAAwCoCAAx0wAIABfVUAgAA0qYCAACcaAIAADsyAgACoxCCAAIyvgP//nhnA
Date: Tue, 11 Feb 2014 12:33:22 +0000
Message-ID: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com>  <52FA1561.8040807@usdonovans.com>
In-Reply-To: <52FA1561.8040807@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.45.36]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6A9F0xmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:33:34 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6A9F0xmbrcdx10ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

I still don't understand how this work.
If a host (within the realm) is more overloaded than the realm itself, is i=
t justified to throttle the traffic towards this host with realm-report?
If yes, can it guarantee the overload mitigation of the server?
If yes, what is the use of host report when realm report is provided. Can w=
e simply say that the reacting node simply forgets the host report when rea=
lm report is available?

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, February 11, 2014 5:50 PM
To: Nirav Salot (nsalot); lionel.morand@orange.com; Jouni Korhonen; Wiehe, =
Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

The definition of a realm overload report is to decrease the total number o=
f requests sent to the realm.  The algorithm suggests one way of achieving =
the reduction of traffic.  Other approaches could clearly be taken, as long=
 as the total amount of traffic to the realm is reduced.

Steve

On 2/11/14 3:57 AM, Nirav Salot (nsalot) wrote:
Steve,

I don't understand one aspect.
Why should the request be throttled with realm report when the request is t=
argeted to a particular host within the realm.
Can this request be routed to another host in that realm? If not, the reque=
st should be subjected to the throttling based on the host report.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Monday, February 10, 2014 11:22 PM
To: lionel.morand@orange.com; Jouni Korhon=
en; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Lionel,

Why would the reduction for the realm be less than servers.  It is perfectl=
y valid for a realm overload report to ask for a reduction when there are n=
o servers in overload.  This could happen in the case I mentioned where the=
 realm overload report is triggered by layer 3 congestion.

Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.

My logic was not quite correct, but for a different reason.  There is no re=
ason to do the host throttling if the request has already been throttled by=
 the realm report.
It should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    Apply host based throttling logic to that request

One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  This mig=
ht look something like the following:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based throttling logic to that request
    If request is throttled:
      Increment host credit by one for the host indicated in the destinatio=
n-host AVP
  If the request has not already been throttled and there is a host overloa=
d report that applies to the request:
    If host credits exist for the host indicated in the destination-host AV=
P:
      Decrement host credit by one
    else:
      Apply host based throttling logic to that request

Steve
On 2/10/14 10:59 AM, lionel.morand@orange.com wrote:
Hi Steve,

In your example, if an agent has a better knowledge than the server, the Ho=
st type OLR should not be sent unmodified in forwarded answers, or even rem=
oved as irrelevant.

And in a normal case, the reduction for the realm will be likely lower than=
 the reduction needed for a node. S1 is not overload, S2 is 50% overload, t=
he realm (S1+S2) is overloaded 25%. So only the reduction for the Host shou=
ld apply, why the host-type should prevail over realm-type OLR.

By the way, in your proposed logic, it is not clear if the relation between=
 the first and the second conditions is an "IF NOT".

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : lundi 10 f=E9vrier 2014 15:39
=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich=
)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I think we have agreement that a realm report applies to all traffic target=
ed for that realm, independent of the presence or absence of the destinatio=
n-host avp.  Is that correct?

I don't agree with Lionel's proposal.  The realm overload report should tak=
e precedence over the host overload report.

My reasoning is as follows:

- There is something responsible for tracking the health of the realm.  Cal=
l it the "realm overload authority".  The health of the realm can be based =
on a number of factors including the health of individual servers, individu=
al agents and the network connecting Diameter entities.

- When this "realm overload authority" determines that the IP network is co=
ngested, for instance, it would instruct agents or servers to send realm ov=
erload reports with the expectation that the overall traffic sent to the re=
alm as a whole will be reduced.

In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests targeted=
 for a healthy server will be throttled.

I propose the logic should be as follows:

For all requests:
  If there is a realm overload report that applies to the request:
    Apply realm based trottling logic to that request
  If there is a host overload report that applies to the request:
    Apply host based throttling logic to that request

Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.

Steve
On 2/10/14 5:30 AM, lionel.morand@orange.com wrote:

No it was not my intention and it is why it was written "except" :)



The abatement for the Realm applies when NO explicit reduction is requested=
 for a specific node of this realm. In such a case i.e. when an OLR is rece=
ived for a specific node inside a realm for which a reduction also applies,=
 *ONLY* the reduction requested for the node applied.



Is it clearer?



Lioenl



-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, February 07, 2014 11:21 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: ext lionel.morand@orange.com; Steve Do=
novan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



I better like Lionel's approach, but even that is not ok in the unlikely ex=
treme case where we have two servers in a realm, S1 is not overloaded at al=
l, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why shou=
ld a client do a 25% throttling when sending host type requests to the not =
at all overloaded S1?

What is wrong with letting the client

-not throttle host-type requests to S1,

-throttle host type request to S2 with 50% and

-throttle realm type requests wit 25%?



Isn't this what Lionel said below?

 no it is not





Ok, maybe I misread the "realm abatement is applied in any case

except if there is an explicit report for the destination-host"?



If this means the realm abatement is still applied after applying

the host abatement, then I agree it is not the same you said.



- Jouni





I am OK with Lionel's

"wording" here.



- Jouni









From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or=
ange.com

Sent: Wednesday, February 05, 2014 4:14 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



I tend to agree except that I would reverse the logic as for the routing pr=
inciples: the Destination-host takes precedence when present over Destinati=
on-Realm. So the realm abatement is applied in any case except if there is =
an explicit report for the destination-host.



Lioenl



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



It makes more sense to me for a realm report to apply to all requests targe=
ted for that realm, independent the type of request.  This implies that it =
would apply to requests that also have a Destination-Host specified.



If this is the definition of a realm report then we need to specify the int=
eraction between realm reports and host reports.



I propose that throttling would occur on the realm first and the host secon=
d.  If a message targetted for the host is throttled as a result of realm o=
verload then that throttled message would count as part of the reduction ne=
eded to address the host overload.  Messages to the host that survive realm=
 abatement would then be candidates for host overload.



Steve



On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

The case "Realm" as described below raises another question: is it prohibit=
ed for a realm to only rely on a global overload report for the whole realm=
, whatever the nodes inside this realm?

If not, only OLR with the report type "realm" would be received by the reac=
ting node. And the reduction indicated in the OLR will apply always for the=
 realm, whatever the presence of Destination-host AVP in the request... exc=
ept if an explicit report with the type "Host" as been received for this de=
stination-host.



Does it make sense?



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:55

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP



#34: Semantics of OC-Report-Type AVP



Text in clause 4.6  does not fully explain to which requests overload

treatment of a given report type applies.

Proposal:



   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.







   1  A realm report.  The overload treatment should apply to

      requests for which all of the following conditions are true:

      a) The Destination-Host AVP is absent in the request.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.





___________________________________________________________________________=
______________________________________________



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.

_______________________________________________

DiME mailing list

DiME@ietf.org

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







___________________________________________________________________________=
______________________________________________



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_A9CA33BB78081F478946E4F34BF9AAA014D6A9F0xmbrcdx10ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

I still don’t under=
stand how this work.


If a host (within the rea=
lm) is more overloaded than the realm itself, is it justified to throttle t=
he traffic towards this host with realm-report?



If yes, can it guarantee =
the overload mitigation of the server?


If yes, what is the use o=
f host report when realm report is provided. Can we simply say that the rea=
cting node simply forgets the host report when realm report
 is available?


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, February 11, 2014 5:50 PM

To: Nirav Salot (nsalot); lionel.morand@orange.com; Jouni Korhonen; =
Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


The definition of a r=
ealm overload report is to decrease the total number of requests sent to th=
e realm.  The algorithm suggests one way of achieving the reduction of=
 traffic.  Other approaches could clearly
 be taken, as long as the total amount of traffic to the realm is reduced.<=
br>


Steve








On 2/11/14 3:57 AM, Nirav Salot (nsalot) wrote:=







Steve,



 <=
/p>

I don’t understand =
one aspect.


Why should the request be=
 throttled with realm report when the request is targeted to a particular h=
ost within the realm.


Can this request be route=
d to another host in that realm? If not, the request should be subjected to=
 the throttling based on the host report.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Monday, February 10, 2014 11:22 PM

To: lionel.morand@orange=
.com; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP






 


Lionel,



Why would the reduction for the realm be less than servers.  It is per=
fectly valid for a realm overload report to ask for a reduction when there =
are no servers in overload.  This could happen in the case I mentioned=
 where the realm overload report is triggered
 by layer 3 congestion.



Clearly realm overload will be significantly influenced by server overload,=
 but that isn't the only consideration.



My logic was not quite correct, but for a different reason.  There is =
no reason to do the host throttling if the request has already been throttl=
ed by the realm report.

It should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    Apply host based throttling logic to that request



One improvement would be to remember the host throttled by the realm abatem=
ent algorithm and input that into the server abatement algorithm.  Thi=
s might look something like the following:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based throttling logic to that request

    If request is throttled:

      Increment host credit by one for the host indicat=
ed in the destination-host AVP

  If the request has not already been throttled and there is a host ov=
erload report that applies to the request:

    If host credits exist for the host indicated in the dest=
ination-host AVP:

      Decrement host credit by one

    else:

      Apply host based throttling logic to that request=




Steve




On 2/10/14 10:59 AM, 
lionel.morand@orange.com wrote:






Hi Steve,


 <=
/p>

In your example, if an ag=
ent has a better knowledge than the server, the Host type OLR should not be=
 sent unmodified in forwarded answers, or even removed as
 irrelevant.


 <=
/p>

And in a normal case, the=
 reduction for the realm will be likely lower than the reduction needed for=
 a node. S1 is not overload, S2 is 50% overload, the realm
 (S1+S2) is overloaded 25%. So only the reduction for the Host should a=
pply, why the host-type should prevail over realm-type OLR.


 <=
/p>

By the way, in your propo=
sed logic, it is not clear if the relation between the first and the second=
 conditions is an "IF NOT".



 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Envoy=E9 : lundi 10 f=E9vrier 2014 15:39

=C0 : MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich (NSN=
 - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I think we have agree=
ment that a realm report applies to all traffic targeted for that realm, in=
dependent of the presence or absence of the destination-host avp.  Is =
that correct?



I don't agree with Lionel's proposal.  The realm overload report shoul=
d take precedence over the host overload report.



My reasoning is as follows:



- There is something responsible for tracking the health of the realm. =
; Call it the "realm overload authority".  The health of the=
 realm can be based on a number of factors including the health of individu=
al servers, individual agents and the network connecting
 Diameter entities.



- When this "realm overload authority" determines that the IP net=
work is congested, for instance, it would instruct agents or servers to sen=
d realm overload reports with the expectation that the overall traffic sent=
 to the realm as a whole will be reduced.



In this scenario, the fact that the realm is overloaded takes precedence ov=
er the health of the servers.  As such, it is likely that requests tar=
geted for a healthy server will be throttled.



I propose the logic should be as follows:



For all requests:

  If there is a realm overload report that applies to the request:

    Apply realm based trottling logic to that request

  If there is a host overload report that applies to the request:

    Apply host based throttling logic to that request



Note that this also requires the ability to put realm overload reports in a=
ny answer message, not just answers to requests that did not contain a dest=
ination-host AVP.



Steve




On 2/10/14 5:30 AM, 
lionel.morand@orange.com wrote:






No it was not my intention and it is why it was written "except&q=
uot; :)


 


The abatement for the Realm applies when NO explicit reduction is requ=
ested for a specific node of this realm. In such a case i.e. when an OLR is=
 received for a specific node inside a realm for which a reduction also app=
lies, *ONLY* the reduction requested for the node applied.


 


Is it clearer?


 


Lioenl 


 


-----Message d'origine-----


De : Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Envoy=E9 : dimanche 9 f=E9vrier 2014 13:46


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, February 07, 2014 11:21 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: ext lionel.morand@oran=
ge.com; Steve Donovan; dime@ietf.org


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




I better like Lionel's approach, but even that is not ok in the unlike=
ly extreme case where we have two servers in a realm, S1 is not overloaded =
at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why=
 should a client do a 25% throttling when sending host type requests to the=
 not at all overloaded S1?


What is wrong with letting the client


-not throttle host-type requests to S1,


-throttle host type request to S2 with 50% and


-throttle realm type requests wit 25%?




 


Isn't this what Lionel said below?


<Ulrich> no it is not</Ulrich>




 


 


Ok, maybe I misread the "realm abatement is applied in any case


except if there is an explicit report for the destination-host"?<=
o:p>


 


If this means the realm abatement is still applied after applying=



the host abatement, then I agree it is not the same you said.


 


- Jouni


 


 




I am OK with Lionel's


"wording" here.


 


- Jouni


 




 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext lionel.morand@orange.com


Sent: Wednesday, February 05, 2014 4:14 PM


To: Steve Donovan; dime@ietf.org<=
o:p>


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


I tend to agree except that I would reverse the logic as for the routi=
ng principles: the Destination-host takes precedence when present over Dest=
ination-Realm. So the realm abatement is applied in any case except if ther=
e is an explicit report for the destination-host.


 


Lioenl


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


It makes more sense to me for a realm report to apply to all requests =
targeted for that realm, independent the type of request.  This implie=
s that it would apply to requests that also have a Destination-Host specifi=
ed.


 


If this is the definition of a realm report then we need to specify th=
e interaction between realm reports and host reports.


 


I propose that throttling would occur on the realm first and the host =
second.  If a message targetted for the host is throttled as a result =
of realm overload then that throttled message would count as part of the re=
duction needed to address the host overload.  Messages to the host tha=
t survive realm abatement would then be candidates for host overload.<=
/o:p>


 


Steve


 


On 2/4/14 11:12 AM, lionel=
.morand@orange.com wrote:


The case "Realm" as described below raises another question:=
 is it prohibited for a realm to only rely on a global overload report for =
the whole realm, whatever the nodes inside this realm?


If not, only OLR with the report type "realm" would be recei=
ved by the reacting node. And the reduction indicated in the OLR will apply=
 always for the realm, whatever the presence of Destination-host AVP in the=
 request... except if an explicit report with the type "Host" as =
been received for this destination-host.


 


Does it make sense?


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 


Envoy=E9 : mardi 4 f=E9vrier 2014 09:55


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #34: Semantics of OC-Report-Type AVP


 


#34: Semantics of OC-Report-Type AVP


 


Text in clause 4.6  does not fully explain to which requests over=
load


treatment of a given report type applies.


Proposal:


 


   0  A host report.  The overload treatment shoul=
d apply to requests


      for which all of the following conditio=
ns are true:


      a) The Destination-Host AVP is present =
in the request and its value


         matches the value of =
the Origin-Host AVP of the received message


         that contained the OC=
-OLR AVP.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


 


   1  A realm report.  The overload treatment shou=
ld apply to


      requests for which all of the following=
 conditions are true:


      a) The Destination-Host AVP is absent i=
n the request.


      b) The value of the Destination-Realm A=
VP in the request matches the


         value of the Origin-R=
ealm AVP of the received message


         that contained the OC=
-OLR AVP.


      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


 


 


______________________________________________________________________=
___________________________________________________


 


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.


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


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 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.




 




 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D6A9F0xmbrcdx10ciscoc_--


From srdonovan@usdonovans.com  Tue Feb 11 04:41:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C848B1A05E7 for ; Tue, 11 Feb 2014 04:41:03 -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
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 k41cN0ek0sE9 for ; Tue, 11 Feb 2014 04:41:01 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6561A04DC for ; Tue, 11 Feb 2014 04:41:01 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60855 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDCe3-0006Rc-FR for dime@ietf.org; Tue, 11 Feb 2014 04:41:00 -0800
Message-ID: <52FA1A5B.2080104@usdonovans.com>
Date: Tue, 11 Feb 2014 06:40:59 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> <52F8E5A7.6030902@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29A1@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772EE2@ESESSMB101.ericsson.se> <14115_1392115821_52FA006D_14115_2918_1_6B7134B31289DC4FAF731D844122B36E499C02@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <14115_1392115821_52FA006D_14115_2918_1_6B7134B31289DC4FAF731D844122B36E499C02@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------060703090202030409030709"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:41:04 -0000

This is a multi-part message in MIME format.
--------------060703090202030409030709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Agreed, there is nothing contentious here.  I agree that the report
applies only to the application ID included in the message carrying the
overload report. 

Ulrich's wording isn't clear on which messages are being referenced.  Or
I wasn't looking at full context.  It might be better to try to change
the proposed wording from:
How about changing Ulrich's proposal from:

      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.

to the following:

"The value of the application-ID in the Diameter Header of new request
messages matches the value of the Application-ID is an active overload
report."

Steve

On 2/11/14 4:50 AM, lionel.morand@orange.com wrote:
> I think that there is no contentious issue here :)
> I think that Ulrich is right saying that the reacting node needs to take into account the application-id to perform the abatement. Not when receiving the OLR... but when sending a new request.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
> Envoyé : mardi 11 février 2014 11:43
> À : dime@ietf.org
> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Exact, I agree.
> Cheers
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
> Sent: martes, 11 de febrero de 2014 10:37
> To: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Steve,
>
> I do not agree.
>
> e.g. 
> 1. reacting node sends Request with application ID = x to reporting node 2. reporting node sends back answer (containing an OLR) with application ID = x 3. reacting node now may very well send  a new request with application ID = y to the reporting node without breaking any Diameter rules. 
> The new request sent in step 3 is NOT subject to throttling according to the OLR received in step 2.
> I hope this is not contentious.
> In order to provide a complete list of conditions to say when an OLR of a given type applies to a new request, we should not let c) go by the board.
>
> Ulrich
>
>
>  
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Monday, February 10, 2014 3:44 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
>>>       c) The value of the Application-ID in the Diameter Header of the
>>>          request matches the value of the Application-ID of the Diameter
>>>          Header of the received message that contained the OC-OLR AVP.
>> No need for this since we agreed that DOIC implicitly always refers to 
>> the application on which the DOIC AVPs are carried in.
>> yes, we agreed on that, so c) is correct and it does not harm 
>> to keep c)
> SRD> I don't see the reason for including this statement.  By
> definition, an overload report
> applies to the application ID in the answer message.  There is no way for the application-id in the answer message to be different than the application-id in the request message without breaking Diameter.
>
> _______________________________________________
> 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
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------060703090202030409030709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Agreed, there is nothing
      contentious here.  I agree that the report applies only to the
      application ID included in the message carrying the overload
      report.  

      

      Ulrich's wording isn't clear on which messages are being
      referenced.  Or I wasn't looking at full context.  It might be
      better to try to change the proposed wording from:

      How about changing Ulrich's proposal from:

    

    
      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.

    to the following:

      

      "The value of the application-ID in the Diameter Header of new
      request messages matches the value of the Application-ID is an
      active overload report."

      

      Steve

      

    
    
On 2/11/14 4:50 AM,
      lionel.morand@orange.com wrote:

    

    

      
I think that there is no contentious issue here :)
I think that Ulrich is right saying that the reacting node needs to take into account the application-id to perform the abatement. Not when receiving the OLR... but when sending a new request.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : mardi 11 février 2014 11:43
À : dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Exact, I agree.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 11 de febrero de 2014 10:37
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Steve,

I do not agree.

e.g. 
1. reacting node sends Request with application ID = x to reporting node 2. reporting node sends back answer (containing an OLR) with application ID = x 3. reacting node now may very well send  a new request with application ID = y to the reporting node without breaking any Diameter rules. 
The new request sent in step 3 is NOT subject to throttling according to the OLR received in step 2.
I hope this is not contentious.
In order to provide a complete list of conditions to say when an OLR of a given type applies to a new request, we should not let c) go by the board.

Ulrich


 


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 10, 2014 3:44 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP




      

        

          
      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.


        

        
No need for this since we agreed that DOIC implicitly always refers to 
the application on which the DOIC AVPs are carried in.
<Ulrich>yes, we agreed on that, so c) is correct and it does not harm 
to keep c)</Ulrich>


      

      
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way for the application-id in the answer message to be different than the application-id in the request message without breaking Diameter.

_______________________________________________
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

_________________________________________________________________________________________________________________________

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.

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



    

    

  


--------------060703090202030409030709--


From srdonovan@usdonovans.com  Tue Feb 11 04:53:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291991A0144 for ; Tue, 11 Feb 2014 04:53:33 -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
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 Em5UI-NfHc59 for ; Tue, 11 Feb 2014 04:53:25 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 421781A0086 for ; Tue, 11 Feb 2014 04:53:25 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60938 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDCpz-0000Vo-Lf; Tue, 11 Feb 2014 04:53:23 -0800
Message-ID: <52FA1D3F.3070600@usdonovans.com>
Date: Tue, 11 Feb 2014 06:53:19 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Nirav Salot (nsalot)" ,  "lionel.morand@orange.com" , Jouni Korhonen ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net>  <11942_1392031849_52F8B869_11942_4754_1_6B7134B31289DC4FAF731D844122B36E497162@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8E495.8010404@usdonovans.com> <10970_1392051556_52F90564_10970_1652_1_6B7134B31289DC4FAF731D844122B36E497C2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F911CB.3070207@usdonovans.com>  <52FA1561.8040807@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090702020703050204030104"
X-OutGoing-Spam-Status: No, score=-2.9
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
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 12:53:33 -0000

This is a multi-part message in MIME format.
--------------090702020703050204030104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Nirav,

I'm saying that the two are independent conditions, treated separately.

A reacting node receiving both a realm report and a host report must do
two things -- reduce the traffic to the realm by the percentage
requested in the realm report and reduce the traffic sent to the host by
the amount requested in the host report.

The algorithm I suggested achieved this, but is only a suggestion. 
Implementations can do it any way they want, as long as the above two
requirements are met.

More inline.

Steve

On 2/11/14 6:33 AM, Nirav Salot (nsalot) wrote:
>
> Steve,
>
>  
>
> I still don't understand how this work.
>
> If a host (within the realm) is more overloaded than the realm itself,
> is it justified to throttle the traffic towards this host with
> realm-report?
>
SRD> Yes, messages that are throttled because of a throttling to the
host can, and probably should be counted in the separate count of
messages throttled for the realm.
>
> If yes, can it guarantee the overload mitigation of the server?
>
SRD> The reacting node is responsible for reducing the traffic sent to
the server by the requested amount.  So, if the reacting node is doing
its job then yes.
>
> If yes, what is the use of host report when realm report is provided.
> Can we simply say that the reacting node simply forgets the host
> report when realm report is available?
>
SRD> A hosts overload condition is separate from a realms overload
condition.  The host report will clearly be an input to the realms
overload state, but they are separate and should be treated as separate
events.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Tuesday, February 11, 2014 5:50 PM
> *To:* Nirav Salot (nsalot); lionel.morand@orange.com; Jouni Korhonen;
> Wiehe, Ulrich (NSN - DE/Munich)
> *Cc:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> The definition of a realm overload report is to decrease the total
> number of requests sent to the realm.  The algorithm suggests one way
> of achieving the reduction of traffic.  Other approaches could clearly
> be taken, as long as the total amount of traffic to the realm is reduced.
>
> Steve
>
> On 2/11/14 3:57 AM, Nirav Salot (nsalot) wrote:
>
>     Steve,
>
>      
>
>     I don't understand one aspect.
>
>     Why should the request be throttled with realm report when the
>     request is targeted to a particular host within the realm.
>
>     Can this request be routed to another host in that realm? If not,
>     the request should be subjected to the throttling based on the
>     host report.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve
>     Donovan
>     *Sent:* Monday, February 10, 2014 11:22 PM
>     *To:* lionel.morand@orange.com ;
>     Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
>     *Cc:* dime@ietf.org 
>     *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     Lionel,
>
>     Why would the reduction for the realm be less than servers.  It is
>     perfectly valid for a realm overload report to ask for a reduction
>     when there are no servers in overload.  This could happen in the
>     case I mentioned where the realm overload report is triggered by
>     layer 3 congestion.
>
>     Clearly realm overload will be significantly influenced by server
>     overload, but that isn't the only consideration.
>
>     My logic was not quite correct, but for a different reason.  There
>     is no reason to do the host throttling if the request has already
>     been throttled by the realm report.
>     It should be as follows:
>
>     For all requests:
>       If there is a realm overload report that applies to the request:
>         Apply realm based throttling logic to that request
>       If the request has not already been throttled and there is a
>     host overload report that applies to the request:
>         Apply host based throttling logic to that request
>
>     One improvement would be to remember the host throttled by the
>     realm abatement algorithm and input that into the server abatement
>     algorithm.  This might look something like the following:
>
>     For all requests:
>       If there is a realm overload report that applies to the request:
>         Apply realm based throttling logic to that request
>         If request is throttled:
>           Increment host credit by one for the host indicated in the
>     destination-host AVP
>       If the request has not already been throttled and there is a
>     host overload report that applies to the request:
>         If host credits exist for the host indicated in the
>     destination-host AVP:
>           Decrement host credit by one
>         else:
>           Apply host based throttling logic to that request
>
>     Steve
>
>     On 2/10/14 10:59 AM, lionel.morand@orange.com
>      wrote:
>
>         Hi Steve,
>
>          
>
>         In your example, if an agent has a better knowledge than the
>         server, the Host type OLR should not be sent unmodified in
>         forwarded answers, or even removed as irrelevant.
>
>          
>
>         And in a normal case, the reduction for the realm will be
>         likely lower than the reduction needed for a node. S1 is not
>         overload, S2 is 50% overload, the realm (S1+S2) is overloaded
>         25%. So only the reduction for the Host should apply, why the
>         host-type should prevail over realm-type OLR.
>
>          
>
>         By the way, in your proposed logic, it is not clear if the
>         relation between the first and the second conditions is an "IF
>         NOT".
>
>          
>
>         Lionel
>
>          
>
>         *De :*Steve Donovan [mailto:srdonovan@usdonovans.com]
>         *Envoyé :* lundi 10 février 2014 15:39
>         *À :* MORAND Lionel IMT/OLN; Jouni Korhonen; Wiehe, Ulrich
>         (NSN - DE/Munich)
>         *Cc :* dime@ietf.org 
>         *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>          
>
>         I think we have agreement that a realm report applies to all
>         traffic targeted for that realm, independent of the presence
>         or absence of the destination-host avp.  Is that correct?
>
>         I don't agree with Lionel's proposal.  The realm overload
>         report should take precedence over the host overload report.
>
>         My reasoning is as follows:
>
>         - There is something responsible for tracking the health of
>         the realm.  Call it the "realm overload authority".  The
>         health of the realm can be based on a number of factors
>         including the health of individual servers, individual agents
>         and the network connecting Diameter entities.
>
>         - When this "realm overload authority" determines that the IP
>         network is congested, for instance, it would instruct agents
>         or servers to send realm overload reports with the expectation
>         that the overall traffic sent to the realm as a whole will be
>         reduced.
>
>         In this scenario, the fact that the realm is overloaded takes
>         precedence over the health of the servers.  As such, it is
>         likely that requests targeted for a healthy server will be
>         throttled.
>
>         I propose the logic should be as follows:
>
>         For all requests:
>           If there is a realm overload report that applies to the request:
>             Apply realm based trottling logic to that request
>           If there is a host overload report that applies to the request:
>             Apply host based throttling logic to that request
>
>         Note that this also requires the ability to put realm overload
>         reports in any answer message, not just answers to requests
>         that did not contain a destination-host AVP.
>
>         Steve
>
>         On 2/10/14 5:30 AM, lionel.morand@orange.com
>          wrote:
>
>             No it was not my intention and it is why it was written "except" :)
>
>              
>
>             The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.
>
>              
>
>             Is it clearer?
>
>              
>
>             Lioenl 
>
>              
>
>             -----Message d'origine-----
>
>             De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>             Envoyé : dimanche 9 février 2014 13:46
>
>             À : Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org 
>
>             Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>              
>
>              
>
>             On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>              
>
>                  
>
>                  
>
>                 -----Original Message-----
>
>                 From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                 Sent: Friday, February 07, 2014 11:21 AM
>
>                 To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                 Cc: ext lionel.morand@orange.com ; Steve Donovan; dime@ietf.org 
>
>                 Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                  
>
>                  
>
>                 On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                  
>
>                     I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>
>                     What is wrong with letting the client
>
>                     -not throttle host-type requests to S1,
>
>                     -throttle host type request to S2 with 50% and
>
>                     -throttle realm type requests wit 25%?
>
>                  
>
>                 Isn't this what Lionel said below?
>
>                  no it is not
>
>              
>
>              
>
>             Ok, maybe I misread the "realm abatement is applied in any case
>
>             except if there is an explicit report for the destination-host"?
>
>              
>
>             If this means the realm abatement is still applied after applying
>
>             the host abatement, then I agree it is not the same you said.
>
>              
>
>             - Jouni
>
>              
>
>              
>
>                 I am OK with Lionel's
>
>                 "wording" here.
>
>                  
>
>                 - Jouni
>
>                  
>
>                      
>
>                      
>
>                      
>
>                     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com 
>
>                     Sent: Wednesday, February 05, 2014 4:14 PM
>
>                     To: Steve Donovan; dime@ietf.org 
>
>                     Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                      
>
>                     I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.
>
>                      
>
>                     Lioenl
>
>                      
>
>                     De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>
>                     Envoyé : mercredi 5 février 2014 15:56
>
>                     À : dime@ietf.org 
>
>                     Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>                      
>
>                     It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.
>
>                      
>
>                     If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.
>
>                      
>
>                     I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.
>
>                      
>
>                     Steve
>
>                      
>
>                     On 2/4/14 11:12 AM, lionel.morand@orange.com  wrote:
>
>                     The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
>
>                     If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.
>
>                      
>
>                     Does it make sense?
>
>                      
>
>                     Lionel
>
>                      
>
>                     -----Message d'origine-----
>
>                     De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
>
>                     Envoyé : mardi 4 février 2014 09:55
>
>                     À : MORAND Lionel IMT/OLN
>
>                     Cc : dime@ietf.org 
>
>                     Objet : [dime] #34: Semantics of OC-Report-Type AVP
>
>                      
>
>                     #34: Semantics of OC-Report-Type AVP
>
>                      
>
>                     Text in clause 4.6  does not fully explain to which requests overload
>
>                     treatment of a given report type applies.
>
>                     Proposal:
>
>                      
>
>                        0  A host report.  The overload treatment should apply to requests
>
>                           for which all of the following conditions are true:
>
>                           a) The Destination-Host AVP is present in the request and its value
>
>                              matches the value of the Origin-Host AVP of the received message
>
>                              that contained the OC-OLR AVP.
>
>                           b) The value of the Destination-Realm AVP in the request matches the
>
>                              value of the Origin-Realm AVP of the received message
>
>                              that contained the OC-OLR AVP.
>
>                           c) The value of the Application-ID in the Diameter Header of the
>
>                              request matches the value of the Application-ID of the Diameter
>
>                              Header of the received message that contained the OC-OLR AVP.
>
>                      
>
>                      
>
>                      
>
>                        1  A realm report.  The overload treatment should apply to
>
>                           requests for which all of the following conditions are true:
>
>                           a) The Destination-Host AVP is absent in the request.
>
>                           b) The value of the Destination-Realm AVP in the request matches the
>
>                              value of the Origin-Realm AVP of the received message
>
>                              that contained the OC-OLR AVP.
>
>                           c) The value of the Application-ID in the Diameter Header of the
>
>                              request matches the value of the Application-ID of the Diameter
>
>                              Header of the received message that contained the OC-OLR AVP.
>
>                      
>
>                      
>
>                     _________________________________________________________________________________________________________________________
>
>                      
>
>                     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.
>
>                     _______________________________________________
>
>                     DiME mailing list
>
>                     DiME@ietf.org 
>
>                     https://www.ietf.org/mailman/listinfo/dime
>
>                  
>
>              
>
>              
>
>             _________________________________________________________________________________________________________________________
>
>              
>
>             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.
>
>      
>
>  
>


--------------090702020703050204030104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Nirav,

      

      I'm saying that the two are independent conditions, treated
      separately.

      

      A reacting node receiving both a realm report and a host report
      must do two things -- reduce the traffic to the realm by the
      percentage requested in the realm report and reduce the traffic
      sent to the host by the amount requested in the host report.

      

      The algorithm I suggested achieved this, but is only a
      suggestion.  Implementations can do it any way they want, as long
      as the above two requirements are met.

      

      More inline.

      

      Steve

      

    
    
On 2/11/14 6:33 AM, Nirav Salot
      (nsalot) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
I
            still don’t understand how this work.

        
If
            a host (within the realm) is more overloaded than the realm
            itself, is it justified to throttle the traffic towards this
            host with realm-report?
          

      

    

    SRD> Yes, messages that are throttled because of a throttling to
    the host can, and probably should be counted in the separate count
    of messages throttled for the realm.

    

      

        

        
If
            yes, can it guarantee the overload mitigation of the server?

      

    

    SRD> The reacting node is responsible for reducing the traffic
    sent to the server by the requested amount.  So, if the reacting
    node is doing its job then yes.

    

      

        

        
If
            yes, what is the use of host report when realm report is
            provided. Can we simply say that the reacting node simply
            forgets the host report when realm report is available?

      

    

    SRD> A hosts overload condition is separate from a realms
    overload condition.  The host report will clearly be an input to the
    realms overload state, but they are separate and should be treated
    as separate events.

    

      

        

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: Tuesday, February 11, 2014 5:50 PM

                To: Nirav Salot (nsalot);
                lionel.morand@orange.com; Jouni Korhonen; Wiehe, Ulrich
                (NSN - DE/Munich)

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
The definition
          of a realm overload report is to decrease the total number of
          requests sent to the realm.  The algorithm suggests one way of
          achieving the reduction of traffic.  Other approaches could
          clearly be taken, as long as the total amount of traffic to
          the realm is reduced.

          

          Steve

          

          

        

          
On 2/11/14 3:57 AM, Nirav Salot (nsalot)
            wrote:

        

        

          
Steve,
            

          
 

          
I
              don’t understand one aspect.

          
Why
              should the request be throttled with realm report when the
              request is targeted to a particular host within the realm.

          
Can
              this request be routed to another host in that realm? If
              not, the request should be subjected to the throttling
              based on the host report.

          
 

          
Regards,

          
Nirav.

          
 

          

            

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

                  Sent: Monday, February 10, 2014 11:22 PM

                  To: lionel.morand@orange.com;
                  Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)

                  Cc: dime@ietf.org

                  Subject: Re: [Dime] [dime] #34: Semantics of
                  OC-Report-Type AVP

            

          

          
 

          
Lionel,

            

            Why would the reduction for the realm be less than servers. 
            It is perfectly valid for a realm overload report to ask for
            a reduction when there are no servers in overload.  This
            could happen in the case I mentioned where the realm
            overload report is triggered by layer 3 congestion.

            

            Clearly realm overload will be significantly influenced by
            server overload, but that isn't the only consideration.

            

            My logic was not quite correct, but for a different reason. 
            There is no reason to do the host throttling if the request
            has already been throttled by the realm report.

            It should be as follows:

            

            For all requests:

              If there is a realm overload report that applies to the
            request:

                Apply realm based throttling logic to that request

              If the request has not already been throttled and there is
            a host overload report that applies to the request:

                Apply host based throttling logic to that request

            

            One improvement would be to remember the host throttled by
            the realm abatement algorithm and input that into the server
            abatement algorithm.  This might look something like the
            following:

            

            For all requests:

                If there is a realm overload report that applies to the
              request:

                  Apply realm based throttling logic to that request

                  If request is throttled:

                    Increment host credit by one for the host indicated
              in the destination-host AVP

                If the request has not already been throttled and there
              is a host overload report that applies to the request:

                  If host credits exist for the host indicated in the
              destination-host AVP:

                    Decrement host credit by one

                  else:

                    Apply host based throttling logic to that request

            

            Steve

          

            
On 2/10/14 10:59 AM, 
                lionel.morand@orange.com wrote:

          

          

            
Hi
                Steve,

            
 

            
In
                your example, if an agent has a better knowledge than
                the server, the Host type OLR should not be sent
                unmodified in forwarded answers, or even removed as
                irrelevant.

            
 

            
And
                in a normal case, the reduction for the realm will be
                likely lower than the reduction needed for a node. S1 is
                not overload, S2 is 50% overload, the realm (S1+S2) is
                overloaded 25%. So only the reduction for the Host
                should apply, why the host-type should prevail over
                realm-type OLR.

            
 

            
By
                the way, in your proposed logic, it is not clear if the
                relation between the first and the second conditions is
                an "IF NOT".
              

            
 

            
Lionel

            
 

            

              

                
De :
                    Steve Donovan [mailto:srdonovan@usdonovans.com]
                    

                    Envoyé : lundi 10 février 2014 15:39

                    À : MORAND Lionel IMT/OLN; Jouni Korhonen;
                    Wiehe, Ulrich (NSN - DE/Munich)

                    Cc : dime@ietf.org

                    Objet : Re: [Dime] [dime] #34: Semantics of
                    OC-Report-Type AVP

              

            

            
 

            
I think we
              have agreement that a realm report applies to all traffic
              targeted for that realm, independent of the presence or
              absence of the destination-host avp.  Is that correct?

              

              I don't agree with Lionel's proposal.  The realm overload
              report should take precedence over the host overload
              report.

              

              My reasoning is as follows:

              

              - There is something responsible for tracking the health
              of the realm.  Call it the "realm overload authority". 
              The health of the realm can be based on a number of
              factors including the health of individual servers,
              individual agents and the network connecting Diameter
              entities.

              

              - When this "realm overload authority" determines that the
              IP network is congested, for instance, it would instruct
              agents or servers to send realm overload reports with the
              expectation that the overall traffic sent to the realm as
              a whole will be reduced.

              

              In this scenario, the fact that the realm is overloaded
              takes precedence over the health of the servers.  As such,
              it is likely that requests targeted for a healthy server
              will be throttled.

              

              I propose the logic should be as follows:

              

              For all requests:

                If there is a realm overload report that applies to the
              request:

                  Apply realm based trottling logic to that request

                If there is a host overload report that applies to the
              request:

                  Apply host based throttling logic to that request

              

              Note that this also requires the ability to put realm
              overload reports in any answer message, not just answers
              to requests that did not contain a destination-host AVP.

              

              Steve

            

              
On 2/10/14 5:30 AM, 
                  lionel.morand@orange.com wrote:

            

            

              
No it was not my intention and it is why it was written "except" :)

              
 

              
The abatement for the Realm applies when NO explicit reduction is requested for a specific node of this realm. In such a case i.e. when an OLR is received for a specific node inside a realm for which a reduction also applies, *ONLY* the reduction requested for the node applied.

              
 

              
Is it clearer?

              
 

              
Lioenl 

              
 

              
-----Message d'origine-----

              
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

              
Envoyé : dimanche 9 février 2014 13:46

              
À : Wiehe, Ulrich (NSN - DE/Munich)

              
Cc : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org

              
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

              
 

              
 

              
On Feb 7, 2014, at 3:12 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

              
 

              

                
 

                
 

                
-----Original Message-----

                
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                
Sent: Friday, February 07, 2014 11:21 AM

                
To: Wiehe, Ulrich (NSN - DE/Munich)

                
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org

                
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                
 

                
 

                
On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

                
 

                

                  
I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?

                  
What is wrong with letting the client

                  
-not throttle host-type requests to S1,

                  
-throttle host type request to S2 with 50% and

                  
-throttle realm type requests wit 25%?

                

                
 

                
Isn't this what Lionel said below?

                
<Ulrich> no it is not</Ulrich>

              

              
 

              
 

              
Ok, maybe I misread the "realm abatement is applied in any case

              
except if there is an explicit report for the destination-host"?

              
 

              
If this means the realm abatement is still applied after applying

              
the host abatement, then I agree it is not the same you said.

              
 

              
- Jouni

              
 

              
 

              

                
I am OK with Lionel's

                
"wording" here.

                
 

                
- Jouni

                
 

                

                  
 

                  
 

                  
 

                  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com

                  
Sent: Wednesday, February 05, 2014 4:14 PM

                  
To: Steve Donovan; dime@ietf.org

                  
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                  
 

                  
I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

                  
 

                  
Lioenl

                  
 

                  
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

                  
Envoyé : mercredi 5 février 2014 15:56

                  
À : dime@ietf.org

                  
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

                  
 

                  
It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

                  
 

                  
If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

                  
 

                  
I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

                  
 

                  
Steve

                  
 

                  
On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:

                  
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?

                  
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

                  
 

                  
Does it make sense?

                  
 

                  
Lionel

                  
 

                  
-----Message d'origine-----

                  
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 

                  
Envoyé : mardi 4 février 2014 09:55

                  
À : MORAND Lionel IMT/OLN

                  
Cc : dime@ietf.org

                  
Objet : [dime] #34: Semantics of OC-Report-Type AVP

                  
 

                  
#34: Semantics of OC-Report-Type AVP

                  
 

                  
Text in clause 4.6  does not fully explain to which requests overload

                  
treatment of a given report type applies.

                  
Proposal:

                  
 

                  
   0  A host report.  The overload treatment should apply to requests

                  
      for which all of the following conditions are true:

                  
      a) The Destination-Host AVP is present in the request and its value

                  
         matches the value of the Origin-Host AVP of the received message

                  
         that contained the OC-OLR AVP.

                  
      b) The value of the Destination-Realm AVP in the request matches the

                  
         value of the Origin-Realm AVP of the received message

                  
         that contained the OC-OLR AVP.

                  
      c) The value of the Application-ID in the Diameter Header of the

                  
         request matches the value of the Application-ID of the Diameter

                  
         Header of the received message that contained the OC-OLR AVP.

                  
 

                  
 

                  
 

                  
   1  A realm report.  The overload treatment should apply to

                  
      requests for which all of the following conditions are true:

                  
      a) The Destination-Host AVP is absent in the request.

                  
      b) The value of the Destination-Realm AVP in the request matches the

                  
         value of the Origin-Realm AVP of the received message

                  
         that contained the OC-OLR AVP.

                  
      c) The value of the Application-ID in the Diameter Header of the

                  
         request matches the value of the Application-ID of the Diameter

                  
         Header of the received message that contained the OC-OLR AVP.

                  
 

                  
 

                  
_________________________________________________________________________________________________________________________

                  
 

                  
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.

                  
_______________________________________________

                  
DiME mailing list

                  
DiME@ietf.org

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

                

                
 

              

              
 

              
 

              
_________________________________________________________________________________________________________________________

              
 

              
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.

          

          
 

        

        
 

      

    

    

  


--------------090702020703050204030104--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 05:54:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665471A00BC for ; Tue, 11 Feb 2014 05:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzy8SvbjUAbI for ; Tue, 11 Feb 2014 05:54:43 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD0F21A031B for ; Tue, 11 Feb 2014 05:54:38 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-6e-52fa2b9ddb83
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AF.38.23809.D9B2AF25; Tue, 11 Feb 2014 14:54:37 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 14:53:55 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpqukxIAgAADxQCAAAUcgIAAYRYAgAAcxICAAPpJ0A==
Date: Tue, 11 Feb 2014 13:53:55 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209772FEFESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje5c7V9BBtN6dC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxufPbawFx/Mrvp3vZG1gfBXfxcjBISFgIvH4jXcXIyeQKSZx 4d56ti5GLg4hgUOMEhtOTGCHcJYwSrxc94oFpIpNwE7i0ukXTCDNIgIaEitOZIKEhQW8JX58 uMwEYosI+Ej0Nh5hg7DDJK6u2sICUs4ioCoxp10PJMwr4CvxaO4SJojx/5gkFp9+yQqS4BSw l9j0/CFYLyPQQd9PrQGbySwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpJYdPszVH2+xLQL f9gglglKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Jk z03MzEkvN9rECIySg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYPd0F5Vf3n5n3JiHqV4TlhWc9by7/bimL9HPQu/TYsrvtr7v/j7uqTNlnCqTi9rfy RLhxHlgl/fvRogyGVdtn3P3jEOv5Qul/bJqs5YyCqdLbjVtnJf9wXRLC989nqqK6qenrZUof j38Taq3NcXbtyfI+e6VoVovKxX/JLE/DJHymXVke+ahHiaU4I9FQi7moOBEApIogC2ACAAA=
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 13:54:45 -0000

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

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:


Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:


Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:



Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:



On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:



On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:


#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.




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


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











Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Ben Campbell

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:








Just post it here.







On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:








Okay. Does that mean we should assign the issue to m=
e in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:










Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:










On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:










On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:








#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.






 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_087A34937E64E74E848732CFF8354B9209772FEFESESSMB101erics_--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 06:13:14 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4B41A0325 for ; Tue, 11 Feb 2014 06:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj_MXpIyfWjI for ; Tue, 11 Feb 2014 06:13:07 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2C21A0310 for ; Tue, 11 Feb 2014 06:13:06 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-2b-52fa2ff1fb49
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7A.6B.23809.1FF2AF25; Tue, 11 Feb 2014 15:13:05 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 15:13:04 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPI+1LK95DWDMaH0qQEyVc/ebDNpqpv0FwgATFJ4CAAUePcIAAGAbggAABmJCAAA7UgIAAKh5A
Date: Tue, 11 Feb 2014 14:13:03 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209773067@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> <52F8E5A7.6030902@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B29A1@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772EE2@ESESSMB101.ericsson.se> <14115_1392115821_52FA006D_14115_2918_1_6B7134B31289DC4FAF731D844122B36E499C02@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52FA1A5B.2080104@usdonovans.com>
In-Reply-To: <52FA1A5B.2080104@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209773067ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje5H/V9BBhNbhCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxustYQUvlzFW3Lk7h6mBcU8/YxcjJ4eEgIlE+4F5bBC2mMSF e+uBbC4OIYFDjBJ9My8zQjhLGCXa33cxgVSxCdhJXDr9Asjm4BARUJY4/csBJCwsYC/x9cYZ ZhBbRMBBYs3zkywQdpTElk3bwWwWAVWJniXHwBbzCvhKnOn+wwIxv5dFYufE9awgCU4BPYn9 L5vBGhiBLvp+ag3YXmYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQtpLE2sMQy5gF8iVmfzvM DrFMUOLkzCcsExhFZiEZNQtJ2SwkZRBxPYkbU6ewQdjaEssWvmaGsHUlZvw7xIIsvoCRfRUj e25iZk56udEmRmCsHNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAGHdM8PdkDpnvWrOkXuvbPJ2c/95Ly/N55dJYp92PfEWYunn0+lUfW69zuWt+dBv/ Q/bVczwO+L+LfsKszXley0Sd+2Tst5I7pkExCTvnNy9WaZ3xIfPn10s8zt++W77TkHn/5n35 /Wp/F/v/TXxdbFekDUuvtH6p6n1usKtZrlD+ZURxRvNZJZbijERDLeai4kQALYvuy2MCAAA=
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 14:13:15 -0000

--_000_087A34937E64E74E848732CFF8354B9209773067ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

Ulrich proposal was the following:


   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:

      a) The Destination-Host AVP is present in the request and its value

         matches the value of the Origin-Host AVP of the received message

         that contained the OC-OLR AVP.

      b) The value of the Destination-Realm AVP in the request matches the

         value of the Origin-Realm AVP of the received message

         that contained the OC-OLR AVP.

      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.

Since the text is for Host Report, and as it is introduced, I think origina=
l text is better.
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 11 de febrero de 2014 13:41
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Agreed, there is nothing contentious here.  I agree that the report applies=
 only to the application ID included in the message carrying the overload r=
eport.

Ulrich's wording isn't clear on which messages are being referenced.  Or I =
wasn't looking at full context.  It might be better to try to change the pr=
oposed wording from:
How about changing Ulrich's proposal from:



      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.
to the following:

"The value of the application-ID in the Diameter Header of new request mess=
ages matches the value of the Application-ID is an active overload report."

Steve
On 2/11/14 4:50 AM, lionel.morand@orange.com wrote:

I think that there is no contentious issue here :)

I think that Ulrich is right saying that the reacting node needs to take in=
to account the application-id to perform the abatement. Not when receiving =
the OLR... but when sending a new request.



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 11 f=E9vrier 2014 11:43

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



Exact, I agree.

Cheers

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: martes, 11 de febrero de 2014 10:37

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



Steve,



I do not agree.



e.g.

1. reacting node sends Request with application ID =3D x to reporting node =
2. reporting node sends back answer (containing an OLR) with application ID=
 =3D x 3. reacting node now may very well send  a new request with applicat=
ion ID =3D y to the reporting node without breaking any Diameter rules.

The new request sent in step 3 is NOT subject to throttling according to th=
e OLR received in step 2.

I hope this is not contentious.

In order to provide a complete list of conditions to say when an OLR of a g=
iven type applies to a new request, we should not let c) go by the board.



Ulrich











-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Monday, February 10, 2014 3:44 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP





      c) The value of the Application-ID in the Diameter Header of the

         request matches the value of the Application-ID of the Diameter

         Header of the received message that contained the OC-OLR AVP.

No need for this since we agreed that DOIC implicitly always refers to

the application on which the DOIC AVPs are carried in.

yes, we agreed on that, so c) is correct and it does not harm

to keep c)

SRD> I don't see the reason for including this statement.  By

definition, an overload report

applies to the application ID in the answer message.  There is no way for t=
he application-id in the answer message to be different than the applicatio=
n-id in the request message without breaking Diameter.



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_087A34937E64E74E848732CFF8354B9209773067ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

Ulrich proposal was the f=
ollowing:


 <=
/p>

   0  A host report.  The overlo=
ad treatment should apply to requests


      for which all of the =
following conditions are true:


      a) The Destination-Ho=
st AVP is present in the request and its value


         mat=
ches the value of the Origin-Host AVP of the received message


         tha=
t contained the OC-OLR AVP.


      b) The value of the D=
estination-Realm AVP in the request matches the


         val=
ue of the Origin-Realm AVP of the received message


         tha=
t contained the OC-OLR AVP.


      c) The value of the A=
pplication-ID in the Diameter Header of the


         req=
uest matches the value of the Application-ID of the Diameter


         Hea=
der of the received message that contained the OC-OLR AVP.


 


Since the tex=
t is for Host Report, and as it is introduced, I think original text is bet=
ter.


Cheers


/MCruz


 <=
/p>





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

Sent: martes, 11 de febrero de 2014 13:41

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


Agreed, there is nothing contentious here.  I a=
gree that the report applies only to the application ID included in the mes=
sage carrying the overload report. 




Ulrich's wording isn't clear on which messages are being referenced.  =
Or I wasn't looking at full context.  It might be better to try to cha=
nge the proposed wording from:

How about changing Ulrich's proposal from:








      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.


to the following:



"The value of the application-ID in the Diameter Header of new request=
 messages matches the value of the Application-ID is an active overload rep=
ort."



Steve




On 2/11/14 4:50 AM, 
lionel.morand@orange.com wrote:






I think that there is no contentious issue here :)


I think that Ulrich is right saying that the reacting node needs to ta=
ke into account the application-id to perform the abatement. Not when recei=
ving the OLR... but when sending a new request.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : mardi 11 f=E9vrier 2014 11:43


=C0 : dime@ietf.org


Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


Exact, I agree.


Cheers


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: martes, 11 de febrero de 2014 10:37


To: ext Steve Donovan; dime@ietf.org<=
/a>


Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


Steve,


 


I do not agree.


 


e.g. 


1. reacting node sends Request with application ID =3D x to reporting =
node 2. reporting node sends back answer (containing an OLR) with applicati=
on ID =3D x 3. reacting node now may very well send  a new request wit=
h application ID =3D y to the reporting node without breaking any Diameter =
rules. 


The new request sent in step 3 is NOT subject to throttling according =
to the OLR received in step 2.


I hope this is not contentious.


In order to provide a complete list of conditions to say when an OLR o=
f a given type applies to a new request, we should not let c) go by the boa=
rd.


 


Ulrich


 


 


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Monday, February 10, 2014 3:44 PM


To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


 


 






      c) The value of the Application-ID in t=
he Diameter Header of the


         request matches the v=
alue of the Application-ID of the Diameter


         Header of the receive=
d message that contained the OC-OLR AVP.




No need for this since we agreed that DOIC implicitly always refers to=
 


the application on which the DOIC AVPs are carried in.

<Ulrich>yes, we agreed on that, so c) is correct and it does not=
 harm 


to keep c)</Ulrich>




SRD> I don't see the reason for including this statement.  By<=
o:p>


definition, an overload report


applies to the application ID in the answer message.  There is no=
 way for the application-id in the answer message to be different than the =
application-id in the request message without breaking Diameter.=



 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_087A34937E64E74E848732CFF8354B9209773067ESESSMB101erics_--


From ben@nostrum.com  Tue Feb 11 06:18:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAEC1A0338 for ; Tue, 11 Feb 2014 06:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSZc12kHk54i for ; Tue, 11 Feb 2014 06:18:00 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE1C51A032D for ; Tue, 11 Feb 2014 06:18:00 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1BEHufH046001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Feb 2014 08:17:58 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <28236_1392113210_52F9F63A_28236_134_5_6B7134B31289DC4FAF731D844122B36E4999E8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Tue, 11 Feb 2014 08:17:56 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <28236_1392113210_52F9F63A_28236_134_5_6B7134B31289DC4FAF731D844122B36E4999E8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: "ext lionel.morand@orange.com" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 14:18:05 -0000

On Feb 11, 2014, at 4:06 AM, lionel.morand@orange.com wrote:

> On 1), the reacting node will know that the server is DOIC-enabled =
when receiving the Supported-Features AVP, whatever the content of this =
AVP. When no OLR is sent, I think that there is nothing preventing a =
reporting node to announce all
>=20

I'm confused. I thought the thread was saying that sending the =
OC-Supported-Features AVP in an answer would be optional. Did I =
misunderstand?=20

> On 2), honestly, I don't see the need for trying to keep a single AVP =
for all the possible abatements, especially if we are saying that the =
overload control is defined per application.
> I think that there is value to try to reuse the same algo across =
application but not so try to reuse the same AVP across algos.
>=20
> I do not foresee 1000 different algos defined for Diameter systems. =
And if it is, defining one OC-OLR AVP per algo is not an issue. We are =
not running out of AVP codes. The AVP code itself is sufficient to =
indicate the algo to use i.e. "this is an overload report for algo x". =
And each application will explain anyhow how to use this overload =
report.

If we don't do this in a consistent way across applications, then =
application-independent relays will not be able to participate.

>=20
> The main conclusions would be to be able to:
> - Get rid of the OC-Supported-Features AVP in answer containing an =
OC-OLR AVP.

Disagree for the reasons stated. I want a a consistent, single AVP that =
I can use to tell if the server supports DOIC. The code I envision =
wouldn't bother looking for OC-OLR if OC-Supported-Features was absent. =
It costs nothing to put it in, and it makes life much easier on the =
recipient.

> - get rid of the sequence number in the OC-Supported-Feature AVP in =
all the requests and in the answer when the OC-Supported-features AVP is =
including for capabilities discovery.

Have we also agreed to require OC-Supported-Feature in every request?

>=20
> Regards,
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
> Envoy=E9 : mardi 11 f=E9vrier 2014 01:14
> =C0 : Steve Donovan
> Cc : dime@ietf.org list
> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
>=20
> I don't quite agree with where I think this thread is going, on two =
points:
>=20
> 1) I want the reacting node to be able to learn if a (potentially) =
reporting node supports DOIC, even when that node is not in overload. I =
don't want to specify any particular behavior for that knowledge, but I =
suspect implementations may want to treat DOIC compliant servers in some =
way differently than they do non-DOIC servers. For example, I might have =
a configured rate limit for non-DOIC peers, but use a higher (or no) =
limit for peers that are known to support DOIC (and can thus speak for =
themselves.)
>=20
> 2) It's clumsy to have to look at an external (to OC-OLR) AVP to find =
out the algorithm. I think the actual algorithm for a particular report =
should be indicated in OC-OLR, not OC-Supported-Features at the root of =
the message.
>=20
>=20
> Now, separate from those points, I think we should consider whether =
it's okay for a reporting nodes to switch algorithms mid-stream, vs pick =
an algorithm and stick with it. Right now, I think we effectively allow =
a reporting node to send an OLR for one algorithm in one answer, then =
another algorithm in the next, even for the same reacting node. If so, =
we need to define what it means when that happens.
>=20
> For example, if I receive an OLR with the "loss" algorithm, and =
another with the "rate" algorithm from the same server, does the second =
replace the first? Do I now have two overload state entries that I need =
to "stack"?
>=20
> Thanks!
>=20
> Ben.
>=20
> On Feb 10, 2014, at 9:07 AM, Steve Donovan  =
wrote:
>=20
>> I'll attempt to summarize where we are on this.  If this is agreed to =
then the necessary changes would be made to the -01 draft.  Some of this =
is already in the draft, some of it will require changes.
>>=20
>> - The draft already makes it optional for the reporting node to =
include the OC-Supported-Features AVP in answer messages - No change =
required here.
>>=20
>> - A reporting node must choose the overload abatement algorithm to be =
sent to a reacting node from the set of abatement algorithms included in =
the OC-Supported-Features AVP received in the request message.
>>=20
>> - If the reporting node sends an OC-OLR AVP and there is no =
OC-Supported-Features AVP then the abatement algorithm used by the =
reacting node must be loss.
>>=20
>> - The reporting node may include the OC-Supported-Features AVP with =
the loss algorithm indicated in the OC-Feature-Vector AVP.
>>=20
>> - If the reporting node wants the reacting node to apply an algorithm =
other then loss, the reacting node must include the =
OC-Supported-Features AVP with a single algorithm indicated in the =
OC-Feature-Vector AVP.=20
>>=20
>> - New abatement algorithm extensions may use and extend the existing =
OC-OLR AVP.  The new algorithms may also create a new overload report =
AVP if that makes the most sense.
>>=20
>> - The loss algorithm is and always will be the mandatory to implement =
algorithm.  Or it will be until a new RFC is published that changes the =
mandatory to implement algorithm.
>>=20
>> Steve=20
>>=20
>> On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:
>>>=20
>>> -----Message d'origine-----
>>> De : Jouni Korhonen [
>>> mailto:jouni.nospam@gmail.com
>>> ]=20
>>> Envoy=E9 : lundi 10 f=E9vrier 2014 12:24
>>> =C0 : MORAND Lionel IMT/OLN
>>> Cc :=20
>>> dime@ietf.org
>>>=20
>>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
>>>=20
>>>=20
>>> On Feb 10, 2014, at 1:15 PM,=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> Hi Jouni,
>>>>=20
>>>>=20
>>>>> As the syntax of the OC-Feature-Vector is adapted to advertize =
supported algos, it could be easier to clarify that the OC-OLR AVP is =
THE report AVP for the reduction algo (default) and a new dedicated =
report AVP must be created when a new algo is introduced. In this way, =
the OC-OLR is self-explicit.
>>>>>=20
>>>> Bah. OLR should work for additional abatement algorithms
>>>> IF we agree that the OLR is align with the announced
>>>> abatement algorithm..=20
>>>>=20
>>>> [LM] The issue if when you have more than one algo (let say 2). =
There is no way for the reporting node to indicate the algo to use with =
the OLR sent in the answer using the OC-Feature-Vector. The only info =
that you could have is "use either one or the other".
>>>>=20
>>> This we can fix (and I personally would like to fix). The reporting =
node
>>> announces in its OC-Feature-Vector the selected common algorithm for =
the
>>> sent OLR. We had this at some point of time, btw.
>>>=20
>>> [LM] Acceptable! So in answer including the OLR, the =
OC-Feature-Vector MAY be used (when present) to indicate the algo to =
use, algo part of the common algos between the reporting node and the =
reacting node.
>>>=20
>>>=20
>>>> The simpliest way would be to define a new AVP when you want to =
support more than the default algo. If you want to rely on the same OLR =
with another algo, you should have a way to indicate the algo to use =
with the given OLR.
>>>>=20
>>> I recall there was a strong arguments against algorithm types in =
OLRs..
>>>=20
>>> [LM] I was not proposing such idea :)
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>>=20
>>>>> It would be purely optional to send the Supported-Features AVP =
along with the OC-OLR AVP.
>>>>>=20
>>>> It is already today if you only support the default, right.
>>>>=20
>>>> [LM] Right. No issue here.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : Jouni Korhonen [
>>>> mailto:jouni.nospam@gmail.com
>>>> ]=20
>>>> Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages
>>>>=20
>>>>=20
>>>> On Feb 4, 2014, at 5:01 PM,=20
>>>> lionel.morand@orange.com
>>>> wrote:
>>>>=20
>>>>=20
>>>>> I think that there is actually an issue here but the proposed way =
to solve it is not the correct one.
>>>>>=20
>>>> Agree.
>>>>=20
>>>>=20
>>>>> The initial idea was to be able to use the same overload report =
with several algorithms. So the OLR was somehow only meaningful along =
with the OC-Feature-Vector AVP.
>>>>>=20
>>>> The initial idea was to go on lines of RFC5447.
>>>>=20
>>>>=20
>>>>> But because the OC-Feature-Vector AVP is defined as a set of =
flags, it is not possible to say that this OLR is to be used with only =
one given algo when more than one is defined (as the bit flags will =
advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector =
cannot be used to indicate the abatement to perform.
>>>>>=20
>>>> My intention was always allow:
>>>>=20
>>>> client announces  ABC
>>>> server supports    BCD
>>>> server announced only  e.g. C since it is common
>>>> alternatively server announced nothing and then the default applies
>>>>=20
>>>>=20
>>>>> As the syntax of the OC-Feature-Vector is adapted to advertize =
supported algos, it could be easier to clarify that the OC-OLR AVP is =
THE report AVP for the reduction algo (default) and a new dedicated =
report AVP must be created when a new algo is introduced. In this way, =
the OC-OLR is self-explicit.
>>>>>=20
>>>> Bah. OLR should work for additional abatement algorithms
>>>> IF we agree that the OLR is align with the announced
>>>> abatement algorithm..=20
>>>>=20
>>>>=20
>>>>> It would be purely optional to send the Supported-Features AVP =
along with the OC-OLR AVP.
>>>>>=20
>>>> It is already today if you only support the default, right.
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>>> Lionel=20
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : dime issue tracker [
>>>>> mailto:trac+dime@trac.tools.ietf.org
>>>>> ]=20
>>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48
>>>>> =C0 : MORAND Lionel IMT/OLN
>>>>> Cc :=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : [dime] #30: OC-Supported-Features AVP in answer messages
>>>>>=20
>>>>> #30: OC-Supported-Features AVP in answer messages
>>>>>=20
>>>>> According to the current feature advertisement/negotiation =
mechanism in
>>>>> the -01 draft reporting DOIC endpoint insert an =
OC-Supported-Features AVP
>>>>> in answer messages to indicate their supported OC features to the =
reacting
>>>>> DOIC endpoint.
>>>>> The author of this document believes that  the best a reacting =
node can do
>>>>> with such information is to ignore it, and therefore proposes to =
allow
>>>>> reporting nodes not to insert OC-Supported-Features AVPs in answer
>>>>> messages.
>>>>> Currently only one feature is defined (OLR_DEFAULT_ALGO).
>>>>> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but =
no other
>>>>> feature is only interested in receiving/not receiving OC-OLR AVPs =
from
>>>>> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly =
indicates
>>>>> support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not =
receiving
>>>>> an OC-OLR-AVP from the reporting DOIC endpoint may have two =
reasons:
>>>>>=20
>>>>> a) There is no overload
>>>>> b) DOIC is not supported
>>>>>=20
>>>>> The reacting DOIC endpoint does not need to differentiate between =
these
>>>>> two cases as the behavior (do not throttle) is the same in both =
cases.
>>>>> The -01 draft says in  clause 4.1:
>>>>>  If there is no single matching
>>>>>  capability the reacting node MUST act as if it does not implement
>>>>>  DOIC and cease inserting any DOIC related AVPs into any Diameter
>>>>>  messages with this specific reacting node.
>>>>>=20
>>>>> This however is inconsistent.
>>>>> The reacting node that ceases sending DOIC related AVPs would =
never
>>>>> recognize when the server is upgraded to support DOIC.
>>>>> Subsequent requests (not including DOIC related AVPs) may take a =
different
>>>>> path towards the server and on that path there may be an agent =
that
>>>>> supports DOIC (with a match of supported features) and could take =
the role
>>>>> of the reporting DOIC endpoint; but the agent cannot take this =
role since
>>>>> the reacting node (although supporting DOIC) ceased sending of OC-
>>>>> Supported-Features AVPs.
>>>>> In summary: As long as no extension feature is defined within  =
draft-ietf-
>>>>> dime-ovli  (i.e. never, since extensions will  be defined in other
>>>>> drafts), there is no need for draft-ietf-dime-ovli  to mandate or =
even
>>>>> describe inclusion of OC-Supported-Features AVP in answer =
messages.
>>>>>=20
>>>>> --=20
>>>>> --------------------------------------+--------------------------
>>>>> Reporter: =20
>>>>> lionel.morand@orange.com
>>>>>  |      Owner:  Ulrich Wiehe
>>>>>   Type:  defect                    |     Status:  new
>>>>> Priority:  major                     |  Milestone:
>>>>> Component:  draft-docdt-dime-ovli     |    Version:
>>>>> Severity:  Active WG Document        |   Keywords:
>>>>> --------------------------------------+--------------------------
>>>>>=20
>>>>> Ticket URL:=20
>>>>> 
>>>>>=20
>>>>> dime=20
>>>>> 
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>> they should not be distributed, used or copied without =
authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>>=20
>>>=20
>>> =
__________________________________________________________________________=
_______________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 06:19:47 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA88A1A032D for ; Tue, 11 Feb 2014 06:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lexsqkuH0Vav for ; Tue, 11 Feb 2014 06:19:42 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C66271A03BB for ; Tue, 11 Feb 2014 06:19:41 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-a0-52fa317cb2e7
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 83.6C.23809.C713AF25; Tue, 11 Feb 2014 15:19:40 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 15:19:40 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAlWmMf1mPE0uklIAv2DU+a5qmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDg///ya4CAAEgwoA==
Date: Tue, 11 Feb 2014 14:19:39 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <24563_1391533955_52F11F82_24563_614_1_6B7134B31289DC4FAF731D844122B36E477563@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F25115.9030204@usdonovans.com> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvjW6N4a8gg7vPjCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvTzwgVvOxgr7u6QbWB8kNfFyMkhIWAi0fujkQnCFpO4cG89 WxcjF4eQwCFGiWXfZrNDOEsYJZ7sOsgIUsUmYCdx6fQLoA4ODhEBZYnTvxxAwsIC9hJfb5xh BrFFBBwk1jw/yQJh10ms3fmCFcRmEVCVeNd0AGwMr4CvxNslK5kh5h/jkPi+eBMjiMMp0MYo sfDGc7BuRqCTvp9aA3Yes4C4xK0n86FOFZBYsuc8M4QtKvHy8T9WCFtJYu3h7SwQ9XoSN6ZO YYOwtSWWLXzNDLFZUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm60iREY+Ae3 /FbdwXjnnMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLZodNirscrG Xpj/aKP83d+LWiIX3GMqn/i19d5qZZ3Kqgpdu5pPHTxljEtfLj05IU167734yPXWT0uYwqYd 7atw+anBscszbdeEHPbLr2vuif258H9BrkRRzPLVcwPFsnWy9OWEdzmfuiS5In6JcvvlU9MX 1wbzR4YVKsW1K2WHbtzBzzTnpBJLcUaioRZzUXEiANx0bUxKAgAA
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 14:19:48 -0000

Lionel,

About first case:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host=20

I do not agree on this, since if Destination Host is used, there is no reas=
on to throttle messages if this Host has not provided any OLR.
This is in line with the example used from the beginning:
---------
..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% ov=
erloaded, and the aggregated realm overload is 25%. Why should a client do =
a 25% throttling when sending host type requests to the not at all overload=
ed S1?
What is wrong with letting the client
-not throttle host-type requests to S1,
-throttle host type request to S2 with 50% and
-throttle realm type requests wit 25%?
------------

And I think this is what JJ commented:
[JJ] there may be a misunderstanding somewhere, so good to try to clarify; =
coming back to Ulrich example, Host S1 is not overloaded, so reacting node =
has not received Host reduction OLR for S1. But as there  is a realm reduct=
ion, reacting node will reduce traffic with destination Host S1.

In my opinion, reducing traffic to S1 is wrong.

Regards
/MCruz

-----Original Message-----
From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Sent: martes, 11 de febrero de 2014 11:57
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi maria-cruz,

JJ agreed on the following approach:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host [JJ] there may be a misunderstanding somew=
here, so good to try to clarify; coming back to Ulrich example, Host S1 is =
not overloaded, so reacting node has not received Host reduction OLR for S1=
. But as there  is a realm reduction, reacting node will reduce traffic wit=
h destination Host S1.
  =20
- If the reacting node has received an indication only for host traffic red=
uction, apply host reduction for messages containing a Destination-Host. No=
 reduction for messages with only a Destination-Realm.
[JJ] OK
=20
- If the reacting node has received both an indication for host traffic and=
 for realm traffic reduction, only the realm reduction will apply for messa=
ges with only the Destination-Realm AVP and only the host reduction will ap=
ply for messages with the Destination-Host AVP (and the Destination-Realm A=
VP).
[JJ] OK, Host reduction prevails

In other words, as said earlier, the Host reduction prevails over realm red=
uction when the overloaded host is inside an overloaded realm and the react=
ing has received info about both type of overload.

What is the issue with this approach?

Regards,

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:49 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hello,
I agree with JJ:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host [JJ] there may be a misunderstanding somew=
here, so good to try to clarify; coming back to Ulrich example, Host S1 is =
not overloaded, so reacting node has not received Host reduction OLR for S1=
. But as there  is a realm reduction, reacting node will reduce traffic wit=
h destination Host S1.

[MCruz] And... if the request is sent to a Destination-Host, if there is an=
y applicable OLR, it will be received immediately in the answer, and will b=
e applicable from next request on.
Simple and robust in my opinion. Then, we do not need to evaluate whether w=
e have OLR for Realm and/or Host, and even check their validity & applicabi=
lity.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 15:00
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Lionel=20

Please see in line

-----Message d'origine-----
De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9=
=A0: lundi 10 f=E9vrier 2014 14:25 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES); dime@ietf.org Objet=A0: RE: [Dime] [dime] #34: Semantics of OC-Report=
-Type AVP

I disagree and my proposal was somehow misunderstood.

I don't see the issue to have the following sequence:

- If the reacting node has received an indication only for Realm traffic Re=
duction, apply Realm reduction is for any message, with Destination-Realm a=
nd with/without Destination-Host [JJ] there may be a misunderstanding somew=
here, so good to try to clarify; coming back to Ulrich example, Host S1 is =
not overloaded, so reacting node has not received Host reduction OLR for S1=
. But as there  is a realm reduction, reacting node will reduce traffic wit=
h destination Host S1.
  =20
- If the reacting node has received an indication only for host traffic red=
uction, apply host reduction for messages containing a Destination-Host. No=
 reduction for messages with only a Destination-Realm.
[JJ] OK
=20
- If the reacting node has received both an indication for host traffic and=
 for realm traffic reduction, only the realm reduction will apply for messa=
ges with only the Destination-Realm AVP and only the host reduction will ap=
ply for messages with the Destination-Host AVP (and the Destination-Realm A=
VP).
[JJ] OK, Host reduction prevails

In other words, as said earlier, the Host reduction prevails over realm red=
uction when the overloaded host is inside an overloaded realm and the react=
ing has received info about both type of overload.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9=A0: lundi 10 f=E9vrier 2014 13:56 =C0=A0: dime@=
ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear  all

I share Ulrich and MCruz views,
- Host OLR based control applies to requests where Destination Host is know=
n
- Realm OLR based control applies to requests where Destination Host is not=
 known (only the Destination realm).

I think it is simple, otherwise as MCruz indicated it complicates; e.g abou=
t the Ulrich's example where the Host S1 is not overloaded but the realm is=
 overloaded. the client will not receive Host OLR reports from host S1 (so =
no explicit traffic reduction requested by S1), but according to Lionel com=
ment, I understand  client will have to throttle the requests sent to S1 ac=
cording to realm OLR, so how to avoid this.

JJacques

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: vendredi 7 f=E9vrier 2014 17:15 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear all,

I am in favor of the proposal made by Ulrich in the sequence diagram he pro=
vided.
----
As a summary:
Consequently the reacting node will receive realm type OLRs from the agent =
and host type OLRs from the servers.
The received realm type OLR will be relevant for the reacting node when sen=
ding/throttling realm type requests; the received host type OLR will be rel=
evant for the reacting node       when sending/throttling host type request=
s.
-----

It may occur though, that a Client has only received Realm type OLR, and th=
en it has to send a request to one specific host, then the Client will not =
apply any restriction, but as soon as the response is received back, Client=
 will update Host type OLR.  Same will apply when only Host type OLR has be=
en received by Client.
The alternative will be to always send back from an Agent both Host OLR plu=
s Realm OLR, but I do not think this is necessary and may complicate the so=
lution.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> I better like Lionel's approach, but even that is not ok in the unlikely =
extreme case where we have two servers in a realm, S1 is not overloaded at =
all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why sh=
ould a client do a 25% throttling when sending host type requests to the no=
t at all overloaded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1, -throttle host type request to
> S2 with 50% and -throttle realm type requests wit 25%?

Isn't this what Lionel said below?
 no it is not
 I am OK with Lionel's
"wording" here.

- Jouni

> =20
> =20
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
> lionel.morand@orange.com
> Sent: Wednesday, February 05, 2014 4:14 PM
> To: Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> I tend to agree except that I would reverse the logic as for the routing =
principles: the Destination-host takes precedence when present over Destina=
tion-Realm. So the realm abatement is applied in any case except if there i=
s an explicit report for the destination-host.
> =20
> Lioenl
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet : Re=
:
> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> It makes more sense to me for a realm report to apply to all requests tar=
geted for that realm, independent the type of request.  This implies that i=
t would apply to requests that also have a Destination-Host specified.
>=20
> If this is the definition of a realm report then we need to specify the i=
nteraction between realm reports and host reports.
>=20
> I propose that throttling would occur on the realm first and the host sec=
ond.  If a message targetted for the host is throttled as a result of realm=
 overload then that throttled message would count as part of the reduction =
needed to address the host overload.  Messages to the host that survive rea=
lm abatement would then be candidates for host overload.
>=20
> Steve
>=20
> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
> The case "Realm" as described below raises another question: is it prohib=
ited for a realm to only rely on a global overload report for the whole rea=
lm, whatever the nodes inside this realm?
> If not, only OLR with the report type "realm" would be received by the re=
acting node. And the reduction indicated in the OLR will apply always for t=
he realm, whatever the presence of Destination-host AVP in the request... e=
xcept if an explicit report with the type "Host" as been received for this =
destination-host.
> =20
> Does it make sense?
> =20
> Lionel
> =20
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #34: Semantics of OC-Report-Type AVP
> =20
> #34: Semantics of OC-Report-Type AVP
> =20
>  Text in clause 4.6  does not fully explain to which requests overload=20
> treatment of a given report type applies.
>  Proposal:
> =20
>     0  A host report.  The overload treatment should apply to requests
>        for which all of the following conditions are true:
>        a) The Destination-Host AVP is present in the request and its valu=
e
>           matches the value of the Origin-Host AVP of the received messag=
e
>           that contained the OC-OLR AVP.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
> =20
> =20
> =20
>     1  A realm report.  The overload treatment should apply to
>        requests for which all of the following conditions are true:
>        a) The Destination-Host AVP is absent in the request.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
> =20
> =20
> ______________________________________________________________________
> ___________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 05:59:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4B01A032D for ; Tue, 11 Feb 2014 05:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLHZPQJyHkaH for ; Tue, 11 Feb 2014 05:59:49 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4B1A030C for ; Tue, 11 Feb 2014 05:59:47 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-b7-52fa2cd21660
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 98.4E.04853.2DC2AF25; Tue, 11 Feb 2014 14:59:46 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 14:59:45 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjw///bTtD//37qYA==
Date: Tue, 11 Feb 2014 13:59:44 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920977300CESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje4lnV9BBmum6VnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujINNz1kK9lzjrHhzdSVLA+OJbZxdjJwcEgImEl9mbGCBsMUk Ltxbz9bFyMUhJHCCUeL2/e1MEM4SRomex81gVWwCdhKXTr8ASnBwiAgoS5z+5QASFhYol3h5 6QoziC0iUCHxeeslsF4RgXOMEsc/NDGBJFgEVCXunFjCCmLzCvhKLJj+nxViwRweiUXXd4Ct 5hRoZpRYf/wZO0gVI9BN30+tAetmFhCXuPVkPhPErQISS/acZ4awRSVePv7HCmErSaw9vJ0F oj5fYkU/xEm8AoISJ2c+YZnAKDILyahZSMpmISmbBfQcs4CmxPpd+hAlihJTuh+yQ9gaEq1z 5rIjiy9gZF/FKFmcWlycm25koJebnluil1qUmVxcnJ+nV5y6iREYUwe3/DbawXhyj/0hRmkO FiVx3uusNUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGL3E5ux98ahw4etXJiadbo5aM5bf 5lSacq9m+5btlzIcHrbszCnhro9dU7aoU1C0655jc7hab2KU3u76krxYz5b3sx+9TTh62N3G yX5/Jsfnc39f/Xgb78Pjmv60k98ktvEA84Xe5/MMTwiuXC7+oEnvyXvpGW7zv9v5mNz7wuKk OzNj+v4ztUosxRmJhlrMRcWJAOpDiKJ3AgAA
X-Mailman-Approved-At: Tue, 11 Feb 2014 07:03:21 -0800
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 13:59:58 -0000

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

TGlvbmVsLCBOaXJhdiwgYWxsLA0KDQpNYXliZSB0aGUgbm90ZSBjb3VsZCBiZSBtb2RpZmllZDoN
Cg0KTm90ZSDigJN0aGUgcmVhY3Rpbmcgbm9kZSBjb3VsZCBiZSBhbnkgYWdlbnQgaW4gdGhlIHBh
dGgsIGFuZCB0aGF0IGluIHNvbWUgZXJyb3Igc2l0dWF0aW9ucyBvdmVybG9hZCByZXBvcnRzIG1h
eSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMuDQoNCkkgYWRkZWQgdGhlIGNhc2UgT0xS
IGNvdWxkIGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlcywgc2luY2UgaXQgaGlnaGxpZ2h0
cyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmVyIHdpbGwgbm90IGtub3cgd2hldGhlciBvciBu
b3QgYSB2YWxpZCBPTFIgaXMgcmVjZWl2ZWQgYnkgcmVhY3Rpbmcgbm9kZS4NCg0KQmVzdCByZWdh
cmRzDQovTUNydXoNCg0KDQpGcm9tOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20gW21haWx0bzps
aW9uZWwubW9yYW5kQG9yYW5nZS5jb21dDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUg
MjAxNCAxMTozNg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJq
ZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN
Cg0KQXQgbGVhc3QsIGl0IGlzIG5vdCAidGhlIG9ubHkgc3VyZSB3YXkiLg0KRm9yIGluc3RhbmNl
LCBzdWJzZXF1ZW50IG1lc3NhZ2VzIHBhcnQgb2YgdGhlIHNhbWUgc2Vzc2lvbiAob3IgcHNldWRv
LXNlc3Npb24pIGNvdWxkIGFsc28gYmUgdXNlZCBhcyBpbmRpY2F0aW9uIGZvciB0aGUgcmVwb3J0
aW5nIG5vZGUgdGhhdCB0aGUgT0xSIGhhcyBiZWVuIHJlY2VpdmVkIGJ5IHRoZSByZWFjdGluZyBu
b2RlIChiZXNpZGVzIHRoZSByZWNlcHRpb24gb2YgdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBp
biB0aGUgcmVxdWVzdCkuDQpJdCBpcyB3aHkgSSB3YXMgc2F5aW5nIHRoYXQgdGhpcyBjYW4gYmUg
Zml4ZWQgcGVyIGFwcGxpY2F0aW9uL3N5c3RlbS4NCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6IEJhcnRv
bG9tZQ0KRW52b3nDqSA6IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTE6MzENCsOAIDogZGltZUBp
ZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkZpbmUgTmlyYXYsIEkgYWdyZWUg
dGhpcyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCk15IGludGVudGlvbiBpcyB0aGF0IGFu
eSByZWFkZXIgcmVhbGl6ZXMgd2hhdCB0aGlzIGtub3dsZWRnZSBpbiB0aGUgc2VydmVyIGltcGxp
ZXMgd2hlbiB3ZSB0YWxrIGFib3V0IGFnZW50cyBpbiB0aGUgcGF0aC4gVGhpcyBpcyB3aHkgSSB0
aGluayB0aGlzIG5vdGUgaXMgaGVscGZ1bC4NCg0KUmVnYXJkcw0KL01DcnV6DQoNCkZyb206IE5p
cmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IG1hcnRl
cywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjI2DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7
IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBkbyBub3QgYWdy
ZWUgcmVnYXJkaW5nIHRoZSBjb21wbGV4aXR5IHNpbmNlIGl0IGlzIGhpZ2hseSBpbXBsZW1lbnRh
dGlvbiBzcGVjaWZpYy4NCkxldHMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gaW4gdGhlIHByb3Rv
Y29sIGRlc2lnbi4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNl
bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDM6NTQgUE0NClRvOiBkaW1lQGlldGYub3Jn
PG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkhlbGxvLA0KDQpJIHRoaW5rIGl0IGlzIGlt
cG9ydGFudCB0byBoaWdobGlnaHQgY29tcGxleGl0eSBmb3IgdGhlIHNlcnZlciB0byAg4oCcZ3Vh
cmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92
ZXJsb2FkIHJlcG9ydC7igJ0NCkkgdGhpbmsgdGhpcyBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2Vu
dGVuY2UgYWRkZWQgYnkgU3RldmUuDQoNCkNoZWVycw0KL01DcnV6DQoNCkZyb206IERpTUUgW21h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOaXJhdiBTYWxvdCAobnNh
bG90KQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjANClRvOiBsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IFN0
ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
SSBhbSBhbHNvIGZpbmUgd2l0aCBTdGV2ZSdzIHByb3Bvc2VkIHdvcmRpbmcgdG8gcmVjb21tZW5k
IHRoZSBpbmNsdXNpb24gb2YgT0xSIGJ1dCB0byBub3QgbWFuZGF0ZSBpdC4NCg0KSSBhbSBub3Qg
c3VyZSBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNz
YXJ5IHRvIGFkZCBpdC4NCk5vdGUgLSB0aGUgb25seSBzdXJlIHdheSwgd2l0aG91dCBwcm9wcmll
dGFyeSBtZWNoYW5pc21zLCB0byBrbm93IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZl
ZCBhbiBvdmVybG9hZCByZXBvcnQgaXMgd2hlbiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIGNsaWVu
dCBhbmQgdGhlcmUgaXMgbm8gYWdlbnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0
aW5nIG5vZGUuDQoNCkkgcHJlZmVyIHRvIHJlbW92ZSBpdCBzaW5jZSBJIGRvIG5vdCBzZWUgYXMg
dmFsdWUgYWRkaXRpb24uDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPg0KU2VudDogTW9uZGF5LCBGZWJy
dWFyeSAxMCwgMjAxNCAxMDoxMyBQTQ0KVG86IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8
bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSdtIGZpbmUgd2l0aCBhIHJlY29tbWVuZGF0
aW9uLg0KDQpCdXQgSSBoYXZlIGEgZ2VuZXJhbCBjb21tZW50OiB3aGVuIGEgTUFZIG9yIGV2ZW4g
YSBTSE9VTEQgYXBwbHksIGl0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBOT1QgdXAgdG8gdGhl
IG5vZGUgdG8gZG8gb3Igbm90IHRvIGRvIHNvbWV0aGluZy4gSXQgZG9lcyBub3QgbWVhbiB0aGF0
IGl0IGlzIG9ubHkgYW4gaW1wbGVtZW50YXRpb24gb3B0aW9uLg0KRm9yIGluc3RhbmNlLCBvdmVy
IGEgZ2l2ZW4gaW50ZXJmYWNlLCB0aGUgcmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkgdGhh
dCBzb21lIHN0YXRlcyBhcmUgbWFpbnRhaW5lZCBieSB0aGUgc2VydmVyLiBBbmQgaXQgY291bGQg
YmUgZGVjaWRlZCB0byBhZGQgc29tZSBvdmVybG9hZCByZWxhdGVkIGluZm8gaW4gc3VjaCBzdGF0
ZXMuIEZvciBpbnN0YW5jZSBhZ2FpbiwgdGhlIG5vZGUgY2FuIHVzZSB0aGlzIHN0YXRlIHRvIGtu
b3cgaWYgYSByZW1vdGUgbm9kZSBoYXZlIGJlZW4gbm90aWZpZWQgb3Igbm90IGZvciBpbnN0YW5j
ZS4gQW5kIGluIHN1Y2ggYSBjYXNlLCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaW5jbHVk
ZSBhbiBPTFIgaW4gZWFjaCBtZXNzYWdlLiBJdCBpcyBqdXN0IGZvciBpbGx1c3RyYXRpb24uIFRo
ZSBwb2ludCBpcyB0aGF0IHlvdSBtYXkgaGF2ZSBzb21lIGNhc2VzIGZvciB3aGljaCB0aGUgT0xS
IGluIGV2ZXJ5IGFuc3dlciBtaWdodCBub3QgYmUgcmVxdWlyZWQuDQoNCkkgYWdyZWUgdGhhdCBo
YXZpbmcgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgaXMgZmluZeKApiBidXQgaXQgc2hvdWxkIGJl
IG5vdCBtYW5kYXRvcnkgaW4gYWxsIGNhc2VzIEkgdGhpbmsuIFNvIE9LIGZvciBhICJTSE9VTEQi
IG9yICJSRUNPTU1FTkRFRCIuDQoNClJlZ2FyZHMsDQoNCkxpb25lbA0KDQpEZSA6IERpTUUgW21h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgU3RldmUgRG9ub3Zhbg0K
RW52b3nDqSA6IGx1bmRpIDEwIGbDqXZyaWVyIDIwMTQgMTc6MjENCsOAIDogZGltZUBpZXRmLm9y
ZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgYWdyZWUgd2l0aCBib3RoIE1hcmlhIENy
dXogYW5kIE5pcmF2LiA6LSkNCg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNheWlu
ZyB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVw
b3J0IGluIGFsbCByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5IE1h
cmlhIENydXouDQoNCkkgYWxzbyBzdWdnZXN0IHRoYXQgd2UgaW5jbHVkZSBOaXJhdidzIHByb3Bv
c2FsIHRoYXQgaWYgYSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBo
YXMgYWxyZWFkeSByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBtYXkgY2hvb3Nl
IHRvIG5vdCBzZW5kIGl0IGFnYWluLiAgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGlu
ZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIGJ1dCB3ZSBzaG91
bGQgaW5jbHVkZSB3b3JkaW5nIGFib3V0IG5ldHdvcmtzIGFyY2hpdGVjdHVyZXMgdGhhdCBtYWtl
IGl0IGRpZmZpY3VsdCB0byBrbm93LiAgVGhlIGNhc2Ugb2YgYWdlbnRzIGFjdGluZyBhcyByZWFj
dGluZyBub2RlcyBmb3Igbm9uIHN1cHBvcnRpbmcgY2xpZW50cyBiZWluZyBvbmUgZXhhbXBsZS4N
Cg0KV2UgYWxzbyBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSByZWNvbW1lbmRlZCBhcHByb2Fj
aCBpcyBub3QgcHJlY2x1ZGVkIGJ5IE5pcmF2J3MgcHJvcG9zYWwuDQoNCkkgcHJvcG9zZSB0aGUg
Zm9sbG93aW5nIG5vcm1hdGl2ZSB3b3JkaW5nLCB3aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5
IE1hcmlhIENydXoncyByZWFzb25zIGZvciByZWNvbW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQg
cmVwb3J0IGlzIGFsd2F5cyBpbmNsdWRlZC4NCg0KLS0tLS0NCg0KQSByZXBvcnRpbmcgbm9kZSBN
VVNUIGVuc3VyZSB0aGF0IGFsbCByZWFjdGluZyBub2RlcyByZWNlaXZlIG5ldyBvdmVybG9hZCBy
ZXBvcnRzLg0KDQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVk
ZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGlu
ZyBub2Rlcy4NCg0KTm90ZSAtIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgYWxzbyBpbmNsdWRlIHRo
ZSBvdmVybG9hZCByZXBvcnQgaW4gYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gbm9uIHJlYWN0aW5n
IG5vZGVzIGlmIHRoYXQgaXMgbW9yZSBlZmZpY2llbnQuICBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdp
bGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBv
cnQgRE9JQy4NCg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92
ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0
IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBv
cnQuDQoNCk5vdGUgLSB0aGUgb25seSBzdXJlIHdheSwgd2l0aG91dCBwcm9wcmlldGFyeSBtZWNo
YW5pc21zLCB0byBrbm93IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCBhbiBvdmVy
bG9hZCByZXBvcnQgaXMgd2hlbiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIGNsaWVudCBhbmQgdGhl
cmUgaXMgbm8gYWdlbnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUu
DQpPbiAyLzEwLzE0IDM6NTIgQU0sIE1hcmlhIENydXogQmFydG9sb21lIHdyb3RlOg0KDQpIZWxs
byBOaXJhdiwNCg0KDQoNCkFueSBzb2x1dGlvbiBzaG91bGQgYmFsYW5jZSBkaWZmZXJlbnQgZmFj
dG9ycywgZWZmaWNpZW5jeSBjb3VsZCBiZSBkaXNjdXNzZWQgZnJvbSBkaWZmZXJlbnQgcGVyc3Bl
Y3RpdmVzLCBidXQgZmlyc3Qgd2UgbmVlZCB0byBhc3N1cmUgdGhlIG1lY2hhbmlzbSB3ZSBhcmUg
ZGVmaW5pbmcgaXMgcHJvdmlkaW5nIHZhbGlkIE9MUiB0byByZWFjdGluZyBub2Rlcy4NCg0KDQoN
CllvdXIgcHJvcG9zZWQgdGV4dA0KDQoiIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUu
Zy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCBy
ZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9y
dGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVx
dWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQoNCg0KDQpJZiB0aGUg
cmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3aGV0aGVyIG9yIG5vdCBvdmVybG9hZCByZXBv
cnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIGFuZCBpdCBkZWNpZGVzIChzaW5j
ZSBpdCBpcyBhICJtYXkiKSB0byBkbyBub3Qgc2VuZCB0aGUgT0xSIGFnYWluLCB0aGVuIG92ZXJs
b2FkIG1pdGlnYXRpb24gbWVjaGFuaXNtIHdpbGwgbm90IHdvcmsgaW4gY2FzZSBPTFIgd2FzIG5v
dCBwcm9wZXJseSByZWNlaXZlZCBieSBjb3JyZXNwb25kaW5nIHBvdGVudGlhbCByZWFjdGluZyBu
b2Rlcy4gQW5kIHdlIG5lZWQgdG8gbm90ZSB0aGF0ICJyZWFjdGluZyBub2RlcyIgY291bGQgYmUg
bm90IG9ubHkgdGhlIGNsaWVudCwgYnV0IEFOWSBhZ2VudCB1c2VkIGZvciByb3V0aW5nIChub3Qg
b25seSB3aGVuIHRoZSBhZ2VudCBpcyBwcm92aWRpbmcgc2VydmljZSB0byBhIFJlYWxtLCBidXQg
d2hlbiBpdCBpcyByZWFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQp
Lg0KDQpUaGVuLCBvbiBvbmUgaGFuZCBpdCBpcyBub3Qgc2ltcGxlIHRvIGtub3cgd2hlbiByZWFj
dGluZyBub2RlcyBoYXZlIHZhbGlkIE9MUiBpbmZvIChhcyBleHBsYWluZWQgYmVsb3cpLCBidXQg
aWYgT0xSIGlzIG5vdCBzZW50IGFnYWluIChhcyBwZXIgeW91ciBwcm9wb3NlZCAibWF5IikgdGhl
biBvbmUgb3IgbXVsdGlwbGUgcmVhY3Rpbmcgbm9kZXMgZG8gbm90IGhhdmUgdGhlIHJlcXVpcmVk
IE9MUiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIHdpbGwgbm90IHdvcmsuDQoNCg0KDQpUaGVy
ZWZvcmUsIGluIG15IG9waW5pb24sIHRoZSBzaW1wbGVzdCB3YXkgdG8gcHJvdmlkZSByZXF1aXJl
ZCBpbmZvcm1hdGlvbiBpcyB0byBwcm92aWRlIE9MUiBpbiBBTEwgYW5zd2Vycy4NCg0KDQoNCkJl
c3QgcmVnYXJkcw0KDQovTUNydXoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN
CkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NCg0K
U2VudDogbHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo0Mg0KDQpUbzogTWFyaWEgQ3J1
eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1Ympl
Y3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQoNCg0KQnV0IE1hcmlhLUNydXosDQoNCg0KDQpIb3cgY2FuIHdlIHNheSB0aGF0ICJpbmNsdWRp
bmcgdGhlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcyBpcyBzaW1wbGUgYW5kIGVmZmlj
aWVudD8iDQoNCkl0IGlzIHNpbXBsZSBmb3Igc3VyZSBidXQgbm90IGVmZmljaWVudC4NCg0KDQoN
CkEgc2xpZ2h0bHkgZGlmZmVyZW50IHdvcmRpbmcgZnJvbSB3aGF0IEkgcHJvcG9zZWQgZWFybGll
ciBpcywgV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaGFzIGEgbmV3IG92ZXJsb2FkIHJlcG9ydCB0
aGF0IG5lZWRzIHRvIGJlIHByb3ZpZGVkIHRvIGEgcmVhY3Rpbmcgbm9kZSAoYnkgdXBkYXRpbmcg
dGhlIGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVwb3J0IG9yIGJ5IHByb3ZpZGluZyB0aGUg
b3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUgZmlyc3QgdGltZSksIGl0IHNoYWxsIGluY2x1ZGUgT0xS
IGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQt
RmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRk
aXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBp
cyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRv
IHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9M
UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNCg0KU2VudDogTW9uZGF5LCBG
ZWJydWFyeSAxMCwgMjAxNCAzOjAzIFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1l
QGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk5pcmF2LCBhbGwsDQoNCg0KDQpJIHRoaW5rIHdlIHNo
b3VsZCBkZWZpbmUgYW4gYWNjdXJhdGUgYW5kIHJvYnVzdCBzb2x1dGlvbiwgYXMgZWZmaWNpZW50
IGFuZCBzaW1wbGUgYXMgcG9zc2libGUuDQoNCkkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFz
IGEgcHVyZSAibWF5IiwgYnV0IGxlYXZpbmcgaXQgdXAgdG8gaW1wbGVtZW50YXRpb24gZG9lcyBu
b3QgYXNzdXJlIHJlYWN0aW5nIG5vZGUgaGFzIHZhbGlkIE9MUiBpbmZvcm1hdGlvbiwgd2hhdCBp
cyBiYXNpYyBmb3IgdGhpcyBtZWNoYW5pc20gdG8gd29yay4NCg0KDQoNCkJlc3QgcmVnYXJkcw0K
DQovTUNydXoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IE5pcmF2
IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NCg0KU2VudDogbHVuZXMs
IDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxMDoxMg0KDQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7
IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTWFyaWEt
Q3J1eiwNCg0KDQoNCkkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ugb24gInNlbmRpbmcgT0xSIGluIEFM
TCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzIi4NCg0KQW5kIHdlIGFyZSBu
b3QgdHJ5aW5nIHRvIHByZXZlbnQgaXQgLSBhdCBsZWFzdCB0aGF0IGlzIG15IGludGVudGlvbi4N
Cg0KQnV0IHRoZSBtYWluIHF1ZXN0aW9uIGlzLCBhcmUgd2UgdHJ5aW5nIHRvIHByZXZlbnQgYW55
IG90aGVyIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uLCB3aGljaCBtYXkgYmUgc21hcnRlciBhbmQg
Y2FuIGF2b2lkIGluY2x1ZGluZyByZWR1bmRhbnQgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3Nh
Z2U/DQoNCg0KDQpNb3N0IHByb2JhYmx5LCB0aGUgdmVyeSBmaXJzdCBpbXBsZW1lbnRhdGlvbiBv
ZiBvdmVybG9hZCBjb250cm9sIHdpbGwgaW5jbHVkZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVz
c2FnZXMuDQoNCkJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJlc3RyaWN0
IHRoZSBkZXZlbG9wZXJzIHdoaWNoIGNhbiBjb21lIHVwIHdpdGggc29tZSBuaWNlIHR3ZWFrcyBh
bmQgdHJpY2tzIHRvIGF2b2lkIHNlbmRpbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gZXZlcnkg
bWVzc2FnZS4gQW5kIHRoaXMgaXMgd2hlcmUgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGFuZCBhdm9p
ZCBwdXR0aW5nIHN1Y2ggcmVzdHJpY3Rpb25zIGluIHByb3RvY29sIGRlZmluaXRpb24uDQoNCldo
YXQgZG8geW91IHRoaW5rPw0KDQoNCg0KVGhpcyBhbHNvIHRoZSByZWFzb24gSSB3YXMgc3VnZ2Vz
dGluZyBsb29zZSBkZXNjcmlwdGlvbiBvZiB3aGVuIHRvIGluY2x1ZGUgT0xSIChmcm9tIHRoZSBy
ZXBvcnRpbmcgbm9kZSBwb2ludCBvZiB2aWV3KS4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0K
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQoN
ClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDcsIDIwMTQgODo1NyBQTQ0KDQpUbzogZGltZUBpZXRm
Lm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpIZWxsbyBVbHJpY2gsIE5p
cmF2LA0KDQoNCg0KSSBhZ3JlZSB3aXRoIFVscmljaCB0aGF0IHRoZSB0ZXh0IHByb3ZpZGVkIGJ5
IE5pcmF2IGlzIGp1c3QgYSBNQVksIGFuZCB3aGV0aGVyIG9yIG5vdCB0aGUgc2VydmVyIHNlbmRz
IGFuIE9MUiBpbiBhbGwgYW5zd2VycyBzaGFsbCBub3QgYmUganVzdCBhIE1BWS4NCg0KDQoNCk9u
IHRoZSBvdGhlciBoYW5kLCBjcml0ZXJpYSBwcm92aWRlZCBieSBVbHJpY2ggb24gd2hlbiBPTFIg
aGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMgdGhlIHNlcnZlciBoYXMgc29tZSBrbm93bGVkZ2U6DQoN
CmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBh
bHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0KDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90
IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0
aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGly
ZQ0KDQpjKSBvdGhlcndpc2UNCg0KDQoNClJlcG9ydGluZyBub2RlIG11c3QgaGF2ZSBzb21lIGtu
b3dsZWRnZSBhYm91dCBPTFIgcmVjZXB0aW9uL3N0YXR1cyBpbiByZWFjdGluZyBub2RlLiBIb3cg
ZG9lcyBzZXJ2ZXIgYWNxdWlyZSB0aGlzIGtub3dsZWRnZT8NCg0KVGFrZSBpbnRvIGFjY291bnQg
YXMgd2VsbCB0aGF0IGEgInJlYWN0aW5nIiBub2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChpbiBj
YXNlIGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8gYSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxmIG9m
IGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KSAgYW5kIGEgQ2xpZW50LiBJbiB0aGUgY2FzZSBvZiBB
Z2VudHMsIGluIGZhY3QgdGhlIFNlcnZlciBtYXkgbm90IGV2ZW4ga25vdyBpZiB0aGlzIGlzIGdv
aW5nIHRvIGFjdCBhcyBhIHJlYWN0aW5nIG5vZGUgb3IganVzdCB0cmFuc3BhcmVudGx5LCBpbiBm
YWN0LCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaGF2ZSBhbnkga25vd2xlZGdlIGFib3V0
IHdoYXQgYWdlbnRzIGluIHRoZSBjaGFpbiB0byB0aGUgZmluYWwgQ2xpZW50Lg0KDQoNCg0KVGhl
cmVmb3JlLCBJIGRlZmluaXRlbHkgdGhpbmsgdGhhdCBzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2Vy
cyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlczoNCg0KLSBzdGF0ZS1sZXNzIGltcGxlbWVu
dGF0aW9uICh0cmFuc2FjdGlvbiBvciBzZXNzaW9uKSBpcyBzaW1wbGVyLA0KDQotIHRoZSBzZXJ2
ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gc2VuZCBhbiBP
TCB0byBhIHJlYWN0aW5nIG5vZGUNCg0KLSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gYm90
aGVyIHdoZXRoZXIgYW4gcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBPTFIg
b3Igd2hldGhlciB0aGlzIE9MUiBpcyBzdGlsbCB2YWxpZCAoaGFzIG5vdCBleHBpcmVkKS4NCg0K
LSBzZW5kaW5nIGFuIGFkZGl0aW9uYWwgQVZQIGlzIG5vdCBwcm9jZXNzaW5nIGNvbnN1bWluZywg
aW4gY29tcGFyaXNvbiB3aXRoIHJlcXVpcmVkIGFib3ZlIGNoZWNrcyAoaWYgdGhpcyBpcyBub3Qg
c2VudCkuDQoNCiAgSW4gZmFjdCwgaW4gYW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVz
dCBhbmQgbGVhc3QgY29tcGxleCBpcyB0byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZm
ZWN0ZWQvYXBwbGljYWJsZSBub2RlcywNCg0KICBhbmQgdGhlIGxhdHRlciBzaG91bGQgdGFrZSBj
YXJlIHRvIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9ucw0KDQotIG1vcmUgcm9idXN0IHNvbHV0aW9u
LCBhcyBubyBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhlIGNoZWNrcyBvbiB0aGUgbmVlZCB0byBz
ZW5kIGluZm9ybWF0aW9uLCAgZm9yIHNpdHVhdGlvbnMgd2hlcmUgYW4gYW5zd2VyIG1lc3NhZ2Ug
aXMgbG9zdCwgIOKApg0KDQoNCg0KDQoNCkJlc3QgcmVnYXJkcw0KDQovTUNydXoNCg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gp
DQoNClNlbnQ6IHZpZXJuZXMsIDA3IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo1OQ0KDQpUbzogZXh0
IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0
bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRm
Lm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpOaXJhdiwNCg0KDQoNCkkn
bSBhZnJhaWQgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlv
bi4NCg0KDQoNCiJ3aGVuIGl0IHdhbnRzIHRvIHByb3ZpZGUvdXBkYXRlLi4uLml0IHNoYWxsIGlu
Y2x1ZGUuLi4iIHRyYW5zbGF0ZXMgdG8gIi4uLml0IG1heSBpbmNsdWRlLi4uIi4NCg0KDQoNCiJp
biBvdGhlciBjYXNlcyIgaW4gdGhlIGdpdmVuIGNvbnRleHQgdHJhbnNsYXRlcyB0byAid2hlbiBp
dCBkb2VzIG5vdCB3YW50IHRvIHByb3ZpZGUvdXBkYXRlLi4uIg0KDQoNCg0KDQoNCldlIGhhdmUg
dGhlIGZvbGxvd2luZyBjYXNlczoNCg0KYSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQoNCmIpIHRo
ZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEg
dGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBP
TFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlDQoNCmMpIG90aGVyd2lzZQ0KDQoNCg0KaW4gY2FzZSBh
KSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFIgaW4gY2Fz
ZSBiKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUgcmVhY3Rp
bmcgbm9kZSB3aXRoIHRoZSBsYXRlc3QgT0xSIGluIGNhc2UgYykgdGhlIHJlcG9ydGluZyBub2Rl
IE1VU1QgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcgbm9kZSBk
b2VzIG5vdCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIHJlcGxheSBvciBhbiB1cGRhdGUpDQoNCg0K
DQpVbHJpY2gNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBl
eHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KDQpTZW50
OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgNDo0OSBQTQ0KDQpUbzogV2llaGUsIFVscmlj
aCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5v
cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KVWxyaWNoLA0KDQoNCg0KSXQg
c2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3
b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC4NCg0KSG93IGFib3V0IHRoZSBmb2xsb3dpbmcu
DQoNCg0KDQpXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVy
bG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJs
b2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIg
aW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRp
dGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlz
IG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8g
dGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xS
IGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQt
RmVhdHVyZSBBVlAuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkg
W21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5
IDA2LCAyMDE0IDM6NTcgUE0NCg0KVG86IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQg
U3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3Vi
amVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQoNCg0KDQpOaXJhdiwgTGlvbmVsLA0KDQoNCg0KSSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNv
bmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQg
YnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzoNCg0KDQoNCjInLiB0aGUgcmVwb3J0aW5nIG5v
ZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0
byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBh
biBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rp
bmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgcmVhc29uYWJsZSBvdmVybG9hZCBjb250cm9sIGluZm9y
bWF0aW9uIChlLmcuIHRoZSBsYXRlc3QgT0xSLCB3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3Rp
bmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIiwg
b3IgYW4gb2xkICBidXQgc29vbiBleHBpcmluZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg
aXMgbm90IG92ZXJsb2FkZWQpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4u
KSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90
KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRh
aW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCg0KDQpJIGRvbid0IGFncmVlIHdp
dGggTGlvbmVscyBkby13aGF0LXlvdS13YW50IGFwcHJvYWNoLiBPdmVybG9hZCBjb250cm9sIHdp
bGwgbm90IHdvcmsgd2hlbiB3ZSBhbGxvdyB0aGUgcmVwb3J0aW5nIG5vZGUgbm90IHRvIHVwZGF0
ZSByZWFjdGluZyBub2Rlcywgd2hpY2ggYXJlIG5vdCAoc3VmZmljaWFudGx5KSBhd2FyZSBvZiB0
aGUgY3VycmVudCBvdmVybG9hZCBzdGF0dXMsIHdpdGggdXAgdG8gZGF0ZSBPTFJzLg0KDQoNCg0K
VWxyaWNoDQoNCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206
IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbT4gW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dDQoNClNlbnQ6IFRodXJzZGF5
LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBBTQ0KDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7
IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1l
QGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtk
aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl
c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCg0KDQoNCg0KLS0t
LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNl
c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBOaXJhdiBTYWxvdCAobnNhbG90KSBFbnZvecOpIDog
amV1ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4IMOAIDogV2llaGUsIFVscmljaCAoTlNOIC0gREUv
TXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0
Zi5vcmc+IE9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCg0KDQpVbHJpY2gsDQoNCg0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNp
bmcgdGhpcyBiZWhhdmlvciBvbiByZXBvcnRpbmcgbm9kZSAib3RoZXJ3aXNlIChpLmUuIGlmIGl0
IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBv
dmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1
ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINCg0KVGhl
IHJlcG9ydGluZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQg
dGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9k
ZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy4NCg0KDQoNCltMTV0gQWdyZWUuIElu
IG90aGVyIHdvcmRzLCBpdCBpcyBub3QgZGVlbWVkIHJlcXVpcmVkIGZvciB0aGUgZGVmYXVsdCBt
ZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQuIEhvdyBhbmQgd2hlbiB0aGUgcmVwb3J0
aW5nIG5vZGUgZGVjaWRlcyB0byBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciBtYXkgZGVw
ZW5kIG9uIHRoZSBhcHBsaWNhdGlvbiBvciBvbiB0aGUgaW1wbGVtZW50YXRpb24uIEF0IGxlYXN0
LCBpdCBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuDQoNCg0KDQpBcyB3ZSBoYWQgZGlzY3Vz
c2VkIGVhcmxpZXIsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBl
eHBsaWNpdGx5IHN0b3AgdGhyb3R0bGluZyBhdCBlYWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNh
bWUgdGltZS4gSW4gb3RoZXIgd29yZHMsIHRoZSByZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhl
IG5hdHVyYWwgZXhwaXJ5IG9mIHRoZSBPTFIgdG8gZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhl
IHNpZ25hbGluZyB0cmFmZmljIHRvd2FyZHMgaXQuDQoNCg0KDQpbTE1dIEFncmVlDQoNCg0KDQpU
aGVyZSBtYXkgYmUgb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUga25v
d3MgdGhhdCB0aGUgbGFzdCBvdmVybG9hZCBzaXR1YXRpb24gZW5kZWQgbG9uZyB0aW1lIGJhY2sg
aW4gdGhlIHBhc3QsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGl0IHRvIGluY2x1ZGUgT0xSIGlmIGN1
cnJlbnRseSB0aGVyZSBpcyBubyBvdmVybG9hZCBjb25kaXRpb24uDQoNCg0KDQpbTE1dIEFncmVl
DQoNCg0KDQpSZXN0IG9mIHRoZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuDQoN
Cg0KDQpbTE1dIEFncmVlDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmlj
aCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1
YXJ5IDA2LCAyMDE0IDI6MjMgUE0NCg0KVG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBTYWxv
dCAobnNhbG90KTsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVj
dDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN
Cg0KDQpBY3R1YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmluY2lwbGVzOg0KDQoxLiBM
YWNrIG9mIE9MUiBtZWFucyAibm8gY2hhbmdlIg0KDQoyLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5v
IG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1
cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1T
dXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9k
ZSBhbHJlYWR5IGhhcyBnb3QgdGhlIGxhdGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBPTFIgcmVx
dWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3Zlcmxv
YWQiKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGlu
ZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4g
YW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3Vw
cG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KQ2FuIHBlb3BsZSBwbGVhc2UgY29uZmlybS4NCg0K
DQoNClVscmljaA0KDQoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVi
cnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0KDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVA
aWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KQWdyZWVkLiAgVG8g
cmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhl
IGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUgZm9yIHRoZSBob3N0IG9yIHJlYWxtLiAgSWYgdGhlcmUg
aXMgYSBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IGNvbnRpbnVlcyB0
byBhcHBseSB1bnRpbCBpdCBlaXRoZXIgdGltZXMgb3V0IG9yIGlzIGV4cGxpY2l0bHkgY2hhbmdl
ZCB3aXRoIGEgbmV3IG92ZXJsb2FkIHJlcG9ydC4gIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBh
Y3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1w
bGllcyB0aGVyZSBpcyBubyBvdmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQoNCg0K
U3RldmUNCg0KT24gMi81LzE0IDk6MTkgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0K
DQpJIGFncmVlIHdpdGggU3RldmUgZXhjZXB0IHRoZSBwYXJ0ICJzaG91bGRu4oCZdCBsYWNrIG9m
IE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD8iDQoNCg0KDQpXZSBoYWQgc29t
ZSBkaXNjdXNzaW9uIHNvbWV0aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhhdCBpdCBpcyByZWFzb25h
YmxlIHRvIG5vdCBtYW5kYXRlIHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5
IGFuc3dlciBtZXNzYWdlLiBFLmcuIHdoZW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9mIHRyYWNr
aW5nIHdoYXQgaXMgc2VudCB0byB3aGljaCBjbGllbnQgYW5kIGhlbmNlIHdhbnRzIHRvIGF2b2lk
IHNlbmRpbmcgaW5mb3JtYXRpb24gd2hpY2ggaXMgcmVkdW5kYW50LiBCdXQgdGhpcyBpcyBvcHRp
b25hbCBpbXBsZW1lbnRhdGlvbiBhbmQgYXQgdGhlIHNhbWUgdGltZSBuZWVkIG5vdCBiZSBwcm9o
aWJpdGVkIGZyb20gcHJvdG9jb2wgcG9pbnQgb2Ygdmlldy4NCg0KDQoNClNvIGJhc2ljYWxseSwg
dGhlIGxhY2sgb2YgT0xSIHNob3VsZCBub3QgYWZmZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVk
IE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4gVGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVl
IHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVyIE9MUiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxp
ZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUgZXhwbGljaXQgT0xSIHdpdGggIjAiIG92ZXJsb2FkLW1l
dHJpYyBpcyByZWNlaXZlZC4NCg0KSW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxl
IGltcGxlbWVudGF0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcg
b2YgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoN
Cg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgU3RldmUgRG9ub3Zhbg0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6
MDAgUE0NCg0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1Ympl
Y3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQoNCg0KaW5saW5lDQoNCk9uIDIvNS8xNCA3OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpIHdyb3RlOg0KDQpPayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5v
ZGVzIE1VU1QgaW5zZXJ0IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0
IGNvcnJlc3BvbmQgdG8gcmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBv
cnRlZC1GZWF0dXJlcyBBVlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0
ZWQpLg0KDQpTUkQ+IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT8gIFNob3VsZG4ndCBsYWNr
IG9mIGFuIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD8NCg0KDQoNCg0KDQoN
Cg0KDQoNCk90aGVyIGNyaXRlcmlhIGxpa2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0gdG8g
bWF0dGVyLg0KDQpTUkQ+IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5z
d2VyIGRvZXMgZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRl
ZCBub2RlIHRvIGxvb2sgZm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBl
dmVyeSBtZXNzYWdlIGlzIGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRp
YWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLg0KDQoNCg0KDQoNCg0KDQoN
Cg0KRm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBp
cyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0
IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4g
dGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBs
YXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNz
IGEgbmV3IE9MUj8NCg0KU1JEPiBUaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZXF1ZW5jZSBu
dW1iZXIuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KQ0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1
LCAyMDE0IDU6MjcgQU0NCg0KVG86IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlv
bmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9y
Zz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCg0KDQpJIHNoYXJlIHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLg0KDQoN
Cg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
DQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+
DQoNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDk6MDcgUE0NCg0KVG86IGRpbWVA
aWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSSB1bmRlcnN0YW5k
IHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VTIE5P
VCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuDQoNClNvIHRoZSBvcHRpb25zIHdvdWxk
IGJlOg0KDQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KDQoyLSBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgcmVxdWVzdCArIE9DLU9MUiBBVlAgaW4gc29tZSBh
bnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0aGUgY2xpZW50
IG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQoNCg0KDQpJZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJp
b24sIHRoZSBvcHRpb24gMSBzZWVtcyB0aGUgYmVzdCBhcHByb2FjaC4NCg0KDQoNCkxpb25lbA0K
DQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQoNCkRlIDogZGltZSBpc3N1ZSB0cmFj
a2VyIFttYWlsdG86dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddDQoNCkVudm95w6kgOiBt
YXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDkNCg0Kw4AgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4N
Cg0KQ2MgOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpPYmpldCA6IFtk
aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl
c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCiMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KIEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRl
ZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdGhhdCBpcyAgdG8gYmUgaW5j
bHVkZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0ICBzdXJ2aXZlZCBhIHRocm90dGxpbmcuIFRoaXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBT
ZXF1ZW5jZS1OdW1iZXINCg0KIChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdo
aWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXMNCg0KIHN1cnZpdmVkKSBpcyBwZXJmb3JtZWQu
IEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5kaWNhdGVzIHRoYXQgY3VycmVudGx5IG5vICB0aHJvdHRs
aW5nIGlzIHBlcmZvcm1lZC4gIFJlcG9ydGluZyBET0lDIGVuZHBvaW50cyBtYXkgdXNlIHRoaXMg
IGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCB0
byB1cGRhdGUgdGhlICByZWFjdGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIu
DQoNCiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0
aGUgbmVlZCBmb3IgdGhlICByZXBvcnRpbmcgbm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2
ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5nIERPSUMgIGVuZHBvaW50IGNhbm5vdCBrbm93IHdo
ZXRoZXIgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaXMgYWN0dWFsbHkgZG9pbmcgIHRoZSBy
aWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLg0KDQog
VGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1c3RuZXNzIGFzIGl0IGFsbG93cyB0
aGUgcmVwb3J0aW5nIERPSUMgIGVuZHBvaW50IHRvIGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJv
cHJpYXRlIHRocm90dGxpbmcgYnkgdGhlIHJlYWN0aW5nICBET0lDIGVuZHBvaW50IChjYXVzZWQg
Ynkgd2hhdGV2ZXIgcmVhc29uKS4NCg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gYWxzbyBhbGxv
d3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBSRkMgNzA2OC4NCg0KIEluIHN1bW1hcnkgaXQgaXMg
cHJvcG9zZWQgdG8gZGVmaW5lIHRoZSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdG8g
IGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4N
Cg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBp
ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2
ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn
aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj
b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy
IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp
cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1
ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg
cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs
c2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg
YmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk
IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl
IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFs
dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt
b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGlu
ZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1F
QGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWls
dG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5v
cmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u
dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0
IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll
cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy
ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly
ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl
cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0
ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm
YWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt
YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h
eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs
IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk
ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkg
YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi
ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl
bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu
ZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg
c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1
ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg
YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg
ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUg
cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs
c2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg
YmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs
ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJl
IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl
biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6
MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl
dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLlByZm9ybWF0SFRNTCwgbGkuUHJm
b3JtYXRIVE1MLCBkaXYuUHJmb3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0
w6kgSFRNTCI7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFy
Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNw
YW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBD
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1h
dMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnAuVGV4
dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7bXNvLXN0
eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1
bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj
b2xvcjpibGFjazt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRl
eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpz
cGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0
OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu
MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv
cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsLCBOaXJhdiwgYWxsLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+TWF5YmUgdGhlIG5vdGUgY291bGQgYmUgbW9kaWZpZWQ6PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KTm90ZSDigJN0aGUg
cmVhY3Rpbmcgbm9kZSBjb3VsZCBiZSBhbnkgYWdlbnQgaW4gdGhlIHBhdGgsIGFuZCB0aGF0IGlu
IHNvbWUgZXJyb3Igc2l0dWF0aW9ucyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQg
YnkgcmVhY3Rpbmcgbm9kZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90
OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkkgYWRkZWQgdGhlIGNhc2UgT0xSIGNvdWxkIGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rl
cywgc2luY2UgaXQgaGlnaGxpZ2h0cyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmVyIHdpbGwg
bm90IGtub3cgd2hldGhlciBvciBub3QgYSB2YWxpZCBPTFIgaXMgcmVjZWl2ZWQNCiBieSByZWFj
dGluZyBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gbGlvbmVsLm1v
cmFuZEBvcmFuZ2UuY29tIFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KPGJyPg0K
PGI+U2VudDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjM2PGJyPg0KPGI+
VG86PC9iPiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXQgbGVhc3QsIGl0IGlzIG5vdCAm
cXVvdDt0aGUgb25seSBzdXJlIHdheSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Rm9yIGluc3RhbmNlLCBzdWJzZXF1ZW50IG1lc3NhZ2VzIHBhcnQgb2YgdGhlIHNhbWUgc2Vz
c2lvbiAob3IgcHNldWRvLXNlc3Npb24pIGNvdWxkIGFsc28gYmUgdXNlZCBhcyBpbmRpY2F0aW9u
IGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdGhhdCB0aGUgT0xSIGhhcyBiZWVuDQogcmVjZWl2ZWQg
YnkgdGhlIHJlYWN0aW5nIG5vZGUgKGJlc2lkZXMgdGhlIHJlY2VwdGlvbiBvZiB0aGUgT0MtU3Vw
cG9ydGVkLUZlYXR1cmVzIGluIHRoZSByZXF1ZXN0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+SXQgaXMgd2h5IEkgd2FzIHNheWluZyB0aGF0IHRoaXMgY2FuIGJlIGZpeGVkIHBlciBh
cHBsaWNhdGlvbi9zeXN0ZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9i
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g
RGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBNYXJpYSBDcnV6IEJh
cnRvbG9tZTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJkaSAxMSBmw6l2cmllciAyMDE0
IDExOjMxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9y
ZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG
UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpbmUgTmlyYXYsIEkgYWdy
ZWUgdGhpcyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+TXkgaW50ZW50aW9uIGlzIHRoYXQgYW55IHJlYWRlciByZWFsaXplcyB3aGF0IHRo
aXMga25vd2xlZGdlIGluIHRoZSBzZXJ2ZXIgaW1wbGllcyB3aGVuIHdlIHRhbGsgYWJvdXQgYWdl
bnRzIGluIHRoZSBwYXRoLiBUaGlzIGlzIHdoeSBJIHRoaW5rIHRoaXMgbm90ZSBpcyBoZWxwZnVs
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vTUNydXo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE
RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gTmly
YXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0bzpuc2Fsb3RAY2lzY28uY29tIj5tYWls
dG86bnNhbG90QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gbWFydGVzLCAxMSBk
ZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjY8YnI+DQo8Yj5Ubzo8L2I+IE1hcmlhIENydXogQmFydG9s
b21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkkgZG8gbm90IGFn
cmVlIHJlZ2FyZGluZyB0aGUgY29tcGxleGl0eSBzaW5jZSBpdCBpcyBoaWdobHkgaW1wbGVtZW50
YXRpb24gc3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkxldHMgbm90IG1h
a2UgYW55IGFzc3VtcHRpb24gaW4gdGhlIHByb3RvY29sIGRlc2lnbi48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlZ2Fy
ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9h
Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFyaWEgQ3J1eiBCYXJ0b2xvbWU8YnI+DQo8Yj5TZW50
OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMTQgMzo1NCBQTTxicj4NCjxiPlRvOjwvYj4g
PGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGhpZ2hsaWdodCBjb21wbGV4aXR5IGZvciB0aGUg
c2VydmVyIHRvICZuYnNwO+KAnDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5ndWFyYW50ZWUgdGhhdCB0
aGUgcmVhY3Rpbmcgbm9kZQ0KIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBv
cnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0N
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoaXMgaXMgdGhlIHB1cnBv
c2Ugb2YgdGhlIHNlbnRlbmNlIGFkZGVkIGJ5IFN0ZXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9u
IEJlaGFsZiBPZiA8L2I+TmlyYXYgU2Fsb3QgKG5zYWxvdCk8YnI+DQo8Yj5TZW50OjwvYj4gbWFy
dGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjA8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9
Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bTwvYT47IFN0ZXZlIERvbm92YW47DQo8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGlt
ZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
NDQwNjEiPkkgYW0gYWxzbyBmaW5lIHdpdGggU3RldmUncyBwcm9wb3NlZCB3b3JkaW5nIHRvIHJl
Y29tbWVuZCB0aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQgdG8gbm90IG1hbmRhdGUgaXQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj5JIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBmb2xsb3dpbmcgdGV4dCwgaWYgaXQgaXMgYWJz
b2x1dGVseSBuZWNlc3NhcnkgdG8gYWRkIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk5vdGUgLSB0aGUgb25seSBzdXJlIHdheSwg
d2l0aG91dCBwcm9wcmlldGFyeSBtZWNoYW5pc21zLCB0byBrbm93IHRoYXQgYSByZWFjdGluZyBu
b2RlIGhhcyByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBvcnQgaXMgd2hlbiB0aGUgcmVhY3Rpbmcg
bm9kZSBpcyBhIGNsaWVudCBhbmQgdGhlcmUgaXMgbm8gYWdlbnQgYmV0d2Vlbg0KIHRoZSBjbGll
bnQgYW5kIHRoZSByZXBvcnRpbmcgbm9kZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBwcmVmZXIgdG8gcmVtb3ZlIGl0IHNpbmNl
IEkgZG8gbm90IHNlZSBhcyB2YWx1ZSBhZGRpdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
NDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+
T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
Ij5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg
RmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+IFN0ZXZlIERvbm92YW47
IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSdtIGZpbmUgd2l0aCBh
IHJlY29tbWVuZGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IEkgaGF2ZSBhIGdlbmVyYWwgY29tbWVudDog
d2hlbiBhIE1BWSBvciBldmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQg
aXQgaXMgTk9UIHVwIHRvIHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0byBkbyBzb21ldGhpbmcuIEl0
IGRvZXMgbm90IG1lYW4NCiB0aGF0IGl0IGlzIG9ubHkgYW4gaW1wbGVtZW50YXRpb24gb3B0aW9u
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIG92ZXIgYSBnaXZl
biBpbnRlcmZhY2UsIHRoZSByZWxhdGVkIHNwZWNpZmljYXRpb24gY2FuIHNheSB0aGF0IHNvbWUg
c3RhdGVzIGFyZSBtYWludGFpbmVkIGJ5IHRoZSBzZXJ2ZXIuIEFuZCBpdCBjb3VsZCBiZSBkZWNp
ZGVkIHRvIGFkZCBzb21lIG92ZXJsb2FkDQogcmVsYXRlZCBpbmZvIGluIHN1Y2ggc3RhdGVzLiBG
b3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0byBrbm93IGlm
IGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5zdGFuY2UuIEFu
ZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGluY2x1ZGUgYW4g
T0xSIGluIGVhY2ggbWVzc2FnZS4gSXQgaXMganVzdCBmb3IgaWxsdXN0cmF0aW9uLiBUaGUgcG9p
bnQNCiBpcyB0aGF0IHlvdSBtYXkgaGF2ZSBzb21lIGNhc2VzIGZvciB3aGljaCB0aGUgT0xSIGlu
IGV2ZXJ5IGFuc3dlciBtaWdodCBub3QgYmUgcmVxdWlyZWQuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRo
YXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIGlzIGZpbmXigKYgYnV0IGl0IHNob3Vs
ZCBiZSBub3QgbWFuZGF0b3J5IGluIGFsbCBjYXNlcyBJIHRoaW5rLiBTbyBPSyBmb3IgYSAmcXVv
dDtTSE9VTEQmcXVvdDsgb3IgJnF1b3Q7UkVDT01NRU5ERUQmcXVvdDsuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdh
cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+TGlvbmVsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOndpbmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEg
cGFydCBkZTwvYj4gU3RldmUgRG9ub3Zhbjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5k
aSAxMCBmw6l2cmllciAyMDE0IDE3OjIxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiA8YSBocmVmPSJt
YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmo8L2I+PC9z
cGFuPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0
ZXh0Ij5ldCZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvDQogQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PHNwYW4gbGFuZz0iRlIiPkkgYWdyZWUgd2l0aCBib3RoIE1hcmlhIENydXogYW5kIE5p
cmF2LiA6LSk8YnI+DQo8YnI+DQpJIHN1Z2dlc3QgdGhhdCB3ZSBoYXZlIHdvcmRpbmcgc2F5aW5n
IHRoZSByZWNvbW1lbmRlZCBhcHByb2FjaCBpcyB0byBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBv
cnQgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQgYnkgTWFy
aWEgQ3J1ei4mbmJzcDsNCjxicj4NCjxicj4NCkkgYWxzbyBzdWdnZXN0IHRoYXQgd2UgaW5jbHVk
ZSBOaXJhdidzIHByb3Bvc2FsIHRoYXQgaWYgYSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IGEg
cmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBvcnQgdGhl
biBpdCBtYXkgY2hvb3NlIHRvIG5vdCBzZW5kIGl0IGFnYWluLiZuYnNwOyBJIGRvbid0IHRoaW5r
IHdlIG5lZWQgdG8gaW5jbHVkaW5nIGFueXRoaW5nIGFib3V0IGhvdyB0aGUgcmVwb3J0aW5nIG5v
ZGUga25vd3MNCiBidXQgd2Ugc2hvdWxkIGluY2x1ZGUgd29yZGluZyBhYm91dCBuZXR3b3JrcyBh
cmNoaXRlY3R1cmVzIHRoYXQgbWFrZSBpdCBkaWZmaWN1bHQgdG8ga25vdy4mbmJzcDsgVGhlIGNh
c2Ugb2YgYWdlbnRzIGFjdGluZyBhcyByZWFjdGluZyBub2RlcyBmb3Igbm9uIHN1cHBvcnRpbmcg
Y2xpZW50cyBiZWluZyBvbmUgZXhhbXBsZS48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90
OyI+V2UgYWxzbyBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSByZWNvbW1lbmRlZCBhcHByb2Fj
aCBpcyBub3QgcHJlY2x1ZGVkIGJ5IE5pcmF2J3MgcHJvcG9zYWwuPGJyPg0KPGJyPg0KSSBwcm9w
b3NlIHRoZSBmb2xsb3dpbmcgbm9ybWF0aXZlIHdvcmRpbmcsIHdoaWNoIGNhbiBiZSBzdXBwbGVt
ZW50ZWQgYnkgTWFyaWEgQ3J1eidzIHJlYXNvbnMgZm9yIHJlY29tbWVuZGluZyB0aGF0IHRoZSBv
dmVybG9hZCByZXBvcnQgaXMgYWx3YXlzIGluY2x1ZGVkLjxicj4NCjxicj4NCi0tLS0tPGJyPg0K
PGJyPg0KQSByZXBvcnRpbmcgbm9kZSBNVVNUIGVuc3VyZSB0aGF0IGFsbCByZWFjdGluZyBub2Rl
cyByZWNlaXZlIG5ldyBvdmVybG9hZCByZXBvcnRzLjxicj4NCjxicj4NCkl0IGlzIHJlY29tbWVu
ZGVkIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxs
IGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIHJlYWN0aW5nIG5vZGVzLiZuYnNwOw0KPGJyPg0KPGJy
Pg0KTm90ZSAtIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgYWxzbyBpbmNsdWRlIHRoZSBvdmVybG9h
ZCByZXBvcnQgaW4gYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gbm9uIHJlYWN0aW5nIG5vZGVzIGlm
IHRoYXQgaXMgbW9yZSBlZmZpY2llbnQuJm5ic3A7IFRoZSBvdmVybG9hZCByZXBvcnQgd2lsbCBq
dXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBE
T0lDLjxicj4NCjxicj4NCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBh
biBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUg
dGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQg
cmVwb3J0Ljxicj4NCjxicj4NCk5vdGUgLSB0aGUgb25seSBzdXJlIHdheSwgd2l0aG91dCBwcm9w
cmlldGFyeSBtZWNoYW5pc21zLCB0byBrbm93IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyByZWNl
aXZlZCBhbiBvdmVybG9hZCByZXBvcnQgaXMgd2hlbiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIGNs
aWVudCBhbmQgdGhlcmUgaXMgbm8gYWdlbnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVw
b3J0aW5nIG5vZGUuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPk9uIDIvMTAvMTQg
Mzo1MiBBTSwgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IZWxsbyBOaXJhdiw8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Bbnkgc29sdXRpb24g
c2hvdWxkIGJhbGFuY2UgZGlmZmVyZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291bGQgYmUgZGlz
Y3Vzc2VkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQgdG8g
YXNzdXJlIHRoZSBtZWNoYW5pc20gd2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGluZyB2YWxpZCBP
TFIgdG8gcmVhY3Rpbmcgbm9kZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+WW91ciBwcm9wb3NlZCB0ZXh0Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90OyBBZGRpdGlvbmFsbHksIGlu
IG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBp
ZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5n
IG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNw
b25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAu
JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
SWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3Zlcmxv
YWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRl
cyAoc2luY2UgaXQgaXMgYSAmcXVvdDttYXkmcXVvdDspIHRvIGRvIG5vdCBzZW5kIHRoZSBPTFIg
YWdhaW4sIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlvbiBtZWNoYW5pc20gd2lsbCBub3Qgd29yayBp
biBjYXNlIE9MUiB3YXMgbm90IHByb3Blcmx5IHJlY2VpdmVkIGJ5IGNvcnJlc3BvbmRpbmcgcG90
ZW50aWFsIHJlYWN0aW5nIG5vZGVzLiBBbmQgd2UgbmVlZCB0byBub3RlIHRoYXQgJnF1b3Q7cmVh
Y3Rpbmcgbm9kZXMmcXVvdDsgY291bGQgYmUgbm90IG9ubHkgdGhlIGNsaWVudCwgYnV0IEFOWSBh
Z2VudCB1c2VkIGZvciByb3V0aW5nIChub3Qgb25seSB3aGVuIHRoZSBhZ2VudCBpcyBwcm92aWRp
bmcgc2VydmljZSB0byBhIFJlYWxtLCBidXQgd2hlbiBpdCBpcyByZWFjdGluZyBvbiBiZWhhbGYg
b2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVuLCBvbiBvbmUgaGFuZCBpdCBpcyBub3Qgc2ltcGxl
IHRvIGtub3cgd2hlbiByZWFjdGluZyBub2RlcyBoYXZlIHZhbGlkIE9MUiBpbmZvIChhcyBleHBs
YWluZWQgYmVsb3cpLCBidXQgaWYgT0xSIGlzIG5vdCBzZW50IGFnYWluIChhcyBwZXIgeW91ciBw
cm9wb3NlZCAmcXVvdDttYXkmcXVvdDspIHRoZW4gb25lIG9yIG11bHRpcGxlIHJlYWN0aW5nIG5v
ZGVzIGRvIG5vdCBoYXZlIHRoZSByZXF1aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlv
biB3aWxsIG5vdCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlRoZXJlZm9yZSwgaW4gbXkgb3BpbmlvbiwgdGhlIHNpbXBsZXN0IHdheSB0byBw
cm92aWRlIHJlcXVpcmVkIGluZm9ybWF0aW9uIGlzIHRvIHByb3ZpZGUgT0xSIGluIEFMTCBhbnN3
ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJl
c3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhy
ZWY9Im1haWx0bzpuc2Fsb3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5d
IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6
IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDI8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJFOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJ1dCBNYXJpYS1DcnV6LDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhvdyBjYW4gd2Ug
c2F5IHRoYXQgJnF1b3Q7aW5jbHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2Fn
ZXMgaXMgc2ltcGxlIGFuZCBlZmZpY2llbnQ/JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1dCBub3Qg
ZWZmaWNpZW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5BIHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVh
cmxpZXIgaXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBv
cnQgdGhhdCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0
aW5nIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcg
dGhlIG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRl
IE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9y
dGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUu
IEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5v
ZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRl
ZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRo
ZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwv
YT5dIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAs
IDIwMTQgMzowMyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlRvOiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJq
ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdiwg
YWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkg
dGhpbmsgd2Ugc2hvdWxkIGRlZmluZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0IHNvbHV0aW9uLCBh
cyBlZmZpY2llbnQgYW5kIHNpbXBsZSBhcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBh
cyBhIHB1cmUgJnF1b3Q7bWF5JnF1b3Q7LCBidXQgbGVhdmluZyBpdCB1cCB0byBpbXBsZW1lbnRh
dGlvbiBkb2VzIG5vdCBhc3N1cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQgT0xSIGluZm9ybWF0
aW9uLCB3aGF0IGlzIGJhc2ljIGZvciB0aGlzIG1lY2hhbmlzbSB0byB3b3JrLiA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZXN0IHJlZ2FyZHM8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4vTUNydXo8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNh
bG90QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IGx1bmVzLCAxMCBkZSBm
ZWJyZXJvIGRlIDIwMTQgMTA6MTI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5UbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1haWx0bzpk
aW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPk1hcmlhLUNydXosPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBmdWxseSBhZ3JlZSB3aXRoIHlvdSBvbiAmcXVv
dDtzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdl
cyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5BbmQgd2UgYXJlIG5vdCB0cnlpbmcgdG8gcHJldmVudCBpdCAtIGF0IGxlYXN0IHRoYXQgaXMg
bXkgaW50ZW50aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5CdXQgdGhlIG1haW4gcXVlc3Rpb24gaXMsIGFyZSB3ZSB0cnlpbmcgdG8gcHJldmVu
dCBhbnkgb3RoZXIgcG9zc2libGUgaW1wbGVtZW50YXRpb24sIHdoaWNoIG1heSBiZSBzbWFydGVy
IGFuZCBjYW4gYXZvaWQgaW5jbHVkaW5nIHJlZHVuZGFudCBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIg
bWVzc2FnZT88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5Nb3N0IHByb2JhYmx5LCB0aGUgdmVyeSBmaXJzdCBpbXBsZW1lbnRhdGlvbiBvZiBvdmVybG9h
ZCBjb250cm9sIHdpbGwgaW5jbHVkZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QnV0IGF0IHRo
ZSBzYW1lIHRpbWUsIEkgZG8gbm90IHdhbnQgdG8gcmVzdHJpY3QgdGhlIGRldmVsb3BlcnMgd2hp
Y2ggY2FuIGNvbWUgdXAgd2l0aCBzb21lIG5pY2UgdHdlYWtzIGFuZCB0cmlja3MgdG8gYXZvaWQg
c2VuZGluZyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBldmVyeSBtZXNzYWdlLiBBbmQgdGhpcyBp
cyB3aGVyZSB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYW5kIGF2b2lkIHB1dHRpbmcgc3VjaCByZXN0
cmljdGlvbnMgaW4gcHJvdG9jb2wgZGVmaW5pdGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2hhdCBkbyB5b3UgdGhpbms/PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhpcyBhbHNvIHRoZSByZWFz
b24gSSB3YXMgc3VnZ2VzdGluZyBsb29zZSBkZXNjcmlwdGlvbiBvZiB3aGVuIHRvIGluY2x1ZGUg
T0xSIChmcm9tIHRoZSByZXBvcnRpbmcgbm9kZSBwb2ludCBvZiB2aWV3KS48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJh
cnRvbG9tZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDcsIDIwMTQgODo1NyBQTTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiA8YSBocmVmPSJtYWlsdG86ZGlt
ZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IZWxsbyBVbHJpY2gsIE5pcmF2LDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhh
dCB0aGUgdGV4dCBwcm92aWRlZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBv
ciBub3QgdGhlIHNlcnZlciBzZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJl
IGp1c3QgYSBNQVkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+T24gdGhlIG90aGVyIGhhbmQsIGNyaXRlcmlhIHByb3ZpZGVkIGJ5IFVscmljaCBvbiB3
aGVuIE9MUiBoYXMgdG8gYmUgc2VudCByZXF1aXJlcyB0aGUgc2VydmVyIGhhcyBzb21lIGtub3ds
ZWRnZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5h
KSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxy
ZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5iKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQg
KGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFj
dGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmMpIG90aGVyd2lzZTxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlcG9ydGluZyBu
b2RlIG11c3QgaGF2ZSBzb21lIGtub3dsZWRnZSBhYm91dCBPTFIgcmVjZXB0aW9uL3N0YXR1cyBp
biByZWFjdGluZyBub2RlLiBIb3cgZG9lcyBzZXJ2ZXIgYWNxdWlyZSB0aGlzIGtub3dsZWRnZT8g
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGFrZSBp
bnRvIGFjY291bnQgYXMgd2VsbCB0aGF0IGEgJnF1b3Q7cmVhY3RpbmcmcXVvdDsgbm9kZSBtYXkg
YmUgYm90aCBhbiBBZ2VudCAoaW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2aWNlIHRvIGEgcmVhbG0g
b3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkmbmJzcDsgYW5k
IGEgQ2xpZW50LiBJbiB0aGUgY2FzZSBvZiBBZ2VudHMsIGluIGZhY3QgdGhlIFNlcnZlciBtYXkg
bm90IGV2ZW4ga25vdyBpZiB0aGlzIGlzIGdvaW5nIHRvIGFjdCBhcyBhIHJlYWN0aW5nIG5vZGUg
b3IganVzdCB0cmFuc3BhcmVudGx5LCBpbiBmYWN0LCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQg
dG8gaGF2ZSBhbnkga25vd2xlZGdlIGFib3V0IHdoYXQgYWdlbnRzIGluIHRoZSBjaGFpbiB0byB0
aGUgZmluYWwgQ2xpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIg
aW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXM6PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBzdGF0ZS1sZXNzIGltcGxl
bWVudGF0aW9uICh0cmFuc2FjdGlvbiBvciBzZXNzaW9uKSBpcyBzaW1wbGVyLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gdGhlIHNlcnZlciBkb2Vz
IG5vdCBuZWVkIHRvIGRldGVybWluZSB3aGV0aGVyIG9yIG5vdCB0byBzZW5kIGFuIE9MIHRvIGEg
cmVhY3Rpbmcgbm9kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhlciB3aGV0aGVyIGFuIHJl
YWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBP
TFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBzZW5kaW5nIGFuIGFkZGl0aW9uYWwgQVZQ
IGlzIG5vdCBwcm9jZXNzaW5nIGNvbnN1bWluZywgaW4gY29tcGFyaXNvbiB3aXRoIHJlcXVpcmVk
IGFib3ZlIGNoZWNrcyAoaWYgdGhpcyBpcyBub3Qgc2VudCkuIDxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBJbiBmYWN0LCBpbiBhbiBvdmVy
bG9hZCBzaXR1YXRpb24sIHRoZSBlYXNpZXN0IGFuZCBsZWFzdCBjb21wbGV4IGlzIHRvIHNlbmQg
aW5mb3JtYXRpb24gb3V0IHRvIGFsbCBhZmZlY3RlZC9hcHBsaWNhYmxlIG5vZGVzLCA8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgYW5kIHRo
ZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMmbmJz
cDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBt
b3JlIHJvYnVzdCBzb2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVj
a3Mgb24gdGhlIG5lZWQgdG8gc2VuZCBpbmZvcm1hdGlvbiwmbmJzcDsgZm9yIHNpdHVhdGlvbnMg
d2hlcmUgYW4gYW5zd2VyIG1lc3NhZ2UgaXMgbG9zdCwmbmJzcDsg4oCmPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QmVzdCByZWdhcmRzPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+L01DcnV6PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5t
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFdpZWhlLCBVbHJp
Y2ggKE5TTiAtIERFL011bmljaCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5TZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTk8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogZXh0
IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0ZXZlIERvbm92
YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJl
OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkknbSBhZnJhaWQgeW91
ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDt3aGVuIGl0IHdh
bnRzIHRvIHByb3ZpZGUvdXBkYXRlLi4uLml0IHNoYWxsIGluY2x1ZGUuLi4mcXVvdDsgdHJhbnNs
YXRlcyB0byAmcXVvdDsuLi5pdCBtYXkgaW5jbHVkZS4uLiZxdW90Oy48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDtpbiBvdGhlciBjYXNlcyZx
dW90OyBpbiB0aGUgZ2l2ZW4gY29udGV4dCB0cmFuc2xhdGVzIHRvICZxdW90O3doZW4gaXQgZG9l
cyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldlIGhhdmUgdGhlIGZvbGxvd2luZyBjYXNl
czo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hKSB0
aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFk
eSBnb3QgdGhlIGxhdGVzdCBPTFI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5iKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGku
ZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGlu
ZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmMpIG90aGVyd2lzZTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmluIGNhc2UgYSkgdGhl
IHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikg
dGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5v
ZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNU
IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBu
b3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVscmljaDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+RnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90
QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFy
eSAwNiwgMjAxNCA0OjQ5IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+VG86IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCA8YSBo
cmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5n
ZS5jb208L2E+OyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v
cmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+VWxyaWNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJs
eSB0aGUgcHJvcG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG93IGFib3V0IHRoZSBmb2xs
b3dpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
V2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3ZlcmxvYWQgcmVw
b3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBv
cnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSBy
ZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBB
VlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5
LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdh
cmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFj
dGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUg
cmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUg
QVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJl
Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gp
IFs8YSBocmVmPSJtYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb20iPm1haWx0bzp1bHJpY2gud2ll
aGVAbnNuLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDM6NTcgUE08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogZXh0IDxhIGhy
ZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbTwvYT47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJl
Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYsIExpb25lbCw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGNhbiB1bmRlcnN0YW5k
IE5pcmF2J3MgY29uY2VybiAoYWx0aG91Z2ggdmlvbGF0aW5nIFJFUTEwKSBhbmQgaG9wIGl0IGlz
IGFkZHJlc3NlZCBieSB0aGUgbW9kaWZpZWQgcHJpbmNpcGxlIDInOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjInLiB0aGUgcmVwb3J0aW5nIG5vZGUg
KG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byBy
ZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBP
Qy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcg
bm9kZSBhbHJlYWR5IGhhcyBnb3QgcmVhc29uYWJsZSBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0
aW9uIChlLmcuIHRoZSBsYXRlc3QgT0xSLCB3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3Rpbmcg
dHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgJnF1b3Q7bm8gb3ZlcmxvYWQm
cXVvdDssIG9yIGFuIG9sZCZuYnNwOyBidXQgc29vbiBleHBpcmluZyBPTFIgd2hlbiB0aGUgcmVw
b3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMg
bm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJs
b2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3Rz
IHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBkb24ndCBhZ3JlZSB3aXRo
IExpb25lbHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxs
IG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUg
cmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhl
IGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2gmbmJzcDsgPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5Gcm9tOiBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbSI+bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT5d
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDog
VGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDEwOjIwIEFNPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJl
Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t
LS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGUm
bmJzcDs6IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChu
c2Fsb3QpIEVudm95w6kmbmJzcDs6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCZuYnNw
OzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPiBPYmpldCZuYnNw
OzogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNoLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgYW0gbm90
IHN1cmUgYWJvdXQgZm9yY2luZyB0aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2RlICZxdW90
O290aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9k
ZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9M
UiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5UaGUgcmVwb3J0aW5nIG5vZGUgbWF5IHNpbXBseSBub3QgaW5jbHVkZSBP
TFIgYXNzdW1pbmcgdGhhdCB0aGUgZWFybGllciBwcm92aWRlZCBPTFIgd2lsbCBleHBpcmUgYW5k
IHRoZSByZWFjdGluZyBub2RlIHdpbGwgc3RvcCB0aHJvdHRsaW5nIHRoZSB0cmFmZmljLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltMTV0gQWdyZWUu
IEluIG90aGVyIHdvcmRzLCBpdCBpcyBub3QgZGVlbWVkIHJlcXVpcmVkIGZvciB0aGUgZGVmYXVs
dCBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQuIEhvdyBhbmQgd2hlbiB0aGUgcmVw
b3J0aW5nIG5vZGUgZGVjaWRlcyB0byBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciBtYXkg
ZGVwZW5kIG9uIHRoZSBhcHBsaWNhdGlvbiBvciBvbiB0aGUgaW1wbGVtZW50YXRpb24uIEF0IGxl
YXN0LCBpdCBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVy
LCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBz
dG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIElu
IG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4
cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcg
dHJhZmZpYyB0b3dhcmRzIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5UaGVyZSBtYXkgYmUgb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUg
cmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgbGFzdCBvdmVybG9hZCBzaXR1YXRpb24gZW5k
ZWQgbG9uZyB0aW1lIGJhY2sgaW4gdGhlIHBhc3QsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGl0IHRv
IGluY2x1ZGUgT0xSIGlmIGN1cnJlbnRseSB0aGVyZSBpcyBubyBvdmVybG9hZCBjb25kaXRpb24u
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W0xNXSBB
Z3JlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJl
c3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVsb3cgYXJlIGZpbmUgd2l0aCBtZS48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTE1dIEFncmVlPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgWzxhIGhyZWY9Im1h
aWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbSI+bWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tPC9h
Pl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50
OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMjoyMyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkFjdHVhbGx5IHdlIHNlZW0gdG8gYWdyZWUgb24gdHdvIHByaW5jaXBsZXM6PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MS4gTGFjayBvZiBPTFIgbWVh
bnMgJnF1b3Q7bm8gY2hhbmdlJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Mi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhl
ciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiBy
ZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMg
Z290IHRoZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZp
YyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgJnF1b3Q7bm8gb3ZlcmxvYWQmcXVvdDsp
OyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5v
ZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBP
TFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Q2FuIHBlb3BsZSBwbGVhc2UgY29uZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0g
T24gQmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAx
NCA0OjM1IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9y
ZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5BZ3JlZWQuJm5ic3A7IFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9h
ZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0
aGUgaG9zdCBvciByZWFsbS4mbmJzcDsgSWYgdGhlcmUgaXMgYSBjdXJyZW50bHkgYWN0aXZlIG92
ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IGNvbnRpbnVlcyB0byBhcHBseSB1bnRpbCBpdCBlaXRoZXIg
dGltZXMgb3V0IG9yIGlzIGV4cGxpY2l0bHkgY2hhbmdlZCB3aXRoIGEgbmV3IG92ZXJsb2FkIHJl
cG9ydC4mbmJzcDsgSWYgdGhlcmUgaXMgbm8gY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBv
cnQgdGhlbiBsYWNrIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCBpbXBsaWVzIHRoZXJlIGlzIG5vIG92
ZXJsb2FkIGZvciB0aGUgaG9zdCBhbmQgcmVhbG0uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3RldmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PbiAyLzUvMTQgOToxOSBBTSwgTmlyYXYgU2Fsb3QgKG5z
YWxvdCkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+SSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAmcXVvdDtzaG91bGRu4oCZ
dCBsYWNrIG9mIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD8mcXVvdDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZSBoYWQgc29t
ZSBkaXNjdXNzaW9uIHNvbWV0aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhhdCBpdCBpcyByZWFzb25h
YmxlIHRvIG5vdCBtYW5kYXRlIHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5
IGFuc3dlciBtZXNzYWdlLiBFLmcuIHdoZW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9mIHRyYWNr
aW5nIHdoYXQgaXMgc2VudCB0byB3aGljaCBjbGllbnQgYW5kIGhlbmNlIHdhbnRzIHRvIGF2b2lk
IHNlbmRpbmcgaW5mb3JtYXRpb24gd2hpY2ggaXMgcmVkdW5kYW50LiBCdXQgdGhpcyBpcyBvcHRp
b25hbCBpbXBsZW1lbnRhdGlvbiBhbmQgYXQgdGhlIHNhbWUgdGltZSBuZWVkIG5vdCBiZSBwcm9o
aWJpdGVkIGZyb20gcHJvdG9jb2wgcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TbyBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9M
UiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJl
YWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNl
ZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9y
IHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICZxdW90OzAmcXVvdDsgb3ZlcmxvYWQtbWV0cmlj
IGlzIHJlY2VpdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlv
biBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUg
cmVhY3Rpbmcgbm9kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3RldmUg
RG9ub3ZhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODowMCBQTTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiA8YSBocmVmPSJtYWlsdG86
ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pbmxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5PayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVz
IE1VU1QgaW5zZXJ0IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNv
cnJlc3BvbmQgdG8gcmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlcyBBVlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQp
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNSRCZn
dDsgV2h5IGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlPyZuYnNwOyBTaG91bGRuJ3QgbGFjayBvZiBh
biBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T3RoZXIgY3JpdGVyaWEgbGlrZSBSRVEx
OCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U1JEJmd0OyBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQg
cmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVx
dWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0
aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xS
cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gb3Ig
bXkgY2xhcmlmaWNhdGlvbjogSSBndWVzcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGlzIG5vdCBy
ZXF1aXJlZCB0byBwcm9jZXNzIGV2ZXJ5IHNpbmdsZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2lsbCBi
ZSByZXBsYXlzIGFueXdheSkuIFdoYXQgd291bGQgYmUgdGhlIHByb2NlZHVyZSBpbiB0aGUgcmVh
Y3Rpbmcgbm9kZSBpbiBvcmRlciB0byBtaW5pbWl6ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVkIE9M
UnMgYW5kIGF0IHRoZSBzYW1lIHRpbWUgbWluaW1pemUgdGhlIHJpc2sgdG9vIG1pc3MgYSBuZXcg
T0xSPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNS
RCZndDsgVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYg
U2Fsb3QgKG5zYWxvdCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0i
bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDog
UmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBzaGFyZSB0aGUg
c2FtZSBvcGluaW9uIGFzIExpb25lbC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJl
Zj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFu
Z2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQs
IDIwMTQgOTowNyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlRvOiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJq
ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHVuZGVy
c3RhbmQgdGhhdCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIERP
RVMgTk9UIGluc2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4gPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gdGhlIG9wdGlvbnMgd291bGQgYmU6
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MS0gT0Mt
T0xSIEFWUCBpbiBldmVyeSBhbnN3ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4yLSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZl
cnkgcmVxdWVzdCAmIzQzOyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJl
bnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVk
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHRo
ZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFw
cHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
Pkxpb25lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
Pi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPkRlJm5ic3A7OiBkaW1lIGlzc3VlIHRyYWNrZXIgWzxhIGhy
ZWY9Im1haWx0bzp0cmFjJiM0MztkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmciPm1haWx0bzp0cmFj
JiM0MztkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmc8L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkVudm95w6kmbmJzcDs6IG1hcmRpIDQgZsOpdnJp
ZXIgMjAxNCAwOTo0OTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPsOAJm5ic3A7OiBNT1JBTkQgTGlvbmVsIElNVC9PTE48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DYyZuYnNwOzogPGEgaHJlZj0ibWFpbHRv
OmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T2JqZXQmbmJzcDs6IFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4jMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gSXQgaGFzIGJlZW4g
cHJvcG9zZWQgdG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0aGF0
IGlzJm5ic3A7IHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCZuYnNwOyBzdXJ2aXZlZCBhIHRocm90dGxpbmcuIFRoaXMg
QVZQIHdvdWxkIGluZGljYXRlIHRoZSBTZXF1ZW5jZS1OdW1iZXI8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gKFRpbWVTdGFtcCkgb2YgdGhlIE9MUiBh
Y2NvcmRpbmcgdG8gd2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdhczxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBzdXJ2aXZlZCkgaXMgcGVyZm9y
bWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyZuYnNw
OyB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4mbmJzcDsgUmVwb3J0aW5nIERPSUMgZW5kcG9pbnRz
IG1heSB1c2UgdGhpcyZuYnNwOyBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhl
ciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZSZuYnNwOyByZWFjdGluZyBET0lDIGVuZHBv
aW50IHdpdGggdGhlIGxhdGVzdCBPTFIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+IEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNoYW5pc20gd291
bGQgcmVzdWx0IGluIHRoZSBuZWVkIGZvciB0aGUmbmJzcDsgcmVwb3J0aW5nIG5vZGUgdG8gc2Vu
ZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDJm5ic3A7
IGVuZHBvaW50IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQg
aXMgYWN0dWFsbHkgZG9pbmcmbmJzcDsgdGhlIHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRo
cm90dGxpbmcvbm90IHRocm90dGxpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+IFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0
bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDJm5ic3A7IGVuZHBvaW50IHRvIGRl
dGVjdCBhbmQgY29ycmVjdCBpbmFwcHJvcHJpYXRlIHRocm90dGxpbmcgYnkgdGhlIHJlYWN0aW5n
Jm5ic3A7IERPSUMgZW5kcG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24pLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBUaGUgZmVlZGJhY2sg
bWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IEluIHN1bW1h
cnkgaXQgaXMgcHJvcG9zZWQgdG8gZGVmaW5lIHRoZSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgdG8mbmJzcDsgYmUgdXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWls
aW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg
cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2
aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg
b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl
IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl
dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv
bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRv
dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91
IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj
b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0
ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk
IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv
ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhhbmsg
eW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWlsaW5nIGxpc3Q8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVm
PSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRp
TUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5E
aU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86
RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq
b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg
b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg
b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl
IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg
YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg
ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp
bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy
Y2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y
IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50aGV5IHNob3Vs
ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv
bi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz
ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcyBlbWFpbHMgbWF5
IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg
YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw
ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp
bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh
bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs
IHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp
ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs
ZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh
IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50
cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0
IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv
cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l
c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5rIHlvdS48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_087A34937E64E74E848732CFF8354B920977300CESESSMB101erics_--


From srdonovan@usdonovans.com  Tue Feb 11 07:07:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C331A033A for ; Tue, 11 Feb 2014 07:07:38 -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
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 aVZ9w8t_pDSO for ; Tue, 11 Feb 2014 07:07:35 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBE1A03E6 for ; Tue, 11 Feb 2014 07:07:35 -0800 (PST)
Received: from [137.254.4.59] (port=42134 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDEvt-0002iR-0t for dime@ietf.org; Tue, 11 Feb 2014 07:07:34 -0800
Message-ID: <52FA3CC6.9050205@usdonovans.com>
Date: Tue, 11 Feb 2014 09:07:50 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:07:38 -0000

On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
> Lionel,
>
> About first case:
>
> - If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host 
>
> I do not agree on this, since if Destination Host is used, there is no reason to throttle messages if this Host has not provided any OLR.
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not
have visibility of the entire realm. 
> This is in line with the example used from the beginning:
> ---------
> ..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1,
> -throttle host type request to S2 with 50% and
> -throttle realm type requests wit 25%?
> ------------
>
> And I think this is what JJ commented:
> [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>
> In my opinion, reducing traffic to S1 is wrong.
SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.
>
> Regards
> /MCruz
>
> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
> Sent: martes, 11 de febrero de 2014 11:57
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi maria-cruz,
>
> JJ agreed on the following approach:
>
> - If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>    
> - If the reacting node has received an indication only for host traffic reduction, apply host reduction for messages containing a Destination-Host. No reduction for messages with only a Destination-Realm.
> [JJ] OK
>  
> - If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm reduction when the overloaded host is inside an overloaded realm and the reacting has received info about both type of overload.
>
> What is the issue with this approach?
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : mardi 11 février 2014 11:49 À : dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hello,
> I agree with JJ:
>
> - If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>
> [MCruz] And... if the request is sent to a Destination-Host, if there is any applicable OLR, it will be received immediately in the answer, and will be applicable from next request on.
> Simple and robust in my opinion. Then, we do not need to evaluate whether we have OLR for Realm and/or Host, and even check their validity & applicability.
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: lunes, 10 de febrero de 2014 15:00
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi Lionel 
>
> Please see in line
>
> -----Message d'origine-----
> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoyé : lundi 10 février 2014 14:25 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> I disagree and my proposal was somehow misunderstood.
>
> I don't see the issue to have the following sequence:
>
> - If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>    
> - If the reacting node has received an indication only for host traffic reduction, apply host reduction for messages containing a Destination-Host. No reduction for messages with only a Destination-Realm.
> [JJ] OK
>  
> - If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm reduction when the overloaded host is inside an overloaded realm and the reacting has received info about both type of overload.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 10 février 2014 13:56 À : dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear  all
>
> I share Ulrich and MCruz views,
> - Host OLR based control applies to requests where Destination Host is known
> - Realm OLR based control applies to requests where Destination Host is not known (only the Destination realm).
>
> I think it is simple, otherwise as MCruz indicated it complicates; e.g about the Ulrich's example where the Host S1 is not overloaded but the realm is overloaded. the client will not receive Host OLR reports from host S1 (so no explicit traffic reduction requested by S1), but according to Lionel comment, I understand  client will have to throttle the requests sent to S1 according to realm OLR, so how to avoid this.
>
> JJacques
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : vendredi 7 février 2014 17:15 À : dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear all,
>
> I am in favor of the proposal made by Ulrich in the sequence diagram he provided.
> ----
> As a summary:
> Consequently the reacting node will receive realm type OLRs from the agent and host type OLRs from the servers.
> The received realm type OLR will be relevant for the reacting node when sending/throttling realm type requests; the received host type OLR will be relevant for the reacting node       when sending/throttling host type requests.
> -----
>
> It may occur though, that a Client has only received Realm type OLR, and then it has to send a request to one specific host, then the Client will not apply any restriction, but as soon as the response is received back, Client will update Host type OLR.  Same will apply when only Host type OLR has been received by Client.
> The alternative will be to always send back from an Agent both Host OLR plus Realm OLR, but I do not think this is necessary and may complicate the solution.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
> Sent: viernes, 07 de febrero de 2014 14:13
> To: ext Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Friday, February 07, 2014 11:21 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>> What is wrong with letting the client
>> -not throttle host-type requests to S1, -throttle host type request to
>> S2 with 50% and -throttle realm type requests wit 25%?
> Isn't this what Lionel said below?
>  no it is not
>  I am OK with Lionel's
> "wording" here.
>
> - Jouni
>
>>  
>>  
>>  
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext 
>> lionel.morand@orange.com
>> Sent: Wednesday, February 05, 2014 4:14 PM
>> To: Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>  
>> I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.
>>  
>> Lioenl
>>  
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan 
>> Envoyé : mercredi 5 février 2014 15:56 À : dime@ietf.org Objet : Re:
>> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>  
>> It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.
>>
>> If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.
>>
>> I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.
>>
>> Steve
>>
>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
>> The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
>> If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.
>>  
>> Does it make sense?
>>  
>> Lionel
>>  
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoyé : mardi 4 février 2014 09:55
>> À : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>>  
>> #34: Semantics of OC-Report-Type AVP
>>  
>>  Text in clause 4.6  does not fully explain to which requests overload 
>> treatment of a given report type applies.
>>  Proposal:
>>  
>>     0  A host report.  The overload treatment should apply to requests
>>        for which all of the following conditions are true:
>>        a) The Destination-Host AVP is present in the request and its value
>>           matches the value of the Origin-Host AVP of the received message
>>           that contained the OC-OLR AVP.
>>        b) The value of the Destination-Realm AVP in the request matches the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diameter
>>           Header of the received message that contained the OC-OLR AVP.
>>  
>>  
>>  
>>     1  A realm report.  The overload treatment should apply to
>>        requests for which all of the following conditions are true:
>>        a) The Destination-Host AVP is absent in the request.
>>        b) The value of the Destination-Realm AVP in the request matches the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diameter
>>           Header of the received message that contained the OC-OLR AVP.
>>  
>>  
>> ______________________________________________________________________
>> ___________________________________________________
>>  
>> 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.
>> _______________________________________________
>> 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
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> 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
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From lionel.morand@orange.com  Tue Feb 11 07:14:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BFE1A0376 for ; Tue, 11 Feb 2014 07:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z41dcKXAHhzU for ; Tue, 11 Feb 2014 07:14:30 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id BC4801A03FB for ; Tue, 11 Feb 2014 07:14:29 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 58AF5374181 for ; Tue, 11 Feb 2014 16:14:28 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 43F9A1800C1 for ; Tue, 11 Feb 2014 16:14:28 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 16:14:28 +0100
From: 
To: "dime@ietf.org" 
Thread-Topic: Mailing list issue: Message body size is is limited to 150 KB
Thread-Index: Ac8nO/HmAlElPAw2S4OaCXjeIHuM3w==
Date: Tue, 11 Feb 2014 15:14:27 +0000
Message-ID: <16318_1392131668_52FA3E54_16318_1850_1_6B7134B31289DC4FAF731D844122B36E49A214@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: 2iQ= CJf+ Ci0O CzPs DbCr D5fn E/6y FRtE GN2O G+cG HwEF H4sM IVLi Itd4 J+bP L1Ja; 1; ZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {AC7F3841-2EFA-41CB-80B0-BE54C1B8483F}; bABpAG8AbgBlAGwALgBtAG8AcgBhAG4AZABAAG8AcgBhAG4AZwBlAC4AYwBvAG0A; Tue, 11 Feb 2014 15:14:23 GMT; TQBhAGkAbABpAG4AZwAgAGwAaQBzAHQAIABpAHMAcwB1AGUAOgAgAE0AZQBzAHMAYQBnAGUAIABiAG8AZAB5ACAAcwBpAHoAZQAgAGkAcwAgAGkAcwAgAGwAaQBtAGkAdABlAGQAIAB0AG8AIAAxADUAMAAgAEsAQgA=
x-cr-puzzleid: {AC7F3841-2EFA-41CB-80B0-BE54C1B8483F}
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615
Subject: [Dime] Mailing list issue: Message body size is is limited to 150 KB
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:14:33 -0000

Please be careful when sending an email on IETF mailing list.
The message body size cannot exceed 150 ko and when using htlm format, this=
 limit is quickly reached when answered messages are automatically copied i=
n the body.

As a consequence, the message is blocked, waiting for moderator approval. S=
o don't be surprised if you can't see your mail on the mailing list as soon=
 as sent.

Tips:
- use the text format instead of html.
- do not attach document to the email
- Avoid too many successive responses "inline/see above"
- keep the subject line unchanged to track previous emails on the same topic

Regards,

Lionel

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From srdonovan@usdonovans.com  Tue Feb 11 07:17:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291271A0386 for ; Tue, 11 Feb 2014 07:17:31 -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
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 TwogW1FGwyXs for ; Tue, 11 Feb 2014 07:17:29 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id CE1911A0326 for ; Tue, 11 Feb 2014 07:17:29 -0800 (PST)
Received: from [137.254.4.59] (port=55555 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDF5U-0002dv-Kl for dime@ietf.org; Tue, 11 Feb 2014 07:17:29 -0800
Message-ID: <52FA3F19.7060503@usdonovans.com>
Date: Tue, 11 Feb 2014 09:17:45 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------080300040607020103070904"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: [Dime] Requirement for handling realm overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:17:31 -0000

This is a multi-part message in MIME format.
--------------080300040607020103070904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

The following is the requirement stating the need to support realm overload.

 REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.

Enscript Output
This requirement does qualify realm to mean "realm routed requests".  
It talks about handling throttling in the face of overload of the realm.

Steve

--------------080300040607020103070904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    The following is the
      requirement stating the need to support realm overload.

    

    
      
    
    

      

        

          
 REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.


        

      

    

    
      Enscript Output
      

      This requirement does qualify realm to mean "realm routed
      requests".   It talks about handling throttling in the face of
      overload of the realm.

      

      Steve

    
  


--------------080300040607020103070904--


From lionel.morand@orange.com  Tue Feb 11 07:25:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603A71A0502 for ; Tue, 11 Feb 2014 07:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeQw0dL-cm6t for ; Tue, 11 Feb 2014 07:24:59 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 40C891A0412 for ; Tue, 11 Feb 2014 07:24:59 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 223A422C287; Tue, 11 Feb 2014 16:24:58 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 06F7E238076; Tue, 11 Feb 2014 16:24:58 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 16:24:57 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDggAACzDCAAChLgIAADXcAgAAVYoA=
Date: Tue, 11 Feb 2014 15:24:57 +0000
Message-ID: <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.9050205@usdonovans.com>
In-Reply-To: <52FA3CC6.9050205@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.11.81814
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:25:04 -0000

Hi Maria Cruz,

Actually I've missed this point. Sorry.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: mardi 11 f=E9vrier 2014 16:08
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
> Lionel,
>
> About first case:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host=20
>
> I do not agree on this, since if Destination Host is used, there is no re=
ason to throttle messages if this Host has not provided any OLR.
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not
have visibility of the entire realm.=20
> This is in line with the example used from the beginning:
> ---------
> ..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% =
overloaded, and the aggregated realm overload is 25%. Why should a client d=
o a 25% throttling when sending host type requests to the not at all overlo=
aded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1,
> -throttle host type request to S2 with 50% and
> -throttle realm type requests wit 25%?
> ------------
>
> And I think this is what JJ commented:
> [JJ] there may be a misunderstanding somewhere, so good to try to clarify=
; coming back to Ulrich example, Host S1 is not overloaded, so reacting nod=
e has not received Host reduction OLR for S1. But as there  is a realm redu=
ction, reacting node will reduce traffic with destination Host S1.
>
> In my opinion, reducing traffic to S1 is wrong.
SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.
>
> Regards
> /MCruz
>
> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
> Sent: martes, 11 de febrero de 2014 11:57
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi maria-cruz,
>
> JJ agreed on the following approach:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>=20=20=20=20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
>=20=20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> What is the issue with this approach?
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9 : mardi 11 f=E9vrier 2014 11:49 =C0 : dime@ietf.org Objet : Re:=
 [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hello,
> I agree with JJ:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>
> [MCruz] And... if the request is sent to a Destination-Host, if there is =
any applicable OLR, it will be received immediately in the answer, and will=
 be applicable from next request on.
> Simple and robust in my opinion. Then, we do not need to evaluate whether=
 we have OLR for Realm and/or Host, and even check their validity & applica=
bility.
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
> Sent: lunes, 10 de febrero de 2014 15:00
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi Lionel=20
>
> Please see in line
>
> -----Message d'origine-----
> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9 =
: lundi 10 f=E9vrier 2014 14:25 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=
 dime@ietf.org Objet : RE: [Dime] [dime] #34: Semantics of OC-Report-Type A=
VP
>
> I disagree and my proposal was somehow misunderstood.
>
> I don't see the issue to have the following sequence:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>=20=20=20=20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
>=20=20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9 : lundi 10 f=E9vrier 2014 13:56 =C0 : dime@ietf=
.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear  all
>
> I share Ulrich and MCruz views,
> - Host OLR based control applies to requests where Destination Host is kn=
own
> - Realm OLR based control applies to requests where Destination Host is n=
ot known (only the Destination realm).
>
> I think it is simple, otherwise as MCruz indicated it complicates; e.g ab=
out the Ulrich's example where the Host S1 is not overloaded but the realm =
is overloaded. the client will not receive Host OLR reports from host S1 (s=
o no explicit traffic reduction requested by S1), but according to Lionel c=
omment, I understand  client will have to throttle the requests sent to S1 =
according to realm OLR, so how to avoid this.
>
> JJacques
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9 : vendredi 7 f=E9vrier 2014 17:15 =C0 : dime@ietf.org Objet : R=
e: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear all,
>
> I am in favor of the proposal made by Ulrich in the sequence diagram he p=
rovided.
> ----
> As a summary:
> Consequently the reacting node will receive realm type OLRs from the agen=
t and host type OLRs from the servers.
> The received realm type OLR will be relevant for the reacting node when s=
ending/throttling realm type requests; the received host type OLR will be r=
elevant for the reacting node       when sending/throttling host type reque=
sts.
> -----
>
> It may occur though, that a Client has only received Realm type OLR, and =
then it has to send a request to one specific host, then the Client will no=
t apply any restriction, but as soon as the response is received back, Clie=
nt will update Host type OLR.  Same will apply when only Host type OLR has =
been received by Client.
> The alternative will be to always send back from an Agent both Host OLR p=
lus Realm OLR, but I do not think this is necessary and may complicate the =
solution.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN=
 - DE/Munich)
> Sent: viernes, 07 de febrero de 2014 14:13
> To: ext Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Friday, February 07, 2014 11:21 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> I better like Lionel's approach, but even that is not ok in the unlikely=
 extreme case where we have two servers in a realm, S1 is not overloaded at=
 all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why s=
hould a client do a 25% throttling when sending host type requests to the n=
ot at all overloaded S1?
>> What is wrong with letting the client
>> -not throttle host-type requests to S1, -throttle host type request to
>> S2 with 50% and -throttle realm type requests wit 25%?
> Isn't this what Lionel said below?
>  no it is not
>  I am OK with Lionel's
> "wording" here.
>
> - Jouni
>
>>=20=20
>>=20=20
>>=20=20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
>> lionel.morand@orange.com
>> Sent: Wednesday, February 05, 2014 4:14 PM
>> To: Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20=20
>> I tend to agree except that I would reverse the logic as for the routing=
 principles: the Destination-host takes precedence when present over Destin=
ation-Realm. So the realm abatement is applied in any case except if there =
is an explicit report for the destination-host.
>>=20=20
>> Lioenl
>>=20=20
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet : R=
e:
>> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20=20
>> It makes more sense to me for a realm report to apply to all requests ta=
rgeted for that realm, independent the type of request.  This implies that =
it would apply to requests that also have a Destination-Host specified.
>>
>> If this is the definition of a realm report then we need to specify the =
interaction between realm reports and host reports.
>>
>> I propose that throttling would occur on the realm first and the host se=
cond.  If a message targetted for the host is throttled as a result of real=
m overload then that throttled message would count as part of the reduction=
 needed to address the host overload.  Messages to the host that survive re=
alm abatement would then be candidates for host overload.
>>
>> Steve
>>
>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
>> The case "Realm" as described below raises another question: is it prohi=
bited for a realm to only rely on a global overload report for the whole re=
alm, whatever the nodes inside this realm?
>> If not, only OLR with the report type "realm" would be received by the r=
eacting node. And the reduction indicated in the OLR will apply always for =
the realm, whatever the presence of Destination-host AVP in the request... =
except if an explicit report with the type "Host" as been received for this=
 destination-host.
>>=20=20
>> Does it make sense?
>>=20=20
>> Lionel
>>=20=20
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
>> =C0 : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>>=20=20
>> #34: Semantics of OC-Report-Type AVP
>>=20=20
>>  Text in clause 4.6  does not fully explain to which requests overload=
=20
>> treatment of a given report type applies.
>>  Proposal:
>>=20=20
>>     0  A host report.  The overload treatment should apply to requests
>>        for which all of the following conditions are true:
>>        a) The Destination-Host AVP is present in the request and its val=
ue
>>           matches the value of the Origin-Host AVP of the received messa=
ge
>>           that contained the OC-OLR AVP.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diameter
>>           Header of the received message that contained the OC-OLR AVP.
>>=20=20
>>=20=20
>>=20=20
>>     1  A realm report.  The overload treatment should apply to
>>        requests for which all of the following conditions are true:
>>        a) The Destination-Host AVP is absent in the request.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diameter
>>           Header of the received message that contained the OC-OLR AVP.
>>=20=20
>>=20=20
>> ______________________________________________________________________
>> ___________________________________________________
>>=20=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20=20
>> This message and its attachments may contain confidential or=20
>> 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 d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> 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
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 07:29:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671E21A0583 for ; Tue, 11 Feb 2014 07:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 ZSnAaiO0kmSg for ; Tue, 11 Feb 2014 07:29:40 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C5EFA1A0376 for ; Tue, 11 Feb 2014 07:29:39 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-0a-52fa41e21e42
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B0.D1.04249.2E14AF25; Tue, 11 Feb 2014 16:29:38 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 16:29:38 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAlWmMf1mPE0uklIAv2DU+a5qmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDg///ya4CAAEgwoP///fMAAALVKuA=
Date: Tue, 11 Feb 2014 15:29:37 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097730D2@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.9050205@usdonovans.com>
In-Reply-To: <52FA3CC6.9050205@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+Jvje4jx19BBkv3GVjM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBPrtzIVzJvIWHFyFk8DY0tpFyMHh4SAicS3yUAmJ5ApJnHh 3nq2LkYuDiGBI4wSJzaugXKWMErMvD6JBaSKTcBO4tLpF0wgzSICyhKnfzmAhIUF7CW+3jjD DGKLCDhIrHl+kgWkV0Sgi1Hi74UjTCAJFgFVif3NMxlBbF4BX4lzk9YwQyzo55D40zsDbAGn gJ7E44PzwCYxAp30/dQasGZmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaSxNrD21kg6vUk bkydwgZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaM4tTgpN93IYBMj MPQPbvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC8xDQ1 LONVe+y7JZ/vq6jv+HjNVqWbY/ZuX/GanTumf1uxnWV1+AnrPU/DpwftUAi6GDLnXIxY+IRA ZqdzJmsDlVcUFuRvt09b4aZ8co2hiXmGmt0ua6Y59/6k+s+IUe3/7OoWMasn4KjMT+UPrEIv 7t++kV3V8LIhwczm6ZrIZwv/Tftcl79JiaU4I9FQi7moOBEA97iNEUsCAAA=
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:29:44 -0000

Steve,

Well, it is clear that we do not agree on this.

On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
> Lionel,
>
> About first case:
>
> - If the reacting node has received an indication only for Realm=20
> traffic Reduction, apply Realm reduction is for any message, with=20
> Destination-Realm and with/without Destination-Host
>
> I do not agree on this, since if Destination Host is used, there is no re=
ason to throttle messages if this Host has not provided any OLR.
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not have=
 visibility of the entire realm.=20
> This is in line with the example used from the beginning:
> ---------
> ..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% =
overloaded, and the aggregated realm overload is 25%. Why should a client d=
o a 25% throttling when sending host type requests to the not at all overlo=
aded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1, -throttle host type request to=20
> S2 with 50% and -throttle realm type requests wit 25%?
> ------------
>
> And I think this is what JJ commented:
> [JJ] there may be a misunderstanding somewhere, so good to try to clarify=
; coming back to Ulrich example, Host S1 is not overloaded, so reacting nod=
e has not received Host reduction OLR for S1. But as there  is a realm redu=
ction, reacting node will reduce traffic with destination Host S1.
>
> In my opinion, reducing traffic to S1 is wrong.
SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.
>
> Regards
> /MCruz
>
> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: martes, 11 de febrero de 2014 11:57
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi maria-cruz,
>
> JJ agreed on the following approach:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>   =20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
> =20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> What is the issue with this approach?
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20
> Bartolome Envoy=E9 : mardi 11 f=E9vrier 2014 11:49 =C0 : dime@ietf.org Ob=
jet=20
> : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hello,
> I agree with JJ:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>
> [MCruz] And... if the request is sent to a Destination-Host, if there is =
any applicable OLR, it will be received immediately in the answer, and will=
 be applicable from next request on.
> Simple and robust in my opinion. Then, we do not need to evaluate whether=
 we have OLR for Realm and/or Host, and even check their validity & applica=
bility.
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN,=20
> JEAN-JACQUES (JEAN-JACQUES)
> Sent: lunes, 10 de febrero de 2014 15:00
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi Lionel
>
> Please see in line
>
> -----Message d'origine-----
> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9=
=20
> : lundi 10 f=E9vrier 2014 14:25 =C0 : TROTTIN, JEAN-JACQUES=20
> (JEAN-JACQUES); dime@ietf.org Objet : RE: [Dime] [dime] #34: Semantics=20
> of OC-Report-Type AVP
>
> I disagree and my proposal was somehow misunderstood.
>
> I don't see the issue to have the following sequence:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>   =20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
> =20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN,=20
> JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : lundi 10 f=E9vrier 2014 13:56 =C0 =
:=20
> dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of=20
> OC-Report-Type AVP
>
> Dear  all
>
> I share Ulrich and MCruz views,
> - Host OLR based control applies to requests where Destination Host is=20
> known
> - Realm OLR based control applies to requests where Destination Host is n=
ot known (only the Destination realm).
>
> I think it is simple, otherwise as MCruz indicated it complicates; e.g ab=
out the Ulrich's example where the Host S1 is not overloaded but the realm =
is overloaded. the client will not receive Host OLR reports from host S1 (s=
o no explicit traffic reduction requested by S1), but according to Lionel c=
omment, I understand  client will have to throttle the requests sent to S1 =
according to realm OLR, so how to avoid this.
>
> JJacques
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20
> Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 17:15 =C0 : dime@ietf.org=
=20
> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear all,
>
> I am in favor of the proposal made by Ulrich in the sequence diagram he p=
rovided.
> ----
> As a summary:
> Consequently the reacting node will receive realm type OLRs from the agen=
t and host type OLRs from the servers.
> The received realm type OLR will be relevant for the reacting node when s=
ending/throttling realm type requests; the received host type OLR will be r=
elevant for the reacting node       when sending/throttling host type reque=
sts.
> -----
>
> It may occur though, that a Client has only received Realm type OLR, and =
then it has to send a request to one specific host, then the Client will no=
t apply any restriction, but as soon as the response is received back, Clie=
nt will update Host type OLR.  Same will apply when only Host type OLR has =
been received by Client.
> The alternative will be to always send back from an Agent both Host OLR p=
lus Realm OLR, but I do not think this is necessary and may complicate the =
solution.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20
> (NSN - DE/Munich)
> Sent: viernes, 07 de febrero de 2014 14:13
> To: ext Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Friday, February 07, 2014 11:21 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> I better like Lionel's approach, but even that is not ok in the unlikely=
 extreme case where we have two servers in a realm, S1 is not overloaded at=
 all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why s=
hould a client do a 25% throttling when sending host type requests to the n=
ot at all overloaded S1?
>> What is wrong with letting the client -not throttle host-type=20
>> requests to S1, -throttle host type request to
>> S2 with 50% and -throttle realm type requests wit 25%?
> Isn't this what Lionel said below?
>  no it is not
>  I am OK with Lionel's
> "wording" here.
>
> - Jouni
>
>> =20
>> =20
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
>> lionel.morand@orange.com
>> Sent: Wednesday, February 05, 2014 4:14 PM
>> To: Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>> =20
>> I tend to agree except that I would reverse the logic as for the routing=
 principles: the Destination-host takes precedence when present over Destin=
ation-Realm. So the realm abatement is applied in any case except if there =
is an explicit report for the destination-host.
>> =20
>> Lioenl
>> =20
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet : R=
e:
>> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>> =20
>> It makes more sense to me for a realm report to apply to all requests ta=
rgeted for that realm, independent the type of request.  This implies that =
it would apply to requests that also have a Destination-Host specified.
>>
>> If this is the definition of a realm report then we need to specify the =
interaction between realm reports and host reports.
>>
>> I propose that throttling would occur on the realm first and the host se=
cond.  If a message targetted for the host is throttled as a result of real=
m overload then that throttled message would count as part of the reduction=
 needed to address the host overload.  Messages to the host that survive re=
alm abatement would then be candidates for host overload.
>>
>> Steve
>>
>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
>> The case "Realm" as described below raises another question: is it prohi=
bited for a realm to only rely on a global overload report for the whole re=
alm, whatever the nodes inside this realm?
>> If not, only OLR with the report type "realm" would be received by the r=
eacting node. And the reduction indicated in the OLR will apply always for =
the realm, whatever the presence of Destination-host AVP in the request... =
except if an explicit report with the type "Host" as been received for this=
 destination-host.
>> =20
>> Does it make sense?
>> =20
>> Lionel
>> =20
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
>> =C0 : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>> =20
>> #34: Semantics of OC-Report-Type AVP
>> =20
>>  Text in clause 4.6  does not fully explain to which requests=20
>> overload treatment of a given report type applies.
>>  Proposal:
>> =20
>>     0  A host report.  The overload treatment should apply to requests
>>        for which all of the following conditions are true:
>>        a) The Destination-Host AVP is present in the request and its val=
ue
>>           matches the value of the Origin-Host AVP of the received messa=
ge
>>           that contained the OC-OLR AVP.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diamete=
r
>>           Header of the received message that contained the OC-OLR AVP.
>> =20
>> =20
>> =20
>>     1  A realm report.  The overload treatment should apply to
>>        requests for which all of the following conditions are true:
>>        a) The Destination-Host AVP is absent in the request.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diamete=
r
>>           Header of the received message that contained the OC-OLR AVP.
>> =20
>> =20
>> _____________________________________________________________________
>> _ ___________________________________________________
>> =20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>> =20
>> This message and its attachments may contain confidential or=20
>> 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 d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> 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
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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 lionel.morand@orange.com  Tue Feb 11 07:30:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0661A03FB for ; Tue, 11 Feb 2014 07:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5gyWQ5_mzL2 for ; Tue, 11 Feb 2014 07:30:46 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD811A04DC for ; Tue, 11 Feb 2014 07:30:46 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 211743743A6; Tue, 11 Feb 2014 16:30:45 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 07026384089; Tue, 11 Feb 2014 16:30:45 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 16:30:41 +0100
From: 
To: MORAND Lionel IMT/OLN , Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAK95DWDMaH0qQEyVc/ebDNpqmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDggAACzDCAAChLgIAADXcAgAAVYoCAAADGMA==
Date: Tue, 11 Feb 2014 15:30:41 +0000
Message-ID: <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.9050205@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.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.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.11.70017
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:30:51 -0000

So now I understand Ulrich, Maria Cruz and JJ comments.

"My" proposal would force the servers in the realm to always send an OLR ju=
st to say "I'm not overloaded" i.e. with the value 0. That is anyway a poss=
ibility.
But if we want to avoid that, Realm type must only apply to message without=
 destination host.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com
Envoy=E9=A0: mardi 11 f=E9vrier 2014 16:25
=C0=A0: Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Maria Cruz,

Actually I've missed this point. Sorry.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: mardi 11 f=E9vrier 2014 16:08
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
> Lionel,
>
> About first case:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host=20
>
> I do not agree on this, since if Destination Host is used, there is no re=
ason to throttle messages if this Host has not provided any OLR.
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not
have visibility of the entire realm.=20
> This is in line with the example used from the beginning:
> ---------
> ..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% =
overloaded, and the aggregated realm overload is 25%. Why should a client d=
o a 25% throttling when sending host type requests to the not at all overlo=
aded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1,
> -throttle host type request to S2 with 50% and
> -throttle realm type requests wit 25%?
> ------------
>
> And I think this is what JJ commented:
> [JJ] there may be a misunderstanding somewhere, so good to try to clarify=
; coming back to Ulrich example, Host S1 is not overloaded, so reacting nod=
e has not received Host reduction OLR for S1. But as there  is a realm redu=
ction, reacting node will reduce traffic with destination Host S1.
>
> In my opinion, reducing traffic to S1 is wrong.
SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.
>
> Regards
> /MCruz
>
> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
> Sent: martes, 11 de febrero de 2014 11:57
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi maria-cruz,
>
> JJ agreed on the following approach:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>=20=20=20=20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
>=20=20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> What is the issue with this approach?
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9 : mardi 11 f=E9vrier 2014 11:49 =C0 : dime@ietf.org Objet : Re:=
 [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hello,
> I agree with JJ:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>
> [MCruz] And... if the request is sent to a Destination-Host, if there is =
any applicable OLR, it will be received immediately in the answer, and will=
 be applicable from next request on.
> Simple and robust in my opinion. Then, we do not need to evaluate whether=
 we have OLR for Realm and/or Host, and even check their validity & applica=
bility.
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
> Sent: lunes, 10 de febrero de 2014 15:00
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi Lionel=20
>
> Please see in line
>
> -----Message d'origine-----
> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9 =
: lundi 10 f=E9vrier 2014 14:25 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=
 dime@ietf.org Objet : RE: [Dime] [dime] #34: Semantics of OC-Report-Type A=
VP
>
> I disagree and my proposal was somehow misunderstood.
>
> I don't see the issue to have the following sequence:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>=20=20=20=20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
>=20=20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9 : lundi 10 f=E9vrier 2014 13:56 =C0 : dime@ietf=
.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear  all
>
> I share Ulrich and MCruz views,
> - Host OLR based control applies to requests where Destination Host is kn=
own
> - Realm OLR based control applies to requests where Destination Host is n=
ot known (only the Destination realm).
>
> I think it is simple, otherwise as MCruz indicated it complicates; e.g ab=
out the Ulrich's example where the Host S1 is not overloaded but the realm =
is overloaded. the client will not receive Host OLR reports from host S1 (s=
o no explicit traffic reduction requested by S1), but according to Lionel c=
omment, I understand  client will have to throttle the requests sent to S1 =
according to realm OLR, so how to avoid this.
>
> JJacques
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9 : vendredi 7 f=E9vrier 2014 17:15 =C0 : dime@ietf.org Objet : R=
e: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear all,
>
> I am in favor of the proposal made by Ulrich in the sequence diagram he p=
rovided.
> ----
> As a summary:
> Consequently the reacting node will receive realm type OLRs from the agen=
t and host type OLRs from the servers.
> The received realm type OLR will be relevant for the reacting node when s=
ending/throttling realm type requests; the received host type OLR will be r=
elevant for the reacting node       when sending/throttling host type reque=
sts.
> -----
>
> It may occur though, that a Client has only received Realm type OLR, and =
then it has to send a request to one specific host, then the Client will no=
t apply any restriction, but as soon as the response is received back, Clie=
nt will update Host type OLR.  Same will apply when only Host type OLR has =
been received by Client.
> The alternative will be to always send back from an Agent both Host OLR p=
lus Realm OLR, but I do not think this is necessary and may complicate the =
solution.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN=
 - DE/Munich)
> Sent: viernes, 07 de febrero de 2014 14:13
> To: ext Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Friday, February 07, 2014 11:21 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> I better like Lionel's approach, but even that is not ok in the unlikely=
 extreme case where we have two servers in a realm, S1 is not overloaded at=
 all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why s=
hould a client do a 25% throttling when sending host type requests to the n=
ot at all overloaded S1?
>> What is wrong with letting the client
>> -not throttle host-type requests to S1, -throttle host type request to
>> S2 with 50% and -throttle realm type requests wit 25%?
> Isn't this what Lionel said below?
>  no it is not
>  I am OK with Lionel's
> "wording" here.
>
> - Jouni
>
>>=20=20
>>=20=20
>>=20=20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
>> lionel.morand@orange.com
>> Sent: Wednesday, February 05, 2014 4:14 PM
>> To: Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20=20
>> I tend to agree except that I would reverse the logic as for the routing=
 principles: the Destination-host takes precedence when present over Destin=
ation-Realm. So the realm abatement is applied in any case except if there =
is an explicit report for the destination-host.
>>=20=20
>> Lioenl
>>=20=20
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet : R=
e:
>> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20=20
>> It makes more sense to me for a realm report to apply to all requests ta=
rgeted for that realm, independent the type of request.  This implies that =
it would apply to requests that also have a Destination-Host specified.
>>
>> If this is the definition of a realm report then we need to specify the =
interaction between realm reports and host reports.
>>
>> I propose that throttling would occur on the realm first and the host se=
cond.  If a message targetted for the host is throttled as a result of real=
m overload then that throttled message would count as part of the reduction=
 needed to address the host overload.  Messages to the host that survive re=
alm abatement would then be candidates for host overload.
>>
>> Steve
>>
>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
>> The case "Realm" as described below raises another question: is it prohi=
bited for a realm to only rely on a global overload report for the whole re=
alm, whatever the nodes inside this realm?
>> If not, only OLR with the report type "realm" would be received by the r=
eacting node. And the reduction indicated in the OLR will apply always for =
the realm, whatever the presence of Destination-host AVP in the request... =
except if an explicit report with the type "Host" as been received for this=
 destination-host.
>>=20=20
>> Does it make sense?
>>=20=20
>> Lionel
>>=20=20
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
>> =C0 : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>>=20=20
>> #34: Semantics of OC-Report-Type AVP
>>=20=20
>>  Text in clause 4.6  does not fully explain to which requests overload=
=20
>> treatment of a given report type applies.
>>  Proposal:
>>=20=20
>>     0  A host report.  The overload treatment should apply to requests
>>        for which all of the following conditions are true:
>>        a) The Destination-Host AVP is present in the request and its val=
ue
>>           matches the value of the Origin-Host AVP of the received messa=
ge
>>           that contained the OC-OLR AVP.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diameter
>>           Header of the received message that contained the OC-OLR AVP.
>>=20=20
>>=20=20
>>=20=20
>>     1  A realm report.  The overload treatment should apply to
>>        requests for which all of the following conditions are true:
>>        a) The Destination-Host AVP is absent in the request.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diameter
>>           Header of the received message that contained the OC-OLR AVP.
>>=20=20
>>=20=20
>> ______________________________________________________________________
>> ___________________________________________________
>>=20=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20=20
>> This message and its attachments may contain confidential or=20
>> 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 d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> 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
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

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.

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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From ulrich.wiehe@nsn.com  Tue Feb 11 07:31:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E433E1A0565 for ; Tue, 11 Feb 2014 07:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBEq8DRoXdre for ; Tue, 11 Feb 2014 07:31:44 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 60C5E1A0548 for ; Tue, 11 Feb 2014 07:31:40 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1BFVcCW022034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 16:31:38 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1BFVbNb000712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 16:31:37 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 16:31:37 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 16:31:37 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUA==
Date: Tue, 11 Feb 2014 15:31:36 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com>
In-Reply-To: <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 15600
X-purgate-ID: 151667::1392132698-00001A6F-EA51F3F1/0-0/0-0
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:31:49 -0000

Ben,
please see inline.

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Tuesday, February 11, 2014 1:14 AM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I don't quite agree with where I think this thread is going, on two points:

1) I want the reacting node to be able to learn if a (potentially) reportin=
g node supports DOIC, even when that node is not in overload. I don't want =
to specify any particular behavior for that knowledge, but I suspect implem=
entations may want to treat DOIC compliant servers in some way differently =
than they do non-DOIC servers. For example, I might have a configured rate =
limit for non-DOIC peers, but use a higher (or no) limit for peers that are=
 known to support DOIC (and can thus speak for themselves.)
sounds like a new requirement; where does it come from? I would hav=
e thought that there is no need to distinguish between
a) DOIC not supported and therefore no traffic reduction requested, and
b) DOIC supported, but not in overload and therefore no traffic reduction r=
equested=20

2) It's clumsy to have to look at an external (to OC-OLR) AVP to find out t=
he algorithm. I think the actual algorithm for a particular report should b=
e indicated in OC-OLR, not OC-Supported-Features at the root of the message=
.
I agree


Now, separate from those points, I think we should consider whether it's ok=
ay for a reporting nodes to switch algorithms mid-stream, vs pick an algori=
thm and stick with it. Right now, I think we effectively allow a reporting =
node to send an OLR for one algorithm in one answer, then another algorithm=
 in the next, even for the same reacting node. If so, we need to define wha=
t it means when that happens.

For example, if I receive an OLR with the "loss" algorithm, and another wit=
h the "rate" algorithm from the same server, does the second replace the fi=
rst? Do I now have two overload state entries that I need to "stack"?

Thanks!

Ben.

On Feb 10, 2014, at 9:07 AM, Steve Donovan  wrote=
:

> I'll attempt to summarize where we are on this.  If this is agreed to the=
n the necessary changes would be made to the -01 draft.  Some of this is al=
ready in the draft, some of it will require changes.
>=20
> - The draft already makes it optional for the reporting node to include t=
he OC-Supported-Features AVP in answer messages - No change required here.
>=20
> - A reporting node must choose the overload abatement algorithm to be sen=
t to a reacting node from the set of abatement algorithms included in the O=
C-Supported-Features AVP received in the request message.
>=20
> - If the reporting node sends an OC-OLR AVP and there is no OC-Supported-=
Features AVP then the abatement algorithm used by the reacting node must be=
 loss.
>=20
> - The reporting node may include the OC-Supported-Features AVP with the l=
oss algorithm indicated in the OC-Feature-Vector AVP.
>=20
> - If the reporting node wants the reacting node to apply an algorithm oth=
er then loss, the reacting node must include the OC-Supported-Features AVP =
with a single algorithm indicated in the OC-Feature-Vector AVP.=20
>=20
> - New abatement algorithm extensions may use and extend the existing OC-O=
LR AVP.  The new algorithms may also create a new overload report AVP if th=
at makes the most sense.
>=20
> - The loss algorithm is and always will be the mandatory to implement alg=
orithm.  Or it will be until a new RFC is published that changes the mandat=
ory to implement algorithm.
>=20
> Steve=20
>=20
> On 2/10/14 5:36 AM, lionel.morand@orange.com wrote:
>>=20
>> -----Message d'origine-----
>> De : Jouni Korhonen [
>> mailto:jouni.nospam@gmail.com
>> ]=20
>> Envoy=E9 : lundi 10 f=E9vrier 2014 12:24
>> =C0 : MORAND Lionel IMT/OLN
>> Cc :=20
>> dime@ietf.org
>>=20
>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messa=
ges
>>=20
>>=20
>> On Feb 10, 2014, at 1:15 PM,=20
>> 
>>  wrote:
>>=20
>>=20
>>> Hi Jouni,
>>>=20
>>>=20
>>>> As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.
>>>>=20
>>> Bah. OLR should work for additional abatement algorithms
>>> IF we agree that the OLR is align with the announced
>>> abatement algorithm..=20
>>>=20
>>> [LM] The issue if when you have more than one algo (let say 2). There i=
s no way for the reporting node to indicate the algo to use with the OLR se=
nt in the answer using the OC-Feature-Vector. The only info that you could =
have is "use either one or the other".
>>>=20
>> This we can fix (and I personally would like to fix). The reporting node
>> announces in its OC-Feature-Vector the selected common algorithm for the
>> sent OLR. We had this at some point of time, btw.
>>=20
>> [LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector M=
AY be used (when present) to indicate the algo to use, algo part of the com=
mon algos between the reporting node and the reacting node.
>>=20
>>=20
>>> The simpliest way would be to define a new AVP when you want to support=
 more than the default algo. If you want to rely on the same OLR with anoth=
er algo, you should have a way to indicate the algo to use with the given O=
LR.
>>>=20
>> I recall there was a strong arguments against algorithm types in OLRs..
>>=20
>> [LM] I was not proposing such idea :)
>>=20
>> - Jouni
>>=20
>>=20
>>>=20
>>>> It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.
>>>>=20
>>> It is already today if you only support the default, right.
>>>=20
>>> [LM] Right. No issue here.
>>>=20
>>> -----Message d'origine-----
>>> De : Jouni Korhonen [
>>> mailto:jouni.nospam@gmail.com
>>> ]=20
>>> Envoy=E9 : vendredi 7 f=E9vrier 2014 11:04
>>> =C0 : MORAND Lionel IMT/OLN
>>> Cc :=20
>>> dime@ietf.org
>>>=20
>>> Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer mess=
ages
>>>=20
>>>=20
>>> On Feb 4, 2014, at 5:01 PM,=20
>>> lionel.morand@orange.com
>>>  wrote:
>>>=20
>>>=20
>>>> I think that there is actually an issue here but the proposed way to s=
olve it is not the correct one.
>>>>=20
>>> Agree.
>>>=20
>>>=20
>>>> The initial idea was to be able to use the same overload report with s=
everal algorithms. So the OLR was somehow only meaningful along with the OC=
-Feature-Vector AVP.
>>>>=20
>>> The initial idea was to go on lines of RFC5447.
>>>=20
>>>=20
>>>> But because the OC-Feature-Vector AVP is defined as a set of flags, it=
 is not possible to say that this OLR is to be used with only one given alg=
o when more than one is defined (as the bit flags will advertize 1 AND 2 fo=
r 2 supported algos). So the OC-Feature-Vector cannot be used to indicate t=
he abatement to perform.
>>>>=20
>>> My intention was always allow:
>>>=20
>>>  client announces  ABC
>>>  server supports    BCD
>>>  server announced only  e.g. C since it is common
>>>  alternatively server announced nothing and then the default applies
>>>=20
>>>=20
>>>> As the syntax of the OC-Feature-Vector is adapted to advertize support=
ed algos, it could be easier to clarify that the OC-OLR AVP is THE report A=
VP for the reduction algo (default) and a new dedicated report AVP must be =
created when a new algo is introduced. In this way, the OC-OLR is self-expl=
icit.
>>>>=20
>>> Bah. OLR should work for additional abatement algorithms
>>> IF we agree that the OLR is align with the announced
>>> abatement algorithm..=20
>>>=20
>>>=20
>>>> It would be purely optional to send the Supported-Features AVP along w=
ith the OC-OLR AVP.
>>>>=20
>>> It is already today if you only support the default, right.
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>> Lionel=20
>>>>=20
>>>> -----Message d'origine-----
>>>> De : dime issue tracker [
>>>> mailto:trac+dime@trac.tools.ietf.org
>>>> ]=20
>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:48
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : [dime] #30: OC-Supported-Features AVP in answer messages
>>>>=20
>>>> #30: OC-Supported-Features AVP in answer messages
>>>>=20
>>>> According to the current feature advertisement/negotiation mechanism i=
n
>>>> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features =
AVP
>>>> in answer messages to indicate their supported OC features to the reac=
ting
>>>> DOIC endpoint.
>>>> The author of this document believes that  the best a reacting node ca=
n do
>>>> with such information is to ignore it, and therefore proposes to allow
>>>> reporting nodes not to insert OC-Supported-Features AVPs in answer
>>>> messages.
>>>> Currently only one feature is defined (OLR_DEFAULT_ALGO).
>>>> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no ot=
her
>>>> feature is only interested in receiving/not receiving OC-OLR AVPs from
>>>> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
>>>> support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not recei=
ving
>>>> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:
>>>>=20
>>>> a) There is no overload
>>>> b) DOIC is not supported
>>>>=20
>>>> The reacting DOIC endpoint does not need to differentiate between thes=
e
>>>> two cases as the behavior (do not throttle) is the same in both cases.
>>>> The -01 draft says in  clause 4.1:
>>>>   If there is no single matching
>>>>   capability the reacting node MUST act as if it does not implement
>>>>   DOIC and cease inserting any DOIC related AVPs into any Diameter
>>>>   messages with this specific reacting node.
>>>>=20
>>>> This however is inconsistent.
>>>> The reacting node that ceases sending DOIC related AVPs would never
>>>> recognize when the server is upgraded to support DOIC.
>>>> Subsequent requests (not including DOIC related AVPs) may take a diffe=
rent
>>>> path towards the server and on that path there may be an agent that
>>>> supports DOIC (with a match of supported features) and could take the =
role
>>>> of the reporting DOIC endpoint; but the agent cannot take this role si=
nce
>>>> the reacting node (although supporting DOIC) ceased sending of OC-
>>>> Supported-Features AVPs.
>>>> In summary: As long as no extension feature is defined within  draft-i=
etf-
>>>> dime-ovli  (i.e. never, since extensions will  be defined in other
>>>> drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
>>>> describe inclusion of OC-Supported-Features AVP in answer messages.
>>>>=20
>>>> --=20
>>>> --------------------------------------+--------------------------
>>>> Reporter: =20
>>>> lionel.morand@orange.com
>>>>   |      Owner:  Ulrich Wiehe
>>>>    Type:  defect                    |     Status:  new
>>>> Priority:  major                     |  Milestone:
>>>> Component:  draft-docdt-dime-ovli     |    Version:
>>>> Severity:  Active WG Document        |   Keywords:
>>>> --------------------------------------+--------------------------
>>>>=20
>>>> Ticket URL:=20
>>>> 
>>>>=20
>>>> dime=20
>>>> 
>>>>=20
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________________________________=
__________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations conf=
identielles 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 message=
s electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme=
 ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or privileged=
 information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>=20
>> ________________________________________________________________________=
_________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations confi=
dentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r=
ecu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages=
 electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>>=20
>> 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

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


From lionel.morand@orange.com  Tue Feb 11 07:35:29 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512581A054C for ; Tue, 11 Feb 2014 07:35:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hsld0BCPBse for ; Tue, 11 Feb 2014 07:35:21 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8FADC1A040B for ; Tue, 11 Feb 2014 07:35:20 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BAE343B40A8; Tue, 11 Feb 2014 16:35:19 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 926EA35C084; Tue, 11 Feb 2014 16:35:19 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 16:35:19 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjw///bTtD//37qYP/+4ahg
Date: Tue, 11 Feb 2014 15:35:18 +0000
Message-ID: <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E49A34EPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.11.81814
X-Mailman-Approved-At: Tue, 11 Feb 2014 07:36:22 -0800
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 15:35:29 -0000

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

QXQgbGVhc3QsIGl0IGlzIGNvcnJlY3QhIOKYug0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNCkVudm95
w6kgOiBtYXJkaSAxMSBmw6l2cmllciAyMDE0IDE1OjAwDQrDgCA6IGRpbWVAaWV0Zi5vcmcNCk9i
amV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQoNCkxpb25lbCwgTmlyYXYsIGFsbCwNCg0KTWF5YmUgdGhlIG5vdGUgY291bGQgYmUgbW9kaWZp
ZWQ6DQoNCk5vdGUg4oCTdGhlIHJlYWN0aW5nIG5vZGUgY291bGQgYmUgYW55IGFnZW50IGluIHRo
ZSBwYXRoLCBhbmQgdGhhdCBpbiBzb21lIGVycm9yIHNpdHVhdGlvbnMgb3ZlcmxvYWQgcmVwb3J0
cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLg0KDQpJIGFkZGVkIHRoZSBjYXNl
IE9MUiBjb3VsZCBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMsIHNpbmNlIGl0IGhpZ2hs
aWdodHMgYSBzaXR1YXRpb24gd2hlcmUgdGhlIHNlcnZlciB3aWxsIG5vdCBrbm93IHdoZXRoZXIg
b3Igbm90IGEgdmFsaWQgT0xSIGlzIHJlY2VpdmVkIGJ5IHJlYWN0aW5nIG5vZGUuDQoNCkJlc3Qg
cmVnYXJkcw0KL01DcnV6DQoNCg0KRnJvbTogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFttYWls
dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJv
IGRlIDIwMTQgMTE6MzYNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0K
U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCkF0IGxlYXN0LCBpdCBpcyBub3QgInRoZSBvbmx5IHN1cmUgd2F5Ii4NCkZvciBpbnN0
YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdlcyBwYXJ0IG9mIHRoZSBzYW1lIHNlc3Npb24gKG9yIHBz
ZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNvIGJlIHVzZWQgYXMgaW5kaWNhdGlvbiBmb3IgdGhlIHJl
cG9ydGluZyBub2RlIHRoYXQgdGhlIE9MUiBoYXMgYmVlbiByZWNlaXZlZCBieSB0aGUgcmVhY3Rp
bmcgbm9kZSAoYmVzaWRlcyB0aGUgcmVjZXB0aW9uIG9mIHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZXMgaW4gdGhlIHJlcXVlc3QpLg0KSXQgaXMgd2h5IEkgd2FzIHNheWluZyB0aGF0IHRoaXMgY2Fu
IGJlIGZpeGVkIHBlciBhcHBsaWNhdGlvbi9zeXN0ZW0uDQoNCkxpb25lbA0KDQpEZSA6IERpTUUg
W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBC
YXJ0b2xvbWUNCkVudm95w6kgOiBtYXJkaSAxMSBmw6l2cmllciAyMDE0IDExOjMxDQrDgCA6IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpGaW5lIE5pcmF2LCBJIGFn
cmVlIHRoaXMgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpNeSBpbnRlbnRpb24gaXMgdGhh
dCBhbnkgcmVhZGVyIHJlYWxpemVzIHdoYXQgdGhpcyBrbm93bGVkZ2UgaW4gdGhlIHNlcnZlciBp
bXBsaWVzIHdoZW4gd2UgdGFsayBhYm91dCBhZ2VudHMgaW4gdGhlIHBhdGguIFRoaXMgaXMgd2h5
IEkgdGhpbmsgdGhpcyBub3RlIGlzIGhlbHBmdWwuDQoNClJlZ2FyZHMNCi9NQ3J1eg0KDQpGcm9t
OiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQpTZW50OiBt
YXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyNg0KVG86IE1hcmlhIENydXogQmFydG9s
b21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgZG8gbm90
IGFncmVlIHJlZ2FyZGluZyB0aGUgY29tcGxleGl0eSBzaW5jZSBpdCBpcyBoaWdobHkgaW1wbGVt
ZW50YXRpb24gc3BlY2lmaWMuDQpMZXRzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBw
cm90b2NvbCBkZXNpZ24uDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21l
DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCAzOjU0IFBNDQpUbzogZGltZUBpZXRm
Lm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpIZWxsbywNCg0KSSB0aGluayBpdCBp
cyBpbXBvcnRhbnQgdG8gaGlnaGxpZ2h0IGNvbXBsZXhpdHkgZm9yIHRoZSBzZXJ2ZXIgdG8gIOKA
nGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRo
ZSBvdmVybG9hZCByZXBvcnQu4oCdDQpJIHRoaW5rIHRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhl
IHNlbnRlbmNlIGFkZGVkIGJ5IFN0ZXZlLg0KDQpDaGVlcnMNCi9NQ3J1eg0KDQpGcm9tOiBEaU1F
IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmlyYXYgU2Fsb3Qg
KG5zYWxvdCkNClNlbnQ6IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIwDQpUbzog
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+
OyBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQoNCkkgYW0gYWxzbyBmaW5lIHdpdGggU3RldmUncyBwcm9wb3NlZCB3b3JkaW5nIHRvIHJlY29t
bWVuZCB0aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQgdG8gbm90IG1hbmRhdGUgaXQuDQoNCkkgYW0g
bm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5l
Y2Vzc2FyeSB0byBhZGQgaXQuDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJv
cHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVj
ZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBj
bGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJl
cG9ydGluZyBub2RlLg0KDQpJIHByZWZlciB0byByZW1vdmUgaXQgc2luY2UgSSBkbyBub3Qgc2Vl
IGFzIHZhbHVlIGFkZGl0aW9uLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9y
YW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4NClNlbnQ6IE1vbmRheSwg
RmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE0NClRvOiBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYu
b3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkknbSBmaW5lIHdpdGggYSByZWNvbW1l
bmRhdGlvbi4NCg0KQnV0IEkgaGF2ZSBhIGdlbmVyYWwgY29tbWVudDogd2hlbiBhIE1BWSBvciBl
dmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgTk9UIHVwIHRv
IHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0byBkbyBzb21ldGhpbmcuIEl0IGRvZXMgbm90IG1lYW4g
dGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi4NCkZvciBpbnN0YW5jZSwg
b3ZlciBhIGdpdmVuIGludGVyZmFjZSwgdGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5
IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1haW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNv
dWxkIGJlIGRlY2lkZWQgdG8gYWRkIHNvbWUgb3ZlcmxvYWQgcmVsYXRlZCBpbmZvIGluIHN1Y2gg
c3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0
byBrbm93IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5z
dGFuY2UuIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGlu
Y2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVzc2FnZS4gSXQgaXMganVzdCBmb3IgaWxsdXN0cmF0aW9u
LiBUaGUgcG9pbnQgaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhl
IE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLg0KDQpJIGFncmVlIHRo
YXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIGlzIGZpbmXigKYgYnV0IGl0IHNob3Vs
ZCBiZSBub3QgbWFuZGF0b3J5IGluIGFsbCBjYXNlcyBJIHRoaW5rLiBTbyBPSyBmb3IgYSAiU0hP
VUxEIiBvciAiUkVDT01NRU5ERUQiLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KRGUgOiBEaU1F
IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92
YW4NCkVudm95w6kgOiBsdW5kaSAxMCBmw6l2cmllciAyMDE0IDE3OjIxDQrDgCA6IGRpbWVAaWV0
Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJIGFncmVlIHdpdGggYm90aCBNYXJp
YSBDcnV6IGFuZCBOaXJhdi4gOi0pDQoNCkkgc3VnZ2VzdCB0aGF0IHdlIGhhdmUgd29yZGluZyBz
YXlpbmcgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIHRvIGluY2x1ZGUgdGhlIG92ZXJsb2Fk
IHJlcG9ydCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBi
eSBNYXJpYSBDcnV6Lg0KDQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBw
cm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0aW5nIG5v
ZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNo
b29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4gIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBpbmNs
dWRpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyBidXQgd2Ug
c2hvdWxkIGluY2x1ZGUgd29yZGluZyBhYm91dCBuZXR3b3JrcyBhcmNoaXRlY3R1cmVzIHRoYXQg
bWFrZSBpdCBkaWZmaWN1bHQgdG8ga25vdy4gIFRoZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMg
cmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1w
bGUuDQoNCldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQgYXBw
cm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLg0KDQpJIHByb3Bvc2Ug
dGhlIGZvbGxvd2luZyBub3JtYXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRl
ZCBieSBNYXJpYSBDcnV6J3MgcmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJs
b2FkIHJlcG9ydCBpcyBhbHdheXMgaW5jbHVkZWQuDQoNCi0tLS0tDQoNCkEgcmVwb3J0aW5nIG5v
ZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3Zlcmxv
YWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGlu
Y2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVh
Y3Rpbmcgbm9kZXMuDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVk
ZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFj
dGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiAgVGhlIG92ZXJsb2FkIHJlcG9y
dCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBz
dXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBh
biBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUg
dGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQg
cmVwb3J0Lg0KDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkg
bWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4g
b3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5k
IHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBu
b2RlLg0KT24gMi8xMC8xNCAzOjUyIEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZToNCg0K
SGVsbG8gTmlyYXYsDQoNCg0KDQpBbnkgc29sdXRpb24gc2hvdWxkIGJhbGFuY2UgZGlmZmVyZW50
IGZhY3RvcnMsIGVmZmljaWVuY3kgY291bGQgYmUgZGlzY3Vzc2VkIGZyb20gZGlmZmVyZW50IHBl
cnNwZWN0aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQgdG8gYXNzdXJlIHRoZSBtZWNoYW5pc20gd2Ug
YXJlIGRlZmluaW5nIGlzIHByb3ZpZGluZyB2YWxpZCBPTFIgdG8gcmVhY3Rpbmcgbm9kZXMuDQoN
Cg0KDQpZb3VyIHByb3Bvc2VkIHRleHQNCg0KIiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2Vz
LCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3Zlcmxv
YWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSBy
ZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhl
IHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KDQoNCg0KSWYg
dGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQg
cmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAo
c2luY2UgaXQgaXMgYSAibWF5IikgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBv
dmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdh
cyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rp
bmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxk
IGJlIG5vdCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAo
bm90IG9ubHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwg
YnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xp
ZW50KS4NCg0KVGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93IHdoZW4g
cmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJlbG93KSwg
YnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQgIm1heSIp
IHRoZW4gb25lIG9yIG11bHRpcGxlIHJlYWN0aW5nIG5vZGVzIGRvIG5vdCBoYXZlIHRoZSByZXF1
aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlvbiB3aWxsIG5vdCB3b3JrLg0KDQoNCg0K
VGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVx
dWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuDQoNCg0K
DQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21d
DQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDINCg0KVG86IE1hcmlh
IENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpT
dWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcNCg0KDQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQoNCg0KSG93IGNhbiB3ZSBzYXkgdGhhdCAiaW5j
bHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMgaXMgc2ltcGxlIGFuZCBl
ZmZpY2llbnQ/Ig0KDQpJdCBpcyBzaW1wbGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuDQoN
Cg0KDQpBIHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVh
cmxpZXIgaXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBv
cnQgdGhhdCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0
aW5nIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcg
dGhlIG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRl
IE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9y
dGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUu
IEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5v
ZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRl
ZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRo
ZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQoNClNlbnQ6IE1vbmRh
eSwgRmVicnVhcnkgMTAsIDIwMTQgMzowMyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpOaXJhdiwgYWxsLA0KDQoNCg0KSSB0aGluayB3
ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVmZmlj
aWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KDQpJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3Nh
bCBhcyBhIHB1cmUgIm1heSIsIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRv
ZXMgbm90IGFzc3VyZSByZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdo
YXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuDQoNCg0KDQpCZXN0IHJlZ2Fy
ZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBO
aXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IGx1
bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6MTINCg0KVG86IE1hcmlhIENydXogQmFydG9s
b21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk1h
cmlhLUNydXosDQoNCg0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91IG9uICJzZW5kaW5nIE9MUiBp
biBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlcyIuDQoNCkFuZCB3ZSBh
cmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBteSBpbnRlbnRp
b24uDQoNCkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50
IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIg
YW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBt
ZXNzYWdlPw0KDQoNCg0KTW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRp
b24gb2Ygb3ZlcmxvYWQgY29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2Vy
IG1lc3NhZ2VzLg0KDQpCdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0
cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vh
a3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2
ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQg
YXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLg0K
DQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KDQoNClRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1
Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0
aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJh
di4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9t
ZQ0KDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE0NCg0KVG86IGRpbWVA
aWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSGVsbG8gVWxyaWNo
LCBOaXJhdiwNCg0KDQoNCkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBwcm92aWRl
ZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNlcnZlciBz
ZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVkuDQoNCg0K
DQpPbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4g
T0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdl
Og0KDQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBo
YXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlz
IG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25v
d3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBl
eHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoNCg0KDQpSZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29t
ZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4g
SG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBrbm93bGVkZ2U/DQoNClRha2UgaW50byBhY2Nv
dW50IGFzIHdlbGwgdGhhdCBhICJyZWFjdGluZyIgbm9kZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAo
aW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2aWNlIHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFs
ZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkgIGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ug
b2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBp
cyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwg
aW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBh
Ym91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC4NCg0KDQoN
ClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFu
c3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXM6DQoNCi0gc3RhdGUtbGVzcyBpbXBs
ZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikgaXMgc2ltcGxlciwNCg0KLSB0aGUg
c2VydmVyIGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQg
YW4gT0wgdG8gYSByZWFjdGluZyBub2RlDQoNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRv
IGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4g
T0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCku
DQoNCi0gc2VuZGluZyBhbiBhZGRpdGlvbmFsIEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1p
bmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMg
bm90IHNlbnQpLg0KDQogIEluIGZhY3QsIGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwgdGhlIGVh
c2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQgdG8gYWxs
IGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsDQoNCiAgYW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRh
a2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbnMNCg0KLSBtb3JlIHJvYnVzdCBzb2x1
dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVja3Mgb24gdGhlIG5lZWQg
dG8gc2VuZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNz
YWdlIGlzIGxvc3QsICDigKYNCg0KDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVu
aWNoKQ0KDQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTkNCg0KVG86
IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxt
YWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVA
aWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsDQoNCg0K
DQpJJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRl
bnRpb24uDQoNCg0KDQoid2hlbiBpdCB3YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFs
bCBpbmNsdWRlLi4uIiB0cmFuc2xhdGVzIHRvICIuLi5pdCBtYXkgaW5jbHVkZS4uLiIuDQoNCg0K
DQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gIndo
ZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQoNCg0KDQpXZSBo
YXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6DQoNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0
aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0KDQpi
KSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2Fu
dCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3Qg
YW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KDQpjKSBvdGhlcndpc2UNCg0KDQoNCmluIGNh
c2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGlu
IGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJl
YWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcg
bm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5v
ZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKQ0K
DQoNCg0KVWxyaWNoDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJv
bTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NCg0K
U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkgUE0NCg0KVG86IFdpZWhlLCBV
bHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNClVscmljaCwNCg0KDQoN
Ckl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJvcG9z
ZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuDQoNCkhvdyBhYm91dCB0aGUgZm9sbG93
aW5nLg0KDQoNCg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcg
b3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBv
dmVybG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUg
T0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4g
QWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9k
ZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVk
IHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhl
IE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9y
dGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5p
Y2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJy
dWFyeSAwNiwgMjAxNCAzOjU3IFBNDQoNClRvOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBOaXJhdiBTYWxvdCAobnNhbG90KTsg
ZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoN
ClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQoNCg0KTmlyYXYsIExpb25lbCwNCg0KDQoNCkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYn
cyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVz
c2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lwbGUgMic6DQoNCg0KDQoyJy4gdGhlIHJlcG9ydGlu
ZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBu
b3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWlu
ZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJl
YWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29udHJvbCBp
bmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1
ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9h
ZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24gZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9ydGluZyBu
b2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2Fy
ZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9y
IG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBj
b250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KSSBkb24ndCBhZ3Jl
ZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJv
bCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1
cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUg
b2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0K
DQoNClVscmljaA0KDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpG
cm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9y
YW5nZS5jb20+IFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KDQpTZW50OiBUaHVy
c2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fs
b3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3Zhbjsg
ZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQoNCg0KDQoN
Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nD
qSA6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgCA6IFdpZWhlLCBVbHJpY2ggKE5TTiAt
IERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1l
QGlldGYub3JnPiBPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQoNCg0KVWxyaWNoLA0KDQoNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBm
b3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBp
ZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRo
ZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8g
cmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQoN
ClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0
aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5n
IG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZmaWMuDQoNCg0KDQpbTE1dIEFncmVl
LiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1
bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJl
cG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5
IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBs
ZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLg0KDQoNCg0KQXMgd2UgaGFkIGRp
c2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUg
dG8gZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRo
ZSBzYW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93
IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9m
IHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0Lg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoN
Cg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2Rl
IGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBi
YWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0byBpbmNsdWRlIE9MUiBp
ZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9uLg0KDQoNCg0KW0xNXSBB
Z3JlZQ0KDQoNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1l
Lg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N
dW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBG
ZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNDQoNClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYg
U2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1
YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
Zw0KDQoNCg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxlczoNCg0K
MS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5nZSINCg0KMi4gdGhlIHJlcG9ydGluZyBub2Rl
IChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8g
cmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4g
T0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUgYW4gT0xS
IHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92
ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBv
cnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0
dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0u
DQoNCg0KDQpVbHJpY2gNCg0KDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KDQpTZW50OiBXZWRuZXNkYXks
IEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBk
aW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkFncmVlZC4g
IFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdl
IHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS4gIElmIHRo
ZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51
ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNo
YW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCByZXBvcnQuICBJZiB0aGVyZSBpcyBubyBjdXJyZW50
bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0
IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS4NCg0K
DQoNClN0ZXZlDQoNCk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90
ZToNCg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFj
ayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KDQoNCg0KV2UgaGFk
IHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVh
c29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBl
dmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0
cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBh
dm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMg
b3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUg
cHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuDQoNCg0KDQpTbyBiYXNpY2Fs
bHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNl
aXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250
aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUg
dmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBvdmVybG9h
ZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQoNCkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4
aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRs
aW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2
Lg0KDQoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIFN0ZXZlIERvbm92YW4NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAx
NCA4OjAwIFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpT
dWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcNCg0KDQoNCmlubGluZQ0KDQpPbiAyLzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNO
IC0gREUvTXVuaWNoKSB3cm90ZToNCg0KT2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGlu
ZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMg
dGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1T
dXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVx
dWVzdGVkKS4NCg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/ICBTaG91bGRuJ3Qg
bGFjayBvZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KDQoN
Cg0KDQoNCg0KDQpPdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVt
IHRvIG1hdHRlci4NCg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5
IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFuIG92ZXJs
b2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29yaywgcG90
ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4NCg0KDQoNCg0KDQoN
Cg0KDQoNCkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5v
ZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAo
bW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJl
IGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2Yg
cmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28g
bWlzcyBhIG5ldyBPTFI/DQoNClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVu
Y2UgbnVtYmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy
eSAwNSwgMjAxNCA1OjI3IEFNDQoNClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRv
Omxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0
Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQoNCg0KSSBzaGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExpb25lbC4N
Cg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2Uu
Y29tPg0KDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQoNClRvOiBk
aW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkkgdW5kZXJz
dGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9F
UyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLg0KDQpTbyB0aGUgb3B0aW9ucyB3
b3VsZCBiZToNCg0KMS0gT0MtT0xSIEFWUCBpbiBldmVyeSBhbnN3ZXINCg0KMi0gT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNv
bWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNs
aWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQoNCg0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3Jp
dGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9hY2guDQoNCg0KDQpMaW9u
ZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IGRpbWUgaXNzdWUg
dHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0KDQpFbnZvecOp
IDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5DQoNCsOAIDogTU9SQU5EIExpb25lbCBJTVQv
T0xODQoNCkNjIDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KT2JqZXQg
OiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQojMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0
byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMgIHRvIGJl
IGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0
aGUgU2VxdWVuY2UtTnVtYmVyDQoNCiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0
byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQoNCiBzdXJ2aXZlZCkgaXMgcGVyZm9y
bWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyAgdGhy
b3R0bGluZyBpcyBwZXJmb3JtZWQuICBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0
aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5l
ZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3Qg
T0xSLg0KDQogQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQg
aW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVwb3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBp
biBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCBjYW5ub3Qga25v
dyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nICB0
aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4N
Cg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxv
d3MgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5h
cHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZyAgRE9JQyBlbmRwb2ludCAoY2F1
c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQoNCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28g
YWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjguDQoNCiBJbiBzdW1tYXJ5IGl0
IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IHRvICBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcuDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRp
TUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg
cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2
aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg
b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl
IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl
dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv
bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRv
dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91
IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz
IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg
bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg
dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNl
aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl
bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBi
ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl
ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1h
aWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0K
RGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8
bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGll
dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50
IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl
cyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj
b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy
IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0
cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u
aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUg
dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg
b3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh
dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1
dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZl
IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh
bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMg
bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh
dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj
b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg
ZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w
aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl
cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1
aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx
dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRv
dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91
IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz
IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg
bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl
ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k
IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1h
eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl
IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk
ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p
dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0
b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls
bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs
ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl
cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl
IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K
ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7
CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh
dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw
bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh
dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs
ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm
aWVkLgpUaGFuayB5b3UuCgo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx
IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN
CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg
MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6MiAyIDYg
MyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBk
aXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5
bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25z
b2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxl
LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1M
UHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRN
TCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy
IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6Ymxh
Y2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ
cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6
YmxhY2s7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5CYWxsb29uVGV4dA0K
CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsN
Cgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi
QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7
DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0
OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpzcGFu
LkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw
YW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46
NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n
PSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCwgaXQgaXMgY29ycmVjdCENCjwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFyaWEgQ3J1
eiBCYXJ0b2xvbWU8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgMTEgZsOpdnJpZXIg
MjAxNCAxNTowMDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gZGltZUBpZXRmLm9yZzxicj4NCjxiPk9i
amV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5M
aW9uZWwsIE5pcmF2LCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1h
eWJlIHRoZSBub3RlIGNvdWxkIGJlIG1vZGlmaWVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZx
dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KTm90ZSDigJN0aGUgcmVhY3Rpbmcgbm9kZSBj
b3VsZCBiZSBhbnkgYWdlbnQgaW4gdGhlIHBhdGgsIGFuZCB0aGF0IGluIHNvbWUgZXJyb3Igc2l0
dWF0aW9ucyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9k
ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWRkZWQgdGhl
IGNhc2UgT0xSIGNvdWxkIGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlcywgc2luY2UgaXQg
aGlnaGxpZ2h0cyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmVyIHdpbGwgbm90IGtub3cgd2hl
dGhlciBvciBub3QgYSB2YWxpZA0KIE9MUiBpcyByZWNlaXZlZCBieSByZWFjdGluZyBub2RlLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
d2luZG93dGV4dCI+IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSBbbWFpbHRvOmxpb25lbC5tb3Jh
bmRAb3JhbmdlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8g
ZGUgMjAxNCAxMTozNjxicj4NCjxiPlRvOjwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVA
aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF0IGxlYXN0LCBpdCBpcyBu
b3QgJnF1b3Q7dGhlIG9ubHkgc3VyZSB3YXkmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIHN1YnNlcXVlbnQgbWVzc2FnZXMgcGFy
dCBvZiB0aGUgc2FtZSBzZXNzaW9uIChvciBwc2V1ZG8tc2Vzc2lvbikgY291bGQgYWxzbyBiZSB1
c2VkIGFzIGluZGljYXRpb24gZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0aGF0IHRoZQ0KIE9MUiBo
YXMgYmVlbiByZWNlaXZlZCBieSB0aGUgcmVhY3Rpbmcgbm9kZSAoYmVzaWRlcyB0aGUgcmVjZXB0
aW9uIG9mIHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgaW4gdGhlIHJlcXVlc3QpLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgd2h5IEkgd2FzIHNheWlu
ZyB0aGF0IHRoaXMgY2FuIGJlIGZpeGVkIHBlciBhcHBsaWNhdGlvbi9zeXN0ZW0uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8
YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxMTozMTxi
cj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpbmUgTmlyYXYsIEkgYWdyZWUgdGhpcyBpcyBpbXBsZW1l
bnRhdGlvbiBzcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPk15IGludGVudGlvbiBpcyB0aGF0IGFueSByZWFkZXIgcmVhbGl6ZXMgd2hhdCB0aGlzIGtu
b3dsZWRnZSBpbiB0aGUgc2VydmVyIGltcGxpZXMgd2hlbiB3ZSB0YWxrIGFib3V0IGFnZW50cyBp
biB0aGUgcGF0aC4gVGhpcyBpcyB3aHkgSSB0aGluayB0aGlzDQogbm90ZSBpcyBoZWxwZnVsLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7
cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij4gTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0bzpuc2Fs
b3RAY2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50
OjwvYj4gbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjY8YnI+DQo8Yj5Ubzo8L2I+
IE1hcmlhIENydXogQmFydG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGlt
ZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkkgZG8gbm90IGFn
cmVlIHJlZ2FyZGluZyB0aGUgY29tcGxleGl0eSBzaW5jZSBpdCBpcyBoaWdobHkgaW1wbGVtZW50
YXRpb24gc3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYx
Ij5MZXRzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7
cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
ZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
Pk1hcmlhIENydXogQmFydG9sb21lPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5
IDExLCAyMDE0IDM6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll
dGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgaXQgaXMg
aW1wb3J0YW50IHRvIGhpZ2hsaWdodCBjb21wbGV4aXR5IGZvciB0aGUgc2VydmVyIHRvICZuYnNw
O+KAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1
b3Q7c2VyaWYmcXVvdDsiPmd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZw0KIG5vZGUgYWxyZWFk
eSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0NCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlzIGlzIHRoZSBwdXJw
b3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRlZCBieSBTdGV2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBb
PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNl
c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5pcmF2IFNhbG90IChuc2Fsb3Qp
PGJyPg0KPGI+U2VudDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIwPGJy
Pg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5s
aW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBTdGV2ZSBEb25vdmFuOw0KPGEgaHJlZj0ibWFp
bHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj5JIGFtIGFsc28gZmluZSB3aXRoIFN0ZXZlJ3MgcHJvcG9zZWQgd29yZGluZyB0
byByZWNvbW1lbmQgdGhlIGluY2x1c2lvbiBvZiBPTFIgYnV0IHRvIG5vdCBtYW5kYXRlIGl0Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIGFtIG5vdCBzdXJlIGFib3V0IHRo
ZSBmb2xsb3dpbmcgdGV4dCwgaWYgaXQgaXMgYWJzb2x1dGVseSBuZWNlc3NhcnkgdG8gYWRkIGl0
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Tm90ZSAt
IHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtu
b3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBp
cyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2Vu
dCBiZXR3ZWVuIHRoZSBjbGllbnQNCiBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIHByZWZlciB0byByZW1vdmUgaXQgc2lu
Y2UgSSBkbyBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMyNDQwNjEiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQw
NjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g
MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlN
RSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzps
aW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT48YnI+
DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAxMDoxMyBQTTxicj4NCjxi
PlRvOjwvYj4gU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRp
bWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JJ20gZmluZSB3
aXRoIGEgcmVjb21tZW5kYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkJ1dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1lbnQ6IHdoZW4gYSBNQVkgb3IgZXZlbiBhIFNIT1VM
RCBhcHBseSwgaXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIE5PVCB1cCB0byB0aGUgbm9kZSB0
byBkbyBvciBub3QgdG8gZG8gc29tZXRoaW5nLiBJdA0KIGRvZXMgbm90IG1lYW4gdGhhdCBpdCBp
cyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgb3ZlciBhIGdpdmVuIGludGVyZmFjZSwg
dGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1h
aW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNvdWxkIGJlIGRlY2lkZWQNCiB0byBhZGQg
c29tZSBvdmVybG9hZCByZWxhdGVkIGluZm8gaW4gc3VjaCBzdGF0ZXMuIEZvciBpbnN0YW5jZSBh
Z2FpbiwgdGhlIG5vZGUgY2FuIHVzZSB0aGlzIHN0YXRlIHRvIGtub3cgaWYgYSByZW1vdGUgbm9k
ZSBoYXZlIGJlZW4gbm90aWZpZWQgb3Igbm90IGZvciBpbnN0YW5jZS4gQW5kIGluIHN1Y2ggYSBj
YXNlLCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaW5jbHVkZSBhbiBPTFIgaW4gZWFjaCBt
ZXNzYWdlLiBJdCBpcyBqdXN0IGZvcg0KIGlsbHVzdHJhdGlvbi4gVGhlIHBvaW50IGlzIHRoYXQg
eW91IG1heSBoYXZlIHNvbWUgY2FzZXMgZm9yIHdoaWNoIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2Vy
IG1pZ2h0IG5vdCBiZSByZXF1aXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSBhZ3JlZSB0aGF0IGhhdmluZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l4oCm
IGJ1dCBpdCBzaG91bGQgYmUgbm90IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4gU28g
T0sgZm9yIGEgJnF1b3Q7U0hPVUxEJnF1b3Q7IG9yICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNw
Ozo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
ZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9i
PiBTdGV2ZSBEb25vdmFuPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGx1bmRpIDEwIGbDqXZy
aWVyIDIwMTQgMTc6MjE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaW1l
QGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPk9iajwvYj48L3NwYW4+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ZXQmbmJzcDs6PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvDQogQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPkkgYWdyZWUgd2l0aCBib3RoIE1hcmlhIENydXogYW5kIE5pcmF2LiA6LSk8YnI+
DQo8YnI+DQpJIHN1Z2dlc3QgdGhhdCB3ZSBoYXZlIHdvcmRpbmcgc2F5aW5nIHRoZSByZWNvbW1l
bmRlZCBhcHByb2FjaCBpcyB0byBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYWxsIHJl
c3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQgYnkgTWFyaWEgQ3J1ei4mbmJz
cDsNCjxicj4NCjxicj4NCkkgYWxzbyBzdWdnZXN0IHRoYXQgd2UgaW5jbHVkZSBOaXJhdidzIHBy
b3Bvc2FsIHRoYXQgaWYgYSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IGEgcmVhY3Rpbmcgbm9k
ZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBtYXkgY2hv
b3NlIHRvIG5vdCBzZW5kIGl0IGFnYWluLiZuYnNwOyBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8g
aW5jbHVkaW5nIGFueXRoaW5nIGFib3V0IGhvdyB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MNCiBi
dXQgd2Ugc2hvdWxkIGluY2x1ZGUgd29yZGluZyBhYm91dCBuZXR3b3JrcyBhcmNoaXRlY3R1cmVz
IHRoYXQgbWFrZSBpdCBkaWZmaWN1bHQgdG8ga25vdy4mbmJzcDsgVGhlIGNhc2Ugb2YgYWdlbnRz
IGFjdGluZyBhcyByZWFjdGluZyBub2RlcyBmb3Igbm9uIHN1cHBvcnRpbmcgY2xpZW50cyBiZWlu
ZyBvbmUgZXhhbXBsZS48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUg
dGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidz
IHByb3Bvc2FsLjxicj4NCjxicj4NCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSB3
b3JkaW5nLCB3aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFzb25z
IGZvciByZWNvbW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBpbmNs
dWRlZC48YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBl
bnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0
cy48YnI+DQo8YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5j
bHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFj
dGluZyBub2Rlcy4mbmJzcDsNCjxicj4NCjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUg
bWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBz
ZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNw
OyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIg
bm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBu
b2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rp
bmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFk
eSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48YnI+DQo8YnI+DQpOb3RlIC0gdGhl
IG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0
aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdo
ZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJl
dHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzEwLzE0IDM6NTIgQU0sIE1h
cmlhIENydXogQmFydG9sb21lIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkhlbGxvIE5pcmF2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Bbnkg
c29sdXRpb24gc2hvdWxkIGJhbGFuY2UgZGlmZmVyZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291
bGQgYmUgZGlzY3Vzc2VkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdl
IG5lZWQgdG8gYXNzdXJlIHRoZSBtZWNoYW5pc20gd2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGlu
ZyB2YWxpZCBPTFIgdG8gcmVhY3Rpbmcgbm9kZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPllvdXIgcHJvcG9zZWQgdGV4dCZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZxdW90OyBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdo
ZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0
IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcg
bm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3Qg
Y29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuJnF1b3Q7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPklmIHRoZSByZXBvcnRpbmcgaXMgbm90IGF3YXJlIGFib3V0IHdoZXRo
ZXIgb3Igbm90IG92ZXJsb2FkIHJlcG9ydCBpcyBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9k
ZSwgYW5kIGl0IGRlY2lkZXMgKHNpbmNlIGl0IGlzIGEgJnF1b3Q7bWF5JnF1b3Q7KSB0byBkbyBu
b3Qgc2VuZCB0aGUgT0xSIGFnYWluLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gbWVjaGFuaXNt
IHdpbGwgbm90IHdvcmsgaW4gY2FzZSBPTFIgd2FzIG5vdCBwcm9wZXJseSByZWNlaXZlZCBieSBj
b3JyZXNwb25kaW5nIHBvdGVudGlhbCByZWFjdGluZyBub2Rlcy4gQW5kIHdlIG5lZWQgdG8gbm90
ZSB0aGF0ICZxdW90O3JlYWN0aW5nIG5vZGVzJnF1b3Q7IGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBj
bGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUg
YWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVh
Y3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4gPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVuLCBvbiBvbmUgaGFuZCBpdCBpcyBub3Qg
c2ltcGxlIHRvIGtub3cgd2hlbiByZWFjdGluZyBub2RlcyBoYXZlIHZhbGlkIE9MUiBpbmZvIChh
cyBleHBsYWluZWQgYmVsb3cpLCBidXQgaWYgT0xSIGlzIG5vdCBzZW50IGFnYWluIChhcyBwZXIg
eW91ciBwcm9wb3NlZCAmcXVvdDttYXkmcXVvdDspIHRoZW4gb25lIG9yIG11bHRpcGxlIHJlYWN0
aW5nIG5vZGVzIGRvIG5vdCBoYXZlIHRoZSByZXF1aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQgbWl0
aWdhdGlvbiB3aWxsIG5vdCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVy
ZWZvcmUsIGluIG15IG9waW5pb24sIHRoZSBzaW1wbGVzdCB3YXkgdG8gcHJvdmlkZSByZXF1aXJl
ZCBpbmZvcm1hdGlvbiBpcyB0byBwcm92aWRlIE9MUiBpbiBBTEwgYW5zd2Vycy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90
QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XSA8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIw
MTQgMTA6NDI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBNYXJp
YSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0
Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0
OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QnV0IE1hcmlhLUNydXosPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPkhvdyBjYW4gd2Ugc2F5IHRoYXQgJnF1b3Q7aW5jbHVkaW5nIHRoZSBP
TFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMgaXMgc2ltcGxlIGFuZCBlZmZpY2llbnQ/JnF1
b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCBpcyBzaW1wbGUg
Zm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5BIHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVhcmxp
ZXIgaXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQg
dGhhdCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5n
IHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhl
IG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9M
UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFk
ZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg
aXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0
byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBP
TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u
IEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+U2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAzOjAzIFBNPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRv
OmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYs
IGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB0aGluayB3ZSBzaG91bGQgZGVm
aW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVudCBhbmQgc2lt
cGxlIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
SSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwgYXMgYSBwdXJlICZxdW90O21heSZxdW90OywgYnV0
IGxlYXZpbmcgaXQgdXAgdG8gaW1wbGVtZW50YXRpb24gZG9lcyBub3QgYXNzdXJlIHJlYWN0aW5n
IG5vZGUgaGFzIHZhbGlkIE9MUiBpbmZvcm1hdGlvbiwgd2hhdCBpcyBiYXNpYyBmb3IgdGhpcyBt
ZWNoYW5pc20gdG8gd29yay4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QgcmVn
YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+L01DcnV6PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBOaXJhdiBTYWxvdCAobnNh
bG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lz
Y28uY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6
IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6MTI8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPlRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFp
bHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TWFy
aWEtQ3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBmdWxseSBhZ3JlZSB3aXRo
IHlvdSBvbiAmcXVvdDtzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRh
bnQgYWR2YW50YWdlcyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPkFuZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBp
cyBteSBpbnRlbnRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
QnV0IHRoZSBtYWluIHF1ZXN0aW9uIGlzLCBhcmUgd2UgdHJ5aW5nIHRvIHByZXZlbnQgYW55IG90
aGVyIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uLCB3aGljaCBtYXkgYmUgc21hcnRlciBhbmQgY2Fu
IGF2b2lkIGluY2x1ZGluZyByZWR1bmRhbnQgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2U/
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1vc3QgcHJvYmFibHksIHRoZSB2ZXJ5IGZp
cnN0IGltcGxlbWVudGF0aW9uIG9mIG92ZXJsb2FkIGNvbnRyb2wgd2lsbCBpbmNsdWRlIE9MUiBp
biBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJlc3RyaWN0
IHRoZSBkZXZlbG9wZXJzIHdoaWNoIGNhbiBjb21lIHVwIHdpdGggc29tZSBuaWNlIHR3ZWFrcyBh
bmQgdHJpY2tzIHRvIGF2b2lkIHNlbmRpbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gZXZlcnkg
bWVzc2FnZS4gQW5kIHRoaXMgaXMgd2hlcmUgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGFuZCBhdm9p
ZCBwdXR0aW5nIHN1Y2ggcmVzdHJpY3Rpb25zIGluIHByb3RvY29sIGRlZmluaXRpb24uIDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2hhdCBkbyB5b3UgdGhpbms/PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1
Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0
aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5O
aXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUg
WzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IEZyaWRheSwgRmVicnVhcnkg
MDcsIDIwMTQgODo1NyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkhlbGxvIFVscmljaCwgTmlyYXYsPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBwcm92aWRlZCBieSBOaXJh
diBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNlcnZlciBzZW5kcyBhbiBP
TFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVkuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPk9uIHRoZSBvdGhlciBoYW5kLCBjcml0ZXJpYSBwcm92aWRlZCBieSBV
bHJpY2ggb24gd2hlbiBPTFIgaGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMgdGhlIHNlcnZlciBoYXMg
c29tZSBrbm93bGVkZ2U6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5h
KSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxy
ZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2Vz
IG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUg
aGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jKSBvdGhlcndpc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+UmVwb3J0aW5nIG5vZGUgbXVzdCBoYXZlIHNvbWUga25vd2xlZGdlIGFib3V0IE9MUiBy
ZWNlcHRpb24vc3RhdHVzIGluIHJlYWN0aW5nIG5vZGUuIEhvdyBkb2VzIHNlcnZlciBhY3F1aXJl
IHRoaXMga25vd2xlZGdlPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlRha2UgaW50byBhY2NvdW50IGFzIHdlbGwgdGhhdCBhICZxdW90O3JlYWN0aW5nJnF1b3Q7IG5v
ZGUgbWF5IGJlIGJvdGggYW4gQWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMgc2VydmljZSB0byBh
IHJlYWxtIG9yIGFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpJm5i
c3A7IGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2
ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGlu
ZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5v
dCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hh
aW4gdG8gdGhlIGZpbmFsIENsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhl
cmVmb3JlLCBJIGRlZmluaXRlbHkgdGhpbmsgdGhhdCBzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2Vy
cyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPi0gc3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24g
b3Igc2Vzc2lvbikgaXMgc2ltcGxlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGRldGVybWluZSB3aGV0aGVyIG9y
IG5vdCB0byBzZW5kIGFuIE9MIHRvIGEgcmVhY3Rpbmcgbm9kZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+LSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gYm90aGVy
IHdoZXRoZXIgYW4gcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBPTFIgb3Ig
d2hldGhlciB0aGlzIE9MUiBpcyBzdGlsbCB2YWxpZCAoaGFzIG5vdCBleHBpcmVkKS48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gc2VuZGluZyBhbiBhZGRpdGlvbmFs
IEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1
aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLiA8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBJbiBmYWN0LCBpbiBhbiBvdmVybG9hZCBz
aXR1YXRpb24sIHRoZSBlYXNpZXN0IGFuZCBsZWFzdCBjb21wbGV4IGlzIHRvIHNlbmQgaW5mb3Jt
YXRpb24gb3V0IHRvIGFsbCBhZmZlY3RlZC9hcHBsaWNhYmxlIG5vZGVzLCA8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBhbmQgdGhlIGxhdHRlciBzaG91bGQg
dGFrZSBjYXJlIHRvIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9ucyZuYnNwOyA8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gbW9yZSByb2J1c3Qgc29sdXRpb24sIGFzIG5v
IG5lZWQgdG8gY2F0ZXIgZm9yIGFsbCB0aGUgY2hlY2tzIG9uIHRoZSBuZWVkIHRvIHNlbmQgaW5m
b3JtYXRpb24sJm5ic3A7IGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlz
IGxvc3QsJm5ic3A7IOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QgcmVnYXJkczxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+L01DcnV6PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo
YWxmIE9mIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IHZpZXJuZXMsIDA3IGRlIGZlYnJlcm8gZGUgMjAx
NCAxMDo1OTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IGV4dCBO
aXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9y
YW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IGV4dCBTdGV2ZSBEb25vdmFu
OyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5OaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSdtIGFmcmFp
ZCB5b3VyIHByb3Bvc2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGUgaW50ZW50aW9uLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDt3aGVuIGl0IHdhbnRzIHRvIHByb3ZpZGUv
dXBkYXRlLi4uLml0IHNoYWxsIGluY2x1ZGUuLi4mcXVvdDsgdHJhbnNsYXRlcyB0byAmcXVvdDsu
Li5pdCBtYXkgaW5jbHVkZS4uLiZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
JnF1b3Q7aW4gb3RoZXIgY2FzZXMmcXVvdDsgaW4gdGhlIGdpdmVuIGNvbnRleHQgdHJhbnNsYXRl
cyB0byAmcXVvdDt3aGVuIGl0IGRvZXMgbm90IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUuLi4mcXVv
dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hKSB0aGUgcmVwb3J0aW5nIG5vZGUg
a25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBP
TFI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmIpIHRoZSByZXBvcnRp
bmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGlu
ZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3
aWxsIHNvb24gZXhwaXJlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5j
KSBvdGhlcndpc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aW4gY2FzZSBhKSB0aGUg
cmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFIgaW4gY2FzZSBiKSB0
aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUgcmVhY3Rpbmcgbm9k
ZSB3aXRoIHRoZSBsYXRlc3QgT0xSIGluIGNhc2UgYykgdGhlIHJlcG9ydGluZyBub2RlIE1VU1Qg
aW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcgbm9kZSBkb2VzIG5v
dCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIHJlcGxheSBvciBhbiB1cGRhdGUpPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPlVscmljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5G
cm9tOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0bzpuc2Fsb3RAY2lz
Y28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgNDo0
OSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IFdpZWhlLCBV
bHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFu
ZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBleHQgU3RldmUgRG9u
b3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+VWxyaWNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCBz
ZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUgcGFnZSBidXQgcHJvYmFibHkgdGhlIHByb3Bvc2VkIHdv
cmRpbmcgYmVsb3cgaXMgbm90IHRoZSBiZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+SG93IGFib3V0IHRoZSBmb2xsb3dpbmcuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPldoZW4gdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUgbmV3IG92
ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3Zl
cmxvYWQgcmVwb3J0IHRvd2FyZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNsdWRlIE9M
UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFk
ZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg
aXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0
byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBP
TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUv
TXVuaWNoKSBbPGEgaHJlZj0ibWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86dWxy
aWNoLndpZWhlQG5zbi5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDM6NTcgUE08bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBleHQgPGEgaHJlZj0ibWFpbHRvOmxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGlt
ZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P
bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp
dmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdiwgTGlv
bmVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGNhbiB1bmRlcnN0YW5kIE5pcmF2
J3MgY29uY2VybiAoYWx0aG91Z2ggdmlvbGF0aW5nIFJFUTEwKSBhbmQgaG9wIGl0IGlzIGFkZHJl
c3NlZCBieSB0aGUgbW9kaWZpZWQgcHJpbmNpcGxlIDInOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4yJy4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9h
ZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0
byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlm
IGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNv
bmFibGUgb3ZlcmxvYWQgY29udHJvbCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwg
d2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9M
UiBpbmRpY2F0aW5nICZxdW90O25vIG92ZXJsb2FkJnF1b3Q7LCBvciBhbiBvbGQmbmJzcDsgYnV0
IHNvb24gZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9h
ZGVkKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGlu
ZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4g
YW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3Vw
cG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGRvbid0
IGFncmVlIHdpdGggTGlvbmVscyBkby13aGF0LXlvdS13YW50IGFwcHJvYWNoLiBPdmVybG9hZCBj
b250cm9sIHdpbGwgbm90IHdvcmsgd2hlbiB3ZSBhbGxvdyB0aGUgcmVwb3J0aW5nIG5vZGUgbm90
IHRvIHVwZGF0ZSByZWFjdGluZyBub2Rlcywgd2hpY2ggYXJlIG5vdCAoc3VmZmljaWFudGx5KSBh
d2FyZSBvZiB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0dXMsIHdpdGggdXAgdG8gZGF0ZSBPTFJz
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2gmbmJzcDsgPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+RnJvbTogZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzpsaW9uZWwu
bW9yYW5kQG9yYW5nZS5jb20iPm1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+XTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogVGh1cnNkYXksIEZl
YnJ1YXJ5IDA2LCAyMDE0IDEwOjIwIEFNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5UbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERF
L011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9y
ZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EZSZuYnNwOzogRGlNRSBbPGEgaHJlZj0ibWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwv
YT5dIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nDqSZuYnNwOzogamV1
ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4IMOAJm5ic3A7OiBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v
cmciPmRpbWVAaWV0Zi5vcmc8L2E+IE9iamV0Jm5ic3A7OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VWxyaWNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGFtIG5vdCBzdXJlIGFi
b3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiByZXBvcnRpbmcgbm9kZSAmcXVvdDtvdGhlcndp
c2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1h
dHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVz
cG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZSBBVlAuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUg
cmVwb3J0aW5nIG5vZGUgbWF5IHNpbXBseSBub3QgaW5jbHVkZSBPTFIgYXNzdW1pbmcgdGhhdCB0
aGUgZWFybGllciBwcm92aWRlZCBPTFIgd2lsbCBleHBpcmUgYW5kIHRoZSByZWFjdGluZyBub2Rl
IHdpbGwgc3RvcCB0aHJvdHRsaW5nIHRoZSB0cmFmZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5bTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1
aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBI
b3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xS
IGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGlt
cGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcyB3ZSBoYWQgZGlzY3Vzc2VkIGVhcmxpZXIs
IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBleHBsaWNpdGx5IHN0
b3AgdGhyb3R0bGluZyBhdCBlYWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4gSW4g
b3RoZXIgd29yZHMsIHRoZSByZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhlIG5hdHVyYWwgZXhw
aXJ5IG9mIHRoZSBPTFIgdG8gZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhlIHNpZ25hbGluZyB0
cmFmZmljIHRvd2FyZHMgaXQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltMTV0gQWdy
ZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlcmUgbWF5IGJlIG90aGVyIGNhc2Vz
LCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3Zlcmxv
YWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBu
byBuZWVkIGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3Zl
cmxvYWQgY29uZGl0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTE1dIEFncmVl
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlc3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVs
b3cgYXJlIGZpbmUgd2l0aCBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W0xNXSBB
Z3JlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFs8
YSBocmVmPSJtYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb20iPm1haWx0bzp1bHJpY2gud2llaGVA
bnNuLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50
OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMjoyMyBQTTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBTYWxvdCAo
bnNhbG90KTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+QWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNp
cGxlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEuIExhY2sgb2Yg
T0xSIG1lYW5zICZxdW90O25vIGNoYW5nZSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Mi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBv
dmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNw
b25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUg
QVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290
IHRoZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyBy
ZWR1Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgJnF1b3Q7bm8gb3ZlcmxvYWQmcXVvdDspOyBv
dGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUg
KG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIg
aW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQt
RmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNhbiBwZW9wbGUgcGxl
YXNlIGNvbmZpcm0uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVscmljaDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo
YWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBOaXJhdiBTYWxvdCAobnNhbG90
KTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtk
aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl
c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+QWdyZWVkLiZuYnNwOyBUbyByZXN0YXRlIC0tIGxhY2sgb2YgYW4gb3Zlcmxv
YWQgcmVwb3J0IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0ZSBmb3Ig
dGhlIGhvc3Qgb3IgcmVhbG0uJm5ic3A7IElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBv
dmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVy
IHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCBy
ZXBvcnQuJm5ic3A7IElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVw
b3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVyZSBpcyBubyBv
dmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5TdGV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T24gMi81
LzE0IDk6MTkgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFy
dCAmcXVvdDtzaG91bGRu4oCZdCBsYWNrIG9mIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3Zl
cmxvYWRlZD8mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2UgaGFkIHNvbWUg
ZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJs
ZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBh
bnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2lu
ZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBz
ZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9u
YWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGli
aXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3VsZCBub3QgYWZmZWN0IHRo
ZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9kZS4gVGhlIHJlYWN0
aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVyIE9MUiB1bnRpbCB0
aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUgZXhwbGljaXQgT0xS
IHdpdGggJnF1b3Q7MCZxdW90OyBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbiBteSB2aWV3LCB0aGlzIGFsbG93cyBm
b3IgZmxleGlibGUgaW1wbGVtZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3Vu
ZCBoYW5kbGluZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEg
aHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0
IDg6MDAgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiA8YSBo
cmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5pbmxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9uIDIv
NS8xNCA3OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T2sgdGhlbiBsZXQncyBzdGF0ZSB0
aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3
ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29u
dGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1
Y3Rpb24gaXMgcmVxdWVzdGVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlNSRCZndDsgV2h5IGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlPyZuYnNwOyBTaG91bGRuJ3Qg
bGFjayBvZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk90aGVyIGNy
aXRlcmlhIGxpa2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U1JEJmd0OyBSZXF1aXJpbmcgYW4gb3Zl
cmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBi
dXQgcmVxdWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFs
IGFkZGl0aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRp
bmcgT0xScy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Rm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcg
bm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVk
IChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1
cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBv
ZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRv
byBtaXNzIGEgbmV3IE9MUj88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlNSRCZndDsgVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9t
OiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIGV4dCBOaXJhdiBTYWxvdCAobnNh
bG90KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogV2VkbmVz
ZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0
Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBzaGFyZSB0aGUgc2Ft
ZSBvcGluaW9uIGFzIExpb25lbC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJk
cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwv
YT5dIE9uIEJlaGFsZiBPZiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
Ij5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5TZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRv
OmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB1bmRl
cnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBE
T0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gdGhlIG9wdGlvbnMgd291bGQgYmU6PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFu
c3dlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Mi0gT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgJiM0MzsgT0MtT0xSIEFWUCBp
biBzb21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRo
ZSBjbGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+SWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhl
IGJlc3QgYXBwcm9hY2guPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkxpb25lbDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRlJm5ic3A7OiBkaW1lIGlzc3Vl
IHRyYWNrZXIgWzxhIGhyZWY9Im1haWx0bzp0cmFjJiM0MztkaW1lQHRyYWMudG9vbHMuaWV0Zi5v
cmciPm1haWx0bzp0cmFjJiM0MztkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmc8L2E+XTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RW52b3nDqSZuYnNwOzogbWFyZGkgNCBm
w6l2cmllciAyMDE0IDA5OjQ5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij7DgCZuYnNwOzogTU9SQU5EIExpb25lbCBJTVQvT0xOPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5DYyZuYnNwOzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmci
PmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5PYmpldCZuYnNwOzogW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4jMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IEl0IGhhcyBiZWVuIHByb3Bvc2Vk
IHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdGhhdCBpcyZuYnNw
OyB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQmbmJzcDsgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3Vs
ZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4gKFRpbWVTdGFtcCkgb2YgdGhlIE9MUiBhY2NvcmRpbmcgdG8gd2hpY2gg
dGhlIHRocm90dGxpbmcgKHdoaWNoIHdhczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+IHN1cnZpdmVkKSBpcyBwZXJmb3JtZWQuIEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5k
aWNhdGVzIHRoYXQgY3VycmVudGx5IG5vJm5ic3A7IHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLiZu
YnNwOyBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzJm5ic3A7IGluZm9ybWF0
aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCB0byB1cGRhdGUg
dGhlJm5ic3A7IHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0IE9MUi48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBBYnNlbmNlIG9mIHRoaXMgZmVl
ZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlJm5ic3A7IHJl
cG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRoZSBy
ZXBvcnRpbmcgRE9JQyZuYnNwOyBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFj
dGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nJm5ic3A7IHRoZSByaWdodCB0aGlu
ZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92
ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDJm5ic3A7IGVuZHBv
aW50IHRvIGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJvcHJpYXRlIHRocm90dGxpbmcgYnkgdGhl
IHJlYWN0aW5nJm5ic3A7IERPSUMgZW5kcG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24p
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IFRoZSBmZWVkYmFjayBt
ZWNoYW5pc20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBSRkMgNzA2OC48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBJbiBzdW1tYXJ5IGl0IGlzIHBy
b3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvJm5i
c3A7IGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EaU1FIG1haWxpbmcg
bGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0ibWFp
bHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50
IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl
cyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp
ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy
cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg
YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg
ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz
cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm
aWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIG1lc3NhZ2UgYW5k
IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp
bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3Qg
YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl
IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90
IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig
ZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhhbmsg
eW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWlsaW5nIGxp
c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0
bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8
L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBt
YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhy
ZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2UgbWVzc2FnZSBldCBzZXMgcGll
Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll
bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv
cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg
ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw
aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli
bGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
Pk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg
YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u
ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk
IGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnRoZXkgc2hv
dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0
aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgeW91IGhhdmUg
cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu
ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n
ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh
bmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdl
IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg
Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz
YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy
LCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0
ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz
YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48
L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg
Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVz
c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2
aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286
cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv
cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286
cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp
YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs
c2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz
IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp
dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz
IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn
ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBk
ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry
b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0
b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv
dSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg
Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi
ZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg
b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp
cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg
T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk
LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_6B7134B31289DC4FAF731D844122B36E49A34EPEXCVZYM13corpora_--


From ben@nostrum.com  Tue Feb 11 08:08:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5621F1A0502 for ; Tue, 11 Feb 2014 08:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPUDWDZ54ZWt for ; Tue, 11 Feb 2014 08:08:20 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 015791A0548 for ; Tue, 11 Feb 2014 08:08:19 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-079-215.mycingular.net [166.147.79.215]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1BG7jPO050540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Feb 2014 10:08:15 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>
Date: Tue, 11 Feb 2014 09:55:27 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 166.147.79.215 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 16:08:21 -0000

On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> 1) I want the reacting node to be able to learn if a (potentially) =
reporting node supports DOIC, even when that node is not in overload. I =
don't want to specify any particular behavior for that knowledge, but I =
suspect implementations may want to treat DOIC compliant servers in some =
way differently than they do non-DOIC servers. For example, I might have =
a configured rate limit for non-DOIC peers, but use a higher (or no) =
limit for peers that are known to support DOIC (and can thus speak for =
themselves.)
> sounds like a new requirement; where does it come from? I =
would have thought that there is no need to distinguish between
> a) DOIC not supported and therefore no traffic reduction requested, =
and
> b) DOIC supported, but not in overload and therefore no traffic =
reduction requested=20
>=20

At one point, I thought we agreed as a group that a reacting node should =
be able to identify if a (potential) reporting node supported the =
mechanism. But in any case, we have a requirement that the mechanism =
must work in a mixed environment, where some nodes support it and some =
don't. It's much _easier_ to meet that requirement if we can tell what =
nodes support it and what don't.=20

In general, a reacting node can assume that a server that supports DOIC, =
but hasn't reported overload is not overloaded. It can make no such =
assumption about a server that doesn't support DOIC. If it does not know =
the difference between a non-overloaded server and a non-supporting =
server, it must assume all such servers are non-supporting. It ends up =
simply knowing that some servers _are_ overloaded, and some other =
servers _might_be_ overloaded.


From jouni.nospam@gmail.com  Tue Feb 11 09:56:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB7D1A06D4 for ; Tue, 11 Feb 2014 09:56: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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkGTkaWkzZyo for ; Tue, 11 Feb 2014 09:56:31 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 39B181A06D6 for ; Tue, 11 Feb 2014 09:56:31 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id hr13so6293075lab.3 for ; Tue, 11 Feb 2014 09:56:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gojvpye4yNWiuGsVhgDkjVvYzETmkXZWOncfqmP0oP4=; b=sWUZZYTHpnxbzpO0mxnBJumG1Z6T29/Kbq8SmBicIa91copXOZV4KY31Oq8uIyUHoj QJhaBfiFzp/CNZFd/naNHwrpMJgCBUsfJFeOQSPvDUHoxcwjRF0taGUXVik1Y2+0Fen6 AwxN5fWHZQB34HQV7qRgwnkVLKnwqmRtMc+uzI3QA49BCqOOiYmZPVwOC23IDm7JoV7j TRbMPvFVQWkrU50n72q0a7gAsQDkqq8/gEOe5et7u9tnnKuh9suY1JazG9D+yJDBSYy3 7rZHLHrI/uR+1pUSezKJ39g587h3l44bkcmVG1nmkzD/Y6M+rxbVwEMOK8ayCLARYiGn IorA==
X-Received: by 10.112.43.70 with SMTP id u6mr25747463lbl.30.1392141389831; Tue, 11 Feb 2014 09:56:29 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id jf8sm20663675lbc.8.2014.02.11.09.56.25 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 09:56:26 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2BB2@DEMUMBX014.nsn-intra.net>
Date: Tue, 11 Feb 2014 19:56:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com> <52F9605C.7000504@usdonovans.com> <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2BB2@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "ben@nostrum.com" 
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 17:56:34 -0000

Fine with me. That just needs to be just stated more clearly.
Now there are too many SHOULDs and stuff.

- JOuni

On Feb 11, 2014, at 2:32 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> I agree that OC-OLR AVPs are allowed only in answer messages.
>=20
> But I do not agree with=20
>>> if there are other DOIC AVPs in the=20
>>> request, then the absence of the OC-Supported-Features is
>>> interpreted as support for the default abatement algorithm.
>=20
> "other DOIC AVPs" would be AVPs defined for future extensions. A =
reporting node that does not support any future extension would simply =
ignore "other DOIC AVPs" and would interprete the absence of =
OC-Supported-Features as "DOIC not supported by any downstream node".
>=20
> Things are not symmetric.
> Ulrich
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni =
Korhonen
> Sent: Tuesday, February 11, 2014 7:45 AM
> To: Steve Donovan
> Cc: ben@nostrum.com; dime@ietf.org; =
draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism =
needs to be rethought
>=20
>=20
> Your assumption is correct. "Other DOIC AVPs" is a future thing.
> Currently we have no other DOIC AVPs for requests. It is just I
> asking the same semantics for the OC-Supported-Features for both
> directions.
>=20
> - Jouni
>=20
>=20
> On Feb 11, 2014, at 1:27 AM, Steve Donovan  =
wrote:
>=20
>> It has been my assumption that the OC-OLR AVP would only be allowed =
in answer messages.  Is this the consensus?
>>=20
>> Steve
>>=20
>> On 2/10/14 4:27 PM, Jouni Korhonen wrote:
>>> Basically yes.. however, if there are other DOIC AVPs in the=20
>>> request, then the absence of the OC-Supported-Features is
>>> interpreted as support for the default abatement algorithm.
>>> We should have that behaviour in both requests and answers.
>>>=20
>>> - Jouni
>>>=20
>>> On Feb 10, 2014, at 7:03 PM, Steve Donovan=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> My sense from recent discussions is that the lifetime of the =
OC-Supported-Feature AVP is assumed to be one transaction.  This means =
that the AVP must be included in all request messages sent by a reacting =
node.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>>>=20
>>>>> #49: capabilities announcement mechanism needs to be rethought
>>>>>=20
>>>>> The capabilities announcement mechanism needs serious rethought.
>>>>> Specifically, the lifetime of the state associated with a =
capabilities
>>>>> announcement is unclear. It does not make sense to tie that =
lifetime to
>>>>> Diameter session lifetimes, unless we expect to have different =
capability
>>>>> sets for different sessions. (and it doesn't help at all for =
non-session
>>>>> applications or pseudo-sessions.)
>>>>>=20
>>>>> I think we either need to mandate that the capabilities are =
stateless,
>>>>> that is, must be included in every request, and any OLR in a =
response must
>>>>> match the OC-Supported-Features from the corresponding request.
>>>>> Otherwise, we need a way to activate and deactivate the set =
associated
>>>>> with a capabilities set.
>>>>>=20
>>>>> (This is a side effect of allowing DOIC to cross non-supporting =
agents. If
>>>>> we didn't allow that, we could make DOIC support and capabilites
>>>>> negotiation happen as part of the CAR exchange. )
>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 12:21:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1011A066E for ; Tue, 11 Feb 2014 12:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCar85ND5PPN for ; Tue, 11 Feb 2014 12:21:31 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2E11A0660 for ; Tue, 11 Feb 2014 12:21:30 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-82-52fa86499bda
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CE.FA.10875.9468AF25; Tue, 11 Feb 2014 21:21:29 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 21:21:29 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNA=
Date: Tue, 11 Feb 2014 20:21:28 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvja5n268ggzUXLC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsuyjUwFU5Qq9kxaztTA+Ee6i5GTQ0LARGLfwzWsELaYxIV7 69m6GLk4hAQOMUpc7O9mhnCWMEpMOLAPrIpNwE7i0ukXTF2MHBwiAhoSK05kgpjCAj4SMzaH gVSICPhKzFw9gxmiIkni/h1jEJNFQFWib2oISAUvUMXqC9uYQWwhgS+sEtvnuYHYnAL2Eo9O fGIHsRmBrvl+ag0TiM0sIC5x68l8JogrBSSW7DnPDGGLSrx8/A/qeiWJtYe3s0DU60gs2P2J DcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25iZk56ueEmRmDAH9zy W3cH46lzIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaJYwhUPUK2H2 kZV5j67unqN47taOiE8Npxby5yz4wvZ65nUutu5D/r0Fbjv3PXoqE6HDECQsn6YkdPj7ej2W nV93fCwt7bf/+LiK7bv6haaLLxSb9V0r56llLfloonJ5jaJoz8xVLm3zxFZqdc1ycnJODFGS ffRAxGPa/0yZhZrCapcuOk2+rMRSnJFoqMVcVJwIAIhsqntGAgAA
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 20:21:34 -0000

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement  in our 3GPP TR:

6.3.3	Implicit Overload Indication
6.3.3.1	Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
-	DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
-	Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> 1) I want the reacting node to be able to learn if a (potentially)=20
> reporting node supports DOIC, even when that node is not in overload.=20
> I don't want to specify any particular behavior for that knowledge,=20
> but I suspect implementations may want to treat DOIC compliant servers=20
> in some way differently than they do non-DOIC servers. For example, I=20
> might have a configured rate limit for non-DOIC peers, but use a=20
> higher (or no) limit for peers that are known to support DOIC (and can=20
> thus speak for themselves.) sounds like a new requirement;=20
> where does it come from? I would have thought that there is no need to=20
> distinguish between
> a) DOIC not supported and therefore no traffic reduction requested,=20
> and
> b) DOIC supported, but not in overload and therefore no traffic=20
> reduction requested
>=20

At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

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


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 13:14:37 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBADF1A0757 for ; Tue, 11 Feb 2014 13:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 cNs4DR3MeKXj for ; Tue, 11 Feb 2014 13:14:30 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DAA2F1A0746 for ; Tue, 11 Feb 2014 13:14:29 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-21-52fa92b41ff0
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AB.3C.04249.4B29AF25; Tue, 11 Feb 2014 22:14:28 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 22:14:28 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #49: capabilities announcement mechanism needs to	be rethought
Thread-Index: AQHPJ1KV7BrrEMqGdEWzisuuFUh1Rpqwi6ZA
Date: Tue, 11 Feb 2014 21:14:27 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097731D8@ESESSMB101.ericsson.se>
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com> <52F9605C.7000504@usdonovans.com> <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2BB2@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje6WSb+CDH41GFnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGv9WxgLVutUTHx6hKWBcalKFyMnh4SAicSmZXvZIWwxiQv3 1rN1MXJxCAkcYZS4MPM9E0hCSGAJo8SrU7ogNpuAncSl0y+A4hwcIgLKEqd/OYCEhQWiJf6/ 72MEsUUEYiSu3vjIDmEbSTw/ehTMZhFQldj4bAvYSF4BX4m2/n5miF1vmSSajs8HK+IUsJVo OTyHDcRmBDro+6k1YA3MAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWwlibWHt7NA1OtILNj9 iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI0dxanFSbrqRwSZGYOAf 3PLbYgfj5b82hxilOViUxHk/vnUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cComPOEx1j8 wsaY+VXXsrhVJiwzWGMoaH4pspXr5Clri0pnhTeTHQ8qNd+xeFX15u2+la5Pl9S2G608OaX9 R3iI18e12s/7nt41DRZ/nSpst7bIUWlypuKl7R8mFZc+fv9RP2zVeq636x1kllxSizrBolNu oPV82jN7GXv3f66TD7c9D7PY7xevxFKckWioxVxUnAgARtV1yEoCAAA=
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to	be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 21:14:38 -0000

Hello all,

I would like to come back to the initial comments by Ben on this subject:

>The capabilities announcement mechanism needs serious rethought.
 >Specifically, the lifetime of the state associated with a capabilities
 >announcement is unclear. It does not make sense to tie that lifetime to
 >Diameter session lifetimes, unless we expect to have different capability
 >sets for different sessions. (and it doesn't help at all for non-session
 >applications or pseudo-sessions.)

[MCruz] I agree we do not need to tie a capability set to a session, but on=
 the other hand, what could be the reason to modify the capability set with=
in a session?
I think this was the original reason why it is considered that the capabili=
ty just needs to be announced once per session. In fact, I think this is a =
valid solution.

> I think we either need to mandate that the capabilities are stateless,
 >that is, must be included in every request, and any OLR in a response mus=
t
 >match the OC-Supported-Features from the corresponding request.
 >Otherwise, we need a way to activate and deactivate the set associated
 >with a capabilities set.

[MCruz] We could allow to define the capability set just once per session (=
obviously for session-based applications, for non-session based keeps being=
 in each message).
We can define that within a session it is not allowed to modify the capabil=
ity set.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: martes, 11 de febrero de 2014 18:56
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs t=
o be rethought


Fine with me. That just needs to be just stated more clearly.
Now there are too many SHOULDs and stuff.

- JOuni

On Feb 11, 2014, at 2:32 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> I agree that OC-OLR AVPs are allowed only in answer messages.
>=20
> But I do not agree with
>>> if there are other DOIC AVPs in the request, then the absence of the=20
>>> OC-Supported-Features is interpreted as support for the default=20
>>> abatement algorithm.
>=20
> "other DOIC AVPs" would be AVPs defined for future extensions. A reportin=
g node that does not support any future extension would simply ignore "othe=
r DOIC AVPs" and would interprete the absence of OC-Supported-Features as "=
DOIC not supported by any downstream node".
>=20
> Things are not symmetric.
> Ulrich
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20
> Korhonen
> Sent: Tuesday, February 11, 2014 7:45 AM
> To: Steve Donovan
> Cc: ben@nostrum.com; dime@ietf.org;=20
> draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism=20
> needs to be rethought
>=20
>=20
> Your assumption is correct. "Other DOIC AVPs" is a future thing.
> Currently we have no other DOIC AVPs for requests. It is just I asking=20
> the same semantics for the OC-Supported-Features for both directions.
>=20
> - Jouni
>=20
>=20
> On Feb 11, 2014, at 1:27 AM, Steve Donovan  wro=
te:
>=20
>> It has been my assumption that the OC-OLR AVP would only be allowed in a=
nswer messages.  Is this the consensus?
>>=20
>> Steve
>>=20
>> On 2/10/14 4:27 PM, Jouni Korhonen wrote:
>>> Basically yes.. however, if there are other DOIC AVPs in the=20
>>> request, then the absence of the OC-Supported-Features is=20
>>> interpreted as support for the default abatement algorithm.
>>> We should have that behaviour in both requests and answers.
>>>=20
>>> - Jouni
>>>=20
>>> On Feb 10, 2014, at 7:03 PM, Steve Donovan=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> My sense from recent discussions is that the lifetime of the OC-Suppor=
ted-Feature AVP is assumed to be one transaction.  This means that the AVP =
must be included in all request messages sent by a reacting node.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>>>=20
>>>>> #49: capabilities announcement mechanism needs to be rethought
>>>>>=20
>>>>> The capabilities announcement mechanism needs serious rethought.
>>>>> Specifically, the lifetime of the state associated with a=20
>>>>> capabilities announcement is unclear. It does not make sense to=20
>>>>> tie that lifetime to Diameter session lifetimes, unless we expect=20
>>>>> to have different capability sets for different sessions. (and it=20
>>>>> doesn't help at all for non-session applications or=20
>>>>> pseudo-sessions.)
>>>>>=20
>>>>> I think we either need to mandate that the capabilities are=20
>>>>> stateless, that is, must be included in every request, and any OLR=20
>>>>> in a response must match the OC-Supported-Features from the correspon=
ding request.
>>>>> Otherwise, we need a way to activate and deactivate the set=20
>>>>> associated with a capabilities set.
>>>>>=20
>>>>> (This is a side effect of allowing DOIC to cross non-supporting=20
>>>>> agents. If we didn't allow that, we could make DOIC support and=20
>>>>> capabilites negotiation happen as part of the CAR exchange. )
>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> 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 maria.cruz.bartolome@ericsson.com  Tue Feb 11 13:21:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F561A0757 for ; Tue, 11 Feb 2014 13:21:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWhvXoU4r3v9 for ; Tue, 11 Feb 2014 13:21:37 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48F1A0743 for ; Tue, 11 Feb 2014 13:21:36 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-91-52fa945f027c
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id B1.09.04853.F549AF25; Tue, 11 Feb 2014 22:21:35 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 22:21:35 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #43: Overstated guidance on	session-ending requests.
Thread-Index: AQHPJoX801rjEzu/c06unIOm5bxUC5qwkV/A
Date: Tue, 11 Feb 2014 21:21:34 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097731E9@ESESSMB101.ericsson.se>
References: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> <52F9070A.8080608@usdonovans.com> <6150_1392053497_52F90CF9_6150_15734_1_6B7134B31289DC4FAF731D844122B36E497E5B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <6150_1392053497_52F90CF9_6150_15734_1_6B7134B31289DC4FAF731D844122B36E497E5B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097731E9ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW78lF9BBp/malnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE9/7jMVHGhlrOg5bd3A+KWRsYuRk0NCwERi5a3FzBC2mMSF e+vZQGwhgROMEm8/B3QxcgHZSxglepafBEuwCdhJXDr9gqmLkYNDREBZ4vQvB5CwsECgRMvO aywgtohAkMShZdtYIWwjiWV/V4DtYhFQlbi57C/YGF4BX4mlR+6wQMx/yihx9cEsJhCHU6CV UWLSpA1gHYxAF30/tYYJxGYWEJe49WQ+E8SlAhJL9pyHulpU4uXjf6wQtpLE2sPbWSDq8yV6 t2xlhtgmKHFy5hOWCYwis5CMmoWkbBaSsllAvzELaEqs36UPUaIoMaX7ITuErSHROmcuO7L4 Akb2VYySxanFxbnpRgZ6uem5JXqpRZnJxcX5eXrFqZsYgdF0cMtvox2MJ/fYH2KU5mBREue9 zloTJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxespbv4a1YjeKa+6tvNj2hXdF+fcc/TWu F8+7L9jClzjtLsfXiTuVnfr+7IyZN2P2bGHnJC/ji5blnjn/7z6w6KhJWpbynEufV9mo9skb A9kZ26+9ipILk91xyviye9YRQdFLb6761Pl26sV8mdt85sYCgarug3c3td+cd/1ZkulT7fz3 /i/fKLEUZyQaajEXFScCAKNK+9h0AgAA
Subject: Re: [Dime] [dime] #43: Overstated guidance on	session-ending	requests.
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 21:21:39 -0000

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

QWdyZWVkDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJy
ZXJvIGRlIDIwMTQgMTg6MzINClRvOiBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnOyBkcmFm
dC1kb2NkdC1kaW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7IGJlbkBub3N0cnVtLmNvbQ0KU3ViamVj
dDogUmU6IFtEaW1lXSBbZGltZV0gIzQzOiBPdmVyc3RhdGVkIGd1aWRhbmNlIG9uIHNlc3Npb24t
ZW5kaW5nIHJlcXVlc3RzLg0KDQpIaSBTdGV2ZSwgQmVuLA0KDQpJIGFncmVlIHdpdGggU3RldmUg
dGhhdCB3ZSBoYXZlIHRoZSB0ZXh0IGluIGludHJvZHVjdGlvbiBpcyBjbGVhciBlbm91Z2ggdG8g
YXZvaWQgYW1iaWd1aXR5Lg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KRGUgOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVu
dm95w6kgOiBsdW5kaSAxMCBmw6l2cmllciAyMDE0IDE4OjA2DQrDgCA6IGRpbWVAaWV0Zi5vcmc7
IGRyYWZ0LWRvY2R0LWRpbWUtb3ZsaUB0b29scy5pZXRmLm9yZzsgYmVuQG5vc3RydW0uY29tDQpP
YmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICM0MzogT3ZlcnN0YXRlZCBndWlkYW5jZSBvbiBzZXNz
aW9uLWVuZGluZyByZXF1ZXN0cy4NCg0KU2VjdGlvbiAzLjEuNCBpcyBub3Qgbm9ybWF0aXZlIGFu
ZCBzYXlzOg0KDQpUaGUgZm9sbG93aW5nIGxpc3Qgb2YgcmVxdWVzdCB0cmVhdG1lbnQgcmVnYXJk
aW5nIHRocm90dGxpbmcgaXMgcHJvdmlkZWQNCg0KYXMgZ3VpZGVsaW5lcyBmb3IgYXBwbGljYXRp
b24gZGVzaWduZXJzIHdoZW4gaW1wbGVtZW50aW5nIHRoZQ0KDQpEaWFtZXRlciBvdmVybG9hZCBj
b250cm9sIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KRXhhY3QgYmVo
YXZpb3IgcmVnYXJkaW5nIHRocm90dGxpbmcgbXVzdCBiZSBkZWZpbmVkIHBlciBhcHBsaWNhdGlv
bi4NCkRvIHlvdSB0aGluayB3ZSBuZWVkIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiB0aGF0IGFwcGxp
Y2F0aW9uIGRlc2lnbmVycyBzaG91bGQgcmVmbGVjdCB0aGF0IGxvY2FsIHBvbGljeSBhcHBsaWVz
Pw0KDQpTdGV2ZQ0KT24gMi83LzE0IDM6MzQgUE0sIGRpbWUgaXNzdWUgdHJhY2tlciB3cm90ZToN
Cg0KIzQzOiBPdmVyc3RhdGVkIGd1aWRhbmNlIG9uIHNlc3Npb24tZW5kaW5nIHJlcXVlc3RzLg0K
DQoNCg0KIEluIHNlY3Rpb24gMy4xLjQsIHVuZGVyICJJbnRyYS1TZXNzaW9uIFJlcXVlc3RzIiBp
bmRpY2F0ZXMgdGhhdCBzZXNzaW9uDQoNCiBlbmRpbmcgcmVxdWVzdHMgc2hvdWxkIGJlIHRocm90
dGxlZCBsZXNzIGFnZ3Jlc3NpdmVseS4gV2hpbGUgSSBhZ3JlZQ0KDQogdGhhdCdzIGEgZ29vZCBp
ZGVhIGluIGdlbmVyYWwsIEkgdGhpbmsgdGhhdCdzIGEgbWF0ZXIgb2YgbG9jYWwgcG9saWN5LCBh
bmQNCg0KIG5vdCB1cCB0byBET0lDIHRvIHNwZWNpZnkuDQoNCg0KDQogSXQgd291bGQgYmUgYmV0
dGVyIHRvIGluZGljYXRlIHRoYXQgcHJpb3JpdGl6YXRpb24gdW5kZXIgb3ZlcmxvYWQgaXMgdXAg
dG8NCg0KIGxvY2FsIHBvbGljeSwgYW5kIGxpc3QgcHJpb3JpdGl6aW5nIG9mIHNlc3Npb24tZW5k
aW5nIHJlcXVlc3RzIGFzIGFuDQoNCiBleGFtcGxlIG9mIGEgcG90ZW50aWFsIGxvY2FsIHBvbGlj
eS4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50
ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw
cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs
b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt
ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVy
IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl
cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5n
ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl
LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz
IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y
bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBi
ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJ
ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo
ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0K
QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn
ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFu
ayB5b3UuDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg
NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7
DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr
O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs
YWNrO30NCnAuUHJmb3JtYXRIVE1MLCBsaS5QcmZvcm1hdEhUTUwsIGRpdi5QcmZvcm1hdEhUTUwN
Cgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIjsNCgltc28tc3R5bGUtbGluazoi
UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0
eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29u
c29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG
NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky
LjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29s
b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlZDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5saW9uZWwubW9yYW5kQG9yYW5nZS5j
b208YnI+DQo8Yj5TZW50OjwvYj4gbHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxODozMjxi
cj4NCjxiPlRvOjwvYj4gU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzsgZHJhZnQtZG9jZHQt
ZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyBiZW5Abm9zdHJ1bS5jb208YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzQzOiBPdmVyc3RhdGVkIGd1aWRhbmNlIG9uIHNlc3Np
b24tZW5kaW5nIHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+SGkgU3RldmUsIEJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGggU3Rl
dmUgdGhhdCB3ZSBoYXZlIHRoZSB0ZXh0IGluIGludHJvZHVjdGlvbiBpcyBjbGVhciBlbm91Z2gg
dG8gYXZvaWQgYW1iaWd1aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi
PkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0K
PGI+RGUgbGEgcGFydCBkZTwvYj4gU3RldmUgRG9ub3Zhbjxicj4NCjxiPkVudm95w6kmbmJzcDs6
PC9iPiBsdW5kaSAxMCBmw6l2cmllciAyMDE0IDE4OjA2PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBk
aW1lQGlldGYub3JnOyBkcmFmdC1kb2NkdC1kaW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7IGJlbkBu
b3N0cnVtLmNvbTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzQz
OiBPdmVyc3RhdGVkIGd1aWRhbmNlIG9uIHNlc3Npb24tZW5kaW5nIHJlcXVlc3RzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRlIiPlNlY3Rpb24gMy4xLjQgaXMgbm90IG5vcm1hdGl2ZSBhbmQg
c2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJMQzQ1NiI+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5UaGUgZm9sbG93aW5nIGxpc3Qgb2YgcmVxdWVzdCB0cmVhdG1lbnQgcmVnYXJk
aW5nIHRocm90dGxpbmcgaXMgcHJvdmlkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2
Pg0KPGRpdiBpZD0iTEM0NTciPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YXMgZ3VpZGVsaW5lcyBm
b3IgYXBwbGljYXRpb24gZGVzaWduZXJzIHdoZW4gaW1wbGVtZW50aW5nIHRoZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2IGlkPSJMQzQ1OCI+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIj5EaWFtZXRlciBvdmVybG9hZCBjb250cm9sIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhp
cyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdiBpZD0iTEM0
NTkiPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RXhhY3QgYmVoYXZpb3IgcmVnYXJkaW5nIHRocm90
dGxpbmcgbXVzdCBiZSBkZWZpbmVkIHBlciBhcHBsaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiI+RG8geW91IHRoaW5rIHdlIG5lZWQgZnVydGhlciBjbGFy
aWZpY2F0aW9uIHRoYXQgYXBwbGljYXRpb24gZGVzaWduZXJzIHNob3VsZCByZWZsZWN0IHRoYXQg
bG9jYWwgcG9saWN5IGFwcGxpZXM/PGJyPg0KPGJyPg0KU3RldmU8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPk9uIDIvNy8x
NCAzOjM0IFBNLCBkaW1lIGlzc3VlIHRyYWNrZXIgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiM0MzogT3ZlcnN0YXRlZCBndWlkYW5j
ZSBvbiBzZXNzaW9uLWVuZGluZyByZXF1ZXN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+IEluIHNlY3Rpb24gMy4xLjQsIHVuZGVyICZxdW90O0ludHJhLVNlc3Np
b24gUmVxdWVzdHMmcXVvdDsgaW5kaWNhdGVzIHRoYXQgc2Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+IGVuZGluZyByZXF1ZXN0cyBzaG91bGQgYmUg
dGhyb3R0bGVkIGxlc3MgYWdncmVzc2l2ZWx5LiBXaGlsZSBJIGFncmVlPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gdGhhdCdzIGEgZ29vZCBpZGVhIGluIGdl
bmVyYWwsIEkgdGhpbmsgdGhhdCdzIGEgbWF0ZXIgb2YgbG9jYWwgcG9saWN5LCBhbmQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiBub3QgdXAgdG8gRE9JQyB0
byBzcGVjaWZ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4gSXQg
d291bGQgYmUgYmV0dGVyIHRvIGluZGljYXRlIHRoYXQgcHJpb3JpdGl6YXRpb24gdW5kZXIgb3Zl
cmxvYWQgaXMgdXAgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiPiBsb2NhbCBwb2xpY3ksIGFuZCBsaXN0IHByaW9yaXRpemluZyBvZiBzZXNzaW9uLWVuZGlu
ZyByZXF1ZXN0cyBhcyBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiI+IGV4YW1wbGUgb2YgYSBwb3RlbnRpYWwgbG9jYWwgcG9saWN5LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG
UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DZSBtZXNzYWdl
IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg
Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnBhcyBldHJlIGRpZmZ1c2Vz
LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj
dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBk
ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry
b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u
c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu
IE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp
dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJl
IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNl
aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl
bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh
bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj
aGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_087A34937E64E74E848732CFF8354B92097731E9ESESSMB101erics_--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 13:31:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2561A075B for ; Tue, 11 Feb 2014 13:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZStgGipyA8a for ; Tue, 11 Feb 2014 13:31:26 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4531A0765 for ; Tue, 11 Feb 2014 13:31:24 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-09-52fa96ab7a50
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 44.94.23809.BA69AF25; Tue, 11 Feb 2014 22:31:24 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 22:31:23 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] [dime] #39: Definition of Diameter Routing
Thread-Index: AQHPJn6lXeCtSDWIB0ecpaPVZfAQkpqwlCoQ
Date: Tue, 11 Feb 2014 21:31:23 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209773201@ESESSMB101.ericsson.se>
References: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org> <52F900AF.6020201@usdonovans.com>
In-Reply-To: <52F900AF.6020201@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209773201ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje6aab+CDK5MY7aY27uCzWLKij9M DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAldG565HLAUvzCvOPF3N1sA4x6yLkZNDQsBE 4sKumawQtpjEhXvr2boYuTiEBA4xSqxu72eGcJYwSjQtesQMUsUmYCdx6fQLpi5GDg4RgRKJ qW26IGFhoPDVxz1gJSIC9hKLLp9khLCNJD5+XQYWZxFQlbj4cAkTiM0r4Cvx/dUeMFtIIEti 3qa5YDangJ7Eyu7ZYPWMQAd9P7UGLM4sIC5x68l8JohDBSSW7DnPDGGLSrx8/A/qASWJtYe3 s0DU50v0bz7CArFLUOLkzCcsExhFZiEZNQtJ2SwkZbOAPmMW0JRYv0sfokRRYkr3Q3YIW0Oi dc5cdmTxBYzsqxjZcxMzc9LLjTYxAiPn4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQbG9k8vLXdwGO+sF2tLmMIz03Lui5nW28wmXJgxe4Jvl1LVA5nD D+WNVt5fxfln4Q+BVd6BVfWnc/4uleK9e3NZfoyvW3qmR66J/KeQZ3/2nvnbVcfEYG23doPe 7tbOB9XWc7a8Tr3V9/1V2mXGj180pXyuXEhxui1VVHI4dsMCrd9+2uyvavozlViKMxINtZiL ihMBhSmwzmoCAAA=
Subject: Re: [Dime] [dime] #39: Definition of Diameter Routing
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 21:31:29 -0000

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

QWdyZWVkDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0
IDE3OjM5DQpUbzogZGltZUBpZXRmLm9yZzsgZHJhZnQtZG9jZHQtZGltZS1vdmxpQHRvb2xzLmll
dGYub3JnOyBiZW5Abm9zdHJ1bS5jb20NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzOTog
RGVmaW5pdGlvbiBvZiBEaWFtZXRlciBSb3V0aW5nDQoNCkkgYWdyZWUgd2l0aCBCZW4sIEkgZG9u
J3Qgc2VlIHRoZSBuZWVkIHRvIGluY2x1ZGUgdGhpcyBkZWZpbml0aW9uLg0KDQpTdGV2ZQ0KT24g
Mi83LzE0IDI6NDEgUE0sIGRpbWUgaXNzdWUgdHJhY2tlciB3cm90ZToNCg0KIzM5OiBEZWZpbml0
aW9uIG9mIERpYW1ldGVyIFJvdXRpbmcNCg0KDQoNCiBEbyB3ZSBuZWVkIHRoaXMgZGVmaW5pdGlv
bj8gRGlhbWV0ZXIgcm91dGluZyBzaG91bGQgYmUgZnVsbHkgZGVmaW5lZCBieQ0KDQogdGhlIGJh
c2Ugc3BlY2lmaWNhdGlvbi4NCg0KDQoNCiBCdXQgaWYgd2UgZG8sIEkgdGhpbmsgdGhlIHBocmFz
ZSAibm9uLWFkamFjZW50IG5vZGVzIiBpbiB0aGUgZmlyc3QNCg0KIHNlbnRlbmNlIGlzIG1pc2xl
YWRpbmcuIERlc3RpbmF0aW9uLVJlYWxtIGlzIGFsc28gdXNlZCB0byByb3V0ZSBiZXR3ZWVuDQoN
CiBhZGphY2VudCBub2RlcywgYXQgbGVhc3QgdW50aWwgeW91IHJlYWNoIHRoZSBub2RlIHJlc3Bv
bnNpYmxlIGZvciB0aGUNCg0KIHJlYW0rYXBwbGljYXRpb24uIFdlIHNob3VsZCBhbHNvIGluY2x1
ZGUgQXBwbGljYXRpb24tSWQuDQoNCg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg
NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7
DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr
O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs
YWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN
CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi
IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv
cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdyZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN0ZXZlIERvbm92YW48YnI+DQo8Yj5TZW50OjwvYj4g
bHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxNzozOTxicj4NCjxiPlRvOjwvYj4gZGltZUBp
ZXRmLm9yZzsgZHJhZnQtZG9jZHQtZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyBiZW5Abm9zdHJ1
bS5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzM5OiBEZWZpbml0
aW9uIG9mIERpYW1ldGVyIFJvdXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgYWdyZWUgd2l0aCBC
ZW4sIEkgZG9uJ3Qgc2VlIHRoZSBuZWVkIHRvIGluY2x1ZGUgdGhpcyBkZWZpbml0aW9uLjxicj4N
Cjxicj4NClN0ZXZlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gMi83LzE0IDI6NDEgUE0sIGRpbWUgaXNzdWUgdHJhY2tlciB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPiMzOTogRGVmaW5pdGlvbiBvZiBEaWFtZXRlciBSb3V0aW5nPG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IERvIHdl
IG5lZWQgdGhpcyBkZWZpbml0aW9uPyBEaWFtZXRlciByb3V0aW5nIHNob3VsZCBiZSBmdWxseSBk
ZWZpbmVkIGJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+IHRoZSBiYXNlIHNwZWNpZmljYXRpb24u
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IEJ1
dCBpZiB3ZSBkbywgSSB0aGluayB0aGUgcGhyYXNlICZxdW90O25vbi1hZGphY2VudCBub2RlcyZx
dW90OyBpbiB0aGUgZmlyc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gc2VudGVuY2UgaXMgbWlz
bGVhZGluZy4gRGVzdGluYXRpb24tUmVhbG0gaXMgYWxzbyB1c2VkIHRvIHJvdXRlIGJldHdlZW48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gYWRqYWNlbnQgbm9kZXMsIGF0IGxlYXN0IHVudGlsIHlv
dSByZWFjaCB0aGUgbm9kZSByZXNwb25zaWJsZSBmb3IgdGhlPG86cD48L286cD48L3ByZT4NCjxw
cmU+IHJlYW0mIzQzO2FwcGxpY2F0aW9uLiBXZSBzaG91bGQgYWxzbyBpbmNsdWRlIEFwcGxpY2F0
aW9uLUlkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_087A34937E64E74E848732CFF8354B9209773201ESESSMB101erics_--


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 13:44:14 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ADF1A077C for ; Tue, 11 Feb 2014 13:44:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPONxrk-nkll for ; Tue, 11 Feb 2014 13:44:11 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8440A1A0771 for ; Tue, 11 Feb 2014 13:44:10 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-9c-52fa99a96c3d
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.EE.10875.9A99AF25; Tue, 11 Feb 2014 22:44:09 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 22:44:09 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #35: additional report types are proposed
Thread-Index: AQHPIb89LRIcp4kT7Umf//YV8Pl9CpqlRfYAgADBN4CAAEQggIAAAqGAgAAIEgCAAF3UAIAAGngAgAADUQCAB4gtsIAAOGYAgAIPCGA=
Date: Tue, 11 Feb 2014 21:44:08 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209773218@ESESSMB101.ericsson.se>
References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> <081.72db5756df1220c7d22a82469b92ce52@trac.tools.ietf.org> <5522_1391534304_52F120E0_5522_8615_1_6B7134B31289DC4FAF731D844122B36E4775B3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B1FA3@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B1FEF@DEMUMBX014.nsn-intra.net> <8858_1391612876_52F253CC_8858_340_1_6B7134B31289DC4FAF731D844122B36E487208@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2254@DEMUMBX014.nsn-intra.net> <18813_1391619270_52F26CC6_18813_5166_1_6B7134B31289DC4FAF731D844122B36E487640@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F8ED8E.5090403@usdonovans.com>
In-Reply-To: <52F8ED8E.5090403@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje7Kmb+CDHZ+l7SY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGU8mT2Ir+BNfceDKQsYGxumeXYycHBICJhKnLy5nhLDFJC7c W88GYgsJHGKU+Pc+uIuRC8hewihxdcl6dpAEm4CdxKXTL5i6GDk4RASUJU7/cgAJCwu4SFxc 0AMVdpVY8FsfJCwiUCbxb9F/FhCbRUBV4vTuj2CreAV8Jf69usoIMf4gu8SbSV+YQRKcAnoS Ox8fA2tgBLrn+6k1TCA2s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbSWLt4e0sEPV6Ejem TmGDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxciem5iZk15uuIkRGPQH t/zW3cF46pzIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAmLv+YaJqQ lbzP/K49Q0fZJs/Tq63knCR/dOfq1N/5kyYp+FyhU68+dM0WX+swcZEvF28yTTYzerUpX3Sm +4lJtTVr/3D2BPa7zIoUeRWUvKBfb+7zO18cl3HvVWkpqhBZUpUrnXfr3YZiUUPNuxkTpk57 56XP8rDjMJO2ULOj9IbZ+4/8rVViKc5INNRiLipOBAC+xCGLSAIAAA==
Subject: Re: [Dime] [dime] #35: additional report types are proposed
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 21:44:14 -0000

Fine for me as well.
Thanks

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 16:18
To: dime@ietf.org
Subject: Re: [Dime] [dime] #35: additional report types are proposed

+1 on adding an agent behavior sub-section to section 5.5 and that it
should capture Ulrich's wording that an agent must be able to differentiate=
 OLRs and the resulting abatement on a per client basis.

Steve

On 2/10/14 5:09 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi all
>
> I also agree with Lionel and Nirav. As Ulrich proposes, I also think good=
 to have a clarification and the hereafter proposed sentence from Ulrich in=
 agent behavior (when acting on behalf of the client) is OK for me:
> "When an agent receives an OLR in response to a request initiated by a cl=
ient not supporting DOIC, this agent, acting on behalf of the client, needs=
 to (or MUST) bind the received OLR to the origin-host in the request of th=
e client".
>
> JJacques
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de=20
> lionel.morand@orange.com Envoy=E9 : mercredi 5 f=E9vrier 2014 17:55 =C0 :=
=20
> Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot);=20
> dime@ietf.org Objet : Re: [Dime] [dime] #35: additional report types=20
> are proposed
>
> If I'm correct, the following condition:
>
>        d) The values of the Origin-Host and Origin-Realm AVPs in the  req=
uest
>           match the values of the Destination-Host and Destination-Realm
>           AVPs respectively of the received message that contained the OC=
-
>           OLR AVP.
>
> is not correct as the message containing the OC-OLR AVP is an answer and =
there is Destination-Host or Destination-Realm AVPs in an answer.
>
> If you want to clarify something, it can be in the section describing the=
 agent behavior. And such clarification will be that when an agent received=
 an OLR in response to a request initiated by a client not supporting DOIC,=
 this agent needs to bind the received OLR to the origin-host of the client=
 (no need of the origin-realm).
>
> Lionel
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
> Envoy=E9 : mercredi 5 f=E9vrier 2014 17:43 =C0 : MORAND Lionel IMT/OLN; e=
xt=20
> Nirav Salot (nsalot); dime@ietf.org Objet : RE: [Dime] [dime] #35:=20
> additional report types are proposed
>
> Even if some feel this is implicit, it should not harm to add the d) cond=
ition explicitly please.
>
> -----Original Message-----
> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: Wednesday, February 05, 2014 4:08 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Nirav Salot (nsalot);=20
> dime@ietf.org
> Subject: RE: [Dime] [dime] #35: additional report types are proposed
>
> Isn't it implicit?
> An answer is sent to the origin-host of the corresponding request. The ag=
ent is not the targeting point of the answer and is not supposed to be the =
reacting node. Now if an agent wants to act on behalf a client not supporti=
ng the DOCI mechanism at the application, this agent will have to maintain =
a binding for this client. This requirement is not bound to the overload co=
ntrol mechanism but to any function provides by the agent on behalf of down=
stream clients.=20
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
> Envoy=E9 : mercredi 5 f=E9vrier 2014 10:32 =C0 : ext Nirav Salot (nsalot)=
;=20
> MORAND Lionel IMT/OLN; dime@ietf.org Objet : RE: [Dime] [dime] #35:=20
> additional report types are proposed
>
> Nirav,
> ... and this natural requirement is missing from the current draft.
>
> To address this requirement we could replace the descriptions for report =
types 0 and 1 with the decriptions of my proposed report types 2 and 3 resp=
ectively.
>
> As a consquence, however, the agent in the given example configuration wo=
uld have to store always OLRs per client even when S wants all clients to d=
o the same throttling. Would that be acceptable?
>
> Ulrich
>
>
> -----Original Message-----
> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
> Sent: Wednesday, February 05, 2014 10:03 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com;=20
> dime@ietf.org
> Subject: RE: [Dime] [dime] #35: additional report types are proposed
>
> Ulrich,
>
> I do not think so.
> If we believe that there should be host-specific OLR and if we want to su=
pport the model when the agent acts as reacting node (on behalf of the clie=
nt(s)), then the agents are naturally required to store OLR per client/host=
 behind the agent (based on the destination-host AVP in the answer message)=
.
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> Sent: Wednesday, February 05, 2014 2:24 PM
> To: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org
> Subject: RE: [Dime] [dime] #35: additional report types are proposed
>
> Hi Lionel, Nirav,
>
> your argument only holds in configurations where the client is the reacti=
ng node.
>
> In a configuration like this
>
>
> +-------+
> | C1    |          +------+
> |       |----------|  A   |               +------+
> +-------+          |      |               | S    |
>                    |      |---------------|      |
> +-------+          |      |               +------+
> | C2    |----------|      |
> |       |          +------+
> +-------+
> where clients C1 and C2 do not support DOIC and the same agent A takes th=
e role of the reacting node on behalf of both C1 and C2 the situation is di=
fferent. According to the current version of the draft this will result in =
big mess with frequent replacements of OLRs in A when e.g. S requests a 50%=
 reduction from C1 and 0% reduction from C2.=20
>
> Best regards
> Ulrich
>
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot=20
> (nsalot)
> Sent: Wednesday, February 05, 2014 5:50 AM
> To: lionel.morand@orange.com; dime@ietf.org
> Subject: Re: [Dime] [dime] #35: additional report types are proposed
>
> Same view as Lionel below.
> New report types seem more confusing than adding value.
>
> The reporting node knows the host which is going to receive the message (=
and hence report within the message) and hence it can generate "host specif=
ic" report and it insert into the message.
> No need to define new report types for achieving this.
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20
> lionel.morand@orange.com
> Sent: Tuesday, February 04, 2014 10:48 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #35: additional report types are proposed
>
> I don't see the added-value of these new report types.
> In any case the reporting node will decide which reduction value to send =
to each node and the reacting node will behave accordingly to the value rec=
eived in the OLR. So what is the point to say "this value applies to you on=
ly"?
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue=20
> tracker Envoy=E9 : mardi 4 f=E9vrier 2014 16:39 =C0 : MORAND Lionel IMT/O=
LN=20
> Cc : dime@ietf.org Objet : Re: [Dime] [dime] #35: additional report=20
> types are proposed
>
> #35: additional report types are proposed
>
> Description changed by lionel.morand@orange-ftgroup.com:
>
> Old description:
>
>> With regard to Overload Mitigation Differentiation per Client (#33)=20
>> two additional report types are proposed:
>>
>>    2  A host per client report.  The overload treatment should apply to
>>       requests for which all of the following conditions are true:
>>       a) The Destination-Host AVP is present in the request and its valu=
e
>>          matches the value of the Origin-Host AVP of the received messag=
e
>>          that contained the OC-OLR AVP.
>>       b) The value of the Destination-Realm AVP in the request=20
>> matches the
>>          value of the Origin-Realm AVP of the received message
>>          that contained the OC-OLR AVP.
>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
>>       d) The values of the Origin-Host and Origin-Realm AVPs in the=20
>> request
>>          match the values of the Destination-Host and Destination-Realm
>>          AVPs respectively of the received message that contained the OC=
-
>>          OLR AVP.
>>
>>    3  A realm per client report.  The overload treatment should apply to
>>       requests for which all of the following conditions are true:
>>       a) The Destination-Host AVP is absent in the request.
>>       b) The value of the Destination-Realm AVP in the request=20
>> matches the
>>          value of the Origin-Realm AVP of the received message
>>          that contained the OC-OLR AVP.
>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
>>       d) The values of the Origin-Host and Origin-Realm AVPs in the=20
>> request
>>          match the values of the Destination-Host and Destination-Realm
>>          AVPs respectively of the received message that contained the OC=
-
>>          OLR AVP.
> New description:
>
>  The -01 draft does not address the 3GPP requirement to allow reporting  =
DOIC endpoints to request different amount of load reduction from  differen=
t clients (see TR 29.809 clause 6.4.7).
>  Since 3GPP is the main consumer of DOIC it is proposed to address this  =
requirement by adding two new report types.
>  two additional report types are proposed:
>
>     2  A host per client report.  The overload treatment should apply to
>        requests for which all of the following conditions are true:
>        a) The Destination-Host AVP is present in the request and its valu=
e
>           matches the value of the Origin-Host AVP of the received messag=
e
>           that contained the OC-OLR AVP.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
>        d) The values of the Origin-Host and Origin-Realm AVPs in the  req=
uest
>           match the values of the Destination-Host and Destination-Realm
>           AVPs respectively of the received message that contained the OC=
-
>           OLR AVP.
>
>     3  A realm per client report.  The overload treatment should apply to
>        requests for which all of the following conditions are true:
>        a) The Destination-Host AVP is absent in the request.
>        b) The value of the Destination-Realm AVP in the request matches t=
he
>           value of the Origin-Realm AVP of the received message
>           that contained the OC-OLR AVP.
>        c) The value of the Application-ID in the Diameter Header of the
>           request matches the value of the Application-ID of the Diameter
>           Header of the received message that contained the OC-OLR AVP.
>        d) The values of the Origin-Host and Origin-Realm AVPs in the  req=
uest
>           match the values of the Destination-Host and Destination-Realm
>           AVPs respectively of the received message that contained the OC=
-
>           OLR AVP.
>
> --
>

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


From jean-jacques.trottin@alcatel-lucent.com  Tue Feb 11 13:52:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379AD1A076A for ; Tue, 11 Feb 2014 13:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9UTt0DvXlVr for ; Tue, 11 Feb 2014 13:52:47 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id A06E81A0773 for ; Tue, 11 Feb 2014 13:52:47 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1BLqiRO023504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Feb 2014 15:52:46 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1BLqian022382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 22:52:44 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 11 Feb 2014 22:52:44 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIcx34wrZRRvx1EKFdFq4TjstmpqmsICAgAAE6ICAABUugIACvZWAgAAwCoCAADL/AIAEjBxA///7RACAABhCgIABTnoAgAACQICAADisgIAADXYAgAAEyICAAAGagIAAZP8w
Date: Tue, 11 Feb 2014 21:52:43 +0000
Message-ID: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.9050205@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.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: [135.239.27.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 21:52:52 -0000

Dear all

I come back a bit late on this long debate to confirm my position that I sh=
are with  Ulrich MCruz Nirav and I think now Lionel and that I again summar=
ize here in these two statements :=20
- Host OLR based control applies to requests where Destination Host is know=
n
- Realm OLR based control applies to requests where Destination Host is not=
 known (only the Destination realm).

>From History, we have started by defining the Host report so to control the=
 traffic towards each server,(our main goal), but we observed a difficulty =
when the reacting node does not know  the host to which a  request is sent =
and for this  we introduced the realm report. Annex B1 example in the draft=
 is the use case well illustrating  this approach and  which corresponds to=
 the above statements.

Another point which was mentioned, is, for  the reacting node, to keep the =
throttling based on realm report independent of the throttling based on the=
 host report, this is naturally achieved with the two above statements as w=
e distinguish requests having a destination host from those having not. But=
 if we can apply both reports to the same request, then we need additional =
rules eg  which report prevails; in the discussion there were also divergen=
ce on this point, but we can imagine other rules eg the report that has the=
 highest reduction value prevails, why not in some cases, so a trend to ove=
rcomplexify.=20

For me the two above statements avoid overlapping between the two reports  =
and are simple to apply, so I keep my preference for these two statements.

Best regards

JJacques  =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com
Envoy=E9=A0: mardi 11 f=E9vrier 2014 16:31
=C0=A0: MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

So now I understand Ulrich, Maria Cruz and JJ comments.

"My" proposal would force the servers in the realm to always send an OLR ju=
st to say "I'm not overloaded" i.e. with the value 0. That is anyway a poss=
ibility.
But if we want to avoid that, Realm type must only apply to message without=
 destination host.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com Envoy=E9=A0: mardi 11 f=E9vrier 2014 16:25 =C0=A0: Steve Donovan; di=
me@ietf.org Objet=A0: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AV=
P

Hi Maria Cruz,

Actually I've missed this point. Sorry.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo=
y=E9=A0: mardi 11 f=E9vrier 2014 16:08 =C0=A0: dime@ietf.org Objet=A0: Re: =
[Dime] [dime] #34: Semantics of OC-Report-Type AVP


On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
> Lionel,
>
> About first case:
>
> - If the reacting node has received an indication only for Realm=20
> traffic Reduction, apply Realm reduction is for any message, with=20
> Destination-Realm and with/without Destination-Host
>
> I do not agree on this, since if Destination Host is used, there is no re=
ason to throttle messages if this Host has not provided any OLR.
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not have=
 visibility of the entire realm.=20
> This is in line with the example used from the beginning:
> ---------
> ..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% =
overloaded, and the aggregated realm overload is 25%. Why should a client d=
o a 25% throttling when sending host type requests to the not at all overlo=
aded S1?
> What is wrong with letting the client
> -not throttle host-type requests to S1, -throttle host type request to=20
> S2 with 50% and -throttle realm type requests wit 25%?
> ------------
>
> And I think this is what JJ commented:
> [JJ] there may be a misunderstanding somewhere, so good to try to clarify=
; coming back to Ulrich example, Host S1 is not overloaded, so reacting nod=
e has not received Host reduction OLR for S1. But as there  is a realm redu=
ction, reacting node will reduce traffic with destination Host S1.
>
> In my opinion, reducing traffic to S1 is wrong.
SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.
>
> Regards
> /MCruz
>
> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: martes, 11 de febrero de 2014 11:57
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi maria-cruz,
>
> JJ agreed on the following approach:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>   =20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
> =20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> What is the issue with this approach?
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20
> Bartolome Envoy=E9 : mardi 11 f=E9vrier 2014 11:49 =C0 : dime@ietf.org Ob=
jet=20
> : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hello,
> I agree with JJ:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>
> [MCruz] And... if the request is sent to a Destination-Host, if there is =
any applicable OLR, it will be received immediately in the answer, and will=
 be applicable from next request on.
> Simple and robust in my opinion. Then, we do not need to evaluate whether=
 we have OLR for Realm and/or Host, and even check their validity & applica=
bility.
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN,=20
> JEAN-JACQUES (JEAN-JACQUES)
> Sent: lunes, 10 de febrero de 2014 15:00
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Hi Lionel
>
> Please see in line
>
> -----Message d'origine-----
> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9=
=20
> : lundi 10 f=E9vrier 2014 14:25 =C0 : TROTTIN, JEAN-JACQUES=20
> (JEAN-JACQUES); dime@ietf.org Objet : RE: [Dime] [dime] #34: Semantics=20
> of OC-Report-Type AVP
>
> I disagree and my proposal was somehow misunderstood.
>
> I don't see the issue to have the following sequence:
>
> - If the reacting node has received an indication only for Realm traffic =
Reduction, apply Realm reduction is for any message, with Destination-Realm=
 and with/without Destination-Host [JJ] there may be a misunderstanding som=
ewhere, so good to try to clarify; coming back to Ulrich example, Host S1 i=
s not overloaded, so reacting node has not received Host reduction OLR for =
S1. But as there  is a realm reduction, reacting node will reduce traffic w=
ith destination Host S1.
>   =20
> - If the reacting node has received an indication only for host traffic r=
eduction, apply host reduction for messages containing a Destination-Host. =
No reduction for messages with only a Destination-Realm.
> [JJ] OK
> =20
> - If the reacting node has received both an indication for host traffic a=
nd for realm traffic reduction, only the realm reduction will apply for mes=
sages with only the Destination-Realm AVP and only the host reduction will =
apply for messages with the Destination-Host AVP (and the Destination-Realm=
 AVP).
> [JJ] OK, Host reduction prevails
>
> In other words, as said earlier, the Host reduction prevails over realm r=
eduction when the overloaded host is inside an overloaded realm and the rea=
cting has received info about both type of overload.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN,=20
> JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : lundi 10 f=E9vrier 2014 13:56 =C0 =
:=20
> dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of=20
> OC-Report-Type AVP
>
> Dear  all
>
> I share Ulrich and MCruz views,
> - Host OLR based control applies to requests where Destination Host is=20
> known
> - Realm OLR based control applies to requests where Destination Host is n=
ot known (only the Destination realm).
>
> I think it is simple, otherwise as MCruz indicated it complicates; e.g ab=
out the Ulrich's example where the Host S1 is not overloaded but the realm =
is overloaded. the client will not receive Host OLR reports from host S1 (s=
o no explicit traffic reduction requested by S1), but according to Lionel c=
omment, I understand  client will have to throttle the requests sent to S1 =
according to realm OLR, so how to avoid this.
>
> JJacques
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20
> Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 17:15 =C0 : dime@ietf.org=
=20
> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Dear all,
>
> I am in favor of the proposal made by Ulrich in the sequence diagram he p=
rovided.
> ----
> As a summary:
> Consequently the reacting node will receive realm type OLRs from the agen=
t and host type OLRs from the servers.
> The received realm type OLR will be relevant for the reacting node when s=
ending/throttling realm type requests; the received host type OLR will be r=
elevant for the reacting node       when sending/throttling host type reque=
sts.
> -----
>
> It may occur though, that a Client has only received Realm type OLR, and =
then it has to send a request to one specific host, then the Client will no=
t apply any restriction, but as soon as the response is received back, Clie=
nt will update Host type OLR.  Same will apply when only Host type OLR has =
been received by Client.
> The alternative will be to always send back from an Agent both Host OLR p=
lus Realm OLR, but I do not think this is necessary and may complicate the =
solution.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20
> (NSN - DE/Munich)
> Sent: viernes, 07 de febrero de 2014 14:13
> To: ext Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Friday, February 07, 2014 11:21 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> I better like Lionel's approach, but even that is not ok in the unlikely=
 extreme case where we have two servers in a realm, S1 is not overloaded at=
 all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why s=
hould a client do a 25% throttling when sending host type requests to the n=
ot at all overloaded S1?
>> What is wrong with letting the client -not throttle host-type=20
>> requests to S1, -throttle host type request to
>> S2 with 50% and -throttle realm type requests wit 25%?
> Isn't this what Lionel said below?
>  no it is not
>  I am OK with Lionel's
> "wording" here.
>
> - Jouni
>
>> =20
>> =20
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
>> lionel.morand@orange.com
>> Sent: Wednesday, February 05, 2014 4:14 PM
>> To: Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>> =20
>> I tend to agree except that I would reverse the logic as for the routing=
 principles: the Destination-host takes precedence when present over Destin=
ation-Realm. So the realm abatement is applied in any case except if there =
is an explicit report for the destination-host.
>> =20
>> Lioenl
>> =20
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet : R=
e:
>> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>> =20
>> It makes more sense to me for a realm report to apply to all requests ta=
rgeted for that realm, independent the type of request.  This implies that =
it would apply to requests that also have a Destination-Host specified.
>>
>> If this is the definition of a realm report then we need to specify the =
interaction between realm reports and host reports.
>>
>> I propose that throttling would occur on the realm first and the host se=
cond.  If a message targetted for the host is throttled as a result of real=
m overload then that throttled message would count as part of the reduction=
 needed to address the host overload.  Messages to the host that survive re=
alm abatement would then be candidates for host overload.
>>
>> Steve
>>
>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
>> The case "Realm" as described below raises another question: is it prohi=
bited for a realm to only rely on a global overload report for the whole re=
alm, whatever the nodes inside this realm?
>> If not, only OLR with the report type "realm" would be received by the r=
eacting node. And the reduction indicated in the OLR will apply always for =
the realm, whatever the presence of Destination-host AVP in the request... =
except if an explicit report with the type "Host" as been received for this=
 destination-host.
>> =20
>> Does it make sense?
>> =20
>> Lionel
>> =20
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
>> =C0 : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>> =20
>> #34: Semantics of OC-Report-Type AVP
>> =20
>>  Text in clause 4.6  does not fully explain to which requests=20
>> overload treatment of a given report type applies.
>>  Proposal:
>> =20
>>     0  A host report.  The overload treatment should apply to requests
>>        for which all of the following conditions are true:
>>        a) The Destination-Host AVP is present in the request and its val=
ue
>>           matches the value of the Origin-Host AVP of the received messa=
ge
>>           that contained the OC-OLR AVP.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diamete=
r
>>           Header of the received message that contained the OC-OLR AVP.
>> =20
>> =20
>> =20
>>     1  A realm report.  The overload treatment should apply to
>>        requests for which all of the following conditions are true:
>>        a) The Destination-Host AVP is absent in the request.
>>        b) The value of the Destination-Realm AVP in the request matches =
the
>>           value of the Origin-Realm AVP of the received message
>>           that contained the OC-OLR AVP.
>>        c) The value of the Application-ID in the Diameter Header of the
>>           request matches the value of the Application-ID of the Diamete=
r
>>           Header of the received message that contained the OC-OLR AVP.
>> =20
>> =20
>> _____________________________________________________________________
>> _ ___________________________________________________
>> =20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>> =20
>> This message and its attachments may contain confidential or=20
>> 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 d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> 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
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez 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 i=
nformation that may be protected by law; they should not be distributed, us=
ed or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

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


From maria.cruz.bartolome@ericsson.com  Tue Feb 11 13:59:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430CB1A0760 for ; Tue, 11 Feb 2014 13:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_HZFfUDq2Zv for ; Tue, 11 Feb 2014 13:59:30 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4725A1A077B for ; Tue, 11 Feb 2014 13:59:27 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-76-52fa9d3d9747
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0B.B5.23809.D3D9AF25; Tue, 11 Feb 2014 22:59:26 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 22:59:25 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
Thread-Index: AQHPJLlGaYcs5B7+bkSRJFt4wCbOs5quglmQ///z0wCAAilQQA==
Date: Tue, 11 Feb 2014 21:59:25 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usdonovans.com>
In-Reply-To: <52F8DB0C.3000603@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920977322FESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvja7d3F9BBo8OsVvM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFd3ZjMWXN/BVNHWfpetgXFzJ1MXIyeHhICJxNblm9ggbDGJ C/fWg9lCAocYJfoPyXUxcgHZSxgl7q7rZAFJsAnYSVw6/QKomYNDREBZ4vQvB5CwsECgxN1l exlBbBGBIIk7v64xQ9hOEjfmd7CD2CwCqhJnL18EG8Mr4Cux+dFCRoj5PRwSxxqnsIDM5BTQ k2j4lAlSwwh0z/dTa8DuZBYQl7j1ZD7UzQISS/acZ4awRSVePv7HCmErSaw9vJ0Foj5f4vK7 40wQuwQlTs58wjKBUWQWklGzkJTNQlIGEdeTuDF1ChuErS2xbOFrZghbV2LGv0MsyOILGNlX MbLnJmbmpJcbbWIERsrBLb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYw7PHcGR8dyGHy7tiMizGaC30Qfx/rkR82vF2g1LbrJ/OmNcLP4luiK9MYtwScY 9l+s+PQ6bGqCuOact5EfPfRFpiw1X3P49YmKRU/v7PuenrW5PPSNk9CDKTEhy3RkbPi/SgW8 uKxz6cweiS1Tcz5fKjCeG/M0hSfll6DA+yvbLI/KaRUqXIpQYinOSDTUYi4qTgQAUK7WimIC AAA=
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within	OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 21:59:35 -0000

--_000_087A34937E64E74E848732CFF8354B920977322FESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It sounds reasonable to me as well.
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 14:59
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR

+1
On 2/10/14 7:47 AM, lionel.morand@orange.com wrote:

I would add, maybe even before the format (NTP time based), that the real r=
equirements for the sequence-number are:



- Globally/eternally unique

- increase monotonically over time, including over a reboot (as remind by S=
teve)



The NTP time based type is just a guidance provided by the draft on how to =
generate sequence numbers with such properties.



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen

Envoy=E9 : samedi 8 f=E9vrier 2014 11:33

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR





Sounds acceptable. Would the following then work for all:



o clarify that once the overload report expires there is no

  reason to remember anything about it

o the sequence number would be similar to session-id.. based

  on the NTP time + any vendor specific data to make it

  "globally and eternally unique".



- Jouni







On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Steve,



sounds like an acceptable proposal which allows to come back to sync after =
OLR expiry.

This requires however an update of clause 5.5.2 to clearly state

Once the overload report expires there is no reason to remember anything ab=
out it and the next overload report received could, conceivably have any va=
lue.





Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Thursday, February 06, 2014 4:50 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



A couple of things -



The requirement is that the sequence number increase monotonically over tim=
e, including over a reboot.  Use of NTP time is one way of doing this but i=
s not the only way.  Someone could, for instance, use a time stamp to set t=
he sequence number for the first overload report sent after a reboot and th=
en increment the sequence number value by one for each subsequent overload =
report sent.  This actually has better properties than an NTP time stamp as=
 it would take much longer to roll over.  One could also create a global se=
quence number service that is not tied to time and have a Diameter server q=
uery that global sequence number server after each reboot.



We also have a duration timer on overload reports.  This gives us one way t=
o reset.  It should only be required to remember the sequence number of an =
active overload report.  Once the overload report expires there is no reaso=
n to remember anything about it and the next overload report received could=
, conceivably have any value.



The requirement we need is similar to the session-id in the base Diameter s=
pecification.  The wording there is -- "The Session-Id MUST be globally and=
 eternally unique".  We just need eternally as the spacial differentiation =
is based on the context of the message carrying the overload report.



It would be perfectly valid for the DOIC draft to suggest the use of NTP ti=
mestamps to populate the sequence number but it should be worded in a simil=
ar fashion as the Diameter base RFC -- The Session-Id includes a mandatory =
portion and an implementation-defined portion; a recommended format for the=
 implementation-defined portion is outlined below ..."



Steve



On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I cannot understand what is the problem with mandating timestamp.

But I can see interoperability problems with the current definition:



Assume the sender sends sequence numbers

1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....

but the receicer for any reason receives

1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....

The receiver would accept

1, 1, ... 1, 2, 2, ... 2, 3, 30000

and then silently discards

3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....

with no way to come back to sync.



Are we sure that this cannot happen?



Mandating timestamp for sequence number generation at the sender and plausi=
bility checking (i.e. received value must be between stored value and time =
of reception) for the receiver may not be the only way to solve the problem=
. But in the moment I don't see another way.



Ulrich





-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell

Sent: Wednesday, February 05, 2014 4:57 PM

To: ext lionel.morand@orange.com

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



My point is, we have an interop requirement that the sequence number always=
 increases over time scope. We do not have the interop requirement that the=
 sequence number be implemented as a time stamp. A time stamp is probably a=
 good way to  meet the interop requirements, but it is not, in itself, an i=
nterop requirement.



On Feb 5, 2014, at 9:53 AM,   wr=
ote:



Not sure to understand: if there is a kind of "interop requirement", it is =
a case for a "MUST".

We are not violating anything.



Reporting and reacting nodes will just rely on the Diameter interfaces to k=
now how to handle the received sequence-number. So any MUST on the format o=
f the sequence-number is acceptable if it avoids interop issues.



-----Message d'origine-----

De : Ben Campbell [mailto:ben@nostrum.com]

Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47

=C0 : MORAND Lionel IMT/OLN

Cc : Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR



I concur with Steve on this one. Using a time stamp is a good way to meet t=
he requirements, but it's not our job to normatively state an implementatio=
n. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Sect=
ion 6 of 2119 includes the following:



"In particular, [normative requirements] MUST only be used where it is

  actually required for interoperation or to limit behavior which has

  potential for causing harm (e.g., limiting retransmisssions)  "



The only appropriate reason to require a timestamp would be if we expected =
peers to interpret the field as a point in time. OTOH, it would be perfectl=
y reasonable to state the actual interop requirements, then add a non-norma=
tive (probably indented) paragraph suggesting that a timestamp is a good wa=
y to do this.



On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:



I think the out-of-sync failover described by Ulrich is a good use case to =
mandate a specific semantic.



Is there any specific NOT to mandate the use of NTP timestamps if it is a s=
imple way to solve the possible issues and please everyone?



Lionel



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR



How the sequence number is implemented is an implementation decision.  Ther=
e is no reason to mandate that is be an NTP timestamp.  That should be incl=
uded only as one way of addressing the requirement.



Steve



On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:

I also agree.



Regards,

Nirav.



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange=
.com

Sent: Tuesday, February 04, 2014 11:50 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



The existing wording seems actually fuzzy.

If it is "like an NTP timestamp", be proud and say it loud!



In summary: ok with the proposal if it clarifies this handling of this sequ=
ence-number.



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:50

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR



#32: Sequence-Number Time-Stamp values within OC-OLR



The -01 draft says in clause 4.4:

   From the functionality point of view, the OC-Sequence-Number AVP MUST

   be used as a non-volatile increasing counter between two overload

   control endpoints (neglecting the fact that the contents of the AVP

   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only

   required to be unique between two overload control endpoints.

   Sequence numbers are treated in uni-directional manner, i.e. two

   sequence numbers on each direction between two endpoints are not

   related or correlated.



   When generating sequence numbers, the new sequence number MUST be

   greater than any sequence number previously seen between two

   endpoints within a time window that tolerates the wraparound of the

   NTP timestamp (i.e. approximately 68 years).





With this mechanism it is difficult to get back to sync once you are out  o=
f sync (for whatever reason).

It is proposed to mandate that the Sequence Number is a real 64-bit NTP  ti=
mestamp (RFC5905) indicating the point in time when the OLR was created,  a=
nd to mandate that  OLRs with a time stamp higher than time of reception  m=
ust be ignored by the reacting node.





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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



_______________________________________________

DiME mailing list

DiME@ietf.org

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_087A34937E64E74E848732CFF8354B920977322FESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











It sounds reasonable to m=
e as well.


/MCruz<=
/p>

 <=
/p>





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

Sent: lunes, 10 de febrero de 2014 14:59

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values wi=
thin OC-OLR






 


+1




On 2/10/14 7:47 AM, 
lionel.morand@orange.com wrote:






I would add, maybe even before the format (NTP time based), that the r=
eal requirements for the sequence-number are:


 


- Globally/eternally unique


- increase monotonically over time, including over a reboot (as remind=
 by Steve) 


 


The NTP time based type is just a guidance provided by the draft on ho=
w to generate sequence numbers with such properties.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Jouni Korhonen


Envoy=E9 : samedi 8 f=E9vrier 2014 11:33


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : dime@ietf.org


Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR


 


 


Sounds acceptable. Would the following then work for all:

 


o clarify that once the overload report expires there is no=



  reason to remember anything about it


o the sequence number would be similar to session-id.. based 


  on the NTP time + any vendor specific data to make it =



  "globally and eternally unique".

 


- Jouni


 


 


 


On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Steve,


 


sounds like an acceptable proposal which allows to come back to sync a=
fter OLR expiry.


This requires however an update of clause 5.5.2 to clearly state<=
/o:p>


Once the overload report expires there is no reason to remember anythi=
ng about it and the next overload report received could, conceivably have a=
ny value. 


 


 


Ulrich


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Thursday, February 06, 2014 4:50 PM


To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


A couple of things - 


 


The requirement is that the sequence number increase monotonically ove=
r time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time=
 stamp to set the sequence number for the first overload report sent after =
a reboot and then increment the sequence number value by one for each subse=
quent overload report sent.  This actually has better properties than =
an NTP time stamp as it would take much longer to roll over.  One coul=
d also create a global sequence number service that is not tied to time and=
 have a Diameter server query that global sequence number server after each=
 reboot.


 


We also have a duration timer on overload reports.  This gives us=
 one way to reset.  It should only be required to remember the sequenc=
e number of an active overload report.  Once the overload report expir=
es there is no reason to remember anything about it and the next overload r=
eport received could, conceivably have any value. 


 


The requirement we need is similar to the session-id in the base Diame=
ter specification.  The wording there is -- "The Session-Id MUST =
be globally and eternally unique".  We just need eternally as the=
 spacial differentiation is based on the context of the message carrying th=
e overload report.


 


It would be perfectly valid for the DOIC draft to suggest the use of N=
TP timestamps to populate the sequence number but it should be worded in a =
similar fashion as the Diameter base RFC -- The Session-Id includes a manda=
tory portion and an implementation-defined portion; a recommended format fo=
r the implementation-defined portion is outlined below ..."=



 


Steve


 


On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I cannot understand what is the problem with mandating timestamp.=



But I can see interoperability problems with the current definition:


 


Assume the sender sends sequence numbers


1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 


but the receicer for any reason receives 


1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,...=
. 


The receiver would accept


1, 1, ... 1, 2, 2, ... 2, 3, 30000


and then silently discards


3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 


with no way to come back to sync.


 


Are we sure that this cannot happen?


 


Mandating timestamp for sequence number generation at the sender and p=
lausibility checking (i.e. received value must be between stored value and =
time of reception) for the receiver may not be the only way to solve the pr=
oblem. But in the moment I don't see another way.


 


Ulrich


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Ben Campbell


Sent: Wednesday, February 05, 2014 4:57 PM


To: ext lionel.morand@oran=
ge.com


Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


My point is, we have an interop requirement that the sequence number a=
lways increases over time scope. We do not have the interop requirement tha=
t the sequence number be implemented as a time stamp. A time stamp is proba=
bly a good way to  meet the interop requirements, but it is not, in it=
self, an interop requirement.


 


On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:


 


Not sure to understand: if there is a kind of "interop requiremen=
t", it is a case for a "MUST".


We are not violating anything.


 


Reporting and reacting nodes will just rely on the Diameter interfaces=
 to know how to handle the received sequence-number. So any MUST on the for=
mat of the sequence-number is acceptable if it avoids interop issues.<=
/o:p>


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] 


Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47


=C0 : MORAND Lionel IMT/OLN


Cc : Steve Donovan; dime@ietf.org=



Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


I concur with Steve on this one. Using a time stamp is a good way to m=
eet the requirements, but it's not our job to normatively state an implemen=
tation. In fact, it violates an RFC 2119 "MUST" level requirement=
 to do so. Section 6 of 2119 includes the following:


 


"In particular, [normative requirements] MUST only be used where =
it is


  actually required for interoperation or to limit behavior which=
 has


  potential for causing harm (e.g., limiting retransmisssions)&nb=
sp; "


 


The only appropriate reason to require a timestamp would be if we expe=
cted peers to interpret the field as a point in time. OTOH, it would be per=
fectly reasonable to state the actual interop requirements, then add a non-=
normative (probably indented) paragraph suggesting that a timestamp is a go=
od way to do this.


 


On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:


 


I think the out-of-sync failover described by Ulrich is a good use cas=
e to mandate a specific semantic.


 


Is there any specific NOT to mandate the use of NTP timestamps if it i=
s a simple way to solve the possible issues and please everyone?=



 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


How the sequence number is implemented is an implementation decision.&=
nbsp; There is no reason to mandate that is be an NTP timestamp.  That=
 should be included only as one way of addressing the requirement.


 


Steve


 


On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:


I also agree.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: Tuesday, February 04, 2014 11:50 PM


To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


The existing wording seems actually fuzzy.


If it is "like an NTP timestamp", be proud and say it loud!<=
o:p>


 


In summary: ok with the proposal if it clarifies this handling of this=
 sequence-number.


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]


Envoy=E9 : mardi 4 f=E9vrier 2014 09:50


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


 


#32: Sequence-Number Time-Stamp values within OC-OLR


 


The -01 draft says in clause 4.4:


   From the functionality point of view, the OC-Sequence-Num=
ber AVP MUST


   be used as a non-volatile increasing counter between two =
overload


   control endpoints (neglecting the fact that the contents =
of the AVP


   is a 64-bit NTP timestamp [RFC5905]).  The sequence =
number is only


   required to be unique between two overload control endpoi=
nts.


   Sequence numbers are treated in uni-directional manner, i=
.e. two


   sequence numbers on each direction between two endpoints =
are not


   related or correlated.


 


   When generating sequence numbers, the new sequence n=
umber MUST be


   greater than any sequence number previously seen between =
two


   endpoints within a time window that tolerates the wraparo=
und of the


   NTP timestamp (i.e. approximately 68 years).

 


 


With this mechanism it is difficult to get back to sync once you are o=
ut  of sync (for whatever reason).


It is proposed to mandate that the Sequence Number is a real 64-bit NT=
P  timestamp (RFC5905) indicating the point in time when the OLR was c=
reated,  and to mandate that  OLRs with a time stamp higher than =
time of reception  must be ignored by the reacting node.

 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_087A34937E64E74E848732CFF8354B920977322FESESSMB101erics_--


From jouni.nospam@gmail.com  Tue Feb 11 14:31:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957091A0798 for ; Tue, 11 Feb 2014 14:31:49 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ipjjw-Xmrxg5 for ; Tue, 11 Feb 2014 14:31:47 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 167F31A0793 for ; Tue, 11 Feb 2014 14:31:46 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id w7so6443614lbi.35 for ; Tue, 11 Feb 2014 14:31:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HYwDcDxzUEe4syZmYs95AOjjKKq2z9xSkDKMUFNK6i4=; b=BLAfUaiHiM8EAYoz9ETB6J1Y/L/R457Kcb7rFqDNSNOf8cavnqhNH6cJt/wqVPeX4v lZDxZOTx53esX67PRxYk/+1EdSKx8QmpATkOTKHQRoK4MtnbJ6ICarRi5J/LtNu8PrwU YpmmkRum+95D2XcWJTfEgccJAEMpnQq2SmYsdxINcUVMUyR2C1xq9Ct+U5sCOp4+AuJe vyJcHzIIxD/hPpk40BYbLm6/E5p0yyDG7mMrzOGFR/a25WQqCuBTf3rtEElAr4h+1pSl UxZt2Icm6z66o9XlYsmk7w6hfFa56NDQHTT0DSUlJcNR9G3UPA/yKS72f+45FlBcovFy MlTA==
X-Received: by 10.112.144.35 with SMTP id sj3mr3335010lbb.44.1392157905243; Tue, 11 Feb 2014 14:31:45 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:4530:967a:5206:7997? ([2001:1bc8:101:f101:4530:967a:5206:7997]) by mx.google.com with ESMTPSA id gi5sm21418389lbc.4.2014.02.11.14.31.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 14:31:42 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se>
Date: Wed, 12 Feb 2014 00:31:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload	reports expire
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 22:31:49 -0000

Fine with me.

- Jouni

On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome =
 wrote:

> Ben, Nirav,
>=20
> I follow same argumentation.
> Regards
> /MCruz
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot =
(nsalot)
> Sent: martes, 11 de febrero de 2014 11:23
> To: Ben Campbell; Jouni Korhonen
> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting =
overload reports expire
>=20
> Ben,
>=20
> I resonate with your thinking below.
>=20
> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: Monday, February 10, 2014 9:54 PM
> To: Jouni Korhonen
> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting =
overload reports expire
>=20
>=20
> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen  =
wrote:
>=20
>>=20
>> My reasoning for explicit termination was that knowing the=20
>> implementation folks they will let overload conditions expire unless =
advised otherwise.
>> And having unnecessary stuff hanging around waiting for a cleanup is=20=

>> not a good thing in general. But I am open here for other options..
>>=20
>=20
> I think it's reasonable to say that a reporting node should terminate =
an overload condition in a timely manner. But if it's about to expire =
anyway, then expiration might be just as timely as an explicit report.=20=

>=20
> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Tue Feb 11 14:32:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2AC1A07B1 for ; Tue, 11 Feb 2014 14:32:32 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeCcm7EFyPfN for ; Tue, 11 Feb 2014 14:32:29 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC51A0798 for ; Tue, 11 Feb 2014 14:32:29 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id w7so6339696lbi.7 for ; Tue, 11 Feb 2014 14:32:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mMOBFPesY5Z/kztn6/lfSisP0Ttep8jHQUt7pWUMMH4=; b=VzGOBLzxhA146uqgmXXWjh8zYiP629rjJMdigccwWpynLBTS4H3bp0Xi9YRFWwEADV OeBv3tGzoiK0j6j9BVicLuJ6nnDanuunvbknD8SUUehHF8sR6XYmhxJc3OYJyzKzbQHx 1lxM2Zw1w6/b4LPVS1EG/HZOR2FIgCvFpspWZEs/Jt4ro8h/1fh24meJwVc62ljRTjgj tCAioC8tCjKCUGC9TCr3B4KOBA1LoslmTfG9ZhFA7HdbUSNBuwNkEQmrMbbZGniNSUpa QJFpGoBXKWkf7NlpoviDm2Bz/M+/99+iGGEPlcZF6uruHGVkz51FWTr35/x0IhqkzEMw 1dbA==
X-Received: by 10.112.77.138 with SMTP id s10mr2958201lbw.59.1392157946743; Tue, 11 Feb 2014 14:32:26 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:4530:967a:5206:7997? ([2001:1bc8:101:f101:4530:967a:5206:7997]) by mx.google.com with ESMTPSA id gi5sm21418389lbc.4.2014.02.11.14.32.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 14:32:26 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Wed, 12 Feb 2014 00:32:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <81534CDC-4132-450B-88FB-853E1085CA21@gmail.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com> 
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 22:32:32 -0000

Works for me.

- JOuni

On Feb 11, 2014, at 1:55 AM, Ben Campbell  wrote:

> So, here's some proposed text. (intentionally ignoring the related =
discussion about handling invalid values):
>=20
> Section 4.5, first paragraph, last 2 sentences:
>=20
> Old:
>=20
> Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 =
hours) MUST NOT be used. Invalid validity duration values are treated as =
if the OC-Validity-Duration AVP were not present.
>=20
> New:
>=20
> Validity duration values above 86400 MUST NOT be used. Invalid =
validity duration values are treated as if the OC-Validity-Duration AVP =
were not present. A value of zero (0) indicates that an existing =
overload condition has ended and that the reporting node is in a stable =
condition.
>=20
> Section 4.7, 2nd paragraph:
>=20
> Old:
>=20
>  The value of the Reduction-Percentage AVP is between one (1) and one =
hundred (100).  Values greater than 100 are interpreted as 100.  The =
value of 100 means that no traffic is expected, i.e. the reporting node =
is under a severe load and ceases to process any new messages. The =
Reduction-Percentage AVP MUST be present in an overload report that uses =
the default abatement algorithm.
>=20
> Note that there is no zero (0) value defined for the =
Reduction-Percentage AVP. A zero value would logically indicate that no =
overload abatement is requested. Instead, reporting nodes use a =
OC-Validity-Duration AVP value of zero (0) to indicate the end of an =
overload condition. [Section 4.5]
>=20
>=20
>=20
>=20
>=20
>=20
> On Feb 10, 2014, at 4:12 PM, Jouni Korhonen  =
wrote:
>=20
>> Just post it here.
>>=20
>>=20
>>=20
>> On Feb 10, 2014, at 6:25 PM, Ben Campbell  wrote:
>>=20
>>> Okay. Does that mean we should assign the issue to me in the =
tracker?
>>>=20
>>> On Feb 10, 2014, at 10:06 AM, Jouni Korhonen =
 wrote:
>>>=20
>>>>=20
>>>> Ben,
>>>>=20
>>>> Propose some text and we can see how it fits in.
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>> On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:
>>>>=20
>>>>>=20
>>>>> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen =
 wrote:
>>>>>=20
>>>>>>=20
>>>>>> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>>>>>>=20
>>>>>>> #45: Why is a validity duration of 0 disallowed?
>>>>>>>=20
>>>>>>> Section 4.5 disallows a validity duration of zero. Why do we =
want to
>>>>>>> disallow that? It would allow a quick way of ending any existing =
overload
>>>>>>> condition without worrying about the semantics of the abatement =
algorithm.
>>>>>>> (We currently use a reduction percentage of zero to end an =
overload
>>>>>>> condition--but that's specific to the loss algorithm and might =
not make
>>>>>>> sense for all future ones.)
>>>>>>=20
>>>>>> Right. Avoiding two ways of ending overload condition was the =
reason.
>>>>>> I am OK to have validity duration 0 as an additional method =
ending the
>>>>>> overload condition based on the reasoning above.
>>>>>>=20
>>>>>=20
>>>>> I would go further and make duration 0 the _preferred_ way, for =
two reasons:
>>>>>=20
>>>>> 1) It's algorithm independent. (reduction-percentage of 0 is =
specific to algorithms that use reduction percentage.)
>>>>>=20
>>>>> 2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From jouni.nospam@gmail.com  Tue Feb 11 14:43:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6208B1A07C5 for ; Tue, 11 Feb 2014 14:43:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQgeYWhhrg8h for ; Tue, 11 Feb 2014 14:43:05 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 106CB1A0767 for ; Tue, 11 Feb 2014 14:43:04 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id u14so6341351lbd.23 for ; Tue, 11 Feb 2014 14:43:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LP3qWLR87LXlTDHQGDhEsJKHo1KtOg/faEtCsgYMFfM=; b=vPwmJGlfu+ShTIyzsOFYTmNdaAqgFv9QJDZ3j1FDZGI8Jek3li8pDBLL6kRfgUIcEb HeGkI3185sU6vGRc/izZmDhpeHeVCYhJDJgtSQ9KGJLhfYUU4SgEOw4l4987NSWI7Csd Jg8s08TeufcKiKAfOSAAiX/Yx5Zsvv+wVVgMwtTVkWAXe5a6E2l7cjIi/3MY9iX1HxxP smV8Bdt4jDCmHVZd3qZHh0NL8xqU7avATfpB5DPVtbAOF7aL/0VMzuJTuV1CSxph0wpJ OI2Xf0Op8w+Vt2oLBFxoVpEQs1Wmfv1kFHVVGFqjxvzyWAGsToLE8aN7D1Jj9b0tFc0z doSA==
X-Received: by 10.112.198.135 with SMTP id jc7mr388569lbc.75.1392158583749; Tue, 11 Feb 2014 14:43:03 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:4530:967a:5206:7997? ([2001:1bc8:101:f101:4530:967a:5206:7997]) by mx.google.com with ESMTPSA id w2sm30004107lad.4.2014.02.11.14.43.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 14:43:00 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se>
Date: Wed, 12 Feb 2014 00:42:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within	OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 22:43:08 -0000

If the NTP is only going to be guidance when building the globally
and eternally unique sequence number, IMHO better not mention NTP
then at all. Just include the required properties below. One less
mandatory reference..

- Jouni


On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome =
 wrote:

> It sounds reasonable to me as well.
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: lunes, 10 de febrero de 2014 14:59
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
> =20
> +1
> On 2/10/14 7:47 AM, lionel.morand@orange.com wrote:
> I would add, maybe even before the format (NTP time based), that the =
real requirements for the sequence-number are:
> =20
> - Globally/eternally unique
> - increase monotonically over time, including over a reboot (as remind =
by Steve)=20
> =20
> The NTP time based type is just a guidance provided by the draft on =
how to generate sequence numbers with such properties.
> =20
> Lionel
> =20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoy=E9 : samedi 8 f=E9vrier 2014 11:33
> =C0 : Wiehe, Ulrich (NSN - DE/Munich)
> Cc : dime@ietf.org
> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
> =20
> =20
> Sounds acceptable. Would the following then work for all:
> =20
> o clarify that once the overload report expires there is no
>   reason to remember anything about it
> o the sequence number would be similar to session-id.. based=20
>   on the NTP time + any vendor specific data to make it=20
>   "globally and eternally unique".
> =20
> - Jouni
> =20
> =20
> =20
> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Steve,
> =20
> sounds like an acceptable proposal which allows to come back to sync =
after OLR expiry.
> This requires however an update of clause 5.5.2 to clearly state
> Once the overload report expires there is no reason to remember =
anything about it and the next overload report received could, =
conceivably have any value.=20
> =20
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Thursday, February 06, 2014 4:50 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
> =20
> A couple of things -=20
> =20
> The requirement is that the sequence number increase monotonically =
over time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time =
stamp to set the sequence number for the first overload report sent =
after a reboot and then increment the sequence number value by one for =
each subsequent overload report sent.  This actually has better =
properties than an NTP time stamp as it would take much longer to roll =
over.  One could also create a global sequence number service that is =
not tied to time and have a Diameter server query that global sequence =
number server after each reboot.
> =20
> We also have a duration timer on overload reports.  This gives us one =
way to reset.  It should only be required to remember the sequence =
number of an active overload report.  Once the overload report expires =
there is no reason to remember anything about it and the next overload =
report received could, conceivably have any value.=20
> =20
> The requirement we need is similar to the session-id in the base =
Diameter specification.  The wording there is -- "The Session-Id MUST be =
globally and eternally unique".  We just need eternally as the spacial =
differentiation is based on the context of the message carrying the =
overload report.
> =20
> It would be perfectly valid for the DOIC draft to suggest the use of =
NTP timestamps to populate the sequence number but it should be worded =
in a similar fashion as the Diameter base RFC -- The Session-Id includes =
a mandatory portion and an implementation-defined portion; a recommended =
format for the implementation-defined portion is outlined below ..."
> =20
> Steve
> =20
> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> I cannot understand what is the problem with mandating timestamp.
> But I can see interoperability problems with the current definition:
> =20
> Assume the sender sends sequence numbers
> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
> but the receicer for any reason receives=20
> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20
> The receiver would accept
> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
> and then silently discards
> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
> with no way to come back to sync.
> =20
> Are we sure that this cannot happen?
> =20
> Mandating timestamp for sequence number generation at the sender and =
plausibility checking (i.e. received value must be between stored value =
and time of reception) for the receiver may not be the only way to solve =
the problem. But in the moment I don't see another way.
> =20
> Ulrich
> =20
> =20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben =
Campbell
> Sent: Wednesday, February 05, 2014 4:57 PM
> To: ext lionel.morand@orange.com
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
> =20
> My point is, we have an interop requirement that the sequence number =
always increases over time scope. We do not have the interop requirement =
that the sequence number be implemented as a time stamp. A time stamp is =
probably a good way to  meet the interop requirements, but it is not, in =
itself, an interop requirement.
> =20
> On Feb 5, 2014, at 9:53 AM,  =
 wrote:
> =20
> Not sure to understand: if there is a kind of "interop requirement", =
it is a case for a "MUST".
> We are not violating anything.
> =20
> Reporting and reacting nodes will just rely on the Diameter interfaces =
to know how to handle the received sequence-number. So any MUST on the =
format of the sequence-number is acceptable if it avoids interop issues.
> =20
> -----Message d'origine-----
> De : Ben Campbell [mailto:ben@nostrum.com]=20
> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
> =C0 : MORAND Lionel IMT/OLN
> Cc : Steve Donovan; dime@ietf.org
> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
> =20
> I concur with Steve on this one. Using a time stamp is a good way to =
meet the requirements, but it's not our job to normatively state an =
implementation. In fact, it violates an RFC 2119 "MUST" level =
requirement to do so. Section 6 of 2119 includes the following:
> =20
> "In particular, [normative requirements] MUST only be used where it is
>   actually required for interoperation or to limit behavior which has
>   potential for causing harm (e.g., limiting retransmisssions)  "
> =20
> The only appropriate reason to require a timestamp would be if we =
expected peers to interpret the field as a point in time. OTOH, it would =
be perfectly reasonable to state the actual interop requirements, then =
add a non-normative (probably indented) paragraph suggesting that a =
timestamp is a good way to do this.
> =20
> On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
> =20
> I think the out-of-sync failover described by Ulrich is a good use =
case to mandate a specific semantic.
> =20
> Is there any specific NOT to mandate the use of NTP timestamps if it =
is a simple way to solve the possible issues and please everyone?
> =20
> Lionel
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
> =C0 : dime@ietf.org
> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
> =20
> How the sequence number is implemented is an implementation decision.  =
There is no reason to mandate that is be an NTP timestamp.  That should =
be included only as one way of addressing the requirement.
> =20
> Steve
> =20
> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
> I also agree.
> =20
> Regards,
> Nirav.
> =20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of =
lionel.morand@orange.com
> Sent: Tuesday, February 04, 2014 11:50 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
> =20
> The existing wording seems actually fuzzy.
> If it is "like an NTP timestamp", be proud and say it loud!
> =20
> In summary: ok with the proposal if it clarifies this handling of this =
sequence-number.
> =20
> Lionel
> =20
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
> =20
> #32: Sequence-Number Time-Stamp values within OC-OLR
> =20
> The -01 draft says in clause 4.4:
>    =46rom the functionality point of view, the OC-Sequence-Number AVP =
MUST
>    be used as a non-volatile increasing counter between two overload
>    control endpoints (neglecting the fact that the contents of the AVP
>    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
>    required to be unique between two overload control endpoints.
>    Sequence numbers are treated in uni-directional manner, i.e. two
>    sequence numbers on each direction between two endpoints are not
>    related or correlated.
> =20
>    When generating sequence numbers, the new sequence number MUST be
>    greater than any sequence number previously seen between two
>    endpoints within a time window that tolerates the wraparound of the
>    NTP timestamp (i.e. approximately 68 years).
> =20
> =20
> With this mechanism it is difficult to get back to sync once you are =
out  of sync (for whatever reason).
> It is proposed to mandate that the Sequence Number is a real 64-bit =
NTP  timestamp (RFC5905) indicating the point in time when the OLR was =
created,  and to mandate that  OLRs with a time stamp higher than time =
of reception  must be ignored by the reacting node.
> =20
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> _______________________________________________
> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Tue Feb 11 15:11:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D821A07C5 for ; Tue, 11 Feb 2014 15:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7lxg5_-3WZB for ; Tue, 11 Feb 2014 15:11:45 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E1B3B1A07CA for ; Tue, 11 Feb 2014 15:11:44 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id pv20so6593981lab.30 for ; Tue, 11 Feb 2014 15:11:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h5KTU8PeCjEIxnMx+Pg5LZwXgqth/8gvpDdxGTauvVQ=; b=rZ7aHtmDYSWjuIglShVaVTIacfrk/kT3q0GpZRGYN9kncrVoAb4h0tuFFn0qknipP/ cy1kr1eeqOjb4kVgfEMptmFiA3Y6gYMOx4mOuf9sj+EpKhknG9SaeUMB2q0KV9FDFoxA 0HYOSSaVqXVLCpr5Jjz2r7xm1fSv0DDMb3ylk/Zj0vXf8+5Yj06yih775hz/LMHeJrqa fAjxWbDKDQ/HZzmPRAMXHb+5GA/7WB4/Cka+7kSVNDE1g1j7lzTT6R8od2yzR2IAogKF n8ZdRkzGLnvXVfgkzcO+bTq3ep7KDyv4SoIcZ6wl3cOKKlspU1tGDjF1yYutqNdM/qXm /Pkg==
X-Received: by 10.152.30.68 with SMTP id q4mr3658011lah.44.1392160303602; Tue, 11 Feb 2014 15:11:43 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:4530:967a:5206:7997? ([2001:1bc8:101:f101:4530:967a:5206:7997]) by mx.google.com with ESMTPSA id g8sm30112628lae.1.2014.02.11.15.11.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 15:11:43 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Wed, 12 Feb 2014 01:11:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32153_1391613236_52F25534_32153_19305_1_6B7134B31289DC4FAF731D844122B36E487240@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B2236@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B25AF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097723D7@ESESSMB101.ericsson.se>  <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup> 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Feb 2014 23:11:49 -0000

So are we converging to an agreement here? I could join the
camp of U/MC/N/L/J..

- Jouni

On Feb 11, 2014, at 11:52 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:

> Dear all
>=20
> I come back a bit late on this long debate to confirm my position that =
I share with  Ulrich MCruz Nirav and I think now Lionel and that I again =
summarize here in these two statements :=20
> - Host OLR based control applies to requests where Destination Host is =
known
> - Realm OLR based control applies to requests where Destination Host =
is not known (only the Destination realm).
>=20
>> =46rom History, we have started by defining the Host report so to =
control the traffic towards each server,(our main goal), but we observed =
a difficulty when the reacting node does not know  the host to which a  =
request is sent and for this  we introduced the realm report. Annex B1 =
example in the draft is the use case well illustrating  this approach =
and  which corresponds to the above statements.
>=20
> Another point which was mentioned, is, for  the reacting node, to keep =
the throttling based on realm report independent of the throttling based =
on the host report, this is naturally achieved with the two above =
statements as we distinguish requests having a destination host from =
those having not. But if we can apply both reports to the same request, =
then we need additional rules eg  which report prevails; in the =
discussion there were also divergence on this point, but we can imagine =
other rules eg the report that has the highest reduction value prevails, =
why not in some cases, so a trend to overcomplexify.=20
>=20
> For me the two above statements avoid overlapping between the two =
reports  and are simple to apply, so I keep my preference for these two =
statements.
>=20
> Best regards
>=20
> JJacques  =20
>=20
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de =
lionel.morand@orange.com
> Envoy=E9 : mardi 11 f=E9vrier 2014 16:31
> =C0 : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org
> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>=20
> So now I understand Ulrich, Maria Cruz and JJ comments.
>=20
> "My" proposal would force the servers in the realm to always send an =
OLR just to say "I'm not overloaded" i.e. with the value 0. That is =
anyway a possibility.
> But if we want to avoid that, Realm type must only apply to message =
without destination host.
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de =
lionel.morand@orange.com Envoy=E9 : mardi 11 f=E9vrier 2014 16:25 =C0 : =
Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of =
OC-Report-Type AVP
>=20
> Hi Maria Cruz,
>=20
> Actually I've missed this point. Sorry.
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan =
Envoy=E9 : mardi 11 f=E9vrier 2014 16:08 =C0 : dime@ietf.org Objet : Re: =
[Dime] [dime] #34: Semantics of OC-Report-Type AVP
>=20
>=20
> On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
>> Lionel,
>>=20
>> About first case:
>>=20
>> - If the reacting node has received an indication only for Realm=20
>> traffic Reduction, apply Realm reduction is for any message, with=20
>> Destination-Realm and with/without Destination-Host
>>=20
>> I do not agree on this, since if Destination Host is used, there is =
no reason to throttle messages if this Host has not provided any OLR.
> SRD> There is if the reacting node has received an overload report
> requesting a traffic reduction on the realm.  The server/host does not =
have visibility of the entire realm.=20
>> This is in line with the example used from the beginning:
>> ---------
>> ..we have two servers in a realm, S1 is not overloaded at all, S2 is =
50% overloaded, and the aggregated realm overload is 25%. Why should a =
client do a 25% throttling when sending host type requests to the not at =
all overloaded S1?
>> What is wrong with letting the client
>> -not throttle host-type requests to S1, -throttle host type request =
to=20
>> S2 with 50% and -throttle realm type requests wit 25%?
>> ------------
>>=20
>> And I think this is what JJ commented:
>> [JJ] there may be a misunderstanding somewhere, so good to try to =
clarify; coming back to Ulrich example, Host S1 is not overloaded, so =
reacting node has not received Host reduction OLR for S1. But as there  =
is a realm reduction, reacting node will reduce traffic with destination =
Host S1.
>>=20
>> In my opinion, reducing traffic to S1 is wrong.
> SRD> It isn't reducing traffic to S1.  It is reducing traffic to the =
realm.
>>=20
>> Regards
>> /MCruz
>>=20
>> -----Original Message-----
>> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
>> Sent: martes, 11 de febrero de 2014 11:57
>> To: Maria Cruz Bartolome; dime@ietf.org
>> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20
>> Hi maria-cruz,
>>=20
>> JJ agreed on the following approach:
>>=20
>> - If the reacting node has received an indication only for Realm =
traffic Reduction, apply Realm reduction is for any message, with =
Destination-Realm and with/without Destination-Host [JJ] there may be a =
misunderstanding somewhere, so good to try to clarify; coming back to =
Ulrich example, Host S1 is not overloaded, so reacting node has not =
received Host reduction OLR for S1. But as there  is a realm reduction, =
reacting node will reduce traffic with destination Host S1.
>>=20
>> - If the reacting node has received an indication only for host =
traffic reduction, apply host reduction for messages containing a =
Destination-Host. No reduction for messages with only a =
Destination-Realm.
>> [JJ] OK
>>=20
>> - If the reacting node has received both an indication for host =
traffic and for realm traffic reduction, only the realm reduction will =
apply for messages with only the Destination-Realm AVP and only the host =
reduction will apply for messages with the Destination-Host AVP (and the =
Destination-Realm AVP).
>> [JJ] OK, Host reduction prevails
>>=20
>> In other words, as said earlier, the Host reduction prevails over =
realm reduction when the overloaded host is inside an overloaded realm =
and the reacting has received info about both type of overload.
>>=20
>> What is the issue with this approach?
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20
>> Bartolome Envoy=E9 : mardi 11 f=E9vrier 2014 11:49 =C0 : =
dime@ietf.org Objet=20
>> : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20
>> Hello,
>> I agree with JJ:
>>=20
>> - If the reacting node has received an indication only for Realm =
traffic Reduction, apply Realm reduction is for any message, with =
Destination-Realm and with/without Destination-Host [JJ] there may be a =
misunderstanding somewhere, so good to try to clarify; coming back to =
Ulrich example, Host S1 is not overloaded, so reacting node has not =
received Host reduction OLR for S1. But as there  is a realm reduction, =
reacting node will reduce traffic with destination Host S1.
>>=20
>> [MCruz] And... if the request is sent to a Destination-Host, if there =
is any applicable OLR, it will be received immediately in the answer, =
and will be applicable from next request on.
>> Simple and robust in my opinion. Then, we do not need to evaluate =
whether we have OLR for Realm and/or Host, and even check their validity =
& applicability.
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN,=20
>> JEAN-JACQUES (JEAN-JACQUES)
>> Sent: lunes, 10 de febrero de 2014 15:00
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20
>> Hi Lionel
>>=20
>> Please see in line
>>=20
>> -----Message d'origine-----
>> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] =
Envoy=E9=20
>> : lundi 10 f=E9vrier 2014 14:25 =C0 : TROTTIN, JEAN-JACQUES=20
>> (JEAN-JACQUES); dime@ietf.org Objet : RE: [Dime] [dime] #34: =
Semantics=20
>> of OC-Report-Type AVP
>>=20
>> I disagree and my proposal was somehow misunderstood.
>>=20
>> I don't see the issue to have the following sequence:
>>=20
>> - If the reacting node has received an indication only for Realm =
traffic Reduction, apply Realm reduction is for any message, with =
Destination-Realm and with/without Destination-Host [JJ] there may be a =
misunderstanding somewhere, so good to try to clarify; coming back to =
Ulrich example, Host S1 is not overloaded, so reacting node has not =
received Host reduction OLR for S1. But as there  is a realm reduction, =
reacting node will reduce traffic with destination Host S1.
>>=20
>> - If the reacting node has received an indication only for host =
traffic reduction, apply host reduction for messages containing a =
Destination-Host. No reduction for messages with only a =
Destination-Realm.
>> [JJ] OK
>>=20
>> - If the reacting node has received both an indication for host =
traffic and for realm traffic reduction, only the realm reduction will =
apply for messages with only the Destination-Realm AVP and only the host =
reduction will apply for messages with the Destination-Host AVP (and the =
Destination-Realm AVP).
>> [JJ] OK, Host reduction prevails
>>=20
>> In other words, as said earlier, the Host reduction prevails over =
realm reduction when the overloaded host is inside an overloaded realm =
and the reacting has received info about both type of overload.
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN,=20
>> JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : lundi 10 f=E9vrier 2014 13:56 =
=C0 :=20
>> dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of=20
>> OC-Report-Type AVP
>>=20
>> Dear  all
>>=20
>> I share Ulrich and MCruz views,
>> - Host OLR based control applies to requests where Destination Host =
is=20
>> known
>> - Realm OLR based control applies to requests where Destination Host =
is not known (only the Destination realm).
>>=20
>> I think it is simple, otherwise as MCruz indicated it complicates; =
e.g about the Ulrich's example where the Host S1 is not overloaded but =
the realm is overloaded. the client will not receive Host OLR reports =
from host S1 (so no explicit traffic reduction requested by S1), but =
according to Lionel comment, I understand  client will have to throttle =
the requests sent to S1 according to realm OLR, so how to avoid this.
>>=20
>> JJacques
>>=20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20
>> Bartolome Envoy=E9 : vendredi 7 f=E9vrier 2014 17:15 =C0 : =
dime@ietf.org=20
>> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20
>> Dear all,
>>=20
>> I am in favor of the proposal made by Ulrich in the sequence diagram =
he provided.
>> ----
>> As a summary:
>> Consequently the reacting node will receive realm type OLRs from the =
agent and host type OLRs from the servers.
>> The received realm type OLR will be relevant for the reacting node =
when sending/throttling realm type requests; the received host type OLR =
will be relevant for the reacting node       when sending/throttling =
host type requests.
>> -----
>>=20
>> It may occur though, that a Client has only received Realm type OLR, =
and then it has to send a request to one specific host, then the Client =
will not apply any restriction, but as soon as the response is received =
back, Client will update Host type OLR.  Same will apply when only Host =
type OLR has been received by Client.
>> The alternative will be to always send back from an Agent both Host =
OLR plus Realm OLR, but I do not think this is necessary and may =
complicate the solution.
>>=20
>> Best regards
>> /MCruz
>>=20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20=

>> (NSN - DE/Munich)
>> Sent: viernes, 07 de febrero de 2014 14:13
>> To: ext Jouni Korhonen
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
>> Sent: Friday, February 07, 2014 11:21 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>=20
>>=20
>> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>=20
>>> I better like Lionel's approach, but even that is not ok in the =
unlikely extreme case where we have two servers in a realm, S1 is not =
overloaded at all, S2 is 50% overloaded, and the aggregated realm =
overload is 25%. Why should a client do a 25% throttling when sending =
host type requests to the not at all overloaded S1?
>>> What is wrong with letting the client -not throttle host-type=20
>>> requests to S1, -throttle host type request to
>>> S2 with 50% and -throttle realm type requests wit 25%?
>> Isn't this what Lionel said below?
>>  no it is not
>> I am OK with Lionel's
>> "wording" here.
>>=20
>> - Jouni
>>=20
>>>=20
>>>=20
>>>=20
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext=20
>>> lionel.morand@orange.com
>>> Sent: Wednesday, February 05, 2014 4:14 PM
>>> To: Steve Donovan; dime@ietf.org
>>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>=20
>>> I tend to agree except that I would reverse the logic as for the =
routing principles: the Destination-host takes precedence when present =
over Destination-Realm. So the realm abatement is applied in any case =
except if there is an explicit report for the destination-host.
>>>=20
>>> Lioenl
>>>=20
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20=

>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:56 =C0 : dime@ietf.org Objet =
: Re:
>>> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>=20
>>> It makes more sense to me for a realm report to apply to all =
requests targeted for that realm, independent the type of request.  This =
implies that it would apply to requests that also have a =
Destination-Host specified.
>>>=20
>>> If this is the definition of a realm report then we need to specify =
the interaction between realm reports and host reports.
>>>=20
>>> I propose that throttling would occur on the realm first and the =
host second.  If a message targetted for the host is throttled as a =
result of realm overload then that throttled message would count as part =
of the reduction needed to address the host overload.  Messages to the =
host that survive realm abatement would then be candidates for host =
overload.
>>>=20
>>> Steve
>>>=20
>>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
>>> The case "Realm" as described below raises another question: is it =
prohibited for a realm to only rely on a global overload report for the =
whole realm, whatever the nodes inside this realm?
>>> If not, only OLR with the report type "realm" would be received by =
the reacting node. And the reduction indicated in the OLR will apply =
always for the realm, whatever the presence of Destination-host AVP in =
the request... except if an explicit report with the type "Host" as been =
received for this destination-host.
>>>=20
>>> Does it make sense?
>>>=20
>>> Lionel
>>>=20
>>> -----Message d'origine-----
>>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:55
>>> =C0 : MORAND Lionel IMT/OLN
>>> Cc : dime@ietf.org
>>> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>>>=20
>>> #34: Semantics of OC-Report-Type AVP
>>>=20
>>> Text in clause 4.6  does not fully explain to which requests=20
>>> overload treatment of a given report type applies.
>>> Proposal:
>>>=20
>>>    0  A host report.  The overload treatment should apply to =
requests
>>>       for which all of the following conditions are true:
>>>       a) The Destination-Host AVP is present in the request and its =
value
>>>          matches the value of the Origin-Host AVP of the received =
message
>>>          that contained the OC-OLR AVP.
>>>       b) The value of the Destination-Realm AVP in the request =
matches the
>>>          value of the Origin-Realm AVP of the received message
>>>          that contained the OC-OLR AVP.
>>>       c) The value of the Application-ID in the Diameter Header of =
the
>>>          request matches the value of the Application-ID of the =
Diameter
>>>          Header of the received message that contained the OC-OLR =
AVP.
>>>=20
>>>=20
>>>=20
>>>    1  A realm report.  The overload treatment should apply to
>>>       requests for which all of the following conditions are true:
>>>       a) The Destination-Host AVP is absent in the request.
>>>       b) The value of the Destination-Realm AVP in the request =
matches the
>>>          value of the Origin-Realm AVP of the received message
>>>          that contained the OC-OLR AVP.
>>>       c) The value of the Application-ID in the Diameter Header of =
the
>>>          request matches the value of the Application-ID of the =
Diameter
>>>          Header of the received message that contained the OC-OLR =
AVP.
>>>=20
>>>=20
>>> =
_____________________________________________________________________
>>> _ ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations=20=

>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,=20
>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20=

>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or=20
>>> 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.
>>> _______________________________________________
>>> 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
>>=20
>> =
______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> =
______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From trac+dime@trac.tools.ietf.org  Tue Feb 11 23:43:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A761A087B for ; Tue, 11 Feb 2014 23:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSiCDSpl9_73 for ; Tue, 11 Feb 2014 23:43:27 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F11C21A087A for ; Tue, 11 Feb 2014 23:43:26 -0800 (PST)
Received: from localhost ([127.0.0.1]:46943 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WDUTT-0003zW-Lc; Wed, 12 Feb 2014 08:43:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Wed, 12 Feb 2014 07:43:15 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/50
Message-ID: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
X-Trac-Ticket-ID: 50
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #50: OC-OLR AVP implicit info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Feb 2014 07:43:31 -0000

#50: OC-OLR AVP implicit info

 Now (chapter 4.3):

    The OC-OLR AVP does not contain explicit information to which
    application it applies to and who inserted the AVP or whom the
    specific OC-OLR AVP concerns to. Both these information is
    implicitly learned from the encapsulating Diameter message/command.
    The application the OC-OLR AVP applies to is the same as the
    Application-Id found in the Diameter message header.  The identity
    the OC-OLR AVP concerns is determined from the Origin-Host AVP found
    from the encapsulating Diameter command.


 My understanding is that “who inserted the AVP†cannot always be learned
 from the encapsulating Diameter message, since “origin-host†may not
 always contain the host that inserted the OLR.
 A part from that, “whom the specific OC-OLR AVP concerns toâ€, could be a
 bit misleading… “whom†may be host, realm, or any other future ReportType,
 or even any other “narrowed scope†within the OLR. Last sentence is
 affected by this ambiguity as well.


 New proposal (related to new text proposed chapter 4.6, see to Issue #34):

 The OC-OLR AVP does not contain explicitly all information needed by the
 reacting node in order to decide whether a subsequent request must undergo
 a throttling process with the received reduction percentage.
 The following information is implicitly known from the received
 application answer and OC-OLR AVP, that is used by reacting node to
 identify subsequent requests that are requested to be throttled:

 a)The Application-ID is the value of the Application-ID of the Diameter
   Header of the received message that contained the OC-OLR AVP.

 b)The Destination-Realm AVP (if required, see 4.6) is the value of the
 Origin-Host AVP of the received message that contained the OC-OLR AVP.

 c)The Destination-Host AVP (if required, see 4.6) is the value of the
 Origin-Host AVP of the received message that contained the OC-OLR AVP.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-docdt-dime-
  maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-docdt-dime-ovli    |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From trac+dime@trac.tools.ietf.org  Tue Feb 11 23:51:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335611A0878 for ; Tue, 11 Feb 2014 23:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsVVpfV7pbtQ for ; Tue, 11 Feb 2014 23:51:43 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 77D5E1A0867 for ; Tue, 11 Feb 2014 23:51:43 -0800 (PST)
Received: from localhost ([127.0.0.1]:47411 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WDUbd-0006Ym-Tl; Wed, 12 Feb 2014 08:51:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Wed, 12 Feb 2014 07:51:41 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/51
Message-ID: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 51
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: dime@ietf.org
Subject: [Dime] [dime] #51: OC-Supported-Features in requests
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Feb 2014 07:51:45 -0000

#51: OC-Supported-Features in requests

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter
 message a DOIC
 supporting node sends (and intends to use for DOIC purposes).

 Why is "should" used?

 Proposal: replace SHOULD by MUST

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
 Severity:  Active WG Document                 |    Version:  1.0
                                               |   Keywords:
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From trac+dime@trac.tools.ietf.org  Wed Feb 12 00:13:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DE91A08B6 for ; Wed, 12 Feb 2014 00:13:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00g7p5n3-PLY for ; Wed, 12 Feb 2014 00:13:16 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 306A71A08B5 for ; Wed, 12 Feb 2014 00:13:16 -0800 (PST)
Received: from localhost ([127.0.0.1]:48275 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WDUwU-00072r-Iz; Wed, 12 Feb 2014 09:13:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Wed, 12 Feb 2014 08:13:14 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/52
Message-ID: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 52
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: dime@ietf.org
Subject: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Feb 2014 08:13:18 -0000

#52: Throttling not needed to be based on previous history

 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.

 Proposal:
 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
 and describes the percentage of the traffic that the sender is
 requested to reduce, compared to what it otherwise would send.


 The intention is to avoid that anyone may interpret reacting node is
 required to consider history of sent information when throttling.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
 Severity:  Active WG Document                 |    Version:  1.0
                                               |   Keywords:
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From ulrich.wiehe@nsn.com  Wed Feb 12 00:14:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B5D1A08B3 for ; Wed, 12 Feb 2014 00:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaZ1WjSZbIBS for ; Wed, 12 Feb 2014 00:14:18 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCDB1A08B6 for ; Wed, 12 Feb 2014 00:14:17 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1C8EE6c009609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 09:14:15 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1C8EEvw030606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 09:14:14 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 09:14:14 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 09:14:14 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYA==
Date: Wed, 12 Feb 2014 08:14:13 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 5312
X-purgate-ID: 151667::1392192855-000025D0-7513956A/0-0/0-0
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 08:14:22 -0000

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.
2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?=20

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement  in our 3GPP TR:

6.3.3	Implicit Overload Indication
6.3.3.1	Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
-	DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
-	Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> 1) I want the reacting node to be able to learn if a (potentially)=20
> reporting node supports DOIC, even when that node is not in overload.=20
> I don't want to specify any particular behavior for that knowledge,=20
> but I suspect implementations may want to treat DOIC compliant servers=20
> in some way differently than they do non-DOIC servers. For example, I=20
> might have a configured rate limit for non-DOIC peers, but use a=20
> higher (or no) limit for peers that are known to support DOIC (and can=20
> thus speak for themselves.) sounds like a new requirement;=20
> where does it come from? I would have thought that there is no need to=20
> distinguish between
> a) DOIC not supported and therefore no traffic reduction requested,=20
> and
> b) DOIC supported, but not in overload and therefore no traffic=20
> reduction requested
>=20

At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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 maria.cruz.bartolome@ericsson.com  Wed Feb 12 00:43:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30F61A08C9 for ; Wed, 12 Feb 2014 00:43:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n1SCr7xbJ4Z for ; Wed, 12 Feb 2014 00:43:53 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id DDB271A08CA for ; Wed, 12 Feb 2014 00:43:51 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-cb-52fb3446fcca
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 1F.A0.04853.6443BF25; Wed, 12 Feb 2014 09:43:50 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 09:43:50 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpqukxIAgAADxQCAAAUcgIAAYRYAgAAcxICAAPpJ0IABO9pA
Date: Wed, 12 Feb 2014 08:43:49 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774086ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja6bye8gg1ebVSzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv9zl1gL7s1krOh+spWtgXFSG2MXIweHhICJxLnjFV2MnECm mMSFe+vZuhi5OIQETjBKtO+/wQrhLGGUuPKukxmkik3ATuLS6RdMIM0iAhoSK05kgoSFBbwl fny4zARiiwj4SPQ2HmGDsKMk1hxfzAhiswioSlz485gFxOYV8JV4ueMHE8T8Q8wS296sA5vP KeAn8WnBDLBmRqCLvp9aAzaUWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4StKLHzbDszRH2+ xIHpM9khlglKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCy r2KULE4tLs5NNzLQy03PLdFLLcpMLi7Oz9MrTt3ECIyng1t+G+1gPLnH/hCjNAeLkjjvddaa ICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M/rJHpTQ94q05Qx1YdJ4xLN/u9X1K2uVlE+vM /kt//X6k6LRnTu35ww031pal6SfFrdt62Pp2wvt0/uh7Br8btOadNahddFn+5LclGXdXWIox RJ178SBo417v9KrDjCHisVPCTufvWMKfm+Jmpf3o2bWP10QPxx16p3ji0Y8TdwKuyuqZTJI4 rcRSnJFoqMVcVJwIAAYJPMt1AgAA
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 08:43:56 -0000

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

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:

Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:

Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:


Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:


On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:


On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:

#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


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











Ben, all,


 <=
/p>

This comment affects as w=
ell clause 5.5.2:


 <=
/p>

  =
; value =3D=3D 0


 =



  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 


This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:






Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:






Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:








Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:








On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:








On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:






#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_087A34937E64E74E848732CFF8354B9209774086ESESSMB101erics_--


From ulrich.wiehe@nsn.com  Wed Feb 12 00:47:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202901A08CA for ; Wed, 12 Feb 2014 00:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdN_AQEnTKRP for ; Wed, 12 Feb 2014 00:47:05 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E9E7E1A08C5 for ; Wed, 12 Feb 2014 00:47:04 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1C8l24n020832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 09:47:02 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1C8l24b027836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 09:47:02 +0100
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 09:47:01 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 09:47:01 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #49: capabilities announcement mechanism needs to	be rethought
Thread-Index: AQHPJ25Iid4Ru3kOOUuYJlIK6HwZcJqxSf3w
Date: Wed, 12 Feb 2014 08:47:00 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2ECF@DEMUMBX014.nsn-intra.net>
References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> <52F90653.6040104@usdonovans.com> <4208F877-455F-4A28-BB15-FA3C5B3A8795@gmail.com> <52F9605C.7000504@usdonovans.com> <37D3D981-FBA0-4DF9-B381-34ED048F8BFD@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2BB2@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B92097731D8@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097731D8@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 7501
X-purgate-ID: 151667::1392194822-000025D0-15CDDB38/0-0/0-0
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs	to	be rethought
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 08:47:08 -0000

Hello,

not sure I understand the proposal.

Isn't it so that session states are maintained by client and server whereas=
 capabilities are exchanged between reacting node and reporting node?
In the following example configuration

                                         +--------+
+----------------+                       | A1     |              +---------=
+
| client         |-----------------------|        |--------------| Server  =
|
| not supporting |                       +--------+              |         =
|  =20
| DOIC           |                       +--------+              |         =
|    =20
|                |-----------------------| A2     |--------------|         =
|=20
+----------------+                       |        |              +---------=
+
                                         +--------+

A first request within a session may be sent from Client via A1 to the serv=
er; a second request within the same session may take the path via A2. A1 a=
nd A2 may support different capabilities.
The proposed requirement not to allow a capability change within a session =
would not be met by such example configurations.

I'm ok with Ben's proposal=20

 >.....to mandate that the capabilities are stateless,
 >that is, must be included in every request, and any OLR in a response mus=
t
 >match the OC-Supported-Features from the corresponding request.

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 10:14 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs t=
o be rethought

Hello all,

I would like to come back to the initial comments by Ben on this subject:

>The capabilities announcement mechanism needs serious rethought.
 >Specifically, the lifetime of the state associated with a capabilities
 >announcement is unclear. It does not make sense to tie that lifetime to
 >Diameter session lifetimes, unless we expect to have different capability
 >sets for different sessions. (and it doesn't help at all for non-session
 >applications or pseudo-sessions.)

[MCruz] I agree we do not need to tie a capability set to a session, but on=
 the other hand, what could be the reason to modify the capability set with=
in a session?
I think this was the original reason why it is considered that the capabili=
ty just needs to be announced once per session. In fact, I think this is a =
valid solution.

> I think we either need to mandate that the capabilities are stateless,
 >that is, must be included in every request, and any OLR in a response mus=
t
 >match the OC-Supported-Features from the corresponding request.
 >Otherwise, we need a way to activate and deactivate the set associated
 >with a capabilities set.

[MCruz] We could allow to define the capability set just once per session (=
obviously for session-based applications, for non-session based keeps being=
 in each message).
We can define that within a session it is not allowed to modify the capabil=
ity set.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: martes, 11 de febrero de 2014 18:56
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs t=
o be rethought


Fine with me. That just needs to be just stated more clearly.
Now there are too many SHOULDs and stuff.

- JOuni

On Feb 11, 2014, at 2:32 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> I agree that OC-OLR AVPs are allowed only in answer messages.
>=20
> But I do not agree with
>>> if there are other DOIC AVPs in the request, then the absence of the=20
>>> OC-Supported-Features is interpreted as support for the default=20
>>> abatement algorithm.
>=20
> "other DOIC AVPs" would be AVPs defined for future extensions. A reportin=
g node that does not support any future extension would simply ignore "othe=
r DOIC AVPs" and would interprete the absence of OC-Supported-Features as "=
DOIC not supported by any downstream node".
>=20
> Things are not symmetric.
> Ulrich
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20
> Korhonen
> Sent: Tuesday, February 11, 2014 7:45 AM
> To: Steve Donovan
> Cc: ben@nostrum.com; dime@ietf.org;=20
> draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism=20
> needs to be rethought
>=20
>=20
> Your assumption is correct. "Other DOIC AVPs" is a future thing.
> Currently we have no other DOIC AVPs for requests. It is just I asking=20
> the same semantics for the OC-Supported-Features for both directions.
>=20
> - Jouni
>=20
>=20
> On Feb 11, 2014, at 1:27 AM, Steve Donovan  wro=
te:
>=20
>> It has been my assumption that the OC-OLR AVP would only be allowed in a=
nswer messages.  Is this the consensus?
>>=20
>> Steve
>>=20
>> On 2/10/14 4:27 PM, Jouni Korhonen wrote:
>>> Basically yes.. however, if there are other DOIC AVPs in the=20
>>> request, then the absence of the OC-Supported-Features is=20
>>> interpreted as support for the default abatement algorithm.
>>> We should have that behaviour in both requests and answers.
>>>=20
>>> - Jouni
>>>=20
>>> On Feb 10, 2014, at 7:03 PM, Steve Donovan=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> My sense from recent discussions is that the lifetime of the OC-Suppor=
ted-Feature AVP is assumed to be one transaction.  This means that the AVP =
must be included in all request messages sent by a reacting node.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>>>=20
>>>>> #49: capabilities announcement mechanism needs to be rethought
>>>>>=20
>>>>> The capabilities announcement mechanism needs serious rethought.
>>>>> Specifically, the lifetime of the state associated with a=20
>>>>> capabilities announcement is unclear. It does not make sense to=20
>>>>> tie that lifetime to Diameter session lifetimes, unless we expect=20
>>>>> to have different capability sets for different sessions. (and it=20
>>>>> doesn't help at all for non-session applications or=20
>>>>> pseudo-sessions.)
>>>>>=20
>>>>> I think we either need to mandate that the capabilities are=20
>>>>> stateless, that is, must be included in every request, and any OLR=20
>>>>> in a response must match the OC-Supported-Features from the correspon=
ding request.
>>>>> Otherwise, we need a way to activate and deactivate the set=20
>>>>> associated with a capabilities set.
>>>>>=20
>>>>> (This is a side effect of allowing DOIC to cross non-supporting=20
>>>>> agents. If we didn't allow that, we could make DOIC support and=20
>>>>> capabilites negotiation happen as part of the CAR exchange. )
>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> 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 maria.cruz.bartolome@ericsson.com  Wed Feb 12 00:56:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC3B1A08C1 for ; Wed, 12 Feb 2014 00:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-kl613x4PJE for ; Wed, 12 Feb 2014 00:56:25 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3E1A08C0 for ; Wed, 12 Feb 2014 00:56:24 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-6f-52fb3736986d
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BA.3E.23809.6373BF25; Wed, 12 Feb 2014 09:56:23 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 09:56:22 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [dime] #52: Throttling not needed to be based on previous history
Thread-Index: AQHPJ8pHWh6U3x1NsUGCEW0ghWu/OpqxT/wg
Date: Wed, 12 Feb 2014 08:56:22 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se>
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
In-Reply-To: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvja65+e8gg31PmC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtXpJ9gLzilVtDZMZmlgvKPYxcjBISFgIjHjlUwXIyeQKSZx 4d56ti5GLg4hgUOMEt9m7WKFcJYwSvzdMo0VpIpNwE7i0ukXTCDNIgLKEqd/OYCEhQUCJO60 bmQHsUUEAiUWnzvIDGEbSUx6OoMVpJxFQFXi9pECkDCvgK/EyhuLmUBsIQE3iVuLtrCB2JwC 7hKnps5nAbEZge75fmoNWA2zgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WCFtRYufZdmaQVcwC mhLrd+lDtCpKTOl+yA6xVlDi5MwnLBMYRWchmToLoWMWko5ZSDoWMLKsYmTPTczMSS832sQI DPeDW36r7mC8c07kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgX/Nrx XaThzI91mh/vvTxqHKjerJ/V56g3vyO07fDnXn/W4znVIrlS1WYnGPVDZh8PzyqzLvFYPotV LEHnRk7/u9KV7N6HO+dflFFPs1FQzZW93XIv6M+FA33eMko39z+IEg3a8Mtn/hnOaYal0nXX WFkNNYRLd0yc1X4gZflLhx/Tbxo0syuxFGckGmoxFxUnAgDLPqONRQIAAA==
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 08:56:27 -0000

U2FtZSBjb21tZW50IGFsc28gYXBwbGllcyB0byBmb2xsb3dpbmcgcGFyYWdyYXBoIGluIDUuNS4y
DQoNCk5vdzoNCiAgIDAgPCB2YWx1ZSA8IDEwMA0KDQogICAgICBJbmRpY2F0ZXMgdGhhdCB0aGUg
cmVwb3J0aW5nIG5vZGUgdXJnZXMgdGhlIHJlYWN0aW5nIG5vZGUgdG8NCiAgICAgIHJlZHVjZSBp
dHMgdHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2UuICBGb3IgZXhhbXBsZSBpZiB0aGUNCiAg
ICAgIHJlYWN0aW5nIG5vZGUgaGFzIGJlZW4gc2VuZGluZyAxMDAgcGFja2V0cyBwZXIgc2Vjb25k
IHRvIHRoZQ0KICAgICAgcmVwb3J0aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRpb24gb2YgT0MtUmVk
dWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUNCiAgICAgIG9mIDEwIHdvdWxkIG1lYW4gdGhhdCBmcm9t
IG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIG9ubHkgc2VuZA0KICAgICAgOTAgcGFja2V0
cyBwZXIgc2Vjb25kLiAgSG93IHRoZSByZWFjdGluZyBub2RlIGFjaGlldmVzIHRoZSAidHJ1ZQ0K
ICAgICAgcmVkdWN0aW9uIiB0cmFuc2FjdGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0
IG1lc3NhZ2VzIGlzIHVwDQogICAgICB0byB0aGUgaW1wbGVtZW50YXRpb24uICBUaGUgcmVhY3Rp
bmcgbm9kZSBNQVkgc2ltcGx5IGRyb3AgZXZlcnkNCiAgICAgIDEwdGggcGFja2V0IGZyb20gaXRz
IG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9uDQogICAgICBsb2dp
YyB0cnkgdG8gcmVjb3ZlciBmcm9tIGl0LjAgPCB2YWx1ZSA8IDEwMA0KDQpQcm9wb3NhbDoNCklu
ZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9kZSB0
bw0KcmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2VudGFnZS4gRm9yIGV4YW1wbGUg
aWYgdGhlDQpyZWFjdGluZyBub2RlIHdvdWxkIHNlbmQgMTAwIHBhY2tldHMgdG8gdGhlCQkJCTwt
LS0NCnJlcG9ydGluZyBub2RlLCB0aGVuIGEgcmVjZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJj
ZW50YWdlIHZhbHVlDQpvZiAxMCB3b3VsZCBtZWFuIHRoYXQgZnJvbSBub3cgb24gdGhlIHJlYWN0
aW5nIG5vZGUgTVVTVCBvbmx5IHNlbmQNCjkwIHBhY2tldHMgcGVyIHNlY29uZC4gSG93IHRoZSBy
ZWFjdGluZyBub2RlIGFjaGlldmVzIHRoZSAidHJ1ZQ0KcmVkdWN0aW9uIiB0cmFuc2FjdGlvbnMg
bGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0IG1lc3NhZ2VzIGlzIHVwDQp0byB0aGUgaW1wbGVt
ZW50YXRpb24uIFRoZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeQ0KMTB0aCBw
YWNrZXQgZnJvbSBpdHMgb3V0cHV0IHF1ZXVlIGFuZCBsZXQgdGhlIGdlbmVyaWMgYXBwbGljYXRp
b24NCmxvZ2ljIHRyeSB0byByZWNvdmVyIGZyb20gaXQuDQoNCg0KV2Ugc2hvdWxkIG5vdCBzcGVj
aWZ5IGEgcmF0ZXMgZm9yIHRoZSBzaW1wbGUgbG9zcyBhbGdvcml0aG0uIEl04oCZcyB1cCB0byB0
aGUgaW1wbGVtZW50YXRpb24gaG93IHRvIHJlZHVjZSwgYnV0IG5vIHRpbWUgdW5pdCBoYXMgdG8g
YmUgc3BlY2lmaWVkLiANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBk
aW1lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5pZXRmLm9yZ10g
DQpTZW50OiBtacOpcmNvbGVzLCAxMiBkZSBmZWJyZXJvIGRlIDIwMTQgOToxMw0KVG86IE1hcmlh
IENydXogQmFydG9sb21lDQpDYzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogW2RpbWVdICM1Mjog
VGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkNCg0K
IzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9y
eQ0KDQogTm93IChjaGFwdGVyIDQuNyk6DQogICAgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdl
IEFWUCAoQVZQIGNvZGUgVEJEOCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyDQogICAgYW5kIGRlc2Ny
aWJlcyB0aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMNCiAg
ICByZXF1ZXN0ZWQgdG8gcmVkdWNlLCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3Vs
ZCBoYXZlIHNlbnQuDQoNCiBQcm9wb3NhbDoNCiBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2Ug
QVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzIgIGFuZCBkZXNjcmliZXMg
dGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzICByZXF1ZXN0
ZWQgdG8gcmVkdWNlLCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3VsZCBzZW5kLg0K
DQoNCiBUaGUgaW50ZW50aW9uIGlzIHRvIGF2b2lkIHRoYXQgYW55b25lIG1heSBpbnRlcnByZXQg
cmVhY3Rpbmcgbm9kZSBpcyAgcmVxdWlyZWQgdG8gY29uc2lkZXIgaGlzdG9yeSBvZiBzZW50IGlu
Zm9ybWF0aW9uIHdoZW4gdGhyb3R0bGluZy4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KIFJlcG9ydGVy
OiAgbWFyaWEuY3J1ei5iYXJ0b2xvbWVAZXJpY3Nzb24uY29tICB8ICAgICAgT3duZXI6ICBNQ3J1
eg0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBCYXJ0
b2xvbcOpDQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgIFN0YXR1czogIG5ldw0KQ29tcG9uZW50OiAgZHJhZnQtZG9jZHQtZGltZS1vdmxpICAgICAg
ICAgICAgICB8ICBNaWxlc3RvbmU6DQogU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAg
ICAgICAgICAgICAgIHwgICAgVmVyc2lvbjogIDEuMA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNr
ZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvZGltZS90cmFjL3RpY2tldC81
Mj4NCmRpbWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9kaW1lLz4NCg0K


From ulrich.wiehe@nsn.com  Wed Feb 12 00:57:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D1D1A08CF for ; Wed, 12 Feb 2014 00:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXzcyxJWu7kE for ; Wed, 12 Feb 2014 00:57:32 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B78691A08D2 for ; Wed, 12 Feb 2014 00:57:31 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1C8vSjM014179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 09:57:29 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1C8vSfF003175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 09:57:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 09:57:28 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7tgekp4k6zkyUmkn+veC4s5qukxIAgAADxQCAAAUcgIAAYRYAgAAcxICAAPpJ0IABO9pAgAAD4vA=
Date: Wed, 12 Feb 2014 08:57:27 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2F04DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 23479
X-purgate-ID: 151667::1392195449-00001A6F-4BC9FBA6/0-0/0-0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 08:57:38 -0000

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

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


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











I’m confused,<=
/o:p>


 <=
/p>

I thought =
that people were in favour of allowing 0 to indicate end of overload.<=
/o:p>


 =
;


Ulrich


 =
;






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,<=
o:p>


 =
;


This comme=
nt affects as well clause 5.5.2:


 =
;


  =
; value =3D=3D 0


 =



  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 


This shoul=
d be modified to explain this value is not valid and what is the expected b=
ehavior (i.e. it is discarded).


 =
;


Best regar=
ds


/MCruz


 =
;






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,<=
/o:p>


 =
;


This appro=
ach sounds reasonable to me.


But I woul=
d like to clarify what should be the behavior if a Reduction-Percentage=3D0=
 is received. This is an invalid value, then I presume it should
 be discarded by client. 


 =
;


Regards


/MCruz


 =
;






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of Ben Campbell

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. =
(intentionally ignoring the related discussion about handling invalid value=
s):






 






Section 4.5, first paragraph, l=
ast 2 sentences:






 






Old:






 






Validity duration values 0 (i.e=
., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid va=
lidity duration values are treated as if the OC-Validity-Duration AVP were =
not present.






 






New:






 






Validity duration values above =
86400 MUST NOT be used. Invalid validity duration values are treated as if =
the OC-Validity-Duration AVP were not present. A value of zero (0) indicate=
s that an existing overload condition
 has ended and that the reporting node is in a stable condition.=







 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reductio=
n-Percentage AVP is between one (1) and one hundred (100).  Values gre=
ater than 100 are interpreted as 100.  The value of 100 means that no =
traffic is expected, i.e. the reporting node is under
 a severe load and ceases to process any new messages. The Reduction-Percen=
tage AVP MUST be present in an overload report that uses the default abatem=
ent algorithm.








 










Note that there is no zero (0) =
value defined for the Reduction-Percentage AVP. A zero value would logicall=
y indicate that no overload abatement is requested. Instead, reporting node=
s use a OC-Validity-Duration AVP value
 of zero (0) to indicate the end of an overload condition. [Section 4.5]










 






 






 






 






 




=


On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=
Just post it here.







On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


=
Okay. Does that mean we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=


Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:


=


On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=


On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration=
 of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)


=


Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.


=


I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2F04DEMUMBX014nsnin_--


From maria.cruz.bartolome@ericsson.com  Wed Feb 12 01:13:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0A1A08C2 for ; Wed, 12 Feb 2014 01:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcroLZPffbjo for ; Wed, 12 Feb 2014 01:13:05 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id A1A331A08C1 for ; Wed, 12 Feb 2014 01:13:04 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-0b-52fb3b1f912c
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 0A.85.04853.F1B3BF25; Wed, 12 Feb 2014 10:13:03 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 10:13:02 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpqukxIAgAADxQCAAAUcgIAAYRYAgAAcxICAAPpJ0IABO9pA///zkoCAABRu8A==
Date: Wed, 12 Feb 2014 09:13:01 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774131ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja689e8gg4/rxC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvmTc1kKrh1irDh07RVjA+PW1YxdjJwcEgImEusXv2aCsMUk LtxbzwZiCwmcYJS4fSO4i5ELyF7CKPH06G+wIjYBO4lLp18A2RwcIgIaEitOZIKEhQW8JX58 uAxWIiLgI9HbeIQNws6S2P7/C1icRUBV4s/JhcwgNq+Ar8THk9uYIOafYZGYdnQfWBGnQIBE x9W77CA2I9BB30+tAYszC4hL3HoyH+pQAYkle84zQ9iiEi8f/2OFsBUldp5tZ4aoz5e4928K C8QyQYmTM5+wTGAUmYVk1CwkZbOQlEHE9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEAuy+AJG9lWM ksWpxcW56UYGernpuSV6qUWZycXF+Xl6xambGIHxdHDLb6MdjCf32B9ilOZgURLnvc5aEyQk kJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkYtx2po32qwcy7o2tV7J3TP/ybf6E5feTPEU2cJp GeadyxKU5HCKyabT6sa+S9nZOgWChfGKF3o3LpXunjQ7hukY07olUh3JqvYdfO99fkt0XZ4f Lnttw97gbK3Ujbu/lgdNEo3xTnBbsc++JzV273ov1Z4Vr1fcXLHMsW7nP4Htaicu33LarsRS nJFoqMVcVJwIAOy9Pp51AgAA
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:13:09 -0000

--_000_087A34937E64E74E848732CFF8354B9209774131ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_087A34937E64E74E848732CFF8354B9209774131ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear Ulrich, all,


 <=
/p>

The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
o:p>


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 


I thought that people wer=
e in favour of allowing 0 to indicate end of overload.

 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 <=
/p>

This comment affects as w=
ell clause 5.5.2:


 <=
/p>

  =
; value =3D=3D 0


 =



  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 


This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:




On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_087A34937E64E74E848732CFF8354B9209774131ESESSMB101erics_--


From ulrich.wiehe@nsn.com  Wed Feb 12 01:13:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBBA1A08C1 for ; Wed, 12 Feb 2014 01:13:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI_WJmlExWrY for ; Wed, 12 Feb 2014 01:13:51 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3A1A08C9 for ; Wed, 12 Feb 2014 01:13:50 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1C9DkW2021125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 10:13:46 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1C9DjFf005096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 10:13:45 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 10:13:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" 
Thread-Topic: [Dime] [dime] #50: OC-OLR AVP implicit info
Thread-Index: AQHPJ8YkuggLJhr06kytgQtL4UJMl5qxU9Bg
Date: Wed, 12 Feb 2014 09:13:43 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F21@DEMUMBX014.nsn-intra.net>
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
In-Reply-To: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 4828
X-purgate-ID: 151667::1392196426-00001A6F-D3053EFC/0-0/0-0
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:13:55 -0000

SGksDQoNCkknbSBvayB3aXRoIHRoZSBmaXJzdCBzZW50ZW5jZToNCj4gVGhlIE9DLU9MUiBBVlAg
ZG9lcyBub3QgY29udGFpbiBleHBsaWNpdGx5IGFsbCBpbmZvcm1hdGlvbiBuZWVkZWQgYnkgdGhl
DQo+IHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8gZGVjaWRlIHdoZXRoZXIgYSBzdWJzZXF1ZW50
IHJlcXVlc3QgbXVzdCB1bmRlcmdvDQo+IGEgdGhyb3R0bGluZyBwcm9jZXNzIHdpdGggdGhlIHJl
Y2VpdmVkIHJlZHVjdGlvbiBwZXJjZW50YWdlLg0KDQpUaGUgcmVzdCwgaG93ZXZlciwgc2hvdWxk
IGJlIHJlcGxhY2VkIHdpdGggZS5nLjoNCg0KVGhlIHZhbHVlIG9mIHRoZSBPQy1SZXBvcnQtVHlw
ZSBBVlAgd2l0aGluIHRoZSBPQy1PTFIgQVZQIGluZGljYXRlcyB3aGljaCBpbXBsaWNpdCANCmlu
Zm9ybWF0aW9uIGlzIHJlbGV2YW50IGZvciB0aGlzIGRlY2lzaW9uIChzZWUgY2xhdXNlIDQuNiku
DQoNClVscmljaA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUg
W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgZGltZSBpc3N1
ZSB0cmFja2VyDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDg6NDMgQU0NClRv
OiBkcmFmdC1kb2NkdC1kaW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7IG1hcmlhLmNydXouYmFydG9s
b21lQGVyaWNzc29uLmNvbQ0KQ2M6IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFtEaW1lXSBbZGlt
ZV0gIzUwOiBPQy1PTFIgQVZQIGltcGxpY2l0IGluZm8NCg0KIzUwOiBPQy1PTFIgQVZQIGltcGxp
Y2l0IGluZm8NCg0KIE5vdyAoY2hhcHRlciA0LjMpOg0KDQogICAgVGhlIE9DLU9MUiBBVlAgZG9l
cyBub3QgY29udGFpbiBleHBsaWNpdCBpbmZvcm1hdGlvbiB0byB3aGljaA0KICAgIGFwcGxpY2F0
aW9uIGl0IGFwcGxpZXMgdG8gYW5kIHdobyBpbnNlcnRlZCB0aGUgQVZQIG9yIHdob20gdGhlDQog
ICAgc3BlY2lmaWMgT0MtT0xSIEFWUCBjb25jZXJucyB0by4gQm90aCB0aGVzZSBpbmZvcm1hdGlv
biBpcw0KICAgIGltcGxpY2l0bHkgbGVhcm5lZCBmcm9tIHRoZSBlbmNhcHN1bGF0aW5nIERpYW1l
dGVyIG1lc3NhZ2UvY29tbWFuZC4NCiAgICBUaGUgYXBwbGljYXRpb24gdGhlIE9DLU9MUiBBVlAg
YXBwbGllcyB0byBpcyB0aGUgc2FtZSBhcyB0aGUNCiAgICBBcHBsaWNhdGlvbi1JZCBmb3VuZCBp
biB0aGUgRGlhbWV0ZXIgbWVzc2FnZSBoZWFkZXIuICBUaGUgaWRlbnRpdHkNCiAgICB0aGUgT0Mt
T0xSIEFWUCBjb25jZXJucyBpcyBkZXRlcm1pbmVkIGZyb20gdGhlIE9yaWdpbi1Ib3N0IEFWUCBm
b3VuZA0KICAgIGZyb20gdGhlIGVuY2Fwc3VsYXRpbmcgRGlhbWV0ZXIgY29tbWFuZC4NCg0KDQog
TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IOKAnHdobyBpbnNlcnRlZCB0aGUgQVZQ4oCdIGNhbm5v
dCBhbHdheXMgYmUgbGVhcm5lZA0KIGZyb20gdGhlIGVuY2Fwc3VsYXRpbmcgRGlhbWV0ZXIgbWVz
c2FnZSwgc2luY2Ug4oCcb3JpZ2luLWhvc3TigJ0gbWF5IG5vdA0KIGFsd2F5cyBjb250YWluIHRo
ZSBob3N0IHRoYXQgaW5zZXJ0ZWQgdGhlIE9MUi4NCiBBIHBhcnQgZnJvbSB0aGF0LCDigJx3aG9t
IHRoZSBzcGVjaWZpYyBPQy1PTFIgQVZQIGNvbmNlcm5zIHRv4oCdLCBjb3VsZCBiZSBhDQogYml0
IG1pc2xlYWRpbmfigKYg4oCcd2hvbeKAnSBtYXkgYmUgaG9zdCwgcmVhbG0sIG9yIGFueSBvdGhl
ciBmdXR1cmUgUmVwb3J0VHlwZSwNCiBvciBldmVuIGFueSBvdGhlciDigJxuYXJyb3dlZCBzY29w
ZeKAnSB3aXRoaW4gdGhlIE9MUi4gTGFzdCBzZW50ZW5jZSBpcw0KIGFmZmVjdGVkIGJ5IHRoaXMg
YW1iaWd1aXR5IGFzIHdlbGwuDQoNCg0KIE5ldyBwcm9wb3NhbCAocmVsYXRlZCB0byBuZXcgdGV4
dCBwcm9wb3NlZCBjaGFwdGVyIDQuNiwgc2VlIHRvIElzc3VlICMzNCk6DQoNCiBUaGUgT0MtT0xS
IEFWUCBkb2VzIG5vdCBjb250YWluIGV4cGxpY2l0bHkgYWxsIGluZm9ybWF0aW9uIG5lZWRlZCBi
eSB0aGUNCiByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIGRlY2lkZSB3aGV0aGVyIGEgc3Vic2Vx
dWVudCByZXF1ZXN0IG11c3QgdW5kZXJnbw0KIGEgdGhyb3R0bGluZyBwcm9jZXNzIHdpdGggdGhl
IHJlY2VpdmVkIHJlZHVjdGlvbiBwZXJjZW50YWdlLg0KIFRoZSBmb2xsb3dpbmcgaW5mb3JtYXRp
b24gaXMgaW1wbGljaXRseSBrbm93biBmcm9tIHRoZSByZWNlaXZlZA0KIGFwcGxpY2F0aW9uIGFu
c3dlciBhbmQgT0MtT0xSIEFWUCwgdGhhdCBpcyB1c2VkIGJ5IHJlYWN0aW5nIG5vZGUgdG8NCiBp
ZGVudGlmeSBzdWJzZXF1ZW50IHJlcXVlc3RzIHRoYXQgYXJlIHJlcXVlc3RlZCB0byBiZSB0aHJv
dHRsZWQ6DQoNCiBhKVRoZSBBcHBsaWNhdGlvbi1JRCBpcyB0aGUgdmFsdWUgb2YgdGhlIEFwcGxp
Y2F0aW9uLUlEIG9mIHRoZSBEaWFtZXRlcg0KICAgSGVhZGVyIG9mIHRoZSByZWNlaXZlZCBtZXNz
YWdlIHRoYXQgY29udGFpbmVkIHRoZSBPQy1PTFIgQVZQLg0KDQogYilUaGUgRGVzdGluYXRpb24t
UmVhbG0gQVZQIChpZiByZXF1aXJlZCwgc2VlIDQuNikgaXMgdGhlIHZhbHVlIG9mIHRoZQ0KIE9y
aWdpbi1Ib3N0IEFWUCBvZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZSB0aGF0IGNvbnRhaW5lZCB0aGUg
T0MtT0xSIEFWUC4NCg0KIGMpVGhlIERlc3RpbmF0aW9uLUhvc3QgQVZQIChpZiByZXF1aXJlZCwg
c2VlIDQuNikgaXMgdGhlIHZhbHVlIG9mIHRoZQ0KIE9yaWdpbi1Ib3N0IEFWUCBvZiB0aGUgcmVj
ZWl2ZWQgbWVzc2FnZSB0aGF0IGNvbnRhaW5lZCB0aGUgT0MtT0xSIEFWUC4NCg0KLS0gDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg
ICAgT3duZXI6ICBkcmFmdC1kb2NkdC1kaW1lLQ0KICBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmlj
c3Nvbi5jb20gIHwgIG92bGlAdG9vbHMuaWV0Zi5vcmcNCiAgICAgVHlwZTogIGRlZmVjdCAgICAg
ICAgICAgICAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAg
ICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBkcmFmdC1kb2NkdC1kaW1l
LW92bGkgICAgfCAgICBWZXJzaW9uOiAgMS4wDQogU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1l
bnQgICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6
IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9kaW1lL3RyYWMvdGlja2V0LzUwPg0KZGlt
ZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUvPg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K


From ulrich.wiehe@nsn.com  Wed Feb 12 01:16:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7ADD1A08D3 for ; Wed, 12 Feb 2014 01:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH5zYYWy13ul for ; Wed, 12 Feb 2014 01:16:49 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F26041A08BA for ; Wed, 12 Feb 2014 01:16:48 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1C9Gk7H028048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 10:16:46 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1C9Gk1D014159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 10:16:46 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 10:16:46 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 10:16:46 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" , "maria.cruz.bartolome@ericsson.com" 
Thread-Topic: [Dime] [dime] #51: OC-Supported-Features in requests
Thread-Index: AQHPJ8dJMvhOqgSOVkGQ3fH3JyWghZqxViIg
Date: Wed, 12 Feb 2014 09:16:46 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F32@DEMUMBX014.nsn-intra.net>
References: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org>
In-Reply-To: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1956
X-purgate-ID: 151667::1392196607-00001A6F-AC77D7EC/0-0/0-0
Subject: Re: [Dime] [dime] #51: OC-Supported-Features in requests
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:16:52 -0000

SSBhZ3JlZS4NCg0KQWJzZW5jZSBvZiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIGZyb20gYSBy
ZXF1ZXN0IG1lYW5zICJET0lDIG5vdCBzdXBwb3J0ZWQiLg0KVWxyaWNoDQoNCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgZXh0IGRpbWUgaXNzdWUgdHJhY2tlcg0KU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAxMiwgMjAxNCA4OjUyIEFNDQpUbzogbWFyaWEuY3J1ei5iYXJ0b2xvbWVAZXJpY3Nz
b24uY29tDQpDYzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogW0RpbWVdIFtkaW1lXSAjNTE6IE9D
LVN1cHBvcnRlZC1GZWF0dXJlcyBpbiByZXF1ZXN0cw0KDQojNTE6IE9DLVN1cHBvcnRlZC1GZWF0
dXJlcyBpbiByZXF1ZXN0cw0KDQogTm93Og0KIFRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQ
IFNIT1VMRCBiZSBpbmNsdWRlZCBpbnRvIGV2ZXJ5IERpYW1ldGVyDQogbWVzc2FnZSBhIERPSUMN
CiBzdXBwb3J0aW5nIG5vZGUgc2VuZHMgKGFuZCBpbnRlbmRzIHRvIHVzZSBmb3IgRE9JQyBwdXJw
b3NlcykuDQoNCiBXaHkgaXMgInNob3VsZCIgdXNlZD8NCg0KIFByb3Bvc2FsOiByZXBsYWNlIFNI
T1VMRCBieSBNVVNUDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBtYXJp
YS5jcnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20gIHwgICAgICBPd25lcjogIE1DcnV6DQogICAg
IFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIEJhcnRvbG9tw6kN
CiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgU3Rh
dHVzOiAgbmV3DQpDb21wb25lbnQ6ICBkcmFmdC1kb2NkdC1kaW1lLW92bGkgICAgICAgICAgICAg
IHwgIE1pbGVzdG9uZToNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgICAgICAgICAg
ICAgICAgfCAgICBWZXJzaW9uOiAgMS4wDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNr
ZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvZGltZS90cmFjL3RpY2tldC81
MT4NCmRpbWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9kaW1lLz4NCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpE
aU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUN
Cg==


From ulrich.wiehe@nsn.com  Wed Feb 12 01:21:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6992E1A08C3 for ; Wed, 12 Feb 2014 01:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeBaYSDXfJZi for ; Wed, 12 Feb 2014 01:21:50 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B3B941A08C8 for ; Wed, 12 Feb 2014 01:21:49 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1C9LltP007229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 10:21:47 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1C9LkAO001080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 10:21:46 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 10:21:46 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 10:21:46 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7tgekp4k6zkyUmkn+veC4s5qukxIAgAADxQCAAAUcgIAAYRYAgAAcxICAAPpJ0IABO9pAgAAD4vD///QJgIAAExhQ
Date: Wed, 12 Feb 2014 09:21:45 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2F51DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 29683
X-purgate-ID: 151667::1392196907-000025D0-C2767EE7/0-0/0-0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:21:55 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2F51DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2F51DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Thank you =
for the clarification.


I agree.


 =
;






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulric=
h, all,


 


The propos=
al was to use OC-Validity-Duration AVP =3D0 to indicate end of overload, si=
nce this could be generally applied to any algorithm.


Then, Redu=
ction-Percentage =3D 0 should be considered as invalid.


I found th=
is reasonable.


 


Best regar=
ds


/MCruz


 


 






From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m confused,


 


I thought =
that people were in favour of allowing 0 to indicate end of overload.


 


Ulrich


 






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,<=
/span>


 


This comme=
nt affects as well clause 5.5.2:


 


  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This shoul=
d be modified to explain this value is not valid and what is the expected b=
ehavior (i.e. it is discarded).


 


Best regar=
ds


/MCruz


 






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,


 


This appro=
ach sounds reasonable to me.<=
/p>

But I woul=
d like to clarify what should be the behavior if a Reduction-Percentage=3D0=
 is received. This is an invalid value, then I presume it should
 be discarded by client. 


 


Regards


/MCruz


 






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of Ben Campbell

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. =
(intentionally ignoring the related discussion about handling invalid value=
s):






 






Section 4.5, first paragraph, l=
ast 2 sentences:






 






Old:






 






Validity duration values 0 (i.e=
., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid va=
lidity duration values are treated as if the OC-Validity-Duration AVP were =
not present.






 






New:






 






Validity duration values above =
86400 MUST NOT be used. Invalid validity duration values are treated as if =
the OC-Validity-Duration AVP were not present. A value of zero (0) indicate=
s that an existing overload condition
 has ended and that the reporting node is in a stable condition.=







 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reductio=
n-Percentage AVP is between one (1) and one hundred (100).  Values gre=
ater than 100 are interpreted as 100.  The value of 100 means that no =
traffic is expected, i.e. the reporting node is under
 a severe load and ceases to process any new messages. The Reduction-Percen=
tage AVP MUST be present in an overload report that uses the default abatem=
ent algorithm.








 










Note that there is no zero (0) =
value defined for the Reduction-Percentage AVP. A zero value would logicall=
y indicate that no overload abatement is requested. Instead, reporting node=
s use a OC-Validity-Duration AVP value
 of zero (0) to indicate the end of an overload condition. [Section 4.5]










 






 






 






 






 




=


On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=
Just post it here.







On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


=
Okay. Does that mean we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=


Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:


=


On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=


On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration=
 of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)


=


Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.


=


I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B2F51DEMUMBX014nsnin_--


From jouni.nospam@gmail.com  Wed Feb 12 01:23:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAE61A08C3 for ; Wed, 12 Feb 2014 01:23:03 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5ni5zUGR3rT for ; Wed, 12 Feb 2014 01:22:57 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5D48C1A08C2 for ; Wed, 12 Feb 2014 01:22:57 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id b8so6770265lan.4 for ; Wed, 12 Feb 2014 01:22:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T0IIDAxep80WK/4ZDCvvvfBPKidAieQ9LKm5NKBdsTo=; b=AzRVqm6x974r6HjCYcd6XZLu3LtbFaLw0d1i+Y7+GJq3xBmC/afGYYSJlfVW74NR2Q gpX8FfHXSK2nQmox3IpEAR3oY7dSq/6JtsocR07FKBgsPWABSVQ3Rgi/JbKqrt6t580w +LJF8GDYIU6vpk/OrN8f8hHqrsaq3F1MUUDrEDssXpBWBaBZtw7upt9BpH5iSV7xZCbD D8XFbrvwDldzuMA4vGxg2pNeFoY9HZMKtAk2BV6dUvm5g3pQ4w1Lg820qk+pf+U31SPE sp/G98e9FJ3I0LU2sieEW9yf+13xm51NqyWa9q8FGGC4AcCl/N96ChyiKbhn6huucxKY 6OQA==
X-Received: by 10.152.180.42 with SMTP id dl10mr1041939lac.62.1392196975906; Wed, 12 Feb 2014 01:22:55 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id 10sm32353655lan.5.2014.02.12.01.22.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 01:22:53 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F32@DEMUMBX014.nsn-intra.net>
Date: Wed, 12 Feb 2014 11:22:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F32@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #51: OC-Supported-Features in requests
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:23:03 -0000

Also in answer messages now? The text quoted below does not =
differentiate
whether it is answer or request.

- Jouni

On Feb 12, 2014, at 11:16 AM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> I agree.
>=20
> Absence of OC-Supported-Features AVP from a request means "DOIC not =
supported".
> Ulrich
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue =
tracker
> Sent: Wednesday, February 12, 2014 8:52 AM
> To: maria.cruz.bartolome@ericsson.com
> Cc: dime@ietf.org
> Subject: [Dime] [dime] #51: OC-Supported-Features in requests
>=20
> #51: OC-Supported-Features in requests
>=20
> Now:
> The OC-Supported-Features AVP SHOULD be included into every Diameter
> message a DOIC
> supporting node sends (and intends to use for DOIC purposes).
>=20
> Why is "should" used?
>=20
> Proposal: replace SHOULD by MUST
>=20
> --=20
> =
-----------------------------------------------+--------------------------=
-
> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>     Type:  defect                             |  Bartolom=E9
> Priority:  major                              |     Status:  new
> Component:  draft-docdt-dime-ovli              |  Milestone:
> Severity:  Active WG Document                 |    Version:  1.0
>                                               |   Keywords:
> =
-----------------------------------------------+--------------------------=
-
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> 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 jouni.nospam@gmail.com  Wed Feb 12 01:31:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E8A1A08CD for ; Wed, 12 Feb 2014 01:31:38 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mNrWy1Z4Sjw for ; Wed, 12 Feb 2014 01:31:36 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A32B11A08C2 for ; Wed, 12 Feb 2014 01:31:35 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id y1so6761561lam.41 for ; Wed, 12 Feb 2014 01:31:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CCFQT9ezuHIFfDTxSsHprN8V7uUziJZMjUwJI4dLjHc=; b=NKk9rgPiB1130WzWcCXzFv/XLx1Gc3G73iyv7oreTpqI8tFR11OesJqa3GtgfJPzHa I809S5Mtwy7V6s7zUbM9ZNtRxfZr8oF1h8/J5p3P0sZRiD/UepdGcAaNimvO/oZvjGDU QqIfDPHvgJzm8D5oifB8pC274XYVR0Km6GQz2CIE+7CytlsHV0bQq2HtHchLi6U+NzvD FKVUjhrP+T45NCfCS6RTkJvC1J430CenuoQUcW8fQNZsmKv6RoKCtjZxny0qSlv4EFJh Y+umB8krgYa5JQQFyJeHQYp+ymGvD0d2EkpKVPkfRihakozc2jBLuQhORYjIArvs1GC9 vsng==
X-Received: by 10.152.242.36 with SMTP id wn4mr385643lac.84.1392197494143; Wed, 12 Feb 2014 01:31:34 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id e1sm32406616laa.8.2014.02.12.01.31.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 01:31:31 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F21@DEMUMBX014.nsn-intra.net>
Date: Wed, 12 Feb 2014 11:31:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F21@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:31:38 -0000

I am OK with both proposals with a slight preference to Ulrich's
text, since it avoid unnecessary duplication of text from Section
4.6 (which is to be formulated..)

- JOuni


On Feb 12, 2014, at 11:13 AM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Hi,
>=20
> I'm ok with the first sentence:
>> The OC-OLR AVP does not contain explicitly all information needed by =
the
>> reacting node in order to decide whether a subsequent request must =
undergo
>> a throttling process with the received reduction percentage.
>=20
> The rest, however, should be replaced with e.g.:
>=20
> The value of the OC-Report-Type AVP within the OC-OLR AVP indicates =
which implicit=20
> information is relevant for this decision (see clause 4.6).
>=20
> Ulrich
>=20
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue =
tracker
> Sent: Wednesday, February 12, 2014 8:43 AM
> To: draft-docdt-dime-ovli@tools.ietf.org; =
maria.cruz.bartolome@ericsson.com
> Cc: dime@ietf.org
> Subject: [Dime] [dime] #50: OC-OLR AVP implicit info
>=20
> #50: OC-OLR AVP implicit info
>=20
> Now (chapter 4.3):
>=20
>    The OC-OLR AVP does not contain explicit information to which
>    application it applies to and who inserted the AVP or whom the
>    specific OC-OLR AVP concerns to. Both these information is
>    implicitly learned from the encapsulating Diameter message/command.
>    The application the OC-OLR AVP applies to is the same as the
>    Application-Id found in the Diameter message header.  The identity
>    the OC-OLR AVP concerns is determined from the Origin-Host AVP =
found
>    from the encapsulating Diameter command.
>=20
>=20
> My understanding is that =93who inserted the AVP=94 cannot always be =
learned
> from the encapsulating Diameter message, since =93origin-host=94 may =
not
> always contain the host that inserted the OLR.
> A part from that, =93whom the specific OC-OLR AVP concerns to=94, =
could be a
> bit misleading=85 =93whom=94 may be host, realm, or any other future =
ReportType,
> or even any other =93narrowed scope=94 within the OLR. Last sentence =
is
> affected by this ambiguity as well.
>=20
>=20
> New proposal (related to new text proposed chapter 4.6, see to Issue =
#34):
>=20
> The OC-OLR AVP does not contain explicitly all information needed by =
the
> reacting node in order to decide whether a subsequent request must =
undergo
> a throttling process with the received reduction percentage.
> The following information is implicitly known from the received
> application answer and OC-OLR AVP, that is used by reacting node to
> identify subsequent requests that are requested to be throttled:
>=20
> a)The Application-ID is the value of the Application-ID of the =
Diameter
>   Header of the received message that contained the OC-OLR AVP.
>=20
> b)The Destination-Realm AVP (if required, see 4.6) is the value of the
> Origin-Host AVP of the received message that contained the OC-OLR AVP.
>=20
> c)The Destination-Host AVP (if required, see 4.6) is the value of the
> Origin-Host AVP of the received message that contained the OC-OLR AVP.
>=20
> --=20
> =
-------------------------------------+------------------------------------=
-
> Reporter:                           |      Owner:  draft-docdt-dime-
>  maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
>     Type:  defect                   |     Status:  new
> Priority:  major                    |  Milestone:
> Component:  draft-docdt-dime-ovli    |    Version:  1.0
> Severity:  Active WG Document       |   Keywords:
> =
-------------------------------------+------------------------------------=
-
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Wed Feb 12 01:32:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773021A08C2 for ; Wed, 12 Feb 2014 01:32:58 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m_3QPAbKPso for ; Wed, 12 Feb 2014 01:32:56 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E1D021A08EB for ; Wed, 12 Feb 2014 01:32:55 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id c11so6871367lbj.17 for ; Wed, 12 Feb 2014 01:32:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BhW20MSSaDd4tXS7immIHMmEOc0QcF9mRGQFcT6th7E=; b=gnQtA3rYM2DxtdWulCl5mM0/rctoq0Tixg3kW/MnNrSXtr8y1PGjzdgJXNMR3X+92Z xI9CZIezGDf4VVeoTswjoOEVQUPPSGlgFRTOmFmQfLK6XUx/99tMpUemrBmZW9VleNGc uBiVG4T5dUaHeqsFdgUtx7HEEXII2d/SwyNOd97RsUtFZOsiRtjkuks0E+hr1Y14bRXA c8o1yROadi12rsZiK9L/i9J3OHtvkKZOWFPt1CEKCHpMu/fRnuhBWxtQWJMxH6cWvU7F CgDiAAHBlICdzoDGtHdaXsdFopf0eiNMKoAtQrfIWHs86SQmUE/x5C/51MboJdAPfXyK OYOw==
X-Received: by 10.152.242.165 with SMTP id wr5mr1117458lac.47.1392197574517; Wed, 12 Feb 2014 01:32:54 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id v5sm32418873laj.0.2014.02.12.01.32.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 01:32:51 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
Date: Wed, 12 Feb 2014 11:32:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
To: dime@ietf.org
X-Mailer: Apple Mail (2.1510)
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:32:58 -0000

Fine by me.

- Jouni


On Feb 12, 2014, at 10:13 AM, dime issue tracker =
 wrote:

> #52: Throttling not needed to be based on previous history
>=20
> Now (chapter 4.7):
>    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of =
Unsigned32
>    and describes the percentage of the traffic that the sender is
>    requested to reduce, compared to what it otherwise would have sent.
>=20
> Proposal:
> The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
> and describes the percentage of the traffic that the sender is
> requested to reduce, compared to what it otherwise would send.
>=20
>=20
> The intention is to avoid that anyone may interpret reacting node is
> required to consider history of sent information when throttling.
>=20
> --=20
> =
-----------------------------------------------+--------------------------=
-
> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>     Type:  defect                             |  Bartolom=E9
> Priority:  major                              |     Status:  new
> Component:  draft-docdt-dime-ovli              |  Milestone:
> Severity:  Active WG Document                 |    Version:  1.0
>                                               |   Keywords:
> =
-----------------------------------------------+--------------------------=
-
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Wed Feb 12 01:36:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F174B1A08F2 for ; Wed, 12 Feb 2014 01:36:27 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbBicevV2CyZ for ; Wed, 12 Feb 2014 01:36:25 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 210561A08D8 for ; Wed, 12 Feb 2014 01:36:24 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id p9so6782876lbv.6 for ; Wed, 12 Feb 2014 01:36:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G5XaDwvmvwiYZKmccFurSRyJX42pPnX+e7V0YLMSfzk=; b=ziXZYADW6qhvEbRCWeE/lVBbmSoMldF9V97TnLh181gzxtKWvikDJ892sbMsCg4JL/ aZ1NET2srBAtknM6kXKhNkoBTLcFkDn+RXeziNlVXRGbIm+uHCtHHicci9xlYAZxW1Ti b/SiKJ3cX1TUXsz0dG3zWGkkzM5ieXR14DP+U2874U5/zhY2+yjzkswe7FS9gW7ymtWb +SIBgOP5GCzoWN6rmfdd9BUDs3R3pBIgCF8/Oz9VkAbwyPzitUEP68hODwwrEpCNhDkv kBzlpOd2CkQPhxuRj+pQqx4viW1ZyBs0j5bLvUpHHeLfkqe3fI4IsYhuA3TFpNuiaCXB JcDA==
X-Received: by 10.152.9.65 with SMTP id x1mr30752961laa.6.1392197783715; Wed, 12 Feb 2014 01:36:23 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id w2sm32427666lad.4.2014.02.12.01.36.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 01:36:21 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se>
Date: Wed, 12 Feb 2014 11:36:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:36:28 -0000

Fine by me.. though you then need to apply the same change=20
to the rest of this paragraph, not only the first one.

Also, please update this additional concern into the
issue tracker issue #52.

- Jouni

On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome =
 wrote:

> Same comment also applies to following paragraph in 5.5.2
>=20
> Now:
>   0 < value < 100
>=20
>      Indicates that the reporting node urges the reacting node to
>      reduce its traffic by a given percentage.  For example if the
>      reacting node has been sending 100 packets per second to the
>      reporting node, then a reception of OC-Reduction-Percentage value
>      of 10 would mean that from now on the reacting node MUST only =
send
>      90 packets per second.  How the reacting node achieves the "true
>      reduction" transactions leading to the sent request messages is =
up
>      to the implementation.  The reacting node MAY simply drop every
>      10th packet from its output queue and let the generic application
>      logic try to recover from it.0 < value < 100
>=20
> Proposal:
> Indicates that the reporting node urges the reacting node to
> reduce its traffic by a given percentage. For example if the
> reacting node would send 100 packets to the				=
<---
> reporting node, then a reception of OC-Reduction-Percentage value
> of 10 would mean that from now on the reacting node MUST only send
> 90 packets per second. How the reacting node achieves the "true
> reduction" transactions leading to the sent request messages is up
> to the implementation. The reacting node MAY simply drop every
> 10th packet from its output queue and let the generic application
> logic try to recover from it.
>=20
>=20
> We should not specify a rates for the simple loss algorithm. It=92s up =
to the implementation how to reduce, but no time unit has to be =
specified.=20
>=20
>=20
>=20
> -----Original Message-----
> From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]=20
> Sent: mi=E9rcoles, 12 de febrero de 2014 9:13
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> Subject: [dime] #52: Throttling not needed to be based on previous =
history
>=20
> #52: Throttling not needed to be based on previous history
>=20
> Now (chapter 4.7):
>    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of =
Unsigned32
>    and describes the percentage of the traffic that the sender is
>    requested to reduce, compared to what it otherwise would have sent.
>=20
> Proposal:
> The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  =
and describes the percentage of the traffic that the sender is  =
requested to reduce, compared to what it otherwise would send.
>=20
>=20
> The intention is to avoid that anyone may interpret reacting node is  =
required to consider history of sent information when throttling.
>=20
> --=20
> =
-----------------------------------------------+------------------------
> -----------------------------------------------+---
> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>     Type:  defect                             |  Bartolom=E9
> Priority:  major                              |     Status:  new
> Component:  draft-docdt-dime-ovli              |  Milestone:
> Severity:  Active WG Document                 |    Version:  1.0
>                                               |   Keywords:
> =
-----------------------------------------------+------------------------
> -----------------------------------------------+---
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From maria.cruz.bartolome@ericsson.com  Wed Feb 12 01:55:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28EE1A0901 for ; Wed, 12 Feb 2014 01:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4nevBdJ3bUB for ; Wed, 12 Feb 2014 01:55:39 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 374DF1A08D5 for ; Wed, 12 Feb 2014 01:55:38 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-1c-52fb4519781d
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 0F.BC.04853.9154BF25; Wed, 12 Feb 2014 10:55:37 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 10:55:36 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYIAAHLvQ
Date: Wed, 12 Feb 2014 09:55:35 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvja6k6+8gg9PrTCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtaT55gKJplUbOrZxtTA+EGri5GTQ0LAROLo3eUsELaYxIV7 69m6GLk4hAROMEps/D6TEcJZwiix+c0/NpAqNgE7iUunXzB1MXJwiAhoSKw4kQliCgv4SMzY HAZSISLgKzFz9QxmCDtPovfyLSYQm0VAVeLN/2NgnbxANUvfuUJM/8cmsXD7MnaQGk6BAIkl K1ezgtiMQPd8P7UGrJdZQFzi1pP5TBB3Ckgs2XOeGcIWlXj5+B8rhK0osfNsOzNEvZ7EjalT 2CBsbYllC1+DxXkFBCVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjJLFqcXFuelGBnq56bkl eqlFmcnFxfl5esWpmxiBkXFwy2+jHYwn99gfYpTmYFES573OWhMkJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgXHrE92zbgytIbc5U1bEuXdJny25fX0F896wjTW5XOvV/W8+O8UvbGC9ZV/6 rcz0Q1u4Fbp/eLZbGSTnn/i+5qRabv8yi8q9+gfnlN2fz5id6/MkbdGKbsZ3kwOUd09Przy1 3Legff7mzFc73tv1GfNtEa/Qsn5zuEHm3WctL2vZBycj5z3SlVZiKc5INNRiLipOBAB9G9vR WgIAAA==
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 09:55:42 -0000

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting no=
de overload mitigation based on implicit indications (as described by TR), =
therefore any 3GPP application that will support new "Overload mitigation" =
feature (or whatever may be the name), shall improve its procedures with th=
is objective. It is expected as well, that this new 3GPP "Overload mitigati=
on" feature makes use of our DOIC, and then it is very beneficial that the =
reacting node could identify at any moment whether or not the reporting nod=
e supports DOIC, since procedures to be implemented could be potentially di=
fferent.

2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?=20
[MCruz] Reacting node receives reporting node Supported-Features. Regardles=
s the reporting node is either an agent or a server, in case the reacting n=
ode needs to treat "implicit indications" (like TOO_BUSY), expected reactio=
n may depend on whether or not reporting node supports DOIC. This informati=
on is very beneficial to determine the most appropriate reaction.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement  in our 3GPP TR:

6.3.3	Implicit Overload Indication
6.3.3.1	Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
-	DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
-	Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> 1) I want the reacting node to be able to learn if a (potentially)=20
> reporting node supports DOIC, even when that node is not in overload.
> I don't want to specify any particular behavior for that knowledge,=20
> but I suspect implementations may want to treat DOIC compliant servers=20
> in some way differently than they do non-DOIC servers. For example, I=20
> might have a configured rate limit for non-DOIC peers, but use a=20
> higher (or no) limit for peers that are known to support DOIC (and can=20
> thus speak for themselves.) sounds like a new requirement;=20
> where does it come from? I would have thought that there is no need to=20
> distinguish between
> a) DOIC not supported and therefore no traffic reduction requested,=20
> and
> b) DOIC supported, but not in overload and therefore no traffic=20
> reduction requested
>=20

At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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 jean-jacques.trottin@alcatel-lucent.com  Wed Feb 12 02:13:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FBB1A090C for ; Wed, 12 Feb 2014 02:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4u6mOUT5UZa for ; Wed, 12 Feb 2014 02:13:03 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 13A731A091C for ; Wed, 12 Feb 2014 02:13:02 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1CACwlP000559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Feb 2014 04:12:59 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1CACvXW020603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Feb 2014 11:12:57 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 11:12:57 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb/qgZCc+pd4WU6PPq6Pjc7gSpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxA=
Date: Wed, 12 Feb 2014 10:12:56 +0000
Message-ID: 
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.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: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026645F9FR712WXCHMBA11z_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 12 Feb 2014 02:19:04 -0800
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 10:13:11 -0000

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

SGkNCg0KT24gdGhpcyB0b3BpYywgbXkgdmlldyBpcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIHNo
YWxsICByZWNlaXZlIOKAnGVub3VnaOKAnSBPTFJzIHBlciBwZXJpb2Qgb2YgdGltZSB0byBlbnN1
cmUgdGhlIGVmZmljaWVuY3kgb2YgdGhlIHRyYWZmaWMgIHJlZHVjdGlvbiBtZWNoYW5pc20gLiBB
IHdheSB0byBhY2hpZXZlICB0aGUg4oCcZW5vdWdo4oCdIGlzIHRvIGhhdmUgYW4gT0xSIGluIGFs
bCAgYW5zd2VyICBtZXNzYWdlcyBhcyBwcm9wb3NlZCBhbmQgdGhpcyBjYW4gdGhlIHJlY29tbWVu
ZGVkIHdheS4gTm93IGFzIE5pcmF2IHNhaWQsIHRoZXJlIG1heSBiZSBwcm90b2NvbCBkZXNpZ24g
dGhhdCB3aWxsIGJlaGF2ZSBkaWZmZXJlbnRseSBhbmQgc2VuZCDigJxlbm91Z2jigJ0gT0xScyAg
YnV0IG5vdCBpbiBhbGwgbWVzc2FnZXMuDQoNCkFzIGFsc28gTmlyYXYgbm90ZWQsICBJIGRvIG5v
dCB3ZWxsIHNlZSB0aGUgbmVlZCB0byB3cml0ZSBhZGRpdGlvbmFsIG5vdGVzIGFzIG1hbnkgc2l0
dWF0aW9ucyBjYW4gb2NjdXIgYW5kICBhcmUgbm90IGxpbWl0ZWQgdG8gdGhlIGV4YW1wbGUgb2Yg
dGhlIHJlYWN0aW5nICBub2RlICBkaXNjYXJkaW5nIE9MUnMuDQoNCkJlc3QgcmVnYXJkcw0KDQpK
SmFjcXVlcw0KDQoNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBE
ZSBsYSBwYXJ0IGRlIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0KRW52b3nDqSA6IG1hcmRpIDEx
IGbDqXZyaWVyIDIwMTQgMTY6MzUNCsOAIDogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0
Zi5vcmcNCk9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCkF0IGxlYXN0LCBpdCBpcyBjb3JyZWN0ISDimLoNCg0KRGUgOiBEaU1FIFtt
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogQmFy
dG9sb21lDQpFbnZvecOpIDogbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxNTowMA0Kw4AgOiBkaW1l
QGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTGlvbmVsLCBOaXJhdiwgYWxs
LA0KDQpNYXliZSB0aGUgbm90ZSBjb3VsZCBiZSBtb2RpZmllZDoNCg0KTm90ZSDigJN0aGUgcmVh
Y3Rpbmcgbm9kZSBjb3VsZCBiZSBhbnkgYWdlbnQgaW4gdGhlIHBhdGgsIGFuZCB0aGF0IGluIHNv
bWUgZXJyb3Igc2l0dWF0aW9ucyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkg
cmVhY3Rpbmcgbm9kZXMuDQoNCkkgYWRkZWQgdGhlIGNhc2UgT0xSIGNvdWxkIGJlIGRpc2NhcmRl
ZCBieSByZWFjdGluZyBub2Rlcywgc2luY2UgaXQgaGlnaGxpZ2h0cyBhIHNpdHVhdGlvbiB3aGVy
ZSB0aGUgc2VydmVyIHdpbGwgbm90IGtub3cgd2hldGhlciBvciBub3QgYSB2YWxpZCBPTFIgaXMg
cmVjZWl2ZWQgYnkgcmVhY3Rpbmcgbm9kZS4NCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KDQpG
cm9tOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbT4gW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dDQpTZW50OiBtYXJ0ZXMsIDEx
IGRlIGZlYnJlcm8gZGUgMjAxNCAxMTozNg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1l
QGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkF0IGxlYXN0LCBpdCBpcyBu
b3QgInRoZSBvbmx5IHN1cmUgd2F5Ii4NCkZvciBpbnN0YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdl
cyBwYXJ0IG9mIHRoZSBzYW1lIHNlc3Npb24gKG9yIHBzZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNv
IGJlIHVzZWQgYXMgaW5kaWNhdGlvbiBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRoYXQgdGhlIE9M
UiBoYXMgYmVlbiByZWNlaXZlZCBieSB0aGUgcmVhY3Rpbmcgbm9kZSAoYmVzaWRlcyB0aGUgcmVj
ZXB0aW9uIG9mIHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgaW4gdGhlIHJlcXVlc3QpLg0KSXQg
aXMgd2h5IEkgd2FzIHNheWluZyB0aGF0IHRoaXMgY2FuIGJlIGZpeGVkIHBlciBhcHBsaWNhdGlv
bi9zeXN0ZW0uDQoNCkxpb25lbA0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmddIERlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNCkVudm95w6kgOiBtYXJk
aSAxMSBmw6l2cmllciAyMDE0IDExOjMxDQrDgCA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVA
aWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQpGaW5lIE5pcmF2LCBJIGFncmVlIHRoaXMgaXMgaW1wbGVtZW50YXRp
b24gc3BlY2lmaWMuDQpNeSBpbnRlbnRpb24gaXMgdGhhdCBhbnkgcmVhZGVyIHJlYWxpemVzIHdo
YXQgdGhpcyBrbm93bGVkZ2UgaW4gdGhlIHNlcnZlciBpbXBsaWVzIHdoZW4gd2UgdGFsayBhYm91
dCBhZ2VudHMgaW4gdGhlIHBhdGguIFRoaXMgaXMgd2h5IEkgdGhpbmsgdGhpcyBub3RlIGlzIGhl
bHBmdWwuDQoNClJlZ2FyZHMNCi9NQ3J1eg0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBb
bWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUg
MjAxNCAxMToyNg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0
bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgZG8gbm90IGFncmVlIHJlZ2FyZGluZyB0aGUgY29t
cGxleGl0eSBzaW5jZSBpdCBpcyBoaWdobHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpMZXRz
IG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24uDQoNClJlZ2Fy
ZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBUdWVzZGF5LCBGZWJydWFy
eSAxMSwgMjAxNCAzOjU0IFBNDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9y
Zz4NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQpIZWxsbywNCg0KSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gaGlnaGxpZ2h0
IGNvbXBsZXhpdHkgZm9yIHRoZSBzZXJ2ZXIgdG8gIOKAnGd1YXJhbnRlZSB0aGF0IHRoZSByZWFj
dGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQu4oCdDQpJ
IHRoaW5rIHRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlbnRlbmNlIGFkZGVkIGJ5IFN0ZXZl
Lg0KDQpDaGVlcnMNCi9NQ3J1eg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNClNlbnQ6IG1hcnRlcywg
MTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIwDQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBTdGV2ZSBEb25vdmFuOyBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgYW0gYWxzbyBmaW5lIHdpdGgg
U3RldmUncyBwcm9wb3NlZCB3b3JkaW5nIHRvIHJlY29tbWVuZCB0aGUgaW5jbHVzaW9uIG9mIE9M
UiBidXQgdG8gbm90IG1hbmRhdGUgaXQuDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxv
d2luZyB0ZXh0LCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBhZGQgaXQuDQpOb3Rl
IC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8g
a25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0
IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFn
ZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KDQpJIHByZWZl
ciB0byByZW1vdmUgaXQgc2luY2UgSSBkbyBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KDQpS
ZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbT4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MTMg
UE0NClRvOiBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nDQoNCkknbSBmaW5lIHdpdGggYSByZWNvbW1lbmRhdGlvbi4NCg0KQnV0IEkgaGF2ZSBh
IGdlbmVyYWwgY29tbWVudDogd2hlbiBhIE1BWSBvciBldmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBk
b2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgTk9UIHVwIHRvIHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0
byBkbyBzb21ldGhpbmcuIEl0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxl
bWVudGF0aW9uIG9wdGlvbi4NCkZvciBpbnN0YW5jZSwgb3ZlciBhIGdpdmVuIGludGVyZmFjZSwg
dGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1h
aW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNvdWxkIGJlIGRlY2lkZWQgdG8gYWRkIHNv
bWUgb3ZlcmxvYWQgcmVsYXRlZCBpbmZvIGluIHN1Y2ggc3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdh
aW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0byBrbm93IGlmIGEgcmVtb3RlIG5vZGUg
aGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5zdGFuY2UuIEFuZCBpbiBzdWNoIGEgY2Fz
ZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGluY2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVz
c2FnZS4gSXQgaXMganVzdCBmb3IgaWxsdXN0cmF0aW9uLiBUaGUgcG9pbnQgaXMgdGhhdCB5b3Ug
bWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWln
aHQgbm90IGJlIHJlcXVpcmVkLg0KDQpJIGFncmVlIHRoYXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZl
cnkgYW5zd2VyIGlzIGZpbmXigKYgYnV0IGl0IHNob3VsZCBiZSBub3QgbWFuZGF0b3J5IGluIGFs
bCBjYXNlcyBJIHRoaW5rLiBTbyBPSyBmb3IgYSAiU0hPVUxEIiBvciAiUkVDT01NRU5ERUQiLg0K
DQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll
dGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAxMCBm
w6l2cmllciAyMDE0IDE3OjIxDQrDgCA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5v
cmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQpJIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pDQoN
Ckkgc3VnZ2VzdCB0aGF0IHdlIGhhdmUgd29yZGluZyBzYXlpbmcgdGhlIHJlY29tbWVuZGVkIGFw
cHJvYWNoIGlzIHRvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbGwgcmVzcG9uc2Ug
bWVzc2FnZXMgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBieSBNYXJpYSBDcnV6Lg0KDQpJIGFsc28g
c3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0
aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQg
YW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fp
bi4gIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBpbmNsdWRpbmcgYW55dGhpbmcgYWJvdXQgaG93
IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyBidXQgd2Ugc2hvdWxkIGluY2x1ZGUgd29yZGluZyBh
Ym91dCBuZXR3b3JrcyBhcmNoaXRlY3R1cmVzIHRoYXQgbWFrZSBpdCBkaWZmaWN1bHQgdG8ga25v
dy4gIFRoZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBz
dXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuDQoNCldlIGFsc28gbmVlZCB0byBt
YWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBi
eSBOaXJhdidzIHByb3Bvc2FsLg0KDQpJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUg
d29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBNYXJpYSBDcnV6J3MgcmVhc29u
cyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHdheXMgaW5j
bHVkZWQuDQoNCi0tLS0tDQoNCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwg
cmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVj
b21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBp
biBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCk5vdGUgLSB0
aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlu
IGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1v
cmUgZWZmaWNpZW50LiAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBi
eSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0
aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSBy
ZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBh
bHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0KDQpOb3RlIC0gdGhlIG9u
bHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0
IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4g
dGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdl
ZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KT24gMi8xMC8xNCAzOjUyIEFN
LCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZToNCg0KSGVsbG8gTmlyYXYsDQoNCg0KDQpBbnkg
c29sdXRpb24gc2hvdWxkIGJhbGFuY2UgZGlmZmVyZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291
bGQgYmUgZGlzY3Vzc2VkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdl
IG5lZWQgdG8gYXNzdXJlIHRoZSBtZWNoYW5pc20gd2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGlu
ZyB2YWxpZCBPTFIgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCg0KDQpZb3VyIHByb3Bvc2VkIHRleHQN
Cg0KIiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGlu
ZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJv
dmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVk
ZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1T
dXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KDQoNCg0KSWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdh
cmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRo
ZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2UgaXQgaXMgYSAibWF5IikgdG8g
ZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hh
bmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQg
YnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRv
IG5vdGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQs
IGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQg
aXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcg
b24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4NCg0KVGhlbiwgb24gb25lIGhh
bmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxp
ZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBh
Z2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQgIm1heSIpIHRoZW4gb25lIG9yIG11bHRpcGxlIHJl
YWN0aW5nIG5vZGVzIGRvIG5vdCBoYXZlIHRoZSByZXF1aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQg
bWl0aWdhdGlvbiB3aWxsIG5vdCB3b3JrLg0KDQoNCg0KVGhlcmVmb3JlLCBpbiBteSBvcGluaW9u
LCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8g
cHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMuDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6
DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAo
bnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBm
ZWJyZXJvIGRlIDIwMTQgMTA6NDINCg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkJ1dCBNYXJpYS1DcnV6
LA0KDQoNCg0KSG93IGNhbiB3ZSBzYXkgdGhhdCAiaW5jbHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRo
ZSBhbnN3ZXIgbWVzc2FnZXMgaXMgc2ltcGxlIGFuZCBlZmZpY2llbnQ/Ig0KDQpJdCBpcyBzaW1w
bGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuDQoNCg0KDQpBIHNsaWdodGx5IGRpZmZlcmVu
dCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVhcmxpZXIgaXMsIFdoZW4gdGhlIHJlcG9y
dGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQgdGhhdCBuZWVkcyB0byBiZSBwcm92
aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5nIHRoZSBlYXJsaWVyIHByb3ZpZGVk
IG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhlIG92ZXJsb2FkIHJlcG9ydCBmb3Ig
dGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRv
IHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRz
IHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIg
Y2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBv
dmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwg
dGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0
byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoN
ClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K
RnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1h
cmlhIENydXogQmFydG9sb21lDQoNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMzow
MyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVj
dDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN
Cg0KDQpOaXJhdiwgYWxsLA0KDQoNCg0KSSB0aGluayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3Vy
YXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3Np
YmxlLg0KDQpJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBhcyBhIHB1cmUgIm1heSIsIGJ1dCBs
ZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3VyZSByZWFjdGluZyBu
b2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVj
aGFuaXNtIHRvIHdvcmsuDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFp
bHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIw
MTQgMTA6MTINCg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0
bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk1hcmlhLUNydXosDQoNCg0KDQpJIGZ1bGx5
IGFncmVlIHdpdGggeW91IG9uICJzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBp
bXBvcnRhbnQgYWR2YW50YWdlcyIuDQoNCkFuZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50
IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBteSBpbnRlbnRpb24uDQoNCkJ1dCB0aGUgbWFpbiBxdWVz
dGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBs
ZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcg
cmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPw0KDQoNCg0KTW9zdCBwcm9i
YWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Ygb3ZlcmxvYWQgY29udHJvbCB3
aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzLg0KDQpCdXQgYXQgdGhl
IHNhbWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGlj
aCBjYW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBz
ZW5kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlz
IHdoZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3Ry
aWN0aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0K
DQoNClRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRp
b24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQg
b2YgdmlldykuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KDQpTZW50OiBGcmlkYXksIEZlYnJ1
YXJ5IDA3LCAyMDE0IDg6NTcgUE0NCg0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0
Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQoNCg0KSGVsbG8gVWxyaWNoLCBOaXJhdiwNCg0KDQoNCkkgYWdyZWUg
d2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBwcm92aWRlZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZ
LCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNlcnZlciBzZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dl
cnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVkuDQoNCg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgY3Jp
dGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVp
cmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdlOg0KDQphKSB0aGUgcmVwb3J0aW5nIG5v
ZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVz
dCBPTFINCg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRv
ZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9k
ZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoN
Cg0KDQpSZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJl
Y2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUg
dGhpcyBrbm93bGVkZ2U/DQoNClRha2UgaW50byBhY2NvdW50IGFzIHdlbGwgdGhhdCBhICJyZWFj
dGluZyIgbm9kZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAoaW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2
aWNlIHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNs
aWVudCkgIGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBT
ZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFj
dGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2Vz
IG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUg
Y2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC4NCg0KDQoNClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5
IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50
IGFkdmFudGFnZXM6DQoNCi0gc3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24g
b3Igc2Vzc2lvbikgaXMgc2ltcGxlciwNCg0KLSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8g
ZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFjdGluZyBub2Rl
DQoNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0
aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIg
aXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuDQoNCi0gc2VuZGluZyBhbiBhZGRpdGlv
bmFsIEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCBy
ZXF1aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLg0KDQogIEluIGZhY3Qs
IGluIGFuIG92ZXJsb2FkIHNpdHVhdGlvbiwgdGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXgg
aXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9k
ZXMsDQoNCiAgYW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJp
YXRlIGFjdGlvbnMNCg0KLSBtb3JlIHJvYnVzdCBzb2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRl
ciBmb3IgYWxsIHRoZSBjaGVja3Mgb24gdGhlIG5lZWQgdG8gc2VuZCBpbmZvcm1hdGlvbiwgIGZv
ciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlzIGxvc3QsICDigKYNCg0KDQoN
Cg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKQ0KDQpTZW50OiB2aWVybmVzLCAw
NyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTkNCg0KVG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90
KTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFu
Z2UuY29tPjsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0
Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsDQoNCg0KDQpJJ20gYWZyYWlkIHlvdXIgcHJvcG9z
ZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24uDQoNCg0KDQoid2hlbiBpdCB3
YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uIiB0cmFuc2xhdGVz
IHRvICIuLi5pdCBtYXkgaW5jbHVkZS4uLiIuDQoNCg0KDQoiaW4gb3RoZXIgY2FzZXMiIGluIHRo
ZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gIndoZW4gaXQgZG9lcyBub3Qgd2FudCB0byBw
cm92aWRlL3VwZGF0ZS4uLiINCg0KDQoNCg0KDQpXZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6
DQoNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhh
cyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0KDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMg
bm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93
cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4
cGlyZQ0KDQpjKSBvdGhlcndpc2UNCg0KDQoNCmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2Rl
IG1heSBvciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBu
b2RlIG1heSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0
ZXN0IE9MUiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9M
UiBpbiB0aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVy
IHRoaXMgaXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKQ0KDQoNCg0KVWxyaWNoDQoNCg0KDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fs
b3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5
IDA2LCAyMDE0IDQ6NDkgUE0NCg0KVG86IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7
IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbT47IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYu
b3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KDQoNClVscmljaCwNCg0KDQoNCkl0IHNlZW1zIHdlIGFsbCBhcmUgb24g
c2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJvcG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3Qg
dGhlIGJlc3QuDQoNCkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLg0KDQoNCg0KV2hlbiB0aGUgcmVw
b3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRz
IHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgdG93YXJkcyBh
IHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8g
dGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMg
dGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBj
YXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92
ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0
aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRv
IHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0K
UmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpG
cm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhl
QG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNDQoN
ClRvOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9y
YW5nZS5jb20+OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVA
aWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsIExpb25l
bCwNCg0KDQoNCkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9s
YXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmlu
Y2lwbGUgMic6DQoNCg0KDQoyJy4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhl
ciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiBy
ZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMg
Z290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29udHJvbCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0
ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9u
IG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24g
ZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsg
b3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2Rl
IChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xS
IGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLg0KDQoNCg0KSSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15
b3Utd2FudCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2Ug
YWxsb3cgdGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdo
aWNoIGFyZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQg
c3RhdHVzLCB3aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0KDQoNClVscmljaA0KDQoNCg0KDQoNCg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+IFttYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQg
MTA6MjAgQU0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04g
LSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGlt
ZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQoNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt
LS0tLQ0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh
cnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nDqSA6IGpldWRpIDYgZsOpdnJpZXIgMjAx
NCAxMDowOCDDgCA6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBE
b25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPiBPYmpldCA6IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KVWxy
aWNoLA0KDQoNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24g
cmVwb3J0aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRo
ZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1V
U1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVk
IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQoNClRoZSByZXBvcnRpbmcgbm9kZSBtYXkg
c2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVk
IE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxp
bmcgdGhlIHRyYWZmaWMuDQoNCg0KDQpbTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMg
bm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBp
biB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8g
aW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRp
b24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1
bmRlcnN0YW5kaW5nLg0KDQoNCg0KQXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBp
cyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBzdG9wIHRocm90
dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIEluIG90aGVyIHdv
cmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0
aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0
b3dhcmRzIGl0Lg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNh
c2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3Zl
cmxvYWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBp
cyBubyBuZWVkIGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8g
b3ZlcmxvYWQgY29uZGl0aW9uLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVzdCBvZiB0aGUg
cHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1lLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoN
Cg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
DQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndp
ZWhlQG5zbi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBN
DQoNClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0
Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt
ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KQWN0dWFsbHkgd2Ugc2Vl
bSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxlczoNCg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5v
IGNoYW5nZSINCg0KMi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVy
bG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25z
ZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQ
IGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRo
ZSBsYXRlc3QgT0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1
Y3Rpb24gb3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5l
LiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdo
ZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMg
dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4N
Cg0KDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uDQoNCg0KDQpVbHJpY2gNCg0KDQoNCkZy
b206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQg
U3RldmUgRG9ub3Zhbg0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUg
UE0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1l
QGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkFncmVlZC4gIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBh
biBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0
YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS4gIElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2
ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0
aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9h
ZCByZXBvcnQuICBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9y
dCB0aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3Zl
cmxvYWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS4NCg0KDQoNClN0ZXZlDQoNCk9uIDIvNS8xNCA5
OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToNCg0KSSBhZ3JlZSB3aXRoIFN0ZXZl
IGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQg
YXMgbm90IG92ZXJsb2FkZWQ/Ig0KDQoNCg0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGlt
ZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0
aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5n
LiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8g
d2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9u
IHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24g
YW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29s
IHBvaW50IG9mIHZpZXcuDQoNCg0KDQpTbyBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91
bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5n
IG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBv
bGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4g
dGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQoN
CkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0
aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rp
bmcgbm9kZS4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KRnJvbTogRGlNRSBbbWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NCg0K
U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNDQoNClRvOiBkaW1lQGll
dGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCmlubGluZQ0KDQpPbiAy
LzUvMTQgNzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCg0K
T2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBP
Qy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVl
c3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChl
dmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS4NCg0KU1JEPiBXaHkgaW4g
ZXZlcnkgYW5zd2VyIG1lc3NhZ2U/ICBTaG91bGRuJ3QgbGFjayBvZiBhbiBPTFIgYmUgaW50ZXJw
cmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KDQoNCg0KDQoNCg0KDQpPdGhlciBjcml0ZXJp
YSBsaWtlIFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci4NCg0KU1JEPiBSZXF1
aXJpbmcgYW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJy
ZWFrIFJFUTEzLCBidXQgcmVxdWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBh
biBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNv
IHN1YnN0YW50aWFsIGFkZGl0aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUg
dGhhbiBpbnNlcnRpbmcgT0xScy4NCg0KDQoNCg0KDQoNCg0KDQoNCkZvciBteSBjbGFyaWZpY2F0
aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHBy
b2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55
d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGlu
IG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhl
IHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/DQoNClNSRD4g
VGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5z
YWxvdCkNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNDQoNClRv
OiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bT47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSSBz
aGFyZSB0aGUgc2FtZSBvcGluaW9uIGFzIExpb25lbC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2
Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPg0KDQpTZW50OiBUdWVzZGF5LCBG
ZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1l
QGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNl
cm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4g
ZXZlcnkgYW5zd2VyLg0KDQpTbyB0aGUgb3B0aW9ucyB3b3VsZCBiZToNCg0KMS0gT0MtT0xSIEFW
UCBpbiBldmVyeSBhbnN3ZXINCg0KMi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJl
bnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVk
Lg0KDQoNCg0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2Vl
bXMgdGhlIGJlc3QgYXBwcm9hY2guDQoNCg0KDQpMaW9uZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBk
J29yaWdpbmUtLS0tLQ0KDQpEZSA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGlt
ZUB0cmFjLnRvb2xzLmlldGYub3JnXQ0KDQpFbnZvecOpIDogbWFyZGkgNCBmw6l2cmllciAyMDE0
IDA5OjQ5DQoNCsOAIDogTU9SQU5EIExpb25lbCBJTVQvT0xODQoNCkNjIDogZGltZUBpZXRmLm9y
ZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KT2JqZXQgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcNCg0KDQoNCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGlu
ZyBET0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQoNCiAo
VGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAo
d2hpY2ggd2FzDQoNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQ
IGluZGljYXRlcyB0aGF0IGN1cnJlbnRseSBubyAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuICBS
ZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRl
ciB0byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3Rp
bmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLg0KDQogQWJzZW5jZSBvZiB0aGlz
IGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVw
b3J0aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJl
cG9ydGluZyBET0lDICBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBE
T0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nICB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdh
cmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCg0KIFRoZSBmZWVkYmFjayBtZWNoYW5p
c20gaW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDICBl
bmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5
IHRoZSByZWFjdGluZyAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbiku
DQoNCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4
IGZyb20gUkZDIDcwNjguDQoNCiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0
aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvICBiZSB1c2VkIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQoNCg0KDQoNCg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGlu
ZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0K
Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m
b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk
b25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0
aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl
IHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll
Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl
cyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl
IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoN
ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7
IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh
dXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90
IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig
ZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYu
b3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlN
RUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRp
TUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlz
dA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNz
YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv
bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0K
cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u
IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln
bmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj
ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz
IGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg
Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoN
Cg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50
aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh
dzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo
b3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp
cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl
ZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2Fn
ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z
IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBh
cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT
aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h
bGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz
IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk
J2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl
IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoN
ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7
DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy
cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k
IGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg
bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg
b3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2Ug
ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj
b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMg
ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg
dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl
cg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq
b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh
bHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt
ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpU
aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg
b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K
DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg
YXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp
dHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v
dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y
IGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw
YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OlRpbWVzOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s
b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz
aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwg
Q2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6
YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBD
YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpi
bGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1h
dMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj
azt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1
bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4
dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29s
b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ
Y29sb3I6YmxhY2s7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBk
aXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQi
Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNt
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxs
b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u
dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuQmFsbG9v
blRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNvLXN0eWxlLW5hbWU6
IkJhbGxvb24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT
dHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMyDQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1
cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaQ0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5PbiB0aGlzIHRvcGljLCBteSB2aWV3IGlzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgc2hhbGwg
Jm5ic3A7cmVjZWl2ZSDigJxlbm91Z2jigJ0gT0xScyBwZXIgcGVyaW9kIG9mIHRpbWUgdG8gZW5z
dXJlIHRoZSBlZmZpY2llbmN5IG9mIHRoZSB0cmFmZmljICZuYnNwO3JlZHVjdGlvbiBtZWNoYW5p
c20NCiAuIEEgd2F5IHRvIGFjaGlldmUgJm5ic3A7dGhlIOKAnGVub3VnaOKAnSBpcyB0byBoYXZl
IGFuIE9MUiBpbiBhbGwgJm5ic3A7YW5zd2VyICZuYnNwO21lc3NhZ2VzIGFzIHByb3Bvc2VkIGFu
ZCB0aGlzIGNhbiB0aGUgcmVjb21tZW5kZWQgd2F5LiBOb3cgYXMgTmlyYXYgc2FpZCwgdGhlcmUg
bWF5IGJlIHByb3RvY29sIGRlc2lnbiB0aGF0IHdpbGwgYmVoYXZlIGRpZmZlcmVudGx5IGFuZCBz
ZW5kIOKAnGVub3VnaOKAnSBPTFJzICZuYnNwO2J1dCBub3QgaW4gYWxsIG1lc3NhZ2VzLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+QXMgYWxzbyBOaXJhdiBub3RlZCwgJm5ic3A7SSBkbyBub3Qgd2VsbCBzZWUgdGhlIG5l
ZWQgdG8gd3JpdGUgYWRkaXRpb25hbCBub3RlcyBhcyBtYW55IHNpdHVhdGlvbnMgY2FuIG9jY3Vy
IGFuZCAmbmJzcDthcmUgbm90IGxpbWl0ZWQgdG8gdGhlIGV4YW1wbGUgb2YgdGhlIHJlYWN0aW5n
DQogJm5ic3A7bm9kZSAmbmJzcDtkaXNjYXJkaW5nIE9MUnMuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2Fy
ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkpKYWNxdWVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bh
bj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl
eHQiPiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBk
ZTwvYj4gbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+
IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTY6MzU8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IE1hcmlh
IENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBS
ZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXQgbGVhc3QsIGl0IGlzIGNvcnJlY3QhDQo8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2Nv
bG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp
bmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRl
IGxhIHBhcnQgZGU8L2I+IE1hcmlhIENydXogQmFydG9sb21lPGJyPg0KPGI+RW52b3nDqSZuYnNw
Ozo8L2I+IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTU6MDA8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+
IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxi
Pk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+TGlvbmVsLCBOaXJhdiwgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5YmUgdGhlIG5vdGUg
Y291bGQgYmUgbW9kaWZpZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90
OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KTm90ZSDigJN0aGUgcmVhY3Rpbmcgbm9kZSBjb3Vs
ZCBiZSBhbnkgYWdlbnQgaW4gdGhlIHBhdGgsIGFuZCB0aGF0IGluIHNvbWUgZXJyb3Igc2l0dWF0
aW9ucyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWRkZWQgdGhlIGNhc2Ug
T0xSIGNvdWxkIGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlcywgc2luY2UgaXQgaGlnaGxp
Z2h0cyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmVyIHdpbGwgbm90IGtub3cgd2hldGhlciBv
ciBub3QgYSB2YWxpZCBPTFIgaXMgcmVjZWl2ZWQNCiBieSByZWFjdGluZyBub2RlLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9NQ3J1ejxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj
bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4NCjxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9y
YW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1h
aWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPm1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAy
MDE0IDExOjM2PGJyPg0KPGI+VG86PC9iPiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0i
bWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8
L2I+IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCwgaXQgaXMgbm90ICZxdW90
O3RoZSBvbmx5IHN1cmUgd2F5JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5G
b3IgaW5zdGFuY2UsIHN1YnNlcXVlbnQgbWVzc2FnZXMgcGFydCBvZiB0aGUgc2FtZSBzZXNzaW9u
IChvciBwc2V1ZG8tc2Vzc2lvbikgY291bGQgYWxzbyBiZSB1c2VkIGFzIGluZGljYXRpb24gZm9y
IHRoZSByZXBvcnRpbmcgbm9kZSB0aGF0IHRoZSBPTFIgaGFzIGJlZW4NCiByZWNlaXZlZCBieSB0
aGUgcmVhY3Rpbmcgbm9kZSAoYmVzaWRlcyB0aGUgcmVjZXB0aW9uIG9mIHRoZSBPQy1TdXBwb3J0
ZWQtRmVhdHVyZXMgaW4gdGhlIHJlcXVlc3QpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5JdCBpcyB3aHkgSSB3YXMgc2F5aW5nIHRoYXQgdGhpcyBjYW4gYmUgZml4ZWQgcGVyIGFwcGxp
Y2F0aW9uL3N5c3RlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1F
IFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IE1hcmlhIENydXogQmFydG9s
b21lPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTE6
MzE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5k
aW1lQGlldGYub3JnPC9hPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmluZSBOaXJhdiwgSSBhZ3JlZSB0
aGlzIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5NeSBpbnRlbnRpb24gaXMgdGhhdCBhbnkgcmVhZGVyIHJlYWxpemVzIHdoYXQgdGhpcyBr
bm93bGVkZ2UgaW4gdGhlIHNlcnZlciBpbXBsaWVzIHdoZW4gd2UgdGFsayBhYm91dCBhZ2VudHMg
aW4gdGhlIHBhdGguIFRoaXMgaXMgd2h5IEkgdGhpbmsgdGhpcyBub3RlIGlzIGhlbHBmdWwuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9NQ3J1ejxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBOaXJhdiBT
YWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpu
c2Fsb3RAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0ZXMsIDExIGRlIGZl
YnJlcm8gZGUgMjAxNCAxMToyNjxicj4NCjxiPlRvOjwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7
IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBkbyBub3QgYWdyZWUg
cmVnYXJkaW5nIHRoZSBjb21wbGV4aXR5IHNpbmNlIGl0IGlzIGhpZ2hseSBpbXBsZW1lbnRhdGlv
biBzcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TGV0cyBub3QgbWFrZSBh
bnkgYXNzdW1wdGlvbiBpbiB0aGUgcHJvdG9jb2wgZGVzaWduLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVnYXJkcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5NYXJpYSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNlbnQ6PC9i
PiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBo
cmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0
aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gaGlnaGxpZ2h0IGNvbXBsZXhpdHkgZm9yIHRoZSBzZXJ2
ZXIgdG8gJm5ic3A74oCcPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmd1YXJhbnRlZSB0aGF0IHRoZSBy
ZWFjdGluZyBub2RlDQogYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnQ0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhpcyBpcyB0aGUgcHVycG9zZSBv
ZiB0aGUgc2VudGVuY2UgYWRkZWQgYnkgU3RldmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnM8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5OaXJhdiBTYWxvdCAobnNhbG90KTxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0ZXMs
IDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyMDxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9h
PjsgU3RldmUgRG9ub3ZhbjsNCjxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGll
dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2
MSI+SSBhbSBhbHNvIGZpbmUgd2l0aCBTdGV2ZSdzIHByb3Bvc2VkIHdvcmRpbmcgdG8gcmVjb21t
ZW5kIHRoZSBpbmNsdXNpb24gb2YgT0xSIGJ1dCB0byBub3QgbWFuZGF0ZSBpdC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEi
PkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBhYnNvbHV0
ZWx5IG5lY2Vzc2FyeSB0byBhZGQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l
cyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Tm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRo
b3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUg
aGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2Rl
IGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuDQogdGhlIGNsaWVudCBh
bmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzI0NDA2MSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIHByZWZlciB0byByZW1vdmUgaXQgc2luY2UgSSBk
byBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQw
NjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2
MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC
ZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJy
dWFyeSAxMCwgMjAxNCAxMDoxMyBQTTxicj4NCjxiPlRvOjwvYj4gU3RldmUgRG9ub3ZhbjsgPGEg
aHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JJ20gZmluZSB3aXRoIGEgcmVj
b21tZW5kYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBoYXZlIGEgZ2VuZXJhbCBjb21tZW50OiB3aGVu
IGEgTUFZIG9yIGV2ZW4gYSBTSE9VTEQgYXBwbHksIGl0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBp
cyBOT1QgdXAgdG8gdGhlIG5vZGUgdG8gZG8gb3Igbm90IHRvIGRvIHNvbWV0aGluZy4gSXQgZG9l
cyBub3QgbWVhbg0KIHRoYXQgaXQgaXMgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRpb24uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgb3ZlciBhIGdpdmVuIGlu
dGVyZmFjZSwgdGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5IHRoYXQgc29tZSBzdGF0
ZXMgYXJlIG1haW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNvdWxkIGJlIGRlY2lkZWQg
dG8gYWRkIHNvbWUgb3ZlcmxvYWQNCiByZWxhdGVkIGluZm8gaW4gc3VjaCBzdGF0ZXMuIEZvciBp
bnN0YW5jZSBhZ2FpbiwgdGhlIG5vZGUgY2FuIHVzZSB0aGlzIHN0YXRlIHRvIGtub3cgaWYgYSBy
ZW1vdGUgbm9kZSBoYXZlIGJlZW4gbm90aWZpZWQgb3Igbm90IGZvciBpbnN0YW5jZS4gQW5kIGlu
IHN1Y2ggYSBjYXNlLCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaW5jbHVkZSBhbiBPTFIg
aW4gZWFjaCBtZXNzYWdlLiBJdCBpcyBqdXN0IGZvciBpbGx1c3RyYXRpb24uIFRoZSBwb2ludA0K
IGlzIHRoYXQgeW91IG1heSBoYXZlIHNvbWUgY2FzZXMgZm9yIHdoaWNoIHRoZSBPTFIgaW4gZXZl
cnkgYW5zd2VyIG1pZ2h0IG5vdCBiZSByZXF1aXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBo
YXZpbmcgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgaXMgZmluZeKApiBidXQgaXQgc2hvdWxkIGJl
IG5vdCBtYW5kYXRvcnkgaW4gYWxsIGNhc2VzIEkgdGhpbmsuIFNvIE9LIGZvciBhICZxdW90O1NI
T1VMRCZxdW90OyBvciAmcXVvdDtSRUNPTU1FTkRFRCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5MaW9uZWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0
IGRlPC9iPiBTdGV2ZSBEb25vdmFuPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGx1bmRpIDEw
IGbDqXZyaWVyIDIwMTQgMTc6MjE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPk9iajwvYj48L3NwYW4+
PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi
PmV0Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOndpbmRvd3RleHQiPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8NCiBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp
dmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48c3BhbiBsYW5nPSJGUiI+SSBhZ3JlZSB3aXRoIGJvdGggTWFyaWEgQ3J1eiBhbmQgTmlyYXYu
IDotKTxicj4NCjxicj4NCkkgc3VnZ2VzdCB0aGF0IHdlIGhhdmUgd29yZGluZyBzYXlpbmcgdGhl
IHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIHRvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBp
biBhbGwgcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBieSBNYXJpYSBD
cnV6LiZuYnNwOw0KPGJyPg0KPGJyPg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBpbmNsdWRlIE5p
cmF2J3MgcHJvcG9zYWwgdGhhdCBpZiBhIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgYSByZWFj
dGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0
IG1heSBjaG9vc2UgdG8gbm90IHNlbmQgaXQgYWdhaW4uJm5ic3A7IEkgZG9uJ3QgdGhpbmsgd2Ug
bmVlZCB0byBpbmNsdWRpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRoZSByZXBvcnRpbmcgbm9kZSBr
bm93cw0KIGJ1dCB3ZSBzaG91bGQgaW5jbHVkZSB3b3JkaW5nIGFib3V0IG5ldHdvcmtzIGFyY2hp
dGVjdHVyZXMgdGhhdCBtYWtlIGl0IGRpZmZpY3VsdCB0byBrbm93LiZuYnNwOyBUaGUgY2FzZSBv
ZiBhZ2VudHMgYWN0aW5nIGFzIHJlYWN0aW5nIG5vZGVzIGZvciBub24gc3VwcG9ydGluZyBjbGll
bnRzIGJlaW5nIG9uZSBleGFtcGxlLjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5X
ZSBhbHNvIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlz
IG5vdCBwcmVjbHVkZWQgYnkgTmlyYXYncyBwcm9wb3NhbC48YnI+DQo8YnI+DQpJIHByb3Bvc2Ug
dGhlIGZvbGxvd2luZyBub3JtYXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRl
ZCBieSBNYXJpYSBDcnV6J3MgcmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJs
b2FkIHJlcG9ydCBpcyBhbHdheXMgaW5jbHVkZWQuPGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+
DQpBIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJl
Y2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuPGJyPg0KPGJyPg0KSXQgaXMgcmVjb21tZW5kZWQg
dGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5z
d2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuJm5ic3A7DQo8YnI+DQo8YnI+DQpO
b3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJl
cG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhh
dCBpcyBtb3JlIGVmZmljaWVudC4mbmJzcDsgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3Qg
YmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMu
PGJyPg0KPGJyPg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92
ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0
IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBv
cnQuPGJyPg0KPGJyPg0KTm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0
YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVk
IGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50
IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRp
bmcgbm9kZS48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+T24gMi8xMC8xNCAzOjUy
IEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhlbGxvIE5pcmF2LDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFueSBzb2x1dGlvbiBzaG91
bGQgYmFsYW5jZSBkaWZmZXJlbnQgZmFjdG9ycywgZWZmaWNpZW5jeSBjb3VsZCBiZSBkaXNjdXNz
ZWQgZnJvbSBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLCBidXQgZmlyc3Qgd2UgbmVlZCB0byBhc3N1
cmUgdGhlIG1lY2hhbmlzbSB3ZSBhcmUgZGVmaW5pbmcgaXMgcHJvdmlkaW5nIHZhbGlkIE9MUiB0
byByZWFjdGluZyBub2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5Zb3VyIHByb3Bvc2VkIHRleHQmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7IEFkZGl0aW9uYWxseSwgaW4gb3Ro
ZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRo
ZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9k
ZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNl
LCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4mcXVv
dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB0
aGUgcmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3aGV0aGVyIG9yIG5vdCBvdmVybG9hZCBy
ZXBvcnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIGFuZCBpdCBkZWNpZGVzIChz
aW5jZSBpdCBpcyBhICZxdW90O21heSZxdW90OykgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2Fp
biwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNh
c2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRp
YWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAmcXVvdDtyZWFjdGlu
ZyBub2RlcyZxdW90OyBjb3VsZCBiZSBub3Qgb25seSB0aGUgY2xpZW50LCBidXQgQU5ZIGFnZW50
IHVzZWQgZm9yIHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4gdGhlIGFnZW50IGlzIHByb3ZpZGluZyBz
ZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlzIHJlYWN0aW5nIG9uIGJlaGFsZiBvZiBh
IG5vbi1zdXBwb3J0aW5nIGNsaWVudCkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPlRoZW4sIG9uIG9uZSBoYW5kIGl0IGlzIG5vdCBzaW1wbGUgdG8g
a25vdyB3aGVuIHJlYWN0aW5nIG5vZGVzIGhhdmUgdmFsaWQgT0xSIGluZm8gKGFzIGV4cGxhaW5l
ZCBiZWxvdyksIGJ1dCBpZiBPTFIgaXMgbm90IHNlbnQgYWdhaW4gKGFzIHBlciB5b3VyIHByb3Bv
c2VkICZxdW90O21heSZxdW90OykgdGhlbiBvbmUgb3IgbXVsdGlwbGUgcmVhY3Rpbmcgbm9kZXMg
ZG8gbm90IGhhdmUgdGhlIHJlcXVpcmVkIE9MUiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIHdp
bGwgbm90IHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+VGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3Zp
ZGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QmVzdCBy
ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0i
bWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl0gPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogbHVu
ZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo0MjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJl
Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QnV0IE1hcmlhLUNydXosPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG93IGNhbiB3ZSBzYXkg
dGhhdCAmcXVvdDtpbmNsdWRpbmcgdGhlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcyBp
cyBzaW1wbGUgYW5kIGVmZmljaWVudD8mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCBpcyBzaW1wbGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZp
Y2llbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkEgc2xpZ2h0bHkgZGlmZmVyZW50IHdvcmRpbmcgZnJvbSB3aGF0IEkgcHJvcG9zZWQgZWFybGll
ciBpcywgV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaGFzIGEgbmV3IG92ZXJsb2FkIHJlcG9ydCB0
aGF0IG5lZWRzIHRvIGJlIHByb3ZpZGVkIHRvIGEgcmVhY3Rpbmcgbm9kZSAoYnkgdXBkYXRpbmcg
dGhlIGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVwb3J0IG9yIGJ5IHByb3ZpZGluZyB0aGUg
b3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUgZmlyc3QgdGltZSksIGl0IHNoYWxsIGluY2x1ZGUgT0xS
IGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQt
RmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRk
aXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBp
cyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRv
IHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9M
UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0g
T24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAx
NCAzOjAzIFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6
IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LCBhbGws
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB0aGlu
ayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVm
ZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEg
cHVyZSAmcXVvdDttYXkmcXVvdDssIGJ1dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9u
IGRvZXMgbm90IGFzc3VyZSByZWFjdGluZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24s
IHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVjaGFuaXNtIHRvIHdvcmsuIDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QgcmVnYXJkczxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi9NQ3J1ejxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+RnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0bzpuc2Fsb3RA
Y2lzY28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogbHVuZXMsIDEwIGRlIGZlYnJl
cm8gZGUgMjAxNCAxMDoxMjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVA
aWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+TWFyaWEtQ3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGZ1bGx5IGFncmVlIHdpdGggeW91IG9uICZxdW90O3Nl
bmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzJnF1
b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFu
ZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBteSBp
bnRlbnRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFu
eSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5k
IGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNz
YWdlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1v
c3QgcHJvYmFibHksIHRoZSB2ZXJ5IGZpcnN0IGltcGxlbWVudGF0aW9uIG9mIG92ZXJsb2FkIGNv
bnRyb2wgd2lsbCBpbmNsdWRlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcy48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CdXQgYXQgdGhlIHNh
bWUgdGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBj
YW4gY29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5k
aW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdo
ZXJlIHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0
aW9ucyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIGFsc28gdGhlIHJlYXNvbiBJ
IHdhcyBzdWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVkZSBPTFIg
KGZyb20gdGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5G
cm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9s
b21lPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2Vu
dDogRnJpZGF5LCBGZWJydWFyeSAwNywgMjAxNCA4OjU3IFBNPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll
dGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPkhlbGxvIFVscmljaCwgTmlyYXYsPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBhZ3JlZSB3aXRoIFVscmljaCB0aGF0IHRo
ZSB0ZXh0IHByb3ZpZGVkIGJ5IE5pcmF2IGlzIGp1c3QgYSBNQVksIGFuZCB3aGV0aGVyIG9yIG5v
dCB0aGUgc2VydmVyIHNlbmRzIGFuIE9MUiBpbiBhbGwgYW5zd2VycyBzaGFsbCBub3QgYmUganVz
dCBhIE1BWS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5PbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4g
T0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdl
OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmEpIHRo
ZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5
IGdvdCB0aGUgbGF0ZXN0IE9MUjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5k
LiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Yykgb3RoZXJ3aXNlPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVwb3J0aW5nIG5vZGUg
bXVzdCBoYXZlIHNvbWUga25vd2xlZGdlIGFib3V0IE9MUiByZWNlcHRpb24vc3RhdHVzIGluIHJl
YWN0aW5nIG5vZGUuIEhvdyBkb2VzIHNlcnZlciBhY3F1aXJlIHRoaXMga25vd2xlZGdlPyA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UYWtlIGludG8g
YWNjb3VudCBhcyB3ZWxsIHRoYXQgYSAmcXVvdDtyZWFjdGluZyZxdW90OyBub2RlIG1heSBiZSBi
b3RoIGFuIEFnZW50IChpbiBjYXNlIGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8gYSByZWFsbSBvciBh
Y3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KSZuYnNwOyBhbmQgYSBD
bGllbnQuIEluIHRoZSBjYXNlIG9mIEFnZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3Qg
ZXZlbiBrbm93IGlmIHRoaXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBq
dXN0IHRyYW5zcGFyZW50bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBo
YXZlIGFueSBrbm93bGVkZ2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBm
aW5hbCBDbGllbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+VGhlcmVmb3JlLCBJIGRlZmluaXRlbHkgdGhpbmsgdGhhdCBzZW5kaW5nIE9MUiBpbiBB
TEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdlczo8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIHN0YXRlLWxlc3MgaW1wbGVtZW50
YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNlc3Npb24pIGlzIHNpbXBsZXIsPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSB0aGUgc2VydmVyIGRvZXMgbm90
IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFj
dGluZyBub2RlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+LSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gYm90aGVyIHdoZXRoZXIgYW4gcmVhY3Rp
bmcgbm9kZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBPTFIgb3Igd2hldGhlciB0aGlzIE9MUiBp
cyBzdGlsbCB2YWxpZCAoaGFzIG5vdCBleHBpcmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIHNlbmRpbmcgYW4gYWRkaXRpb25hbCBBVlAgaXMg
bm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29uIHdpdGggcmVxdWlyZWQgYWJv
dmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IEluIGZhY3QsIGluIGFuIG92ZXJsb2Fk
IHNpdHVhdGlvbiwgdGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZv
cm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsIDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBhbmQgdGhlIGxh
dHRlciBzaG91bGQgdGFrZSBjYXJlIHRvIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9ucyZuYnNwOyA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIG1vcmUg
cm9idXN0IHNvbHV0aW9uLCBhcyBubyBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhlIGNoZWNrcyBv
biB0aGUgbmVlZCB0byBzZW5kIGluZm9ybWF0aW9uLCZuYnNwOyBmb3Igc2l0dWF0aW9ucyB3aGVy
ZSBhbiBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCZuYnNwOyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4vTUNydXo8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlNlbnQ6IHZpZXJuZXMsIDA3IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo1OTxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBleHQgTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFu
Z2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBleHQgU3RldmUgRG9ub3Zhbjsg
PGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYsPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSdtIGFmcmFpZCB5b3VyIHBy
b3Bvc2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGUgaW50ZW50aW9uLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90O3doZW4gaXQgd2FudHMg
dG8gcHJvdmlkZS91cGRhdGUuLi4uaXQgc2hhbGwgaW5jbHVkZS4uLiZxdW90OyB0cmFuc2xhdGVz
IHRvICZxdW90Oy4uLml0IG1heSBpbmNsdWRlLi4uJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90O2luIG90aGVyIGNhc2VzJnF1b3Q7
IGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7d2hlbiBpdCBkb2VzIG5v
dCB3YW50IHRvIHByb3ZpZGUvdXBkYXRlLi4uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmEpIHRoZSBy
ZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdv
dCB0aGUgbGF0ZXN0IE9MUjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBk
b2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5v
ZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Yykgb3RoZXJ3aXNlPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aW4gY2FzZSBhKSB0aGUgcmVw
b3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFIgaW4gY2FzZSBiKSB0aGUg
cmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUgcmVhY3Rpbmcgbm9kZSB3
aXRoIHRoZSBsYXRlc3QgT0xSIGluIGNhc2UgYykgdGhlIHJlcG9ydGluZyBub2RlIE1VU1QgaW5j
bHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcgbm9kZSBkb2VzIG5vdCBr
bm93IHdoZXRoZXIgdGhpcyBpcyBhIHJlcGxheSBvciBhbiB1cGRhdGUpPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNoPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5G
cm9tOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgWzxhIGhyZWY9Im1haWx0bzpuc2Fsb3RAY2lz
Y28uY29tIj5tYWlsdG86bnNhbG90QGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2
LCAyMDE0IDQ6NDkgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5UbzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IDxhIGhyZWY9
Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bTwvYT47IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+
ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5VbHJpY2gsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+SXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2UgYnV0IHByb2JhYmx5IHRo
ZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ib3cgYWJvdXQgdGhlIGZvbGxvd2lu
Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XaGVu
IHRoZSByZXBvcnRpbmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQg
b3Igd2FudHMgdG8gdXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0
b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3Bv
bnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwg
dG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGlu
IG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBp
ZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5n
IG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNw
b25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJk
cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJh
di48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgWzxh
IGhyZWY9Im1haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbSI+bWFpbHRvOnVscmljaC53aWVoZUBu
c24uY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMzo1NyBQTTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBleHQgPGEgaHJlZj0i
bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PC9hPjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJt
YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdiwgTGlvbmVsLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgY2FuIHVuZGVyc3RhbmQgTmly
YXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRpbmcgUkVRMTApIGFuZCBob3AgaXQgaXMgYWRk
cmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lwbGUgMic6PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8g
bWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVy
biBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2Rl
IGFscmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24g
KGUuZy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFm
ZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVybG9hZCZxdW90
Oywgb3IgYW4gb2xkJm5ic3A7IGJ1dCBzb29uIGV4cGlyaW5nIE9MUiB3aGVuIHRoZSByZXBvcnRp
bmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCk7IG90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3Qg
YXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRl
ZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hp
Y2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGRvbid0IGFncmVlIHdpdGggTGlv
bmVscyBkby13aGF0LXlvdS13YW50IGFwcHJvYWNoLiBPdmVybG9hZCBjb250cm9sIHdpbGwgbm90
IHdvcmsgd2hlbiB3ZSBhbGxvdyB0aGUgcmVwb3J0aW5nIG5vZGUgbm90IHRvIHVwZGF0ZSByZWFj
dGluZyBub2Rlcywgd2hpY2ggYXJlIG5vdCAoc3VmZmljaWFudGx5KSBhd2FyZSBvZiB0aGUgY3Vy
cmVudCBvdmVybG9hZCBzdGF0dXMsIHdpdGggdXAgdG8gZGF0ZSBPTFJzLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVscmljaCZuYnNwOyA8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkZyb206IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
Ij5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+IFs8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1v
cmFuZEBvcmFuZ2UuY29tIj5tYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPl08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBUaHVy
c2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IFdpZWhl
LCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJt
YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EZSZuYnNw
OzogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxv
dCkgRW52b3nDqSZuYnNwOzogamV1ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4IMOAJm5ic3A7OiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgPGEgaHJl
Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+IE9iamV0Jm5ic3A7OiBS
ZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2gsPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBhbSBub3Qgc3Vy
ZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0aW5nIG5vZGUgJnF1b3Q7b3Ro
ZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChu
byBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGlu
IHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZl
YXR1cmUgQVZQLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBpbmNsdWRlIE9MUiBh
c3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4cGlyZSBhbmQgdGhl
IHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZmaWMuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W0xNXSBBZ3JlZS4gSW4g
b3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1l
Y2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3aGVuIHRoZSByZXBvcnRp
bmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyIG1heSBkZXBl
bmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVhc3Qs
IGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcyB3ZSBoYWQgZGlzY3Vzc2VkIGVhcmxpZXIsIHRo
ZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBleHBsaWNpdGx5IHN0b3Ag
dGhyb3R0bGluZyBhdCBlYWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4gSW4gb3Ro
ZXIgd29yZHMsIHRoZSByZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhlIG5hdHVyYWwgZXhwaXJ5
IG9mIHRoZSBPTFIgdG8gZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhlIHNpZ25hbGluZyB0cmFm
ZmljIHRvd2FyZHMgaXQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+W0xNXSBBZ3JlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPlRoZXJlIG1heSBiZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBs
b25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5j
bHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTE1dIEFncmVl
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVzdCBv
ZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1lLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbPGEgaHJlZj0ibWFpbHRv
OnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb208L2E+XTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFRo
dXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBT
YWxvdCAobnNhbG90KTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5v
cmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QWN0
dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxlczo8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xLiBMYWNrIG9mIE9MUiBtZWFucyAm
cXVvdDtubyBjaGFuZ2UmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4yLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92
ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3Bv
bnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBB
VlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3Qg
dGhlIGxhdGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJl
ZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAmcXVvdDtubyBvdmVybG9hZCZxdW90Oyk7IG90
aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAo
bm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBp
biByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5DYW4gcGVvcGxlIHBsZWFzZSBjb25maXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVscmljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC
ZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6
MzUgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5U
bzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5k
aW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkFncmVlZC4mbmJzcDsgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92ZXJsb2FkIHJl
cG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUgZm9yIHRoZSBo
b3N0IG9yIHJlYWxtLiZuYnNwOyBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3Zlcmxv
YWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1l
cyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0
LiZuYnNwOyBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0
aGVuIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3Zlcmxv
YWQgZm9yIHRoZSBob3N0IGFuZCByZWFsbS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdGV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAobnNhbG90
KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5JIGFncmVlIHdpdGggU3RldmUgZXhjZXB0IHRoZSBwYXJ0ICZxdW90O3Nob3VsZG7igJl0IGxh
Y2sgb2YgT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPyZxdW90OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldlIGhhZCBzb21lIGRp
c2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUg
dG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5z
d2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcg
d2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2Vu
ZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFs
IGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0
ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNo
b3VsZCBub3QgYWZmZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rp
bmcgbm9kZS4gVGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9u
IG9sZGVyIE9MUiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hl
biB0aGUgZXhwbGljaXQgT0xSIHdpdGggJnF1b3Q7MCZxdW90OyBvdmVybG9hZC1tZXRyaWMgaXMg
cmVjZWl2ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+SW4gbXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0
IHRoZSByZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFj
dGluZyBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25v
dmFuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2Vu
dDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1l
QGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPmlubGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPk9uIDIvNS8xNCA3OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04g
LSBERS9NdW5pY2gpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPk9rIHRoZW4gbGV0J3Mgc3RhdGUgdGhhdCByZXBvcnRpbmcgbm9kZXMgTVVT
VCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVz
cG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdoaWNoIGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZl
YXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxvYWQgcmVkdWN0aW9uIGlzIHJlcXVlc3RlZCkuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U1JEJmd0OyBX
aHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/Jm5ic3A7IFNob3VsZG4ndCBsYWNrIG9mIGFuIE9M
UiBiZSBpbnRlcnByZXRlZCBhcyBub3Qgb3ZlcmxvYWRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PdGhlciBjcml0ZXJpYSBsaWtlIFJFUTE4IG9y
IFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TUkQmZ3Q7IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBv
cnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJp
bmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sgZm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlzIGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25h
bCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZvciBteSBj
bGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVp
cmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJl
cGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGlu
ZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBh
bmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U1JEJmd0
OyBUaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIGV4dCBOaXJhdiBTYWxv
dCAobnNhbG90KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiA8YSBocmVmPSJtYWls
dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+
OyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHNoYXJlIHRoZSBzYW1l
IG9waW5pb24gYXMgTGlvbmVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJt
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
PC9hPl0gT24gQmVoYWxmIE9mIDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAx
NCA5OjA3IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VG86IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6
IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgdW5kZXJzdGFu
ZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBO
T1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TbyB0aGUgb3B0aW9ucyB3b3VsZCBiZTo8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xLSBPQy1PTFIg
QVZQIGluIGV2ZXJ5IGFuc3dlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBy
ZXF1ZXN0ICYjNDM7IE9DLU9MUiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0
aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgdGhlcmUg
aXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhlIGJlc3QgYXBwcm9h
Y2guPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TGlv
bmVsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0t
LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+RGUmbmJzcDs6IGRpbWUgaXNzdWUgdHJhY2tlciBbPGEgaHJlZj0i
bWFpbHRvOnRyYWMmIzQzO2RpbWVAdHJhYy50b29scy5pZXRmLm9yZyI+bWFpbHRvOnRyYWMmIzQz
O2RpbWVAdHJhYy50b29scy5pZXRmLm9yZzwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RW52b3nDqSZuYnNwOzogbWFyZGkgNCBmw6l2cmllciAy
MDE0IDA5OjQ5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+w4AmbmJzcDs6IE1PUkFORCBMaW9uZWwgSU1UL09MTjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNjJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86ZGlt
ZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PYmpldCZuYnNwOzogW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBJdCBoYXMgYmVlbiBwcm9w
b3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXMm
bmJzcDsgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0Jm5ic3A7IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBBVlAg
d291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29y
ZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IHN1cnZpdmVkKSBpcyBwZXJmb3JtZWQu
IEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5kaWNhdGVzIHRoYXQgY3VycmVudGx5IG5vJm5ic3A7IHRo
cm90dGxpbmcgaXMgcGVyZm9ybWVkLiZuYnNwOyBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5
IHVzZSB0aGlzJm5ic3A7IGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGRldGVjdCB3aGV0aGVyIHRo
ZXJlIGlzIGEgbmVlZCB0byB1cGRhdGUgdGhlJm5ic3A7IHJlYWN0aW5nIERPSUMgZW5kcG9pbnQg
d2l0aCB0aGUgbGF0ZXN0IE9MUi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4gQWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCBy
ZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSZuYnNwOyByZXBvcnRpbmcgbm9kZSB0byBzZW5kIE9D
LU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0aW5nIERPSUMmbmJzcDsgZW5k
cG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpcyBh
Y3R1YWxseSBkb2luZyZuYnNwOyB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0
bGluZy9ub3QgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4gVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBpbXByb3ZlcyByb2J1c3RuZXNz
IGFzIGl0IGFsbG93cyB0aGUgcmVwb3J0aW5nIERPSUMmbmJzcDsgZW5kcG9pbnQgdG8gZGV0ZWN0
IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmcmbmJz
cDsgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IFRoZSBmZWVkYmFjayBtZWNo
YW5pc20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJvbSBSRkMgNzA2OC48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gSW4gc3VtbWFyeSBp
dCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCB0byZuYnNwOyBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EaU1FIG1haWxpbmcg
bGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxh
IGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2
ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn
aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj
b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy
IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp
cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1
ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg
cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs
c2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp
ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi
eSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0
aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l
c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFuayB5b3Uu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1h
aWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBt
YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVA
aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpEaU1F
QGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
aW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50
ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw
cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj
b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy
IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z
aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu
dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl
IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp
dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnRoZXkgc2hvdWxkIG5v
dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHlvdSBo
YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl
ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFzIGVtYWlscyBtYXkgYmUg
YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu
IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl
bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp
ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh
dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1
aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz
IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk
J2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl
IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h
eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5
IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk
IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+
QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn
ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg
am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz
IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug
Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh
ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx
dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz
dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug
bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBh
dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h
dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls
IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi
bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp
ZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5r
IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_E194C2E18676714DACA9C3A2516265D2026645F9FR712WXCHMBA11z_--


From ulrich.wiehe@nsn.com  Wed Feb 12 02:34:29 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5881A0928 for ; Wed, 12 Feb 2014 02:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX2Rj1tGzCW1 for ; Wed, 12 Feb 2014 02:34:26 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7731A0927 for ; Wed, 12 Feb 2014 02:34:26 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1CAYNJj016061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 11:34:23 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1CAYN8X020619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 11:34:23 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 11:34:22 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 11:34:22 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] [dime] #51: OC-Supported-Features in requests
Thread-Index: AQHPJ8dJMvhOqgSOVkGQ3fH3JyWghZqxViIg///xjQCAACOKAA==
Date: Wed, 12 Feb 2014 10:34:21 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F8E@DEMUMBX014.nsn-intra.net>
References: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F32@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2362
X-purgate-ID: 151667::1392201263-00001A6F-1C763709/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #51: OC-Supported-Features in requests
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 10:34:29 -0000

Jouni,
Thank you for the hint.

This depends on the outcome of issue #30.

For now I would agree to say "...MUST be included in every Diameter request=
...."

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, February 12, 2014 10:23 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org; maria.cruz.bartolome@ericsson.com
Subject: Re: [Dime] [dime] #51: OC-Supported-Features in requests



Also in answer messages now? The text quoted below does not differentiate
whether it is answer or request.

- Jouni

On Feb 12, 2014, at 11:16 AM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> I agree.
>=20
> Absence of OC-Supported-Features AVP from a request means "DOIC not suppo=
rted".
> Ulrich
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue tra=
cker
> Sent: Wednesday, February 12, 2014 8:52 AM
> To: maria.cruz.bartolome@ericsson.com
> Cc: dime@ietf.org
> Subject: [Dime] [dime] #51: OC-Supported-Features in requests
>=20
> #51: OC-Supported-Features in requests
>=20
> Now:
> The OC-Supported-Features AVP SHOULD be included into every Diameter
> message a DOIC
> supporting node sends (and intends to use for DOIC purposes).
>=20
> Why is "should" used?
>=20
> Proposal: replace SHOULD by MUST
>=20
> --=20
> -----------------------------------------------+-------------------------=
--
> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>     Type:  defect                             |  Bartolom=E9
> Priority:  major                              |     Status:  new
> Component:  draft-docdt-dime-ovli              |  Milestone:
> Severity:  Active WG Document                 |    Version:  1.0
>                                               |   Keywords:
> -----------------------------------------------+-------------------------=
--
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> 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 ulrich.wiehe@nsn.com  Wed Feb 12 04:38:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C571A0980 for ; Wed, 12 Feb 2014 04:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0JlGYcpbTRI for ; Wed, 12 Feb 2014 04:38:54 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 45A7A1A094E for ; Wed, 12 Feb 2014 04:38:54 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1CCcp2l023836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 13:38:51 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1CCcpN1008382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 13:38:51 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 13:38:51 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 13:38:51 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYIAAHLvQgAAuN4A=
Date: Wed, 12 Feb 2014 12:38:50 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 7683
X-purgate-ID: 151667::1392208731-00001A6F-7A9C46E5/0-0/0-0
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 12:38:59 -0000

The reacting node (when receiving OC-Supported-Features AVP in an answer) k=
nows that the corresponding request took a path towards the server on which=
 there is a reporting node (which supports DOIC). It does not know whether =
this reporting node is the server or an agent and it does not know whether =
subsequent requests will take the same path or a different path on which th=
ere may be no reporting node.=20
Consequently the presence of OC-Supported-Features AVP in an answer does no=
t tell you anything usefull on which to base behaviour for subsequent reque=
sts targeted to the same server.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:56 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting no=
de overload mitigation based on implicit indications (as described by TR), =
therefore any 3GPP application that will support new "Overload mitigation" =
feature (or whatever may be the name), shall improve its procedures with th=
is objective. It is expected as well, that this new 3GPP "Overload mitigati=
on" feature makes use of our DOIC, and then it is very beneficial that the =
reacting node could identify at any moment whether or not the reporting nod=
e supports DOIC, since procedures to be implemented could be potentially di=
fferent.

2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?=20
[MCruz] Reacting node receives reporting node Supported-Features. Regardles=
s the reporting node is either an agent or a server, in case the reacting n=
ode needs to treat "implicit indications" (like TOO_BUSY), expected reactio=
n may depend on whether or not reporting node supports DOIC. This informati=
on is very beneficial to determine the most appropriate reaction.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement  in our 3GPP TR:

6.3.3	Implicit Overload Indication
6.3.3.1	Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
-	DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
-	Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> 1) I want the reacting node to be able to learn if a (potentially)=20
> reporting node supports DOIC, even when that node is not in overload.
> I don't want to specify any particular behavior for that knowledge,=20
> but I suspect implementations may want to treat DOIC compliant servers=20
> in some way differently than they do non-DOIC servers. For example, I=20
> might have a configured rate limit for non-DOIC peers, but use a=20
> higher (or no) limit for peers that are known to support DOIC (and can=20
> thus speak for themselves.) sounds like a new requirement;=20
> where does it come from? I would have thought that there is no need to=20
> distinguish between
> a) DOIC not supported and therefore no traffic reduction requested,=20
> and
> b) DOIC supported, but not in overload and therefore no traffic=20
> reduction requested
>=20

At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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 ulrich.wiehe@nsn.com  Wed Feb 12 05:28:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C9D1A0281 for ; Wed, 12 Feb 2014 05:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kasBMtCjPKh for ; Wed, 12 Feb 2014 05:28:14 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE5A1A0105 for ; Wed, 12 Feb 2014 05:28:13 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1CDS9gZ018273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 14:28:09 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1CDS9Fs014658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 14:28:09 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 14:28:09 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 14:28:09 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext lionel.morand@orange.com" , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #32:	Sequence-Number	Time-Stamp	values	within OC-OLR
Thread-Index: AQHPJ/ZEdcqDl1zjUk6WFwfQrgA7lg==
Date: Wed, 12 Feb 2014 13:28:08 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3055@DEMUMBX014.nsn-intra.net>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29423_1391537999_52F12F4F_29423_3802_1_6B7134B31289DC4FAF731D844122B36E47772A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 14349
X-purgate-ID: 151667::1392211690-000025D0-C2001126/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #32:	Sequence-Number	Time-Stamp	values	within	OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 13:28:22 -0000

Maybe its worth to explicitly say that "... there is no reason to remember =
anything about it" includes "no need for reacting nodes to remember sequenc=
e numbers of expired OLRs" or even mandate that sequence numbers of expired=
 OLRs must not be remembered by reacting nodes.
Ulrich

-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Sent: Monday, February 10, 2014 2:48 PM
To: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: RE: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR

I would add, maybe even before the format (NTP time based), that the real r=
equirements for the sequence-number are:

- Globally/eternally unique
- increase monotonically over time, including over a reboot (as remind by S=
teve)=20

The NTP time based type is just a guidance provided by the draft on how to =
generate sequence numbers with such properties.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: samedi 8 f=E9vrier 2014 11:33
=C0=A0: Wiehe, Ulrich (NSN - DE/Munich)
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O=
C-OLR


Sounds acceptable. Would the following then work for all:

o clarify that once the overload report expires there is no
  reason to remember anything about it
o the sequence number would be similar to session-id.. based=20
  on the NTP time + any vendor specific data to make it=20
  "globally and eternally unique".

- Jouni



On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> Steve,
> =20
> sounds like an acceptable proposal which allows to come back to sync afte=
r OLR expiry.
> This requires however an update of clause 5.5.2 to clearly state
> Once the overload report expires there is no reason to remember anything =
about it and the next overload report received could, conceivably have any =
value.=20
>=20
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Thursday, February 06, 2014 4:50 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within =
OC-OLR
> =20
> A couple of things -=20
>=20
> The requirement is that the sequence number increase monotonically over t=
ime, including over a reboot.  Use of NTP time is one way of doing this but=
 is not the only way.  Someone could, for instance, use a time stamp to set=
 the sequence number for the first overload report sent after a reboot and =
then increment the sequence number value by one for each subsequent overloa=
d report sent.  This actually has better properties than an NTP time stamp =
as it would take much longer to roll over.  One could also create a global =
sequence number service that is not tied to time and have a Diameter server=
 query that global sequence number server after each reboot.
>=20
> We also have a duration timer on overload reports.  This gives us one way=
 to reset.  It should only be required to remember the sequence number of a=
n active overload report.  Once the overload report expires there is no rea=
son to remember anything about it and the next overload report received cou=
ld, conceivably have any value.=20
>=20
> The requirement we need is similar to the session-id in the base Diameter=
 specification.  The wording there is -- "The Session-Id MUST be globally a=
nd eternally unique".  We just need eternally as the spacial differentiatio=
n is based on the context of the message carrying the overload report.
>=20
> It would be perfectly valid for the DOIC draft to suggest the use of NTP =
timestamps to populate the sequence number but it should be worded in a sim=
ilar fashion as the Diameter base RFC -- The Session-Id includes a mandator=
y portion and an implementation-defined portion; a recommended format for t=
he implementation-defined portion is outlined below ..."
>=20
> Steve
>=20
> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> I cannot understand what is the problem with mandating timestamp.
> But I can see interoperability problems with the current definition:
> =20
> Assume the sender sends sequence numbers
> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
> but the receicer for any reason receives=20
> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20
> The receiver would accept
> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
> and then silently discards
> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
> with no way to come back to sync.
> =20
> Are we sure that this cannot happen?
> =20
> Mandating timestamp for sequence number generation at the sender and plau=
sibility checking (i.e. received value must be between stored value and tim=
e of reception) for the receiver may not be the only way to solve the probl=
em. But in the moment I don't see another way.
> =20
> Ulrich
> =20
> =20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Wednesday, February 05, 2014 4:57 PM
> To: ext lionel.morand@orange.com
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within =
OC-OLR
> =20
> My point is, we have an interop requirement that the sequence number alwa=
ys increases over time scope. We do not have the interop requirement that t=
he sequence number be implemented as a time stamp. A time stamp is probably=
 a good way to  meet the interop requirements, but it is not, in itself, an=
 interop requirement.
> =20
> On Feb 5, 2014, at 9:53 AM,   wrote:
> =20
> Not sure to understand: if there is a kind of "interop requirement", it i=
s a case for a "MUST".
> We are not violating anything.
> =20
> Reporting and reacting nodes will just rely on the Diameter interfaces to=
 know how to handle the received sequence-number. So any MUST on the format=
 of the sequence-number is acceptable if it avoids interop issues.
> =20
> -----Message d'origine-----
> De : Ben Campbell [mailto:ben@nostrum.com]=20
> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
> =C0 : MORAND Lionel IMT/OLN
> Cc : Steve Donovan; dime@ietf.org
> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O=
C-OLR
> =20
> I concur with Steve on this one. Using a time stamp is a good way to meet=
 the requirements, but it's not our job to normatively state an implementat=
ion. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Se=
ction 6 of 2119 includes the following:
> =20
> "In particular, [normative requirements] MUST only be used where it is
>   actually required for interoperation or to limit behavior which has
>   potential for causing harm (e.g., limiting retransmisssions)  "
> =20
> The only appropriate reason to require a timestamp would be if we expecte=
d peers to interpret the field as a point in time. OTOH, it would be perfec=
tly reasonable to state the actual interop requirements, then add a non-nor=
mative (probably indented) paragraph suggesting that a timestamp is a good =
way to do this.
> =20
> On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
> =20
> I think the out-of-sync failover described by Ulrich is a good use case t=
o mandate a specific semantic.
> =20
> Is there any specific NOT to mandate the use of NTP timestamps if it is a=
 simple way to solve the possible issues and please everyone?
> =20
> Lionel
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
> =C0 : dime@ietf.org
> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O=
C-OLR
> =20
> How the sequence number is implemented is an implementation decision.  Th=
ere is no reason to mandate that is be an NTP timestamp.  That should be in=
cluded only as one way of addressing the requirement.
> =20
> Steve
> =20
> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
> I also agree.
> =20
> Regards,
> Nirav.
> =20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@oran=
ge.com
> Sent: Tuesday, February 04, 2014 11:50 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within =
OC-OLR
> =20
> The existing wording seems actually fuzzy.
> If it is "like an NTP timestamp", be proud and say it loud!
> =20
> In summary: ok with the proposal if it clarifies this handling of this se=
quence-number.
> =20
> Lionel
> =20
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
> =C0 : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
> =20
> #32: Sequence-Number Time-Stamp values within OC-OLR
> =20
> The -01 draft says in clause 4.4:
>    From the functionality point of view, the OC-Sequence-Number AVP MUST
>    be used as a non-volatile increasing counter between two overload
>    control endpoints (neglecting the fact that the contents of the AVP
>    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
>    required to be unique between two overload control endpoints.
>    Sequence numbers are treated in uni-directional manner, i.e. two
>    sequence numbers on each direction between two endpoints are not
>    related or correlated.
> =20
>    When generating sequence numbers, the new sequence number MUST be
>    greater than any sequence number previously seen between two
>    endpoints within a time window that tolerates the wraparound of the
>    NTP timestamp (i.e. approximately 68 years).
> =20
> =20
> With this mechanism it is difficult to get back to sync once you are out =
 of sync (for whatever reason).
> It is proposed to mandate that the Sequence Number is a real 64-bit NTP  =
timestamp (RFC5905) indicating the point in time when the OLR was created, =
 and to mandate that  OLRs with a time stamp higher than time of reception =
 must be ignored by the reacting node.
> =20
> =20
> _________________________________________________________________________=
________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu 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 o=
u falsifie. Merci.
> =20
> This message and its attachments may contain confidential or privileged i=
nformation 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 de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> _________________________________________________________________________=
________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu 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 o=
u falsifie. Merci.
> =20
> This message and its attachments may contain confidential or privileged i=
nformation 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 de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> _______________________________________________
> 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
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From maria.cruz.bartolome@ericsson.com  Wed Feb 12 05:34:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8491A0990 for ; Wed, 12 Feb 2014 05:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E7qkNgeUtfD for ; Wed, 12 Feb 2014 05:34:39 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C28D11A098F for ; Wed, 12 Feb 2014 05:34:38 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-d9-52fb786db253
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D7.0A.23809.D687BF25; Wed, 12 Feb 2014 14:34:37 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 14:34:36 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #52: Throttling not needed to be based on previous history
Thread-Index: AQHPJ8pHWh6U3x1NsUGCEW0ghWu/OpqxT/wg///7cQCAAB9oIA==
Date: Wed, 12 Feb 2014 13:34:35 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097745AF@ESESSMB101.ericsson.se>
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW5uxe8gg9anohZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/eXucwFP9Uq9pz+xN7AuF+ui5GDQ0LARGLiRakuRk4gU0zi wr31bF2MXBxCAocYJRrWL2GCcJYwSnT9XsgCUsUmYCdx6fQLJpBmEQFlidO/HEBMYYFwid61 hSAVIgIREjOvv2CHsJ0k5n6YzgpiswioSix6+JsNxOYV8JWYO38zM8T4vYwS37+tBSviFLCV WLB0JpjNCHTQ91NrmEBsZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2ksSPDZdYIOr1JG5M ncIGYWtLLFv4mhlisaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyipE9NzEzJ73caBMjMOgP bvmtuoPxzjmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcz9jEElMp /Vro+TVJ4yuz1Hmtp9gu2Ldv4o+1JVsZUw7VvX2rV/9oxiLJgwa6YgcLF1SlRfnv/bwr9J9h bDXDVV+5/d++z54+q7Zz6uyw9bPF16bta54h0Kq20qvleK3zw9kLf7/QX1EumMvctF8hZdrs zV8m5dUsFU3bvoZdVjPQ7V6W1JmFSizFGYmGWsxFxYkAgTU5bEgCAAA=
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 13:34:50 -0000

Thanks Jouni, I didn't realize.
One more correction added

> Proposal:
> Indicates that the reporting node urges the reacting node to reduce=20
> its traffic by a given percentage. For example if the
> reacting node would send 100 packets to the				<---
> reporting node, then a reception of OC-Reduction-Percentage value of=20
> 10 would mean that from now on the reacting node MUST only send
> 90 packets instead of 100. How the reacting node achieves the "true      =
 <---
> reduction" transactions leading to the sent request messages is up to=20
> the implementation. The reacting node MAY simply drop every 10th=20
> packet from its output queue and let the generic application logic try=20
> to recover from it.


-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 10:36
To: Maria Cruz Bartolome
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previo=
us history


Fine by me.. though you then need to apply the same change to the rest of t=
his paragraph, not only the first one.

Also, please update this additional concern into the issue tracker issue #5=
2.

- Jouni

On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome  wrote:

> Same comment also applies to following paragraph in 5.5.2
>=20
> Now:
>   0 < value < 100
>=20
>      Indicates that the reporting node urges the reacting node to
>      reduce its traffic by a given percentage.  For example if the
>      reacting node has been sending 100 packets per second to the
>      reporting node, then a reception of OC-Reduction-Percentage value
>      of 10 would mean that from now on the reacting node MUST only send
>      90 packets per second.  How the reacting node achieves the "true
>      reduction" transactions leading to the sent request messages is up
>      to the implementation.  The reacting node MAY simply drop every
>      10th packet from its output queue and let the generic application
>      logic try to recover from it.0 < value < 100
>=20
> Proposal:
> Indicates that the reporting node urges the reacting node to reduce=20
> its traffic by a given percentage. For example if the
> reacting node would send 100 packets to the				<---
> reporting node, then a reception of OC-Reduction-Percentage value of=20
> 10 would mean that from now on the reacting node MUST only send
> 90 packets per second. How the reacting node achieves the "true=20
> reduction" transactions leading to the sent request messages is up to=20
> the implementation. The reacting node MAY simply drop every 10th=20
> packet from its output queue and let the generic application logic try=20
> to recover from it.
>=20
>=20
> We should not specify a rates for the simple loss algorithm. It's up to t=
he implementation how to reduce, but no time unit has to be specified.=20
>=20
>=20
>=20
> -----Original Message-----
> From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
> Sent: mi=E9rcoles, 12 de febrero de 2014 9:13
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> Subject: [dime] #52: Throttling not needed to be based on previous=20
> history
>=20
> #52: Throttling not needed to be based on previous history
>=20
> Now (chapter 4.7):
>    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
>    and describes the percentage of the traffic that the sender is
>    requested to reduce, compared to what it otherwise would have sent.
>=20
> Proposal:
> The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  an=
d describes the percentage of the traffic that the sender is  requested to =
reduce, compared to what it otherwise would send.
>=20
>=20
> The intention is to avoid that anyone may interpret reacting node is  req=
uired to consider history of sent information when throttling.
>=20
> --
> -----------------------------------------------+----------------------
> -----------------------------------------------+--
> -----------------------------------------------+---
> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>     Type:  defect                             |  Bartolom=E9
> Priority:  major                              |     Status:  new
> Component:  draft-docdt-dime-ovli              |  Milestone:
> Severity:  Active WG Document                 |    Version:  1.0
>                                               |   Keywords:
> -----------------------------------------------+----------------------
> -----------------------------------------------+--
> -----------------------------------------------+---
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From trac+dime@trac.tools.ietf.org  Wed Feb 12 05:42:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC41A02B0 for ; Wed, 12 Feb 2014 05:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYMmQYi5rO6K for ; Wed, 12 Feb 2014 05:42:50 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4877D1A0238 for ; Wed, 12 Feb 2014 05:42:49 -0800 (PST)
Received: from localhost ([127.0.0.1]:34886 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WDa5Q-00069Y-GJ; Wed, 12 Feb 2014 14:42:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Wed, 12 Feb 2014 13:42:48 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/53
Message-ID: <075.7050d926bbf4992a2147612aa862564a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 53
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: dime@ietf.org
Subject: [Dime] [dime] #53: 5.5.2 chapter typo?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Feb 2014 13:42:52 -0000

#53: 5.5.2 chapter typo?

 Now following text seems to be wrong and could be deleted:

    .........  If the OC-Supported-Features AVP
    is received for the first time for the reporting node or the OC-
    Sequence-Number AVP value is less than the previously received/
    recorded one (and is outside the valid overflow window), then either
    the sequence number is stale (e.g. an intentional or unintentional
    replay) and SHOULD be silently discarded.

 As long as, the situations that it refers are covered later in the same
 chapter:

     .....
     .....

    If the OC-OLR AVP is received for the first time, the reacting node
    MUST create an overload condition state associated with the related
    realm or a specific host in the realm identified in the message
    carrying the OC-OLR AVP, as described in Section 5.5.1.

    If the value of the OC-Sequence-Number AVP contained in the received
    OC-OLR AVP is equal to or less than the value stored in an existing
    overload condition state, the received OC-OLR AVP SHOULD be silently
    discarded.  If the value of the OC-Sequence-Number AVP contained in
    the received OC-OLR AVP is greater than the value stored in an
    existing overload condition state or there is no previously recorded
    sequence number, the reacting node MUST update the overload condition
    state associated with the realm or the specific node is the realm.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  minor                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
 Severity:  Active WG Document                 |    Version:  1.0
                                               |   Keywords:
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From ben@nostrum.com  Wed Feb 12 05:43:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6471A02B0 for ; Wed, 12 Feb 2014 05:43:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7eOmuKxizxc for ; Wed, 12 Feb 2014 05:43:53 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFB21A00EE for ; Wed, 12 Feb 2014 05:43:53 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1CDhlVU004736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Feb 2014 07:43:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
Date: Wed, 12 Feb 2014 07:43:47 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <60E12F73-6EF4-485E-A4CF-33B5992EC510@nostrum.com>
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
To: "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 13:43:55 -0000

On Feb 12, 2014, at 1:43 AM, dime issue tracker =
 wrote:

> #50: OC-OLR AVP implicit info
>=20
> Now (chapter 4.3):
>=20
>    The OC-OLR AVP does not contain explicit information to which
>    application it applies to and who inserted the AVP or whom the
>    specific OC-OLR AVP concerns to. Both these information is
>    implicitly learned from the encapsulating Diameter message/command.
>    The application the OC-OLR AVP applies to is the same as the
>    Application-Id found in the Diameter message header.  The identity
>    the OC-OLR AVP concerns is determined from the Origin-Host AVP =
found
>    from the encapsulating Diameter command.
>=20
>=20
> My understanding is that =93who inserted the AVP=94 cannot always be =
learned
> from the encapsulating Diameter message, since =93origin-host=94 may =
not
> always contain the host that inserted the OLR.
> A part from that, =93whom the specific OC-OLR AVP concerns to=94, =
could be a
> bit misleading=85 =93whom=94 may be host, realm, or any other future =
ReportType,
> or even any other =93narrowed scope=94 within the OLR. Last sentence =
is
> affected by this ambiguity as well.
>=20
>=20
> New proposal (related to new text proposed chapter 4.6, see to Issue =
#34):
>=20
> The OC-OLR AVP does not contain explicitly all information needed by =
the
> reacting node in order to decide whether a subsequent request must =
undergo
> a throttling process with the received reduction percentage.
> The following information is implicitly known from the received
> application answer and OC-OLR AVP, that is used by reacting node to
> identify subsequent requests that are requested to be throttled:
>=20
> a)The Application-ID is the value of the Application-ID of the =
Diameter
>   Header of the received message that contained the OC-OLR AVP.
>=20
> b)The Destination-Realm AVP (if required, see 4.6) is the value of the
> Origin-Host AVP of the received message that contained the OC-OLR AVP.
>=20
> c)The Destination-Host AVP (if required, see 4.6) is the value of the
> Origin-Host AVP of the received message that contained the OC-OLR AVP.

b) and c) are the same. Was one intended to be Realm?


>=20
> --=20
> =
-------------------------------------+------------------------------------=
-
> Reporter:                           |      Owner:  draft-docdt-dime-
>  maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
>     Type:  defect                   |     Status:  new
> Priority:  major                    |  Milestone:
> Component:  draft-docdt-dime-ovli    |    Version:  1.0
> Severity:  Active WG Document       |   Keywords:
> =
-------------------------------------+------------------------------------=
-
>=20
> Ticket URL: 
> dime 
>=20


From ben@nostrum.com  Wed Feb 12 05:44:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C371A0979 for ; Wed, 12 Feb 2014 05:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR7F5Q7UKC4z for ; Wed, 12 Feb 2014 05:44:54 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD6321A008E for ; Wed, 12 Feb 2014 05:44:54 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1CDhlVV004736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Feb 2014 07:44:50 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F21@DEMUMBX014.nsn-intra.net>
Date: Wed, 12 Feb 2014 07:44:50 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <107B5E60-DD29-486E-BCA3-B59FFDBC93EE@nostrum.com>
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F21@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 13:44:56 -0000

On Feb 12, 2014, at 3:13 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Hi,
>=20
> I'm ok with the first sentence:
>> The OC-OLR AVP does not contain explicitly all information needed by =
the
>> reacting node in order to decide whether a subsequent request must =
undergo
>> a throttling process with the received reduction percentage.
>=20
> The rest, however, should be replaced with e.g.:
>=20
> The value of the OC-Report-Type AVP within the OC-OLR AVP indicates =
which implicit=20
> information is relevant for this decision (see clause 4.6).

I'm not sure I understand. Did you mean to delete the text about where =
you specifically find the "implicit" parameters? If so, why?


From maria.cruz.bartolome@ericsson.com  Wed Feb 12 05:49:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA761A02E3 for ; Wed, 12 Feb 2014 05:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 3Vwl1i5Q6XCJ for ; Wed, 12 Feb 2014 05:49:38 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 815CF1A0238 for ; Wed, 12 Feb 2014 05:49:37 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-cd-52fb7bef4437
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8D.D3.04249.FEB7BF25; Wed, 12 Feb 2014 14:49:36 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 14:49:35 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [dime] #50: OC-OLR AVP implicit info
Thread-Index: AQHPJ/h3/5vaMu8tIkKzZZuvokw1s5qxogxQ
Date: Wed, 12 Feb 2014 13:49:35 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097745F0@ESESSMB101.ericsson.se>
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org> <60E12F73-6EF4-485E-A4CF-33B5992EC510@nostrum.com>
In-Reply-To: <60E12F73-6EF4-485E-A4CF-33B5992EC510@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6H6t9BBl9u81rM7V3BZjFlxR8m ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvjxpwprAWTpCqWb1rM3sD4VqSLkZNDQsBE ovPmCkYIW0ziwr31bF2MXBxCAkcYJVad2cIK4SxhlPh8bTEzSBWbgJ3EpdMvmEBsEYFKia/7 vrGC2MIChhJrn/YD1XAAxY0kVv7Sgigxklj7ZBdYK4uAqsTcztlg5bwCvhJnX6xiBykXEqiW mNEUBRLmFLCX2HDzMFgJI9A930+tAdvELCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcJWkvix 4RILRL2exI2pU9ggbG2JZQtfM0OsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMXIUpxYn 5aYbGWxiBMbCwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MorO3HmI9efHSvN9N1zcntJtlTZE63n/wZ92bbzv9nDtv+FZu/8Ui+/7y7qPXeQrXhDpy KFQeaa6aMs38cyOjTeaJbd3TOB7fnsjoEr91vn/bxHOfrHqvv7TgKunLFw3R3n1rxwTOCObI tRwHNh8/5pf/7um2CXWFNwQPSOyIuR6q5GPzOOmOqhJLcUaioRZzUXEiANhOVbtTAgAA
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 13:49:40 -0000

Ben,

See below
/MCruz

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 14:44
To: dime@ietf.org list
Cc: draft-docdt-dime-ovli@tools.ietf.org; Maria Cruz Bartolome
Subject: Re: [dime] #50: OC-OLR AVP implicit info


On Feb 12, 2014, at 1:43 AM, dime issue tracker  wrote:

> #50: OC-OLR AVP implicit info
>=20
> Now (chapter 4.3):
>=20
>    The OC-OLR AVP does not contain explicit information to which
>    application it applies to and who inserted the AVP or whom the
>    specific OC-OLR AVP concerns to. Both these information is
>    implicitly learned from the encapsulating Diameter message/command.
>    The application the OC-OLR AVP applies to is the same as the
>    Application-Id found in the Diameter message header.  The identity
>    the OC-OLR AVP concerns is determined from the Origin-Host AVP found
>    from the encapsulating Diameter command.
>=20
>=20
> My understanding is that "who inserted the AVP" cannot always be=20
> learned from the encapsulating Diameter message, since "origin-host"=20
> may not always contain the host that inserted the OLR.
> A part from that, "whom the specific OC-OLR AVP concerns to", could be=20
> a bit misleading. "whom" may be host, realm, or any other future=20
> ReportType, or even any other "narrowed scope" within the OLR. Last=20
> sentence is affected by this ambiguity as well.
>=20
>=20
> New proposal (related to new text proposed chapter 4.6, see to Issue #34)=
:
>=20
> The OC-OLR AVP does not contain explicitly all information needed by=20
> the reacting node in order to decide whether a subsequent request must=20
> undergo a throttling process with the received reduction percentage.
> The following information is implicitly known from the received=20
> application answer and OC-OLR AVP, that is used by reacting node to=20
> identify subsequent requests that are requested to be throttled:
>=20
> a)The Application-ID is the value of the Application-ID of the Diameter
>   Header of the received message that contained the OC-OLR AVP.
>=20
> b)The Destination-Realm AVP (if required, see 4.6) is the value of the=20
> _Origin-REALM_ AVP of the received message that contained the OC-OLR AVP.
>=20
> c)The Destination-Host AVP (if required, see 4.6) is the value of the=20
> Origin-Host AVP of the received message that contained the OC-OLR AVP.

b) and c) are the same. Was one intended to be Realm?

[MCruz] Yes, this was the intention, corrected in caps above.=20

>=20
> --
> -------------------------------------+--------------------------------
> -------------------------------------+-----
> Reporter:                           |      Owner:  draft-docdt-dime-
>  maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
>     Type:  defect                   |     Status:  new
> Priority:  major                    |  Milestone:
> Component:  draft-docdt-dime-ovli    |    Version:  1.0
> Severity:  Active WG Document       |   Keywords:
> -------------------------------------+--------------------------------
> -------------------------------------+-----
>=20
> Ticket URL: 
> dime 
>=20


From ulrich.wiehe@nsn.com  Wed Feb 12 06:00:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D11A09A3 for ; Wed, 12 Feb 2014 06:00:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PATrLp3zS890 for ; Wed, 12 Feb 2014 06:00:08 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 119A31A099B for ; Wed, 12 Feb 2014 05:59:36 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1CDxWoS029714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 14:59:33 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1CDxTLT023002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 14:59:32 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 14:59:31 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 14:59:31 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell 
Thread-Topic: [Dime] [dime] #50: OC-OLR AVP implicit info
Thread-Index: AQHPJ8YkuggLJhr06kytgQtL4UJMl5qxU9BggAA9EwCAABPqEA==
Date: Wed, 12 Feb 2014 13:59:30 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B30A0@DEMUMBX014.nsn-intra.net>
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F21@DEMUMBX014.nsn-intra.net> <107B5E60-DD29-486E-BCA3-B59FFDBC93EE@nostrum.com>
In-Reply-To: <107B5E60-DD29-486E-BCA3-B59FFDBC93EE@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1136
X-purgate-ID: 151667::1392213574-00001A6F-BC5856D0/0-0/0-0
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 14:00:11 -0000

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Wednesday, February 12, 2014 2:45 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; maria.cruz.bartolo=
me@ericsson.com
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info


On Feb 12, 2014, at 3:13 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> Hi,
>=20
> I'm ok with the first sentence:
>> The OC-OLR AVP does not contain explicitly all information needed by the
>> reacting node in order to decide whether a subsequent request must under=
go
>> a throttling process with the received reduction percentage.
>=20
> The rest, however, should be replaced with e.g.:
>=20
> The value of the OC-Report-Type AVP within the OC-OLR AVP indicates which=
 implicit=20
> information is relevant for this decision (see clause 4.6).

I'm not sure I understand. Did you mean to delete the text about where you =
specifically find the "implicit" parameters? If so, why?
 yes, because this will be covered by clause 4.6 (see issue #34)


From trac+dime@trac.tools.ietf.org  Wed Feb 12 06:25:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05391A0389 for ; Wed, 12 Feb 2014 06:25:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77DUvfa0KZf1 for ; Wed, 12 Feb 2014 06:25:41 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCEC1A031B for ; Wed, 12 Feb 2014 06:25:41 -0800 (PST)
Received: from localhost ([127.0.0.1]:37214 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WDakt-0006Gj-Kh; Wed, 12 Feb 2014 15:25:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Wed, 12 Feb 2014 14:25:39 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/54
Message-ID: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org>
X-Trac-Ticket-ID: 54
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: dime@ietf.org
Subject: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Feb 2014 14:25:45 -0000

#54: OC-Report-Type as mandatory AVP

 Now in chapter 4.6:

    The default value of the OC-Report-Type AVP is 0 (i.e. the host
    report).

 This AVP is always required, right? Then, I think it is more precise that
 we define this AVP as mandatory.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
 Severity:  Active WG Document                 |    Version:  1.0
                                               |   Keywords:
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From lionel.morand@orange.com  Wed Feb 12 06:45:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717481A0996 for ; Wed, 12 Feb 2014 06:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBWbbVMD-5vf for ; Wed, 12 Feb 2014 06:45:49 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1591A03B4 for ; Wed, 12 Feb 2014 06:45:49 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 149BB26443A; Wed, 12 Feb 2014 15:45:48 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E8AAA27C0F0; Wed, 12 Feb 2014 15:45:47 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 15:45:47 +0100
From: 
To: "dime@ietf.org" , "maria.cruz.bartolome@ericsson.com" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPJ/5VuFzVjiuvb0aHeNaJvKXrK5qxsJ5g
Date: Wed, 12 Feb 2014 14:45:46 +0000
Message-ID: <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org>
In-Reply-To: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 14:45:51 -0000

SGkgTWFyaWEgQ3J1eiwNCg0KSSdtIGFzc3VtaW5nIHRoYXQgeW91IG1lYW4gInJlcXVpcmVkIiBp
bnN0ZWFkIG9mICJtYW5kYXRvcnkiLCByaWdodD8NCg0KU28gaW5zdGVhZCBvZjoNCg0KICAgT0Mt
T0xSIDo6PSA8IEFWUCBIZWFkZXI6IFRCRDIgPg0KICAgICAgICAgICAgICA8IE9DLVNlcXVlbmNl
LU51bWJlciA+DQogICAgICAgICAgICAgIFsgT0MtUmVwb3J0LVR5cGUgXQ0KICAgICAgICAgICAg
ICBbIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIF0NCiAgICAgICAgICAgICAgWyBPQy1WYWxpZGl0
eS1EdXJhdGlvbiBdDQogICAgICAgICAgICAqIFsgQVZQIF0NCg0KWW91IHdvdWxkIHByZWZlcjoN
Cg0KICAgT0MtT0xSIDo6PSA8IEFWUCBIZWFkZXI6IFRCRDIgPg0KICAgICAgICAgICAgICA8IE9D
LVNlcXVlbmNlLU51bWJlciA+DQogICAgICAgICAgICAgIHsgT0MtUmVwb3J0LVR5cGUgfQ0KICAg
ICAgICAgICAgICBbIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIF0NCiAgICAgICAgICAgICAgWyBP
Qy1WYWxpZGl0eS1EdXJhdGlvbiBdDQogICAgICAgICAgICAqIFsgQVZQIF0NCg0KQW5kIEknbSBm
aW5lIHdpdGggdGhpcyBwcm9wb3NhbC4NCg0KQ2hlZXJzLA0KDQpMaW9uZWwNCg0KLS0tLS1NZXNz
YWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnXSBEZSBsYSBwYXJ0IGRlIGRpbWUgaXNzdWUgdHJhY2tlcg0KRW52b3nDqcKgOiBtZXJjcmVk
aSAxMiBmw6l2cmllciAyMDE0IDE1OjI2DQrDgMKgOiBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmlj
c3Nvbi5jb20NCkNjwqA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6IFtEaW1lXSBbZGltZV0gIzU0
OiBPQy1SZXBvcnQtVHlwZSBhcyBtYW5kYXRvcnkgQVZQDQoNCiM1NDogT0MtUmVwb3J0LVR5cGUg
YXMgbWFuZGF0b3J5IEFWUA0KDQogTm93IGluIGNoYXB0ZXIgNC42Og0KDQogICAgVGhlIGRlZmF1
bHQgdmFsdWUgb2YgdGhlIE9DLVJlcG9ydC1UeXBlIEFWUCBpcyAwIChpLmUuIHRoZSBob3N0DQog
ICAgcmVwb3J0KS4NCg0KIFRoaXMgQVZQIGlzIGFsd2F5cyByZXF1aXJlZCwgcmlnaHQ/IFRoZW4s
IEkgdGhpbmsgaXQgaXMgbW9yZSBwcmVjaXNlIHRoYXQNCiB3ZSBkZWZpbmUgdGhpcyBBVlAgYXMg
bWFuZGF0b3J5Lg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgbWFyaWEu
Y3J1ei5iYXJ0b2xvbWVAZXJpY3Nzb24uY29tICB8ICAgICAgT3duZXI6ICBNQ3J1eg0KICAgICBU
eXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBCYXJ0b2xvbcOpDQog
UHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1
czogIG5ldw0KQ29tcG9uZW50OiAgZHJhZnQtZG9jZHQtZGltZS1vdmxpICAgICAgICAgICAgICB8
ICBNaWxlc3RvbmU6DQogU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAgICAgICAgICAg
ICAgIHwgICAgVmVyc2lvbjogIDEuMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0
IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2RpbWUvdHJhYy90aWNrZXQvNTQ+
DQpkaW1lIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvZGltZS8+DQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlN
RUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p
ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg
ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg
YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl
dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1
ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1
c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls
aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj
aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs
YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp
YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs
c2lmaWVkLgpUaGFuayB5b3UuCgo=


From jean-jacques.trottin@alcatel-lucent.com  Wed Feb 12 11:30:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04471A062C for ; Wed, 12 Feb 2014 11:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztTY_c39WZe8 for ; Wed, 12 Feb 2014 11:30:33 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B566A1A0647 for ; Wed, 12 Feb 2014 11:30:33 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1CJUVHb016285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Feb 2014 13:30:32 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1CJUUcR027049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Feb 2014 20:30:30 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 20:30:30 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #46: Bad normative advice on not	letting overload	reports expire
Thread-Index: AQHPJxXELMYu9QS3d0uaLCS8tFO+/5qwkyKAgAFlB/A=
Date: Wed, 12 Feb 2014 19:30:29 +0000
Message-ID: 
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com>
In-Reply-To: <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #46: Bad normative advice on not	letting	overload	reports expire
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 19:30:37 -0000

Dear all

I come back on this ticket and your current conclusions;
We are in the area of guidance about the use of the expiry timer  but I thi=
nk there are important points to take care with the expiry timer :

If a server  sends OLRs with 50% traffic reduction, the client will divide =
the traffic by two. Then, if the server does not update the expiry timer an=
d leaves  it expire and that traffic conditions have not changed  on client=
 side, the client will stop  throttling  and will double the traffic which =
 I think the server will worry about.=20
 We need to avoid oscillations, and have a graceful behavior as expressed i=
n the requirements 2 , 3 and 7. In fact the server should  progressively de=
crease the value of the % reduction in OLRs it sends according to the dimin=
ution of the traffic it will observe (due to the decrease of the input traf=
fic coming back to normal conditions  on client side)  This is when server =
will  send  OLRs with 0% of traffic reduction without generating overload t=
hat it can  leave the expiry timer expire and no more send OLRs.
The other application of the expiry timer is for error or out of sync situa=
tions (Ulrich I think mentioned this point)  where the expiry timer acts as=
 a reset of the DOC mechanism but in such a case the server should  expect =
a sudden increase of traffic from clients generating overload on its side a=
nd then enter in the overload control by generating the relevant OLRs .=20

So for me the use of expiry timer should be quite limited, the main tool of=
 overload control is the % of reduction put the OLRs and its evolution over=
 time. Ben has mentioned other possibilities in the use of the expiry time,=
 may be, but we have to take care of the ones I mentioned =20

So I consider worthwhile to have  some recommendations in the draft on the =
expiry timer use.

Best regards

JJacques=20
=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: mardi 11 f=E9vrier 2014 23:32
=C0=A0: Maria Cruz Bartolome
Cc=A0: dime@ietf.org list
Objet=A0: Re: [Dime] [dime] #46: Bad normative advice on not letting overlo=
ad reports expire


Fine with me.

- Jouni

On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome  wrote:

> Ben, Nirav,
>=20
> I follow same argumentation.
> Regards
> /MCruz
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot=20
> (nsalot)
> Sent: martes, 11 de febrero de 2014 11:23
> To: Ben Campbell; Jouni Korhonen
> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting=20
> overload reports expire
>=20
> Ben,
>=20
> I resonate with your thinking below.
>=20
> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: Monday, February 10, 2014 9:54 PM
> To: Jouni Korhonen
> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting=20
> overload reports expire
>=20
>=20
> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen  wrot=
e:
>=20
>>=20
>> My reasoning for explicit termination was that knowing the=20
>> implementation folks they will let overload conditions expire unless adv=
ised otherwise.
>> And having unnecessary stuff hanging around waiting for a cleanup is=20
>> not a good thing in general. But I am open here for other options..
>>=20
>=20
> I think it's reasonable to say that a reporting node should terminate an =
overload condition in a timely manner. But if it's about to expire anyway, =
then expiration might be just as timely as an explicit report.=20
>=20
> And of course, the definition of "timely" is somewhat a matter of policy.=
 For example, I can imagine an deployment that had a large number of client=
s using fairly short validity durations, and _never_ explicitly signaling a=
n end to an overload condition. This adds a bit of a "slow-start" to the re=
covery, since different clients will expire the overload condition at diffe=
rent times, and the load will ramp up gradually. I don't see anything wrong=
 with that. Of course, it wouldn't work if one chose long validity duration=
s, or if the signaling of overload to different clients happened in close s=
ynchronization.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> 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 jean-jacques.trottin@alcatel-lucent.com  Wed Feb 12 12:47:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806991A06F0 for ; Wed, 12 Feb 2014 12:47:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu5DrHCHZl_e for ; Wed, 12 Feb 2014 12:47:38 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 72D3E1A0450 for ; Wed, 12 Feb 2014 12:47:38 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1CKlZXE001347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Feb 2014 14:47:36 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1CKlZgk016158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Feb 2014 21:47:35 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 21:47:34 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE88aqIYhHfy6k2vf6t9AbBIc5quSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0A==
Date: Wed, 12 Feb 2014 20:47:34 +0000
Message-ID: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202664851FR712WXCHMBA11z_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2014 20:47:49 -0000

--_000_E194C2E18676714DACA9C3A2516265D202664851FR712WXCHMBA11z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_E194C2E18676714DACA9C3A2516265D202664851FR712WXCHMBA11z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)


 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De : DiME [mailto:dime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
span lang=3D"DE">


 


The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.<=
/span>


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 


Best regards


/MCruz


 


 






From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.


 


Ulrich


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 


This comment affects as w=
ell clause 5.5.2:


 


  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 


Best regards


/MCruz


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,


 


This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 


Regards


/MCruz


 






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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):=







 






Section 4.5, first paragraph, last 2 sentences:






 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.<=
/span>






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:=



Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:

Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:



On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:=





On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_E194C2E18676714DACA9C3A2516265D202664851FR712WXCHMBA11z_--


From nsalot@cisco.com  Wed Feb 12 19:11:37 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E981A00B6 for ; Wed, 12 Feb 2014 19:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 917ZtyXuwtvV for ; Wed, 12 Feb 2014 19:11:32 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7D1A00AF for ; Wed, 12 Feb 2014 19:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43235; q=dns/txt; s=iport; t=1392261091; x=1393470691; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=GNVyBI6MiMGXSzXko5gV5ZU04ajrlClJYW+q2hDx2IE=; b=Ziup83+3vbuoCMDR05rxzaYK9IICLGAf+dvXIs3+3l56ONLiywOuymjv Cx4Vg0zK23YpU70b2iao2utZzJs/xxYcJvWFFrndYbGIHkPGrKAs5k4sr kjQqLvvWwCJaUcH5yru438pnMdZfqI5RMsj6Q3LdltDdV/hG7b+bjKQCU 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFABI3/FKtJV2d/2dsb2JhbABZgkZEOFe/OYEXFnSCJQEBAQQBAQEqQRsCAQgRBAEBCxYBBgchBgsUCQgCBAESCIdpAxENv2INiDwTBIxfgUkBAQoULQoBgySBFASJEI0vjkqFQ4MtgXE5
X-IronPort-AV: E=Sophos;i="4.95,836,1384300800";  d="scan'208,217";a="303728933"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 13 Feb 2014 03:11:29 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1D3BT2w028588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 03:11:29 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 21:11:29 -0600
From: "Nirav Salot (nsalot)" 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE84KkJeLCuVkUibLddl7UiIfJquvdYAgABOmACAAAPGAIAABRuAgABhFgCAABzEgIAA6jWAgAE7sYCAAAPPgIAABFqAgAACcICAAL+eAIAABGyw
Date: Thu, 13 Feb 2014 03:11:28 +0000
Message-ID: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.140.46]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6C2C9xmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 03:11:37 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6C2C9xmbrcdx10ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-          0 reduction, non-zero validity period =3D> Valid. The reacting n=
ode can ignore the validity period if reduction is 0.

-          Non-zero reduction, 0 validity period =3D> Valid. The reacting n=
ode can ignore the reduction if validity period is 0.

-          0 reduction, 0 validity period =3D> Valid as well. Generally, th=
is is what the reporting node will use to indicate the end of overload cond=
ition.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_A9CA33BB78081F478946E4F34BF9AAA014D6C2C9xmbrcdx10ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I also tend to agree with=
 JJ below.


Unless there is a strong =
reason, no point in forbidding the use of 0% reduction – which can al=
so indicate end of overload condition.


 <=
/p>

May be we can clarify tha=
t 0% reduction and/or 0 validity period indicates end of overload. In my vi=
ew, both are valid for the use, individually and together.
 So,


- =
        
0 reduction, non-=
zero validity period =3D> Valid. The reacting node can ignore the validi=
ty period if reduction is 0.


- =
        
Non-zero reductio=
n, 0 validity period =3D> Valid. The reacting node can ignore the reduct=
ion if validity period is 0.


- =
        
0 reduction, 0 va=
lidity period =3D> Valid as well. Generally, this is what the reporting =
node will use to indicate the end of overload condition.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)


 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
span lang=3D"DE">


 


The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.<=
/span>


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 


Best regards


/MCruz


 


 






From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.


 


Ulrich


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 


This comment affects as w=
ell clause 5.5.2:


 


  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 


Best regards


/MCruz


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,


 


This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 


Regards


/MCruz


 






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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):=







 






Section 4.5, first paragraph, last 2 sentences:






 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.<=
/span>






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:=



Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:

Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:



On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:=





On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D6C2C9xmbrcdx10ciscoc_--


From jean-jacques.trottin@alcatel-lucent.com  Thu Feb 13 00:55:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112EC1A015B for ; Thu, 13 Feb 2014 00:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPF0I3n4HRNe for ; Thu, 13 Feb 2014 00:55:47 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 31A3C1A0085 for ; Thu, 13 Feb 2014 00:55:47 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1D8tfwb017259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 02:55:43 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1D8teJ2032019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 09:55:41 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 09:55:40 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" , "maria.cruz.bartolome@ericsson.com" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPJ/5W67jltt6LBECHcH6+O45QI5qxoXkAgAE/IXA=
Date: Thu, 13 Feb 2014 08:55:40 +0000
Message-ID: 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.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: [135.239.27.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 08:55:50 -0000

SGkgTWNydXoNCg0KVGhlIGN1cnJlbnQgZGVzY3JpcHRpb24gaW5kaWNhdGVzIHRoYXQgd2hlbiBu
b3QgcHJlc2VudCB0aGUgT0xSIGlzIG9mIHR5cGUgSG9zdCwgd2hpY2ggd2FzIGZpbmUgZm9yIG1l
IGFuZCBrZWVwcyBteSBwcmVmZXJlbmNlLiANCldlIG1heSBoYXZlICBkZXBsb3ltZW50cyB3aGVy
ZSBSZWFsbSBPTFIgaXMgbm90IHVzZWQsIG9yIHdoZXJlIHN0YXRpc3RpY2FsbHkgdGhlIEhPU1Qg
dHlwZSBpcyB0aGUgbW9zdCBmcmVxdWVudCwgc28gdG8gaGF2ZSB0aGUgZ3JvdXBlZCBPTFItQVZQ
IGNvbnRhaW5pbmcgYSBtaW5pbXVtIG9mIEFWUHMgbWluaW1pemVzIHBhcnNpbmcuIEkgYWdyZWUg
aXQgaXMgYSBzbWFsbCBvcHRpbWl6YXRpb24uDQoNCkJlc3QgcmVnYXJkcw0KDQpKSmFjcXVlcyAN
Cg0KDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbQ0KRW52b3nDqcKgOiBtZXJjcmVkaSAxMiBmw6l2cmllciAyMDE0IDE1OjQ2DQrDgMKgOiBk
aW1lQGlldGYub3JnOyBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20NCk9iamV0wqA6
IFJlOiBbRGltZV0gW2RpbWVdICM1NDogT0MtUmVwb3J0LVR5cGUgYXMgbWFuZGF0b3J5IEFWUA0K
DQpIaSBNYXJpYSBDcnV6LA0KDQpJJ20gYXNzdW1pbmcgdGhhdCB5b3UgbWVhbiAicmVxdWlyZWQi
IGluc3RlYWQgb2YgIm1hbmRhdG9yeSIsIHJpZ2h0Pw0KDQpTbyBpbnN0ZWFkIG9mOg0KDQogICBP
Qy1PTFIgOjo9IDwgQVZQIEhlYWRlcjogVEJEMiA+DQogICAgICAgICAgICAgIDwgT0MtU2VxdWVu
Y2UtTnVtYmVyID4NCiAgICAgICAgICAgICAgWyBPQy1SZXBvcnQtVHlwZSBdDQogICAgICAgICAg
ICAgIFsgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgXQ0KICAgICAgICAgICAgICBbIE9DLVZhbGlk
aXR5LUR1cmF0aW9uIF0NCiAgICAgICAgICAgICogWyBBVlAgXQ0KDQpZb3Ugd291bGQgcHJlZmVy
Og0KDQogICBPQy1PTFIgOjo9IDwgQVZQIEhlYWRlcjogVEJEMiA+DQogICAgICAgICAgICAgIDwg
T0MtU2VxdWVuY2UtTnVtYmVyID4NCiAgICAgICAgICAgICAgeyBPQy1SZXBvcnQtVHlwZSB9DQog
ICAgICAgICAgICAgIFsgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgXQ0KICAgICAgICAgICAgICBb
IE9DLVZhbGlkaXR5LUR1cmF0aW9uIF0NCiAgICAgICAgICAgICogWyBBVlAgXQ0KDQpBbmQgSSdt
IGZpbmUgd2l0aCB0aGlzIHByb3Bvc2FsLg0KDQpDaGVlcnMsDQoNCkxpb25lbA0KDQotLS0tLU1l
c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmddIERlIGxhIHBhcnQgZGUgZGltZSBpc3N1ZSB0cmFja2VyIEVudm95w6nCoDogbWVyY3Jl
ZGkgMTIgZsOpdnJpZXIgMjAxNCAxNToyNiDDgMKgOiBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmlj
c3Nvbi5jb20gQ2PCoDogZGltZUBpZXRmLm9yZyBPYmpldMKgOiBbRGltZV0gW2RpbWVdICM1NDog
T0MtUmVwb3J0LVR5cGUgYXMgbWFuZGF0b3J5IEFWUA0KDQojNTQ6IE9DLVJlcG9ydC1UeXBlIGFz
IG1hbmRhdG9yeSBBVlANCg0KIE5vdyBpbiBjaGFwdGVyIDQuNjoNCg0KICAgIFRoZSBkZWZhdWx0
IHZhbHVlIG9mIHRoZSBPQy1SZXBvcnQtVHlwZSBBVlAgaXMgMCAoaS5lLiB0aGUgaG9zdA0KICAg
IHJlcG9ydCkuDQoNCiBUaGlzIEFWUCBpcyBhbHdheXMgcmVxdWlyZWQsIHJpZ2h0PyBUaGVuLCBJ
IHRoaW5rIGl0IGlzIG1vcmUgcHJlY2lzZSB0aGF0ICB3ZSBkZWZpbmUgdGhpcyBBVlAgYXMgbWFu
ZGF0b3J5Lg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQogUmVwb3J0ZXI6ICBtYXJpYS5jcnV6LmJhcnRv
bG9tZUBlcmljc3Nvbi5jb20gIHwgICAgICBPd25lcjogIE1DcnV6DQogICAgIFR5cGU6ICBkZWZl
Y3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIEJhcnRvbG9tw6kNCiBQcmlvcml0eTog
IG1ham9yICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQpD
b21wb25lbnQ6ICBkcmFmdC1kb2NkdC1kaW1lLW92bGkgICAgICAgICAgICAgIHwgIE1pbGVzdG9u
ZToNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgICAgICAgICAgICAgICAgfCAgICBW
ZXJzaW9uOiAgMS4wDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJh
Yy50b29scy5pZXRmLm9yZy93Zy9kaW1lL3RyYWMvdGlja2V0LzU0Pg0KZGltZSA8aHR0cDovL3Rv
b2xzLmlldGYub3JnL3dnL2RpbWUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1l
c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0
aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBw
YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g
U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu
YWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq
b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh
bHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz
YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVz
c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2
aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hv
dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0
aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt
ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpU
aGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo=


From ulrich.wiehe@nsn.com  Thu Feb 13 00:56:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CAA1A0152 for ; Thu, 13 Feb 2014 00:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ2sVHn-yf5X for ; Thu, 13 Feb 2014 00:55:59 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 971801A0179 for ; Thu, 13 Feb 2014 00:55:58 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1D8tlU2004949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 09:55:48 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1D8tg45011578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 09:55:47 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Feb 2014 09:55:44 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 09:55:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext Nirav Salot (nsalot)" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7tgekp4k6zkyUmkn+veC4s5qukxIAgAADxQCAAAUcgIAAYRYAgAAcxICAAPpJ0IABO9pAgAAD4vD///QJgIAAExhQgACu9wCAAGtCAIAAbt8Q
Date: Thu, 13 Feb 2014 08:55:43 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3207DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 46368
X-purgate-ID: 151667::1392281749-00001A6F-94A91353/0-0/0-0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 08:56:07 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3207DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I also agree with the principle.

One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-          0 reduction, non-zero validity period =3D> Valid. The reacting n=
ode can ignore the validity period if reduction is 0.

-          Non-zero reduction, 0 validity period =3D> Valid. The reacting n=
ode can ignore the reduction if validity period is 0.

-          0 reduction, 0 validity period =3D> Valid as well. Generally, th=
is is what the reporting node will use to indicate the end of overload cond=
ition.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3207DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I also agr=
ee with the principle.


 =
;


One minor =
clarification:


0%-reducti=
on with non-zero validity period is valid but validity period cannot be ign=
ored: as long as not expired the sequence number needs to
 be stored for future checking; once expired, sequence number must not be u=
sed for future checking.


 =
;


Ulrich


 =
;






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Nirav Salot (nsalot)

Sent: Thursday, February 13, 2014 4:11 AM

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I also ten=
d to agree with JJ below.


Unless the=
re is a strong reason, no point in forbidding the use of 0% reduction ̵=
1; which can also indicate end of overload condition.


 =
;


May be we =
can clarify that 0% reduction and/or 0 validity period indicates end of ove=
rload. In my view, both are valid for the use, individually
 and together. So,


-         
0 =
reduction, non-zero validity period =3D> Valid. The reacting node can ig=
nore the validity period if reduction is 0.


-         
No=
n-zero reduction, 0 validity period =3D> Valid. The reacting node can ig=
nore the reduction if validity period is 0.


-         
0 =
reduction, 0 validity period =3D> Valid as well. Generally, this is what=
 the reporting node will use to indicate the end of overload
 condition. 


 =
;


Regards,


Nirav.


 =
;






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 =
;


On this ti=
cket,  I agree on Ben’s  proposal  to use the Validity=
 period of 0 to indicate the end of overload.


But about =
the value of 0% reduction why to forbid it ?


 =
;


In the pro=
cess to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no=
 request anymore
 traffic reduction but without being yet sure if  it will be  sta=
ble (end of overload condition as Ben reminded means stable  situation=
 without traffic reduction ) , so server  can send 0% reduction OLR&nb=
sp; but with a validity duration different from 0.



Otherwise =
it has to  use 1% throttling to check stability and if traffic with th=
e client is 1000 request per second this means 10 requests throttled
 per second which should not be throttled.


In additio=
n, we do not need to handle the 0% reduction  as an error case (cf Mcr=
uz mail)


 =
;


Best regar=
ds


 =
;


JJacques



 =
;


 =
;






De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you =
for the clarification.


I agree.


 






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulric=
h, all,


 


The propos=
al was to use OC-Validity-Duration AVP =3D0 to indicate end of overload, si=
nce this could be generally applied to any algorithm.


Then, Redu=
ction-Percentage =3D 0 should be considered as invalid.

I found th=
is reasonable.


 


Best regar=
ds


/MCruz


 


 






From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m confused,


 <=
/p>

I thought =
that people were in favour of allowing 0 to indicate end of overload.


 


Ulrich


 






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,<=
/span>


 


This comme=
nt affects as well clause 5.5.2:


 


  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This shoul=
d be modified to explain this value is not valid and what is the expected b=
ehavior (i.e. it is discarded).


 


Best regar=
ds


/MCruz


 






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,


 


This appro=
ach sounds reasonable to me.


But I woul=
d like to clarify what should be the behavior if a Reduction-Percentage=3D0=
 is received. This is an invalid value, then I presume it should
 be discarded by client. 


 


Regards


/MCruz


 






From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of Ben Campbell

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. =
(intentionally ignoring the related discussion about handling invalid value=
s):






 






Section 4.5, first paragraph, l=
ast 2 sentences:






 






Old:






 






Validity duration values 0 (i.e=
., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid va=
lidity duration values are treated as if the OC-Validity-Duration AVP were =
not present.






 






New:






 






Validity duration values above =
86400 MUST NOT be used. Invalid validity duration values are treated as if =
the OC-Validity-Duration AVP were not present. A value of zero (0) indicate=
s that an existing overload condition
 has ended and that the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reductio=
n-Percentage AVP is between one (1) and one hundred (100).  Values gre=
ater than 100 are interpreted as 100.  The value of 100 means that no =
traffic is expected, i.e. the reporting node is under
 a severe load and ceases to process any new messages. The Reduction-Percen=
tage AVP MUST be present in an overload report that uses the default abatem=
ent algorithm.








 










Note that there is no zero (0) =
value defined for the Reduction-Percentage AVP. A zero value would logicall=
y indicate that no overload abatement is requested. Instead, reporting node=
s use a OC-Validity-Duration AVP value
 of zero (0) to indicate the end of an overload condition. [Section 4.5]










 






 






 






 






 




=


On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=
Just post it here.







On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


=
Okay. Does that mean we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=


Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:


=


On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


=


On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration=
 of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)


=


Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.


=


I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3207DEMUMBX014nsnin_--


From jean-jacques.trottin@alcatel-lucent.com  Thu Feb 13 01:23:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B302C1A0177 for ; Thu, 13 Feb 2014 01:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_UaBPrE2teH for ; Thu, 13 Feb 2014 01:23:35 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id E6EAB1A00FA for ; Thu, 13 Feb 2014 01:23:34 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1D9NVsA028645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Feb 2014 03:23:32 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1D9NUdi010229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Feb 2014 10:23:30 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 10:23:30 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE88aqIYhHfy6k2vf6t9AbBIc5quSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIA==
Date: Thu, 13 Feb 2014 09:23:30 +0000
Message-ID: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026649BCFR712WXCHMBA11z_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 09:23:40 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026649BCFR712WXCHMBA11z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am OK with Ulrich

JJacques


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56
=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@=
ietf.org list
Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also agree with the principle.

One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-          0 reduction, non-zero validity period =3D> Valid. The reacting n=
ode can ignore the validity period if reduction is 0.

-          Non-zero reduction, 0 validity period =3D> Valid. The reacting n=
ode can ignore the reduction if validity period is 0.

-          0 reduction, 0 validity period =3D> Valid as well. Generally, th=
is is what the reporting node will use to indicate the end of overload cond=
ition.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_E194C2E18676714DACA9C3A2516265D2026649BCFR712WXCHMBA11z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I am OK with Ulrich<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@ns=
n.com]


Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56

=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES); dime@ietf.org list

Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


I also agree with the pri=
nciple.


 <=
/p>

One minor clarification:<=
o:p>


0%-reduction with non-zer=
o validity period is valid but validity period cannot be ignored: as long a=
s not expired the sequence number needs to be stored for
 future checking; once expired, sequence number must not be used for future=
 checking.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Nirav Salot (nsalot)

Sent: Thursday, February 13, 2014 4:11 AM

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I also tend to agree with=
 JJ below.


Unless there is a strong =
reason, no point in forbidding the use of 0% reduction – which can al=
so indicate end of overload condition.


 <=
/p>

May be we can clarify tha=
t 0% reduction and/or 0 validity period indicates end of overload. In my vi=
ew, both are valid for the use, individually and together.
 So,


- =
;        
0 reduction, non-=
zero validity period =3D> Valid. The reacting node can ignore the validi=
ty period if reduction is 0.


- =
;        
Non-zero reductio=
n, 0 validity period =3D> Valid. The reacting node can ignore the reduct=
ion if validity period is 0.


- =
;        
0 reduction, 0 va=
lidity period =3D> Valid as well. Generally, this is what the reporting =
node will use to indicate the end of overload condition.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)


 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
span lang=3D"DE">


 


The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.<=
/span>


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 


Best regards


/MCruz


 


 






From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.


 


Ulrich


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 


This comment affects as w=
ell clause 5.5.2:


 


  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 


Best regards


/MCruz


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,


 


This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 


Regards


/MCruz


 






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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):=







 






Section 4.5, first paragraph, last 2 sentences:






 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.<=
/span>






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:=



Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:

Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:



On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:=





On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_E194C2E18676714DACA9C3A2516265D2026649BCFR712WXCHMBA11z_--


From maria.cruz.bartolome@ericsson.com  Thu Feb 13 01:56:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB61F1A0117 for ; Thu, 13 Feb 2014 01:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHr_08vnbaqb for ; Thu, 13 Feb 2014 01:56:24 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 21C971A0110 for ; Thu, 13 Feb 2014 01:56:22 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-fa-52fc96c40353
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D2.46.04249.4C69CF25; Thu, 13 Feb 2014 10:56:21 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 10:56:20 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpquSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAWswAgABgL4CAAAfDAIAAGFdA
Date: Thu, 13 Feb 2014 09:56:20 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774896ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje7RaX+CDGbt57WY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQ8uPmUrWNnCXLHi4h2WBsZ915m6GDk5JARMJHbtu8EKYYtJ XLi3nq2LkYtDSOAIo8SeX/fZQBJCAksYJeY+kwOx2QTsJC6dfgHUzMEhIqAhseJEJkhYWMBb 4seHy2AzRQR8JHobj4DNERGYxihx5d9RRpAEi4CqxP9jL8CKeAV8JX49e8oIsayVQ6LxyC1m kASnQKzE2ol7wBYzAl30/dQasAZmAXGJW0/mQ10tILFkz3lmCFtU4uXjf1AfKEksuv0Zqj5f 4s6Zx8wQywQlTs58wjKBUWQWklGzkJTNQlIGEdeTuDF1ChuErS2xbOFrZghbV2LGv0MsyOIL GNlXMXIUpxYn5aYbGWxiBMbLwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MkhmNG5cGW5jZ9Nq1ea8P+FKsWvZH3I1rqbC1cLJLQWRemMxHFx2l4FVf vB5zMYdN6Vfnnva/ct2MWGuRXzGau9g8U1vvzJLrWGln5+N4/np+Wqzw69S1bA9nGcdL5dT8 P1VyMfh1n5vNy/Tqt4Ufv7QEt1yznO91s3b1i+MHdso/7/+wZocSS3FGoqEWc1FxIgAqwWr8 ZQIAAA==
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 09:56:30 -0000

--_000_087A34937E64E74E848732CFF8354B9209774896ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,

I think proposal to use just Validity-Duration=3D0 to end overload mainly h=
as the intention to simplify and avoid the checks you just listed below.
If we allow both, it means that the case Ulrich mentioned is valid, and eve=
n with 0% reduction OLR info cannot be deleted until Validity time expires,=
 even we could receive a new OLR in sequence. Even, the reporting needs sti=
ll to keep Validity timer on for this OLR.
I think this does not provide any added value but simply makes things a bit=
 more complex. What could be the reason to keep 0% reduction but a Validity=
 of a few hours (e.g.)?

Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: jueves, 13 de febrero de 2014 10:24
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I am OK with Ulrich

JJacques


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56
=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@=
ietf.org list
Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also agree with the principle.

One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-        0 reduction, non-zero validity period =3D> Valid. The reacting nod=
e can ignore the validity period if reduction is 0.

-        Non-zero reduction, 0 validity period =3D> Valid. The reacting nod=
e can ignore the reduction if validity period is 0.

-        0 reduction, 0 validity period =3D> Valid as well. Generally, this=
 is what the reporting node will use to indicate the end of overload condit=
ion.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_087A34937E64E74E848732CFF8354B9209774896ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello all,


 <=
/p>

I think proposal to use j=
ust Validity-Duration=3D0 to end overload mainly has the intention to simpl=
ify and avoid the checks you just listed below.


If we allow both, it mean=
s that the case Ulrich mentioned is valid, and even with 0% reduction OLR i=
nfo cannot be deleted until Validity time expires, even
 we could receive a new OLR in sequence. Even, the reporting needs still to=
 keep Validity timer on for this OLR.


I think this does not pro=
vide any added value but simply makes things a bit more complex. What could=
 be the reason to keep 0% reduction but a Validity of a
 few hours (e.g.)?


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: jueves, 13 de febrero de 2014 10:24

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I am OK with Ulrich


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56

=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES); 
dime@ietf.org list

Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


I also agree with the pri=
nciple.


 <=
/p>

One minor clarification:<=
/span>


0%-reduction with non-zer=
o validity period is valid but validity period cannot be ignored: as long a=
s not expired the sequence number needs to be stored for
 future checking; once expired, sequence number must not be used for future=
 checking.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Nirav Salot (nsalot)

Sent: Thursday, February 13, 2014 4:11 AM

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I also tend to agree with=
 JJ below.


Unless there is a strong =
reason, no point in forbidding the use of 0% reduction – which can al=
so indicate end of overload condition.


 <=
/p>

May be we can clarify tha=
t 0% reduction and/or 0 validity period indicates end of overload. In my vi=
ew, both are valid for the use, individually and together.
 So,


-      =
 
0 reduction, non-=
zero validity period =3D> Valid. The reacting node can ignore the validi=
ty period if reduction is 0.


-      =
 
Non-zero reductio=
n, 0 validity period =3D> Valid. The reacting node can ignore the reduct=
ion if validity period is 0.


-      =
 
0 reduction, 0 va=
lidity period =3D> Valid as well. Generally, this is what the reporting =
node will use to indicate the end of overload condition.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)=



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
o:p>


 <=
/p>

The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.

 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 <=
/p>

This comment affects as w=
ell clause 5.5.2:


 <=
/p>

  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:




On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_087A34937E64E74E848732CFF8354B9209774896ESESSMB101erics_--


From jean-jacques.trottin@alcatel-lucent.com  Thu Feb 13 02:43:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF74F1A01D1 for ; Thu, 13 Feb 2014 02:43:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-TXCKSm3Vau for ; Thu, 13 Feb 2014 02:43:15 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 692E51A01CD for ; Thu, 13 Feb 2014 02:43:15 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1DAh9sZ017565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 04:43:11 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1DAh8MJ026385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 11:43:09 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 11:43:09 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Maria Cruz Bartolome , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE88aqIYhHfy6k2vf6t9AbBIc5quSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8IA=
Date: Thu, 13 Feb 2014 10:43:08 +0000
Message-ID: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026649F8FR712WXCHMBA11z_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 10:43:23 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026649F8FR712WXCHMBA11z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi MCruz

AS  Ben proposed, and I agree,   value of zero (0) for the Validity period =
indicates that an existing overload condition has ended and that the report=
ing node is in a stable condition.
An important word is "stable".

When the traffic peak on client side having created the overload decreases,=
   the reporting node progressively diminishes the % traffic reduction in O=
LRs it sends  towards clients taking care to minimize the possible oscillat=
ions. At a certain time ,  server will consider that it can indicate no tra=
ffic reduction to clients. Then is it stable?  there may be different imple=
mentation dependent  ways for the server to decide the situation is stable;=
  one is to send 0% in OLRs and wait a certain number of seconds (not 24 ho=
urs) to check if situation is stable  and then put the validity timer to 0 =
(or leaves the expiry timer  expire). I do not see why to forbid this  way =
to test the stable condition.

So the end of overload condition, as Ben proposed,  can remain ONLY based o=
n Validity  duration value 0 (or timer expiry), not on the value 0 of the %=
 reduction (so a bit different from Nirav statement, but in line with Ulric=
h comment) . The value 0% of the traffic reduction is not forbidden as a po=
ssible  way to check the stability condition .

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56
=C0 : dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hello all,

I think proposal to use just Validity-Duration=3D0 to end overload mainly h=
as the intention to simplify and avoid the checks you just listed below.
If we allow both, it means that the case Ulrich mentioned is valid, and eve=
n with 0% reduction OLR info cannot be deleted until Validity time expires,=
 even we could receive a new OLR in sequence. Even, the reporting needs sti=
ll to keep Validity timer on for this OLR.
I think this does not provide any added value but simply makes things a bit=
 more complex. What could be the reason to keep 0% reduction but a Validity=
 of a few hours (e.g.)?

Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: jueves, 13 de febrero de 2014 10:24
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I am OK with Ulrich

JJacques


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56
=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@=
ietf.org list
Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also agree with the principle.

One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-          0 reduction, non-zero validity period =3D> Valid. The reacting n=
ode can ignore the validity period if reduction is 0.

-          Non-zero reduction, 0 validity period =3D> Valid. The reacting n=
ode can ignore the reduction if validity period is 0.

-          0 reduction, 0 validity period =3D> Valid as well. Generally, th=
is is what the reporting node will use to indicate the end of overload cond=
ition.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_E194C2E18676714DACA9C3A2516265D2026649F8FR712WXCHMBA11z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi MCruz


 <=
/p>

AS  Ben proposed, an=
d I agree,   value of zero (0) for the Validity period indicates =
that an existing overload condition has ended and that the reporting node
 is in a stable condition.


An important word is R=
20;stable”.


 <=
/p>

When the traffic peak on =
client side having created the overload decreases,   the reportin=
g node progressively diminishes the % traffic reduction in OLRs it
 sends  towards clients taking care to minimize the possible oscillati=
ons. At a certain time ,  server will consider that it can indicate no=
 traffic reduction to clients. Then is it stable?  there may be differ=
ent implementation dependent  ways for the server
 to decide the situation is stable;  one is to send 0% in OLRs and wai=
t a certain number of seconds (not 24 hours) to check if situation is stabl=
e  and then put the validity timer to 0 (or leaves the expiry timer &n=
bsp;expire). I do not see why to forbid this  way
 to test the stable condition.


 <=
/p>

So the end of overload co=
ndition, as Ben proposed,  can remain ONLY based on Validity  dur=
ation value 0 (or timer expiry), not on the value 0 of the % reduction
 (so a bit different from Nirav statement, but in line with Ulrich comment)=
 . The value 0% of the traffic reduction is not forbidden as a possible &nb=
sp;way to check the stability condition .


 <=
/p>

Best regards



 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56

=C0 : dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Hello all,


 <=
/p>

I think proposal to use j=
ust Validity-Duration=3D0 to end overload mainly has the intention to simpl=
ify and avoid the checks you just listed below.


If we allow both, it mean=
s that the case Ulrich mentioned is valid, and even with 0% reduction OLR i=
nfo cannot be deleted until Validity time expires, even
 we could receive a new OLR in sequence. Even, the reporting needs still to=
 keep Validity timer on for this OLR.


I think this does not pro=
vide any added value but simply makes things a bit more complex. What could=
 be the reason to keep 0% reduction but a Validity of a
 few hours (e.g.)?


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: jueves, 13 de febrero de 2014 10:24

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I am OK with Ulrich


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56

=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES); 
dime@ietf.org list

Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


I also agree with the pri=
nciple.


 <=
/p>

One minor clarification:<=
/span>


0%-reduction with non-zer=
o validity period is valid but validity period cannot be ignored: as long a=
s not expired the sequence number needs to be stored for
 future checking; once expired, sequence number must not be used for future=
 checking.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Nirav Salot (nsalot)

Sent: Thursday, February 13, 2014 4:11 AM

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I also tend to agree with=
 JJ below.


Unless there is a strong =
reason, no point in forbidding the use of 0% reduction – which can al=
so indicate end of overload condition.


 <=
/p>

May be we can clarify tha=
t 0% reduction and/or 0 validity period indicates end of overload. In my vi=
ew, both are valid for the use, individually and together.
 So,


-      =
   
0 reduction, non-=
zero validity period =3D> Valid. The reacting node can ignore the validi=
ty period if reduction is 0.


-      =
   
Non-zero reductio=
n, 0 validity period =3D> Valid. The reacting node can ignore the reduct=
ion if validity period is 0.


-      =
   
0 reduction, 0 va=
lidity period =3D> Valid as well. Generally, this is what the reporting =
node will use to indicate the end of overload condition.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)=



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
o:p>


 <=
/p>

The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.

 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 <=
/p>

This comment affects as w=
ell clause 5.5.2:


 <=
/p>

  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:




On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_E194C2E18676714DACA9C3A2516265D2026649F8FR712WXCHMBA11z_--


From maria.cruz.bartolome@ericsson.com  Thu Feb 13 03:05:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C701A01DD for ; Thu, 13 Feb 2014 03:05:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbRMsG8vc2az for ; Thu, 13 Feb 2014 03:04:56 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 06A3F1A01D1 for ; Thu, 13 Feb 2014 03:04:54 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-52-52fca6d420f6
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id B0.9B.04853.4D6ACF25; Thu, 13 Feb 2014 12:04:53 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 12:04:52 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpquSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAWswAgABgL4CAAAfDAIAAGFdA///96QCAABU6EA==
Date: Thu, 13 Feb 2014 11:04:51 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097749A2@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097749A2ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje7VZX+CDLa9Y7GY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGd+PdrAWnDzHXLHvxB2WBsbmmcxdjJwcEgImEv1fDjBC2GIS F+6tZ+ti5OIQEjjBKPH09S5WCGcJo8TJF/PAOtgE7CQunX7B1MXIwSEioCGx4kQmSFhYwFvi x4fLTCC2iICPRG/jETYIexmjRPOeIJByFgFVifMteSBhXgFfiZ8Tn7FDjJ/DKbFp/3ew8ZwC sRL/VqxnAbEZgQ76fmoN2ExmAXGJW0/mM0EcKiCxZM95qAdEJV4+/scKYStJLLr9Gao+X2J6 y2Q2iGWCEidnPmGZwCgyC8moWUjKZiEpg4jrSdyYOoUNwtaWWLbwNTOErSsx498hFmTxBYzs qxgli1OLi3PTjQz0ctNzS/RSizKTi4vz8/SKUzcxAuPp4JbfRjsYT+6xP8QozcGiJM57nbUm SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjdGtfe+XNlyvdr2/cMXGPePBE149eAkEfzqhm et93iRVvSbQ4lnrjv2JqUFTEIpHrq48pmG0pvzdnYfVll9k3HktsWXLliAlLvFJN97LyjaHi FXlr1t+Jn/yD/dwhlcPN62Q638XqZE202s36cNksveXCitUeJ2++nOcU1pa2LjhZ9+KvHqvT SizFGYmGWsxFxYkASKJ5+XUCAAA=
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 11:05:05 -0000

--_000_087A34937E64E74E848732CFF8354B92097749A2ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear JJ,

But...  0% for a reacting node means that it does not need to mitigate traf=
fic, and for a reporting node means it is not expecting any mitigation from=
 this client.
Keeping a Validity duration timer on both reporting and reacting on itself =
does not provide any mechanism to improve stability, or?

Cheers
/MCruz

From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc=
atel-lucent.com]
Sent: jueves, 13 de febrero de 2014 11:43
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hi MCruz

AS  Ben proposed, and I agree,   value of zero (0) for the Validity period =
indicates that an existing overload condition has ended and that the report=
ing node is in a stable condition.
An important word is "stable".

When the traffic peak on client side having created the overload decreases,=
   the reporting node progressively diminishes the % traffic reduction in O=
LRs it sends  towards clients taking care to minimize the possible oscillat=
ions. At a certain time ,  server will consider that it can indicate no tra=
ffic reduction to clients. Then is it stable?  there may be different imple=
mentation dependent  ways for the server to decide the situation is stable;=
  one is to send 0% in OLRs and wait a certain number of seconds (not 24 ho=
urs) to check if situation is stable  and then put the validity timer to 0 =
(or leaves the expiry timer  expire). I do not see why to forbid this  way =
to test the stable condition.

So the end of overload condition, as Ben proposed,  can remain ONLY based o=
n Validity  duration value 0 (or timer expiry), not on the value 0 of the %=
 reduction (so a bit different from Nirav statement, but in line with Ulric=
h comment) . The value 0% of the traffic reduction is not forbidden as a po=
ssible  way to check the stability condition .

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56
=C0 : dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hello all,

I think proposal to use just Validity-Duration=3D0 to end overload mainly h=
as the intention to simplify and avoid the checks you just listed below.
If we allow both, it means that the case Ulrich mentioned is valid, and eve=
n with 0% reduction OLR info cannot be deleted until Validity time expires,=
 even we could receive a new OLR in sequence. Even, the reporting needs sti=
ll to keep Validity timer on for this OLR.
I think this does not provide any added value but simply makes things a bit=
 more complex. What could be the reason to keep 0% reduction but a Validity=
 of a few hours (e.g.)?

Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: jueves, 13 de febrero de 2014 10:24
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I am OK with Ulrich

JJacques


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56
=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@=
ietf.org list
Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also agree with the principle.

One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-        0 reduction, non-zero validity period =3D> Valid. The reacting nod=
e can ignore the validity period if reduction is 0.

-        Non-zero reduction, 0 validity period =3D> Valid. The reacting nod=
e can ignore the reduction if validity period is 0.

-        0 reduction, 0 validity period =3D> Valid as well. Generally, this=
 is what the reporting node will use to indicate the end of overload condit=
ion.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



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


--_000_087A34937E64E74E848732CFF8354B92097749A2ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear JJ,


 <=
/p>

But…  0% for a=
 reacting node means that it does not need to mitigate traffic, and for a r=
eporting node means it is not expecting any mitigation from this client.


Keeping a Validity durati=
on timer on both reporting and reacting on itself does not provide any mech=
anism to improve stability, or?


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: TROTTIN,=
 JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alcatel-lucent.co=
m]


Sent: jueves, 13 de febrero de 2014 11:43

To: Maria Cruz Bartolome; dime@ietf.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Hi MCruz


 <=
/p>

AS  Ben proposed, an=
d I agree,   value of zero (0) for the Validity period indicates =
that an existing overload condition has ended and that the reporting node
 is in a stable condition.


An important word is R=
20;stable”.


 <=
/p>

When the traffic peak on =
client side having created the overload decreases,   the reportin=
g node progressively diminishes the % traffic reduction in OLRs it
 sends  towards clients taking care to minimize the possible oscillati=
ons. At a certain time ,  server will consider that it can indicate no=
 traffic reduction to clients. Then is it stable?  there may be differ=
ent implementation dependent  ways for the server
 to decide the situation is stable;  one is to send 0% in OLRs and wai=
t a certain number of seconds (not 24 hours) to check if situation is stabl=
e  and then put the validity timer to 0 (or leaves the expiry timer &n=
bsp;expire). I do not see why to forbid this  way
 to test the stable condition.


 <=
/p>

So the end of overload co=
ndition, as Ben proposed,  can remain ONLY based on Validity  dur=
ation value 0 (or timer expiry), not on the value 0 of the % reduction
 (so a bit different from Nirav statement, but in line with Ulrich comment)=
 . The value 0% of the traffic reduction is not forbidden as a possible &nb=
sp;way to check the stability condition .


 <=
/p>

Best regards



 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56

=C0 : dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Hello all,


 <=
/p>

I think proposal to use j=
ust Validity-Duration=3D0 to end overload mainly has the intention to simpl=
ify and avoid the checks you just listed below.


If we allow both, it mean=
s that the case Ulrich mentioned is valid, and even with 0% reduction OLR i=
nfo cannot be deleted until Validity time expires, even
 we could receive a new OLR in sequence. Even, the reporting needs still to=
 keep Validity timer on for this OLR.


I think this does not pro=
vide any added value but simply makes things a bit more complex. What could=
 be the reason to keep 0% reduction but a Validity of a
 few hours (e.g.)?


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: jueves, 13 de febrero de 2014 10:24

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I am OK with Ulrich


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56

=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES); 
dime@ietf.org list

Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


I also agree with the pri=
nciple.


 <=
/p>

One minor clarification:<=
/span>


0%-reduction with non-zer=
o validity period is valid but validity period cannot be ignored: as long a=
s not expired the sequence number needs to be stored for
 future checking; once expired, sequence number must not be used for future=
 checking.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Nirav Salot (nsalot)

Sent: Thursday, February 13, 2014 4:11 AM

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I also tend to agree with=
 JJ below.


Unless there is a strong =
reason, no point in forbidding the use of 0% reduction – which can al=
so indicate end of overload condition.


 <=
/p>

May be we can clarify tha=
t 0% reduction and/or 0 validity period indicates end of overload. In my vi=
ew, both are valid for the use, individually and together.
 So,


-      =
 
0 reduction, non-=
zero validity period =3D> Valid. The reacting node can ignore the validi=
ty period if reduction is 0.


-      =
 
Non-zero reductio=
n, 0 validity period =3D> Valid. The reacting node can ignore the reduct=
ion if validity period is 0.


-      =
 
0 reduction, 0 va=
lidity period =3D> Valid as well. Generally, this is what the reporting =
node will use to indicate the end of overload condition.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)=



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
o:p>


 <=
/p>

The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.

 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 <=
/p>

This comment affects as w=
ell clause 5.5.2:


 <=
/p>

  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:




On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 






--_000_087A34937E64E74E848732CFF8354B92097749A2ESESSMB101erics_--


From jouni.nospam@gmail.com  Thu Feb 13 04:05:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0411A01FC for ; Thu, 13 Feb 2014 04:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNzROp_AB74T for ; Thu, 13 Feb 2014 04:05:32 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4E77B1A01FA for ; Thu, 13 Feb 2014 04:05:32 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id y1so8067888lam.36 for ; Thu, 13 Feb 2014 04:05:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RHpmTDlbQKxx7FmmExBBC43E7F6x3etQok0fNHxhHm8=; b=E24B/cJBHkZFF67BBW20K8GeDLbQail2IJuUQwN1SAnVwXNvQqcrUq0f9V/IJXSwvo E7p1cL0pfIidv4jJjxKDozFib+YYQleA1FIXJ7qcL0RnaTWhRUAyCKsshCSLIc2oXBJx IXadk0e05kZVfulr0nE4AWUJ3g3SIOCSma0yWcN99w0o4/JCWVwcKS8NVj55Q7HKE2Ag 2b3F29rMQ1m2RxaCqj2ejHg0OafpOGRYPyQvYE76npc22ZnxD+Psb6acjHvnvYIxbkih HjgPRQeUWNnLHLTguGiFlLZumUSzTbFb5YJ21QKor+v3wnxmJEwbuiyXlThU83CntD5k h93A==
X-Received: by 10.112.253.34 with SMTP id zx2mr729928lbc.61.1392293130438; Thu, 13 Feb 2014 04:05:30 -0800 (PST)
Received: from [192.168.250.109] ([194.100.71.98]) by mx.google.com with ESMTPSA id cl5sm1850780lbb.14.2014.02.13.04.05.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 04:05:29 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Thu, 13 Feb 2014 14:05:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:05:34 -0000

Agree that it is a small optimization, which I put there
because at the beginning there seemed to be a lot of worry
on every extra AVP ;-)

I prefer having the AVP optional but with a default value
just like it is now. We have the same for the reduction
percentage and the validity time as well.

- Jouni

On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:

> Hi Mcruz
>=20
> The current description indicates that when not present the OLR is of =
type Host, which was fine for me and keeps my preference.=20
> We may have  deployments where Realm OLR is not used, or where =
statistically the HOST type is the most frequent, so to have the grouped =
OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a =
small optimization.
>=20
> Best regards
>=20
> JJacques=20
>=20
>=20
>=20
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de =
lionel.morand@orange.com
> Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46
> =C0 : dime@ietf.org; maria.cruz.bartolome@ericsson.com
> Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>=20
> Hi Maria Cruz,
>=20
> I'm assuming that you mean "required" instead of "mandatory", right?
>=20
> So instead of:
>=20
>   OC-OLR ::=3D < AVP Header: TBD2 >
>              < OC-Sequence-Number >
>              [ OC-Report-Type ]
>              [ OC-Reduction-Percentage ]
>              [ OC-Validity-Duration ]
>            * [ AVP ]
>=20
> You would prefer:
>=20
>   OC-OLR ::=3D < AVP Header: TBD2 >
>              < OC-Sequence-Number >
>              { OC-Report-Type }
>              [ OC-Reduction-Percentage ]
>              [ OC-Validity-Duration ]
>            * [ AVP ]
>=20
> And I'm fine with this proposal.
>=20
> Cheers,
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue =
tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 : =
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] =
[dime] #54: OC-Report-Type as mandatory AVP
>=20
> #54: OC-Report-Type as mandatory AVP
>=20
> Now in chapter 4.6:
>=20
>    The default value of the OC-Report-Type AVP is 0 (i.e. the host
>    report).
>=20
> This AVP is always required, right? Then, I think it is more precise =
that  we define this AVP as mandatory.
>=20
> --=20
> =
-----------------------------------------------+------------------------
> -----------------------------------------------+---
> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>     Type:  defect                             |  Bartolom=E9
> Priority:  major                              |     Status:  new
> Component:  draft-docdt-dime-ovli              |  Milestone:
> Severity:  Active WG Document                 |    Version:  1.0
>                                               |   Keywords:
> =
-----------------------------------------------+------------------------
> -----------------------------------------------+---
>=20
> Ticket URL: 
> dime 
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> 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 maria.cruz.bartolome@ericsson.com  Thu Feb 13 01:01:17 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC741A017C for ; Thu, 13 Feb 2014 01:01:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB5mzzvM8F_7 for ; Thu, 13 Feb 2014 01:01:09 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 50A651A0169 for ; Thu, 13 Feb 2014 01:01:07 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-3c-52fc89d11b80
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 26.47.04853.1D98CF25; Thu, 13 Feb 2014 10:01:05 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 10:01:04 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsA==
Date: Thu, 13 Feb 2014 09:01:04 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774836ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje7Fzj9BBvN/yljM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLv/zzAWnPvHVTHta2AD44ZbXF2MnBwSAiYSq3bNYIOwxSQu 3FsPZHNxCAmcYJSYdWAyO4SzhFHi6o3VLCBVbAJ2EpdOv2DqYuTgEBFQljj9ywEkLCxQLvHy 0hVmEFtEoELi89ZLTCC9IgKPGCWuvd7FBJJgEVCVuPb1BNg2XgFfiR9vH7NCLFjPJ7Gy4yk7 SIJTIFZi0ubJYMsYgU76fmoNWDOzgLjErSfzmSBOFZBYsuc8M4QtKvHy8T9WCFtJYtHtz1D1 +RIvt3SzQCwTlDg58wnLBEaRWUhGzUJSNgtJ2Syg35gFNCXW79KHKFGUmNL9kB3C1pBonTOX HVl8ASP7KkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2MwHg6uOW30Q7Gk3vsDzFKc7Ao ifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4SfNF+S/7mOCyK5+roq8mmiQvns9w LP91strjyb8LTqXXpNgIxrQ8+piwg1OjuXGLodbh1zviLEVT71d9z6gMm3Jmd2Dgp0orzq2Z qaw380qPGsffWOxf/95m3y1lfk+3HQo9xk2ymw+mqX+vX7n15ZGVqskffZneNVbqHKuNWeVt acvv9VWJpTgj0VCLuag4EQCljwsBdQIAAA==
X-Mailman-Approved-At: Thu, 13 Feb 2014 04:06:59 -0800
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 09:01:17 -0000

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

RGVhciBhbGwsDQoNCkkgdGhpbmsgdGhlbiB3ZSBhZ3JlZSBvbiB0aGUgcHJvcG9zZWQgdGV4dDoN
Cg0KQSByZXBvcnRpbmcgbm9kZSBNVVNUIGVuc3VyZSB0aGF0IGFsbCByZWFjdGluZyBub2RlcyBy
ZWNlaXZlIG5ldyBvdmVybG9hZCByZXBvcnRzLg0KDQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEg
cmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVz
c2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4NCg0KTm90ZSAtIHRoZSByZXBvcnRpbmcgbm9k
ZSBtYXkgYWxzbyBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYW5zd2VyIG1lc3NhZ2Vz
IHNlbnQgdG8gbm9uIHJlYWN0aW5nIG5vZGVzIGlmIHRoYXQgaXMgbW9yZSBlZmZpY2llbnQuICBU
aGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9k
ZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy4NCg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hv
b3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYg
aXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2Vp
dmVkIHRoZSBvdmVybG9hZCByZXBvcnQuDQoNCg0KQnV0IHN0aWxsIHRoZXJlIGFyZSBzb21lIGRp
c2NyZXBhbmNpZXMgYWJvdXQgdGhlIG5vdGUuDQpNeSBwcm9wb3NhbCBpcyB0byBrZWVwIGl0IGp1
c3QgYXMgYW4gaW5kaWNhdGlvbiBvZiBwb3RlbnRpYWwgKG1heWJlIG5vdCBhbGwpIHNpdHVhdGlv
bnMgdGhhdCBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50IGlmIGV2ZXIgYW55IGltcGxlbWVu
dGF0aW9uIG1heSBjb25zaWRlciB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiB0
aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3
ZXIgbWVzc2FnZXMuDQpCZWluZyBhIHJlY29tbWVuZGF0aW9uIGFuZCBub3QgYSBtdXN0LCBhdCBs
ZWFzdCBJIHRoaW5rIHdlIG5lZWQgdG8gaW5kaWNhdGUgd2hhdCBtYXkgaW1wbHkgdG8gZG8gbm90
IGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24uDQpUaGVuIG15IHByb3Bvc2FsIGlzIHRoZSBmb2xs
b3dpbmcsIHRoYXQgaW5jbHVkZXMgYSBtb2RpZmljYXRpb24gdG8gbGFzdCBzZW50ZW5jZSBhYm92
ZToNCg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2Fk
IHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoaXMg
b3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLg0K
DQpOb3RlIOKAk3RoZSByZXBvcnRpbmcgbm9kZSBtYXkgbmVlZCB0byB0YWtlIGludG8gYWNjb3Vu
dCBuZXR3b3JrIGRlcGxveW1lbnQgYW5kIHBvdGVudGlhbCBlcnJvcnMgaW4gb3JkZXIgdG8gYmUg
YWJsZSB0byBndWFyYW50ZWUgdGhhdCBzZW50IG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUgaW4g
dGhlIHJlYWN0aW5nIG5vZGUsIGUuZy4gdGhlcmUgbWF5IGJlIG9uZSBvciBtdWx0aXBsZSBhZ2Vu
dHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzOyBvdmVy
bG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXPigKYNCg0KDQpG
cm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVFJP
VFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpDQpTZW50OiBtacOpcmNvbGVzLCAxMiBk
ZSBmZWJyZXJvIGRlIDIwMTQgMTE6MTMNClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSGkNCg0K
T24gdGhpcyB0b3BpYywgbXkgdmlldyBpcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIHNoYWxsICBy
ZWNlaXZlIOKAnGVub3VnaOKAnSBPTFJzIHBlciBwZXJpb2Qgb2YgdGltZSB0byBlbnN1cmUgdGhl
IGVmZmljaWVuY3kgb2YgdGhlIHRyYWZmaWMgIHJlZHVjdGlvbiBtZWNoYW5pc20gLiBBIHdheSB0
byBhY2hpZXZlICB0aGUg4oCcZW5vdWdo4oCdIGlzIHRvIGhhdmUgYW4gT0xSIGluIGFsbCAgYW5z
d2VyICBtZXNzYWdlcyBhcyBwcm9wb3NlZCBhbmQgdGhpcyBjYW4gdGhlIHJlY29tbWVuZGVkIHdh
eS4gTm93IGFzIE5pcmF2IHNhaWQsIHRoZXJlIG1heSBiZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3
aWxsIGJlaGF2ZSBkaWZmZXJlbnRseSBhbmQgc2VuZCDigJxlbm91Z2jigJ0gT0xScyAgYnV0IG5v
dCBpbiBhbGwgbWVzc2FnZXMuDQoNCkFzIGFsc28gTmlyYXYgbm90ZWQsICBJIGRvIG5vdCB3ZWxs
IHNlZSB0aGUgbmVlZCB0byB3cml0ZSBhZGRpdGlvbmFsIG5vdGVzIGFzIG1hbnkgc2l0dWF0aW9u
cyBjYW4gb2NjdXIgYW5kICBhcmUgbm90IGxpbWl0ZWQgdG8gdGhlIGV4YW1wbGUgb2YgdGhlIHJl
YWN0aW5nICBub2RlICBkaXNjYXJkaW5nIE9MUnMuDQoNCkJlc3QgcmVnYXJkcw0KDQpKSmFjcXVl
cw0KDQoNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw
YXJ0IGRlIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0KRW52b3nDqSA6IG1hcmRpIDExIGbDqXZy
aWVyIDIwMTQgMTY6MzUNCsOAIDogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcN
Ck9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCkF0IGxlYXN0LCBpdCBpcyBjb3JyZWN0ISDimLoNCg0KRGUgOiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogQmFydG9sb21l
DQpFbnZvecOpIDogbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxNTowMA0Kw4AgOiBkaW1lQGlldGYu
b3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTGlvbmVsLCBOaXJhdiwgYWxsLA0KDQpN
YXliZSB0aGUgbm90ZSBjb3VsZCBiZSBtb2RpZmllZDoNCg0KTm90ZSDigJN0aGUgcmVhY3Rpbmcg
bm9kZSBjb3VsZCBiZSBhbnkgYWdlbnQgaW4gdGhlIHBhdGgsIGFuZCB0aGF0IGluIHNvbWUgZXJy
b3Igc2l0dWF0aW9ucyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rp
bmcgbm9kZXMuDQoNCkkgYWRkZWQgdGhlIGNhc2UgT0xSIGNvdWxkIGJlIGRpc2NhcmRlZCBieSBy
ZWFjdGluZyBub2Rlcywgc2luY2UgaXQgaGlnaGxpZ2h0cyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUg
c2VydmVyIHdpbGwgbm90IGtub3cgd2hldGhlciBvciBub3QgYSB2YWxpZCBPTFIgaXMgcmVjZWl2
ZWQgYnkgcmVhY3Rpbmcgbm9kZS4NCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KDQpGcm9tOiBs
aW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4g
W21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZl
YnJlcm8gZGUgMjAxNCAxMTozNg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYu
b3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkF0IGxlYXN0LCBpdCBpcyBub3QgInRo
ZSBvbmx5IHN1cmUgd2F5Ii4NCkZvciBpbnN0YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdlcyBwYXJ0
IG9mIHRoZSBzYW1lIHNlc3Npb24gKG9yIHBzZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNvIGJlIHVz
ZWQgYXMgaW5kaWNhdGlvbiBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRoYXQgdGhlIE9MUiBoYXMg
YmVlbiByZWNlaXZlZCBieSB0aGUgcmVhY3Rpbmcgbm9kZSAoYmVzaWRlcyB0aGUgcmVjZXB0aW9u
IG9mIHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgaW4gdGhlIHJlcXVlc3QpLg0KSXQgaXMgd2h5
IEkgd2FzIHNheWluZyB0aGF0IHRoaXMgY2FuIGJlIGZpeGVkIHBlciBhcHBsaWNhdGlvbi9zeXN0
ZW0uDQoNCkxpb25lbA0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmdd
IERlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNCkVudm95w6kgOiBtYXJkaSAxMSBm
w6l2cmllciAyMDE0IDExOjMxDQrDgCA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5v
cmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQpGaW5lIE5pcmF2LCBJIGFncmVlIHRoaXMgaXMgaW1wbGVtZW50YXRpb24gc3Bl
Y2lmaWMuDQpNeSBpbnRlbnRpb24gaXMgdGhhdCBhbnkgcmVhZGVyIHJlYWxpemVzIHdoYXQgdGhp
cyBrbm93bGVkZ2UgaW4gdGhlIHNlcnZlciBpbXBsaWVzIHdoZW4gd2UgdGFsayBhYm91dCBhZ2Vu
dHMgaW4gdGhlIHBhdGguIFRoaXMgaXMgd2h5IEkgdGhpbmsgdGhpcyBub3RlIGlzIGhlbHBmdWwu
DQoNClJlZ2FyZHMNCi9NQ3J1eg0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRv
Om5zYWxvdEBjaXNjby5jb21dDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAx
MToyNg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1l
QGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nDQoNCkkgZG8gbm90IGFncmVlIHJlZ2FyZGluZyB0aGUgY29tcGxleGl0
eSBzaW5jZSBpdCBpcyBoaWdobHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpMZXRzIG5vdCBt
YWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24uDQoNClJlZ2FyZHMsDQpO
aXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMSwg
MjAxNCAzOjU0IFBNDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1
YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
Zw0KDQpIZWxsbywNCg0KSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gaGlnaGxpZ2h0IGNvbXBs
ZXhpdHkgZm9yIHRoZSBzZXJ2ZXIgdG8gIOKAnGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBu
b2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQu4oCdDQpJIHRoaW5r
IHRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlbnRlbmNlIGFkZGVkIGJ5IFN0ZXZlLg0KDQpD
aGVlcnMNCi9NQ3J1eg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNClNlbnQ6IG1hcnRlcywgMTEgZGUg
ZmVicmVybyBkZSAyMDE0IDExOjIwDQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0
bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3Jn
PG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgYW0gYWxzbyBmaW5lIHdpdGggU3RldmUn
cyBwcm9wb3NlZCB3b3JkaW5nIHRvIHJlY29tbWVuZCB0aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQg
dG8gbm90IG1hbmRhdGUgaXQuDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0
ZXh0LCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBhZGQgaXQuDQpOb3RlIC0gdGhl
IG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0
aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdo
ZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJl
dHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KDQpJIHByZWZlciB0byBy
ZW1vdmUgaXQgc2luY2UgSSBkbyBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLg0KDQpSZWdhcmRz
LA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbT4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE0NClRv
OiBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQoNCkknbSBmaW5lIHdpdGggYSByZWNvbW1lbmRhdGlvbi4NCg0KQnV0IEkgaGF2ZSBhIGdlbmVy
YWwgY29tbWVudDogd2hlbiBhIE1BWSBvciBldmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5v
dCBtZWFuIHRoYXQgaXQgaXMgTk9UIHVwIHRvIHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0byBkbyBz
b21ldGhpbmcuIEl0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0
aW9uIG9wdGlvbi4NCkZvciBpbnN0YW5jZSwgb3ZlciBhIGdpdmVuIGludGVyZmFjZSwgdGhlIHJl
bGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1haW50YWlu
ZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNvdWxkIGJlIGRlY2lkZWQgdG8gYWRkIHNvbWUgb3Zl
cmxvYWQgcmVsYXRlZCBpbmZvIGluIHN1Y2ggc3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRo
ZSBub2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0byBrbm93IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBi
ZWVuIG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5zdGFuY2UuIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhl
IHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGluY2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVzc2FnZS4g
SXQgaXMganVzdCBmb3IgaWxsdXN0cmF0aW9uLiBUaGUgcG9pbnQgaXMgdGhhdCB5b3UgbWF5IGhh
dmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90
IGJlIHJlcXVpcmVkLg0KDQpJIGFncmVlIHRoYXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5z
d2VyIGlzIGZpbmXigKYgYnV0IGl0IHNob3VsZCBiZSBub3QgbWFuZGF0b3J5IGluIGFsbCBjYXNl
cyBJIHRoaW5rLiBTbyBPSyBmb3IgYSAiU0hPVUxEIiBvciAiUkVDT01NRU5ERUQiLg0KDQpSZWdh
cmRzLA0KDQpMaW9uZWwNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAxMCBmw6l2cmll
ciAyMDE0IDE3OjIxDQrDgCA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpP
YmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
Zw0KDQpJIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pDQoNCkkgc3Vn
Z2VzdCB0aGF0IHdlIGhhdmUgd29yZGluZyBzYXlpbmcgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNo
IGlzIHRvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbGwgcmVzcG9uc2UgbWVzc2Fn
ZXMgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBieSBNYXJpYSBDcnV6Lg0KDQpJIGFsc28gc3VnZ2Vz
dCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5v
ZGUga25vd3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3Zl
cmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4gIEkg
ZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBpbmNsdWRpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRoZSBy
ZXBvcnRpbmcgbm9kZSBrbm93cyBidXQgd2Ugc2hvdWxkIGluY2x1ZGUgd29yZGluZyBhYm91dCBu
ZXR3b3JrcyBhcmNoaXRlY3R1cmVzIHRoYXQgbWFrZSBpdCBkaWZmaWN1bHQgdG8ga25vdy4gIFRo
ZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0
aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuDQoNCldlIGFsc28gbmVlZCB0byBtYWtlIHN1
cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJh
didzIHByb3Bvc2FsLg0KDQpJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUgd29yZGlu
Zywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBNYXJpYSBDcnV6J3MgcmVhc29ucyBmb3Ig
cmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHdheXMgaW5jbHVkZWQu
DQoNCi0tLS0tDQoNCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rp
bmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5k
ZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwg
YW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCk5vdGUgLSB0aGUgcmVw
b3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dl
ciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZm
aWNpZW50LiAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERp
YW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5v
ZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGlu
ZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5
IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0KDQpOb3RlIC0gdGhlIG9ubHkgc3Vy
ZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVh
Y3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJl
YWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhl
IGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KT24gMi8xMC8xNCAzOjUyIEFNLCBNYXJp
YSBDcnV6IEJhcnRvbG9tZSB3cm90ZToNCg0KSGVsbG8gTmlyYXYsDQoNCg0KDQpBbnkgc29sdXRp
b24gc2hvdWxkIGJhbGFuY2UgZGlmZmVyZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291bGQgYmUg
ZGlzY3Vzc2VkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQg
dG8gYXNzdXJlIHRoZSBtZWNoYW5pc20gd2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGluZyB2YWxp
ZCBPTFIgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCg0KDQpZb3VyIHByb3Bvc2VkIHRleHQNCg0KIiBB
ZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2Rl
IGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQg
dG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUg
T0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAuIg0KDQoNCg0KSWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUgYWJv
dXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFj
dGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2UgaXQgaXMgYSAibWF5IikgdG8gZG8gbm90
IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3
aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkgY29y
cmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUg
dGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBB
TlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJv
dmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVo
YWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4NCg0KVGhlbiwgb24gb25lIGhhbmQgaXQg
aXMgbm90IHNpbXBsZSB0byBrbm93IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIg
aW5mbyAoYXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAo
YXMgcGVyIHlvdXIgcHJvcG9zZWQgIm1heSIpIHRoZW4gb25lIG9yIG11bHRpcGxlIHJlYWN0aW5n
IG5vZGVzIGRvIG5vdCBoYXZlIHRoZSByZXF1aXJlZCBPTFIsIHRoZW4gb3ZlcmxvYWQgbWl0aWdh
dGlvbiB3aWxsIG5vdCB3b3JrLg0KDQoNCg0KVGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUg
c2ltcGxlc3Qgd2F5IHRvIHByb3ZpZGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlk
ZSBPTFIgaW4gQUxMIGFuc3dlcnMuDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90
KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJv
IGRlIDIwMTQgMTA6NDINCg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3Jn
PG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQoN
Cg0KSG93IGNhbiB3ZSBzYXkgdGhhdCAiaW5jbHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3
ZXIgbWVzc2FnZXMgaXMgc2ltcGxlIGFuZCBlZmZpY2llbnQ/Ig0KDQpJdCBpcyBzaW1wbGUgZm9y
IHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuDQoNCg0KDQpBIHNsaWdodGx5IGRpZmZlcmVudCB3b3Jk
aW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVhcmxpZXIgaXMsIFdoZW4gdGhlIHJlcG9ydGluZyBu
b2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQgdGhhdCBuZWVkcyB0byBiZSBwcm92aWRlZCB0
byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5nIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJs
b2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhlIG92ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZp
cnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSBy
ZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBj
b3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMs
IGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9h
ZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJl
cG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUg
cmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2Fy
ZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTog
RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENy
dXogQmFydG9sb21lDQoNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMzowMyBQTQ0K
DQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpO
aXJhdiwgYWxsLA0KDQoNCg0KSSB0aGluayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFu
ZCByb2J1c3Qgc29sdXRpb24sIGFzIGVmZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0K
DQpJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBhcyBhIHB1cmUgIm1heSIsIGJ1dCBsZWF2aW5n
IGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3VyZSByZWFjdGluZyBub2RlIGhh
cyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMgbWVjaGFuaXNt
IHRvIHdvcmsuDQoNCg0KDQpCZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5z
YWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IGx1bmVzLCAxMCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6
MTINCg0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1l
QGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk1hcmlhLUNydXosDQoNCg0KDQpJIGZ1bGx5IGFncmVl
IHdpdGggeW91IG9uICJzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRh
bnQgYWR2YW50YWdlcyIuDQoNCkFuZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0g
YXQgbGVhc3QgdGhhdCBpcyBteSBpbnRlbnRpb24uDQoNCkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBp
cywgYXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRh
dGlvbiwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5k
YW50IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPw0KDQoNCg0KTW9zdCBwcm9iYWJseSwg
dGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Ygb3ZlcmxvYWQgY29udHJvbCB3aWxsIGlu
Y2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzLg0KDQpCdXQgYXQgdGhlIHNhbWUg
dGltZSwgSSBkbyBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4g
Y29tZSB1cCB3aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5n
IHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJl
IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9u
cyBpbiBwcm90b2NvbCBkZWZpbml0aW9uLg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KDQoNClRo
aXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Yg
d2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2Ygdmll
dykuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3
LCAyMDE0IDg6NTcgUE0NCg0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KSGVsbG8gVWxyaWNoLCBOaXJhdiwNCg0KDQoNCkkgYWdyZWUgd2l0aCBV
bHJpY2ggdGhhdCB0aGUgdGV4dCBwcm92aWRlZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQg
d2hldGhlciBvciBub3QgdGhlIHNlcnZlciBzZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hh
bGwgbm90IGJlIGp1c3QgYSBNQVkuDQoNCg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEg
cHJvdmlkZWQgYnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRo
ZSBzZXJ2ZXIgaGFzIHNvbWUga25vd2xlZGdlOg0KDQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25v
d3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFIN
Cg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90
IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMg
Z290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCg0KYykgb3RoZXJ3aXNlDQoNCg0KDQpS
ZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlv
bi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBr
bm93bGVkZ2U/DQoNClRha2UgaW50byBhY2NvdW50IGFzIHdlbGwgdGhhdCBhICJyZWFjdGluZyIg
bm9kZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAoaW4gY2FzZSBpdCBwcm92aWRlcyBzZXJ2aWNlIHRv
IGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5vbi1zdXBwb3J0aW5nIGNsaWVudCkg
IGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIg
bWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGluZyBu
b2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5vdCBu
ZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4g
dG8gdGhlIGZpbmFsIENsaWVudC4NCg0KDQoNClRoZXJlZm9yZSwgSSBkZWZpbml0ZWx5IHRoaW5r
IHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFu
dGFnZXM6DQoNCi0gc3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vz
c2lvbikgaXMgc2ltcGxlciwNCg0KLSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJt
aW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgYW4gT0wgdG8gYSByZWFjdGluZyBub2RlDQoNCi0g
dGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhlciB3aGV0aGVyIGFuIHJlYWN0aW5nIG5v
ZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9yIHdoZXRoZXIgdGhpcyBPTFIgaXMgc3Rp
bGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuDQoNCi0gc2VuZGluZyBhbiBhZGRpdGlvbmFsIEFW
UCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1aXJl
ZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLg0KDQogIEluIGZhY3QsIGluIGFu
IG92ZXJsb2FkIHNpdHVhdGlvbiwgdGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8g
c2VuZCBpbmZvcm1hdGlvbiBvdXQgdG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsDQoN
CiAgYW5kIHRoZSBsYXR0ZXIgc2hvdWxkIHRha2UgY2FyZSB0byB0YWtlIGFwcHJvcHJpYXRlIGFj
dGlvbnMNCg0KLSBtb3JlIHJvYnVzdCBzb2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3Ig
YWxsIHRoZSBjaGVja3Mgb24gdGhlIG5lZWQgdG8gc2VuZCBpbmZvcm1hdGlvbiwgIGZvciBzaXR1
YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlzIGxvc3QsICDigKYNCg0KDQoNCg0KDQpC
ZXN0IHJlZ2FyZHMNCg0KL01DcnV6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
DQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
V2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKQ0KDQpTZW50OiB2aWVybmVzLCAwNyBkZSBm
ZWJyZXJvIGRlIDIwMTQgMTA6NTkNCg0KVG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0
IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PjsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KTmlyYXYsDQoNCg0KDQpJJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4
dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24uDQoNCg0KDQoid2hlbiBpdCB3YW50cyB0
byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uIiB0cmFuc2xhdGVzIHRvICIu
Li5pdCBtYXkgaW5jbHVkZS4uLiIuDQoNCg0KDQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZl
biBjb250ZXh0IHRyYW5zbGF0ZXMgdG8gIndoZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRl
L3VwZGF0ZS4uLiINCg0KDQoNCg0KDQpXZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6DQoNCmEp
IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJl
YWR5IGdvdCB0aGUgbGF0ZXN0IE9MUg0KDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92
ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0
IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0K
DQpjKSBvdGhlcndpc2UNCg0KDQoNCmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBv
ciBtYXkgbm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1h
eSBvciBtYXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9M
UiBpbiBjYXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0
aGUgYW5zd2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMg
aXMgYSByZXBsYXkgb3IgYW4gdXBkYXRlKQ0KDQoNCg0KVWxyaWNoDQoNCg0KDQoNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFtt
YWlsdG86bnNhbG90QGNpc2NvLmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAy
MDE0IDQ6NDkgUE0NCg0KVG86IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBs
aW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47
IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0K
DQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcNCg0KDQoNClVscmljaCwNCg0KDQoNCkl0IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBw
YWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJvcG9zZWQgd29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJl
c3QuDQoNCkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLg0KDQoNCg0KV2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3ZlcmxvYWQgcmVwb3J0IG9yIHdhbnRzIHRvIHVw
ZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgdG93YXJkcyBhIHJlYWN0
aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJl
cXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhlIGNv
cnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywg
ZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2Fk
IHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVw
b3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSBy
ZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KUmVnYXJk
cywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5zbi5j
b21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNDQoNClRvOiBl
eHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20+OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5v
cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsIExpb25lbCwNCg0K
DQoNCkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRpbmcg
UkVRMTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lwbGUg
Mic6DQoNCg0KDQoyJy4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVy
bG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25z
ZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQ
IGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJl
YXNvbmFibGUgb3ZlcmxvYWQgY29udHJvbCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9M
Uiwgd2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFu
IE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIsIG9yIGFuIG9sZCAgYnV0IHNvb24gZXhwaXJp
bmcgT0xSIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3
aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBt
YXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJl
c3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQLg0KDQoNCg0KSSBkb24ndCBhZ3JlZSB3aXRoIExpb25lbHMgZG8td2hhdC15b3Utd2Fu
dCBhcHByb2FjaC4gT3ZlcmxvYWQgY29udHJvbCB3aWxsIG5vdCB3b3JrIHdoZW4gd2UgYWxsb3cg
dGhlIHJlcG9ydGluZyBub2RlIG5vdCB0byB1cGRhdGUgcmVhY3Rpbmcgbm9kZXMsIHdoaWNoIGFy
ZSBub3QgKHN1ZmZpY2lhbnRseSkgYXdhcmUgb2YgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdHVz
LCB3aXRoIHVwIHRvIGRhdGUgT0xScy4NCg0KDQoNClVscmljaA0KDQoNCg0KDQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2Uu
Y29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+IFttYWlsdG86bGlvbmVsLm1vcmFu
ZEBvcmFuZ2UuY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAg
QU0NCg0KVG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N
dW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRm
Lm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nDQoNCg0KDQoNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K
DQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUg
TmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nDqSA6IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAxMDow
OCDDgCA6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFu
OyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPiBPYmpldCA6IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KVWxyaWNoLA0K
DQoNCg0KSSBhbSBub3Qgc3VyZSBhYm91dCBmb3JjaW5nIHRoaXMgYmVoYXZpb3Igb24gcmVwb3J0
aW5nIG5vZGUgIm90aGVyd2lzZSAoaS5lLiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBv
cnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0
dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4iDQoNClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5
IG5vdCBpbmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3
aWxsIGV4cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhl
IHRyYWZmaWMuDQoNCg0KDQpbTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRl
ZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlz
IGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVk
ZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Ig
b24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0
YW5kaW5nLg0KDQoNCg0KQXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBu
ZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBzdG9wIHRocm90dGxpbmcg
YXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIEluIG90aGVyIHdvcmRzLCB0
aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xS
IHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcgdHJhZmZpYyB0b3dhcmRz
IGl0Lg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KVGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBl
LmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQg
c2l0dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBu
ZWVkIGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3Zlcmxv
YWQgY29uZGl0aW9uLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVzdCBvZiB0aGUgcHJpbmNp
cGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1lLg0KDQoNCg0KW0xNXSBBZ3JlZQ0KDQoNCg0KUmVn
YXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9t
OiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndpZWhlQG5z
bi5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIzIFBNDQoNClRv
OiBleHQgU3RldmUgRG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8
bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBh
Z3JlZSBvbiB0d28gcHJpbmNpcGxlczoNCg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNoYW5n
ZSINCg0KMi4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVk
IG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byBy
ZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0
IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHRoZSBsYXRl
c3QgT0xSICh3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24g
b3IgYW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIik7IG90aGVyd2lzZSAoaS5lLiBpZiBp
dCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIg
b3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMgdG8gcmVx
dWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoN
CkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uDQoNCg0KDQpVbHJpY2gNCg0KDQoNCkZyb206IERp
TUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUg
RG9ub3Zhbg0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDQ6MzUgUE0NCg0K
VG86IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYu
b3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KDQoNCkFncmVlZC4gIFRvIHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVy
bG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZv
ciB0aGUgaG9zdCBvciByZWFsbS4gIElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBvdmVy
bG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVyIHRp
bWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCByZXBv
cnQuICBJZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVu
IGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQg
Zm9yIHRoZSBob3N0IGFuZCByZWFsbS4NCg0KDQoNClN0ZXZlDQoNCk9uIDIvNS8xNCA5OjE5IEFN
LCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToNCg0KSSBhZ3JlZSB3aXRoIFN0ZXZlIGV4Y2Vw
dCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90
IG92ZXJsb2FkZWQ/Ig0KDQoNCg0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNr
IGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2Vy
dmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVu
IHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2gg
Y2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNo
IGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0
IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50
IG9mIHZpZXcuDQoNCg0KDQpTbyBiYXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90
IGFmZmVjdCB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUu
IFRoZSByZWFjdGluZyBub2RlIGNhbiBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBP
TFIgdW50aWwgdGhlIGV4cGlyeSBvZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4
cGxpY2l0IE9MUiB3aXRoICIwIiBvdmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQoNCkluIG15
IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUgcmVw
b3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9k
ZS4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NCg0KU2VudDog
V2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA4OjAwIFBNDQoNClRvOiBkaW1lQGlldGYub3Jn
PG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCmlubGluZQ0KDQpPbiAyLzUvMTQg
Nzo1NyBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCg0KT2sgdGhl
biBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIg
QVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVz
c2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdo
ZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS4NCg0KU1JEPiBXaHkgaW4gZXZlcnkg
YW5zd2VyIG1lc3NhZ2U/ICBTaG91bGRuJ3QgbGFjayBvZiBhbiBPTFIgYmUgaW50ZXJwcmV0ZWQg
YXMgbm90IG92ZXJsb2FkZWQ/DQoNCg0KDQoNCg0KDQoNCg0KDQpPdGhlciBjcml0ZXJpYSBsaWtl
IFJFUTE4IG9yIFJFUTEzIGRvIG5vdCBzZWVtIHRvIG1hdHRlci4NCg0KU1JEPiBSZXF1aXJpbmcg
YW4gb3ZlcmxvYWQgcmVwb3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJF
UTEzLCBidXQgcmVxdWlyaW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1P
bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0
YW50aWFsIGFkZGl0aW9uYWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBp
bnNlcnRpbmcgT0xScy4NCg0KDQoNCg0KDQoNCg0KDQoNCkZvciBteSBjbGFyaWZpY2F0aW9uOiBJ
IGd1ZXNzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3Mg
ZXZlcnkgc2luZ2xlIE9MUiByZWNlaXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4g
V2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVy
IHRvIG1pbmltaXplIHByb2Nlc3Npbmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUg
dGltZSBtaW5pbWl6ZSB0aGUgcmlzayB0b28gbWlzcyBhIG5ldyBPTFI/DQoNClNSRD4gVGhhdCBp
cyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkN
Cg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNDQoNClRvOiBsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KSSBzaGFyZSB0
aGUgc2FtZSBvcGluaW9uIGFzIExpb25lbC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxt
YWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPg0KDQpTZW50OiBUdWVzZGF5LCBGZWJydWFy
eSAwNCwgMjAxNCA5OjA3IFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYu
b3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNlcm4gaXMg
d2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4gZXZlcnkg
YW5zd2VyLg0KDQpTbyB0aGUgb3B0aW9ucyB3b3VsZCBiZToNCg0KMS0gT0MtT0xSIEFWUCBpbiBl
dmVyeSBhbnN3ZXINCg0KMi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5
IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhy
b3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQoN
Cg0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgY3JpdGVyaW9uLCB0aGUgb3B0aW9uIDEgc2VlbXMgdGhl
IGJlc3QgYXBwcm9hY2guDQoNCg0KDQpMaW9uZWwNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdp
bmUtLS0tLQ0KDQpEZSA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFj
LnRvb2xzLmlldGYub3JnXQ0KDQpFbnZvecOpIDogbWFyZGkgNCBmw6l2cmllciAyMDE0IDA5OjQ5
DQoNCsOAIDogTU9SQU5EIExpb25lbCBJTVQvT0xODQoNCkNjIDogZGltZUBpZXRmLm9yZzxtYWls
dG86ZGltZUBpZXRmLm9yZz4NCg0KT2JqZXQgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nDQoNCg0KDQojMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
DQoNCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUgYW4gT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIHRoYXQgaXMgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lD
IGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCAgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
LiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyDQoNCiAoVGltZVN0
YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0aGUgdGhyb3R0bGluZyAod2hpY2gg
d2FzDQoNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGlj
YXRlcyB0aGF0IGN1cnJlbnRseSBubyAgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuICBSZXBvcnRp
bmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzICBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBk
ZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZSAgcmVhY3RpbmcgRE9J
QyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLg0KDQogQWJzZW5jZSBvZiB0aGlzIGZlZWRi
YWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5lZWQgZm9yIHRoZSAgcmVwb3J0aW5n
IG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGlu
ZyBET0lDICBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVu
ZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nICB0aGUgcmlnaHQgdGhpbmcgd2l0aCByZWdhcmQgdG8g
dGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1w
cm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDICBlbmRwb2lu
dCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSBy
ZWFjdGluZyAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5IHdoYXRldmVyIHJlYXNvbikuDQoNCiBU
aGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20g
UkZDIDcwNjguDQoNCiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvICBiZSB1c2VkIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0
DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVz
c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp
b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBh
cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT
aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h
bGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv
aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs
dGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh
Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMg
bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkg
c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp
c2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh
Y2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs
ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm
aWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1h
aWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRm
Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFp
bGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpE
aU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0
IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u
ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0
cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv
dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIN
Cg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p
bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0
ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz
c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y
IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0K
dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1
dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is
IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz
IGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg
bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm
YWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBz
ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp
ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJl
IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz
IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoN
CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50
ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy
YXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh
Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMg
bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRo
ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo
b3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw
bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh
dHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp
YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs
c2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2Vz
IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl
bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBk
aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh
dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQph
IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz
LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0
aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl
IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp
dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5
IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y
aXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi
bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp
ZmllZC4NCg0KVGhhbmsgeW91Lg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z
b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OlRpbWVzOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs
YWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFj
azt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K
CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj
azt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh
Y2s7fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlByZm9ybWF0SFRNTCwgZGl2LlByZm9ybWF0SFRNTA0K
CXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCW1zby1zdHlsZS1saW5rOiJQ
csOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5
bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25z
b2xhczsNCgljb2xvcjpibGFjazt9DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMs
IGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0K
CW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5UZXh0ZWRlYnVs
bGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9u
dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h
aWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2
MTt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMx
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0
OTdEO30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN
CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K
PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91
dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo
aXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGVu
IHdlIGFncmVlIG9uIHRoZSBwcm9wb3NlZCB0ZXh0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90
O3NlcmlmJnF1b3Q7Ij5BIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0
aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuPGJyPg0KPGJyPg0KSXQgaXMg
cmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0
cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuJm5ic3A7DQo8
YnI+DQo8YnI+DQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhl
IG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcg
bm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4mbmJzcDsgVGhlIG92ZXJsb2FkIHJlcG9y
dCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBz
dXBwb3J0IERPSUMuPGJyPg0KPGJyPg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5v
dCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1
YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBv
dmVybG9hZCByZXBvcnQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU
aW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPkJ1dCBzdGlsbCB0aGVyZSBhcmUgc29tZSBkaXNjcmVwYW5jaWVzIGFib3V0IHRo
ZSBub3RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBwcm9wb3NhbCBpcyB0byBr
ZWVwIGl0IGp1c3QgYXMgYW4gaW5kaWNhdGlvbiBvZiBwb3RlbnRpYWwgKG1heWJlIG5vdCBhbGwp
IHNpdHVhdGlvbnMgdGhhdCBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50IGlmIGV2ZXIgYW55
IGltcGxlbWVudGF0aW9uIG1heSBjb25zaWRlcg0KIHRvIGRvIG5vdCBmb2xsb3cgdGhlIHJlY29t
bWVuZGF0aW9uIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMg
aW4gYWxsIGFuc3dlciBtZXNzYWdlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C
ZWluZyBhIHJlY29tbWVuZGF0aW9uIGFuZCBub3QgYSBtdXN0LCBhdCBsZWFzdCBJIHRoaW5rIHdl
IG5lZWQgdG8gaW5kaWNhdGUgd2hhdCBtYXkgaW1wbHkgdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVj
b21tZW5kYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlbiBteSBwcm9w
b3NhbCBpcyB0aGUgZm9sbG93aW5nLCB0aGF0IGluY2x1ZGVzIGEgbW9kaWZpY2F0aW9uIHRvIGxh
c3Qgc2VudGVuY2UgYWJvdmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSByZXBvcnRp
bmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJl
YWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0DQo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJl
ZCI+dGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5n
IG5vZGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7Ij4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3Nl
cmlmJnF1b3Q7Ij48YnI+DQpOb3RlIOKAk3RoZSByZXBvcnRpbmcgbm9kZSBtYXkgbmVlZCB0byB0
YWtlIGludG8gYWNjb3VudCBuZXR3b3JrIGRlcGxveW1lbnQgYW5kIHBvdGVudGlhbCBlcnJvcnMg
aW4gb3JkZXIgdG8gYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCBzZW50IG92ZXJsb2FkIHJlcG9y
dCBpcyBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUsIGUuZy4gdGhlcmUgbWF5IGJlIG9uZSBv
ciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcNCiBhbmQgcmVh
Y3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGlu
ZyBub2Rlc+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERp
TUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRS
T1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKTxicj4NCjxiPlNlbnQ6PC9iPiBtacOp
cmNvbGVzLCAxMiBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MTM8YnI+DQo8Yj5Ubzo8L2I+IGRpbWVA
aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkhpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPk9uIHRoaXMgdG9waWMsIG15IHZpZXcgaXMgdGhhdCB0aGUgcmVhY3Rp
bmcgbm9kZSBzaGFsbCAmbmJzcDtyZWNlaXZlIOKAnGVub3VnaOKAnSBPTFJzIHBlciBwZXJpb2Qg
b2YgdGltZSB0byBlbnN1cmUgdGhlIGVmZmljaWVuY3kgb2YgdGhlIHRyYWZmaWMgJm5ic3A7cmVk
dWN0aW9uIG1lY2hhbmlzbQ0KIC4gQSB3YXkgdG8gYWNoaWV2ZSAmbmJzcDt0aGUg4oCcZW5vdWdo
4oCdIGlzIHRvIGhhdmUgYW4gT0xSIGluIGFsbCAmbmJzcDthbnN3ZXIgJm5ic3A7bWVzc2FnZXMg
YXMgcHJvcG9zZWQgYW5kIHRoaXMgY2FuIHRoZSByZWNvbW1lbmRlZCB3YXkuIE5vdyBhcyBOaXJh
diBzYWlkLCB0aGVyZSBtYXkgYmUgcHJvdG9jb2wgZGVzaWduIHRoYXQgd2lsbCBiZWhhdmUgZGlm
ZmVyZW50bHkgYW5kIHNlbmQg4oCcZW5vdWdo4oCdIE9MUnMgJm5ic3A7YnV0IG5vdCBpbiBhbGwg
bWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5BcyBhbHNvIE5pcmF2IG5vdGVkLCAmbmJzcDtJIGRvIG5vdCB3
ZWxsIHNlZSB0aGUgbmVlZCB0byB3cml0ZSBhZGRpdGlvbmFsIG5vdGVzIGFzIG1hbnkgc2l0dWF0
aW9ucyBjYW4gb2NjdXIgYW5kICZuYnNwO2FyZSBub3QgbGltaXRlZCB0byB0aGUgZXhhbXBsZSBv
ZiB0aGUgcmVhY3RpbmcNCiAmbmJzcDtub2RlICZuYnNwO2Rpc2NhcmRpbmcgT0xScy48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SkphY3F1ZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+
RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6d2luZG93dGV4dCI+IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddDQo8
Yj5EZSBsYSBwYXJ0IGRlPC9iPiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208YnI+DQo8Yj5FbnZv
ecOpJm5ic3A7OjwvYj4gbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxNjozNTxicj4NCjxiPsOAJm5i
c3A7OjwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpl
dCZuYnNwOzo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCwgaXQgaXMg
Y29ycmVjdCENCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9
Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8YnI+DQo8
Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxNTowMDxicj4NCjxi
PsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5v
cmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWwsIE5pcmF2LCBhbGwsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N
YXliZSB0aGUgbm90ZSBjb3VsZCBiZSBtb2RpZmllZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpOb3RlIOKAk3RoZSByZWFj
dGluZyBub2RlIGNvdWxkIGJlIGFueSBhZ2VudCBpbiB0aGUgcGF0aCwgYW5kIHRoYXQgaW4gc29t
ZSBlcnJvciBzaXR1YXRpb25zIG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSBy
ZWFjdGluZyBub2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh
ZGRlZCB0aGUgY2FzZSBPTFIgY291bGQgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLCBz
aW5jZSBpdCBoaWdobGlnaHRzIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBzZXJ2ZXIgd2lsbCBub3Qg
a25vdyB3aGV0aGVyIG9yIG5vdCBhIHZhbGlkIE9MUiBpcyByZWNlaXZlZA0KIGJ5IHJlYWN0aW5n
IG5vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KPGEgaHJlZj0ibWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9h
PiBbPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bWFpbHRvOmxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gbWFydGVzLCAxMSBk
ZSBmZWJyZXJvIGRlIDIwMTQgMTE6MzY8YnI+DQo8Yj5Ubzo8L2I+IE1hcmlhIENydXogQmFydG9s
b21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF0IGxlYXN0LCBp
dCBpcyBub3QgJnF1b3Q7dGhlIG9ubHkgc3VyZSB3YXkmcXVvdDsuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdlcyBwYXJ0IG9mIHRo
ZSBzYW1lIHNlc3Npb24gKG9yIHBzZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNvIGJlIHVzZWQgYXMg
aW5kaWNhdGlvbiBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRoYXQgdGhlIE9MUiBoYXMgYmVlbg0K
IHJlY2VpdmVkIGJ5IHRoZSByZWFjdGluZyBub2RlIChiZXNpZGVzIHRoZSByZWNlcHRpb24gb2Yg
dGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBpbiB0aGUgcmVxdWVzdCkuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkl0IGlzIHdoeSBJIHdhcyBzYXlpbmcgdGhhdCB0aGlzIGNhbiBiZSBm
aXhlZCBwZXIgYXBwbGljYXRpb24vc3lzdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6
PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu
ZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFy
aWEgQ3J1eiBCYXJ0b2xvbWU8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgMTEgZsOp
dnJpZXIgMjAxNCAxMTozMTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRp
bWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBS
ZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GaW5lIE5p
cmF2LCBJIGFncmVlIHRoaXMgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IGludGVudGlvbiBpcyB0aGF0IGFueSByZWFkZXIgcmVhbGl6
ZXMgd2hhdCB0aGlzIGtub3dsZWRnZSBpbiB0aGUgc2VydmVyIGltcGxpZXMgd2hlbiB3ZSB0YWxr
IGFib3V0IGFnZW50cyBpbiB0aGUgcGF0aC4gVGhpcyBpcyB3aHkgSSB0aGluayB0aGlzIG5vdGUg
aXMgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93
dGV4dCI+IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2Nv
LmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IG1h
cnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjI2PGJyPg0KPGI+VG86PC9iPiBNYXJpYSBD
cnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5v
cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5J
IGRvIG5vdCBhZ3JlZSByZWdhcmRpbmcgdGhlIGNvbXBsZXhpdHkgc2luY2UgaXQgaXMgaGlnaGx5
IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5M
ZXRzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24uPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEg
aHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmlhIENydXogQmFydG9sb21lPGJy
Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDM6NTQgUE08YnI+DQo8
Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9h
Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8s
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5JIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBoaWdobGlnaHQgY29tcGxleGl0
eSBmb3IgdGhlIHNlcnZlciB0byAmbmJzcDvigJw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Z3VhcmFu
dGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUNCiBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3Zl
cmxvYWQgcmVwb3J0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlzIGlz
IHRoZSBwdXJwb3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRlZCBieSBTdGV2ZS48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNo
ZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vTUNydXo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwv
YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5pcmF2IFNhbG90IChuc2Fsb3QpPGJyPg0KPGI+U2Vu
dDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIwPGJyPg0KPGI+VG86PC9i
PiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5k
QG9yYW5nZS5jb208L2E+OyBTdGV2ZSBEb25vdmFuOw0KPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0
Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj5JIGFtIGFsc28gZmluZSB3aXRoIFN0ZXZlJ3MgcHJvcG9zZWQgd29y
ZGluZyB0byByZWNvbW1lbmQgdGhlIGluY2x1c2lvbiBvZiBPTFIgYnV0IHRvIG5vdCBtYW5kYXRl
IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzI0NDA2MSI+SSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQsIGlm
IGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIGFkZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ob3RlIC0gdGhlIG9ubHkg
c3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEg
cmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhl
IHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4N
CiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2
MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkkgcHJlZmVyIHRvIHJlbW92
ZSBpdCBzaW5jZSBJIGRvIG5vdCBzZWUgYXMgdmFsdWUgYWRkaXRpb24uDQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJl
Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJt
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9i
PiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEwOjEzIFBNPGJyPg0KPGI+VG86PC9iPiBTdGV2
ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwv
YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkknbSBm
aW5lIHdpdGggYSByZWNvbW1lbmRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGhhdmUgYSBnZW5lcmFs
IGNvbW1lbnQ6IHdoZW4gYSBNQVkgb3IgZXZlbiBhIFNIT1VMRCBhcHBseSwgaXQgZG9lcyBub3Qg
bWVhbiB0aGF0IGl0IGlzIE5PVCB1cCB0byB0aGUgbm9kZSB0byBkbyBvciBub3QgdG8gZG8gc29t
ZXRoaW5nLiBJdCBkb2VzIG5vdCBtZWFuDQogdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0
aW9uIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGluc3RhbmNlLCBv
dmVyIGEgZ2l2ZW4gaW50ZXJmYWNlLCB0aGUgcmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkg
dGhhdCBzb21lIHN0YXRlcyBhcmUgbWFpbnRhaW5lZCBieSB0aGUgc2VydmVyLiBBbmQgaXQgY291
bGQgYmUgZGVjaWRlZCB0byBhZGQgc29tZSBvdmVybG9hZA0KIHJlbGF0ZWQgaW5mbyBpbiBzdWNo
IHN0YXRlcy4gRm9yIGluc3RhbmNlIGFnYWluLCB0aGUgbm9kZSBjYW4gdXNlIHRoaXMgc3RhdGUg
dG8ga25vdyBpZiBhIHJlbW90ZSBub2RlIGhhdmUgYmVlbiBub3RpZmllZCBvciBub3QgZm9yIGlu
c3RhbmNlLiBBbmQgaW4gc3VjaCBhIGNhc2UsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBp
bmNsdWRlIGFuIE9MUiBpbiBlYWNoIG1lc3NhZ2UuIEl0IGlzIGp1c3QgZm9yIGlsbHVzdHJhdGlv
bi4gVGhlIHBvaW50DQogaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2gg
dGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SSBhZ3JlZSB0aGF0IGhhdmluZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l4oCmIGJ1
dCBpdCBzaG91bGQgYmUgbm90IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4gU28gT0sg
Zm9yIGEgJnF1b3Q7U0hPVUxEJnF1b3Q7IG9yICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0N
CjxiPkRlIGxhIHBhcnQgZGU8L2I+IFN0ZXZlIERvbm92YW48YnI+DQo8Yj5FbnZvecOpJm5ic3A7
OjwvYj4gbHVuZGkgMTAgZsOpdnJpZXIgMjAxNCAxNzoyMTxicj4NCjxiPsOAJm5ic3A7OjwvYj4g
PGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+
T2JqPC9iPjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+ZXQmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFJlOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbw0KIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVlIHdpdGggYm90aCBNYXJpYSBD
cnV6IGFuZCBOaXJhdi4gOi0pPGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3Jk
aW5nIHNheWluZyB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0aGUgb3Zl
cmxvYWQgcmVwb3J0IGluIGFsbCByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlz
dGVkIGJ5IE1hcmlhIENydXouJm5ic3A7DQo8YnI+DQo8YnI+DQpJIGFsc28gc3VnZ2VzdCB0aGF0
IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25v
d3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQg
cmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4mbmJzcDsgSSBk
b24ndCB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJl
cG9ydGluZyBub2RlIGtub3dzDQogYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQg
bmV0d29ya3MgYXJjaGl0ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuJm5i
c3A7IFRoZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBz
dXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuPGJyPg0KPGJyPg0KPC9zcGFuPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7
c2VyaWYmcXVvdDsiPldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5k
ZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLjxicj4NCjxi
cj4NCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSB3b3JkaW5nLCB3aGljaCBjYW4g
YmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFzb25zIGZvciByZWNvbW1lbmRpbmcg
dGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBpbmNsdWRlZC48YnI+DQo8YnI+DQot
LS0tLTxicj4NCjxicj4NCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVh
Y3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy48YnI+DQo8YnI+DQpJdCBp
cyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBv
cnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4mbmJzcDsN
Cjxicj4NCjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0
aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGlu
ZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNwOyBUaGUgb3ZlcmxvYWQgcmVw
b3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90
IHN1cHBvcnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8g
bm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4g
Z3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhl
IG92ZXJsb2FkIHJlcG9ydC48YnI+DQo8YnI+DQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdp
dGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9k
ZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5v
ZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBh
bmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5P
biAyLzEwLzE0IDM6NTIgQU0sIE1hcmlhIENydXogQmFydG9sb21lIHdyb3RlOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGVsbG8gTmly
YXYsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QW55
IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2llbmN5IGNv
dWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBmaXJzdCB3
ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBwcm92aWRp
bmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPllvdXIgcHJvcG9zZWQgdGV4dCZuYnNwOyA8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDsgQWRkaXRp
b25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBu
b3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRo
ZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBp
biB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZl
YXR1cmUgQVZQLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPklmIHRoZSByZXBvcnRpbmcgaXMgbm90IGF3YXJlIGFib3V0IHdoZXRoZXIgb3Ig
bm90IG92ZXJsb2FkIHJlcG9ydCBpcyBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgYW5k
IGl0IGRlY2lkZXMgKHNpbmNlIGl0IGlzIGEgJnF1b3Q7bWF5JnF1b3Q7KSB0byBkbyBub3Qgc2Vu
ZCB0aGUgT0xSIGFnYWluLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gbWVjaGFuaXNtIHdpbGwg
bm90IHdvcmsgaW4gY2FzZSBPTFIgd2FzIG5vdCBwcm9wZXJseSByZWNlaXZlZCBieSBjb3JyZXNw
b25kaW5nIHBvdGVudGlhbCByZWFjdGluZyBub2Rlcy4gQW5kIHdlIG5lZWQgdG8gbm90ZSB0aGF0
ICZxdW90O3JlYWN0aW5nIG5vZGVzJnF1b3Q7IGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQs
IGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQg
aXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcg
b24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4gPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlbiwgb24gb25lIGhhbmQgaXQgaXMg
bm90IHNpbXBsZSB0byBrbm93IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5m
byAoYXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMg
cGVyIHlvdXIgcHJvcG9zZWQgJnF1b3Q7bWF5JnF1b3Q7KSB0aGVuIG9uZSBvciBtdWx0aXBsZSBy
ZWFjdGluZyBub2RlcyBkbyBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2Fk
IG1pdGlnYXRpb24gd2lsbCBub3Qgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVyZWZvcmUsIGluIG15IG9waW5pb24sIHRoZSBzaW1wbGVz
dCB3YXkgdG8gcHJvdmlkZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBpcyB0byBwcm92aWRlIE9MUiBp
biBBTEwgYW5zd2Vycy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IE5pcmF2IFNhbG90IChuc2Fs
b3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNj
by5jb208L2E+XSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5TZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IE1hcmlhIENydXogQmFy
dG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0
OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CdXQgTWFyaWEt
Q3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5I
b3cgY2FuIHdlIHNheSB0aGF0ICZxdW90O2luY2x1ZGluZyB0aGUgT0xSIGluIGFsbCB0aGUgYW5z
d2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZmaWNpZW50PyZxdW90OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkl0IGlzIHNpbXBsZSBmb3Igc3Vy
ZSBidXQgbm90IGVmZmljaWVudC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+QSBzbGlnaHRseSBkaWZmZXJlbnQgd29yZGluZyBmcm9tIHdoYXQgSSBw
cm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBoYXMgYSBuZXcgb3Zl
cmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gYSByZWFjdGluZyBub2Rl
IChieSB1cGRhdGluZyB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgb3IgYnkg
cHJvdmlkaW5nIHRoZSBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hh
bGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5n
IE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFj
dGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJl
cG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVh
ZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkg
aW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmlu
ZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBNb25kYXksIEZl
YnJ1YXJ5IDEwLCAyMDE0IDM6MDMgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+TmlyYXYsIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5JIHRoaW5rIHdlIHNob3VsZCBkZWZpbmUgYW4gYWNjdXJhdGUgYW5kIHJvYnVzdCBz
b2x1dGlvbiwgYXMgZWZmaWNpZW50IGFuZCBzaW1wbGUgYXMgcG9zc2libGUuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB1bmRlcnN0YW5kIHlvdXIg
cHJvcG9zYWwgYXMgYSBwdXJlICZxdW90O21heSZxdW90OywgYnV0IGxlYXZpbmcgaXQgdXAgdG8g
aW1wbGVtZW50YXRpb24gZG9lcyBub3QgYXNzdXJlIHJlYWN0aW5nIG5vZGUgaGFzIHZhbGlkIE9M
UiBpbmZvcm1hdGlvbiwgd2hhdCBpcyBiYXNpYyBmb3IgdGhpcyBtZWNoYW5pc20gdG8gd29yay4g
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QmVzdCBy
ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0i
bWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBsdW5l
cywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IE1hcmlhIENydXogQmFydG9sb21lOyA8YSBocmVm
PSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtk
aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl
c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgZnVsbHkgYWdyZWUgd2l0aCB5
b3Ugb24gJnF1b3Q7c2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50
IGFkdmFudGFnZXMmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+QW5kIHdlIGFyZSBub3QgdHJ5aW5nIHRvIHByZXZlbnQgaXQgLSBhdCBsZWFz
dCB0aGF0IGlzIG15IGludGVudGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+QnV0IHRoZSBtYWluIHF1ZXN0aW9uIGlzLCBhcmUgd2UgdHJ5aW5n
IHRvIHByZXZlbnQgYW55IG90aGVyIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uLCB3aGljaCBtYXkg
YmUgc21hcnRlciBhbmQgY2FuIGF2b2lkIGluY2x1ZGluZyByZWR1bmRhbnQgT0xSIGluIGFsbCB0
aGUgYW5zd2VyIG1lc3NhZ2U/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+TW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24g
b2Ygb3ZlcmxvYWQgY29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1l
c3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJlc3RyaWN0IHRoZSBkZXZl
bG9wZXJzIHdoaWNoIGNhbiBjb21lIHVwIHdpdGggc29tZSBuaWNlIHR3ZWFrcyBhbmQgdHJpY2tz
IHRvIGF2b2lkIHNlbmRpbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gZXZlcnkgbWVzc2FnZS4g
QW5kIHRoaXMgaXMgd2hlcmUgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGFuZCBhdm9pZCBwdXR0aW5n
IHN1Y2ggcmVzdHJpY3Rpb25zIGluIHByb3RvY29sIGRlZmluaXRpb24uIDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoYXQgZG8geW91IHRoaW5rPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgYWxz
byB0aGUgcmVhc29uIEkgd2FzIHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0
byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFy
aWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5TZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0i
bWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGVsbG8gVWxyaWNoLCBOaXJhdiw8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGFncmVlIHdpdGgg
VWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1BWSwgYW5k
IHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNo
YWxsIG5vdCBiZSBqdXN0IGEgTUFZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPk9uIHRoZSBvdGhlciBoYW5kLCBjcml0ZXJpYSBwcm92aWRlZCBieSBV
bHJpY2ggb24gd2hlbiBPTFIgaGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMgdGhlIHNlcnZlciBoYXMg
c29tZSBrbm93bGVkZ2U6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5v
ZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBv
dmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhh
dCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmU8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jKSBvdGhl
cndpc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5S
ZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlv
bi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBr
bm93bGVkZ2U/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlRha2UgaW50byBhY2NvdW50IGFzIHdlbGwgdGhhdCBhICZxdW90O3JlYWN0aW5nJnF1b3Q7
IG5vZGUgbWF5IGJlIGJvdGggYW4gQWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMgc2VydmljZSB0
byBhIHJlYWxtIG9yIGFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQp
Jm5ic3A7IGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBT
ZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFj
dGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2Vz
IG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUg
Y2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0aGluayB0aGF0IHNl
bmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gc3RhdGUt
bGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikgaXMgc2ltcGxlciw8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIHRoZSBz
ZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gc2VuZCBh
biBPTCB0byBhIHJlYWN0aW5nIG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4tIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBib3RoZXIgd2hl
dGhlciBhbiByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBvciB3aGV0
aGVyIHRoaXMgT0xSIGlzIHN0aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gc2VuZGluZyBhbiBhZGRp
dGlvbmFsIEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0
aCByZXF1aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLiA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgSW4gZmFjdCwg
aW4gYW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxleCBp
cyB0byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBub2Rl
cywgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7IGFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNhcmUgdG8gdGFrZSBhcHByb3ByaWF0ZSBh
Y3Rpb25zJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPi0gbW9yZSByb2J1c3Qgc29sdXRpb24sIGFzIG5vIG5lZWQgdG8gY2F0ZXIgZm9yIGFs
bCB0aGUgY2hlY2tzIG9uIHRoZSBuZWVkIHRvIHNlbmQgaW5mb3JtYXRpb24sJm5ic3A7IGZvciBz
aXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlzIGxvc3QsJm5ic3A7IOKApjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QgcmVnYXJk
czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi9NQ3J1
ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogdmllcm5lcywgMDcgZGUgZmVicmVybyBkZSAy
MDE0IDEwOjU5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IGV4dCBT
dGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9y
ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5T
dWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJh
diw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JJ20g
YWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24u
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7
d2hlbiBpdCB3YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uJnF1
b3Q7IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7Li4uaXQgbWF5IGluY2x1ZGUuLi4mcXVvdDsuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7aW4gb3Ro
ZXIgY2FzZXMmcXVvdDsgaW4gdGhlIGdpdmVuIGNvbnRleHQgdHJhbnNsYXRlcyB0byAmcXVvdDt3
aGVuIGl0IGRvZXMgbm90IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUuLi4mcXVvdDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZSBoYXZlIHRoZSBmb2xs
b3dpbmcgY2FzZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUg
aGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVy
bG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0
aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmU8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jKSBvdGhlcndp
c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pbiBj
YXNlIGEpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCByZXBsYXkgdGhlIE9MUiBp
biBjYXNlIGIpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCB1cGRkYXRlIHRoZSBy
ZWFjdGluZyBub2RlIHdpdGggdGhlIGxhdGVzdCBPTFIgaW4gY2FzZSBjKSB0aGUgcmVwb3J0aW5n
IG5vZGUgTVVTVCBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9ydGluZyBu
b2RlIGRvZXMgbm90IGtub3cgd2hldGhlciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0ZSk8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2g8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkZyb206IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFp
bHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBUaHVyc2Rh
eSwgRmVicnVhcnkgMDYsIDIwMTQgNDo0OSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gp
OyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1v
cmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpk
aW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCBzZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUgcGFnZSBi
dXQgcHJvYmFibHkgdGhlIHByb3Bvc2VkIHdvcmRpbmcgYmVsb3cgaXMgbm90IHRoZSBiZXN0Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhvdyBhYm91
dCB0aGUgZm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPldoZW4gdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUgbmV3IG92
ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3Zl
cmxvYWQgcmVwb3J0IHRvd2FyZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNsdWRlIE9M
UiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVk
LUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFk
ZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUg
aXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0
byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBP
TFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRl
ZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0g
REUvTXVuaWNoKSBbPGEgaHJlZj0ibWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86
dWxyaWNoLndpZWhlQG5zbi5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3
IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86
IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9y
YW5kQG9yYW5nZS5jb208L2E+OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZlIERvbm92
YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJF
OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LCBMaW9uZWws
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBjYW4g
dW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5k
IGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzo8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4yJy4gdGhlIHJlcG9y
dGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lk
ZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250
YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhl
IHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29udHJv
bCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9MUiBy
ZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICZxdW90O25v
IG92ZXJsb2FkJnF1b3Q7LCBvciBhbiBvbGQmbmJzcDsgYnV0IHNvb24gZXhwaXJpbmcgT0xSIHdo
ZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChpLmUu
IGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hl
dGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0
byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgZG9uJ3Qg
YWdyZWUgd2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJsb2FkIGNv
bnRyb2wgd2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9kZSBub3Qg
dG8gdXBkYXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50bHkpIGF3
YXJlIG9mIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRlIE9MUnMu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNo
Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9y
YW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1h
aWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPm1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBBTTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBOaXJhdiBTYWxvdCAo
bnNhbG90KTsgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92
YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJF
OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tTWVzc2FnZSBk
J29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkRlJm5ic3A7OiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBOaXJh
diBTYWxvdCAobnNhbG90KSBFbnZvecOpJm5ic3A7OiBqZXVkaSA2IGbDqXZyaWVyIDIwMTQgMTA6
MDggw4AmbmJzcDs6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBE
b25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT4g
T2JqZXQmbmJzcDs6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5JIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiByZXBvcnRpbmcg
bm9kZSAmcXVvdDtvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVw
b3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJl
dHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBP
Qy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHJlcG9ydGluZyBub2RlIG1heSBzaW1wbHkgbm90
IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwg
ZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0aGUgdHJh
ZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5b
TE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJlZCBmb3Ig
dGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdo
ZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBh
bnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGltcGxlbWVudGF0
aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFzIHdlIGhhZCBkaXNjdXNz
ZWQgZWFybGllciwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGV4
cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5nIGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2Ft
ZSB0aW1lLiBJbiBvdGhlciB3b3JkcywgdGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0aGUg
bmF0dXJhbCBleHBpcnkgb2YgdGhlIE9MUiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUg
c2lnbmFsaW5nIHRyYWZmaWMgdG93YXJkcyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTE1dIEFncmVlPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcu
IHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0
dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVk
IGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQg
Y29uZGl0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5SZXN0IG9mIHRoZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W0xNXSBBZ3Jl
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2Fy
ZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Tmly
YXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFs8
YSBocmVmPSJtYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb20iPm1haWx0bzp1bHJpY2gud2llaGVA
bnNuLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE08bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogZXh0IFN0ZXZlIERv
bm92YW47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9y
ZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5BY3R1YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmluY2lwbGVzOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEuIExhY2sg
b2YgT0xSIG1lYW5zICZxdW90O25vIGNoYW5nZSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0
dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBh
biBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFs
cmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0
aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICZxdW90O25vIG92ZXJs
b2FkJnF1b3Q7KTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJl
cG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCBy
ZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4g
T0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNoPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJl
Zj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVh
cnkgMDUsIDIwMTQgNDozNSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPlRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgPGEgaHJlZj0ibWFpbHRvOmRp
bWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+QWdyZWVkLiZuYnNwOyBUbyByZXN0YXRlIC0tIGxhY2sgb2Yg
YW4gb3ZlcmxvYWQgcmVwb3J0IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBvdmVybG9hZCBz
dGF0ZSBmb3IgdGhlIGhvc3Qgb3IgcmVhbG0uJm5ic3A7IElmIHRoZXJlIGlzIGEgY3VycmVudGx5
IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwg
aXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBv
dmVybG9hZCByZXBvcnQuJm5ic3A7IElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3Zl
cmxvYWQgcmVwb3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVy
ZSBpcyBubyBvdmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN0ZXZlPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T24gMi81LzE0IDk6MTkgQU0sIE5pcmF2
IFNhbG90IChuc2Fsb3QpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQgJnF1b3Q7
c2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/
JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
V2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQg
aXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9M
UiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJs
ZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50
cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRo
aXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBu
b3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gYmFzaWNhbGx5LCB0aGUg
bGFjayBvZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xS
IGF0IHRoZSByZWFjdGluZyBub2RlLiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8g
cmVhY3QgYmFzZWQgb24gb2xkZXIgT0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5
LXBlcmlvZCBvciB3aGVuIHRoZSBleHBsaWNpdCBPTFIgd2l0aCAmcXVvdDswJnF1b3Q7IG92ZXJs
b2FkLW1ldHJpYyBpcyByZWNlaXZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5JbiBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3IgZmxleGlibGUgaW1w
bGVtZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBoYW5kbGluZyBvZiBP
TFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm
IE9mIFN0ZXZlIERvbm92YW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6MDAgUE08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJl
Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aW5saW5lPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T24gMi81LzE0IDc6NTcgQU0sIFdpZWhl
LCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9y
dGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2Fn
ZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBP
Qy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMg
cmVxdWVzdGVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5TUkQmZ3Q7IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT8mbmJzcDsgU2hvdWxkbid0
IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk90aGVyIGNyaXRlcmlh
IGxpa2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNSRCZndDsgUmVxdWlyaW5nIGFu
IG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVEx
MywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFu
dGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5z
ZXJ0aW5nIE9MUnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Rm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9k
ZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkICht
b3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUg
aW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiBy
ZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBt
aXNzIGEgbmV3IE9MUj88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5TUkQmZ3Q7IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJl
ci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg
ZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3
IEFNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86
IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYu
b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkg
c2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERp
TUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFR1ZXNkYXksIEZl
YnJ1YXJ5IDA0LCAyMDE0IDk6MDcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+SSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRp
bmcgbm9kZSBET0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvIHRoZSBvcHRpb25z
IHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Mi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIGV2ZXJ5IHJlcXVlc3QgJiM0MzsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVu
IHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8g
YmUgdXBkYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5JZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0
aGUgYmVzdCBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5MaW9uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EZSZuYnNwOzogZGltZSBpc3N1ZSB0cmFj
a2VyIFs8YSBocmVmPSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnIj5t
YWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5FbnZvecOpJm5ic3A7OiBtYXJk
aSA0IGbDqXZyaWVyIDIwMTQgMDk6NDk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij7DgCZuYnNwOzogTU9SQU5EIExpb25lbCBJTVQvT0xOPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2MmbmJzcDs6IDxhIGhy
ZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9iamV0Jm5ic3A7OiBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IEl0
IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgdGhhdCBpcyZuYnNwOyB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBl
bmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQmbmJzcDsgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IChUaW1lU3RhbXApIG9m
IHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXM8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gc3Vydml2ZWQp
IGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50
bHkgbm8mbmJzcDsgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuJm5ic3A7IFJlcG9ydGluZyBET0lD
IGVuZHBvaW50cyBtYXkgdXNlIHRoaXMmbmJzcDsgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0
ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGUmbmJzcDsgcmVhY3Rpbmcg
RE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVj
aGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlJm5ic3A7IHJlcG9ydGluZyBu
b2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcg
RE9JQyZuYnNwOyBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lD
IGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nJm5ic3A7IHRoZSByaWdodCB0aGluZyB3aXRoIHJl
Z2FyZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJv
dmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNwOyBlbmRw
b2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRo
ZSByZWFjdGluZyZuYnNwOyBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29u
KS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gVGhl
IGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJG
QyA3MDY4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIHRvJm5ic3A7IGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8
L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl
cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs
ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywg
ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug
Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1
ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn
ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2Ug
ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg
ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg
YmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk
IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp
bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz
YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90
IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig
ZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFp
bGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86RGlNRUBp
ZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJl
Zj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVv
dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DZSBtZXNzYWdlIGV0IHNl
cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk
ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5wYXMgZXRyZSBkaWZmdXNlcywg
ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug
Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmEgbCdleHBlZGl0ZXVyIGV0IGxl
IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj
dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T3JhbmdlIGRlY2xpbmUgdG91dGUg
cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs
c2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp
ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi
eSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1
dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QXMg
ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg
dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5rIHlvdS48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz
IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl
cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91
IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw
YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg
cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg
c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl
IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMg
YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt
YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg
dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp
bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz
YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh
YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz
aWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFu
ayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2Ug
ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj
b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMs
IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1
IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl
dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv
bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z
YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g
TWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoaXMgbWVz
c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2
aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5IHNob3VsZCBub3QgYmUg
ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs
ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu
Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo
YW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_087A34937E64E74E848732CFF8354B9209774836ESESSMB101erics_--


From srdonovan@usdonovans.com  Thu Feb 13 04:15:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0CC1A0200 for ; Thu, 13 Feb 2014 04:15:53 -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
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 m89jVGYliLEC for ; Thu, 13 Feb 2014 04:15:48 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id F32361A01F8 for ; Thu, 13 Feb 2014 04:15:47 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53679 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvCb-0004jO-Vj for dime@ietf.org; Thu, 13 Feb 2014 04:15:46 -0800
Message-ID: <52FCB76E.6020202@usdonovans.com>
Date: Thu, 13 Feb 2014 06:15:42 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050605040907030601020606"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:15:53 -0000

This is a multi-part message in MIME format.
--------------050605040907030601020606
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

Why does the reacting node need to send a reduction percentage of zero
to determine if it is stable?  Can't the reacting node just do its
normal checking for overload after sending the validity period of zero? 
If it finds the need for reduction of traffic, it can just send a new
overload report.

Steve

On 2/13/14 4:43 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi MCruz
>
>  
>
> AS  Ben proposed, and I agree,   value of zero (0) for the Validity
> period indicates that an existing overload condition has ended and
> that the reporting node is in a stable condition.
>
> An important word is "stable".
>
>  
>
> When the traffic peak on client side having created the overload
> decreases,   the reporting node progressively diminishes the % traffic
> reduction in OLRs it sends  towards clients taking care to minimize
> the possible oscillations. At a certain time ,  server will consider
> that it can indicate no traffic reduction to clients. Then is it
> stable?  there may be different implementation dependent  ways for the
> server to decide the situation is stable;  one is to send 0% in OLRs
> and wait a certain number of seconds (not 24 hours) to check if
> situation is stable  and then put the validity timer to 0 (or leaves
> the expiry timer  expire). I do not see why to forbid this  way to
> test the stable condition.
>
>  
>
> So the end of overload condition, as Ben proposed,  can remain ONLY
> based on Validity  duration value 0 (or timer expiry), not on the
> value 0 of the % reduction (so a bit different from Nirav statement,
> but in line with Ulrich comment) . The value 0% of the traffic
> reduction is not forbidden as a possible  way to check the stability
> condition .
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* jeudi 13 février 2014 10:56
> *À :* dime@ietf.org list
> *Objet :* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> Hello all,
>
>  
>
> I think proposal to use just Validity-Duration=0 to end overload
> mainly has the intention to simplify and avoid the checks you just
> listed below.
>
> If we allow both, it means that the case Ulrich mentioned is valid,
> and even with 0% reduction OLR info cannot be deleted until Validity
> time expires, even we could receive a new OLR in sequence. Even, the
> reporting needs still to keep Validity timer on for this OLR.
>
> I think this does not provide any added value but simply makes things
> a bit more complex. What could be the reason to keep 0% reduction but
> a Validity of a few hours (e.g.)?
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* jueves, 13 de febrero de 2014 10:24
> *To:* dime@ietf.org  list
> *Subject:* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> I am OK with Ulrich
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> *Envoyé :* jeudi 13 février 2014 09:56
> *À :* ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES);
> dime@ietf.org  list
> *Objet :* RE: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> I also agree with the principle.
>
>  
>
> One minor clarification:
>
> 0%-reduction with non-zero validity period is valid but validity
> period cannot be ignored: as long as not expired the sequence number
> needs to be stored for future checking; once expired, sequence number
> must not be used for future checking.
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Nirav
> Salot (nsalot)
> *Sent:* Thursday, February 13, 2014 4:11 AM
> *To:* TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
>  list
> *Subject:* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> I also tend to agree with JJ below.
>
> Unless there is a strong reason, no point in forbidding the use of 0%
> reduction -- which can also indicate end of overload condition.
>
>  
>
> May be we can clarify that 0% reduction and/or 0 validity period
> indicates end of overload. In my view, both are valid for the use,
> individually and together. So,
>
> -          0 reduction, non-zero validity period => Valid. The
> reacting node can ignore the validity period if reduction is 0.
>
> -          Non-zero reduction, 0 validity period => Valid. The
> reacting node can ignore the reduction if validity period is 0.
>
> -          0 reduction, 0 validity period => Valid as well. Generally,
> this is what the reporting node will use to indicate the end of
> overload condition.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* Thursday, February 13, 2014 2:18 AM
> *To:* dime@ietf.org  list
> *Subject:* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> Dear all
>
>  
>
> On this ticket,  I agree on Ben's  proposal  to use the Validity
> period of 0 to indicate the end of overload.
>
> But about the value of 0% reduction why to forbid it ?
>
>  
>
> In the process to  return to normal traffic conditions, the  server
> still sending OLR eg with  5% reduction    will consider to no request
> anymore traffic reduction but without being yet sure if  it will be
>  stable (end of overload condition as Ben reminded means stable
>  situation without traffic reduction ) , so server  can send 0%
> reduction OLR  but with a validity duration different from 0.
>
> Otherwise it has to  use 1% throttling to check stability and if
> traffic with the client is 1000 request per second this means 10
> requests throttled per second which should not be throttled.
>
> In addition, we do not need to handle the 0% reduction  as an error
> case (cf Mcruz mail)
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Wiehe,
> Ulrich (NSN - DE/Munich)
> *Envoyé :* mercredi 12 février 2014 10:22
> *À :* ext Maria Cruz Bartolome; dime@ietf.org  list
> *Objet :* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> Thank you for the clarification.
>
> I agree.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Wednesday, February 12, 2014 10:13 AM
> *To:* dime@ietf.org  list
> *Subject:* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> Dear Ulrich, all,
>
>  
>
> The proposal was to use OC-Validity-Duration AVP =0 to indicate end of
> overload, since this could be generally applied to any algorithm.
>
> Then, Reduction-Percentage = 0 should be considered as invalid.
>
> I found this reasonable.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> *Sent:* miércoles, 12 de febrero de 2014 9:57
> *To:* Maria Cruz Bartolome; dime@ietf.org  list
> *Subject:* RE: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> I'm confused,
>
>  
>
> I thought that people were in favour of allowing 0 to indicate end of
> overload.
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Wednesday, February 12, 2014 9:44 AM
> *To:* dime@ietf.org  list
> *Subject:* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> Ben, all,
>
>  
>
> This comment affects as well clause 5.5.2:
>
>  
>
>    value == 0
>
>  
>
>       Indicates explicitly the end of overload condition and the
>
>       reacting node SHOULD NOT apply the traffic abatement algorithm
>
>       procedures anymore for the given reporting node (or realm).
>
>  
>
> This should be modified to explain this value is not valid and what is
> the expected behavior (i.e. it is discarded).
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* martes, 11 de febrero de 2014 14:54
> *To:* dime@ietf.org  list
> *Subject:* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> Ben,
>
>  
>
> This approach sounds reasonable to me.
>
> But I would like to clarify what should be the behavior if a
> Reduction-Percentage=0 is received. This is an invalid value, then I
> presume it should be discarded by client.
>
>  
>
> Regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Ben Campbell
> *Sent:* martes, 11 de febrero de 2014 0:56
> *To:* Jouni Korhonen
> *Cc:* dime@ietf.org  list;
> draft-docdt-dime-ovli@tools.ietf.org
> 
> *Subject:* Re: [Dime] [dime] #45: Why is a validity duration of 0
> disallowed?
>
>  
>
> So, here's some proposed text. (intentionally ignoring the related
> discussion about handling invalid values):
>
>  
>
> Section 4.5, first paragraph, last 2 sentences:
>
>  
>
> Old:
>
>  
>
> Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24
> hours) MUST NOT be used. Invalid validity duration values are treated
> as if the OC-Validity-Duration AVP were not present.
>
>  
>
> New:
>
>  
>
> Validity duration values above 86400 MUST NOT be used. Invalid
> validity duration values are treated as if the OC-Validity-Duration
> AVP were not present. A value of zero (0) indicates that an existing
> overload condition has ended and that the reporting node is in a
> stable condition.
>
>  
>
> Section 4.7, 2nd paragraph:
>
>  
>
> Old:
>
>  
>
>  The value of the Reduction-Percentage AVP is between one (1) and one
> hundred (100).  Values greater than 100 are interpreted as 100.  The
> value of 100 means that no traffic is expected, i.e. the reporting
> node is under a severe load and ceases to process any new messages.
> The Reduction-Percentage AVP MUST be present in an overload report
> that uses the default abatement algorithm.
>
>  
>
>     Note that there is no zero (0) value defined for the
>     Reduction-Percentage AVP. A zero value would logically indicate
>     that no overload abatement is requested. Instead, reporting nodes
>     use a OC-Validity-Duration AVP value of zero (0) to indicate the
>     end of an overload condition. [Section 4.5]
>
>  
>
>  
>
>  
>
>  
>
>  
>
>
> On Feb 10, 2014, at 4:12 PM, Jouni Korhonen  > wrote:
>
> Just post it here.
>
>
>
> On Feb 10, 2014, at 6:25 PM, Ben Campbell  > wrote:
>
> Okay. Does that mean we should assign the issue to me in the tracker?
>
> On Feb 10, 2014, at 10:06 AM, Jouni Korhonen  > wrote:
>
>
> Ben,
>
> Propose some text and we can see how it fits in.
>
> - Jouni
>
>
> On Feb 10, 2014, at 5:53 PM, Ben Campbell  > wrote:
>
>
> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  > wrote:
>
>
> On Feb 7, 2014, at 11:54 PM, dime issue tracker
> >
> wrote:
>
> #45: Why is a validity duration of 0 disallowed?
>
> Section 4.5 disallows a validity duration of zero. Why do we want to
> disallow that? It would allow a quick way of ending any existing overload
> condition without worrying about the semantics of the abatement algorithm.
> (We currently use a reduction percentage of zero to end an overload
> condition--but that's specific to the loss algorithm and might not make
> sense for all future ones.)
>
>
> Right. Avoiding two ways of ending overload condition was the reason.
> I am OK to have validity duration 0 as an additional method ending the
> overload condition based on the reasoning above.
>
>
> I would go further and make duration 0 the _preferred_ way, for two
> reasons:
>
> 1) It's algorithm independent. (reduction-percentage of 0 is specific
> to algorithms that use reduction percentage.)
>
> 2) Explicit signaling of the end of an overload condition becomes
> semantically identical to the expiration of an overload condition.
> This allows a simpler implementation.
>
>  
>
>  
>
>
> _______________________________________________
> 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


--------------050605040907030601020606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      Why does the reacting node need to send a reduction percentage of
      zero to determine if it is stable?  Can't the reacting node just
      do its normal checking for overload after sending the validity
      period of zero?  If it finds the need for reduction of traffic, it
      can just send a new overload report.

      

      Steve

      

    
    
On 2/13/14 4:43 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi
            MCruz

        
 

        
AS
             Ben proposed, and I agree,   value of zero (0) for the
            Validity period indicates that an existing overload
            condition has ended and that the reporting node is in a
            stable condition.

        
An
            important word is “stable”.

        
 

        
When
            the traffic peak on client side having created the overload
            decreases,   the reporting node progressively diminishes the
            % traffic reduction in OLRs it sends  towards clients taking
            care to minimize the possible oscillations. At a certain
            time ,  server will consider that it can indicate no traffic
            reduction to clients. Then is it stable?  there may be
            different implementation dependent  ways for the server to
            decide the situation is stable;  one is to send 0% in OLRs
            and wait a certain number of seconds (not 24 hours) to check
            if situation is stable  and then put the validity timer to 0
            (or leaves the expiry timer  expire). I do not see why to
            forbid this  way to test the stable condition.

        
 

        
So
            the end of overload condition, as Ben proposed,  can remain
            ONLY based on Validity  duration value 0 (or timer expiry),
            not on the value 0 of the % reduction (so a bit different
            from Nirav statement, but in line with Ulrich comment) . The
            value 0% of the traffic reduction is not forbidden as a
            possible  way to check the stability condition .

        
 

        
Best
            regards
            

        
 

        
JJacques

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : jeudi 13 février 2014 10:56

                À : dime@ietf.org list

                Objet : Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
Hello
            all,

        
 

        
I
            think proposal to use just Validity-Duration=0 to end
            overload mainly has the intention to simplify and avoid the
            checks you just listed below.

        
If
            we allow both, it means that the case Ulrich mentioned is
            valid, and even with 0% reduction OLR info cannot be deleted
            until Validity time expires, even we could receive a new OLR
            in sequence. Even, the reporting needs still to keep
            Validity timer on for this OLR.

        
I
            think this does not provide any added value but simply makes
            things a bit more complex. What could be the reason to keep
            0% reduction but a Validity of a few hours (e.g.)?

        
 

        
Best
            regards

        
/MCruz

        
 

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: jueves, 13 de febrero de 2014 10:24

                To: dime@ietf.org list

                Subject: Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
I
            am OK with Ulrich

        
 

        
JJacques

        
 

        
 

        

          

            
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
                

                Envoyé : jeudi 13 février 2014 09:56

                À : ext Nirav Salot (nsalot); TROTTIN,
                JEAN-JACQUES (JEAN-JACQUES); 
                  dime@ietf.org list

                Objet : RE: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
I
            also agree with the principle.

        
 

        
One
            minor clarification:

        
0%-reduction
            with non-zero validity period is valid but validity period
            cannot be ignored: as long as not expired the sequence
            number needs to be stored for future checking; once expired,
            sequence number must not be used for future checking.

        
 

        
Ulrich

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Nirav Salot (nsalot)

                Sent: Thursday, February 13, 2014 4:11 AM

                To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
                list

                Subject: Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
I
            also tend to agree with JJ below.

        
Unless
            there is a strong reason, no point in forbidding the use of
            0% reduction – which can also indicate end of overload
            condition.

        
 

        
May
            be we can clarify that 0% reduction and/or 0 validity period
            indicates end of overload. In my view, both are valid for
            the use, individually and together. So,

        
-         
              0
            reduction, non-zero validity period => Valid. The
            reacting node can ignore the validity period if reduction is
            0.

        
-         
              Non-zero
            reduction, 0 validity period => Valid. The reacting node
            can ignore the reduction if validity period is 0.

        
-         
              0
            reduction, 0 validity period => Valid as well. Generally,
            this is what the reporting node will use to indicate the end
            of overload condition.
          

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: Thursday, February 13, 2014 2:18 AM

                To: dime@ietf.org list

                Subject: Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
Dear
            all
          

        
 

        
On
            this ticket,  I agree on Ben’s  proposal  to use the
            Validity period of 0 to indicate the end of overload.

        
But
            about the value of 0% reduction why to forbid it ?

        
 

        
In
            the process to  return to normal traffic conditions, the
             server still sending OLR eg with  5% reduction    will
            consider to no request anymore traffic reduction but without
            being yet sure if  it will be  stable (end of overload
            condition as Ben reminded means stable  situation without
            traffic reduction ) , so server  can send 0% reduction OLR 
            but with a validity duration different from 0.
          

        
Otherwise
            it has to  use 1% throttling to check stability and if
            traffic with the client is 1000 request per second this
            means 10 requests throttled per second which should not be
            throttled.

        
In
            addition, we do not need to handle the 0% reduction  as an
            error case (cf Mcruz mail)

        
 

        
Best
            regards

        
 

        
JJacques
          

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Wiehe, Ulrich (NSN - DE/Munich)

                Envoyé : mercredi 12 février 2014 10:22

                À : ext Maria Cruz Bartolome; dime@ietf.org
                list

                Objet : Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
Thank
            you for the clarification.

        
I
            agree.

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Maria Cruz Bartolome

                Sent: Wednesday, February 12, 2014 10:13 AM

                To: dime@ietf.org list

                Subject: Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
Dear
            Ulrich, all,

        
 

        
The
            proposal was to use OC-Validity-Duration AVP =0 to indicate
            end of overload, since this could be generally applied to
            any algorithm.

        
Then,
            Reduction-Percentage = 0 should be considered as invalid.

        
I
            found this reasonable.

        
 

        
Best
            regards

        
/MCruz

        
 

        
 

        

          

            
From:
                Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
                

                Sent: miércoles, 12 de febrero de 2014 9:57

                To: Maria Cruz Bartolome; dime@ietf.org
                list

                Subject: RE: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
I’m confused,

        
 

        
I
            thought that people were in favour of allowing 0 to indicate
            end of overload.

        
 

        
Ulrich

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Maria Cruz Bartolome

                Sent: Wednesday, February 12, 2014 9:44 AM

                To: dime@ietf.org list

                Subject: Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
Ben,
            all,

        
 

        
This
            comment affects as well clause 5.5.2:

        
 

        
   value == 0

        
 

        
      Indicates explicitly the end of overload
            condition and the

        
      reacting node SHOULD NOT apply the traffic
            abatement algorithm

        
      procedures anymore for the given reporting
            node (or realm).

        
 

        
This
            should be modified to explain this value is not valid and
            what is the expected behavior (i.e. it is discarded).

        
 

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Maria Cruz Bartolome

                Sent: martes, 11 de febrero de 2014 14:54

                To: dime@ietf.org list

                Subject: Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        
Ben,

        
 

        
This
            approach sounds reasonable to me.

        
But
            I would like to clarify what should be the behavior if a
            Reduction-Percentage=0 is received. This is an invalid
            value, then I presume it should be discarded by client. 

        
 

        
Regards

        
/MCruz

        
 

        

          

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

                Sent: martes, 11 de febrero de 2014 0:56

                To: Jouni Korhonen

                Cc: dime@ietf.org list; 
                  draft-docdt-dime-ovli@tools.ietf.org

                Subject: Re: [Dime] [dime] #45: Why is a validity
                duration of 0 disallowed?

          

        

        
 

        

          
So, here's some proposed text.
            (intentionally ignoring the related discussion about
            handling invalid values):

        

        

          
 

        

        

          
Section 4.5, first paragraph, last 2
            sentences:

        

        

          
 

        

        

          
Old:

        

        

          
 

        

        

          
Validity duration values 0 (i.e., 0
            seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
            Invalid validity duration values are treated as if the
            OC-Validity-Duration AVP were not present.

        

        

          
 

        

        

          
New:

        

        

          
 

        

        

          
Validity duration values above 86400 MUST
            NOT be used. Invalid validity duration values are treated as
            if the OC-Validity-Duration AVP were not present. A value of
            zero (0) indicates that an existing overload condition has
            ended and that the reporting node is in a stable condition.

        

        

          
 

        

        

          
Section 4.7, 2nd paragraph:

        

        

          
 

        

        

          
Old:

        

        

          
 

        

        

          

            
 The value of the Reduction-Percentage
              AVP is between one (1) and one hundred (100).  Values
              greater than 100 are interpreted as 100.  The value of 100
              means that no traffic is expected, i.e. the reporting node
              is under a severe load and ceases to process any new
              messages. The Reduction-Percentage AVP MUST be present in
              an overload report that uses the default abatement
              algorithm.

          

        

        

          
 

        

        

          

            

              
Note that there is no zero (0) value
                defined for the Reduction-Percentage AVP. A zero value
                would logically indicate that no overload abatement is
                requested. Instead, reporting nodes use a
                OC-Validity-Duration AVP value of zero (0) to indicate
                the end of an overload condition. [Section 4.5]

            

          

        

        

          
 

        

        

          
 

        

        

          
 

        

        

          
 

        

        

          
 

        

        


          On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com>
          wrote:

        
Just post it
          here.

          

          

          

          On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com>
          wrote:

        
Okay. Does
          that mean we should assign the issue to me in the tracker?

          

          On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com>
          wrote:

        


          Ben,

          

          Propose some text and we can see how it fits in.

          

          - Jouni

          

          

          On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com>
          wrote:

        


          On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com>
          wrote:

        


          On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org>
          wrote:

        
#45: Why is a validity duration of 0
          disallowed?

          

          Section 4.5 disallows a validity duration of zero. Why do we
          want to

          disallow that? It would allow a quick way of ending any
          existing overload

          condition without worrying about the semantics of the
          abatement algorithm.

          (We currently use a reduction percentage of zero to end an
          overload

          condition--but that's specific to the loss algorithm and might
          not make

          sense for all future ones.)

        


          Right. Avoiding two ways of ending overload condition was the
          reason.

          I am OK to have validity duration 0 as an additional method
          ending the

          overload condition based on the reasoning above.

        


          I would go further and make duration 0 the _preferred_ way,
          for two reasons:

          

          1) It's algorithm independent. (reduction-percentage of 0 is
          specific to algorithms that use reduction percentage.)

          

          2) Explicit signaling of the end of an overload condition
          becomes semantically identical to the expiration of an
          overload condition. This allows a simpler implementation.

        
 

        
 

        


          _______________________________________________

          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


    

    

  


--------------050605040907030601020606--


From srdonovan@usdonovans.com  Thu Feb 13 04:19:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4731A0213 for ; Thu, 13 Feb 2014 04:19:30 -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
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 pQLfyloAQhra for ; Thu, 13 Feb 2014 04:19:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id C7E051A0211 for ; Thu, 13 Feb 2014 04:19:16 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53687 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvFx-00080o-CM for dime@ietf.org; Thu, 13 Feb 2014 04:19:15 -0800
Message-ID: <52FCB83E.4000606@usdonovans.com>
Date: Thu, 13 Feb 2014 06:19:10 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------080903030807000303040801"
X-OutGoing-Spam-Status: No, score=0.6
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
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:19:30 -0000

This is a multi-part message in MIME format.
--------------080903030807000303040801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I'm ok with the suggestion.

Steve

On 2/13/14 3:01 AM, Maria Cruz Bartolome wrote:
>
> Dear all,
>
>  
>
> I think then we agree on the proposed text:
>
>  
>
> A reporting node MUST ensure that all reacting nodes receive new
> overload reports.
>
> It is recommended that a reporting node include overload reports in
> all answer messages sent to reacting nodes. 
>
> Note - the reporting node may also include the overload report in
> answer messages sent to non reacting nodes if that is more efficient. 
> The overload report will just be ignored by a Diameter node that does
> not support DOIC.
>
> A reporting node MAY choose to not send an overload report to a
> reacting node if it can guarantee that the reacting node already has
> received the overload report.
>
>  
>
> But still there are some discrepancies about the note.
>
> My proposal is to keep it just as an indication of potential (maybe
> not all) situations that should be taken into account if ever any
> implementation may consider to do not follow the recommendation that a
> reporting node include overload reports in all answer messages.
>
> Being a recommendation and not a must, at least I think we need to
> indicate what may imply to do not follow the recommendation.
>
> Then my proposal is the following, that includes a modification to
> last sentence above:
>
>  
>
> A reporting node MAY choose to not send an overload report to a
> reacting node if it can guarantee that this overload report is already
> active in the reacting node.
>
>
> Note --the reporting node may need to take into account network
> deployment and potential errors in order to be able to guarantee that
> sent overload report is active in the reacting node, e.g. there may be
> one or multiple agents in the path between reporting and reacting
> nodes; overload reports may be discarded by reacting nodes...
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* miércoles, 12 de febrero de 2014 11:13
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> Hi
>
>  
>
> On this topic, my view is that the reacting node shall  receive
> "enough" OLRs per period of time to ensure the efficiency of the
> traffic  reduction mechanism . A way to achieve  the "enough" is to
> have an OLR in all  answer  messages as proposed and this can the
> recommended way. Now as Nirav said, there may be protocol design that
> will behave differently and send "enough" OLRs  but not in all messages.
>
>  
>
> As also Nirav noted,  I do not well see the need to write additional
> notes as many situations can occur and  are not limited to the example
> of the reacting  node  discarding OLRs.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
> lionel.morand@orange.com
> *Envoyé :* mardi 11 février 2014 16:35
> *À :* Maria Cruz Bartolome; dime@ietf.org
> *Objet :* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> At least, it is correct! J
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 11 février 2014 15:00
> *À :* dime@ietf.org 
> *Objet :* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> Lionel, Nirav, all,
>
>  
>
> Maybe the note could be modified:
>
>
> Note --the reacting node could be any agent in the path, and that in
> some error situations overload reports may be discarded by reacting nodes.
>
>  
>
> I added the case OLR could be discarded by reacting nodes, since it
> highlights a situation where the server will not know whether or not a
> valid OLR is received by reacting node.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> *From:*lionel.morand@orange.com 
> [mailto:lionel.morand@orange.com]
> *Sent:* martes, 11 de febrero de 2014 11:36
> *To:* Maria Cruz Bartolome; dime@ietf.org 
> *Subject:* RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> At least, it is not "the only sure way".
>
> For instance, subsequent messages part of the same session (or
> pseudo-session) could also be used as indication for the reporting
> node that the OLR has been received by the reacting node (besides the
> reception of the OC-Supported-Features in the request).
>
> It is why I was saying that this can be fixed per application/system.
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 11 février 2014 11:31
> *À :* dime@ietf.org 
> *Objet :* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> Fine Nirav, I agree this is implementation specific.
>
> My intention is that any reader realizes what this knowledge in the
> server implies when we talk about agents in the path. This is why I
> think this note is helpful.
>
>  
>
> Regards
>
> /MCruz
>
>  
>
> *From:*Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
> *Sent:* martes, 11 de febrero de 2014 11:26
> *To:* Maria Cruz Bartolome; dime@ietf.org 
> *Subject:* RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> I do not agree regarding the complexity since it is highly
> implementation specific.
>
> Lets not make any assumption in the protocol design.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* Tuesday, February 11, 2014 3:54 PM
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> Hello,
>
>  
>
> I think it is important to highlight complexity for the server to
>  "guarantee that the reacting node already has received the overload
> report."
>
> I think this is the purpose of the sentence added by Steve.
>
>  
>
> Cheers
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Nirav Salot
> (nsalot)
> *Sent:* martes, 11 de febrero de 2014 11:20
> *To:* lionel.morand@orange.com ;
> Steve Donovan; dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> I am also fine with Steve's proposed wording to recommend the
> inclusion of OLR but to not mandate it.
>
>  
>
> I am not sure about the following text, if it is absolutely necessary
> to add it.
>
> Note - the only sure way, without proprietary mechanisms, to know that
> a reacting node has received an overload report is when the reacting
> node is a client and there is no agent between the client and the
> reporting node.
>
>  
>
> I prefer to remove it since I do not see as value addition.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
> *lionel.morand@orange.com 
> *Sent:* Monday, February 10, 2014 10:13 PM
> *To:* Steve Donovan; dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> I'm fine with a recommendation.
>
>  
>
> But I have a general comment: when a MAY or even a SHOULD apply, it
> does not mean that it is NOT up to the node to do or not to do
> something. It does not mean that it is only an implementation option.
>
> For instance, over a given interface, the related specification can
> say that some states are maintained by the server. And it could be
> decided to add some overload related info in such states. For instance
> again, the node can use this state to know if a remote node have been
> notified or not for instance. And in such a case, the server does not
> need to include an OLR in each message. It is just for illustration.
> The point is that you may have some cases for which the OLR in every
> answer might not be required.
>
>  
>
> I agree that having the OLR in every answer is fine... but it should
> be not mandatory in all cases I think. So OK for a "SHOULD" or
> "RECOMMENDED".
>
>  
>
> Regards,
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* lundi 10 février 2014 17:21
> *À :* dime@ietf.org 
> *Obj**et :*Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info
> AVP in request messages that survived a throttling
>
>  
>
> I agree with both Maria Cruz and Nirav. :-)
>
> I suggest that we have wording saying the recommended approach is to
> include the overload report in all response messages for the reasons
> listed by Maria Cruz. 
>
> I also suggest that we include Nirav's proposal that if a reporting
> node knows that a reacting node has already received an overload
> report then it may choose to not send it again.  I don't think we need
> to including anything about how the reporting node knows but we should
> include wording about networks architectures that make it difficult to
> know.  The case of agents acting as reacting nodes for non supporting
> clients being one example.
>
> We also need to make sure that the recommended approach is not
> precluded by Nirav's proposal.
>
> I propose the following normative wording, which can be supplemented
> by Maria Cruz's reasons for recommending that the overload report is
> always included.
>
> -----
>
> A reporting node MUST ensure that all reacting nodes receive new
> overload reports.
>
> It is recommended that a reporting node include overload reports in
> all answer messages sent to reacting nodes. 
>
> Note - the reporting node may also include the overload report in
> answer messages sent to non reacting nodes if that is more efficient. 
> The overload report will just be ignored by a Diameter node that does
> not support DOIC.
>
> A reporting node MAY choose to not send an overload report to a
> reacting node if it can guarantee that the reacting node already has
> received the overload report.
>
> Note - the only sure way, without proprietary mechanisms, to know that
> a reacting node has received an overload report is when the reacting
> node is a client and there is no agent between the client and the
> reporting node.
>
> On 2/10/14 3:52 AM, Maria Cruz Bartolome wrote:
>
>     Hello Nirav,
>
>      
>
>     Any solution should balance different factors, efficiency could be discussed from different perspectives, but first we need to assure the mechanism we are defining is providing valid OLR to reacting nodes.
>
>      
>
>     Your proposed text  
>
>     " Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP."
>
>      
>
>     If the reporting is not aware about whether or not overload report is provided to the reacting node, and it decides (since it is a "may") to do not send the OLR again, then overload mitigation mechanism will not work in case OLR was not properly received by corresponding potential reacting nodes. And we need to note that "reacting nodes" could be not only the client, but ANY agent used for routing (not only when the agent is providing service to a Realm, but when it is reacting on behalf of a non-supporting client). 
>
>     Then, on one hand it is not simple to know when reacting nodes have valid OLR info (as explained below), but if OLR is not sent again (as per your proposed "may") then one or multiple reacting nodes do not have the required OLR, then overload mitigation will not work.
>
>      
>
>     Therefore, in my opinion, the simplest way to provide required information is to provide OLR in ALL answers.
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     -----Original Message-----
>
>     From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com] 
>
>     Sent: lunes, 10 de febrero de 2014 10:42
>
>     To: Maria Cruz Bartolome; dime@ietf.org 
>
>     Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     But Maria-Cruz,
>
>      
>
>     How can we say that "including the OLR in all the answer messages is simple and efficient?"
>
>     It is simple for sure but not efficient. 
>
>      
>
>     A slightly different wording from what I proposed earlier is, When the reporting node has a new overload report that needs to be provided to a reacting node (by updating the earlier provided overload report or by providing the overload report for the first time), it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
>
>     Sent: Monday, February 10, 2014 3:03 PM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Nirav, all,
>
>      
>
>     I think we should define an accurate and robust solution, as efficient and simple as possible.
>
>     I understand your proposal as a pure "may", but leaving it up to implementation does not assure reacting node has valid OLR information, what is basic for this mechanism to work. 
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     -----Original Message-----
>
>     From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
>
>     Sent: lunes, 10 de febrero de 2014 10:12
>
>     To: Maria Cruz Bartolome; dime@ietf.org 
>
>     Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Maria-Cruz,
>
>      
>
>     I fully agree with you on "sending OLR in ALL answers has some important advantages".
>
>     And we are not trying to prevent it - at least that is my intention. 
>
>     But the main question is, are we trying to prevent any other possible implementation, which may be smarter and can avoid including redundant OLR in all the answer message?
>
>      
>
>     Most probably, the very first implementation of overload control will include OLR in all the answer messages.
>
>     But at the same time, I do not want to restrict the developers which can come up with some nice tweaks and tricks to avoid sending the same information in every message. And this is where we need to be careful and avoid putting such restrictions in protocol definition. 
>
>     What do you think?
>
>      
>
>     This also the reason I was suggesting loose description of when to include OLR (from the reporting node point of view).
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
>
>     Sent: Friday, February 07, 2014 8:57 PM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Hello Ulrich, Nirav,
>
>      
>
>     I agree with Ulrich that the text provided by Nirav is just a MAY, and whether or not the server sends an OLR in all answers shall not be just a MAY.
>
>      
>
>     On the other hand, criteria provided by Ulrich on when OLR has to be sent requires the server has some knowledge:
>
>     a) the reporting node knows that the reacting node has already got the latest OLR
>
>     b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire
>
>     c) otherwise
>
>      
>
>     Reporting node must have some knowledge about OLR reception/status in reacting node. How does server acquire this knowledge? 
>
>     Take into account as well that a "reacting" node may be both an Agent (in case it provides service to a realm or acting on behalf of a non-supporting client)  and a Client. In the case of Agents, in fact the Server may not even know if this is going to act as a reacting node or just transparently, in fact, the server does not need to have any knowledge about what agents in the chain to the final Client.
>
>      
>
>     Therefore, I definitely think that sending OLR in ALL answers has some important advantages:
>
>     - state-less implementation (transaction or session) is simpler,
>
>     - the server does not need to determine whether or not to send an OL to a reacting node
>
>     - the server does not need to bother whether an reacting node has already received an OLR or whether this OLR is still valid (has not expired).
>
>     - sending an additional AVP is not processing consuming, in comparison with required above checks (if this is not sent). 
>
>       In fact, in an overload situation, the easiest and least complex is to send information out to all affected/applicable nodes, 
>
>       and the latter should take care to take appropriate actions  
>
>     - more robust solution, as no need to cater for all the checks on the need to send information,  for situations where an answer message is lost,  ...
>
>      
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
>
>     Sent: viernes, 07 de febrero de 2014 10:59
>
>     To: ext Nirav Salot (nsalot); ext lionel.morand@orange.com ; ext Steve Donovan; dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Nirav,
>
>      
>
>     I'm afraid your proposed text does not reflect the intention.
>
>      
>
>     "when it wants to provide/update....it shall include..." translates to "...it may include...".
>
>      
>
>     "in other cases" in the given context translates to "when it does not want to provide/update..."
>
>      
>
>      
>
>     We have the following cases:
>
>     a) the reporting node knows that the reacting node has already got the latest OLR
>
>     b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire
>
>     c) otherwise
>
>      
>
>     in case a) the reporting node may or may not replay the OLR in case b) the reporting node may or may not upddate the reacting node with the latest OLR in case c) the reporting node MUST include the OLR in the answer (the reporting node does not know whether this is a replay or an update)
>
>      
>
>     Ulrich
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
>
>     Sent: Thursday, February 06, 2014 4:49 PM
>
>     To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com ; ext Steve Donovan; dime@ietf.org 
>
>     Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Ulrich,
>
>      
>
>     It seems we all are on same page but probably the proposed wording below is not the best.
>
>     How about the following.
>
>      
>
>     When the reporting node wants to provide new overload report or wants to update the earlier provided overload report towards a reacting node, it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>
>     Sent: Thursday, February 06, 2014 3:57 PM
>
>     To: ext lionel.morand@orange.com ; Nirav Salot (nsalot); ext Steve Donovan; dime@ietf.org 
>
>     Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Nirav, Lionel,
>
>      
>
>     I can understand Nirav's concern (although violating REQ10) and hop it is addressed by the modified principle 2':
>
>      
>
>     2'. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got reasonable overload control information (e.g. the latest OLR, which may be an OLR requesting traffic reduction or an OLR indicating "no overload", or an old  but soon expiring OLR when the reporting node is not overloaded); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.
>
>      
>
>     I don't agree with Lionels do-what-you-want approach. Overload control will not work when we allow the reporting node not to update reacting nodes, which are not (sufficiantly) aware of the current overload status, with up to date OLRs.
>
>      
>
>     Ulrich  
>
>      
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: ext lionel.morand@orange.com  [mailto:lionel.morand@orange.com]
>
>     Sent: Thursday, February 06, 2014 10:20 AM
>
>     To: Nirav Salot (nsalot); Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org 
>
>     Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>      
>
>      
>
>     -----Message d'origine-----
>
>     De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoyé : jeudi 6 février 2014 10:08 À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org  Objet : Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Ulrich,
>
>      
>
>     I am not sure about forcing this behavior on reporting node "otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP."
>
>     The reporting node may simply not include OLR assuming that the earlier provided OLR will expire and the reacting node will stop throttling the traffic.
>
>      
>
>     [LM] Agree. In other words, it is not deemed required for the default mechanism described in this draft. How and when the reporting node decides to include the OLR in the answer may depend on the application or on the implementation. At least, it is my current understanding.
>
>      
>
>     As we had discussed earlier, there is no need for the reporting node to explicitly stop throttling at each reacting node at the same time. In other words, the reporting node can allow the natural expiry of the OLR to facilitate slow ramp of the signaling traffic towards it.
>
>      
>
>     [LM] Agree
>
>      
>
>     There may be other cases, e.g. when the reporting node knows that the last overload situation ended long time back in the past, there is no need for it to include OLR if currently there is no overload condition.
>
>      
>
>     [LM] Agree
>
>      
>
>     Rest of the principles below are fine with me.
>
>      
>
>     [LM] Agree
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>
>     Sent: Thursday, February 06, 2014 2:23 PM
>
>     To: ext Steve Donovan; Nirav Salot (nsalot); dime@ietf.org 
>
>     Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Actually we seem to agree on two principles:
>
>     1. Lack of OLR means "no change"
>
>     2. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got the latest OLR (which may be an OLR requesting traffic reduction or an OLR indicating "no overload"); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.
>
>      
>
>     Can people please confirm.
>
>      
>
>     Ulrich
>
>      
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>
>     Sent: Wednesday, February 05, 2014 4:35 PM
>
>     To: Nirav Salot (nsalot); dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     Agreed.  To restate -- lack of an overload report does not change the current overload state for the host or realm.  If there is a currently active overload report then it continues to apply until it either times out or is explicitly changed with a new overload report.  If there is no currently active overload report then lack of an overload report implies there is no overload for the host and realm.
>
>      
>
>     Steve
>
>     On 2/5/14 9:19 AM, Nirav Salot (nsalot) wrote:
>
>     I agree with Steve except the part "shouldn't lack of OLR be interpreted as not overloaded?"
>
>      
>
>     We had some discussion sometime back and thought that it is reasonable to not mandate the server to include the OLR in every answer message. E.g. when the server is capable of tracking what is sent to which client and hence wants to avoid sending information which is redundant. But this is optional implementation and at the same time need not be prohibited from protocol point of view.
>
>      
>
>     So basically, the lack of OLR should not affect the previously received OLR at the reacting node. The reacting node can continue to react based on older OLR until the expiry of the validity-period or when the explicit OLR with "0" overload-metric is received.
>
>     In my view, this allows for flexible implementation at the reporting node and sound handling of OLR at the reacting node.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>
>     Sent: Wednesday, February 05, 2014 8:00 PM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     inline
>
>     On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).
>
>     SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?
>
>      
>
>      
>
>      
>
>      
>
>     Other criteria like REQ18 or REQ13 do not seem to matter.
>
>     SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.
>
>      
>
>      
>
>      
>
>      
>
>     For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?
>
>     SRD> That is the purpose of the sequence number.
>
>      
>
>      
>
>      
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
>
>     Sent: Wednesday, February 05, 2014 5:27 AM
>
>     To: lionel.morand@orange.com ; dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     I share the same opinion as Lionel.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com 
>
>     Sent: Tuesday, February 04, 2014 9:07 PM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 
>
>     So the options would be:
>
>     1- OC-OLR AVP in every answer
>
>     2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.
>
>      
>
>     If there is no other criterion, the option 1 seems the best approach.
>
>      
>
>     Lionel
>
>      
>
>     -----Message d'origine-----
>
>     De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>
>     Envoyé : mardi 4 février 2014 09:49
>
>     À : MORAND Lionel IMT/OLN
>
>     Cc : dime@ietf.org 
>
>     Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>     #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
>
>      
>
>      It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number
>
>      (TimeStamp) of the OLR according to which the throttling (which was
>
>      survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.
>
>      Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.
>
>      The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).
>
>      The feedback mechanism also allows to address REQ 18 from RFC 7068.
>
>      In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.
>
>      
>
>      
>
>      
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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.
>
>      
>
>     _______________________________________________
>
>     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
>
>  
>
> _________________________________________________________________________________________________________________________
>  
> 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.
> _________________________________________________________________________________________________________________________
>  
> 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.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------080903030807000303040801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I'm ok with the
      suggestion.

      

      Steve

      

    
    
On 2/13/14 3:01 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Dear
            all,

        
 

        
I
            think then we agree on the proposed text:

        
 

        
A reporting node MUST ensure that all reacting
            nodes receive new overload reports.

            

            It is recommended that a reporting node include overload
            reports in all answer messages sent to reacting nodes. 
            

            

            Note - the reporting node may also include the overload
            report in answer messages sent to non reacting nodes if that
            is more efficient.  The overload report will just be ignored
            by a Diameter node that does not support DOIC.

            

            A reporting node MAY choose to not send an overload report
            to a reacting node if it can guarantee that the reacting
            node already has received the overload report.

            

            

        
 

        
But
            still there are some discrepancies about the note.

        
My
            proposal is to keep it just as an indication of potential
            (maybe not all) situations that should be taken into account
            if ever any implementation may consider to do not follow the
            recommendation that a reporting node include overload
            reports in all answer messages.
            

        
Being
            a recommendation and not a must, at least I think we need to
            indicate what may imply to do not follow the recommendation.
            

        
Then
            my proposal is the following, that includes a modification
            to last sentence above:

        
 

        
A
            reporting node MAY choose to not send an overload report to
            a reacting node if it can guarantee that
          this
            overload report is already active in the reacting node.

        


            Note –the reporting node may need to take into account
            network deployment and potential errors in order to be able
            to guarantee that sent overload report is active in the
            reacting node, e.g. there may be one or multiple agents in
            the path between reporting and reacting nodes; overload
            reports may be discarded by reacting nodes…

        
 

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: miércoles, 12 de febrero de 2014 11:13

                To: dime@ietf.org

                Subject: Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
Hi
            

        
 

        
On
            this topic, my view is that the reacting node shall  receive
            “enough” OLRs per period of time to ensure the efficiency of
            the traffic  reduction mechanism . A way to achieve  the
            “enough” is to have an OLR in all  answer  messages as
            proposed and this can the recommended way. Now as Nirav
            said, there may be protocol design that will behave
            differently and send “enough” OLRs  but not in all messages.

        
 

        
As
            also Nirav noted,  I do not well see the need to write
            additional notes as many situations can occur and  are not
            limited to the example of the reacting  node  discarding
            OLRs.

        
 

        
Best
            regards

        
 

        
JJacques
            

        
 

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de lionel.morand@orange.com

                Envoyé : mardi 11 février 2014 16:35

                À : Maria Cruz Bartolome; dime@ietf.org

                Objet : Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
At
            least, it is correct!
          J

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : mardi 11 février 2014 15:00

                À : dime@ietf.org

                Objet : Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
Lionel,
            Nirav, all,

        
 

        
Maybe
            the note could be modified:

        


            Note –the reacting node could be any agent in the path, and
            that in some error situations overload reports may be
            discarded by reacting nodes.

        
 

        
I
            added the case OLR could be discarded by reacting nodes,
            since it highlights a situation where the server will not
            know whether or not a valid OLR is received by reacting
            node.

        
 

        
Best
            regards

        
/MCruz

        
 

        
 

        

          

            
From:
                lionel.morand@orange.com
                [mailto:lionel.morand@orange.com]
                

                Sent: martes, 11 de febrero de 2014 11:36

                To: Maria Cruz Bartolome; dime@ietf.org

                Subject: RE: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
At
            least, it is not "the only sure way".

        
For
            instance, subsequent messages part of the same session (or
            pseudo-session) could also be used as indication for the
            reporting node that the OLR has been received by the
            reacting node (besides the reception of the
            OC-Supported-Features in the request).

        
It
            is why I was saying that this can be fixed per
            application/system.

        
 

        
Lionel

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : mardi 11 février 2014 11:31

                À : dime@ietf.org

                Objet : Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
Fine
            Nirav, I agree this is implementation specific.

        
My
            intention is that any reader realizes what this knowledge in
            the server implies when we talk about agents in the path.
            This is why I think this note is helpful.

        
 

        
Regards

        
/MCruz

        
 

        

          

            
From:
                Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
                

                Sent: martes, 11 de febrero de 2014 11:26

                To: Maria Cruz Bartolome; dime@ietf.org

                Subject: RE: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
I
            do not agree regarding the complexity since it is highly
            implementation specific.

        
Lets
            not make any assumption in the protocol design.

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Maria Cruz Bartolome

                Sent: Tuesday, February 11, 2014 3:54 PM

                To: dime@ietf.org

                Subject: Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
Hello,

        
 

        
I
            think it is important to highlight complexity for the server
            to  “guarantee that the reacting node already has
            received the overload report.”
            

        
I
            think this is the purpose of the sentence added by Steve.

        
 

        
Cheers

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Nirav Salot (nsalot)

                Sent: martes, 11 de febrero de 2014 11:20

                To: lionel.morand@orange.com;
                Steve Donovan;
                dime@ietf.org

                Subject: Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
I
            am also fine with Steve's proposed wording to recommend the
            inclusion of OLR but to not mandate it.

        
 

        
I
            am not sure about the following text, if it is absolutely
            necessary to add it.

        
Note - the only sure way, without proprietary
            mechanisms, to know that a reacting node has received an
            overload report is when the reacting node is a client and
            there is no agent between the client and the reporting node.

        
 

        
I
            prefer to remove it since I do not see as value addition.
            

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of lionel.morand@orange.com

                Sent: Monday, February 10, 2014 10:13 PM

                To: Steve Donovan; dime@ietf.org

                Subject: Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
I'm
            fine with a recommendation.

        
 

        
But
            I have a general comment: when a MAY or even a SHOULD apply,
            it does not mean that it is NOT up to the node to do or not
            to do something. It does not mean that it is only an
            implementation option.

        
For
            instance, over a given interface, the related specification
            can say that some states are maintained by the server. And
            it could be decided to add some overload related info in
            such states. For instance again, the node can use this state
            to know if a remote node have been notified or not for
            instance. And in such a case, the server does not need to
            include an OLR in each message. It is just for illustration.
            The point is that you may have some cases for which the OLR
            in every answer might not be required.

        
 

        
I
            agree that having the OLR in every answer is fine… but it
            should be not mandatory in all cases I think. So OK for a
            "SHOULD" or "RECOMMENDED".

        
 

        
Regards,

        
 

        
Lionel
            

        
 

        

          

            
De :
                DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : lundi 10 février 2014 17:21

                À : dime@ietf.org

                Objet : Re: [Dime] [dime] #31: Sending
                OC-Ongoing-Throttling-Info AVP in request messages that
                survived a throttling

          

        

        
 

        
I agree with both Maria Cruz and Nirav. :-)

            

            I suggest that we have wording saying the recommended
            approach is to include the overload report in all response
            messages for the reasons listed by Maria Cruz. 
            

            

            I also suggest that we include Nirav's proposal that if a
            reporting node knows that a reacting node has already
            received an overload report then it may choose to not send
            it again.  I don't think we need to including anything about
            how the reporting node knows but we should include wording
            about networks architectures that make it difficult to
            know.  The case of agents acting as reacting nodes for non
            supporting clients being one example.

            

          We also need to make sure that the recommended
            approach is not precluded by Nirav's proposal.

            

            I propose the following normative wording, which can be
            supplemented by Maria Cruz's reasons for recommending that
            the overload report is always included.

            

            -----

            

            A reporting node MUST ensure that all reacting nodes receive
            new overload reports.

            

            It is recommended that a reporting node include overload
            reports in all answer messages sent to reacting nodes. 
            

            

            Note - the reporting node may also include the overload
            report in answer messages sent to non reacting nodes if that
            is more efficient.  The overload report will just be ignored
            by a Diameter node that does not support DOIC.

            

            A reporting node MAY choose to not send an overload report
            to a reacting node if it can guarantee that the reacting
            node already has received the overload report.

            

            Note - the only sure way, without proprietary mechanisms, to
            know that a reacting node has received an overload report is
            when the reacting node is a client and there is no agent
            between the client and the reporting node.

        

          
On 2/10/14 3:52 AM, Maria
              Cruz Bartolome wrote:

        

        

          
Hello Nirav,

          
 

          
Any solution should balance different factors, efficiency could be discussed from different perspectives, but first we need to assure the mechanism we are defining is providing valid OLR to reacting nodes.

          
 

          
Your proposed text  

          
" Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP."

          
 

          
If the reporting is not aware about whether or not overload report is provided to the reacting node, and it decides (since it is a "may") to do not send the OLR again, then overload mitigation mechanism will not work in case OLR was not properly received by corresponding potential reacting nodes. And we need to note that "reacting nodes" could be not only the client, but ANY agent used for routing (not only when the agent is providing service to a Realm, but when it is reacting on behalf of a non-supporting client). 

          
Then, on one hand it is not simple to know when reacting nodes have valid OLR info (as explained below), but if OLR is not sent again (as per your proposed "may") then one or multiple reacting nodes do not have the required OLR, then overload mitigation will not work.

          
 

          
Therefore, in my opinion, the simplest way to provide required information is to provide OLR in ALL answers.

          
 

          
Best regards

          
/MCruz

          
 

          
-----Original Message-----

          
From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com] 

          
Sent: lunes, 10 de febrero de 2014 10:42

          
To: Maria Cruz Bartolome; dime@ietf.org

          
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
But Maria-Cruz,

          
 

          
How can we say that "including the OLR in all the answer messages is simple and efficient?"

          
It is simple for sure but not efficient. 

          
 

          
A slightly different wording from what I proposed earlier is, When the reporting node has a new overload report that needs to be provided to a reacting node (by updating the earlier provided overload report or by providing the overload report for the first time), it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.

          
 

          
Regards,

          
Nirav.

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome

          
Sent: Monday, February 10, 2014 3:03 PM

          
To: dime@ietf.org

          
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Nirav, all,

          
 

          
I think we should define an accurate and robust solution, as efficient and simple as possible.

          
I understand your proposal as a pure "may", but leaving it up to implementation does not assure reacting node has valid OLR information, what is basic for this mechanism to work. 

          
 

          
Best regards

          
/MCruz

          
 

          
-----Original Message-----

          
From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]

          
Sent: lunes, 10 de febrero de 2014 10:12

          
To: Maria Cruz Bartolome; dime@ietf.org

          
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Maria-Cruz,

          
 

          
I fully agree with you on "sending OLR in ALL answers has some important advantages".

          
And we are not trying to prevent it - at least that is my intention. 

          
But the main question is, are we trying to prevent any other possible implementation, which may be smarter and can avoid including redundant OLR in all the answer message?

          
 

          
Most probably, the very first implementation of overload control will include OLR in all the answer messages.

          
But at the same time, I do not want to restrict the developers which can come up with some nice tweaks and tricks to avoid sending the same information in every message. And this is where we need to be careful and avoid putting such restrictions in protocol definition. 

          
What do you think?

          
 

          
This also the reason I was suggesting loose description of when to include OLR (from the reporting node point of view).

          
 

          
Regards,

          
Nirav.

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome

          
Sent: Friday, February 07, 2014 8:57 PM

          
To: dime@ietf.org

          
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Hello Ulrich, Nirav,

          
 

          
I agree with Ulrich that the text provided by Nirav is just a MAY, and whether or not the server sends an OLR in all answers shall not be just a MAY.

          
 

          
On the other hand, criteria provided by Ulrich on when OLR has to be sent requires the server has some knowledge:

          
a) the reporting node knows that the reacting node has already got the latest OLR

          
b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire

          
c) otherwise

          
 

          
Reporting node must have some knowledge about OLR reception/status in reacting node. How does server acquire this knowledge? 

          
Take into account as well that a "reacting" node may be both an Agent (in case it provides service to a realm or acting on behalf of a non-supporting client)  and a Client. In the case of Agents, in fact the Server may not even know if this is going to act as a reacting node or just transparently, in fact, the server does not need to have any knowledge about what agents in the chain to the final Client.

          
 

          
Therefore, I definitely think that sending OLR in ALL answers has some important advantages:

          
- state-less implementation (transaction or session) is simpler,

          
- the server does not need to determine whether or not to send an OL to a reacting node

          
- the server does not need to bother whether an reacting node has already received an OLR or whether this OLR is still valid (has not expired).

          
- sending an additional AVP is not processing consuming, in comparison with required above checks (if this is not sent). 

          
  In fact, in an overload situation, the easiest and least complex is to send information out to all affected/applicable nodes, 

          
  and the latter should take care to take appropriate actions  

          
- more robust solution, as no need to cater for all the checks on the need to send information,  for situations where an answer message is lost,  …

          
 

          
 

          
Best regards

          
/MCruz

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

          
Sent: viernes, 07 de febrero de 2014 10:59

          
To: ext Nirav Salot (nsalot); ext lionel.morand@orange.com; ext Steve Donovan; dime@ietf.org

          
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Nirav,

          
 

          
I'm afraid your proposed text does not reflect the intention.

          
 

          
"when it wants to provide/update....it shall include..." translates to "...it may include...".

          
 

          
"in other cases" in the given context translates to "when it does not want to provide/update..."

          
 

          
 

          
We have the following cases:

          
a) the reporting node knows that the reacting node has already got the latest OLR

          
b) the reporting node is not overloaded (i.d. does not want a throttling) and knows that the reacting node has got an OLR that will soon expire

          
c) otherwise

          
 

          
in case a) the reporting node may or may not replay the OLR in case b) the reporting node may or may not upddate the reacting node with the latest OLR in case c) the reporting node MUST include the OLR in the answer (the reporting node does not know whether this is a replay or an update)

          
 

          
Ulrich

          
 

          
 

          
-----Original Message-----

          
From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]

          
Sent: Thursday, February 06, 2014 4:49 PM

          
To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Steve Donovan; dime@ietf.org

          
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Ulrich,

          
 

          
It seems we all are on same page but probably the proposed wording below is not the best.

          
How about the following.

          
 

          
When the reporting node wants to provide new overload report or wants to update the earlier provided overload report towards a reacting node, it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.

          
 

          
Regards,

          
Nirav.

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

          
Sent: Thursday, February 06, 2014 3:57 PM

          
To: ext lionel.morand@orange.com; Nirav Salot (nsalot); ext Steve Donovan; dime@ietf.org

          
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Nirav, Lionel,

          
 

          
I can understand Nirav's concern (although violating REQ10) and hop it is addressed by the modified principle 2':

          
 

          
2'. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got reasonable overload control information (e.g. the latest OLR, which may be an OLR requesting traffic reduction or an OLR indicating "no overload", or an old  but soon expiring OLR when the reporting node is not overloaded); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.

          
 

          
I don't agree with Lionels do-what-you-want approach. Overload control will not work when we allow the reporting node not to update reacting nodes, which are not (sufficiantly) aware of the current overload status, with up to date OLRs.

          
 

          
Ulrich  

          
 

          
 

          
 

          
-----Original Message-----

          
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]

          
Sent: Thursday, February 06, 2014 10:20 AM

          
To: Nirav Salot (nsalot); Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org

          
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
 

          
 

          
-----Message d'origine-----

          
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoyé : jeudi 6 février 2014 10:08 À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Ulrich,

          
 

          
I am not sure about forcing this behavior on reporting node "otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP."

          
The reporting node may simply not include OLR assuming that the earlier provided OLR will expire and the reacting node will stop throttling the traffic.

          
 

          
[LM] Agree. In other words, it is not deemed required for the default mechanism described in this draft. How and when the reporting node decides to include the OLR in the answer may depend on the application or on the implementation. At least, it is my current understanding.

          
 

          
As we had discussed earlier, there is no need for the reporting node to explicitly stop throttling at each reacting node at the same time. In other words, the reporting node can allow the natural expiry of the OLR to facilitate slow ramp of the signaling traffic towards it.

          
 

          
[LM] Agree

          
 

          
There may be other cases, e.g. when the reporting node knows that the last overload situation ended long time back in the past, there is no need for it to include OLR if currently there is no overload condition.

          
 

          
[LM] Agree

          
 

          
Rest of the principles below are fine with me.

          
 

          
[LM] Agree

          
 

          
Regards,

          
Nirav.

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

          
Sent: Thursday, February 06, 2014 2:23 PM

          
To: ext Steve Donovan; Nirav Salot (nsalot); dime@ietf.org

          
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Actually we seem to agree on two principles:

          
1. Lack of OLR means "no change"

          
2. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got the latest OLR (which may be an OLR requesting traffic reduction or an OLR indicating "no overload"); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.

          
 

          
Can people please confirm.

          
 

          
Ulrich

          
 

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

          
Sent: Wednesday, February 05, 2014 4:35 PM

          
To: Nirav Salot (nsalot); dime@ietf.org

          
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
Agreed.  To restate -- lack of an overload report does not change the current overload state for the host or realm.  If there is a currently active overload report then it continues to apply until it either times out or is explicitly changed with a new overload report.  If there is no currently active overload report then lack of an overload report implies there is no overload for the host and realm.

          
 

          
Steve

          
On 2/5/14 9:19 AM, Nirav Salot (nsalot) wrote:

          
I agree with Steve except the part "shouldn’t lack of OLR be interpreted as not overloaded?"

          
 

          
We had some discussion sometime back and thought that it is reasonable to not mandate the server to include the OLR in every answer message. E.g. when the server is capable of tracking what is sent to which client and hence wants to avoid sending information which is redundant. But this is optional implementation and at the same time need not be prohibited from protocol point of view.

          
 

          
So basically, the lack of OLR should not affect the previously received OLR at the reacting node. The reacting node can continue to react based on older OLR until the expiry of the validity-period or when the explicit OLR with "0" overload-metric is received.

          
In my view, this allows for flexible implementation at the reporting node and sound handling of OLR at the reacting node.

          
 

          
Regards,

          
Nirav.

          
 

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

          
Sent: Wednesday, February 05, 2014 8:00 PM

          
To: dime@ietf.org

          
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
inline

          
On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

          
Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).

          
SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?

          
 

          
 

          
 

          
 

          
Other criteria like REQ18 or REQ13 do not seem to matter.

          
SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.

          
 

          
 

          
 

          
 

          
For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?

          
SRD> That is the purpose of the sequence number.

          
 

          
 

          
 

          
 

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)

          
Sent: Wednesday, February 05, 2014 5:27 AM

          
To: lionel.morand@orange.com; dime@ietf.org

          
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
I share the same opinion as Lionel.

          
 

          
Regards,

          
Nirav.

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com

          
Sent: Tuesday, February 04, 2014 9:07 PM

          
To: dime@ietf.org

          
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 

          
So the options would be:

          
1- OC-OLR AVP in every answer

          
2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.

          
 

          
If there is no other criterion, the option 1 seems the best approach.

          
 

          
Lionel

          
 

          
-----Message d'origine-----

          
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

          
Envoyé : mardi 4 février 2014 09:49

          
À : MORAND Lionel IMT/OLN

          
Cc : dime@ietf.org

          
Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

          
 

          
 It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number

          
 (TimeStamp) of the OLR according to which the throttling (which was

          
 survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.

          
 Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.

          
 The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).

          
 The feedback mechanism also allows to address REQ 18 from RFC 7068.

          
 In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.

          
 

          
 

          
 

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

          
 

          
_________________________________________________________________________________________________________________________

          
 

          
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.

          
 

          
_______________________________________________

          
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

        

        
 

        
_________________________________________________________________________________________________________________________

        
 

        
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.

        
_________________________________________________________________________________________________________________________

        
 

        
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.

      

      

      

      

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


    

    

  


--------------080903030807000303040801--


From srdonovan@usdonovans.com  Thu Feb 13 04:24:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1271A0216 for ; Thu, 13 Feb 2014 04:24:15 -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
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 D3ZBdLOAiJcK for ; Thu, 13 Feb 2014 04:24:12 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 262AB1A0213 for ; Thu, 13 Feb 2014 04:24:12 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53692 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvKn-0003qG-E0 for dime@ietf.org; Thu, 13 Feb 2014 04:24:11 -0800
Message-ID: <52FCB96A.1040201@usdonovans.com>
Date: Thu, 13 Feb 2014 06:24:10 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050506000105090905090203"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #46: Bad normative advice on not	letting	overload reports expire
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:24:15 -0000

This is a multi-part message in MIME format.
--------------050506000105090905090203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

I thought we already had wording in the draft about the reacting node
gradually increasing traffic sent to the host after the end of an
overload condition.  This would apply both when the reporting node
explicitly ends the overload period and when the validation timer expires.

Does this cover your concern?

Steve

On 2/12/14 1:30 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Dear all
>
> I come back on this ticket and your current conclusions;
> We are in the area of guidance about the use of the expiry timer  but I think there are important points to take care with the expiry timer :
>
> If a server  sends OLRs with 50% traffic reduction, the client will divide the traffic by two. Then, if the server does not update the expiry timer and leaves  it expire and that traffic conditions have not changed  on client side, the client will stop  throttling  and will double the traffic which  I think the server will worry about. 
>  We need to avoid oscillations, and have a graceful behavior as expressed in the requirements 2 , 3 and 7. In fact the server should  progressively decrease the value of the % reduction in OLRs it sends according to the diminution of the traffic it will observe (due to the decrease of the input traffic coming back to normal conditions  on client side)  This is when server will  send  OLRs with 0% of traffic reduction without generating overload that it can  leave the expiry timer expire and no more send OLRs.
> The other application of the expiry timer is for error or out of sync situations (Ulrich I think mentioned this point)  where the expiry timer acts as a reset of the DOC mechanism but in such a case the server should  expect a sudden increase of traffic from clients generating overload on its side and then enter in the overload control by generating the relevant OLRs . 
>
> So for me the use of expiry timer should be quite limited, the main tool of overload control is the % of reduction put the OLRs and its evolution over time. Ben has mentioned other possibilities in the use of the expiry time, may be, but we have to take care of the ones I mentioned  
>
> So I consider worthwhile to have  some recommendations in the draft on the expiry timer use.
>
> Best regards
>
> JJacques 
>  
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : mardi 11 février 2014 23:32
> À : Maria Cruz Bartolome
> Cc : dime@ietf.org list
> Objet : Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>
>
> Fine with me.
>
> - Jouni
>
> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome  wrote:
>
>> Ben, Nirav,
>>
>> I follow same argumentation.
>> Regards
>> /MCruz
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot 
>> (nsalot)
>> Sent: martes, 11 de febrero de 2014 11:23
>> To: Ben Campbell; Jouni Korhonen
>> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting 
>> overload reports expire
>>
>> Ben,
>>
>> I resonate with your thinking below.
>>
>> Regards,
>> Nirav.
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>> Sent: Monday, February 10, 2014 9:54 PM
>> To: Jouni Korhonen
>> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting 
>> overload reports expire
>>
>>
>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen  wrote:
>>
>>> My reasoning for explicit termination was that knowing the 
>>> implementation folks they will let overload conditions expire unless advised otherwise.
>>> And having unnecessary stuff hanging around waiting for a cleanup is 
>>> not a good thing in general. But I am open here for other options..
>>>
>> I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report. 
>>
>> And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------050506000105090905090203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      I thought we already had wording in the draft about the reacting
      node gradually increasing traffic sent to the host after the end
      of an overload condition.  This would apply both when the
      reporting node explicitly ends the overload period and when the
      validation timer expires.

      

      Does this cover your concern?

      

      Steve

      

    
    
On 2/12/14 1:30 PM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
Dear all

I come back on this ticket and your current conclusions;
We are in the area of guidance about the use of the expiry timer  but I think there are important points to take care with the expiry timer :

If a server  sends OLRs with 50% traffic reduction, the client will divide the traffic by two. Then, if the server does not update the expiry timer and leaves  it expire and that traffic conditions have not changed  on client side, the client will stop  throttling  and will double the traffic which  I think the server will worry about. 
 We need to avoid oscillations, and have a graceful behavior as expressed in the requirements 2 , 3 and 7. In fact the server should  progressively decrease the value of the % reduction in OLRs it sends according to the diminution of the traffic it will observe (due to the decrease of the input traffic coming back to normal conditions  on client side)  This is when server will  send  OLRs with 0% of traffic reduction without generating overload that it can  leave the expiry timer expire and no more send OLRs.
The other application of the expiry timer is for error or out of sync situations (Ulrich I think mentioned this point)  where the expiry timer acts as a reset of the DOC mechanism but in such a case the server should  expect a sudden increase of traffic from clients generating overload on its side and then enter in the overload control by generating the relevant OLRs . 

So for me the use of expiry timer should be quite limited, the main tool of overload control is the % of reduction put the OLRs and its evolution over time. Ben has mentioned other possibilities in the use of the expiry time, may be, but we have to take care of the ones I mentioned  

So I consider worthwhile to have  some recommendations in the draft on the expiry timer use.

Best regards

JJacques 
 

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoyé : mardi 11 février 2014 23:32
À : Maria Cruz Bartolome
Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire


Fine with me.

- Jouni

On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:



      

        
Ben, Nirav,

I follow same argumentation.
Regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot 
(nsalot)
Sent: martes, 11 de febrero de 2014 11:23
To: Ben Campbell; Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting 
overload reports expire

Ben,

I resonate with your thinking below.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, February 10, 2014 9:54 PM
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting 
overload reports expire


On Feb 10, 2014, at 5:16 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:



        

          
My reasoning for explicit termination was that knowing the 
implementation folks they will let overload conditions expire unless advised otherwise.
And having unnecessary stuff hanging around waiting for a cleanup is 
not a good thing in general. But I am open here for other options..



        

        
I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report. 

And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.

_______________________________________________
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

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



    

    

  


--------------050506000105090905090203--


From srdonovan@usdonovans.com  Thu Feb 13 04:26:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5B01A01EC for ; Thu, 13 Feb 2014 04:26:01 -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
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 RRbZZgrDc5Ui for ; Thu, 13 Feb 2014 04:25:57 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD3C1A01AB for ; Thu, 13 Feb 2014 04:25:57 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53693 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvMY-0005GR-0j for dime@ietf.org; Thu, 13 Feb 2014 04:25:55 -0800
Message-ID: <52FCB9D6.3070908@usdonovans.com>
Date: Thu, 13 Feb 2014 06:25:58 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com>
In-Reply-To: <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com>
Content-Type: multipart/alternative; boundary="------------090305010805010406030807"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within	OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:26:01 -0000

This is a multi-part message in MIME format.
--------------090305010805010406030807
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Jouni,

The important thing is to define the properties.  There should be no
harm in giving one suggested implementation.

Steve

On 2/11/14 4:42 PM, Jouni Korhonen wrote:
> If the NTP is only going to be guidance when building the globally
> and eternally unique sequence number, IMHO better not mention NTP
> then at all. Just include the required properties below. One less
> mandatory reference..
>
> - Jouni
>
>
> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome  wrote:
>
>> It sounds reasonable to me as well.
>> /MCruz
>>  
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>> Sent: lunes, 10 de febrero de 2014 14:59
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> +1
>> On 2/10/14 7:47 AM, lionel.morand@orange.com wrote:
>> I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are:
>>  
>> - Globally/eternally unique
>> - increase monotonically over time, including over a reboot (as remind by Steve) 
>>  
>> The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties.
>>  
>> Lionel
>>  
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
>> Envoyé : samedi 8 février 2014 11:33
>> À : Wiehe, Ulrich (NSN - DE/Munich)
>> Cc : dime@ietf.org
>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>>  
>> Sounds acceptable. Would the following then work for all:
>>  
>> o clarify that once the overload report expires there is no
>>   reason to remember anything about it
>> o the sequence number would be similar to session-id.. based 
>>   on the NTP time + any vendor specific data to make it 
>>   "globally and eternally unique".
>>  
>> - Jouni
>>  
>>  
>>  
>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>  
>> Steve,
>>  
>> sounds like an acceptable proposal which allows to come back to sync after OLR expiry.
>> This requires however an update of clause 5.5.2 to clearly state
>> Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 
>>  
>>  
>> Ulrich
>>  
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Thursday, February 06, 2014 4:50 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> A couple of things - 
>>  
>> The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.
>>  
>> We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 
>>  
>> The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.
>>  
>> It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."
>>  
>> Steve
>>  
>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> I cannot understand what is the problem with mandating timestamp.
>> But I can see interoperability problems with the current definition:
>>  
>> Assume the sender sends sequence numbers
>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
>> but the receicer for any reason receives 
>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
>> The receiver would accept
>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>> and then silently discards
>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
>> with no way to come back to sync.
>>  
>> Are we sure that this cannot happen?
>>  
>> Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.
>>  
>> Ulrich
>>  
>>  
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
>> Sent: Wednesday, February 05, 2014 4:57 PM
>> To: ext lionel.morand@orange.com
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.
>>  
>> On Feb 5, 2014, at 9:53 AM,   wrote:
>>  
>> Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
>> We are not violating anything.
>>  
>> Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.
>>  
>> -----Message d'origine-----
>> De : Ben Campbell [mailto:ben@nostrum.com] 
>> Envoyé : mercredi 5 février 2014 16:47
>> À : MORAND Lionel IMT/OLN
>> Cc : Steve Donovan; dime@ietf.org
>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:
>>  
>> "In particular, [normative requirements] MUST only be used where it is
>>   actually required for interoperation or to limit behavior which has
>>   potential for causing harm (e.g., limiting retransmisssions)  "
>>  
>> The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.
>>  
>> On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
>>  
>> I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.
>>  
>> Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?
>>  
>> Lionel
>>  
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>> Envoyé : mercredi 5 février 2014 15:34
>> À : dime@ietf.org
>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.
>>  
>> Steve
>>  
>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>> I also agree.
>>  
>> Regards,
>> Nirav.
>>  
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
>> Sent: Tuesday, February 04, 2014 11:50 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> The existing wording seems actually fuzzy.
>> If it is "like an NTP timestamp", be proud and say it loud!
>>  
>> In summary: ok with the proposal if it clarifies this handling of this sequence-number.
>>  
>> Lionel
>>  
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoyé : mardi 4 février 2014 09:50
>> À : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> The -01 draft says in clause 4.4:
>>    From the functionality point of view, the OC-Sequence-Number AVP MUST
>>    be used as a non-volatile increasing counter between two overload
>>    control endpoints (neglecting the fact that the contents of the AVP
>>    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
>>    required to be unique between two overload control endpoints.
>>    Sequence numbers are treated in uni-directional manner, i.e. two
>>    sequence numbers on each direction between two endpoints are not
>>    related or correlated.
>>  
>>    When generating sequence numbers, the new sequence number MUST be
>>    greater than any sequence number previously seen between two
>>    endpoints within a time window that tolerates the wraparound of the
>>    NTP timestamp (i.e. approximately 68 years).
>>  
>>  
>> With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
>> It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.
>>  
>>  
>> _________________________________________________________________________________________________________________________
>>  
>> 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.
>>  
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>  
>>  
>> _________________________________________________________________________________________________________________________
>>  
>> 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.
>>  
>> _______________________________________________
>> 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
>>  
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>  
>> _________________________________________________________________________________________________________________________
>>  
>> 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.
>>  
>> _______________________________________________
>> 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
>


--------------090305010805010406030807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jouni,

      

      The important thing is to define the properties.  There should be
      no harm in giving one suggested implementation.

      

      Steve

      

    
    
On 2/11/14 4:42 PM, Jouni Korhonen
      wrote:

    

    

      
If the NTP is only going to be guidance when building the globally
and eternally unique sequence number, IMHO better not mention NTP
then at all. Just include the required properties below. One less
mandatory reference..

- Jouni


On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:



      

        
It sounds reasonable to me as well.
/MCruz
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 14:59
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
+1
On 2/10/14 7:47 AM, lionel.morand@orange.com wrote:
I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are:
 
- Globally/eternally unique
- increase monotonically over time, including over a reboot (as remind by Steve) 
 
The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties.
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoyé : samedi 8 février 2014 11:33
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
 
Sounds acceptable. Would the following then work for all:
 
o clarify that once the overload report expires there is no
  reason to remember anything about it
o the sequence number would be similar to session-id.. based 
  on the NTP time + any vendor specific data to make it 
  "globally and eternally unique".
 
- Jouni
 
 
 
On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
 
Steve,
 
sounds like an acceptable proposal which allows to come back to sync after OLR expiry.
This requires however an update of clause 5.5.2 to clearly state
Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 
 
 
Ulrich
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 06, 2014 4:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
A couple of things - 
 
The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.
 
We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 
 
The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.
 
It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."
 
Steve
 
On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
I cannot understand what is the problem with mandating timestamp.
But I can see interoperability problems with the current definition:
 
Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.
 
Are we sure that this cannot happen?
 
Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.
 
Ulrich
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, February 05, 2014 4:57 PM
To: ext lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.
 
On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:
 
Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
We are not violating anything.
 
Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] 
Envoyé : mercredi 5 février 2014 16:47
À : MORAND Lionel IMT/OLN
Cc : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:
 
"In particular, [normative requirements] MUST only be used where it is
  actually required for interoperation or to limit behavior which has
  potential for causing harm (e.g., limiting retransmisssions)  "
 
The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.
 
On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
 
I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.
 
Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:34
À : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.
 
Steve
 
On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
I also agree.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 11:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
The existing wording seems actually fuzzy.
If it is "like an NTP timestamp", be proud and say it loud!
 
In summary: ok with the proposal if it clarifies this handling of this sequence-number.
 
Lionel
 
-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:50
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
#32: Sequence-Number Time-Stamp values within OC-OLR
 
The -01 draft says in clause 4.4:
   From the functionality point of view, the OC-Sequence-Number AVP MUST
   be used as a non-volatile increasing counter between two overload
   control endpoints (neglecting the fact that the contents of the AVP
   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
   required to be unique between two overload control endpoints.
   Sequence numbers are treated in uni-directional manner, i.e. two
   sequence numbers on each direction between two endpoints are not
   related or correlated.
 
   When generating sequence numbers, the new sequence number MUST be
   greater than any sequence number previously seen between two
   endpoints within a time window that tolerates the wraparound of the
   NTP timestamp (i.e. approximately 68 years).
 
 
With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.
 
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
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
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
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



    

    

  


--------------090305010805010406030807--


From srdonovan@usdonovans.com  Thu Feb 13 04:27:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864D11A020A for ; Thu, 13 Feb 2014 04:27:04 -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
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 bsw6gRDIa8R1 for ; Thu, 13 Feb 2014 04:27:00 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 096FE1A0215 for ; Thu, 13 Feb 2014 04:26:54 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53701 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvNT-00062Q-3y for dime@ietf.org; Thu, 13 Feb 2014 04:26:52 -0800
Message-ID: <52FCBA0F.1060503@usdonovans.com>
Date: Thu, 13 Feb 2014 06:26:55 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>  <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B3055@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3055@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------040403010408050206040400"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #32:	Sequence-Number	Time-Stamp	values	within	OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:27:04 -0000

This is a multi-part message in MIME format.
--------------040403010408050206040400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Ulrich,

I agree, we should say must not remember.  Otherwise it will be more
difficult to get back into syncronization.

Steve

On 2/12/14 7:28 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Maybe its worth to explicitly say that "... there is no reason to remember anything about it" includes "no need for reacting nodes to remember sequence numbers of expired OLRs" or even mandate that sequence numbers of expired OLRs must not be remembered by reacting nodes.
> Ulrich
>
> -----Original Message-----
> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
> Sent: Monday, February 10, 2014 2:48 PM
> To: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: RE: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>
> I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are:
>
> - Globally/eternally unique
> - increase monotonically over time, including over a reboot (as remind by Steve) 
>
> The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : samedi 8 février 2014 11:33
> À : Wiehe, Ulrich (NSN - DE/Munich)
> Cc : dime@ietf.org
> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>
>
> Sounds acceptable. Would the following then work for all:
>
> o clarify that once the overload report expires there is no
>   reason to remember anything about it
> o the sequence number would be similar to session-id.. based 
>   on the NTP time + any vendor specific data to make it 
>   "globally and eternally unique".
>
> - Jouni
>
>
>
> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> Steve,
>>  
>> sounds like an acceptable proposal which allows to come back to sync after OLR expiry.
>> This requires however an update of clause 5.5.2 to clearly state
>> Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 
>>
>>  
>> Ulrich
>>  
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Thursday, February 06, 2014 4:50 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> A couple of things - 
>>
>> The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.
>>
>> We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 
>>
>> The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.
>>
>> It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."
>>
>> Steve
>>
>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> I cannot understand what is the problem with mandating timestamp.
>> But I can see interoperability problems with the current definition:
>>  
>> Assume the sender sends sequence numbers
>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
>> but the receicer for any reason receives 
>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
>> The receiver would accept
>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>> and then silently discards
>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
>> with no way to come back to sync.
>>  
>> Are we sure that this cannot happen?
>>  
>> Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.
>>  
>> Ulrich
>>  
>>  
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
>> Sent: Wednesday, February 05, 2014 4:57 PM
>> To: ext lionel.morand@orange.com
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.
>>  
>> On Feb 5, 2014, at 9:53 AM,   wrote:
>>  
>> Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
>> We are not violating anything.
>>  
>> Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.
>>  
>> -----Message d'origine-----
>> De : Ben Campbell [mailto:ben@nostrum.com] 
>> Envoyé : mercredi 5 février 2014 16:47
>> À : MORAND Lionel IMT/OLN
>> Cc : Steve Donovan; dime@ietf.org
>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:
>>  
>> "In particular, [normative requirements] MUST only be used where it is
>>   actually required for interoperation or to limit behavior which has
>>   potential for causing harm (e.g., limiting retransmisssions)  "
>>  
>> The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.
>>  
>> On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
>>  
>> I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.
>>  
>> Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?
>>  
>> Lionel
>>  
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>> Envoyé : mercredi 5 février 2014 15:34
>> À : dime@ietf.org
>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.
>>  
>> Steve
>>  
>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>> I also agree.
>>  
>> Regards,
>> Nirav.
>>  
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
>> Sent: Tuesday, February 04, 2014 11:50 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> The existing wording seems actually fuzzy.
>> If it is "like an NTP timestamp", be proud and say it loud!
>>  
>> In summary: ok with the proposal if it clarifies this handling of this sequence-number.
>>  
>> Lionel
>>  
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Envoyé : mardi 4 février 2014 09:50
>> À : MORAND Lionel IMT/OLN
>> Cc : dime@ietf.org
>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>  
>> The -01 draft says in clause 4.4:
>>    From the functionality point of view, the OC-Sequence-Number AVP MUST
>>    be used as a non-volatile increasing counter between two overload
>>    control endpoints (neglecting the fact that the contents of the AVP
>>    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
>>    required to be unique between two overload control endpoints.
>>    Sequence numbers are treated in uni-directional manner, i.e. two
>>    sequence numbers on each direction between two endpoints are not
>>    related or correlated.
>>  
>>    When generating sequence numbers, the new sequence number MUST be
>>    greater than any sequence number previously seen between two
>>    endpoints within a time window that tolerates the wraparound of the
>>    NTP timestamp (i.e. approximately 68 years).
>>  
>>  
>> With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
>> It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.
>>  
>>  
>> _________________________________________________________________________________________________________________________
>>  
>> 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.
>>  
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>  
>>  
>> _________________________________________________________________________________________________________________________
>>  
>> 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.
>>  
>> _______________________________________________
>> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------040403010408050206040400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I agree, we should say must not remember.  Otherwise it will be
      more difficult to get back into syncronization.

      

      Steve

      

    
    
On 2/12/14 7:28 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Maybe its worth to explicitly say that "... there is no reason to remember anything about it" includes "no need for reacting nodes to remember sequence numbers of expired OLRs" or even mandate that sequence numbers of expired OLRs must not be remembered by reacting nodes.
Ulrich

-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
Sent: Monday, February 10, 2014 2:48 PM
To: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: RE: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are:

- Globally/eternally unique
- increase monotonically over time, including over a reboot (as remind by Steve) 

The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoyé : samedi 8 février 2014 11:33
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


Sounds acceptable. Would the following then work for all:

o clarify that once the overload report expires there is no
  reason to remember anything about it
o the sequence number would be similar to session-id.. based 
  on the NTP time + any vendor specific data to make it 
  "globally and eternally unique".

- Jouni



On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



      

        
Steve,
 
sounds like an acceptable proposal which allows to come back to sync after OLR expiry.
This requires however an update of clause 5.5.2 to clearly state
Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 

 
Ulrich
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 06, 2014 4:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
A couple of things - 

The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.

We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 

The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.

It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."

Steve

On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
I cannot understand what is the problem with mandating timestamp.
But I can see interoperability problems with the current definition:
 
Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.
 
Are we sure that this cannot happen?
 
Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.
 
Ulrich
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, February 05, 2014 4:57 PM
To: ext lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.
 
On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:
 
Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
We are not violating anything.
 
Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] 
Envoyé : mercredi 5 février 2014 16:47
À : MORAND Lionel IMT/OLN
Cc : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:
 
"In particular, [normative requirements] MUST only be used where it is
  actually required for interoperation or to limit behavior which has
  potential for causing harm (e.g., limiting retransmisssions)  "
 
The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.
 
On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:
 
I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.
 
Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:34
À : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.
 
Steve
 
On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
I also agree.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 11:50 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
The existing wording seems actually fuzzy.
If it is "like an NTP timestamp", be proud and say it loud!
 
In summary: ok with the proposal if it clarifies this handling of this sequence-number.
 
Lionel
 
-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:50
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
 
#32: Sequence-Number Time-Stamp values within OC-OLR
 
The -01 draft says in clause 4.4:
   From the functionality point of view, the OC-Sequence-Number AVP MUST
   be used as a non-volatile increasing counter between two overload
   control endpoints (neglecting the fact that the contents of the AVP
   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
   required to be unique between two overload control endpoints.
   Sequence numbers are treated in uni-directional manner, i.e. two
   sequence numbers on each direction between two endpoints are not
   related or correlated.
 
   When generating sequence numbers, the new sequence number MUST be
   greater than any sequence number previously seen between two
   endpoints within a time window that tolerates the wraparound of the
   NTP timestamp (i.e. approximately 68 years).
 
 
With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.
 
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
_________________________________________________________________________________________________________________________
 
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.
 
_______________________________________________
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


      

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

_________________________________________________________________________________________________________________________

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.

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



    

    

  


--------------040403010408050206040400--


From srdonovan@usdonovans.com  Thu Feb 13 04:35:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFF61A0218 for ; Thu, 13 Feb 2014 04:35:09 -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
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 u9Bb1PRnhk6S for ; Thu, 13 Feb 2014 04:35:04 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 299B11A0213 for ; Thu, 13 Feb 2014 04:35:04 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53717 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvVK-000584-R9 for dime@ietf.org; Thu, 13 Feb 2014 04:35:03 -0800
Message-ID: <52FCBBF7.7000700@usdonovans.com>
Date: Thu, 13 Feb 2014 06:35:03 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060206090203070809020201"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:35:10 -0000

This is a multi-part message in MIME format.
--------------060206090203070809020201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Ok, Ok, no reason to gang up on me. :-)

What we have here is an overload report to reduce realm routed
requests.  I think we should be explicit in the draft to define it as such.

I am still concerned that we do not have a way to indicate overload of
the realm as a whole.  I'll enter a new trouble ticket to capture this
issue.

Steve

On 2/11/14 5:11 PM, Jouni Korhonen wrote:
> So are we converging to an agreement here? I could join the
> camp of U/MC/N/L/J..
>
> - Jouni
>
> On Feb 11, 2014, at 11:52 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:
>
>> Dear all
>>
>> I come back a bit late on this long debate to confirm my position that I share with  Ulrich MCruz Nirav and I think now Lionel and that I again summarize here in these two statements : 
>> - Host OLR based control applies to requests where Destination Host is known
>> - Realm OLR based control applies to requests where Destination Host is not known (only the Destination realm).
>>
>>> From History, we have started by defining the Host report so to control the traffic towards each server,(our main goal), but we observed a difficulty when the reacting node does not know  the host to which a  request is sent and for this  we introduced the realm report. Annex B1 example in the draft is the use case well illustrating  this approach and  which corresponds to the above statements.
>> Another point which was mentioned, is, for  the reacting node, to keep the throttling based on realm report independent of the throttling based on the host report, this is naturally achieved with the two above statements as we distinguish requests having a destination host from those having not. But if we can apply both reports to the same request, then we need additional rules eg  which report prevails; in the discussion there were also divergence on this point, but we can imagine other rules eg the report that has the highest reduction value prevails, why not in some cases, so a trend to overcomplexify. 
>>
>> For me the two above statements avoid overlapping between the two reports  and are simple to apply, so I keep my preference for these two statements.
>>
>> Best regards
>>
>> JJacques   
>>
>>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
>> Envoyé : mardi 11 février 2014 16:31
>> À : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org
>> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>
>> So now I understand Ulrich, Maria Cruz and JJ comments.
>>
>> "My" proposal would force the servers in the realm to always send an OLR just to say "I'm not overloaded" i.e. with the value 0. That is anyway a possibility.
>> But if we want to avoid that, Realm type must only apply to message without destination host.
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com Envoyé : mardi 11 février 2014 16:25 À : Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>
>> Hi Maria Cruz,
>>
>> Actually I've missed this point. Sorry.
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : mardi 11 février 2014 16:08 À : dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>
>>
>> On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:
>>> Lionel,
>>>
>>> About first case:
>>>
>>> - If the reacting node has received an indication only for Realm 
>>> traffic Reduction, apply Realm reduction is for any message, with 
>>> Destination-Realm and with/without Destination-Host
>>>
>>> I do not agree on this, since if Destination Host is used, there is no reason to throttle messages if this Host has not provided any OLR.
>> SRD> There is if the reacting node has received an overload report
>> requesting a traffic reduction on the realm.  The server/host does not have visibility of the entire realm. 
>>> This is in line with the example used from the beginning:
>>> ---------
>>> ..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>>> What is wrong with letting the client
>>> -not throttle host-type requests to S1, -throttle host type request to 
>>> S2 with 50% and -throttle realm type requests wit 25%?
>>> ------------
>>>
>>> And I think this is what JJ commented:
>>> [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>>>
>>> In my opinion, reducing traffic to S1 is wrong.
>> SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.
>>> Regards
>>> /MCruz
>>>
>>> -----Original Message-----
>>> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
>>> Sent: martes, 11 de febrero de 2014 11:57
>>> To: Maria Cruz Bartolome; dime@ietf.org
>>> Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>> Hi maria-cruz,
>>>
>>> JJ agreed on the following approach:
>>>
>>> - If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>>>
>>> - If the reacting node has received an indication only for host traffic reduction, apply host reduction for messages containing a Destination-Host. No reduction for messages with only a Destination-Realm.
>>> [JJ] OK
>>>
>>> - If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).
>>> [JJ] OK, Host reduction prevails
>>>
>>> In other words, as said earlier, the Host reduction prevails over realm reduction when the overloaded host is inside an overloaded realm and the reacting has received info about both type of overload.
>>>
>>> What is the issue with this approach?
>>>
>>> Regards,
>>>
>>> Lionel
>>>
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz 
>>> Bartolome Envoyé : mardi 11 février 2014 11:49 À : dime@ietf.org Objet 
>>> : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>> Hello,
>>> I agree with JJ:
>>>
>>> - If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>>>
>>> [MCruz] And... if the request is sent to a Destination-Host, if there is any applicable OLR, it will be received immediately in the answer, and will be applicable from next request on.
>>> Simple and robust in my opinion. Then, we do not need to evaluate whether we have OLR for Realm and/or Host, and even check their validity & applicability.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, 
>>> JEAN-JACQUES (JEAN-JACQUES)
>>> Sent: lunes, 10 de febrero de 2014 15:00
>>> To: dime@ietf.org
>>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>> Hi Lionel
>>>
>>> Please see in line
>>>
>>> -----Message d'origine-----
>>> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoyé 
>>> : lundi 10 février 2014 14:25 À : TROTTIN, JEAN-JACQUES 
>>> (JEAN-JACQUES); dime@ietf.org Objet : RE: [Dime] [dime] #34: Semantics 
>>> of OC-Report-Type AVP
>>>
>>> I disagree and my proposal was somehow misunderstood.
>>>
>>> I don't see the issue to have the following sequence:
>>>
>>> - If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.
>>>
>>> - If the reacting node has received an indication only for host traffic reduction, apply host reduction for messages containing a Destination-Host. No reduction for messages with only a Destination-Realm.
>>> [JJ] OK
>>>
>>> - If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).
>>> [JJ] OK, Host reduction prevails
>>>
>>> In other words, as said earlier, the Host reduction prevails over realm reduction when the overloaded host is inside an overloaded realm and the reacting has received info about both type of overload.
>>>
>>> Lionel
>>>
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, 
>>> JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 10 février 2014 13:56 À : 
>>> dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of 
>>> OC-Report-Type AVP
>>>
>>> Dear  all
>>>
>>> I share Ulrich and MCruz views,
>>> - Host OLR based control applies to requests where Destination Host is 
>>> known
>>> - Realm OLR based control applies to requests where Destination Host is not known (only the Destination realm).
>>>
>>> I think it is simple, otherwise as MCruz indicated it complicates; e.g about the Ulrich's example where the Host S1 is not overloaded but the realm is overloaded. the client will not receive Host OLR reports from host S1 (so no explicit traffic reduction requested by S1), but according to Lionel comment, I understand  client will have to throttle the requests sent to S1 according to realm OLR, so how to avoid this.
>>>
>>> JJacques
>>>
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz 
>>> Bartolome Envoyé : vendredi 7 février 2014 17:15 À : dime@ietf.org 
>>> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>> Dear all,
>>>
>>> I am in favor of the proposal made by Ulrich in the sequence diagram he provided.
>>> ----
>>> As a summary:
>>> Consequently the reacting node will receive realm type OLRs from the agent and host type OLRs from the servers.
>>> The received realm type OLR will be relevant for the reacting node when sending/throttling realm type requests; the received host type OLR will be relevant for the reacting node       when sending/throttling host type requests.
>>> -----
>>>
>>> It may occur though, that a Client has only received Realm type OLR, and then it has to send a request to one specific host, then the Client will not apply any restriction, but as soon as the response is received back, Client will update Host type OLR.  Same will apply when only Host type OLR has been received by Client.
>>> The alternative will be to always send back from an Agent both Host OLR plus Realm OLR, but I do not think this is necessary and may complicate the solution.
>>>
>>> Best regards
>>> /MCruz
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich 
>>> (NSN - DE/Munich)
>>> Sent: viernes, 07 de febrero de 2014 14:13
>>> To: ext Jouni Korhonen
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
>>> Sent: Friday, February 07, 2014 11:21 AM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
>>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>
>>>
>>> On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>
>>>> I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
>>>> What is wrong with letting the client -not throttle host-type 
>>>> requests to S1, -throttle host type request to
>>>> S2 with 50% and -throttle realm type requests wit 25%?
>>> Isn't this what Lionel said below?
>>>  no it is not
>>> I am OK with Lionel's
>>> "wording" here.
>>>
>>> - Jouni
>>>
>>>>
>>>>
>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext 
>>>> lionel.morand@orange.com
>>>> Sent: Wednesday, February 05, 2014 4:14 PM
>>>> To: Steve Donovan; dime@ietf.org
>>>> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>>
>>>> I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.
>>>>
>>>> Lioenl
>>>>
>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan 
>>>> Envoyé : mercredi 5 février 2014 15:56 À : dime@ietf.org Objet : Re:
>>>> [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>>>>
>>>> It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.
>>>>
>>>> If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.
>>>>
>>>> I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.
>>>>
>>>> Steve
>>>>
>>>> On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
>>>> The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
>>>> If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.
>>>>
>>>> Does it make sense?
>>>>
>>>> Lionel
>>>>
>>>> -----Message d'origine-----
>>>> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>>>> Envoyé : mardi 4 février 2014 09:55
>>>> À : MORAND Lionel IMT/OLN
>>>> Cc : dime@ietf.org
>>>> Objet : [dime] #34: Semantics of OC-Report-Type AVP
>>>>
>>>> #34: Semantics of OC-Report-Type AVP
>>>>
>>>> Text in clause 4.6  does not fully explain to which requests 
>>>> overload treatment of a given report type applies.
>>>> Proposal:
>>>>
>>>>    0  A host report.  The overload treatment should apply to requests
>>>>       for which all of the following conditions are true:
>>>>       a) The Destination-Host AVP is present in the request and its value
>>>>          matches the value of the Origin-Host AVP of the received message
>>>>          that contained the OC-OLR AVP.
>>>>       b) The value of the Destination-Realm AVP in the request matches the
>>>>          value of the Origin-Realm AVP of the received message
>>>>          that contained the OC-OLR AVP.
>>>>       c) The value of the Application-ID in the Diameter Header of the
>>>>          request matches the value of the Application-ID of the Diameter
>>>>          Header of the received message that contained the OC-OLR AVP.
>>>>
>>>>
>>>>
>>>>    1  A realm report.  The overload treatment should apply to
>>>>       requests for which all of the following conditions are true:
>>>>       a) The Destination-Host AVP is absent in the request.
>>>>       b) The value of the Destination-Realm AVP in the request matches the
>>>>          value of the Origin-Realm AVP of the received message
>>>>          that contained the OC-OLR AVP.
>>>>       c) The value of the Application-ID in the Diameter Header of the
>>>>          request matches the value of the Application-ID of the Diameter
>>>>          Header of the received message that contained the OC-OLR AVP.
>>>>
>>>>
>>>> _____________________________________________________________________
>>>> _ ___________________________________________________
>>>>
>>>> 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.
>>>> _______________________________________________
>>>> 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
>>>
>>> ______________________________________________________________________
>>> ___________________________________________________
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> 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
>>>
>>> ______________________________________________________________________
>>> ___________________________________________________
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> 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
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> 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
>


--------------060206090203070809020201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ok, Ok, no reason to gang
      up on me. :-)

      

      What we have here is an overload report to reduce realm routed
      requests.  I think we should be explicit in the draft to define it
      as such.

      

      I am still concerned that we do not have a way to indicate
      overload of the realm as a whole.  I'll enter a new trouble ticket
      to capture this issue.

      

      Steve

      

    
    
On 2/11/14 5:11 PM, Jouni Korhonen
      wrote:

    

    

      
So are we converging to an agreement here? I could join the
camp of U/MC/N/L/J..

- Jouni

On Feb 11, 2014, at 11:52 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:



      

        
Dear all

I come back a bit late on this long debate to confirm my position that I share with  Ulrich MCruz Nirav and I think now Lionel and that I again summarize here in these two statements : 
- Host OLR based control applies to requests where Destination Host is known
- Realm OLR based control applies to requests where Destination Host is not known (only the Destination realm).



        

          
From History, we have started by defining the Host report so to control the traffic towards each server,(our main goal), but we observed a difficulty when the reacting node does not know  the host to which a  request is sent and for this  we introduced the realm report. Annex B1 example in the draft is the use case well illustrating  this approach and  which corresponds to the above statements.


        

        
Another point which was mentioned, is, for  the reacting node, to keep the throttling based on realm report independent of the throttling based on the host report, this is naturally achieved with the two above statements as we distinguish requests having a destination host from those having not. But if we can apply both reports to the same request, then we need additional rules eg  which report prevails; in the discussion there were also divergence on this point, but we can imagine other rules eg the report that has the highest reduction value prevails, why not in some cases, so a trend to overcomplexify. 

For me the two above statements avoid overlapping between the two reports  and are simple to apply, so I keep my preference for these two statements.

Best regards

JJacques   


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
Envoyé : mardi 11 février 2014 16:31
À : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

So now I understand Ulrich, Maria Cruz and JJ comments.

"My" proposal would force the servers in the realm to always send an OLR just to say "I'm not overloaded" i.e. with the value 0. That is anyway a possibility.
But if we want to avoid that, Realm type must only apply to message without destination host.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com Envoyé : mardi 11 février 2014 16:25 À : Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Maria Cruz,

Actually I've missed this point. Sorry.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : mardi 11 février 2014 16:08 À : dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On 2/11/14 8:19 AM, Maria Cruz Bartolome wrote:


        

          
Lionel,

About first case:

- If the reacting node has received an indication only for Realm 
traffic Reduction, apply Realm reduction is for any message, with 
Destination-Realm and with/without Destination-Host

I do not agree on this, since if Destination Host is used, there is no reason to throttle messages if this Host has not provided any OLR.


        

        
SRD> There is if the reacting node has received an overload report
requesting a traffic reduction on the realm.  The server/host does not have visibility of the entire realm. 


        

          
This is in line with the example used from the beginning:
---------
..we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
What is wrong with letting the client
-not throttle host-type requests to S1, -throttle host type request to 
S2 with 50% and -throttle realm type requests wit 25%?
------------

And I think this is what JJ commented:
[JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.

In my opinion, reducing traffic to S1 is wrong.


        

        
SRD> It isn't reducing traffic to S1.  It is reducing traffic to the realm.


        

          
Regards
/MCruz

-----Original Message-----
From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: martes, 11 de febrero de 2014 11:57
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi maria-cruz,

JJ agreed on the following approach:

- If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.

- If the reacting node has received an indication only for host traffic reduction, apply host reduction for messages containing a Destination-Host. No reduction for messages with only a Destination-Realm.
[JJ] OK

- If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).
[JJ] OK, Host reduction prevails

In other words, as said earlier, the Host reduction prevails over realm reduction when the overloaded host is inside an overloaded realm and the reacting has received info about both type of overload.

What is the issue with this approach?

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz 
Bartolome Envoyé : mardi 11 février 2014 11:49 À : dime@ietf.org Objet 
: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hello,
I agree with JJ:

- If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.

[MCruz] And... if the request is sent to a Destination-Host, if there is any applicable OLR, it will be received immediately in the answer, and will be applicable from next request on.
Simple and robust in my opinion. Then, we do not need to evaluate whether we have OLR for Realm and/or Host, and even check their validity & applicability.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, 
JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 15:00
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi Lionel

Please see in line

-----Message d'origine-----
De : lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoyé 
: lundi 10 février 2014 14:25 À : TROTTIN, JEAN-JACQUES 
(JEAN-JACQUES); dime@ietf.org Objet : RE: [Dime] [dime] #34: Semantics 
of OC-Report-Type AVP

I disagree and my proposal was somehow misunderstood.

I don't see the issue to have the following sequence:

- If the reacting node has received an indication only for Realm traffic Reduction, apply Realm reduction is for any message, with Destination-Realm and with/without Destination-Host [JJ] there may be a misunderstanding somewhere, so good to try to clarify; coming back to Ulrich example, Host S1 is not overloaded, so reacting node has not received Host reduction OLR for S1. But as there  is a realm reduction, reacting node will reduce traffic with destination Host S1.

- If the reacting node has received an indication only for host traffic reduction, apply host reduction for messages containing a Destination-Host. No reduction for messages with only a Destination-Realm.
[JJ] OK

- If the reacting node has received both an indication for host traffic and for realm traffic reduction, only the realm reduction will apply for messages with only the Destination-Realm AVP and only the host reduction will apply for messages with the Destination-Host AVP (and the Destination-Realm AVP).
[JJ] OK, Host reduction prevails

In other words, as said earlier, the Host reduction prevails over realm reduction when the overloaded host is inside an overloaded realm and the reacting has received info about both type of overload.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, 
JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 10 février 2014 13:56 À : 
dime@ietf.org Objet : Re: [Dime] [dime] #34: Semantics of 
OC-Report-Type AVP

Dear  all

I share Ulrich and MCruz views,
- Host OLR based control applies to requests where Destination Host is 
known
- Realm OLR based control applies to requests where Destination Host is not known (only the Destination realm).

I think it is simple, otherwise as MCruz indicated it complicates; e.g about the Ulrich's example where the Host S1 is not overloaded but the realm is overloaded. the client will not receive Host OLR reports from host S1 (so no explicit traffic reduction requested by S1), but according to Lionel comment, I understand  client will have to throttle the requests sent to S1 according to realm OLR, so how to avoid this.

JJacques

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz 
Bartolome Envoyé : vendredi 7 février 2014 17:15 À : dime@ietf.org 
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Dear all,

I am in favor of the proposal made by Ulrich in the sequence diagram he provided.
----
As a summary:
Consequently the reacting node will receive realm type OLRs from the agent and host type OLRs from the servers.
The received realm type OLR will be relevant for the reacting node when sending/throttling realm type requests; the received host type OLR will be relevant for the reacting node       when sending/throttling host type requests.
-----

It may occur though, that a Client has only received Realm type OLR, and then it has to send a request to one specific host, then the Client will not apply any restriction, but as soon as the response is received back, Client will update Host type OLR.  Same will apply when only Host type OLR has been received by Client.
The alternative will be to always send back from an Agent both Host OLR plus Realm OLR, but I do not think this is necessary and may complicate the solution.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich 
(NSN - DE/Munich)
Sent: viernes, 07 de febrero de 2014 14:13
To: ext Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP



-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
Sent: Friday, February 07, 2014 11:21 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext lionel.morand@orange.com; Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 5, 2014, at 6:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



          

            
I better like Lionel's approach, but even that is not ok in the unlikely extreme case where we have two servers in a realm, S1 is not overloaded at all, S2 is 50% overloaded, and the aggregated realm overload is 25%. Why should a client do a 25% throttling when sending host type requests to the not at all overloaded S1?
What is wrong with letting the client -not throttle host-type 
requests to S1, -throttle host type request to
S2 with 50% and -throttle realm type requests wit 25%?


          

          
Isn't this what Lionel said below?
<Ulrich> no it is not</Ulrich>
I am OK with Lionel's
"wording" here.

- Jouni



          

            


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext 
lionel.morand@orange.com
Sent: Wednesday, February 05, 2014 4:14 PM
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I tend to agree except that I would reverse the logic as for the routing principles: the Destination-host takes precedence when present over Destination-Realm. So the realm abatement is applied in any case except if there is an explicit report for the destination-host.

Lioenl

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan 
Envoyé : mercredi 5 février 2014 15:56 À : dime@ietf.org Objet : Re:
[Dime] [dime] #34: Semantics of OC-Report-Type AVP

It makes more sense to me for a realm report to apply to all requests targeted for that realm, independent the type of request.  This implies that it would apply to requests that also have a Destination-Host specified.

If this is the definition of a realm report then we need to specify the interaction between realm reports and host reports.

I propose that throttling would occur on the realm first and the host second.  If a message targetted for the host is throttled as a result of realm overload then that throttled message would count as part of the reduction needed to address the host overload.  Messages to the host that survive realm abatement would then be candidates for host overload.

Steve

On 2/4/14 11:12 AM, lionel.morand@orange.com wrote:
The case "Realm" as described below raises another question: is it prohibited for a realm to only rely on a global overload report for the whole realm, whatever the nodes inside this realm?
If not, only OLR with the report type "realm" would be received by the reacting node. And the reduction indicated in the OLR will apply always for the realm, whatever the presence of Destination-host AVP in the request... except if an explicit report with the type "Host" as been received for this destination-host.

Does it make sense?

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:55
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #34: Semantics of OC-Report-Type AVP

#34: Semantics of OC-Report-Type AVP

Text in clause 4.6  does not fully explain to which requests 
overload treatment of a given report type applies.
Proposal:

   0  A host report.  The overload treatment should apply to requests
      for which all of the following conditions are true:
      a) The Destination-Host AVP is present in the request and its value
         matches the value of the Origin-Host AVP of the received message
         that contained the OC-OLR AVP.
      b) The value of the Destination-Realm AVP in the request matches the
         value of the Origin-Realm AVP of the received message
         that contained the OC-OLR AVP.
      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.



   1  A realm report.  The overload treatment should apply to
      requests for which all of the following conditions are true:
      a) The Destination-Host AVP is absent in the request.
      b) The value of the Destination-Realm AVP in the request matches the
         value of the Origin-Realm AVP of the received message
         that contained the OC-OLR AVP.
      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.


_____________________________________________________________________
_ ___________________________________________________

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.
_______________________________________________
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

______________________________________________________________________
___________________________________________________

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.

_______________________________________________
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

______________________________________________________________________
___________________________________________________

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.

_______________________________________________
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

_________________________________________________________________________________________________________________________

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.

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

_________________________________________________________________________________________________________________________

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.

_______________________________________________
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



    

    

  


--------------060206090203070809020201--


From srdonovan@usdonovans.com  Thu Feb 13 04:46:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46311A0218 for ; Thu, 13 Feb 2014 04:46:34 -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
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 DcPbFGjL8TjD for ; Thu, 13 Feb 2014 04:46:32 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 40DA71A0217 for ; Thu, 13 Feb 2014 04:46:32 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53730 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvgO-0006En-9O for dime@ietf.org; Thu, 13 Feb 2014 04:46:31 -0800
Message-ID: <52FCBEA4.3020000@usdonovans.com>
Date: Thu, 13 Feb 2014 06:46:28 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060301000700010408020805"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:46:35 -0000

This is a multi-part message in MIME format.
--------------060301000700010408020805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Jouni,

Which optimization, defining a default value or Lionel's proposal to
make it a required AVP?

Steve

On 2/13/14 6:05 AM, Jouni Korhonen wrote:
> Agree that it is a small optimization, which I put there
> because at the beginning there seemed to be a lot of worry
> on every extra AVP ;-)
>
> I prefer having the AVP optional but with a default value
> just like it is now. We have the same for the reduction
> percentage and the validity time as well.
>
> - Jouni
>
> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:
>
>> Hi Mcruz
>>
>> The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
>> We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
>>
>> Best regards
>>
>> JJacques 
>>
>>
>>
>>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
>> Envoyé : mercredi 12 février 2014 15:46
>> À : dime@ietf.org; maria.cruz.bartolome@ericsson.com
>> Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>
>> Hi Maria Cruz,
>>
>> I'm assuming that you mean "required" instead of "mandatory", right?
>>
>> So instead of:
>>
>>   OC-OLR ::= < AVP Header: TBD2 >
>>              < OC-Sequence-Number >
>>              [ OC-Report-Type ]
>>              [ OC-Reduction-Percentage ]
>>              [ OC-Validity-Duration ]
>>            * [ AVP ]
>>
>> You would prefer:
>>
>>   OC-OLR ::= < AVP Header: TBD2 >
>>              < OC-Sequence-Number >
>>              { OC-Report-Type }
>>              [ OC-Reduction-Percentage ]
>>              [ OC-Validity-Duration ]
>>            * [ AVP ]
>>
>> And I'm fine with this proposal.
>>
>> Cheers,
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoyé : mercredi 12 février 2014 15:26 À : maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>
>> #54: OC-Report-Type as mandatory AVP
>>
>> Now in chapter 4.6:
>>
>>    The default value of the OC-Report-Type AVP is 0 (i.e. the host
>>    report).
>>
>> This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
>>
>> -- 
>> -----------------------------------------------+------------------------
>> -----------------------------------------------+---
>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>     Type:  defect                             |  Bartolomé
>> Priority:  major                              |     Status:  new
>> Component:  draft-docdt-dime-ovli              |  Milestone:
>> Severity:  Active WG Document                 |    Version:  1.0
>>                                               |   Keywords:
>> -----------------------------------------------+------------------------
>> -----------------------------------------------+---
>>
>> Ticket URL: 
>> dime 
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> 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
>


--------------060301000700010408020805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jouni,

      

      Which optimization, defining a default value or Lionel's proposal
      to make it a required AVP?

      

      Steve

      

    
    
On 2/13/14 6:05 AM, Jouni Korhonen
      wrote:

    

    

      
Agree that it is a small optimization, which I put there
because at the beginning there seemed to be a lot of worry
on every extra AVP ;-)

I prefer having the AVP optional but with a default value
just like it is now. We have the same for the reduction
percentage and the validity time as well.

- Jouni

On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:



      

        
Hi Mcruz

The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.

Best regards

JJacques 




-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
Envoyé : mercredi 12 février 2014 15:46
À : dime@ietf.org; maria.cruz.bartolome@ericsson.com
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Maria Cruz,

I'm assuming that you mean "required" instead of "mandatory", right?

So instead of:

  OC-OLR ::= < AVP Header: TBD2 >
             < OC-Sequence-Number >
             [ OC-Report-Type ]
             [ OC-Reduction-Percentage ]
             [ OC-Validity-Duration ]
           * [ AVP ]

You would prefer:

  OC-OLR ::= < AVP Header: TBD2 >
             < OC-Sequence-Number >
             { OC-Report-Type }
             [ OC-Reduction-Percentage ]
             [ OC-Validity-Duration ]
           * [ AVP ]

And I'm fine with this proposal.

Cheers,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoyé : mercredi 12 février 2014 15:26 À : maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] [dime] #54: OC-Report-Type as mandatory AVP

#54: OC-Report-Type as mandatory AVP

Now in chapter 4.6:

   The default value of the OC-Report-Type AVP is 0 (i.e. the host
   report).

This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.

-- 
-----------------------------------------------+------------------------
-----------------------------------------------+---
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
    Type:  defect                             |  Bartolomé
Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
Severity:  Active WG Document                 |    Version:  1.0
                                              |   Keywords:
-----------------------------------------------+------------------------
-----------------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>
dime <http://tools.ietf.org/wg/dime/>

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

_________________________________________________________________________________________________________________________

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.

_______________________________________________
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



    

    

  


--------------060301000700010408020805--


From srdonovan@usdonovans.com  Thu Feb 13 04:54:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28351A0218 for ; Thu, 13 Feb 2014 04:54:43 -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
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 Aaq9mQn6zd0z for ; Thu, 13 Feb 2014 04:54:41 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id B4F2B1A0217 for ; Thu, 13 Feb 2014 04:54:41 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53740 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvoN-0004cn-It for dime@ietf.org; Thu, 13 Feb 2014 04:54:40 -0800
Message-ID: <52FCC094.8030406@usdonovans.com>
Date: Thu, 13 Feb 2014 06:54:44 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097745AF@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097745AF@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------080809030501000708010408"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:54:44 -0000

This is a multi-part message in MIME format.
--------------080809030501000708010408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

+1
On 2/12/14 7:34 AM, Maria Cruz Bartolome wrote:
> Thanks Jouni, I didn't realize.
> One more correction added
>
>> Proposal:
>> Indicates that the reporting node urges the reacting node to reduce 
>> its traffic by a given percentage. For example if the
>> reacting node would send 100 packets to the				<---
>> reporting node, then a reception of OC-Reduction-Percentage value of 
>> 10 would mean that from now on the reacting node MUST only send
>> 90 packets instead of 100. How the reacting node achieves the "true       <---
>> reduction" transactions leading to the sent request messages is up to 
>> the implementation. The reacting node MAY simply drop every 10th 
>> packet from its output queue and let the generic application logic try 
>> to recover from it.
>
> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: miércoles, 12 de febrero de 2014 10:36
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
>
>
> Fine by me.. though you then need to apply the same change to the rest of this paragraph, not only the first one.
>
> Also, please update this additional concern into the issue tracker issue #52.
>
> - Jouni
>
> On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome  wrote:
>
>> Same comment also applies to following paragraph in 5.5.2
>>
>> Now:
>>   0 < value < 100
>>
>>      Indicates that the reporting node urges the reacting node to
>>      reduce its traffic by a given percentage.  For example if the
>>      reacting node has been sending 100 packets per second to the
>>      reporting node, then a reception of OC-Reduction-Percentage value
>>      of 10 would mean that from now on the reacting node MUST only send
>>      90 packets per second.  How the reacting node achieves the "true
>>      reduction" transactions leading to the sent request messages is up
>>      to the implementation.  The reacting node MAY simply drop every
>>      10th packet from its output queue and let the generic application
>>      logic try to recover from it.0 < value < 100
>>
>> Proposal:
>> Indicates that the reporting node urges the reacting node to reduce 
>> its traffic by a given percentage. For example if the
>> reacting node would send 100 packets to the				<---
>> reporting node, then a reception of OC-Reduction-Percentage value of 
>> 10 would mean that from now on the reacting node MUST only send
>> 90 packets per second. How the reacting node achieves the "true 
>> reduction" transactions leading to the sent request messages is up to 
>> the implementation. The reacting node MAY simply drop every 10th 
>> packet from its output queue and let the generic application logic try 
>> to recover from it.
>>
>>
>> We should not specify a rates for the simple loss algorithm. It's up to the implementation how to reduce, but no time unit has to be specified. 
>>
>>
>>
>> -----Original Message-----
>> From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Sent: miércoles, 12 de febrero de 2014 9:13
>> To: Maria Cruz Bartolome
>> Cc: dime@ietf.org
>> Subject: [dime] #52: Throttling not needed to be based on previous 
>> history
>>
>> #52: Throttling not needed to be based on previous history
>>
>> Now (chapter 4.7):
>>    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
>>    and describes the percentage of the traffic that the sender is
>>    requested to reduce, compared to what it otherwise would have sent.
>>
>> Proposal:
>> The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  and describes the percentage of the traffic that the sender is  requested to reduce, compared to what it otherwise would send.
>>
>>
>> The intention is to avoid that anyone may interpret reacting node is  required to consider history of sent information when throttling.
>>
>> --
>> -----------------------------------------------+----------------------
>> -----------------------------------------------+--
>> -----------------------------------------------+---
>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>     Type:  defect                             |  Bartolomé
>> Priority:  major                              |     Status:  new
>> Component:  draft-docdt-dime-ovli              |  Milestone:
>> Severity:  Active WG Document                 |    Version:  1.0
>>                                               |   Keywords:
>> -----------------------------------------------+----------------------
>> -----------------------------------------------+--
>> -----------------------------------------------+---
>>
>> Ticket URL: 
>> 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
>


--------------080809030501000708010408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    
On 2/12/14 7:34 AM, Maria Cruz
      Bartolome wrote:

    

    

      
Thanks Jouni, I didn't realize.
One more correction added



      

        
Proposal:
Indicates that the reporting node urges the reacting node to reduce 
its traffic by a given percentage. For example if the
reacting node would send 100 packets to the				<---
reporting node, then a reception of OC-Reduction-Percentage value of 
10 would mean that from now on the reacting node MUST only send
90 packets instead of 100. How the reacting node achieves the "true       <---
reduction" transactions leading to the sent request messages is up to 
the implementation. The reacting node MAY simply drop every 10th 
packet from its output queue and let the generic application logic try 
to recover from it.


      

      

-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: miércoles, 12 de febrero de 2014 10:36
To: Maria Cruz Bartolome
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history


Fine by me.. though you then need to apply the same change to the rest of this paragraph, not only the first one.

Also, please update this additional concern into the issue tracker issue #52.

- Jouni

On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:



      

        
Same comment also applies to following paragraph in 5.5.2

Now:
  0 < value < 100

     Indicates that the reporting node urges the reacting node to
     reduce its traffic by a given percentage.  For example if the
     reacting node has been sending 100 packets per second to the
     reporting node, then a reception of OC-Reduction-Percentage value
     of 10 would mean that from now on the reacting node MUST only send
     90 packets per second.  How the reacting node achieves the "true
     reduction" transactions leading to the sent request messages is up
     to the implementation.  The reacting node MAY simply drop every
     10th packet from its output queue and let the generic application
     logic try to recover from it.0 < value < 100

Proposal:
Indicates that the reporting node urges the reacting node to reduce 
its traffic by a given percentage. For example if the
reacting node would send 100 packets to the				<---
reporting node, then a reception of OC-Reduction-Percentage value of 
10 would mean that from now on the reacting node MUST only send
90 packets per second. How the reacting node achieves the "true 
reduction" transactions leading to the sent request messages is up to 
the implementation. The reacting node MAY simply drop every 10th 
packet from its output queue and let the generic application logic try 
to recover from it.


We should not specify a rates for the simple loss algorithm. It's up to the implementation how to reduce, but no time unit has to be specified. 



-----Original Message-----
From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Sent: miércoles, 12 de febrero de 2014 9:13
To: Maria Cruz Bartolome
Cc: dime@ietf.org
Subject: [dime] #52: Throttling not needed to be based on previous 
history

#52: Throttling not needed to be based on previous history

Now (chapter 4.7):
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
   and describes the percentage of the traffic that the sender is
   requested to reduce, compared to what it otherwise would have sent.

Proposal:
The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  and describes the percentage of the traffic that the sender is  requested to reduce, compared to what it otherwise would send.


The intention is to avoid that anyone may interpret reacting node is  required to consider history of sent information when throttling.

--
-----------------------------------------------+----------------------
-----------------------------------------------+--
-----------------------------------------------+---
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
    Type:  defect                             |  Bartolomé
Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
Severity:  Active WG Document                 |    Version:  1.0
                                              |   Keywords:
-----------------------------------------------+----------------------
-----------------------------------------------+--
-----------------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/52>
dime <http://tools.ietf.org/wg/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



    

    

  


--------------080809030501000708010408--


From srdonovan@usdonovans.com  Thu Feb 13 05:01:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B871A022B for ; Thu, 13 Feb 2014 05:01:06 -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
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 ZwCO1nXQjfEX for ; Thu, 13 Feb 2014 05:01:03 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id C80751A0229 for ; Thu, 13 Feb 2014 05:01:03 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53747 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDvuU-0001xv-S8 for dime@ietf.org; Thu, 13 Feb 2014 05:01:02 -0800
Message-ID: <52FCC20F.5000900@usdonovans.com>
Date: Thu, 13 Feb 2014 07:01:03 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------050202000006050609000900"
X-OutGoing-Spam-Status: No, score=-2.9
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
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 13:01:06 -0000

This is a multi-part message in MIME format.
--------------050202000006050609000900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

This could be addressed by adding the requirement that an
OC-Supported-Features AVP AVP that is inserted by an agent be marked as
such.

Steve

On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> The reacting node (when receiving OC-Supported-Features AVP in an answer) knows that the corresponding request took a path towards the server on which there is a reporting node (which supports DOIC). It does not know whether this reporting node is the server or an agent and it does not know whether subsequent requests will take the same path or a different path on which there may be no reporting node. 
> Consequently the presence of OC-Supported-Features AVP in an answer does not tell you anything usefull on which to base behaviour for subsequent requests targeted to the same server.
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
> Sent: Wednesday, February 12, 2014 10:56 AM
> To: dime@ietf.org list
> Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
> Ulrich,
> Thanks for your response, see comments please
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
> Sent: miércoles, 12 de febrero de 2014 9:14
> To: Maria Cruz Bartolome; dime@ietf.org list
> Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
> I understand your point but I'm not really convinced.
>
> 1. implicit indications (like answer message with result code TOO_BUSY and without piggybacked OLR or Lack of response) should be taken into account by reacting nodes independent from DOIC-support of the server.
> [MCruz] I agree. But one of the 3GPP requirements is to improve reacting node overload mitigation based on implicit indications (as described by TR), therefore any 3GPP application that will support new "Overload mitigation" feature (or whatever may be the name), shall improve its procedures with this objective. It is expected as well, that this new 3GPP "Overload mitigation" feature makes use of our DOIC, and then it is very beneficial that the reacting node could identify at any moment whether or not the reporting node supports DOIC, since procedures to be implemented could be potentially different.
>
> 2. How would the reacting node know whether the OC-Supported-Features AVP received in an answer indicates the features supported by the server (identified by the origin-host received in the answer) or the features supported by an agent on the path? 
> [MCruz] Reacting node receives reporting node Supported-Features. Regardless the reporting node is either an agent or a server, in case the reacting node needs to treat "implicit indications" (like TOO_BUSY), expected reaction may depend on whether or not reporting node supports DOIC. This information is very beneficial to determine the most appropriate reaction.
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
> Sent: Tuesday, February 11, 2014 9:21 PM
> To: dime@ietf.org list
> Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
> I agree with Ben here.
> The mechanism is meant to work in mixed scenarios and it is relevant for the reacting node to know whether or not a server supports DOIC, since the reacting node should be able to mitigate this server overload as well when this server does not support DOIC.
>
> In fact, we have already included this as a requirement  in our 3GPP TR:
>
> 6.3.3	Implicit Overload Indication
> 6.3.3.1	Introduction
> IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of implicit indications and the inadequacy of this approach for large, diverse networks.
> However, a Diameter client may receive some overload indications as defined in Diameter base specification IETF RFC 6733 [2] and then it is recommended that the client uses them to mitigate overload situation. This may happen even if involved server and client support the new CN Overload mechanism under definition, but client handling of such indications is even more important when the new mechanism is not supported by either client or server.
> At least the following indications may be considered:
> -	DIAMETER_TOO_BUSY protocol error:
> Diameter base specification IETF RFC 6733 [2] does not suggest that the receipt of a protocol error DIAMETER_TOO_BUSY response should affect future Diameter messages in any way, then it may be relevant for some applications to define the behavior that best mitigate the overload situation, taking into account application specifics, operator deployments.... For example, MME may implement a mitigation procedure based on the rate of received DIAMETER_TOO_BUSY protocol error from HSS.
> -	Lack of response:
> In case of overload the server may react dropping the requests without any Diameter error message being returned, what may imply retransmissions in the client side, negatively impacting overload. Therefore, for each application, it should be analyzed how to mitigate overload in this situation. For example, the client may consider avoiding retransmissions when a number of messages have not been answered.
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: martes, 11 de febrero de 2014 16:55
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org list
> Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>
>
> On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>
>> 1) I want the reacting node to be able to learn if a (potentially) 
>> reporting node supports DOIC, even when that node is not in overload.
>> I don't want to specify any particular behavior for that knowledge, 
>> but I suspect implementations may want to treat DOIC compliant servers 
>> in some way differently than they do non-DOIC servers. For example, I 
>> might have a configured rate limit for non-DOIC peers, but use a 
>> higher (or no) limit for peers that are known to support DOIC (and can 
>> thus speak for themselves.) sounds like a new requirement; 
>> where does it come from? I would have thought that there is no need to 
>> distinguish between
>> a) DOIC not supported and therefore no traffic reduction requested, 
>> and
>> b) DOIC supported, but not in overload and therefore no traffic 
>> reduction requested
>>
> At one point, I thought we agreed as a group that a reacting node should be able to identify if a (potential) reporting node supported the mechanism. But in any case, we have a requirement that the mechanism must work in a mixed environment, where some nodes support it and some don't. It's much _easier_ to meet that requirement if we can tell what nodes support it and what don't. 
>
> In general, a reacting node can assume that a server that supports DOIC, but hasn't reported overload is not overloaded. It can make no such assumption about a server that doesn't support DOIC. If it does not know the difference between a non-overloaded server and a non-supporting server, it must assume all such servers are non-supporting. It ends up simply knowing that some servers _are_ overloaded, and some other servers _might_be_ overloaded.
>
> _______________________________________________
> 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
>


--------------050202000006050609000900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    This could be addressed
      by adding the requirement that an OC-Supported-Features AVP AVP
      that is inserted by an agent be marked as such.

      

      Steve

    

    
On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
The reacting node (when receiving OC-Supported-Features AVP in an answer) knows that the corresponding request took a path towards the server on which there is a reporting node (which supports DOIC). It does not know whether this reporting node is the server or an agent and it does not know whether subsequent requests will take the same path or a different path on which there may be no reporting node. 
Consequently the presence of OC-Supported-Features AVP in an answer does not tell you anything usefull on which to base behaviour for subsequent requests targeted to the same server.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 10:56 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: miércoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and without piggybacked OLR or Lack of response) should be taken into account by reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting node overload mitigation based on implicit indications (as described by TR), therefore any 3GPP application that will support new "Overload mitigation" feature (or whatever may be the name), shall improve its procedures with this objective. It is expected as well, that this new 3GPP "Overload mitigation" feature makes use of our DOIC, and then it is very beneficial that the reacting node could identify at any moment whether or not the reporting node supports DOIC, since procedures to be implemented could be potentially different.

2. How would the reacting node know whether the OC-Supported-Features AVP received in an answer indicates the features supported by the server (identified by the origin-host received in the answer) or the features supported by an agent on the path? 
[MCruz] Reacting node receives reporting node Supported-Features. Regardless the reporting node is either an agent or a server, in case the reacting node needs to treat "implicit indications" (like TOO_BUSY), expected reaction may depend on whether or not reporting node supports DOIC. This information is very beneficial to determine the most appropriate reaction.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for the reacting node to know whether or not a server supports DOIC, since the reacting node should be able to mitigate this server overload as well when this server does not support DOIC.

In fact, we have already included this as a requirement  in our 3GPP TR:

6.3.3	Implicit Overload Indication
6.3.3.1	Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of implicit indications and the inadequacy of this approach for large, diverse networks.
However, a Diameter client may receive some overload indications as defined in Diameter base specification IETF RFC 6733 [2] and then it is recommended that the client uses them to mitigate overload situation. This may happen even if involved server and client support the new CN Overload mechanism under definition, but client handling of such indications is even more important when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
-	DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the receipt of a protocol error DIAMETER_TOO_BUSY response should affect future Diameter messages in any way, then it may be relevant for some applications to define the behavior that best mitigate the overload situation, taking into account application specifics, operator deployments.... For example, MME may implement a mitigation procedure based on the rate of received DIAMETER_TOO_BUSY protocol error from HSS.
-	Lack of response:
In case of overload the server may react dropping the requests without any Diameter error message being returned, what may imply retransmissions in the client side, negatively impacting overload. Therefore, for each application, it should be analyzed how to mitigate overload in this situation. For example, the client may consider avoiding retransmissions when a number of messages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:



      

        
1) I want the reacting node to be able to learn if a (potentially) 
reporting node supports DOIC, even when that node is not in overload.
I don't want to specify any particular behavior for that knowledge, 
but I suspect implementations may want to treat DOIC compliant servers 
in some way differently than they do non-DOIC servers. For example, I 
might have a configured rate limit for non-DOIC peers, but use a 
higher (or no) limit for peers that are known to support DOIC (and can 
thus speak for themselves.) <Ulrich>sounds like a new requirement; 
where does it come from? I would have thought that there is no need to 
distinguish between
a) DOIC not supported and therefore no traffic reduction requested, 
and
b) DOIC supported, but not in overload and therefore no traffic 
reduction requested</Ulrich>



      

      
At one point, I thought we agreed as a group that a reacting node should be able to identify if a (potential) reporting node supported the mechanism. But in any case, we have a requirement that the mechanism must work in a mixed environment, where some nodes support it and some don't. It's much _easier_ to meet that requirement if we can tell what nodes support it and what don't. 

In general, a reacting node can assume that a server that supports DOIC, but hasn't reported overload is not overloaded. It can make no such assumption about a server that doesn't support DOIC. If it does not know the difference between a non-overloaded server and a non-supporting server, it must assume all such servers are non-supporting. It ends up simply knowing that some servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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



    

    

  


--------------050202000006050609000900--


From nsalot@cisco.com  Thu Feb 13 04:58:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9D71A0225 for ; Thu, 13 Feb 2014 04:58:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CK0sKGP5I2C for ; Thu, 13 Feb 2014 04:58:30 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 771701A022A for ; Thu, 13 Feb 2014 04:58:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=187122; q=dns/txt; s=iport; t=1392296306; x=1393505906; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=VLU0pVTZrnALUoIF14ouXvaA1/dLlBo47Cgq9CJyUGM=; b=jm03u+NdgmSqedGIgki1wCJa7M5bA2iY9Oz0kQfiB6j/Dv+P4rZqsRL6 F67FRsUGaZ5RSiGdLydzgSaeMgBi2LNjyDQ0xGWxZc+Az6qqCUuxhlLNC Fnh/cJ+6MWMeOMFRgRj6Ap9CVCvu+dDi/dned5NEswW4lqMh56oKTjRXO I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApkFADnA/FKtJV2c/2dsb2JhbABZgkJEOFeDALxLGH4WdIIlAQEBBAEBAQsMAQgKOAkXBAIBCBEEAQELCwsBAgQDAgICJQsUCQgCBAESCBOHag2mB6InEwSOFwoHAR8WFwoBBgSCZTWBFASUAUKORodGgW+BPoFoBwIXIg
X-IronPort-AV: E=Sophos;i="4.95,838,1384300800";  d="scan'208,217";a="303830196"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 13 Feb 2014 12:58:24 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1DCwOhA030431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 12:58:24 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 06:58:24 -0600
From: "Nirav Salot (nsalot)" 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//PffggAHqb4CAAGRIIP//nb+AgAABVwCAADj8AIAAGrQAgAE4QwCAAX5BAIAAJZDg
Date: Thu, 13 Feb 2014 12:58:23 +0000
Message-ID: 
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.45.36]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6D626xmbrcdx10ciscoc_"
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 13 Feb 2014 05:05:19 -0800
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 12:58:41 -0000

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

TWFyaWEtQ3J1eiwNCg0KUmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5IHNpbXBsZSBtZWNoYW5p
c20g4oCTIGFzIHBvaW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8gY29uY2x1ZGUgdGhhdCByZXBv
cnQgaGFzIHJlYWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4gYWxsIHRoZSBpbnRyYS1zZXNz
aW9uIG1lc3NhZ2VzIG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3ZlcmxvYWQgcmVwb3J0LCBp
ZiB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFpbnMgdGhlIG92ZXJsb2Fk
IHJlcG9ydC4NCg0KU28geW91ciBub3RlIHJlZ2FyZGluZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8g
dGFrZSBpbnRvIGFjY291bnQgdGhlIG5ldHdvcmsgZGVwbG95bWVudCBldGMuIGlzIG5vdCAxMDAl
IGNvcnJlY3QuDQpMZXQgbWUgc2ltcGxpZnksIGhvcGluZyBpdCB3aWxsIHNhdGlzZnkgeW91ciBj
b25jZXJuLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3Zl
cmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQg
dGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5v
ZGUuDQoNCk5vdGUg4oCTIEluIHNvbWUgY2FzZXMsIGUuZy4gd2hlbiB0aGVyZSBhcmUgb25lIG9y
IG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rp
bmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBu
b2RlcywgdGhlIHJlcG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhh
dCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9ydC4NClJlZ2FyZHMsDQpO
aXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMs
IDIwMTQgMjozMSBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpEZWFyIGFsbCwNCg0KSSB0
aGluayB0aGVuIHdlIGFncmVlIG9uIHRoZSBwcm9wb3NlZCB0ZXh0Og0KDQpBIHJlcG9ydGluZyBu
b2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJs
b2FkIHJlcG9ydHMuDQoNCkl0IGlzIHJlY29tbWVuZGVkIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBp
bmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIHJl
YWN0aW5nIG5vZGVzLg0KDQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1
ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVh
Y3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4gIFRoZSBvdmVybG9hZCByZXBv
cnQgd2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qg
c3VwcG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQg
YW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVl
IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2Fk
IHJlcG9ydC4NCg0KQnV0IHN0aWxsIHRoZXJlIGFyZSBzb21lIGRpc2NyZXBhbmNpZXMgYWJvdXQg
dGhlIG5vdGUuDQpNeSBwcm9wb3NhbCBpcyB0byBrZWVwIGl0IGp1c3QgYXMgYW4gaW5kaWNhdGlv
biBvZiBwb3RlbnRpYWwgKG1heWJlIG5vdCBhbGwpIHNpdHVhdGlvbnMgdGhhdCBzaG91bGQgYmUg
dGFrZW4gaW50byBhY2NvdW50IGlmIGV2ZXIgYW55IGltcGxlbWVudGF0aW9uIG1heSBjb25zaWRl
ciB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiB0aGF0IGEgcmVwb3J0aW5nIG5v
ZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMuDQpCZWlu
ZyBhIHJlY29tbWVuZGF0aW9uIGFuZCBub3QgYSBtdXN0LCBhdCBsZWFzdCBJIHRoaW5rIHdlIG5l
ZWQgdG8gaW5kaWNhdGUgd2hhdCBtYXkgaW1wbHkgdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVjb21t
ZW5kYXRpb24uDQpUaGVuIG15IHByb3Bvc2FsIGlzIHRoZSBmb2xsb3dpbmcsIHRoYXQgaW5jbHVk
ZXMgYSBtb2RpZmljYXRpb24gdG8gbGFzdCBzZW50ZW5jZSBhYm92ZToNCg0KQSByZXBvcnRpbmcg
bm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0
aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlz
IGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLg0KDQpOb3RlIOKAk3RoZSByZXBv
cnRpbmcgbm9kZSBtYXkgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudCBuZXR3b3JrIGRlcGxveW1l
bnQgYW5kIHBvdGVudGlhbCBlcnJvcnMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBndWFyYW50ZWUg
dGhhdCBzZW50IG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUs
IGUuZy4gdGhlcmUgbWF5IGJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0
d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBi
ZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXPigKYNCg0KDQpGcm9tOiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVFJPVFRJTiwgSkVBTi1KQUNRVUVT
IChKRUFOLUpBQ1FVRVMpDQpTZW50OiBtacOpcmNvbGVzLCAxMiBkZSBmZWJyZXJvIGRlIDIwMTQg
MTE6MTMNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDog
UmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkhp
DQoNCk9uIHRoaXMgdG9waWMsIG15IHZpZXcgaXMgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBzaGFs
bCAgcmVjZWl2ZSDigJxlbm91Z2jigJ0gT0xScyBwZXIgcGVyaW9kIG9mIHRpbWUgdG8gZW5zdXJl
IHRoZSBlZmZpY2llbmN5IG9mIHRoZSB0cmFmZmljICByZWR1Y3Rpb24gbWVjaGFuaXNtIC4gQSB3
YXkgdG8gYWNoaWV2ZSAgdGhlIOKAnGVub3VnaOKAnSBpcyB0byBoYXZlIGFuIE9MUiBpbiBhbGwg
IGFuc3dlciAgbWVzc2FnZXMgYXMgcHJvcG9zZWQgYW5kIHRoaXMgY2FuIHRoZSByZWNvbW1lbmRl
ZCB3YXkuIE5vdyBhcyBOaXJhdiBzYWlkLCB0aGVyZSBtYXkgYmUgcHJvdG9jb2wgZGVzaWduIHRo
YXQgd2lsbCBiZWhhdmUgZGlmZmVyZW50bHkgYW5kIHNlbmQg4oCcZW5vdWdo4oCdIE9MUnMgIGJ1
dCBub3QgaW4gYWxsIG1lc3NhZ2VzLg0KDQpBcyBhbHNvIE5pcmF2IG5vdGVkLCAgSSBkbyBub3Qg
d2VsbCBzZWUgdGhlIG5lZWQgdG8gd3JpdGUgYWRkaXRpb25hbCBub3RlcyBhcyBtYW55IHNpdHVh
dGlvbnMgY2FuIG9jY3VyIGFuZCAgYXJlIG5vdCBsaW1pdGVkIHRvIHRoZSBleGFtcGxlIG9mIHRo
ZSByZWFjdGluZyAgbm9kZSAgZGlzY2FyZGluZyBPTFJzLg0KDQpCZXN0IHJlZ2FyZHMNCg0KSkph
Y3F1ZXMNCg0KDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUg
bGEgcGFydCBkZSBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbT4NCkVudm95w6kgOiBtYXJkaSAxMSBmw6l2cmllciAyMDE0IDE2OjM1DQrDgCA6
IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcNCg0KQXQgbGVhc3QsIGl0IGlzIGNvcnJlY3QhIOKYug0KDQpEZSA6IERpTUUgW21haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xv
bWUNCkVudm95w6kgOiBtYXJkaSAxMSBmw6l2cmllciAyMDE0IDE1OjAwDQrDgCA6IGRpbWVAaWV0
Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpMaW9uZWwsIE5pcmF2LCBhbGwsDQoN
Ck1heWJlIHRoZSBub3RlIGNvdWxkIGJlIG1vZGlmaWVkOg0KDQpOb3RlIOKAk3RoZSByZWFjdGlu
ZyBub2RlIGNvdWxkIGJlIGFueSBhZ2VudCBpbiB0aGUgcGF0aCwgYW5kIHRoYXQgaW4gc29tZSBl
cnJvciBzaXR1YXRpb25zIG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFj
dGluZyBub2Rlcy4NCg0KSSBhZGRlZCB0aGUgY2FzZSBPTFIgY291bGQgYmUgZGlzY2FyZGVkIGJ5
IHJlYWN0aW5nIG5vZGVzLCBzaW5jZSBpdCBoaWdobGlnaHRzIGEgc2l0dWF0aW9uIHdoZXJlIHRo
ZSBzZXJ2ZXIgd2lsbCBub3Qga25vdyB3aGV0aGVyIG9yIG5vdCBhIHZhbGlkIE9MUiBpcyByZWNl
aXZlZCBieSByZWFjdGluZyBub2RlLg0KDQpCZXN0IHJlZ2FyZHMNCi9NQ3J1eg0KDQoNCkZyb206
IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PiBbbWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbV0NClNlbnQ6IG1hcnRlcywgMTEgZGUg
ZmVicmVybyBkZSAyMDE0IDExOjM2DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0
Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQXQgbGVhc3QsIGl0IGlzIG5vdCAi
dGhlIG9ubHkgc3VyZSB3YXkiLg0KRm9yIGluc3RhbmNlLCBzdWJzZXF1ZW50IG1lc3NhZ2VzIHBh
cnQgb2YgdGhlIHNhbWUgc2Vzc2lvbiAob3IgcHNldWRvLXNlc3Npb24pIGNvdWxkIGFsc28gYmUg
dXNlZCBhcyBpbmRpY2F0aW9uIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdGhhdCB0aGUgT0xSIGhh
cyBiZWVuIHJlY2VpdmVkIGJ5IHRoZSByZWFjdGluZyBub2RlIChiZXNpZGVzIHRoZSByZWNlcHRp
b24gb2YgdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBpbiB0aGUgcmVxdWVzdCkuDQpJdCBpcyB3
aHkgSSB3YXMgc2F5aW5nIHRoYXQgdGhpcyBjYW4gYmUgZml4ZWQgcGVyIGFwcGxpY2F0aW9uL3N5
c3RlbS4NCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
Z10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KRW52b3nDqSA6IG1hcmRpIDEx
IGbDqXZyaWVyIDIwMTQgMTE6MzENCsOAIDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRm
Lm9yZz4NCk9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCkZpbmUgTmlyYXYsIEkgYWdyZWUgdGhpcyBpcyBpbXBsZW1lbnRhdGlvbiBz
cGVjaWZpYy4NCk15IGludGVudGlvbiBpcyB0aGF0IGFueSByZWFkZXIgcmVhbGl6ZXMgd2hhdCB0
aGlzIGtub3dsZWRnZSBpbiB0aGUgc2VydmVyIGltcGxpZXMgd2hlbiB3ZSB0YWxrIGFib3V0IGFn
ZW50cyBpbiB0aGUgcGF0aC4gVGhpcyBpcyB3aHkgSSB0aGluayB0aGlzIG5vdGUgaXMgaGVscGZ1
bC4NCg0KUmVnYXJkcw0KL01DcnV6DQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWls
dG86bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0
IDExOjI2DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRp
bWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KSSBkbyBub3QgYWdyZWUgcmVnYXJkaW5nIHRoZSBjb21wbGV4
aXR5IHNpbmNlIGl0IGlzIGhpZ2hseSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCkxldHMgbm90
IG1ha2UgYW55IGFzc3VtcHRpb24gaW4gdGhlIHByb3RvY29sIGRlc2lnbi4NCg0KUmVnYXJkcywN
Ck5pcmF2Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEx
LCAyMDE0IDM6NTQgUE0NClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0K
U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCkhlbGxvLA0KDQpJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBoaWdobGlnaHQgY29t
cGxleGl0eSBmb3IgdGhlIHNlcnZlciB0byAg4oCcZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC7igJ0NCkkgdGhp
bmsgdGhpcyBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VudGVuY2UgYWRkZWQgYnkgU3RldmUuDQoN
CkNoZWVycw0KL01DcnV6DQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBOaXJhdiBTYWxvdCAobnNhbG90KQ0KU2VudDogbWFydGVzLCAxMSBk
ZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjANClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5v
cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBhbSBhbHNvIGZpbmUgd2l0aCBTdGV2
ZSdzIHByb3Bvc2VkIHdvcmRpbmcgdG8gcmVjb21tZW5kIHRoZSBpbmNsdXNpb24gb2YgT0xSIGJ1
dCB0byBub3QgbWFuZGF0ZSBpdC4NCg0KSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgZm9sbG93aW5n
IHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIGFkZCBpdC4NCk5vdGUgLSB0
aGUgb25seSBzdXJlIHdheSwgd2l0aG91dCBwcm9wcmlldGFyeSBtZWNoYW5pc21zLCB0byBrbm93
IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBvcnQgaXMg
d2hlbiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIGNsaWVudCBhbmQgdGhlcmUgaXMgbm8gYWdlbnQg
YmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUuDQoNCkkgcHJlZmVyIHRv
IHJlbW92ZSBpdCBzaW5jZSBJIGRvIG5vdCBzZWUgYXMgdmFsdWUgYWRkaXRpb24uDQoNClJlZ2Fy
ZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFu
ZEBvcmFuZ2UuY29tPg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAxMDoxMyBQTQ0K
VG86IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpT
dWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcNCg0KSSdtIGZpbmUgd2l0aCBhIHJlY29tbWVuZGF0aW9uLg0KDQpCdXQgSSBoYXZlIGEgZ2Vu
ZXJhbCBjb21tZW50OiB3aGVuIGEgTUFZIG9yIGV2ZW4gYSBTSE9VTEQgYXBwbHksIGl0IGRvZXMg
bm90IG1lYW4gdGhhdCBpdCBpcyBOT1QgdXAgdG8gdGhlIG5vZGUgdG8gZG8gb3Igbm90IHRvIGRv
IHNvbWV0aGluZy4gSXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIG9ubHkgYW4gaW1wbGVtZW50
YXRpb24gb3B0aW9uLg0KRm9yIGluc3RhbmNlLCBvdmVyIGEgZ2l2ZW4gaW50ZXJmYWNlLCB0aGUg
cmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkgdGhhdCBzb21lIHN0YXRlcyBhcmUgbWFpbnRh
aW5lZCBieSB0aGUgc2VydmVyLiBBbmQgaXQgY291bGQgYmUgZGVjaWRlZCB0byBhZGQgc29tZSBv
dmVybG9hZCByZWxhdGVkIGluZm8gaW4gc3VjaCBzdGF0ZXMuIEZvciBpbnN0YW5jZSBhZ2Fpbiwg
dGhlIG5vZGUgY2FuIHVzZSB0aGlzIHN0YXRlIHRvIGtub3cgaWYgYSByZW1vdGUgbm9kZSBoYXZl
IGJlZW4gbm90aWZpZWQgb3Igbm90IGZvciBpbnN0YW5jZS4gQW5kIGluIHN1Y2ggYSBjYXNlLCB0
aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaW5jbHVkZSBhbiBPTFIgaW4gZWFjaCBtZXNzYWdl
LiBJdCBpcyBqdXN0IGZvciBpbGx1c3RyYXRpb24uIFRoZSBwb2ludCBpcyB0aGF0IHlvdSBtYXkg
aGF2ZSBzb21lIGNhc2VzIGZvciB3aGljaCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtaWdodCBu
b3QgYmUgcmVxdWlyZWQuDQoNCkkgYWdyZWUgdGhhdCBoYXZpbmcgdGhlIE9MUiBpbiBldmVyeSBh
bnN3ZXIgaXMgZmluZeKApiBidXQgaXQgc2hvdWxkIGJlIG5vdCBtYW5kYXRvcnkgaW4gYWxsIGNh
c2VzIEkgdGhpbmsuIFNvIE9LIGZvciBhICJTSE9VTEQiIG9yICJSRUNPTU1FTkRFRCIuDQoNClJl
Z2FyZHMsDQoNCkxpb25lbA0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmddIERlIGxhIHBhcnQgZGUgU3RldmUgRG9ub3Zhbg0KRW52b3nDqSA6IGx1bmRpIDEwIGbDqXZy
aWVyIDIwMTQgMTc6MjENCsOAIDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4N
Ck9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCkkgYWdyZWUgd2l0aCBib3RoIE1hcmlhIENydXogYW5kIE5pcmF2LiA6LSkNCg0KSSBz
dWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNheWluZyB0aGUgcmVjb21tZW5kZWQgYXBwcm9h
Y2ggaXMgdG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFsbCByZXNwb25zZSBtZXNz
YWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5IE1hcmlhIENydXouDQoNCkkgYWxzbyBzdWdn
ZXN0IHRoYXQgd2UgaW5jbHVkZSBOaXJhdidzIHByb3Bvc2FsIHRoYXQgaWYgYSByZXBvcnRpbmcg
bm9kZSBrbm93cyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBv
dmVybG9hZCByZXBvcnQgdGhlbiBpdCBtYXkgY2hvb3NlIHRvIG5vdCBzZW5kIGl0IGFnYWluLiAg
SSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhl
IHJlcG9ydGluZyBub2RlIGtub3dzIGJ1dCB3ZSBzaG91bGQgaW5jbHVkZSB3b3JkaW5nIGFib3V0
IG5ldHdvcmtzIGFyY2hpdGVjdHVyZXMgdGhhdCBtYWtlIGl0IGRpZmZpY3VsdCB0byBrbm93LiAg
VGhlIGNhc2Ugb2YgYWdlbnRzIGFjdGluZyBhcyByZWFjdGluZyBub2RlcyBmb3Igbm9uIHN1cHBv
cnRpbmcgY2xpZW50cyBiZWluZyBvbmUgZXhhbXBsZS4NCg0KV2UgYWxzbyBuZWVkIHRvIG1ha2Ug
c3VyZSB0aGF0IHRoZSByZWNvbW1lbmRlZCBhcHByb2FjaCBpcyBub3QgcHJlY2x1ZGVkIGJ5IE5p
cmF2J3MgcHJvcG9zYWwuDQoNCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSB3b3Jk
aW5nLCB3aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFzb25zIGZv
ciByZWNvbW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBpbmNsdWRl
ZC4NCg0KLS0tLS0NCg0KQSByZXBvcnRpbmcgbm9kZSBNVVNUIGVuc3VyZSB0aGF0IGFsbCByZWFj
dGluZyBub2RlcyByZWNlaXZlIG5ldyBvdmVybG9hZCByZXBvcnRzLg0KDQpJdCBpcyByZWNvbW1l
bmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFs
bCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4NCg0KTm90ZSAtIHRoZSBy
ZXBvcnRpbmcgbm9kZSBtYXkgYWxzbyBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYW5z
d2VyIG1lc3NhZ2VzIHNlbnQgdG8gbm9uIHJlYWN0aW5nIG5vZGVzIGlmIHRoYXQgaXMgbW9yZSBl
ZmZpY2llbnQuICBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEg
RGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy4NCg0KQSByZXBvcnRpbmcg
bm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0
aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVh
ZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuDQoNCk5vdGUgLSB0aGUgb25seSBz
dXJlIHdheSwgd2l0aG91dCBwcm9wcmlldGFyeSBtZWNoYW5pc21zLCB0byBrbm93IHRoYXQgYSBy
ZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBvcnQgaXMgd2hlbiB0aGUg
cmVhY3Rpbmcgbm9kZSBpcyBhIGNsaWVudCBhbmQgdGhlcmUgaXMgbm8gYWdlbnQgYmV0d2VlbiB0
aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUuDQpPbiAyLzEwLzE0IDM6NTIgQU0sIE1h
cmlhIENydXogQmFydG9sb21lIHdyb3RlOg0KDQpIZWxsbyBOaXJhdiwNCg0KDQoNCkFueSBzb2x1
dGlvbiBzaG91bGQgYmFsYW5jZSBkaWZmZXJlbnQgZmFjdG9ycywgZWZmaWNpZW5jeSBjb3VsZCBi
ZSBkaXNjdXNzZWQgZnJvbSBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLCBidXQgZmlyc3Qgd2UgbmVl
ZCB0byBhc3N1cmUgdGhlIG1lY2hhbmlzbSB3ZSBhcmUgZGVmaW5pbmcgaXMgcHJvdmlkaW5nIHZh
bGlkIE9MUiB0byByZWFjdGluZyBub2Rlcy4NCg0KDQoNCllvdXIgcHJvcG9zZWQgdGV4dA0KDQoi
IEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5v
ZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRl
ZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRo
ZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBv
cnRlZC1GZWF0dXJlIEFWUC4iDQoNCg0KDQpJZiB0aGUgcmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBh
Ym91dCB3aGV0aGVyIG9yIG5vdCBvdmVybG9hZCByZXBvcnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJl
YWN0aW5nIG5vZGUsIGFuZCBpdCBkZWNpZGVzIChzaW5jZSBpdCBpcyBhICJtYXkiKSB0byBkbyBu
b3Qgc2VuZCB0aGUgT0xSIGFnYWluLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gbWVjaGFuaXNt
IHdpbGwgbm90IHdvcmsgaW4gY2FzZSBPTFIgd2FzIG5vdCBwcm9wZXJseSByZWNlaXZlZCBieSBj
b3JyZXNwb25kaW5nIHBvdGVudGlhbCByZWFjdGluZyBub2Rlcy4gQW5kIHdlIG5lZWQgdG8gbm90
ZSB0aGF0ICJyZWFjdGluZyBub2RlcyIgY291bGQgYmUgbm90IG9ubHkgdGhlIGNsaWVudCwgYnV0
IEFOWSBhZ2VudCB1c2VkIGZvciByb3V0aW5nIChub3Qgb25seSB3aGVuIHRoZSBhZ2VudCBpcyBw
cm92aWRpbmcgc2VydmljZSB0byBhIFJlYWxtLCBidXQgd2hlbiBpdCBpcyByZWFjdGluZyBvbiBi
ZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpLg0KDQpUaGVuLCBvbiBvbmUgaGFuZCBp
dCBpcyBub3Qgc2ltcGxlIHRvIGtub3cgd2hlbiByZWFjdGluZyBub2RlcyBoYXZlIHZhbGlkIE9M
UiBpbmZvIChhcyBleHBsYWluZWQgYmVsb3cpLCBidXQgaWYgT0xSIGlzIG5vdCBzZW50IGFnYWlu
IChhcyBwZXIgeW91ciBwcm9wb3NlZCAibWF5IikgdGhlbiBvbmUgb3IgbXVsdGlwbGUgcmVhY3Rp
bmcgbm9kZXMgZG8gbm90IGhhdmUgdGhlIHJlcXVpcmVkIE9MUiwgdGhlbiBvdmVybG9hZCBtaXRp
Z2F0aW9uIHdpbGwgbm90IHdvcmsuDQoNCg0KDQpUaGVyZWZvcmUsIGluIG15IG9waW5pb24sIHRo
ZSBzaW1wbGVzdCB3YXkgdG8gcHJvdmlkZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBpcyB0byBwcm92
aWRlIE9MUiBpbiBBTEwgYW5zd2Vycy4NCg0KDQoNCkJlc3QgcmVnYXJkcw0KDQovTUNydXoNCg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fs
b3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NCg0KU2VudDogbHVuZXMsIDEwIGRlIGZlYnJl
cm8gZGUgMjAxNCAxMDo0Mg0KDQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5v
cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KQnV0IE1hcmlhLUNydXosDQoN
Cg0KDQpIb3cgY2FuIHdlIHNheSB0aGF0ICJpbmNsdWRpbmcgdGhlIE9MUiBpbiBhbGwgdGhlIGFu
c3dlciBtZXNzYWdlcyBpcyBzaW1wbGUgYW5kIGVmZmljaWVudD8iDQoNCkl0IGlzIHNpbXBsZSBm
b3Igc3VyZSBidXQgbm90IGVmZmljaWVudC4NCg0KDQoNCkEgc2xpZ2h0bHkgZGlmZmVyZW50IHdv
cmRpbmcgZnJvbSB3aGF0IEkgcHJvcG9zZWQgZWFybGllciBpcywgV2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgaGFzIGEgbmV3IG92ZXJsb2FkIHJlcG9ydCB0aGF0IG5lZWRzIHRvIGJlIHByb3ZpZGVk
IHRvIGEgcmVhY3Rpbmcgbm9kZSAoYnkgdXBkYXRpbmcgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3Zl
cmxvYWQgcmVwb3J0IG9yIGJ5IHByb3ZpZGluZyB0aGUgb3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUg
Zmlyc3QgdGltZSksIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhl
IHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhl
IGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNl
cywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJs
b2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUg
cmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRo
ZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoNCg0KUmVn
YXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9t
OiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEg
Q3J1eiBCYXJ0b2xvbWUNCg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAzOjAzIFBN
DQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBS
ZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoN
Ck5pcmF2LCBhbGwsDQoNCg0KDQpJIHRoaW5rIHdlIHNob3VsZCBkZWZpbmUgYW4gYWNjdXJhdGUg
YW5kIHJvYnVzdCBzb2x1dGlvbiwgYXMgZWZmaWNpZW50IGFuZCBzaW1wbGUgYXMgcG9zc2libGUu
DQoNCkkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEgcHVyZSAibWF5IiwgYnV0IGxlYXZp
bmcgaXQgdXAgdG8gaW1wbGVtZW50YXRpb24gZG9lcyBub3QgYXNzdXJlIHJlYWN0aW5nIG5vZGUg
aGFzIHZhbGlkIE9MUiBpbmZvcm1hdGlvbiwgd2hhdCBpcyBiYXNpYyBmb3IgdGhpcyBtZWNoYW5p
c20gdG8gd29yay4NCg0KDQoNCkJlc3QgcmVnYXJkcw0KDQovTUNydXoNCg0KDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86
bnNhbG90QGNpc2NvLmNvbV0NCg0KU2VudDogbHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAx
MDoxMg0KDQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRp
bWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTWFyaWEtQ3J1eiwNCg0KDQoNCkkgZnVsbHkgYWdy
ZWUgd2l0aCB5b3Ugb24gInNlbmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9y
dGFudCBhZHZhbnRhZ2VzIi4NCg0KQW5kIHdlIGFyZSBub3QgdHJ5aW5nIHRvIHByZXZlbnQgaXQg
LSBhdCBsZWFzdCB0aGF0IGlzIG15IGludGVudGlvbi4NCg0KQnV0IHRoZSBtYWluIHF1ZXN0aW9u
IGlzLCBhcmUgd2UgdHJ5aW5nIHRvIHByZXZlbnQgYW55IG90aGVyIHBvc3NpYmxlIGltcGxlbWVu
dGF0aW9uLCB3aGljaCBtYXkgYmUgc21hcnRlciBhbmQgY2FuIGF2b2lkIGluY2x1ZGluZyByZWR1
bmRhbnQgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2U/DQoNCg0KDQpNb3N0IHByb2JhYmx5
LCB0aGUgdmVyeSBmaXJzdCBpbXBsZW1lbnRhdGlvbiBvZiBvdmVybG9hZCBjb250cm9sIHdpbGwg
aW5jbHVkZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMuDQoNCkJ1dCBhdCB0aGUgc2Ft
ZSB0aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJlc3RyaWN0IHRoZSBkZXZlbG9wZXJzIHdoaWNoIGNh
biBjb21lIHVwIHdpdGggc29tZSBuaWNlIHR3ZWFrcyBhbmQgdHJpY2tzIHRvIGF2b2lkIHNlbmRp
bmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gZXZlcnkgbWVzc2FnZS4gQW5kIHRoaXMgaXMgd2hl
cmUgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGFuZCBhdm9pZCBwdXR0aW5nIHN1Y2ggcmVzdHJpY3Rp
b25zIGluIHByb3RvY29sIGRlZmluaXRpb24uDQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQoNCg0K
VGhpcyBhbHNvIHRoZSByZWFzb24gSSB3YXMgc3VnZ2VzdGluZyBsb29zZSBkZXNjcmlwdGlvbiBv
ZiB3aGVuIHRvIGluY2x1ZGUgT0xSIChmcm9tIHRoZSByZXBvcnRpbmcgbm9kZSBwb2ludCBvZiB2
aWV3KS4NCg0KDQoNClJlZ2FyZHMsDQoNCk5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQoNClNlbnQ6IEZyaWRheSwgRmVicnVhcnkg
MDcsIDIwMTQgODo1NyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9y
Zz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCg0KDQpIZWxsbyBVbHJpY2gsIE5pcmF2LA0KDQoNCg0KSSBhZ3JlZSB3aXRo
IFVscmljaCB0aGF0IHRoZSB0ZXh0IHByb3ZpZGVkIGJ5IE5pcmF2IGlzIGp1c3QgYSBNQVksIGFu
ZCB3aGV0aGVyIG9yIG5vdCB0aGUgc2VydmVyIHNlbmRzIGFuIE9MUiBpbiBhbGwgYW5zd2VycyBz
aGFsbCBub3QgYmUganVzdCBhIE1BWS4NCg0KDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBjcml0ZXJp
YSBwcm92aWRlZCBieSBVbHJpY2ggb24gd2hlbiBPTFIgaGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMg
dGhlIHNlcnZlciBoYXMgc29tZSBrbm93bGVkZ2U6DQoNCmEpIHRoZSByZXBvcnRpbmcgbm9kZSBr
bm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0ZXN0IE9M
Ug0KDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBu
b3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhh
cyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0KDQpjKSBvdGhlcndpc2UNCg0KDQoN
ClJlcG9ydGluZyBub2RlIG11c3QgaGF2ZSBzb21lIGtub3dsZWRnZSBhYm91dCBPTFIgcmVjZXB0
aW9uL3N0YXR1cyBpbiByZWFjdGluZyBub2RlLiBIb3cgZG9lcyBzZXJ2ZXIgYWNxdWlyZSB0aGlz
IGtub3dsZWRnZT8NCg0KVGFrZSBpbnRvIGFjY291bnQgYXMgd2VsbCB0aGF0IGEgInJlYWN0aW5n
IiBub2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChpbiBjYXNlIGl0IHByb3ZpZGVzIHNlcnZpY2Ug
dG8gYSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50
KSAgYW5kIGEgQ2xpZW50LiBJbiB0aGUgY2FzZSBvZiBBZ2VudHMsIGluIGZhY3QgdGhlIFNlcnZl
ciBtYXkgbm90IGV2ZW4ga25vdyBpZiB0aGlzIGlzIGdvaW5nIHRvIGFjdCBhcyBhIHJlYWN0aW5n
IG5vZGUgb3IganVzdCB0cmFuc3BhcmVudGx5LCBpbiBmYWN0LCB0aGUgc2VydmVyIGRvZXMgbm90
IG5lZWQgdG8gaGF2ZSBhbnkga25vd2xlZGdlIGFib3V0IHdoYXQgYWdlbnRzIGluIHRoZSBjaGFp
biB0byB0aGUgZmluYWwgQ2xpZW50Lg0KDQoNCg0KVGhlcmVmb3JlLCBJIGRlZmluaXRlbHkgdGhp
bmsgdGhhdCBzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2
YW50YWdlczoNCg0KLSBzdGF0ZS1sZXNzIGltcGxlbWVudGF0aW9uICh0cmFuc2FjdGlvbiBvciBz
ZXNzaW9uKSBpcyBzaW1wbGVyLA0KDQotIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRl
cm1pbmUgd2hldGhlciBvciBub3QgdG8gc2VuZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGUNCg0K
LSB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gYm90aGVyIHdoZXRoZXIgYW4gcmVhY3Rpbmcg
bm9kZSBoYXMgYWxyZWFkeSByZWNlaXZlZCBhbiBPTFIgb3Igd2hldGhlciB0aGlzIE9MUiBpcyBz
dGlsbCB2YWxpZCAoaGFzIG5vdCBleHBpcmVkKS4NCg0KLSBzZW5kaW5nIGFuIGFkZGl0aW9uYWwg
QVZQIGlzIG5vdCBwcm9jZXNzaW5nIGNvbnN1bWluZywgaW4gY29tcGFyaXNvbiB3aXRoIHJlcXVp
cmVkIGFib3ZlIGNoZWNrcyAoaWYgdGhpcyBpcyBub3Qgc2VudCkuDQoNCiAgSW4gZmFjdCwgaW4g
YW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxleCBpcyB0
byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBub2RlcywN
Cg0KICBhbmQgdGhlIGxhdHRlciBzaG91bGQgdGFrZSBjYXJlIHRvIHRha2UgYXBwcm9wcmlhdGUg
YWN0aW9ucw0KDQotIG1vcmUgcm9idXN0IHNvbHV0aW9uLCBhcyBubyBuZWVkIHRvIGNhdGVyIGZv
ciBhbGwgdGhlIGNoZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5kIGluZm9ybWF0aW9uLCAgZm9yIHNp
dHVhdGlvbnMgd2hlcmUgYW4gYW5zd2VyIG1lc3NhZ2UgaXMgbG9zdCwgIOKApg0KDQoNCg0KDQoN
CkJlc3QgcmVnYXJkcw0KDQovTUNydXoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpDQoNClNlbnQ6IHZpZXJuZXMsIDA3IGRl
IGZlYnJlcm8gZGUgMjAxNCAxMDo1OQ0KDQpUbzogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBl
eHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20+OyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9y
Zz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCg0KDQpOaXJhdiwNCg0KDQoNCkknbSBhZnJhaWQgeW91ciBwcm9wb3NlZCB0
ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi4NCg0KDQoNCiJ3aGVuIGl0IHdhbnRz
IHRvIHByb3ZpZGUvdXBkYXRlLi4uLml0IHNoYWxsIGluY2x1ZGUuLi4iIHRyYW5zbGF0ZXMgdG8g
Ii4uLml0IG1heSBpbmNsdWRlLi4uIi4NCg0KDQoNCiJpbiBvdGhlciBjYXNlcyIgaW4gdGhlIGdp
dmVuIGNvbnRleHQgdHJhbnNsYXRlcyB0byAid2hlbiBpdCBkb2VzIG5vdCB3YW50IHRvIHByb3Zp
ZGUvdXBkYXRlLi4uIg0KDQoNCg0KDQoNCldlIGhhdmUgdGhlIGZvbGxvd2luZyBjYXNlczoNCg0K
YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFs
cmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQoNCmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qg
b3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRo
YXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJl
DQoNCmMpIG90aGVyd2lzZQ0KDQoNCg0KaW4gY2FzZSBhKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5
IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFIgaW4gY2FzZSBiKSB0aGUgcmVwb3J0aW5nIG5vZGUg
bWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUgcmVhY3Rpbmcgbm9kZSB3aXRoIHRoZSBsYXRlc3Qg
T0xSIGluIGNhc2UgYykgdGhlIHJlcG9ydGluZyBub2RlIE1VU1QgaW5jbHVkZSB0aGUgT0xSIGlu
IHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcgbm9kZSBkb2VzIG5vdCBrbm93IHdoZXRoZXIgdGhp
cyBpcyBhIHJlcGxheSBvciBhbiB1cGRhdGUpDQoNCg0KDQpVbHJpY2gNCg0KDQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCkg
W21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYs
IDIwMTQgNDo0OSBQTQ0KDQpUbzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0
IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PjsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQoNCg0KVWxyaWNoLA0KDQoNCg0KSXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1l
IHBhZ2UgYnV0IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUg
YmVzdC4NCg0KSG93IGFib3V0IHRoZSBmb2xsb3dpbmcuDQoNCg0KDQpXaGVuIHRoZSByZXBvcnRp
bmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQgb3Igd2FudHMgdG8g
dXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVh
Y3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUg
cmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUg
Y29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2Vz
LCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3Zlcmxv
YWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSBy
ZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhl
IHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCg0KDQpSZWdh
cmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206
IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNu
LmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDM6NTcgUE0NCg0KVG86
IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbT47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRm
Lm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpOaXJhdiwgTGlvbmVsLA0K
DQoNCg0KSSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGlu
ZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBs
ZSAyJzoNCg0KDQoNCjInLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92
ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3Bv
bnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBB
VlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3Qg
cmVhc29uYWJsZSBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0aW9uIChlLmcuIHRoZSBsYXRlc3Qg
T0xSLCB3aGljaCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3Ig
YW4gT0xSIGluZGljYXRpbmcgIm5vIG92ZXJsb2FkIiwgb3IgYW4gb2xkICBidXQgc29vbiBleHBp
cmluZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQpOyBvdGhl
cndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5v
IG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4g
cmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVh
dHVyZSBBVlAuDQoNCg0KDQpJIGRvbid0IGFncmVlIHdpdGggTGlvbmVscyBkby13aGF0LXlvdS13
YW50IGFwcHJvYWNoLiBPdmVybG9hZCBjb250cm9sIHdpbGwgbm90IHdvcmsgd2hlbiB3ZSBhbGxv
dyB0aGUgcmVwb3J0aW5nIG5vZGUgbm90IHRvIHVwZGF0ZSByZWFjdGluZyBub2Rlcywgd2hpY2gg
YXJlIG5vdCAoc3VmZmljaWFudGx5KSBhd2FyZSBvZiB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0
dXMsIHdpdGggdXAgdG8gZGF0ZSBPTFJzLg0KDQoNCg0KVWxyaWNoDQoNCg0KDQoNCg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4gW21haWx0bzpsaW9uZWwubW9y
YW5kQG9yYW5nZS5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoy
MCBBTQ0KDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERF
L011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGll
dGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmcNCg0KDQoNCg0KDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t
DQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk
ZSBOaXJhdiBTYWxvdCAobnNhbG90KSBFbnZvecOpIDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDEw
OjA4IMOAIDogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92
YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+IE9iamV0IDogUmU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpVbHJpY2gs
DQoNCg0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiByZXBv
cnRpbmcgbm9kZSAib3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJl
cG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCBy
ZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4g
T0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINCg0KVGhlIHJlcG9ydGluZyBub2RlIG1heSBzaW1w
bHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xS
IHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0
aGUgdHJhZmZpYy4NCg0KDQoNCltMTV0gQWdyZWUuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBub3Qg
ZGVlbWVkIHJlcXVpcmVkIGZvciB0aGUgZGVmYXVsdCBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRo
aXMgZHJhZnQuIEhvdyBhbmQgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgZGVjaWRlcyB0byBpbmNs
dWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciBtYXkgZGVwZW5kIG9uIHRoZSBhcHBsaWNhdGlvbiBv
ciBvbiB0aGUgaW1wbGVtZW50YXRpb24uIEF0IGxlYXN0LCBpdCBpcyBteSBjdXJyZW50IHVuZGVy
c3RhbmRpbmcuDQoNCg0KDQpBcyB3ZSBoYWQgZGlzY3Vzc2VkIGVhcmxpZXIsIHRoZXJlIGlzIG5v
IG5lZWQgZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBleHBsaWNpdGx5IHN0b3AgdGhyb3R0bGlu
ZyBhdCBlYWNoIHJlYWN0aW5nIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4gSW4gb3RoZXIgd29yZHMs
IHRoZSByZXBvcnRpbmcgbm9kZSBjYW4gYWxsb3cgdGhlIG5hdHVyYWwgZXhwaXJ5IG9mIHRoZSBP
TFIgdG8gZmFjaWxpdGF0ZSBzbG93IHJhbXAgb2YgdGhlIHNpZ25hbGluZyB0cmFmZmljIHRvd2Fy
ZHMgaXQuDQoNCg0KDQpbTE1dIEFncmVlDQoNCg0KDQpUaGVyZSBtYXkgYmUgb3RoZXIgY2FzZXMs
IGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgbGFzdCBvdmVybG9h
ZCBzaXR1YXRpb24gZW5kZWQgbG9uZyB0aW1lIGJhY2sgaW4gdGhlIHBhc3QsIHRoZXJlIGlzIG5v
IG5lZWQgZm9yIGl0IHRvIGluY2x1ZGUgT0xSIGlmIGN1cnJlbnRseSB0aGVyZSBpcyBubyBvdmVy
bG9hZCBjb25kaXRpb24uDQoNCg0KDQpbTE1dIEFncmVlDQoNCg0KDQpSZXN0IG9mIHRoZSBwcmlu
Y2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuDQoNCg0KDQpbTE1dIEFncmVlDQoNCg0KDQpS
ZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZy
b206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgW21haWx0bzp1bHJpY2gud2llaGVA
bnNuLmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE0NCg0K
VG86IGV4dCBTdGV2ZSBEb25vdmFuOyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9y
ZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpBY3R1YWxseSB3ZSBzZWVtIHRv
IGFncmVlIG9uIHR3byBwcmluY2lwbGVzOg0KDQoxLiBMYWNrIG9mIE9MUiBtZWFucyAibm8gY2hh
bmdlIg0KDQoyLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2Fk
ZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRv
IHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYg
aXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgdGhlIGxh
dGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlv
biBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiKTsgb3RoZXJ3aXNlIChpLmUuIGlm
IGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhl
ciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byBy
ZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQoN
Cg0KQ2FuIHBlb3BsZSBwbGVhc2UgY29uZmlybS4NCg0KDQoNClVscmljaA0KDQoNCg0KRnJvbTog
RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBTdGV2
ZSBEb25vdmFuDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0K
DQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0
Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQoNCg0KQWdyZWVkLiAgVG8gcmVzdGF0ZSAtLSBsYWNrIG9mIGFuIG92
ZXJsb2FkIHJlcG9ydCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGN1cnJlbnQgb3ZlcmxvYWQgc3RhdGUg
Zm9yIHRoZSBob3N0IG9yIHJlYWxtLiAgSWYgdGhlcmUgaXMgYSBjdXJyZW50bHkgYWN0aXZlIG92
ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IGNvbnRpbnVlcyB0byBhcHBseSB1bnRpbCBpdCBlaXRoZXIg
dGltZXMgb3V0IG9yIGlzIGV4cGxpY2l0bHkgY2hhbmdlZCB3aXRoIGEgbmV3IG92ZXJsb2FkIHJl
cG9ydC4gIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRo
ZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVyZSBpcyBubyBvdmVybG9h
ZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQoNCg0KU3RldmUNCg0KT24gMi81LzE0IDk6MTkg
QU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KDQpJIGFncmVlIHdpdGggU3RldmUgZXhj
ZXB0IHRoZSBwYXJ0ICJzaG91bGRu4oCZdCBsYWNrIG9mIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBu
b3Qgb3ZlcmxvYWRlZD8iDQoNCg0KDQpXZSBoYWQgc29tZSBkaXNjdXNzaW9uIHNvbWV0aW1lIGJh
Y2sgYW5kIHRob3VnaHQgdGhhdCBpdCBpcyByZWFzb25hYmxlIHRvIG5vdCBtYW5kYXRlIHRoZSBz
ZXJ2ZXIgdG8gaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlLiBFLmcuIHdo
ZW4gdGhlIHNlcnZlciBpcyBjYXBhYmxlIG9mIHRyYWNraW5nIHdoYXQgaXMgc2VudCB0byB3aGlj
aCBjbGllbnQgYW5kIGhlbmNlIHdhbnRzIHRvIGF2b2lkIHNlbmRpbmcgaW5mb3JtYXRpb24gd2hp
Y2ggaXMgcmVkdW5kYW50LiBCdXQgdGhpcyBpcyBvcHRpb25hbCBpbXBsZW1lbnRhdGlvbiBhbmQg
YXQgdGhlIHNhbWUgdGltZSBuZWVkIG5vdCBiZSBwcm9oaWJpdGVkIGZyb20gcHJvdG9jb2wgcG9p
bnQgb2Ygdmlldy4NCg0KDQoNClNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3VsZCBu
b3QgYWZmZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcgbm9k
ZS4gVGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9sZGVy
IE9MUiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0aGUg
ZXhwbGljaXQgT0xSIHdpdGggIjAiIG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZlZC4NCg0KSW4g
bXkgdmlldywgdGhpcyBhbGxvd3MgZm9yIGZsZXhpYmxlIGltcGxlbWVudGF0aW9uIGF0IHRoZSBy
ZXBvcnRpbmcgbm9kZSBhbmQgc291bmQgaGFuZGxpbmcgb2YgT0xSIGF0IHRoZSByZWFjdGluZyBu
b2RlLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQpGcm9tOiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RldmUgRG9ub3Zhbg0KDQpTZW50
OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6MDAgUE0NCg0KVG86IGRpbWVAaWV0Zi5v
cmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KaW5saW5lDQoNCk9uIDIvNS8x
NCA3OjU3IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOg0KDQpPayB0
aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1VU1QgaW5zZXJ0IGFuIE9DLU9M
UiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJlc3BvbmQgdG8gcmVxdWVzdCBt
ZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgKGV2ZW4g
d2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLg0KDQpTUkQ+IFdoeSBpbiBldmVy
eSBhbnN3ZXIgbWVzc2FnZT8gIFNob3VsZG4ndCBsYWNrIG9mIGFuIE9MUiBiZSBpbnRlcnByZXRl
ZCBhcyBub3Qgb3ZlcmxvYWRlZD8NCg0KDQoNCg0KDQoNCg0KDQoNCk90aGVyIGNyaXRlcmlhIGxp
a2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLg0KDQpTUkQ+IFJlcXVpcmlu
ZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0bHkgYnJlYWsg
UkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sgZm9yIGFuIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlzIGFsc28gc3Vi
c3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFu
IGluc2VydGluZyBPTFJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KRm9yIG15IGNsYXJpZmljYXRpb246
IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2Vz
cyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkp
LiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3Jk
ZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2Ft
ZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NCg0KU1JEPiBUaGF0
IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBOaXJhdiBTYWxvdCAobnNhbG90
KQ0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU0NCg0KVG86IGxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsg
ZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpJIHNoYXJl
IHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLg0KDQoNCg0KUmVnYXJkcywNCg0KTmlyYXYuDQoN
Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
PG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+DQoNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1
YXJ5IDA0LCAyMDE0IDk6MDcgUE0NCg0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0
Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQoNCg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBp
cyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVy
eSBhbnN3ZXIuDQoNClNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOg0KDQoxLSBPQy1PTFIgQVZQIGlu
IGV2ZXJ5IGFuc3dlcg0KDQoyLSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gZXZl
cnkgcmVxdWVzdCArIE9DLU9MUiBBVlAgaW4gc29tZSBhbnN3ZXIgd2hlbiB0aGUgY3VycmVudCB0
aHJvdHRsaW5nIHBlcmZvcm1lZCBieSB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQoN
Cg0KDQpJZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0
aGUgYmVzdCBhcHByb2FjaC4NCg0KDQoNCkxpb25lbA0KDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3Jp
Z2luZS0tLS0tDQoNCkRlIDogZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1lQHRy
YWMudG9vbHMuaWV0Zi5vcmddDQoNCkVudm95w6kgOiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6
NDkNCg0Kw4AgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCg0KQ2MgOiBkaW1lQGlldGYub3JnPG1h
aWx0bzpkaW1lQGlldGYub3JnPg0KDQpPYmpldCA6IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmcNCg0KDQoNCiMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQoNCg0KIEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgdGhhdCBpcyAgdG8gYmUgaW5jbHVkZWQgYnkgdGhlIHJlYWN0aW5nIERP
SUMgZW5kcG9pbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0ICBzdXJ2aXZlZCBhIHRocm90dGxp
bmcuIFRoaXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBTZXF1ZW5jZS1OdW1iZXINCg0KIChUaW1l
U3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGlj
aCB3YXMNCg0KIHN1cnZpdmVkKSBpcyBwZXJmb3JtZWQuIEFic2VuY2Ugb2YgdGhpcyBBVlAgaW5k
aWNhdGVzIHRoYXQgY3VycmVudGx5IG5vICB0aHJvdHRsaW5nIGlzIHBlcmZvcm1lZC4gIFJlcG9y
dGluZyBET0lDIGVuZHBvaW50cyBtYXkgdXNlIHRoaXMgIGluZm9ybWF0aW9uIGluIG9yZGVyIHRv
IGRldGVjdCB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCB0byB1cGRhdGUgdGhlICByZWFjdGluZyBE
T0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuDQoNCiBBYnNlbmNlIG9mIHRoaXMgZmVl
ZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlICByZXBvcnRp
bmcgbm9kZSB0byBzZW5kIE9DLU9MUiBBVlBzIGluIGV2ZXJ5IGFuc3dlciBhcyB0aGUgcmVwb3J0
aW5nIERPSUMgIGVuZHBvaW50IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlYWN0aW5nIERPSUMg
ZW5kcG9pbnQgaXMgYWN0dWFsbHkgZG9pbmcgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0
byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLg0KDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBp
bXByb3ZlcyByb2J1c3RuZXNzIGFzIGl0IGFsbG93cyB0aGUgcmVwb3J0aW5nIERPSUMgIGVuZHBv
aW50IHRvIGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJvcHJpYXRlIHRocm90dGxpbmcgYnkgdGhl
IHJlYWN0aW5nICBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4NCg0K
IFRoZSBmZWVkYmFjayBtZWNoYW5pc20gYWxzbyBhbGxvd3MgdG8gYWRkcmVzcyBSRVEgMTggZnJv
bSBSRkMgNzA2OC4NCg0KIEluIHN1bW1hcnkgaXQgaXMgcHJvcG9zZWQgdG8gZGVmaW5lIHRoZSBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdG8gIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4NCg0KDQoNCg0KDQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxp
c3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBt
ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h
dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMg
cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u
IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln
bmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg
am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn
YWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz
c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y
IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhl
eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv
cmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh
YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz
aWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8
bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGll
dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBt
YWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRpTUUgbWFpbGluZyBsaXN0DQoN
CkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2Ug
ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj
b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMg
ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg
dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl
cg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq
b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh
bHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt
ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpU
aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg
b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K
DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg
YXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp
dHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v
dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y
IGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0
IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u
ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0
cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv
dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIN
Cg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p
bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0
ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz
c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y
IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0K
dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1
dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is
IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz
IGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg
bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm
YWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBz
ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp
ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJl
IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz
IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoN
CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50
ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy
YXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh
Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMg
bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRo
ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo
b3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw
bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh
dHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp
YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs
c2lmaWVkLg0KDQpUaGFuayB5b3UuDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z
b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OlRpbWVzOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs
YWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFj
azt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj
azt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh
Y2s7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTD
qSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ
csOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7
fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlByZm9ybWF0SFRNTCwgZGl2LlByZm9ybWF0SFRNTA0KCXtt
c28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCW1zby1zdHlsZS1saW5rOiJQcsOp
Zm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0
Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl
cmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxl
LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5UZXh0ZWRlYnVsbGVzLCBsaS5UZXh0ZWRl
YnVsbGVzLCBkaXYuVGV4dGVkZWJ1bGxlcw0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVs
bGVzIjsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh
bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h
aWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2
MTt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMx
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0
OTdEO30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu
LkVtYWlsU3R5bGUzNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1
cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi
Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94
bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t
VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj5NYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2
ZXJ5IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFzIHBvaW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8g
Y29uY2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJlYWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4g
YWxsIHRoZSBpbnRyYS1zZXNzaW9uDQogbWVzc2FnZXMgbmVlZCBub3QgY29udGFpbiB0aGUgc2Ft
ZSBvdmVybG9hZCByZXBvcnQsIGlmIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgbWVzc2FnZSBj
b250YWlucyB0aGUgb3ZlcmxvYWQgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYx
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+U28geW91ciBub3RlIHJlZ2Fy
ZGluZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIG5ldHdvcmsg
ZGVwbG95bWVudCBldGMuIGlzIG5vdCAxMDAlIGNvcnJlY3QuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyNDQwNjEiPkxldCBtZSBzaW1wbGlmeSwgaG9waW5nIGl0IHdpbGwgc2F0aXNmeSB5b3VyIGNv
bmNlcm4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSByZXBvcnRpbmcgbm9kZSBNQVkg
Y2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUg
aWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+dGhpcyBvdmVy
bG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGU8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1
b3Q7Ij4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48
YnI+DQpOb3RlIOKAkyBJbiBzb21lIGNhc2VzLCBlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBt
dWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5n
IG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9k
ZXMsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBvcnQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMyNDQwNjEiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNl
c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFyaWEgQ3J1eiBCYXJ0b2xvbWU8YnI+
DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDI6MzEgUE08YnI+DQo8
Yj5Ubzo8L2I+IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGVuIHdlIGFncmVl
IG9uIHRoZSBwcm9wb3NlZCB0ZXh0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBl
bnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0
cy48YnI+DQo8YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5j
bHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFj
dGluZyBub2Rlcy4mbmJzcDsNCjxicj4NCjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUg
bWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBz
ZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNw
OyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIg
bm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBu
b2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rp
bmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFk
eSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+QnV0IHN0aWxsIHRoZXJlIGFyZSBzb21lIGRpc2NyZXBhbmNpZXMg
YWJvdXQgdGhlIG5vdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHByb3Bvc2Fs
IGlzIHRvIGtlZXAgaXQganVzdCBhcyBhbiBpbmRpY2F0aW9uIG9mIHBvdGVudGlhbCAobWF5YmUg
bm90IGFsbCkgc2l0dWF0aW9ucyB0aGF0IHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgaWYg
ZXZlciBhbnkgaW1wbGVtZW50YXRpb24gbWF5IGNvbnNpZGVyDQogdG8gZG8gbm90IGZvbGxvdyB0
aGUgcmVjb21tZW5kYXRpb24gdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQg
cmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkJlaW5nIGEgcmVjb21tZW5kYXRpb24gYW5kIG5vdCBhIG11c3QsIGF0IGxlYXN0IEkg
dGhpbmsgd2UgbmVlZCB0byBpbmRpY2F0ZSB3aGF0IG1heSBpbXBseSB0byBkbyBub3QgZm9sbG93
IHRoZSByZWNvbW1lbmRhdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVu
IG15IHByb3Bvc2FsIGlzIHRoZSBmb2xsb3dpbmcsIHRoYXQgaW5jbHVkZXMgYSBtb2RpZmljYXRp
b24gdG8gbGFzdCBzZW50ZW5jZSBhYm92ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5B
IHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0
IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQNCjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7
Y29sb3I6cmVkIj50aGlzIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUg
cmVhY3Rpbmcgbm9kZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMm
cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDss
JnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCk5vdGUg4oCTdGhlIHJlcG9ydGluZyBub2RlIG1heSBu
ZWVkIHRvIHRha2UgaW50byBhY2NvdW50IG5ldHdvcmsgZGVwbG95bWVudCBhbmQgcG90ZW50aWFs
IGVycm9ycyBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHNlbnQgb3Zlcmxv
YWQgcmVwb3J0IGlzIGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSwgZS5nLiB0aGVyZSBtYXkg
YmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZw0K
IGFuZCByZWFjdGluZyBub2Rlczsgb3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5
IHJlYWN0aW5nIG5vZGVz4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0
ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRST1RUSU4s
IEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKTxicj4NCjxiPlNlbnQ6PC9iPiBtacOpcmNvbGVz
LCAxMiBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MTM8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1h
aWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdGhpcyB0b3Bp
YywgbXkgdmlldyBpcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIHNoYWxsICZuYnNwO3JlY2VpdmUg
4oCcZW5vdWdo4oCdIE9MUnMgcGVyIHBlcmlvZCBvZiB0aW1lIHRvIGVuc3VyZSB0aGUgZWZmaWNp
ZW5jeSBvZiB0aGUgdHJhZmZpYyAmbmJzcDtyZWR1Y3Rpb24gbWVjaGFuaXNtDQogLiBBIHdheSB0
byBhY2hpZXZlICZuYnNwO3RoZSDigJxlbm91Z2jigJ0gaXMgdG8gaGF2ZSBhbiBPTFIgaW4gYWxs
ICZuYnNwO2Fuc3dlciAmbmJzcDttZXNzYWdlcyBhcyBwcm9wb3NlZCBhbmQgdGhpcyBjYW4gdGhl
IHJlY29tbWVuZGVkIHdheS4gTm93IGFzIE5pcmF2IHNhaWQsIHRoZXJlIG1heSBiZSBwcm90b2Nv
bCBkZXNpZ24gdGhhdCB3aWxsIGJlaGF2ZSBkaWZmZXJlbnRseSBhbmQgc2VuZCDigJxlbm91Z2ji
gJ0gT0xScyAmbmJzcDtidXQgbm90IGluIGFsbCBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGFsc28g
TmlyYXYgbm90ZWQsICZuYnNwO0kgZG8gbm90IHdlbGwgc2VlIHRoZSBuZWVkIHRvIHdyaXRlIGFk
ZGl0aW9uYWwgbm90ZXMgYXMgbWFueSBzaXR1YXRpb25zIGNhbiBvY2N1ciBhbmQgJm5ic3A7YXJl
IG5vdCBsaW1pdGVkIHRvIHRoZSBleGFtcGxlIG9mIHRoZSByZWFjdGluZw0KICZuYnNwO25vZGUg
Jm5ic3A7ZGlzY2FyZGluZyBPTFJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5K
SmFjcXVlcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEg
aHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiA8YSBocmVmPSJtYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+PGJyPg0KPGI+
RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTY6MzU8YnI+DQo8Yj7D
gCZuYnNwOzo8L2I+IE1hcmlhIENydXogQmFydG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBp
ZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCwgaXQgaXMgY29ycmVjdCENCjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6
IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC
NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93
dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEg
cGFydCBkZTwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv
Yj4gbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxNTowMDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEg
aHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2Jq
ZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5MaW9uZWwsIE5pcmF2LCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSB0aGUgbm90ZSBjb3Vs
ZCBiZSBtb2RpZmllZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpOb3RlIOKAk3RoZSByZWFjdGluZyBub2RlIGNvdWxkIGJl
IGFueSBhZ2VudCBpbiB0aGUgcGF0aCwgYW5kIHRoYXQgaW4gc29tZSBlcnJvciBzaXR1YXRpb25z
IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlcy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZGRlZCB0aGUgY2FzZSBPTFIg
Y291bGQgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLCBzaW5jZSBpdCBoaWdobGlnaHRz
IGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBzZXJ2ZXIgd2lsbCBub3Qga25vdyB3aGV0aGVyIG9yIG5v
dCBhIHZhbGlkIE9MUiBpcyByZWNlaXZlZA0KIGJ5IHJlYWN0aW5nIG5vZGUuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C
ZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L01DcnV6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRv
Omxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQg
MTE6MzY8YnI+DQo8Yj5Ubzo8L2I+IE1hcmlhIENydXogQmFydG9sb21lOyA8YSBocmVmPSJtYWls
dG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF0IGxlYXN0LCBpdCBpcyBub3QgJnF1b3Q7dGhl
IG9ubHkgc3VyZSB3YXkmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBp
bnN0YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdlcyBwYXJ0IG9mIHRoZSBzYW1lIHNlc3Npb24gKG9y
IHBzZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNvIGJlIHVzZWQgYXMgaW5kaWNhdGlvbiBmb3IgdGhl
IHJlcG9ydGluZyBub2RlIHRoYXQgdGhlIE9MUiBoYXMgYmVlbg0KIHJlY2VpdmVkIGJ5IHRoZSBy
ZWFjdGluZyBub2RlIChiZXNpZGVzIHRoZSByZWNlcHRpb24gb2YgdGhlIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlcyBpbiB0aGUgcmVxdWVzdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0
IGlzIHdoeSBJIHdhcyBzYXlpbmcgdGhhdCB0aGlzIGNhbiBiZSBmaXhlZCBwZXIgYXBwbGljYXRp
b24vc3lzdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu
IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8
YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxMTozMTxi
cj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GaW5lIE5pcmF2LCBJIGFncmVlIHRoaXMg
aXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
Pk15IGludGVudGlvbiBpcyB0aGF0IGFueSByZWFkZXIgcmVhbGl6ZXMgd2hhdCB0aGlzIGtub3ds
ZWRnZSBpbiB0aGUgc2VydmVyIGltcGxpZXMgd2hlbiB3ZSB0YWxrIGFib3V0IGFnZW50cyBpbiB0
aGUgcGF0aC4gVGhpcyBpcyB3aHkgSSB0aGluayB0aGlzIG5vdGUgaXMgaGVscGZ1bC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L01DcnV6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IE5pcmF2IFNhbG90
IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxv
dEBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVy
byBkZSAyMDE0IDExOjI2PGJyPg0KPGI+VG86PC9iPiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEg
aHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIGRvIG5vdCBhZ3JlZSByZWdh
cmRpbmcgdGhlIGNvbXBsZXhpdHkgc2luY2UgaXQgaXMgaGlnaGx5IGltcGxlbWVudGF0aW9uIHNw
ZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5MZXRzIG5vdCBtYWtlIGFueSBh
c3N1bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
NDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0
NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P
biBCZWhhbGYgT2YgPC9iPk1hcmlhIENydXogQmFydG9sb21lPGJyPg0KPGI+U2VudDo8L2I+IFR1
ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDM6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9
Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8sPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5r
IGl0IGlzIGltcG9ydGFudCB0byBoaWdobGlnaHQgY29tcGxleGl0eSBmb3IgdGhlIHNlcnZlciB0
byAmbmJzcDvigJw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Z3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUNCiBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Ljwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdDQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlzIGlzIHRoZSBwdXJwb3NlIG9mIHRo
ZSBzZW50ZW5jZSBhZGRlZCBieSBTdGV2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg
T2YgPC9iPk5pcmF2IFNhbG90IChuc2Fsb3QpPGJyPg0KPGI+U2VudDo8L2I+IG1hcnRlcywgMTEg
ZGUgZmVicmVybyBkZSAyMDE0IDExOjIwPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBT
dGV2ZSBEb25vdmFuOw0KPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5v
cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5J
IGFtIGFsc28gZmluZSB3aXRoIFN0ZXZlJ3MgcHJvcG9zZWQgd29yZGluZyB0byByZWNvbW1lbmQg
dGhlIGluY2x1c2lvbiBvZiBPTFIgYnV0IHRvIG5vdCBtYW5kYXRlIGl0LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBh
bSBub3Qgc3VyZSBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkg
bmVjZXNzYXJ5IHRvIGFkZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ob3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQg
cHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMg
cmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMg
YSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4NCiB0aGUgY2xpZW50IGFuZCB0
aGUgcmVwb3J0aW5nIG5vZGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkkgcHJlZmVyIHRvIHJlbW92ZSBpdCBzaW5jZSBJIGRvIG5v
dCBzZWUgYXMgdmFsdWUgYWRkaXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlZ2FyZHMsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs
ZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5
IDEwLCAyMDE0IDEwOjEzIFBNPGJyPg0KPGI+VG86PC9iPiBTdGV2ZSBEb25vdmFuOyA8YSBocmVm
PSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkknbSBmaW5lIHdpdGggYSByZWNvbW1l
bmRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1lbnQ6IHdoZW4gYSBN
QVkgb3IgZXZlbiBhIFNIT1VMRCBhcHBseSwgaXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIE5P
VCB1cCB0byB0aGUgbm9kZSB0byBkbyBvciBub3QgdG8gZG8gc29tZXRoaW5nLiBJdCBkb2VzIG5v
dCBtZWFuDQogdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGluc3RhbmNlLCBvdmVyIGEgZ2l2ZW4gaW50ZXJm
YWNlLCB0aGUgcmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkgdGhhdCBzb21lIHN0YXRlcyBh
cmUgbWFpbnRhaW5lZCBieSB0aGUgc2VydmVyLiBBbmQgaXQgY291bGQgYmUgZGVjaWRlZCB0byBh
ZGQgc29tZSBvdmVybG9hZA0KIHJlbGF0ZWQgaW5mbyBpbiBzdWNoIHN0YXRlcy4gRm9yIGluc3Rh
bmNlIGFnYWluLCB0aGUgbm9kZSBjYW4gdXNlIHRoaXMgc3RhdGUgdG8ga25vdyBpZiBhIHJlbW90
ZSBub2RlIGhhdmUgYmVlbiBub3RpZmllZCBvciBub3QgZm9yIGluc3RhbmNlLiBBbmQgaW4gc3Vj
aCBhIGNhc2UsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBpbmNsdWRlIGFuIE9MUiBpbiBl
YWNoIG1lc3NhZ2UuIEl0IGlzIGp1c3QgZm9yIGlsbHVzdHJhdGlvbi4gVGhlIHBvaW50DQogaXMg
dGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhlIE9MUiBpbiBldmVyeSBh
bnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGhhdmlu
ZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l4oCmIGJ1dCBpdCBzaG91bGQgYmUgbm90
IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4gU28gT0sgZm9yIGEgJnF1b3Q7U0hPVUxE
JnF1b3Q7IG9yICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkxpb25lbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k
b3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8
L2I+IFN0ZXZlIERvbm92YW48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTAgZsOp
dnJpZXIgMjAxNCAxNzoyMTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRp
bWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqPC9iPjwvc3Bhbj48Yj48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ZXQm
bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbw0KIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz
cGFuIGxhbmc9IkZSIj5JIGFncmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0p
PGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2ZSB3b3JkaW5nIHNheWluZyB0aGUgcmVj
b21tZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFs
bCByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJ5IE1hcmlhIENydXou
Jm5ic3A7DQo8YnI+DQo8YnI+DQpJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYn
cyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCBhIHJlYWN0aW5n
IG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5
IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4mbmJzcDsgSSBkb24ndCB0aGluayB3ZSBuZWVk
IHRvIGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtub3dz
DQogYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0
dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuJm5ic3A7IFRoZSBjYXNlIG9mIGFn
ZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMg
YmVpbmcgb25lIGV4YW1wbGUuPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPldlIGFs
c28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90
IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLjxicj4NCjxicj4NCkkgcHJvcG9zZSB0aGUg
Zm9sbG93aW5nIG5vcm1hdGl2ZSB3b3JkaW5nLCB3aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5
IE1hcmlhIENydXoncyByZWFzb25zIGZvciByZWNvbW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQg
cmVwb3J0IGlzIGFsd2F5cyBpbmNsdWRlZC48YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCkEg
cmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2
ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy48YnI+DQo8YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0
IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIg
bWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4mbmJzcDsNCjxicj4NCjxicj4NCk5vdGUg
LSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0
IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlz
IG1vcmUgZWZmaWNpZW50LiZuYnNwOyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBp
Z25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48YnI+
DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3Zlcmxv
YWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhl
IHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48
YnI+DQo8YnI+DQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkg
bWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4g
b3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5k
IHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBu
b2RlLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5PbiAyLzEwLzE0IDM6NTIgQU0s
IE1hcmlhIENydXogQmFydG9sb21lIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGVsbG8gTmlyYXYsPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QW55IHNvbHV0aW9uIHNob3VsZCBi
YWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2llbmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBm
cm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBmaXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0
aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBwcm92aWRpbmcgdmFsaWQgT0xSIHRvIHJl
YWN0aW5nIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPllvdXIgcHJvcG9zZWQgdGV4dCZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDsgQWRkaXRpb25hbGx5LCBpbiBvdGhlciBj
YXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92
ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0
aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRv
IHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiZxdW90Ozxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHRoZSBy
ZXBvcnRpbmcgaXMgbm90IGF3YXJlIGFib3V0IHdoZXRoZXIgb3Igbm90IG92ZXJsb2FkIHJlcG9y
dCBpcyBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgYW5kIGl0IGRlY2lkZXMgKHNpbmNl
IGl0IGlzIGEgJnF1b3Q7bWF5JnF1b3Q7KSB0byBkbyBub3Qgc2VuZCB0aGUgT0xSIGFnYWluLCB0
aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gbWVjaGFuaXNtIHdpbGwgbm90IHdvcmsgaW4gY2FzZSBP
TFIgd2FzIG5vdCBwcm9wZXJseSByZWNlaXZlZCBieSBjb3JyZXNwb25kaW5nIHBvdGVudGlhbCBy
ZWFjdGluZyBub2Rlcy4gQW5kIHdlIG5lZWQgdG8gbm90ZSB0aGF0ICZxdW90O3JlYWN0aW5nIG5v
ZGVzJnF1b3Q7IGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNl
ZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZp
Y2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9u
LXN1cHBvcnRpbmcgY2xpZW50KS4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+VGhlbiwgb24gb25lIGhhbmQgaXQgaXMgbm90IHNpbXBsZSB0byBrbm93
IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBPTFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJl
bG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2FpbiAoYXMgcGVyIHlvdXIgcHJvcG9zZWQg
JnF1b3Q7bWF5JnF1b3Q7KSB0aGVuIG9uZSBvciBtdWx0aXBsZSByZWFjdGluZyBub2RlcyBkbyBu
b3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gd2lsbCBu
b3Qgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5UaGVyZWZvcmUsIGluIG15IG9waW5pb24sIHRoZSBzaW1wbGVzdCB3YXkgdG8gcHJvdmlkZSBy
ZXF1aXJlZCBpbmZvcm1hdGlvbiBpcyB0byBwcm92aWRlIE9MUiBpbiBBTEwgYW5zd2Vycy48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZXN0IHJlZ2Fy
ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4vTUNy
dXo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWls
dG86bnNhbG90QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XSA8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBsdW5lcywg
MTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IE1hcmlhIENydXogQmFydG9sb21lOyA8YSBocmVmPSJt
YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CdXQgTWFyaWEtQ3J1eiw8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ib3cgY2FuIHdlIHNheSB0aGF0
ICZxdW90O2luY2x1ZGluZyB0aGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNp
bXBsZSBhbmQgZWZmaWNpZW50PyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkl0IGlzIHNpbXBsZSBmb3Igc3VyZSBidXQgbm90IGVmZmljaWVu
dC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QSBz
bGlnaHRseSBkaWZmZXJlbnQgd29yZGluZyBmcm9tIHdoYXQgSSBwcm9wb3NlZCBlYXJsaWVyIGlz
LCBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBoYXMgYSBuZXcgb3ZlcmxvYWQgcmVwb3J0IHRoYXQg
bmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gYSByZWFjdGluZyBub2RlIChieSB1cGRhdGluZyB0aGUg
ZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgb3IgYnkgcHJvdmlkaW5nIHRoZSBvdmVy
bG9hZCByZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4g
dGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0
dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlv
bmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5v
dCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhl
IHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGlu
IHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVh
dHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC
ZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDM6
MDMgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5U
bzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYsIGFsbCw8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHRoaW5rIHdl
IHNob3VsZCBkZWZpbmUgYW4gYWNjdXJhdGUgYW5kIHJvYnVzdCBzb2x1dGlvbiwgYXMgZWZmaWNp
ZW50IGFuZCBzaW1wbGUgYXMgcG9zc2libGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+SSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWwgYXMgYSBwdXJl
ICZxdW90O21heSZxdW90OywgYnV0IGxlYXZpbmcgaXQgdXAgdG8gaW1wbGVtZW50YXRpb24gZG9l
cyBub3QgYXNzdXJlIHJlYWN0aW5nIG5vZGUgaGFzIHZhbGlkIE9MUiBpbmZvcm1hdGlvbiwgd2hh
dCBpcyBiYXNpYyBmb3IgdGhpcyBtZWNoYW5pc20gdG8gd29yay4gPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QmVzdCByZWdhcmRzPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+L01DcnV6PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5Gcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNj
by5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBk
ZSAyMDE0IDEwOjEyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+VG86IE1hcmlhIENydXogQmFydG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRm
Lm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5NYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ugb24gJnF1b3Q7c2VuZGlu
ZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMmcXVvdDsu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QW5kIHdl
IGFyZSBub3QgdHJ5aW5nIHRvIHByZXZlbnQgaXQgLSBhdCBsZWFzdCB0aGF0IGlzIG15IGludGVu
dGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
QnV0IHRoZSBtYWluIHF1ZXN0aW9uIGlzLCBhcmUgd2UgdHJ5aW5nIHRvIHByZXZlbnQgYW55IG90
aGVyIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uLCB3aGljaCBtYXkgYmUgc21hcnRlciBhbmQgY2Fu
IGF2b2lkIGluY2x1ZGluZyByZWR1bmRhbnQgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2U/
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TW9zdCBw
cm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Ygb3ZlcmxvYWQgY29udHJv
bCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJ1dCBhdCB0aGUgc2FtZSB0
aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJlc3RyaWN0IHRoZSBkZXZlbG9wZXJzIHdoaWNoIGNhbiBj
b21lIHVwIHdpdGggc29tZSBuaWNlIHR3ZWFrcyBhbmQgdHJpY2tzIHRvIGF2b2lkIHNlbmRpbmcg
dGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gZXZlcnkgbWVzc2FnZS4gQW5kIHRoaXMgaXMgd2hlcmUg
d2UgbmVlZCB0byBiZSBjYXJlZnVsIGFuZCBhdm9pZCBwdXR0aW5nIHN1Y2ggcmVzdHJpY3Rpb25z
IGluIHByb3RvY29sIGRlZmluaXRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPldoYXQgZG8geW91IHRoaW5rPzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2Fz
IHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJv
bSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206
IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBG
cmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v
cmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+SGVsbG8gVWxyaWNoLCBOaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGFncmVlIHdpdGggVWxyaWNoIHRoYXQgdGhlIHRl
eHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1BWSwgYW5kIHdoZXRoZXIgb3Igbm90IHRo
ZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNoYWxsIG5vdCBiZSBqdXN0IGEg
TUFZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9u
IHRoZSBvdGhlciBoYW5kLCBjcml0ZXJpYSBwcm92aWRlZCBieSBVbHJpY2ggb24gd2hlbiBPTFIg
aGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMgdGhlIHNlcnZlciBoYXMgc29tZSBrbm93bGVkZ2U6PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YSkgdGhlIHJl
cG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290
IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+YikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRv
ZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9k
ZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmU8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jKSBvdGhlcndpc2U8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZXBvcnRpbmcgbm9kZSBtdXN0
IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rp
bmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBrbm93bGVkZ2U/IDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRha2UgaW50byBhY2Nv
dW50IGFzIHdlbGwgdGhhdCBhICZxdW90O3JlYWN0aW5nJnF1b3Q7IG5vZGUgbWF5IGJlIGJvdGgg
YW4gQWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMgc2VydmljZSB0byBhIHJlYWxtIG9yIGFjdGlu
ZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpJm5ic3A7IGFuZCBhIENsaWVu
dC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIgbWF5IG5vdCBldmVu
IGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGluZyBub2RlIG9yIGp1c3Qg
dHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGhhdmUg
YW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4gdG8gdGhlIGZpbmFs
IENsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5UaGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0aGluayB0aGF0IHNlbmRpbmcgT0xSIGluIEFMTCBh
bnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gc3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlv
biAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikgaXMgc2ltcGxlciw8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVl
ZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gc2VuZCBhbiBPTCB0byBhIHJlYWN0aW5n
IG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t
IHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBib3RoZXIgd2hldGhlciBhbiByZWFjdGluZyBu
b2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBvciB3aGV0aGVyIHRoaXMgT0xSIGlzIHN0
aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gc2VuZGluZyBhbiBhZGRpdGlvbmFsIEFWUCBpcyBub3Qg
cHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1aXJlZCBhYm92ZSBj
aGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgSW4gZmFjdCwgaW4gYW4gb3ZlcmxvYWQgc2l0
dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29tcGxleCBpcyB0byBzZW5kIGluZm9ybWF0
aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJsZSBub2RlcywgPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IGFuZCB0aGUgbGF0dGVy
IHNob3VsZCB0YWtlIGNhcmUgdG8gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb25zJm5ic3A7IDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gbW9yZSByb2J1
c3Qgc29sdXRpb24sIGFzIG5vIG5lZWQgdG8gY2F0ZXIgZm9yIGFsbCB0aGUgY2hlY2tzIG9uIHRo
ZSBuZWVkIHRvIHNlbmQgaW5mb3JtYXRpb24sJm5ic3A7IGZvciBzaXR1YXRpb25zIHdoZXJlIGFu
IGFuc3dlciBtZXNzYWdlIGlzIGxvc3QsJm5ic3A7IOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJv
bTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04g
LSBERS9NdW5pY2gpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+U2VudDogdmllcm5lcywgMDcgZGUgZmVicmVybyBkZSAyMDE0IDEwOjU5PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IGV4dCBOaXJhdiBT
YWxvdCAobnNhbG90KTsgZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBo
cmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdiw8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JJ20gYWZyYWlkIHlvdXIgcHJvcG9z
ZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24uPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7d2hlbiBpdCB3YW50cyB0byBw
cm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRlLi4uJnF1b3Q7IHRyYW5zbGF0ZXMgdG8g
JnF1b3Q7Li4uaXQgbWF5IGluY2x1ZGUuLi4mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7aW4gb3RoZXIgY2FzZXMmcXVvdDsgaW4g
dGhlIGdpdmVuIGNvbnRleHQgdHJhbnNsYXRlcyB0byAmcXVvdDt3aGVuIGl0IGRvZXMgbm90IHdh
bnQgdG8gcHJvdmlkZS91cGRhdGUuLi4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YSkgdGhlIHJlcG9y
dGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRo
ZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+YikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMg
bm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBo
YXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jKSBvdGhlcndpc2U8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pbiBjYXNlIGEpIHRoZSByZXBvcnRp
bmcgbm9kZSBtYXkgb3IgbWF5IG5vdCByZXBsYXkgdGhlIE9MUiBpbiBjYXNlIGIpIHRoZSByZXBv
cnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCB1cGRkYXRlIHRoZSByZWFjdGluZyBub2RlIHdpdGgg
dGhlIGxhdGVzdCBPTFIgaW4gY2FzZSBjKSB0aGUgcmVwb3J0aW5nIG5vZGUgTVVTVCBpbmNsdWRl
IHRoZSBPTFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9ydGluZyBub2RlIGRvZXMgbm90IGtub3cg
d2hldGhlciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVwZGF0ZSk8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5VbHJpY2g8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206
IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5j
b20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIw
MTQgNDo0OSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgPGEgaHJlZj0ibWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9h
PjsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1l
QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5JdCBzZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUgcGFnZSBidXQgcHJvYmFibHkgdGhlIHBy
b3Bvc2VkIHdvcmRpbmcgYmVsb3cgaXMgbm90IHRoZSBiZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoZW4gdGhl
IHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUgbmV3IG92ZXJsb2FkIHJlcG9ydCBvciB3
YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVwb3J0IHRvd2Fy
ZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9uc2Us
IHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dh
cmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwgaW4gb3Ro
ZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRo
ZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9k
ZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNl
LCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+RnJvbTogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbPGEgaHJl
Zj0ibWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tIj5tYWlsdG86dWxyaWNoLndpZWhlQG5zbi5j
b208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IGV4dCA8YSBocmVmPSJtYWls
dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+
OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LCBMaW9uZWwsPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBjYW4gdW5kZXJzdGFuZCBOaXJhdidz
IGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNz
ZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4yJy4gdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0
ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZIGRlY2lkZSBub3QgdG8gcmV0dXJuIGFu
IE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9y
dGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxy
ZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQgY29udHJvbCBpbmZvcm1hdGlvbiAoZS5n
LiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMg
cmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICZxdW90O25vIG92ZXJsb2FkJnF1b3Q7LCBv
ciBhbiBvbGQmbmJzcDsgYnV0IHNvb24gZXhwaXJpbmcgT0xSIHdoZW4gdGhlIHJlcG9ydGluZyBu
b2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2Fy
ZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9y
IG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBj
b250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxz
IGRvLXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29y
ayB3aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5n
IG5vZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50
IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRlIE9MUnMuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNoJm5ic3A7IDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+RnJvbTogZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5k
QG9yYW5nZS5jb20iPm1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+XTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFRodXJzZGF5
LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgV2llaGUsIFVs
cmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1haWx0
bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRlJm5ic3A7OiBE
aU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBOaXJhdiBTYWxvdCAobnNhbG90KSBF
bnZvecOpJm5ic3A7OiBqZXVkaSA2IGbDqXZyaWVyIDIwMTQgMTA6MDggw4AmbmJzcDs6IFdpZWhl
LCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJt
YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT4gT2JqZXQmbmJzcDs6IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVscmljaCw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGFtIG5vdCBzdXJlIGFi
b3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiByZXBvcnRpbmcgbm9kZSAmcXVvdDtvdGhlcndp
c2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1h
dHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVz
cG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZSBBVlAuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+VGhlIHJlcG9ydGluZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3Vt
aW5nIHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVh
Y3Rpbmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTE1dIEFncmVlLiBJbiBvdGhl
ciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJlZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFu
aXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBIb3cgYW5kIHdoZW4gdGhlIHJlcG9ydGluZyBu
b2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBv
biB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCwgaXQg
aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUg
aXMgbm8gbmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJv
dHRsaW5nIGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3
b3JkcywgdGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2Yg
dGhlIE9MUiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMg
dG93YXJkcyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5bTE1dIEFncmVlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+VGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGlu
ZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3ZlcmxvYWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcg
dGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpdCB0byBpbmNsdWRl
IE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgY29uZGl0aW9uLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltMTV0gQWdyZWU8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZXN0IG9mIHRo
ZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W0xNXSBBZ3JlZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmlyYXYuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5G
cm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFs8YSBocmVmPSJtYWlsdG86dWxy
aWNoLndpZWhlQG5zbi5jb20iPm1haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbTwvYT5dPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogVGh1cnNk
YXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogZXh0IFN0ZXZlIERvbm92YW47IE5pcmF2IFNhbG90
IChuc2Fsb3QpOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJq
ZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BY3R1YWxs
eSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmluY2lwbGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEuIExhY2sgb2YgT0xSIG1lYW5zICZxdW90
O25vIGNoYW5nZSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3Zlcmxv
YWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2Ug
dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBp
ZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUg
bGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0
aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICZxdW90O25vIG92ZXJsb2FkJnF1b3Q7KTsgb3RoZXJ3
aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBt
YXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJl
c3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFs
ZiBPZiBleHQgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQ
TTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBO
aXJhdiBTYWxvdCAobnNhbG90KTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+QWdyZWVkLiZuYnNwOyBUbyByZXN0YXRlIC0tIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0
IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhvc3Qg
b3IgcmVhbG0uJm5ic3A7IElmIHRoZXJlIGlzIGEgY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCBy
ZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkgdW50aWwgaXQgZWl0aGVyIHRpbWVzIG91
dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBhIG5ldyBvdmVybG9hZCByZXBvcnQuJm5i
c3A7IElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4g
bGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVyZSBpcyBubyBvdmVybG9hZCBm
b3IgdGhlIGhvc3QgYW5kIHJlYWxtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPlN0ZXZlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+T24gMi81LzE0IDk6MTkgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdy
b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkg
YWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQgJnF1b3Q7c2hvdWxkbuKAmXQgbGFjayBv
ZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/JnF1b3Q7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2UgaGFkIHNvbWUgZGlzY3Vz
c2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRoYXQgaXQgaXMgcmVhc29uYWJsZSB0byBu
b3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIg
bWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSBvZiB0cmFja2luZyB3aGF0
IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5jZSB3YW50cyB0byBhdm9pZCBzZW5kaW5n
IGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4gQnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1w
bGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUgbmVlZCBub3QgYmUgcHJvaGliaXRlZCBm
cm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+U28gYmFzaWNhbGx5LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxk
IG5vdCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBu
b2RlLiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3QgYmFzZWQgb24gb2xk
ZXIgT0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlvZCBvciB3aGVuIHRo
ZSBleHBsaWNpdCBPTFIgd2l0aCAmcXVvdDswJnF1b3Q7IG92ZXJsb2FkLW1ldHJpYyBpcyByZWNl
aXZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5J
biBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3IgZmxleGlibGUgaW1wbGVtZW50YXRpb24gYXQgdGhl
IHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBoYW5kbGluZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5n
IG5vZGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBX
ZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6MDAgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0
Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+aW5saW5lPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+T24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERF
L011bmljaCkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+T2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGlu
c2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25k
IHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TUkQmZ3Q7IFdoeSBp
biBldmVyeSBhbnN3ZXIgbWVzc2FnZT8mbmJzcDsgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJl
IGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk90aGVyIGNyaXRlcmlhIGxpa2UgUkVRMTggb3IgUkVR
MTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPlNSRCZndDsgUmVxdWlyaW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBp
biBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywgYnV0IHJlcXVpcmluZyBh
biBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlhbCBhZGRpdGlvbmFsIHdv
cmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5nIE9MUnMuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yIG15IGNsYXJp
ZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQg
dG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5
cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5v
ZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBh
dCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj88bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TUkQmZ3Q7IFRo
YXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJlci48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZy
b206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChu
c2Fsb3QpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA1OjI3IEFNPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IDxhIGhyZWY9Im1haWx0bzps
aW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgc2hhcmUgdGhlIHNhbWUgb3Bp
bmlvbiBhcyBMaW9uZWwuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+
XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDk6
MDcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5U
bzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB1bmRlcnN0YW5kIHRo
YXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBET0VTIE5PVCBp
bnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEtIE9DLU9MUiBBVlAg
aW4gZXZlcnkgYW5zd2VyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Mi0gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVl
c3QgJiM0MzsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRocm90
dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB0aGVyZSBpcyBu
byBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0aGUgYmVzdCBhcHByb2FjaC48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5MaW9uZWw8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU1l
c3NhZ2UgZCdvcmlnaW5lLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5EZSZuYnNwOzogZGltZSBpc3N1ZSB0cmFja2VyIFs8YSBocmVmPSJtYWls
dG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnIj5tYWlsdG86dHJhYyYjNDM7ZGlt
ZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5FbnZvecOpJm5ic3A7OiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQg
MDk6NDk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7D
gCZuYnNwOzogTU9SQU5EIExpb25lbCBJTVQvT0xOPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll
dGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPk9iamV0Jm5ic3A7OiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IEl0IGhhcyBiZWVuIHByb3Bvc2Vk
IHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdGhhdCBpcyZuYnNw
OyB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQmbmJzcDsgc3Vydml2ZWQgYSB0aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3Vs
ZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IChUaW1lU3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5n
IHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gc3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJz
ZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm8mbmJzcDsgdGhyb3R0
bGluZyBpcyBwZXJmb3JtZWQuJm5ic3A7IFJlcG9ydGluZyBET0lDIGVuZHBvaW50cyBtYXkgdXNl
IHRoaXMmbmJzcDsgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUg
aXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGUmbmJzcDsgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCB3aXRo
IHRoZSBsYXRlc3QgT0xSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3Vs
dCBpbiB0aGUgbmVlZCBmb3IgdGhlJm5ic3A7IHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xS
IEFWUHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNwOyBlbmRwb2lu
dCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50IGlzIGFjdHVh
bGx5IGRvaW5nJm5ic3A7IHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5n
L25vdCB0aHJvdHRsaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMg
aXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNwOyBlbmRwb2ludCB0byBkZXRlY3QgYW5k
IGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5nIGJ5IHRoZSByZWFjdGluZyZuYnNwOyBE
T0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gVGhlIGZlZWRiYWNrIG1lY2hhbmlz
bSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBJbiBzdW1tYXJ5IGl0IGlz
IHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRv
Jm5ic3A7IGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJl
Zj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg
Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz
IGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll
cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy
ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh
aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl
dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw
b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp
ZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50
aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh
dzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0
IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl
IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo
bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn
ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5rIHlvdS48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0ibWFpbHRv
OkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EaU1FIG1haWxp
bmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRm
Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0
Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8
L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw
ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp
bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll
cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy
ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1
ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1
c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg
Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgbWVzc2Fn
ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dGhleSBzaG91bGQgbm90IGJl
IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgeW91IGhhdmUg
cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu
ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QXMgZW1haWxzIG1heSBiZSBhbHRl
cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k
aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj
b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg
ZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y
aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl
eiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p
bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0
ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9y
YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0
ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv
bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg
cHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0
aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl
IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo
bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BcyBl
bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0
aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu
dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug
cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp
ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy
cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs
ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl
cHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz
YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u
IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg
b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm
b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6D626xmbrcdx10ciscoc_--


From maria.cruz.bartolome@ericsson.com  Thu Feb 13 05:19:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C431A0237 for ; Thu, 13 Feb 2014 05:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN5S6EbvF9D1 for ; Thu, 13 Feb 2014 05:19:46 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05C1A0234 for ; Thu, 13 Feb 2014 05:19:45 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-10-52fcc66f58f0
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 73.31.23809.F66CCF25; Thu, 13 Feb 2014 14:19:43 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 14:19:43 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3y9MUA==
Date: Thu, 13 Feb 2014 13:19:42 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774C5E@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>  
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774C5EESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvjW7+sT9BBt9eWVjM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAn3Ego6djFWfJiR38A4YStjFyMnh4SAiURry3koW0ziwr31 bF2MXBxCAocYJZqOX2eFcJYwSkz/95UJpIpNwE7i0ukXQDYHh4iAssTpXw4gYWGBcomXl64w g9giAhUSn7deYgLpFRH4xihx8NdhFpAEi4CqxJ1FN8C28Qr4SrS/bYFasJ1fYueSFawgCUag M76fWgO2jFlAXOLWk/lMEOcJSCzZc54ZwhaVePn4HyuErSSx6PZnsIOYBfIlrq+qgZgvKHFy 5hOWCYzCs5BMmoVQNQtJFURYU2L9Ln2IakWJKd0P2SFsDYnWOXPZkcUXMLKvYmTPTczMSS83 2sQIjIaDW36r7mC8c07kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi1 Jb2L0889Mp8V31YQPvdRU5SOX+OUTUodsdqnZxTFH45cULZ/D9eC918b3nPemTLbfu/q3fyn jugG3hJ+uUq0rel65SX+vM+q7Ps5Pv6oeKUQ9/RC5u9N/w9ccxb6pf1M3ExyUWPKVv2J6md/ TMqYv+K4c6dEwibhhwn7/RacS+3mOeHwua1ZiaU4I9FQi7moOBEAsMUk/1QCAAA=
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 13:19:49 -0000

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

TmlyYXYsDQoNCkRvIHlvdSBjb25zaWRlciB0aGF0IG92ZXJsb2FkIHJlcG9ydHMgY2FuIG9ubHkg
YmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzIHdoZW4gdGhlcmUgYXJlIGFnZW50cyBpbiB0
aGUgcGF0aD8NCg0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBj
aXNjby5jb21dDQpTZW50OiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAxNCAxMzo1OA0KVG86
IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3Jn
Pg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nDQoNCk1hcmlhLUNydXosDQoNClJlcG9ydGluZyBub3RlIG1heSB1c2UgdmVyeSBzaW1w
bGUgbWVjaGFuaXNtIOKAkyBhcyBwb2ludGVkIG91dCBieSBMaW9uZWwg4oCTIHRvIGNvbmNsdWRl
IHRoYXQgcmVwb3J0IGhhcyByZWFjaGVkIHRoZSByZWFjdGluZyBub2RlLCBpLmUuIGFsbCB0aGUg
aW50cmEtc2Vzc2lvbiBtZXNzYWdlcyBuZWVkIG5vdCBjb250YWluIHRoZSBzYW1lIG92ZXJsb2Fk
IHJlcG9ydCwgaWYgdGhlIHNlc3Npb24gZXN0YWJsaXNobWVudCBtZXNzYWdlIGNvbnRhaW5zIHRo
ZSBvdmVybG9hZCByZXBvcnQuDQoNClNvIHlvdXIgbm90ZSByZWdhcmRpbmcgdGhlIHJlcG9ydGlu
ZyBub2RlIHRvIHRha2UgaW50byBhY2NvdW50IHRoZSBuZXR3b3JrIGRlcGxveW1lbnQgZXRjLiBp
cyBub3QgMTAwJSBjb3JyZWN0Lg0KTGV0IG1lIHNpbXBsaWZ5LCBob3BpbmcgaXQgd2lsbCBzYXRp
c2Z5IHlvdXIgY29uY2Vybi4NCg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBz
ZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJh
bnRlZSB0aGF0IHRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgYWN0aXZlIGluIHRoZSBy
ZWFjdGluZyBub2RlLg0KDQpOb3RlIOKAkyBJbiBzb21lIGNhc2VzLCBlLmcuIHdoZW4gdGhlcmUg
YXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcg
YW5kIHJlYWN0aW5nIG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkg
cmVhY3Rpbmcgbm9kZXMsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgbm90IGJlIGFibGUgdG8gZ3Vh
cmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBvcnQuDQoN
ClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBUaHVyc2RheSwg
RmVicnVhcnkgMTMsIDIwMTQgMjozMSBQTQ0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmcNCg0KRGVhciBhbGwsDQoNCkkgdGhpbmsgdGhlbiB3ZSBhZ3JlZSBvbiB0
aGUgcHJvcG9zZWQgdGV4dDoNCg0KQSByZXBvcnRpbmcgbm9kZSBNVVNUIGVuc3VyZSB0aGF0IGFs
bCByZWFjdGluZyBub2RlcyByZWNlaXZlIG5ldyBvdmVybG9hZCByZXBvcnRzLg0KDQpJdCBpcyBy
ZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRz
IGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4NCg0KTm90ZSAt
IHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgYWxzbyBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQg
aW4gYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gbm9uIHJlYWN0aW5nIG5vZGVzIGlmIHRoYXQgaXMg
bW9yZSBlZmZpY2llbnQuICBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVk
IGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy4NCg0KQSByZXBv
cnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBh
IHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2Rl
IGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuDQoNCkJ1dCBzdGlsbCB0
aGVyZSBhcmUgc29tZSBkaXNjcmVwYW5jaWVzIGFib3V0IHRoZSBub3RlLg0KTXkgcHJvcG9zYWwg
aXMgdG8ga2VlcCBpdCBqdXN0IGFzIGFuIGluZGljYXRpb24gb2YgcG90ZW50aWFsIChtYXliZSBu
b3QgYWxsKSBzaXR1YXRpb25zIHRoYXQgc2hvdWxkIGJlIHRha2VuIGludG8gYWNjb3VudCBpZiBl
dmVyIGFueSBpbXBsZW1lbnRhdGlvbiBtYXkgY29uc2lkZXIgdG8gZG8gbm90IGZvbGxvdyB0aGUg
cmVjb21tZW5kYXRpb24gdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVw
b3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzLg0KQmVpbmcgYSByZWNvbW1lbmRhdGlvbiBhbmQg
bm90IGEgbXVzdCwgYXQgbGVhc3QgSSB0aGluayB3ZSBuZWVkIHRvIGluZGljYXRlIHdoYXQgbWF5
IGltcGx5IHRvIGRvIG5vdCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uLg0KVGhlbiBteSBwcm9w
b3NhbCBpcyB0aGUgZm9sbG93aW5nLCB0aGF0IGluY2x1ZGVzIGEgbW9kaWZpY2F0aW9uIHRvIGxh
c3Qgc2VudGVuY2UgYWJvdmU6DQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qg
c2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFy
YW50ZWUgdGhhdCB0aGlzIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUg
cmVhY3Rpbmcgbm9kZS4NCg0KTm90ZSDigJN0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5lZWQgdG8g
dGFrZSBpbnRvIGFjY291bnQgbmV0d29yayBkZXBsb3ltZW50IGFuZCBwb3RlbnRpYWwgZXJyb3Jz
IGluIG9yZGVyIHRvIGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQgc2VudCBvdmVybG9hZCByZXBv
cnQgaXMgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLCBlLmcuIHRoZXJlIG1heSBiZSBvbmUg
b3IgbXVsdGlwbGUgYWdlbnRzIGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCByZWFj
dGluZyBub2Rlczsgb3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5n
IG5vZGVz4oCmDQoNCg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6
MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl
dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0K
CXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZh
bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLlByZm9ybWF0SFRNTCwgbGkuUHJmb3Jt
YXRIVE1MLCBkaXYuUHJmb3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg
SFRNTCI7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2lu
OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
VGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs
ZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9
DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJ
e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0
ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpz
cGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N
CnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls
U3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzQNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM1DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s
b3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUzNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMzcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi
IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv
cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+TmlyYXYsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EbyB5b3UgY29uc2lkZXIgdGhh
dCBvdmVybG9hZCByZXBvcnRzIGNhbiBvbmx5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rl
cyB3aGVuIHRoZXJlIGFyZSBhZ2VudHMgaW4gdGhlIHBhdGg/PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu
ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OndpbmRvd3RleHQiPiBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxv
dEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6
PC9iPiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAxNCAxMzo1ODxicj4NCjxiPlRvOjwvYj4g
TWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1l
QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0
NDA2MSI+TWFyaWEtQ3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlcG9ydGluZyBub3RlIG1heSB1c2UgdmVyeSBz
aW1wbGUgbWVjaGFuaXNtIOKAkyBhcyBwb2ludGVkIG91dCBieSBMaW9uZWwg4oCTIHRvIGNvbmNs
dWRlIHRoYXQgcmVwb3J0IGhhcyByZWFjaGVkIHRoZSByZWFjdGluZyBub2RlLCBpLmUuIGFsbCB0
aGUgaW50cmEtc2Vzc2lvbg0KIG1lc3NhZ2VzIG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3Zl
cmxvYWQgcmVwb3J0LCBpZiB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFp
bnMgdGhlIG92ZXJsb2FkIHJlcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlNvIHlvdXIgbm90ZSByZWdhcmRpbmcg
dGhlIHJlcG9ydGluZyBub2RlIHRvIHRha2UgaW50byBhY2NvdW50IHRoZSBuZXR3b3JrIGRlcGxv
eW1lbnQgZXRjLiBpcyBub3QgMTAwJSBjb3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj5MZXQgbWUgc2ltcGxpZnksIGhvcGluZyBpdCB3aWxsIHNhdGlzZnkgeW91ciBjb25jZXJu
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29z
ZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0
IGNhbiBndWFyYW50ZWUgdGhhdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPnRoaXMgb3ZlcmxvYWQg
cmVwb3J0IGlzIGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0K
Tm90ZSDigJMgSW4gc29tZSBjYXNlcywgZS5nLiB3aGVuIHRoZXJlIGFyZSBvbmUgb3IgbXVsdGlw
bGUgYWdlbnRzIGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rl
czsgb3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLCB0
aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5vdCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSBy
ZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCB0aGUgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVnYXJkcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5NYXJpYSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNlbnQ6PC9i
PiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgMjozMSBQTTxicj4NCjxiPlRvOjwvYj4gPGEg
aHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWFyIGFsbCw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkkgdGhpbmsgdGhlbiB3ZSBhZ3JlZSBvbiB0aGUgcHJvcG9zZWQgdGV4dDo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5B
IHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2Vp
dmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuPGJyPg0KPGJyPg0KSXQgaXMgcmVjb21tZW5kZWQgdGhh
dCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2Vy
IG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuJm5ic3A7DQo8YnI+DQo8YnI+DQpOb3Rl
IC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9y
dCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhhdCBp
cyBtb3JlIGVmZmljaWVudC4mbmJzcDsgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUg
aWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuPGJy
Pg0KPGJyPg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJs
b2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRo
ZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBzdGlsbCB0aGVyZSBh
cmUgc29tZSBkaXNjcmVwYW5jaWVzIGFib3V0IHRoZSBub3RlLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5NeSBwcm9wb3NhbCBpcyB0byBrZWVwIGl0IGp1c3QgYXMgYW4gaW5kaWNhdGlv
biBvZiBwb3RlbnRpYWwgKG1heWJlIG5vdCBhbGwpIHNpdHVhdGlvbnMgdGhhdCBzaG91bGQgYmUg
dGFrZW4gaW50byBhY2NvdW50IGlmIGV2ZXIgYW55IGltcGxlbWVudGF0aW9uIG1heSBjb25zaWRl
cg0KIHRvIGRvIG5vdCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIHRoYXQgYSByZXBvcnRpbmcg
bm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcy4NCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZWluZyBhIHJlY29tbWVuZGF0aW9uIGFuZCBu
b3QgYSBtdXN0LCBhdCBsZWFzdCBJIHRoaW5rIHdlIG5lZWQgdG8gaW5kaWNhdGUgd2hhdCBtYXkg
aW1wbHkgdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24uDQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+VGhlbiBteSBwcm9wb3NhbCBpcyB0aGUgZm9sbG93aW5nLCB0aGF0
IGluY2x1ZGVzIGEgbW9kaWZpY2F0aW9uIHRvIGxhc3Qgc2VudGVuY2UgYWJvdmU6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90
OywmcXVvdDtzZXJpZiZxdW90OyI+QSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBz
ZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJh
bnRlZSB0aGF0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+dGhpcyBvdmVybG9hZCByZXBvcnQgaXMg
YWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpOb3RlIOKAk3Ro
ZSByZXBvcnRpbmcgbm9kZSBtYXkgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudCBuZXR3b3JrIGRl
cGxveW1lbnQgYW5kIHBvdGVudGlhbCBlcnJvcnMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBndWFy
YW50ZWUgdGhhdCBzZW50IG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUgaW4gdGhlIHJlYWN0aW5n
IG5vZGUsIGUuZy4gdGhlcmUgbWF5IGJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBh
dGggYmV0d2VlbiByZXBvcnRpbmcNCiBhbmQgcmVhY3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9y
dHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlc+KApjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_087A34937E64E74E848732CFF8354B9209774C5EESESSMB101erics_--


From nsalot@cisco.com  Thu Feb 13 06:56:05 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536A51A01EB for ; Thu, 13 Feb 2014 06:56:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orx4JUP9-2u7 for ; Thu, 13 Feb 2014 06:56:02 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id CFBF51A008E for ; Thu, 13 Feb 2014 06:56:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28592; q=dns/txt; s=iport; t=1392303361; x=1393512961; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=k56SeQ6SJx390zfAD2vEXCtiV9OMZREWm/TZWwFXC60=; b=fq3abWZmW8RuMQZxi4TjHs2oYBpCvfTDh6S5pN1F6gjcK12XD97tYVDd LWHhdq+GnwxgseexBAOurD8XOsfc5Ujz2R3KKIBt1kI9UUSThAAmuk6lG Pxs7wVrGIo+wZYq/Fbi7m2ztGIOUQ+VgL7AryLF8wCWsCDuHlkTlAF2+y c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApcFAOvb/FKtJXHB/2dsb2JhbABZgkJEOFeDALxMGH8WdIIlAQEBBCMKXAIBCBEEAQELCwsDBAMCAgIwFAkIAgQBEgiHfaVjoicXjkg3AQYEgmU1gRQElEOORodGgW+BPoIq
X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208,217";a="20176737"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 13 Feb 2014 14:56:00 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1DEu0DN020195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 14:56:00 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:55:59 -0600
From: "Nirav Salot (nsalot)" 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3y9MUP++Q/+g
Date: Thu, 13 Feb 2014 14:55:59 +0000
Message-ID: 
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209774C5E@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774C5E@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.45.37]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6D6FFxmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 14:56:05 -0000

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

TWFyaWEtQ3J1eiwNCg0KTWF5IGJlIGZvbGxvd2luZyBmb3JtYXR0aW5nIG9mIHRoZSBub3RlIGhl
bHBzPw0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2Fk
IHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoaXMg
b3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLg0K
DQpOb3RlIOKAkyBJbiBzb21lIGNhc2VzIChlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBtdWx0
aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5v
ZGVzLCBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMp
IHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQgdGhl
IHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBvcnQuDQoNClJlZ2FyZHMsDQpOaXJh
di4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIw
MTQgNjo1MCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt
ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpOaXJhdiwNCg0KRG8geW91IGNv
bnNpZGVyIHRoYXQgb3ZlcmxvYWQgcmVwb3J0cyBjYW4gb25seSBiZSBkaXNjYXJkZWQgYnkgcmVh
Y3Rpbmcgbm9kZXMgd2hlbiB0aGVyZSBhcmUgYWdlbnRzIGluIHRoZSBwYXRoPw0KDQoNCkZyb206
IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IGp1
ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDEzOjU4DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xv
bWU7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1
eiwNCg0KUmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFz
IHBvaW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8gY29uY2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJl
YWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4gYWxsIHRoZSBpbnRyYS1zZXNzaW9uIG1lc3Nh
Z2VzIG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3ZlcmxvYWQgcmVwb3J0LCBpZiB0aGUgc2Vz
c2lvbiBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFpbnMgdGhlIG92ZXJsb2FkIHJlcG9ydC4N
Cg0KU28geW91ciBub3RlIHJlZ2FyZGluZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRv
IGFjY291bnQgdGhlIG5ldHdvcmsgZGVwbG95bWVudCBldGMuIGlzIG5vdCAxMDAlIGNvcnJlY3Qu
DQpMZXQgbWUgc2ltcGxpZnksIGhvcGluZyBpdCB3aWxsIHNhdGlzZnkgeW91ciBjb25jZXJuLg0K
DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVw
b3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhpcyBvdmVy
bG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUuDQoNCk5v
dGUg4oCTIEluIHNvbWUgY2FzZXMsIGUuZy4gd2hlbiB0aGVyZSBhcmUgb25lIG9yIG11bHRpcGxl
IGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7
IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2RlcywgdGhl
IHJlcG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCB0aGUgcmVh
Y3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9ydC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0K
DQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
TWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAy
OjMxIFBNDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6
IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpE
ZWFyIGFsbCwNCg0KSSB0aGluayB0aGVuIHdlIGFncmVlIG9uIHRoZSBwcm9wb3NlZCB0ZXh0Og0K
DQpBIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJl
Y2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuDQoNCkl0IGlzIHJlY29tbWVuZGVkIHRoYXQgYSBy
ZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNz
YWdlcyBzZW50IHRvIHJlYWN0aW5nIG5vZGVzLg0KDQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2Rl
IG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMg
c2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4gIFRo
ZSBvdmVybG9hZCByZXBvcnQgd2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2Rl
IHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9v
c2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBp
dCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2
ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0KQnV0IHN0aWxsIHRoZXJlIGFyZSBzb21lIGRpc2Ny
ZXBhbmNpZXMgYWJvdXQgdGhlIG5vdGUuDQpNeSBwcm9wb3NhbCBpcyB0byBrZWVwIGl0IGp1c3Qg
YXMgYW4gaW5kaWNhdGlvbiBvZiBwb3RlbnRpYWwgKG1heWJlIG5vdCBhbGwpIHNpdHVhdGlvbnMg
dGhhdCBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50IGlmIGV2ZXIgYW55IGltcGxlbWVudGF0
aW9uIG1heSBjb25zaWRlciB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiB0aGF0
IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIg
bWVzc2FnZXMuDQpCZWluZyBhIHJlY29tbWVuZGF0aW9uIGFuZCBub3QgYSBtdXN0LCBhdCBsZWFz
dCBJIHRoaW5rIHdlIG5lZWQgdG8gaW5kaWNhdGUgd2hhdCBtYXkgaW1wbHkgdG8gZG8gbm90IGZv
bGxvdyB0aGUgcmVjb21tZW5kYXRpb24uDQpUaGVuIG15IHByb3Bvc2FsIGlzIHRoZSBmb2xsb3dp
bmcsIHRoYXQgaW5jbHVkZXMgYSBtb2RpZmljYXRpb24gdG8gbGFzdCBzZW50ZW5jZSBhYm92ZToN
Cg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJl
cG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoaXMgb3Zl
cmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLg0KDQpO
b3RlIOKAk3RoZSByZXBvcnRpbmcgbm9kZSBtYXkgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudCBu
ZXR3b3JrIGRlcGxveW1lbnQgYW5kIHBvdGVudGlhbCBlcnJvcnMgaW4gb3JkZXIgdG8gYmUgYWJs
ZSB0byBndWFyYW50ZWUgdGhhdCBzZW50IG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUgaW4gdGhl
IHJlYWN0aW5nIG5vZGUsIGUuZy4gdGhlcmUgbWF5IGJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMg
aW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzOyBvdmVybG9h
ZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXPigKYNCg0KDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6
MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl
dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0K
CXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZh
bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLlByZm9ybWF0SFRNTCwgbGkuUHJmb3Jt
YXRIVE1MLCBkaXYuUHJmb3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg
SFRNTCI7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
VGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs
ZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9
DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJ
e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0
ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpz
cGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N
CnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls
U3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzQNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM1DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s
b3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUzNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMzcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h
aWxTdHlsZTM4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3
MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
NDQwNjEiPk1hcmlhLUNydXosPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5NYXkgYmUgZm9sbG93aW5nIGZvcm1hdHRpbmcg
b2YgdGhlIG5vdGUgaGVscHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3Nl
cmlmJnF1b3Q7Ij5BIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3Zl
cmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQN
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7
c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj50aGlzIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IGFj
dGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCk5vdGUg4oCTIEluIHNvbWUgY2Fz
ZXMgKGUuZy4gd2hlbiB0aGVyZSBhcmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0
aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXMsIG92ZXJsb2FkIHJlcG9ydHMg
bWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2RlcykgdGhlIHJlcG9ydGluZyBub2RlIG1h
eSBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgcmVj
ZWl2ZWQgdGhlIHJlcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu
ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OndpbmRvd3RleHQiPiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g
QmVoYWxmIE9mIDwvYj5NYXJpYSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy
c2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNjo1MCBQTTxicj4NCjxiPlRvOjwvYj4gZGltZUBpZXRm
Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tmly
YXYsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5EbyB5b3UgY29uc2lkZXIgdGhhdCBvdmVybG9hZCByZXBvcnRzIGNhbiBv
bmx5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2RlcyB3aGVuIHRoZXJlIGFyZSBhZ2VudHMg
aW4gdGhlIHBhdGg/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBOaXJhdiBTYWxv
dCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fs
b3RAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBqdWV2ZXMsIDEzIGRlIGZlYnJl
cm8gZGUgMjAxNCAxMzo1ODxicj4NCjxiPlRvOjwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxh
IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1
YmplY3Q6PC9iPiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TWFyaWEtQ3J1eiw8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQw
NjEiPlJlcG9ydGluZyBub3RlIG1heSB1c2UgdmVyeSBzaW1wbGUgbWVjaGFuaXNtIOKAkyBhcyBw
b2ludGVkIG91dCBieSBMaW9uZWwg4oCTIHRvIGNvbmNsdWRlIHRoYXQgcmVwb3J0IGhhcyByZWFj
aGVkIHRoZSByZWFjdGluZyBub2RlLCBpLmUuIGFsbCB0aGUgaW50cmEtc2Vzc2lvbg0KIG1lc3Nh
Z2VzIG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3ZlcmxvYWQgcmVwb3J0LCBpZiB0aGUgc2Vz
c2lvbiBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFpbnMgdGhlIG92ZXJsb2FkIHJlcG9ydC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyNDQwNjEiPlNvIHlvdXIgbm90ZSByZWdhcmRpbmcgdGhlIHJlcG9ydGluZyBub2RlIHRvIHRh
a2UgaW50byBhY2NvdW50IHRoZSBuZXR3b3JrIGRlcGxveW1lbnQgZXRjLiBpcyBub3QgMTAwJSBj
b3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5MZXQgbWUgc2ltcGxpZnksIGhv
cGluZyBpdCB3aWxsIHNhdGlzZnkgeW91ciBjb25jZXJuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYm
cXVvdDsiPkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9h
ZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdA0KPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJp
ZiZxdW90Oztjb2xvcjpyZWQiPnRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgYWN0aXZl
IGluIHRoZSByZWFjdGluZyBub2RlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l
cyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KTm90ZSDigJMgSW4gc29tZSBjYXNlcywg
ZS5nLiB3aGVuIHRoZXJlIGFyZSBvbmUgb3IgbXVsdGlwbGUgYWdlbnRzIGluIHRoZSBwYXRoIGJl
dHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlczsgb3ZlcmxvYWQgcmVwb3J0cyBtYXkg
YmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5v
dCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZl
ZCB0aGUgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0
NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0
ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu
ZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJp
YSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTMs
IDIwMTQgMjozMSBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v
cmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhlbiB3ZSBhZ3JlZSBv
biB0aGUgcHJvcG9zZWQgdGV4dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BIHJlcG9ydGluZyBub2RlIE1VU1QgZW5z
dXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMu
PGJyPg0KPGJyPg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1
ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rp
bmcgbm9kZXMuJm5ic3A7DQo8YnI+DQo8YnI+DQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1h
eSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2Vu
dCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4mbmJzcDsg
VGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5v
ZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuPGJyPg0KPGJyPg0KQSByZXBvcnRpbmcgbm9k
ZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5n
IG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkg
aGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkJ1dCBzdGlsbCB0aGVyZSBhcmUgc29tZSBkaXNjcmVwYW5jaWVzIGFi
b3V0IHRoZSBub3RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBwcm9wb3NhbCBp
cyB0byBrZWVwIGl0IGp1c3QgYXMgYW4gaW5kaWNhdGlvbiBvZiBwb3RlbnRpYWwgKG1heWJlIG5v
dCBhbGwpIHNpdHVhdGlvbnMgdGhhdCBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50IGlmIGV2
ZXIgYW55IGltcGxlbWVudGF0aW9uIG1heSBjb25zaWRlcg0KIHRvIGRvIG5vdCBmb2xsb3cgdGhl
IHJlY29tbWVuZGF0aW9uIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJl
cG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5CZWluZyBhIHJlY29tbWVuZGF0aW9uIGFuZCBub3QgYSBtdXN0LCBhdCBsZWFzdCBJIHRo
aW5rIHdlIG5lZWQgdG8gaW5kaWNhdGUgd2hhdCBtYXkgaW1wbHkgdG8gZG8gbm90IGZvbGxvdyB0
aGUgcmVjb21tZW5kYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlbiBt
eSBwcm9wb3NhbCBpcyB0aGUgZm9sbG93aW5nLCB0aGF0IGluY2x1ZGVzIGEgbW9kaWZpY2F0aW9u
IHRvIGxhc3Qgc2VudGVuY2UgYWJvdmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSBy
ZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0
byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0DQo8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv
bG9yOnJlZCI+dGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJl
YWN0aW5nIG5vZGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpOb3RlIOKAk3RoZSByZXBvcnRpbmcgbm9kZSBtYXkgbmVl
ZCB0byB0YWtlIGludG8gYWNjb3VudCBuZXR3b3JrIGRlcGxveW1lbnQgYW5kIHBvdGVudGlhbCBl
cnJvcnMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCBzZW50IG92ZXJsb2Fk
IHJlcG9ydCBpcyBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUsIGUuZy4gdGhlcmUgbWF5IGJl
IG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcNCiBh
bmQgcmVhY3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSBy
ZWFjdGluZyBub2Rlc+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6D6FFxmbrcdx10ciscoc_--


From maria.cruz.bartolome@ericsson.com  Thu Feb 13 07:07:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8354D1A0209 for ; Thu, 13 Feb 2014 07:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I47Z4_-sLxSt for ; Thu, 13 Feb 2014 07:07:38 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDE1A02BC for ; Thu, 13 Feb 2014 07:07:35 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-5d-52fcdfb55774
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.92.04249.5BFDCF25; Thu, 13 Feb 2014 16:07:33 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 16:07:32 +0100
From: Maria Cruz Bartolome 
To: "Nirav Salot (nsalot)" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3y9MUP++VEyA/3yVOgA=
Date: Thu, 13 Feb 2014 15:07:32 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774E01@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209774C5E@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774E01ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje7W+3+CDNqnSFnM7V3BZvFsVYoD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAldF9YyJbwaFGpoo7L44xNTA++MXYxcjJISFg IjH1xixWCFtM4sK99WxdjFwcQgJHGCWW7b/HDuEsYZSYPfEHM0gVm4CdxKXTL5hAbBEBP4l5 PzaDdQsLlEu8vHSFGSJeIfF56yWomiYmib2/bEFsFgFVicYpp8DivAK+Em/7rjFCLNgnIHFh yT6gZg4OTqDEm2ZHkBpGoIu+n1oDVs8sIC5x68l8JohLBSSW7DnPDGGLSrx8/A/qAyWJRbc/ M4GMYRbIl9jf7QGxSlDi5MwnLBMYRWYhmTQLoWoWkiqIsKbE+l36ENWKElO6H7JD2BoSrXPm siOLL2BkX8XIUZxanJSbbmSwiREYOwe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MM4y88pQWc54z26ySoTX7bwO3yVbM1zdYg5c2jFpY5FyeDSn6ttJ 7AcerXvQs9B0udFE5wKrE0V7OhcVHJFnDL+SZMMt3dJ8dnl9/iyPmTZ7mFfpnZyUIKXYumL+ sVMzks5OvziZV7x8o4CjDWtlTIujuKaw3gzXKSUXEvYm2/I6SGixelx1VGIpzkg01GIuKk4E AL33IgBrAgAA
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 15:07:42 -0000

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

TmlyYXYsDQoNCkxldCBtZSBrbm93IGlmIGZvbGxvd2luZyByZXBocmFzaW5nIHN0aWxsIGNvbnZl
eXMgdGhlIG1lYW5pbmcgeW91IHdhbnQgdG8gY292ZXI6DQoNCk5vdGUg4oCTIEluIHNvbWUgY2Fz
ZXMgKGUuZy4gd2hlbiB0aGVyZSBhcmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0
aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXMsIG9yIHdoZW4gb3ZlcmxvYWQg
cmVwb3J0cyBhcmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzKSB0aGUgcmVwb3J0aW5nIG5v
ZGUgbWF5IG5vdCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhh
cyByZWNlaXZlZCB0aGUgcmVwb3J0Lg0KDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFtt
YWlsdG86bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IGp1ZXZlcywgMTMgZGUgZmVicmVybyBkZSAy
MDE0IDE1OjU2DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1Ympl
Y3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQpNYXJpYS1DcnV6LA0KDQpNYXkgYmUgZm9sbG93aW5nIGZvcm1hdHRpbmcgb2YgdGhlIG5vdGUg
aGVscHM/DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3Zlcmxv
YWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhp
cyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUu
DQoNCk5vdGUg4oCTIEluIHNvbWUgY2FzZXMgKGUuZy4gd2hlbiB0aGVyZSBhcmUgb25lIG9yIG11
bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcg
bm9kZXMsIG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rl
cykgdGhlIHJlcG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCB0
aGUgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9ydC4NCg0KUmVnYXJkcywNCk5p
cmF2Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywg
MjAxNCA2OjUwIFBNDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1
YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
Zw0KDQpOaXJhdiwNCg0KRG8geW91IGNvbnNpZGVyIHRoYXQgb3ZlcmxvYWQgcmVwb3J0cyBjYW4g
b25seSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMgd2hlbiB0aGVyZSBhcmUgYWdlbnRz
IGluIHRoZSBwYXRoPw0KDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNh
bG90QGNpc2NvLmNvbV0NClNlbnQ6IGp1ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDEzOjU4
DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0
Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1eiwNCg0KUmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5
IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFzIHBvaW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8gY29u
Y2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJlYWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4gYWxs
IHRoZSBpbnRyYS1zZXNzaW9uIG1lc3NhZ2VzIG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3Zl
cmxvYWQgcmVwb3J0LCBpZiB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFp
bnMgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0KU28geW91ciBub3RlIHJlZ2FyZGluZyB0aGUgcmVw
b3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIG5ldHdvcmsgZGVwbG95bWVudCBl
dGMuIGlzIG5vdCAxMDAlIGNvcnJlY3QuDQpMZXQgbWUgc2ltcGxpZnksIGhvcGluZyBpdCB3aWxs
IHNhdGlzZnkgeW91ciBjb25jZXJuLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8g
bm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4g
Z3VhcmFudGVlIHRoYXQgdGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4g
dGhlIHJlYWN0aW5nIG5vZGUuDQoNCk5vdGUg4oCTIEluIHNvbWUgY2FzZXMsIGUuZy4gd2hlbiB0
aGVyZSBhcmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9y
dGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRl
ZCBieSByZWFjdGluZyBub2RlcywgdGhlIHJlcG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0
byBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9y
dC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAxMywgMjAxNCAyOjMxIFBNDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpEZWFyIGFsbCwNCg0KSSB0aGluayB0aGVuIHdlIGFncmVl
IG9uIHRoZSBwcm9wb3NlZCB0ZXh0Og0KDQpBIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRo
YXQgYWxsIHJlYWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuDQoNCkl0
IGlzIHJlY29tbWVuZGVkIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJl
cG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIHJlYWN0aW5nIG5vZGVzLg0KDQpO
b3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJl
cG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhh
dCBpcyBtb3JlIGVmZmljaWVudC4gIFRoZSBvdmVybG9hZCByZXBvcnQgd2lsbCBqdXN0IGJlIGln
bm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBET0lDLg0KDQpB
IHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0
IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0KQnV0IHN0
aWxsIHRoZXJlIGFyZSBzb21lIGRpc2NyZXBhbmNpZXMgYWJvdXQgdGhlIG5vdGUuDQpNeSBwcm9w
b3NhbCBpcyB0byBrZWVwIGl0IGp1c3QgYXMgYW4gaW5kaWNhdGlvbiBvZiBwb3RlbnRpYWwgKG1h
eWJlIG5vdCBhbGwpIHNpdHVhdGlvbnMgdGhhdCBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50
IGlmIGV2ZXIgYW55IGltcGxlbWVudGF0aW9uIG1heSBjb25zaWRlciB0byBkbyBub3QgZm9sbG93
IHRoZSByZWNvbW1lbmRhdGlvbiB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9h
ZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMuDQpCZWluZyBhIHJlY29tbWVuZGF0aW9u
IGFuZCBub3QgYSBtdXN0LCBhdCBsZWFzdCBJIHRoaW5rIHdlIG5lZWQgdG8gaW5kaWNhdGUgd2hh
dCBtYXkgaW1wbHkgdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24uDQpUaGVuIG15
IHByb3Bvc2FsIGlzIHRoZSBmb2xsb3dpbmcsIHRoYXQgaW5jbHVkZXMgYSBtb2RpZmljYXRpb24g
dG8gbGFzdCBzZW50ZW5jZSBhYm92ZToNCg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRv
IG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2Fu
IGd1YXJhbnRlZSB0aGF0IHRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgYWN0aXZlIGlu
IHRoZSByZWFjdGluZyBub2RlLg0KDQpOb3RlIOKAk3RoZSByZXBvcnRpbmcgbm9kZSBtYXkgbmVl
ZCB0byB0YWtlIGludG8gYWNjb3VudCBuZXR3b3JrIGRlcGxveW1lbnQgYW5kIHBvdGVudGlhbCBl
cnJvcnMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCBzZW50IG92ZXJsb2Fk
IHJlcG9ydCBpcyBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUsIGUuZy4gdGhlcmUgbWF5IGJl
IG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5k
IHJlYWN0aW5nIG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVh
Y3Rpbmcgbm9kZXPigKYNCg0KDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6
MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl
dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0K
CXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZh
bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLlByZm9ybWF0SFRNTCwgbGkuUHJmb3Jt
YXRIVE1MLCBkaXYuUHJmb3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg
SFRNTCI7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2lu
OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
VGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs
ZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9
DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJ
e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0
ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpz
cGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N
CnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls
U3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzQNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM1DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s
b3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUzNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMzcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h
aWxTdHlsZTM4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUzOQ0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3
MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5O
aXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkxldCBtZSBrbm93IGlmIGZvbGxvd2luZyByZXBocmFzaW5nIHN0aWxs
IGNvbnZleXMgdGhlIG1lYW5pbmcgeW91IHdhbnQgdG8gY292ZXI6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtz
ZXJpZiZxdW90OyI+Tm90ZSDigJMgSW4gc29tZSBjYXNlcyAoZS5nLiB3aGVuIHRoZXJlIGFyZSBv
bmUgb3IgbXVsdGlwbGUgYWdlbnRzIGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCBy
ZWFjdGluZyBub2RlcywNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt
ZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5vciB3aGVuIDwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi
Pm92ZXJsb2FkIHJlcG9ydHMNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5hcmUgPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+
ZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5vdCBi
ZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCB0
aGUgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gTmlyYXYgU2Fsb3Qg
KG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGp1
ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDE1OjU2PGJyPg0KPGI+VG86PC9iPiBNYXJpYSBD
cnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzI0NDA2MSI+TWFyaWEtQ3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0
NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk1heSBiZSBmb2xsb3dp
bmcgZm9ybWF0dGluZyBvZiB0aGUgbm90ZSBoZWxwcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMm
cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBu
b3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBn
dWFyYW50ZWUgdGhhdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l
cyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPnRoaXMgb3ZlcmxvYWQgcmVwb3J0
IGlzIGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KTm90ZSDi
gJMgSW4gc29tZSBjYXNlcyAoZS5nLiB3aGVuIHRoZXJlIGFyZSBvbmUgb3IgbXVsdGlwbGUgYWdl
bnRzIGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlcywgb3Zl
cmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzKSB0aGUgcmVw
b3J0aW5nIG5vZGUgbWF5IG5vdCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGlu
ZyBub2RlIGhhcyByZWNlaXZlZCB0aGUgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVnYXJkcyw8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQw
NjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g
MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g
QmVoYWxmIE9mIDwvYj5NYXJpYSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy
c2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNjo1MCBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0i
bWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8
L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvIHlvdSBj
b25zaWRlciB0aGF0IG92ZXJsb2FkIHJlcG9ydHMgY2FuIG9ubHkgYmUgZGlzY2FyZGVkIGJ5IHJl
YWN0aW5nIG5vZGVzIHdoZW4gdGhlcmUgYXJlIGFnZW50cyBpbiB0aGUgcGF0aD88bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJt
YWlsdG86bnNhbG90QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XQ0KPGJy
Pg0KPGI+U2VudDo8L2I+IGp1ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDEzOjU4PGJyPg0K
PGI+VG86PC9iPiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0
Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMjQ0MDYxIj5NYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYx
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVwb3J0aW5nIG5vdGUgbWF5
IHVzZSB2ZXJ5IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFzIHBvaW50ZWQgb3V0IGJ5IExpb25lbCDi
gJMgdG8gY29uY2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJlYWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUs
IGkuZS4gYWxsIHRoZSBpbnRyYS1zZXNzaW9uDQogbWVzc2FnZXMgbmVlZCBub3QgY29udGFpbiB0
aGUgc2FtZSBvdmVybG9hZCByZXBvcnQsIGlmIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgbWVz
c2FnZSBjb250YWlucyB0aGUgb3ZlcmxvYWQgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+U28geW91ciBub3Rl
IHJlZ2FyZGluZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIG5l
dHdvcmsgZGVwbG95bWVudCBldGMuIGlzIG5vdCAxMDAlIGNvcnJlY3QuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMyNDQwNjEiPkxldCBtZSBzaW1wbGlmeSwgaG9waW5nIGl0IHdpbGwgc2F0aXNmeSB5
b3VyIGNvbmNlcm4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSByZXBvcnRpbmcgbm9k
ZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5n
IG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+dGhp
cyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGU8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3Nl
cmlmJnF1b3Q7Ij4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1
b3Q7Ij48YnI+DQpOb3RlIOKAkyBJbiBzb21lIGNhc2VzLCBlLmcuIHdoZW4gdGhlcmUgYXJlIG9u
ZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJl
YWN0aW5nIG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rp
bmcgbm9kZXMsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVl
IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBvcnQuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYx
Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJl
Zj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmlhIENydXogQmFydG9sb21lPGJyPg0K
PGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAyOjMxIFBNPGJyPg0KPGI+
VG86PC9iPiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxs
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+SSB0aGluayB0aGVuIHdlIGFncmVlIG9uIHRoZSBwcm9wb3NlZCB0ZXh0Ojxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2Vy
aWYmcXVvdDsiPkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcg
bm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy48YnI+DQo8YnI+DQpJdCBpcyByZWNv
bW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGlu
IGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4mbmJzcDsNCjxicj4N
Cjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3Zl
cmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2Rl
cyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNwOyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdp
bGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBv
cnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNl
bmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFu
dGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJs
b2FkIHJlcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90
O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHN0
aWxsIHRoZXJlIGFyZSBzb21lIGRpc2NyZXBhbmNpZXMgYWJvdXQgdGhlIG5vdGUuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHByb3Bvc2FsIGlzIHRvIGtlZXAgaXQganVzdCBhcyBh
biBpbmRpY2F0aW9uIG9mIHBvdGVudGlhbCAobWF5YmUgbm90IGFsbCkgc2l0dWF0aW9ucyB0aGF0
IHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgaWYgZXZlciBhbnkgaW1wbGVtZW50YXRpb24g
bWF5IGNvbnNpZGVyDQogdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24gdGhhdCBh
IHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1l
c3NhZ2VzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlaW5nIGEgcmVjb21tZW5k
YXRpb24gYW5kIG5vdCBhIG11c3QsIGF0IGxlYXN0IEkgdGhpbmsgd2UgbmVlZCB0byBpbmRpY2F0
ZSB3aGF0IG1heSBpbXBseSB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbi4NCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVuIG15IHByb3Bvc2FsIGlzIHRoZSBmb2xs
b3dpbmcsIHRoYXQgaW5jbHVkZXMgYSBtb2RpZmljYXRpb24gdG8gbGFzdCBzZW50ZW5jZSBhYm92
ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BIHJlcG9ydGluZyBub2RlIE1BWSBjaG9v
c2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBp
dCBjYW4gZ3VhcmFudGVlIHRoYXQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj50aGlzIG92ZXJsb2Fk
IHJlcG9ydCBpcyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZTwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi
Pi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4N
Ck5vdGUg4oCTdGhlIHJlcG9ydGluZyBub2RlIG1heSBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50
IG5ldHdvcmsgZGVwbG95bWVudCBhbmQgcG90ZW50aWFsIGVycm9ycyBpbiBvcmRlciB0byBiZSBh
YmxlIHRvIGd1YXJhbnRlZSB0aGF0IHNlbnQgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSBpbiB0
aGUgcmVhY3Rpbmcgbm9kZSwgZS5nLiB0aGVyZSBtYXkgYmUgb25lIG9yIG11bHRpcGxlIGFnZW50
cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZw0KIGFuZCByZWFjdGluZyBub2Rlczsgb3Zl
cmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVz4oCmPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_087A34937E64E74E848732CFF8354B9209774E01ESESSMB101erics_--


From anders.askerup@hp.com  Thu Feb 13 07:20:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68921A02A3 for ; Thu, 13 Feb 2014 07:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level: 
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqHcgQGuvC3S for ; Thu, 13 Feb 2014 07:20:37 -0800 (PST)
Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id C460F1A01F7 for ; Thu, 13 Feb 2014 07:20:37 -0800 (PST)
Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 67E078040; Thu, 13 Feb 2014 15:20:36 +0000 (UTC)
Received: from G9W3611.americas.hpqcorp.net (16.216.186.46) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Feb 2014 15:19:32 +0000
Received: from G9W0747.americas.hpqcorp.net ([169.254.4.56]) by G9W3611.americas.hpqcorp.net ([16.216.186.46]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 15:19:32 +0000
From: "Askerup, Anders" 
To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] [dime] #38: Server Farm Definition Issue
Thread-Index: AQHPJk5fRafru9tHlEacmwX02VY39JqzUONA
Date: Thu, 13 Feb 2014 15:19:32 +0000
Message-ID: <602542051F40544EB188D494F506C2494792DEA2@G9W0747.americas.hpqcorp.net>
References: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> <213D2B01-4A4F-4C06-9272-B93D98F629BC@gmail.com>
In-Reply-To: <213D2B01-4A4F-4C06-9272-B93D98F629BC@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.210.48.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 15:20:41 -0000

In addition, there is no such thing as Destination-Server AVP :)
Destination-Server -> Destination-Host
/Anders

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Monday, February 10, 2014 4:53 AM
To: dime@ietf.org
Cc: ben@nostrum.com; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue


Good point. I would clarify that a server farm could mean both: one with
a single identity and one with multiple identities. The selection is=20
implementation and deployment specific.

- Jouni


On Feb 7, 2014, at 10:37 PM, dime issue tracker  wrote:

> #38: Server Farm Definition Issue
>=20
> A "server farm" is defined as "A set of Diameter servers that can handle
> any request for a given set of Diameter applications.". This is not
> strictly true. For example, if a request includes a Destination-Server
> AVP, then then in general only that particular server in the farm can
> handle the request.
>=20
> I assume that we don't mean to limit the server farm concept to situation=
s
> where the entire farm is known by a single Diameter-Identity, do we?
>=20
> --=20
> -------------------------+-----------------------------------------------=
--
> Reporter:               |      Owner:  draft-docdt-dime-
>  ben@nostrum.com        |  ovli@tools.ietf.org
>     Type:  defect       |     Status:  new
> Priority:  minor        |  Milestone:
> Component:  draft-       |    Version:  1.0
>  docdt-dime-ovli        |   Keywords:
> Severity:  Active WG    |
>  Document               |
> -------------------------+-----------------------------------------------=
--
>=20
> Ticket URL: 
> dime 
>=20

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


From maria.cruz.bartolome@ericsson.com  Thu Feb 13 05:18:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FFC1A0237 for ; Thu, 13 Feb 2014 05:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0DiJ6V5RlGc for ; Thu, 13 Feb 2014 05:18:04 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A1FE31A0234 for ; Thu, 13 Feb 2014 05:18:02 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-d9-52fcc608ba36
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9F.F0.23809.806CCF25; Thu, 13 Feb 2014 14:18:00 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 14:18:00 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+NA=
Date: Thu, 13 Feb 2014 13:17:58 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774C42@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774C42ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+JvjS7HsT9BBqcfKVnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAPLPrEUNJzhrmjsWMXUwPhkKXcXIyeHhICJxP7jV1khbDGJ C/fWs3UxcnEICRxilJj5fC87SEJIYAmjxMq9zCA2m4CdxKXTL5i6GDk4RASUJU7/cgAJCwuU S7y8dAWsRESgQuLz1ktMIHNEBN4xSnSvXcEEkmARUJW4MusMWBGvgK/EqgMNjBDLtvFLrHi8 CqyIEyixYO4fNhCbEeii76fWgMWZBcQlbj2ZzwRxqYDEkj3nmSFsUYmXj/9BfaAksej2Z6j6 fIlj+z6xQSwTlDg58wnLBEaRWUhGzUJSNgtJ2Syg35gFNCXW79KHKFGUmNL9kB3C1pBonTOX HVl8ASP7Kkb23MTMnPRyo02MwFg5uOW36g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBa FF9UmpNafIiRiYNTqoGxXfjAVLmXiyU5lUQM1l37UdlW1X8tpl3nefXbVWu+WZ7tlfGa225w 5HeKjxO3s4v8x1b5A0ZBrle9/vTmHDigc00sXKypRvxbQe2tqCl3/++ze3yS43pG3/9I5umd 1jtqLkeXb2H6vueeSOIZ+5+XT35qWbOOy2rGhqBtnl++GIrwrJxYcnO1EktxRqKhFnNRcSIA xKXbZmMCAAA=
X-Mailman-Approved-At: Thu, 13 Feb 2014 08:03:21 -0800
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 13:18:13 -0000

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

TmlyYXYsDQoNCkRvIHlvdSBjb25zaWRlciB0aGF0IG92ZXJsb2FkIHJlcG9ydHMgY2FuIG9ubHkg
YmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzIHdoZW4gdGhlcmUgYXJlIGFnZW50cyBpbiB0
aGUgcGF0aD8NCg0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBj
aXNjby5jb21dDQpTZW50OiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAxNCAxMzo1OA0KVG86
IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1eiwN
Cg0KUmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFzIHBv
aW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8gY29uY2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJlYWNo
ZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4gYWxsIHRoZSBpbnRyYS1zZXNzaW9uIG1lc3NhZ2Vz
IG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3ZlcmxvYWQgcmVwb3J0LCBpZiB0aGUgc2Vzc2lv
biBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFpbnMgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0K
U28geW91ciBub3RlIHJlZ2FyZGluZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRvIGFj
Y291bnQgdGhlIG5ldHdvcmsgZGVwbG95bWVudCBldGMuIGlzIG5vdCAxMDAlIGNvcnJlY3QuDQpM
ZXQgbWUgc2ltcGxpZnksIGhvcGluZyBpdCB3aWxsIHNhdGlzZnkgeW91ciBjb25jZXJuLg0KDQpB
IHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0
IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhpcyBvdmVybG9h
ZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUuDQoNCk5vdGUg
4oCTIEluIHNvbWUgY2FzZXMsIGUuZy4gd2hlbiB0aGVyZSBhcmUgb25lIG9yIG11bHRpcGxlIGFn
ZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7IG92
ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2RlcywgdGhlIHJl
cG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rp
bmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9ydC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpG
cm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFy
aWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAyOjMx
IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkRlYXIgYWxsLA0KDQpJIHRoaW5rIHRoZW4g
d2UgYWdyZWUgb24gdGhlIHByb3Bvc2VkIHRleHQ6DQoNCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBl
bnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0
cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3Zl
cmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9k
ZXMuDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3Zl
cmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2Rl
cyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1
c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERP
SUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9h
ZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGUg
cmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0K
DQpCdXQgc3RpbGwgdGhlcmUgYXJlIHNvbWUgZGlzY3JlcGFuY2llcyBhYm91dCB0aGUgbm90ZS4N
Ck15IHByb3Bvc2FsIGlzIHRvIGtlZXAgaXQganVzdCBhcyBhbiBpbmRpY2F0aW9uIG9mIHBvdGVu
dGlhbCAobWF5YmUgbm90IGFsbCkgc2l0dWF0aW9ucyB0aGF0IHNob3VsZCBiZSB0YWtlbiBpbnRv
IGFjY291bnQgaWYgZXZlciBhbnkgaW1wbGVtZW50YXRpb24gbWF5IGNvbnNpZGVyIHRvIGRvIG5v
dCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNsdWRl
IG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcy4NCkJlaW5nIGEgcmVjb21t
ZW5kYXRpb24gYW5kIG5vdCBhIG11c3QsIGF0IGxlYXN0IEkgdGhpbmsgd2UgbmVlZCB0byBpbmRp
Y2F0ZSB3aGF0IG1heSBpbXBseSB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbi4N
ClRoZW4gbXkgcHJvcG9zYWwgaXMgdGhlIGZvbGxvd2luZywgdGhhdCBpbmNsdWRlcyBhIG1vZGlm
aWNhdGlvbiB0byBsYXN0IHNlbnRlbmNlIGFib3ZlOg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBj
aG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBp
ZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBh
Y3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUuDQoNCk5vdGUg4oCTdGhlIHJlcG9ydGluZyBub2Rl
IG1heSBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50IG5ldHdvcmsgZGVwbG95bWVudCBhbmQgcG90
ZW50aWFsIGVycm9ycyBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHNlbnQg
b3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSwgZS5nLiB0aGVy
ZSBtYXkgYmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9y
dGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRl
ZCBieSByZWFjdGluZyBub2Rlc+KApg0KDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFD
UVVFUykNClNlbnQ6IG1pw6lyY29sZXMsIDEyIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToxMw0KVG86
IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSGkNCg0KT24gdGhp
cyB0b3BpYywgbXkgdmlldyBpcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIHNoYWxsICByZWNlaXZl
IOKAnGVub3VnaOKAnSBPTFJzIHBlciBwZXJpb2Qgb2YgdGltZSB0byBlbnN1cmUgdGhlIGVmZmlj
aWVuY3kgb2YgdGhlIHRyYWZmaWMgIHJlZHVjdGlvbiBtZWNoYW5pc20gLiBBIHdheSB0byBhY2hp
ZXZlICB0aGUg4oCcZW5vdWdo4oCdIGlzIHRvIGhhdmUgYW4gT0xSIGluIGFsbCAgYW5zd2VyICBt
ZXNzYWdlcyBhcyBwcm9wb3NlZCBhbmQgdGhpcyBjYW4gdGhlIHJlY29tbWVuZGVkIHdheS4gTm93
IGFzIE5pcmF2IHNhaWQsIHRoZXJlIG1heSBiZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3aWxsIGJl
aGF2ZSBkaWZmZXJlbnRseSBhbmQgc2VuZCDigJxlbm91Z2jigJ0gT0xScyAgYnV0IG5vdCBpbiBh
bGwgbWVzc2FnZXMuDQoNCkFzIGFsc28gTmlyYXYgbm90ZWQsICBJIGRvIG5vdCB3ZWxsIHNlZSB0
aGUgbmVlZCB0byB3cml0ZSBhZGRpdGlvbmFsIG5vdGVzIGFzIG1hbnkgc2l0dWF0aW9ucyBjYW4g
b2NjdXIgYW5kICBhcmUgbm90IGxpbWl0ZWQgdG8gdGhlIGV4YW1wbGUgb2YgdGhlIHJlYWN0aW5n
ICBub2RlICBkaXNjYXJkaW5nIE9MUnMuDQoNCkJlc3QgcmVnYXJkcw0KDQpKSmFjcXVlcw0KDQoN
Cg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl
IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
Pg0KRW52b3nDqSA6IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTY6MzUNCsOAIDogTWFyaWEgQ3J1
eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6
IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpB
dCBsZWFzdCwgaXQgaXMgY29ycmVjdCEg4pi6DQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KRW52b3nD
qSA6IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTU6MDANCsOAIDogZGltZUBpZXRmLm9yZzxtYWls
dG86ZGltZUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkxpb25lbCwgTmlyYXYsIGFsbCwNCg0KTWF5YmUgdGhl
IG5vdGUgY291bGQgYmUgbW9kaWZpZWQ6DQoNCk5vdGUg4oCTdGhlIHJlYWN0aW5nIG5vZGUgY291
bGQgYmUgYW55IGFnZW50IGluIHRoZSBwYXRoLCBhbmQgdGhhdCBpbiBzb21lIGVycm9yIHNpdHVh
dGlvbnMgb3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVz
Lg0KDQpJIGFkZGVkIHRoZSBjYXNlIE9MUiBjb3VsZCBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcg
bm9kZXMsIHNpbmNlIGl0IGhpZ2hsaWdodHMgYSBzaXR1YXRpb24gd2hlcmUgdGhlIHNlcnZlciB3
aWxsIG5vdCBrbm93IHdoZXRoZXIgb3Igbm90IGEgdmFsaWQgT0xSIGlzIHJlY2VpdmVkIGJ5IHJl
YWN0aW5nIG5vZGUuDQoNCkJlc3QgcmVnYXJkcw0KL01DcnV6DQoNCg0KRnJvbTogbGlvbmVsLm1v
cmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+IFttYWlsdG86
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tXQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRl
IDIwMTQgMTE6MzYNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxtYWls
dG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBdCBsZWFzdCwgaXQgaXMgbm90ICJ0aGUgb25seSBz
dXJlIHdheSIuDQpGb3IgaW5zdGFuY2UsIHN1YnNlcXVlbnQgbWVzc2FnZXMgcGFydCBvZiB0aGUg
c2FtZSBzZXNzaW9uIChvciBwc2V1ZG8tc2Vzc2lvbikgY291bGQgYWxzbyBiZSB1c2VkIGFzIGlu
ZGljYXRpb24gZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0aGF0IHRoZSBPTFIgaGFzIGJlZW4gcmVj
ZWl2ZWQgYnkgdGhlIHJlYWN0aW5nIG5vZGUgKGJlc2lkZXMgdGhlIHJlY2VwdGlvbiBvZiB0aGUg
T0MtU3VwcG9ydGVkLUZlYXR1cmVzIGluIHRoZSByZXF1ZXN0KS4NCkl0IGlzIHdoeSBJIHdhcyBz
YXlpbmcgdGhhdCB0aGlzIGNhbiBiZSBmaXhlZCBwZXIgYXBwbGljYXRpb24vc3lzdGVtLg0KDQpM
aW9uZWwNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw
YXJ0IGRlIE1hcmlhIENydXogQmFydG9sb21lDQpFbnZvecOpIDogbWFyZGkgMTEgZsOpdnJpZXIg
MjAxNCAxMTozMQ0Kw4AgOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KT2Jq
ZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN
Cg0KRmluZSBOaXJhdiwgSSBhZ3JlZSB0aGlzIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLg0K
TXkgaW50ZW50aW9uIGlzIHRoYXQgYW55IHJlYWRlciByZWFsaXplcyB3aGF0IHRoaXMga25vd2xl
ZGdlIGluIHRoZSBzZXJ2ZXIgaW1wbGllcyB3aGVuIHdlIHRhbGsgYWJvdXQgYWdlbnRzIGluIHRo
ZSBwYXRoLiBUaGlzIGlzIHdoeSBJIHRoaW5rIHRoaXMgbm90ZSBpcyBoZWxwZnVsLg0KDQpSZWdh
cmRzDQovTUNydXoNCg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RA
Y2lzY28uY29tXQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjYNClRv
OiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9y
Zz4NClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRo
cm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhy
b3R0bGluZw0KDQpJIGRvIG5vdCBhZ3JlZSByZWdhcmRpbmcgdGhlIGNvbXBsZXhpdHkgc2luY2Ug
aXQgaXMgaGlnaGx5IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLg0KTGV0cyBub3QgbWFrZSBhbnkg
YXNzdW1wdGlvbiBpbiB0aGUgcHJvdG9jb2wgZGVzaWduLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoN
CkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN
YXJpYSBDcnV6IEJhcnRvbG9tZQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMTQgMzo1
NCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS
ZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSGVs
bG8sDQoNCkkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGhpZ2hsaWdodCBjb21wbGV4aXR5IGZv
ciB0aGUgc2VydmVyIHRvICDigJxndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJl
YWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0LuKAnQ0KSSB0aGluayB0aGlzIGlz
IHRoZSBwdXJwb3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRlZCBieSBTdGV2ZS4NCg0KQ2hlZXJzDQov
TUNydXoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8g
ZGUgMjAxNCAxMToyMA0KVG86IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tPjsgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJIGFtIGFsc28gZmluZSB3aXRoIFN0ZXZlJ3MgcHJvcG9z
ZWQgd29yZGluZyB0byByZWNvbW1lbmQgdGhlIGluY2x1c2lvbiBvZiBPTFIgYnV0IHRvIG5vdCBt
YW5kYXRlIGl0Lg0KDQpJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBmb2xsb3dpbmcgdGV4dCwgaWYg
aXQgaXMgYWJzb2x1dGVseSBuZWNlc3NhcnkgdG8gYWRkIGl0Lg0KTm90ZSAtIHRoZSBvbmx5IHN1
cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJl
YWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSBy
ZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRo
ZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcgbm9kZS4NCg0KSSBwcmVmZXIgdG8gcmVtb3ZlIGl0
IHNpbmNlIEkgZG8gbm90IHNlZSBhcyB2YWx1ZSBhZGRpdGlvbi4NCg0KUmVnYXJkcywNCk5pcmF2
Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j
b20+DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEwOjEzIFBNDQpUbzogU3RldmUg
RG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl
OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJJ20g
ZmluZSB3aXRoIGEgcmVjb21tZW5kYXRpb24uDQoNCkJ1dCBJIGhhdmUgYSBnZW5lcmFsIGNvbW1l
bnQ6IHdoZW4gYSBNQVkgb3IgZXZlbiBhIFNIT1VMRCBhcHBseSwgaXQgZG9lcyBub3QgbWVhbiB0
aGF0IGl0IGlzIE5PVCB1cCB0byB0aGUgbm9kZSB0byBkbyBvciBub3QgdG8gZG8gc29tZXRoaW5n
LiBJdCBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRp
b24uDQpGb3IgaW5zdGFuY2UsIG92ZXIgYSBnaXZlbiBpbnRlcmZhY2UsIHRoZSByZWxhdGVkIHNw
ZWNpZmljYXRpb24gY2FuIHNheSB0aGF0IHNvbWUgc3RhdGVzIGFyZSBtYWludGFpbmVkIGJ5IHRo
ZSBzZXJ2ZXIuIEFuZCBpdCBjb3VsZCBiZSBkZWNpZGVkIHRvIGFkZCBzb21lIG92ZXJsb2FkIHJl
bGF0ZWQgaW5mbyBpbiBzdWNoIHN0YXRlcy4gRm9yIGluc3RhbmNlIGFnYWluLCB0aGUgbm9kZSBj
YW4gdXNlIHRoaXMgc3RhdGUgdG8ga25vdyBpZiBhIHJlbW90ZSBub2RlIGhhdmUgYmVlbiBub3Rp
ZmllZCBvciBub3QgZm9yIGluc3RhbmNlLiBBbmQgaW4gc3VjaCBhIGNhc2UsIHRoZSBzZXJ2ZXIg
ZG9lcyBub3QgbmVlZCB0byBpbmNsdWRlIGFuIE9MUiBpbiBlYWNoIG1lc3NhZ2UuIEl0IGlzIGp1
c3QgZm9yIGlsbHVzdHJhdGlvbi4gVGhlIHBvaW50IGlzIHRoYXQgeW91IG1heSBoYXZlIHNvbWUg
Y2FzZXMgZm9yIHdoaWNoIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1pZ2h0IG5vdCBiZSByZXF1
aXJlZC4NCg0KSSBhZ3JlZSB0aGF0IGhhdmluZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBm
aW5l4oCmIGJ1dCBpdCBzaG91bGQgYmUgbm90IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGlu
ay4gU28gT0sgZm9yIGEgIlNIT1VMRCIgb3IgIlJFQ09NTUVOREVEIi4NCg0KUmVnYXJkcywNCg0K
TGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg
cGFydCBkZSBTdGV2ZSBEb25vdmFuDQpFbnZvecOpIDogbHVuZGkgMTAgZsOpdnJpZXIgMjAxNCAx
NzoyMQ0Kw4AgOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KT2JqZXQgOiBS
ZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8g
QVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBh
Z3JlZSB3aXRoIGJvdGggTWFyaWEgQ3J1eiBhbmQgTmlyYXYuIDotKQ0KDQpJIHN1Z2dlc3QgdGhh
dCB3ZSBoYXZlIHdvcmRpbmcgc2F5aW5nIHRoZSByZWNvbW1lbmRlZCBhcHByb2FjaCBpcyB0byBp
bmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0
aGUgcmVhc29ucyBsaXN0ZWQgYnkgTWFyaWEgQ3J1ei4NCg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCB3
ZSBpbmNsdWRlIE5pcmF2J3MgcHJvcG9zYWwgdGhhdCBpZiBhIHJlcG9ydGluZyBub2RlIGtub3dz
IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJl
cG9ydCB0aGVuIGl0IG1heSBjaG9vc2UgdG8gbm90IHNlbmQgaXQgYWdhaW4uICBJIGRvbid0IHRo
aW5rIHdlIG5lZWQgdG8gaW5jbHVkaW5nIGFueXRoaW5nIGFib3V0IGhvdyB0aGUgcmVwb3J0aW5n
IG5vZGUga25vd3MgYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29ya3Mg
YXJjaGl0ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuICBUaGUgY2FzZSBv
ZiBhZ2VudHMgYWN0aW5nIGFzIHJlYWN0aW5nIG5vZGVzIGZvciBub24gc3VwcG9ydGluZyBjbGll
bnRzIGJlaW5nIG9uZSBleGFtcGxlLg0KDQpXZSBhbHNvIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQg
dGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIG5vdCBwcmVjbHVkZWQgYnkgTmlyYXYncyBwcm9w
b3NhbC4NCg0KSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgbm9ybWF0aXZlIHdvcmRpbmcsIHdoaWNo
IGNhbiBiZSBzdXBwbGVtZW50ZWQgYnkgTWFyaWEgQ3J1eidzIHJlYXNvbnMgZm9yIHJlY29tbWVu
ZGluZyB0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWx3YXlzIGluY2x1ZGVkLg0KDQotLS0t
LQ0KDQpBIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5nIG5vZGVz
IHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuDQoNCkl0IGlzIHJlY29tbWVuZGVkIHRoYXQg
YSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBt
ZXNzYWdlcyBzZW50IHRvIHJlYWN0aW5nIG5vZGVzLg0KDQpOb3RlIC0gdGhlIHJlcG9ydGluZyBu
b2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2Fn
ZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4g
IFRoZSBvdmVybG9hZCByZXBvcnQgd2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBu
b2RlIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBj
aG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBp
ZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVj
ZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0KTm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3
aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5v
ZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBu
b2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQg
YW5kIHRoZSByZXBvcnRpbmcgbm9kZS4NCk9uIDIvMTAvMTQgMzo1MiBBTSwgTWFyaWEgQ3J1eiBC
YXJ0b2xvbWUgd3JvdGU6DQoNCkhlbGxvIE5pcmF2LA0KDQoNCg0KQW55IHNvbHV0aW9uIHNob3Vs
ZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2llbmN5IGNvdWxkIGJlIGRpc2N1c3Nl
ZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBmaXJzdCB3ZSBuZWVkIHRvIGFzc3Vy
ZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBwcm92aWRpbmcgdmFsaWQgT0xSIHRv
IHJlYWN0aW5nIG5vZGVzLg0KDQoNCg0KWW91ciBwcm9wb3NlZCB0ZXh0DQoNCiIgQWRkaXRpb25h
bGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qg
YXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSBy
ZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0
aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQLiINCg0KDQoNCklmIHRoZSByZXBvcnRpbmcgaXMgbm90IGF3YXJlIGFib3V0IHdoZXRo
ZXIgb3Igbm90IG92ZXJsb2FkIHJlcG9ydCBpcyBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9k
ZSwgYW5kIGl0IGRlY2lkZXMgKHNpbmNlIGl0IGlzIGEgIm1heSIpIHRvIGRvIG5vdCBzZW5kIHRo
ZSBPTFIgYWdhaW4sIHRoZW4gb3ZlcmxvYWQgbWl0aWdhdGlvbiBtZWNoYW5pc20gd2lsbCBub3Qg
d29yayBpbiBjYXNlIE9MUiB3YXMgbm90IHByb3Blcmx5IHJlY2VpdmVkIGJ5IGNvcnJlc3BvbmRp
bmcgcG90ZW50aWFsIHJlYWN0aW5nIG5vZGVzLiBBbmQgd2UgbmVlZCB0byBub3RlIHRoYXQgInJl
YWN0aW5nIG5vZGVzIiBjb3VsZCBiZSBub3Qgb25seSB0aGUgY2xpZW50LCBidXQgQU5ZIGFnZW50
IHVzZWQgZm9yIHJvdXRpbmcgKG5vdCBvbmx5IHdoZW4gdGhlIGFnZW50IGlzIHByb3ZpZGluZyBz
ZXJ2aWNlIHRvIGEgUmVhbG0sIGJ1dCB3aGVuIGl0IGlzIHJlYWN0aW5nIG9uIGJlaGFsZiBvZiBh
IG5vbi1zdXBwb3J0aW5nIGNsaWVudCkuDQoNClRoZW4sIG9uIG9uZSBoYW5kIGl0IGlzIG5vdCBz
aW1wbGUgdG8ga25vdyB3aGVuIHJlYWN0aW5nIG5vZGVzIGhhdmUgdmFsaWQgT0xSIGluZm8gKGFz
IGV4cGxhaW5lZCBiZWxvdyksIGJ1dCBpZiBPTFIgaXMgbm90IHNlbnQgYWdhaW4gKGFzIHBlciB5
b3VyIHByb3Bvc2VkICJtYXkiKSB0aGVuIG9uZSBvciBtdWx0aXBsZSByZWFjdGluZyBub2RlcyBk
byBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gd2ls
bCBub3Qgd29yay4NCg0KDQoNClRoZXJlZm9yZSwgaW4gbXkgb3BpbmlvbiwgdGhlIHNpbXBsZXN0
IHdheSB0byBwcm92aWRlIHJlcXVpcmVkIGluZm9ybWF0aW9uIGlzIHRvIHByb3ZpZGUgT0xSIGlu
IEFMTCBhbnN3ZXJzLg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCi9NQ3J1eg0KDQoNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0
bzpuc2Fsb3RAY2lzY28uY29tXQ0KDQpTZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0
IDEwOjQyDQoNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQpCdXQgTWFyaWEtQ3J1eiwNCg0KDQoNCkhvdyBj
YW4gd2Ugc2F5IHRoYXQgImluY2x1ZGluZyB0aGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3Nh
Z2VzIGlzIHNpbXBsZSBhbmQgZWZmaWNpZW50PyINCg0KSXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1
dCBub3QgZWZmaWNpZW50Lg0KDQoNCg0KQSBzbGlnaHRseSBkaWZmZXJlbnQgd29yZGluZyBmcm9t
IHdoYXQgSSBwcm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBoYXMg
YSBuZXcgb3ZlcmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gYSByZWFj
dGluZyBub2RlIChieSB1cGRhdGluZyB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBv
cnQgb3IgYnkgcHJvdmlkaW5nIHRoZSBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1l
KSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBj
b250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9u
ZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdo
ZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0
IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcg
bm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3Qg
Y29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCg0KDQpSZWdhcmRzLA0KDQpO
aXJhdi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRv
bG9tZQ0KDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDM6MDMgUE0NCg0KVG86IGRp
bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KTmlyYXYsIGFs
bCwNCg0KDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGRlZmluZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0
IHNvbHV0aW9uLCBhcyBlZmZpY2llbnQgYW5kIHNpbXBsZSBhcyBwb3NzaWJsZS4NCg0KSSB1bmRl
cnN0YW5kIHlvdXIgcHJvcG9zYWwgYXMgYSBwdXJlICJtYXkiLCBidXQgbGVhdmluZyBpdCB1cCB0
byBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBhc3N1cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQg
T0xSIGluZm9ybWF0aW9uLCB3aGF0IGlzIGJhc2ljIGZvciB0aGlzIG1lY2hhbmlzbSB0byB3b3Jr
Lg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCi9NQ3J1eg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lz
Y28uY29tXQ0KDQpTZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyDQoNClRv
OiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9y
Zz4NCg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCg0KDQpNYXJpYS1DcnV6LA0KDQoNCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlv
dSBvbiAic2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFu
dGFnZXMiLg0KDQpBbmQgd2UgYXJlIG5vdCB0cnlpbmcgdG8gcHJldmVudCBpdCAtIGF0IGxlYXN0
IHRoYXQgaXMgbXkgaW50ZW50aW9uLg0KDQpCdXQgdGhlIG1haW4gcXVlc3Rpb24gaXMsIGFyZSB3
ZSB0cnlpbmcgdG8gcHJldmVudCBhbnkgb3RoZXIgcG9zc2libGUgaW1wbGVtZW50YXRpb24sIHdo
aWNoIG1heSBiZSBzbWFydGVyIGFuZCBjYW4gYXZvaWQgaW5jbHVkaW5nIHJlZHVuZGFudCBPTFIg
aW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZT8NCg0KDQoNCk1vc3QgcHJvYmFibHksIHRoZSB2ZXJ5
IGZpcnN0IGltcGxlbWVudGF0aW9uIG9mIG92ZXJsb2FkIGNvbnRyb2wgd2lsbCBpbmNsdWRlIE9M
UiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcy4NCg0KQnV0IGF0IHRoZSBzYW1lIHRpbWUsIEkg
ZG8gbm90IHdhbnQgdG8gcmVzdHJpY3QgdGhlIGRldmVsb3BlcnMgd2hpY2ggY2FuIGNvbWUgdXAg
d2l0aCBzb21lIG5pY2UgdHdlYWtzIGFuZCB0cmlja3MgdG8gYXZvaWQgc2VuZGluZyB0aGUgc2Ft
ZSBpbmZvcm1hdGlvbiBpbiBldmVyeSBtZXNzYWdlLiBBbmQgdGhpcyBpcyB3aGVyZSB3ZSBuZWVk
IHRvIGJlIGNhcmVmdWwgYW5kIGF2b2lkIHB1dHRpbmcgc3VjaCByZXN0cmljdGlvbnMgaW4gcHJv
dG9jb2wgZGVmaW5pdGlvbi4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCg0KDQpUaGlzIGFsc28g
dGhlIHJlYXNvbiBJIHdhcyBzdWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8g
aW5jbHVkZSBPTFIgKGZyb20gdGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLg0KDQoN
Cg0KUmVnYXJkcywNCg0KTmlyYXYuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
DQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
TWFyaWEgQ3J1eiBCYXJ0b2xvbWUNCg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAwNywgMjAxNCA4
OjU3IFBNDQoNClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJq
ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN
Cg0KDQoNCkhlbGxvIFVscmljaCwgTmlyYXYsDQoNCg0KDQpJIGFncmVlIHdpdGggVWxyaWNoIHRo
YXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1BWSwgYW5kIHdoZXRoZXIg
b3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNoYWxsIG5vdCBi
ZSBqdXN0IGEgTUFZLg0KDQoNCg0KT24gdGhlIG90aGVyIGhhbmQsIGNyaXRlcmlhIHByb3ZpZGVk
IGJ5IFVscmljaCBvbiB3aGVuIE9MUiBoYXMgdG8gYmUgc2VudCByZXF1aXJlcyB0aGUgc2VydmVy
IGhhcyBzb21lIGtub3dsZWRnZToNCg0KYSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQoNCmIpIHRo
ZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEg
dGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBP
TFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlDQoNCmMpIG90aGVyd2lzZQ0KDQoNCg0KUmVwb3J0aW5n
IG5vZGUgbXVzdCBoYXZlIHNvbWUga25vd2xlZGdlIGFib3V0IE9MUiByZWNlcHRpb24vc3RhdHVz
IGluIHJlYWN0aW5nIG5vZGUuIEhvdyBkb2VzIHNlcnZlciBhY3F1aXJlIHRoaXMga25vd2xlZGdl
Pw0KDQpUYWtlIGludG8gYWNjb3VudCBhcyB3ZWxsIHRoYXQgYSAicmVhY3RpbmciIG5vZGUgbWF5
IGJlIGJvdGggYW4gQWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMgc2VydmljZSB0byBhIHJlYWxt
IG9yIGFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpICBhbmQgYSBD
bGllbnQuIEluIHRoZSBjYXNlIG9mIEFnZW50cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3Qg
ZXZlbiBrbm93IGlmIHRoaXMgaXMgZ29pbmcgdG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBq
dXN0IHRyYW5zcGFyZW50bHksIGluIGZhY3QsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBo
YXZlIGFueSBrbm93bGVkZ2UgYWJvdXQgd2hhdCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBm
aW5hbCBDbGllbnQuDQoNCg0KDQpUaGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0aGluayB0aGF0IHNl
bmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzOg0K
DQotIHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRyYW5zYWN0aW9uIG9yIHNlc3Npb24pIGlz
IHNpbXBsZXIsDQoNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGRldGVybWluZSB3aGV0
aGVyIG9yIG5vdCB0byBzZW5kIGFuIE9MIHRvIGEgcmVhY3Rpbmcgbm9kZQ0KDQotIHRoZSBzZXJ2
ZXIgZG9lcyBub3QgbmVlZCB0byBib3RoZXIgd2hldGhlciBhbiByZWFjdGluZyBub2RlIGhhcyBh
bHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBvciB3aGV0aGVyIHRoaXMgT0xSIGlzIHN0aWxsIHZhbGlk
IChoYXMgbm90IGV4cGlyZWQpLg0KDQotIHNlbmRpbmcgYW4gYWRkaXRpb25hbCBBVlAgaXMgbm90
IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29uIHdpdGggcmVxdWlyZWQgYWJvdmUg
Y2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4NCg0KICBJbiBmYWN0LCBpbiBhbiBvdmVybG9h
ZCBzaXR1YXRpb24sIHRoZSBlYXNpZXN0IGFuZCBsZWFzdCBjb21wbGV4IGlzIHRvIHNlbmQgaW5m
b3JtYXRpb24gb3V0IHRvIGFsbCBhZmZlY3RlZC9hcHBsaWNhYmxlIG5vZGVzLA0KDQogIGFuZCB0
aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNhcmUgdG8gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb25zDQoN
Ci0gbW9yZSByb2J1c3Qgc29sdXRpb24sIGFzIG5vIG5lZWQgdG8gY2F0ZXIgZm9yIGFsbCB0aGUg
Y2hlY2tzIG9uIHRoZSBuZWVkIHRvIHNlbmQgaW5mb3JtYXRpb24sICBmb3Igc2l0dWF0aW9ucyB3
aGVyZSBhbiBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LCAg4oCmDQoNCg0KDQoNCg0KQmVzdCByZWdh
cmRzDQoNCi9NQ3J1eg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTog
RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpZWhlLCBV
bHJpY2ggKE5TTiAtIERFL011bmljaCkNCg0KU2VudDogdmllcm5lcywgMDcgZGUgZmVicmVybyBk
ZSAyMDE0IDEwOjU5DQoNClRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBsaW9uZWwu
bW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47IGV4dCBT
dGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJq
ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcN
Cg0KDQoNCk5pcmF2LA0KDQoNCg0KSSdtIGFmcmFpZCB5b3VyIHByb3Bvc2VkIHRleHQgZG9lcyBu
b3QgcmVmbGVjdCB0aGUgaW50ZW50aW9uLg0KDQoNCg0KIndoZW4gaXQgd2FudHMgdG8gcHJvdmlk
ZS91cGRhdGUuLi4uaXQgc2hhbGwgaW5jbHVkZS4uLiIgdHJhbnNsYXRlcyB0byAiLi4uaXQgbWF5
IGluY2x1ZGUuLi4iLg0KDQoNCg0KImluIG90aGVyIGNhc2VzIiBpbiB0aGUgZ2l2ZW4gY29udGV4
dCB0cmFuc2xhdGVzIHRvICJ3aGVuIGl0IGRvZXMgbm90IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUu
Li4iDQoNCg0KDQoNCg0KV2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOg0KDQphKSB0aGUgcmVw
b3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3Qg
dGhlIGxhdGVzdCBPTFINCg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVk
IChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVh
Y3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCg0KYykgb3Ro
ZXJ3aXNlDQoNCg0KDQppbiBjYXNlIGEpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5v
dCByZXBsYXkgdGhlIE9MUiBpbiBjYXNlIGIpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5
IG5vdCB1cGRkYXRlIHRoZSByZWFjdGluZyBub2RlIHdpdGggdGhlIGxhdGVzdCBPTFIgaW4gY2Fz
ZSBjKSB0aGUgcmVwb3J0aW5nIG5vZGUgTVVTVCBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dl
ciAodGhlIHJlcG9ydGluZyBub2RlIGRvZXMgbm90IGtub3cgd2hldGhlciB0aGlzIGlzIGEgcmVw
bGF5IG9yIGFuIHVwZGF0ZSkNCg0KDQoNClVscmljaA0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQoNCkZyb206IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5z
YWxvdEBjaXNjby5jb21dDQoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA0OjQ5
IFBNDQoNClRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgbGlvbmVsLm1v
cmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBleHQgU3Rl
dmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVj
dDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN
Cg0KDQpVbHJpY2gsDQoNCg0KDQpJdCBzZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUgcGFnZSBidXQg
cHJvYmFibHkgdGhlIHByb3Bvc2VkIHdvcmRpbmcgYmVsb3cgaXMgbm90IHRoZSBiZXN0Lg0KDQpI
b3cgYWJvdXQgdGhlIGZvbGxvd2luZy4NCg0KDQoNCldoZW4gdGhlIHJlcG9ydGluZyBub2RlIHdh
bnRzIHRvIHByb3ZpZGUgbmV3IG92ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0byB1cGRhdGUgdGhl
IGVhcmxpZXIgcHJvdmlkZWQgb3ZlcmxvYWQgcmVwb3J0IHRvd2FyZHMgYSByZWFjdGluZyBub2Rl
LCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNv
bnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25k
aW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hl
biB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQg
aXMgYWxyZWFkeSBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBu
b2RlIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBj
b250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4NCg0KDQoNClJlZ2FyZHMsDQoNCk5p
cmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogV2llaGUsIFVs
cmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0KDQpT
ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMzo1NyBQTQ0KDQpUbzogZXh0IGxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnPG1haWx0
bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCk5pcmF2LCBMaW9uZWwsDQoNCg0KDQpJIGNh
biB1bmRlcnN0YW5kIE5pcmF2J3MgY29uY2VybiAoYWx0aG91Z2ggdmlvbGF0aW5nIFJFUTEwKSBh
bmQgaG9wIGl0IGlzIGFkZHJlc3NlZCBieSB0aGUgbW9kaWZpZWQgcHJpbmNpcGxlIDInOg0KDQoN
Cg0KMicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBv
ciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVx
dWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBp
cyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFzb25hYmxl
IG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNo
IG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5k
aWNhdGluZyAibm8gb3ZlcmxvYWQiLCBvciBhbiBvbGQgIGJ1dCBzb29uIGV4cGlyaW5nIE9MUiB3
aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCk7IG90aGVyd2lzZSAoaS5l
LiBpZiBpdCBpcyBub3QgYXdhcmUuLi4pIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdo
ZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1VU1QgcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZXMg
dG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUC4N
Cg0KDQoNCkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdhbnQgYXBwcm9h
Y2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93IHRoZSByZXBv
cnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBhcmUgbm90IChz
dWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1
cCB0byBkYXRlIE9MUnMuDQoNCg0KDQpVbHJpY2gNCg0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWls
dG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiBbbWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbV0NCg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDEwOjIwIEFNDQoNClRv
OiBOaXJhdiBTYWxvdCAobnNhbG90KTsgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsg
ZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQoN
ClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQoNCg0KDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCg0KRGUgOiBE
aU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNh
bG90IChuc2Fsb3QpIEVudm95w6kgOiBqZXVkaSA2IGbDqXZyaWVyIDIwMTQgMTA6MDggw4AgOiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBp
ZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4gT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNClVscmljaCwNCg0KDQoNCkkg
YW0gbm90IHN1cmUgYWJvdXQgZm9yY2luZyB0aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2Rl
ICJvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5v
ZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBP
TFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0
ZWQtRmVhdHVyZSBBVlAuIg0KDQpUaGUgcmVwb3J0aW5nIG5vZGUgbWF5IHNpbXBseSBub3QgaW5j
bHVkZSBPTFIgYXNzdW1pbmcgdGhhdCB0aGUgZWFybGllciBwcm92aWRlZCBPTFIgd2lsbCBleHBp
cmUgYW5kIHRoZSByZWFjdGluZyBub2RlIHdpbGwgc3RvcCB0aHJvdHRsaW5nIHRoZSB0cmFmZmlj
Lg0KDQoNCg0KW0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVx
dWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4g
SG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9M
UiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBp
bXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4N
Cg0KDQoNCkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig
dGhlIHJlcG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5nIGF0IGVhY2gg
cmVhY3Rpbmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3b3JkcywgdGhlIHJlcG9y
dGluZyBub2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9MUiB0byBmYWNp
bGl0YXRlIHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJkcyBpdC4NCg0K
DQoNCltMTV0gQWdyZWUNCg0KDQoNClRoZXJlIG1heSBiZSBvdGhlciBjYXNlcywgZS5nLiB3aGVu
IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlv
biBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig
aXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRp
dGlvbi4NCg0KDQoNCltMTV0gQWdyZWUNCg0KDQoNClJlc3Qgb2YgdGhlIHByaW5jaXBsZXMgYmVs
b3cgYXJlIGZpbmUgd2l0aCBtZS4NCg0KDQoNCltMTV0gQWdyZWUNCg0KDQoNClJlZ2FyZHMsDQoN
Ck5pcmF2Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogV2llaGUs
IFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0K
DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMjoyMyBQTQ0KDQpUbzogZXh0IFN0
ZXZlIERvbm92YW47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnPG1haWx0bzpk
aW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkFjdHVhbGx5IHdlIHNlZW0gdG8gYWdyZWUgb24g
dHdvIHByaW5jaXBsZXM6DQoNCjEuIExhY2sgb2YgT0xSIG1lYW5zICJubyBjaGFuZ2UiDQoNCjIu
IHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3Qp
IE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMg
d2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2Fy
ZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAo
d2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9M
UiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90
IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2Fk
ZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdo
aWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCg0KDQpDYW4gcGVv
cGxlIHBsZWFzZSBjb25maXJtLg0KDQoNCg0KVWxyaWNoDQoNCg0KDQpGcm9tOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4N
Cg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA0OjM1IFBNDQoNClRvOiBOaXJh
diBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0K
U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCg0KDQpBZ3JlZWQuICBUbyByZXN0YXRlIC0tIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVw
b3J0IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhv
c3Qgb3IgcmVhbG0uICBJZiB0aGVyZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVw
b3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBvdXQg
b3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LiAgSWYg
dGhlcmUgaXMgbm8gY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBsYWNrIG9m
IGFuIG92ZXJsb2FkIHJlcG9ydCBpbXBsaWVzIHRoZXJlIGlzIG5vIG92ZXJsb2FkIGZvciB0aGUg
aG9zdCBhbmQgcmVhbG0uDQoNCg0KDQpTdGV2ZQ0KDQpPbiAyLzUvMTQgOToxOSBBTSwgTmlyYXYg
U2Fsb3QgKG5zYWxvdCkgd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBh
cnQgInNob3VsZG7igJl0IGxhY2sgb2YgT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9h
ZGVkPyINCg0KDQoNCldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhv
dWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBp
bmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2Vy
dmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBh
bmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1
bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2Ft
ZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3
Lg0KDQoNCg0KU28gYmFzaWNhbGx5LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3Qg
dGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLiBUaGUgcmVh
Y3Rpbmcgbm9kZSBjYW4gY29udGludWUgdG8gcmVhY3QgYmFzZWQgb24gb2xkZXIgT0xSIHVudGls
IHRoZSBleHBpcnkgb2YgdGhlIHZhbGlkaXR5LXBlcmlvZCBvciB3aGVuIHRoZSBleHBsaWNpdCBP
TFIgd2l0aCAiMCIgb3ZlcmxvYWQtbWV0cmljIGlzIHJlY2VpdmVkLg0KDQpJbiBteSB2aWV3LCB0
aGlzIGFsbG93cyBmb3IgZmxleGlibGUgaW1wbGVtZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBu
b2RlIGFuZCBzb3VuZCBoYW5kbGluZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuDQoNCg0K
DQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQoNClNlbnQ6IFdlZG5lc2Rh
eSwgRmVicnVhcnkgMDUsIDIwMTQgODowMCBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQppbmxpbmUNCg0KT24gMi81LzE0IDc6NTcgQU0s
IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6DQoNCk9rIHRoZW4gbGV0J3Mg
c3RhdGUgdGhhdCByZXBvcnRpbmcgbm9kZXMgTVVTVCBpbnNlcnQgYW4gT0MtT0xSIEFWUCBpbiBh
bGwgYW5zd2VyIG1lc3NhZ2VzIHRoYXQgY29ycmVzcG9uZCB0byByZXF1ZXN0IG1lc3NhZ2VzIHdo
aWNoIGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCAoZXZlbiB3aGVuIG5vIGxv
YWQgcmVkdWN0aW9uIGlzIHJlcXVlc3RlZCkuDQoNClNSRD4gV2h5IGluIGV2ZXJ5IGFuc3dlciBt
ZXNzYWdlPyAgU2hvdWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBv
dmVybG9hZGVkPw0KDQoNCg0KDQoNCg0KDQoNCg0KT3RoZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBv
ciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQoNClNSRD4gUmVxdWlyaW5nIGFuIG92ZXJs
b2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVhayBSRVExMywgYnV0
IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4gT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBzdWJzdGFudGlhbCBh
ZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRoYW4gaW5zZXJ0aW5n
IE9MUnMuDQoNCg0KDQoNCg0KDQoNCg0KDQpGb3IgbXkgY2xhcmlmaWNhdGlvbjogSSBndWVzcyB0
aGF0IHRoZSByZWFjdGluZyBub2RlIGlzIG5vdCByZXF1aXJlZCB0byBwcm9jZXNzIGV2ZXJ5IHNp
bmdsZSBPTFIgcmVjZWl2ZWQgKG1vc3Qgd2lsbCBiZSByZXBsYXlzIGFueXdheSkuIFdoYXQgd291
bGQgYmUgdGhlIHByb2NlZHVyZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSBpbiBvcmRlciB0byBtaW5p
bWl6ZSBwcm9jZXNzaW5nIG9mIHJlcGxheWVkIE9MUnMgYW5kIGF0IHRoZSBzYW1lIHRpbWUgbWlu
aW1pemUgdGhlIHJpc2sgdG9vIG1pc3MgYSBuZXcgT0xSPw0KDQpTUkQ+IFRoYXQgaXMgdGhlIHB1
cnBvc2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJlci4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQoNClNlbnQ6
IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNToyNyBBTQ0KDQpUbzogbGlvbmVsLm1vcmFu
ZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBkaW1lQGlldGYu
b3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCkkgc2hhcmUgdGhlIHNhbWUg
b3BpbmlvbiBhcyBMaW9uZWwuDQoNCg0KDQpSZWdhcmRzLA0KDQpOaXJhdi4NCg0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbT4NCg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIw
MTQgOTowNyBQTQ0KDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCg0K
U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcmVhbCBjb25jZXJuIGlzIHdoZW4gdGhl
IHJlcG9ydGluZyBub2RlIERPRVMgTk9UIGluc2VydCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlci4N
Cg0KU28gdGhlIG9wdGlvbnMgd291bGQgYmU6DQoNCjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5z
d2VyDQoNCjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSByZXF1ZXN0
ICsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRocm90dGxpbmcg
cGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4NCg0KDQoNCklmIHRo
ZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFw
cHJvYWNoLg0KDQoNCg0KTGlvbmVsDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N
Cg0KRGUgOiBkaW1lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK2RpbWVAdHJhYy50b29scy5p
ZXRmLm9yZ10NCg0KRW52b3nDqSA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo0OQ0KDQrDgCA6
IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KDQpDYyA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVA
aWV0Zi5vcmc+DQoNCk9iamV0IDogW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQoNCg0KIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCg0KDQogSXQg
aGFzIGJlZW4gcHJvcG9zZWQgdG8gZGVmaW5lIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCB0aGF0IGlzICB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2lu
dCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBB
VlAgd291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KDQogKFRpbWVTdGFtcCkgb2Yg
dGhlIE9MUiBhY2NvcmRpbmcgdG8gd2hpY2ggdGhlIHRocm90dGxpbmcgKHdoaWNoIHdhcw0KDQog
c3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhh
dCBjdXJyZW50bHkgbm8gIHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLiAgUmVwb3J0aW5nIERPSUMg
ZW5kcG9pbnRzIG1heSB1c2UgdGhpcyAgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0ZWN0IHdo
ZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGUgIHJlYWN0aW5nIERPSUMgZW5kcG9p
bnQgd2l0aCB0aGUgbGF0ZXN0IE9MUi4NCg0KIEFic2VuY2Ugb2YgdGhpcyBmZWVkYmFjayBtZWNo
YW5pc20gd291bGQgcmVzdWx0IGluIHRoZSBuZWVkIGZvciB0aGUgIHJlcG9ydGluZyBub2RlIHRv
IHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9JQyAg
ZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBp
cyBhY3R1YWxseSBkb2luZyAgdGhlIHJpZ2h0IHRoaW5nIHdpdGggcmVnYXJkIHRvIHRocm90dGxp
bmcvbm90IHRocm90dGxpbmcuDQoNCiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVzIHJv
YnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyAgZW5kcG9pbnQgdG8gZGV0
ZWN0IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3Rpbmcg
IERPSUMgZW5kcG9pbnQgKGNhdXNlZCBieSB3aGF0ZXZlciByZWFzb24pLg0KDQogVGhlIGZlZWRi
YWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4
Lg0KDQogSW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCB0byAgYmUgdXNlZCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nLg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlzdA0KDQpEaU1F
QGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQg
c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m
aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBk
aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh
dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwn
ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM
ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u
LCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl
IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2Ug
YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl
ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBu
b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N
Cg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu
DQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l
c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0K
VGhhbmsgeW91Lg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRmLm9yZzxtYWlsdG86RGlN
RUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRp
TUUgbWFpbGluZyBsaXN0DQoNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQoN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaU1FIG1haWxpbmcgbGlz
dA0KDQpEaU1FQGlldGYub3JnPG1haWx0bzpEaU1FQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCg0KRGlNRSBtYWlsaW5nIGxpc3QNCg0KRGlNRUBpZXRm
Lm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9kaW1lDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll
Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll
bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1
c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog
cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdl
eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl
cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s
DQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl
dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2Fn
ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hv
dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0
aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht
ZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm
b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk
Lg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl
cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs
ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNl
cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl
Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhw
ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg
bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0K
DQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl
IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2Ug
YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl
ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3Vs
ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv
bi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y
IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N
Cg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg
am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz
IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMs
IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1
IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVk
aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l
c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0K
T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh
bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFu
ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg
aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQg
bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u
DQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp
ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz
Lg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt
ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoN
ClRoYW5rIHlvdS4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z
b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OlRpbWVzOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs
YWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFj
azt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K
CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj
azt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh
Y2s7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTD
qSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ
csOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7
fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlByZm9ybWF0SFRNTCwgZGl2LlByZm9ybWF0SFRNTA0KCXtt
c28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCW1zby1zdHlsZS1saW5rOiJQcsOp
Zm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0
Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl
cmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxl
LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5UZXh0ZWRlYnVsbGVzLCBsaS5UZXh0ZWRl
YnVsbGVzLCBkaXYuVGV4dGVkZWJ1bGxlcw0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVs
bGVzIjsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBj
bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh
bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h
aWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2
MTt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMx
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0
OTdEO30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu
LkVtYWlsU3R5bGUzNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MzYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1
cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs
dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk
bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r
PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+TmlyYXYsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5EbyB5b3UgY29uc2lkZXIgdGhhdCBvdmVybG9hZCByZXBvcnRz
IGNhbiBvbmx5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2RlcyB3aGVuIHRoZXJlIGFyZSBh
Z2VudHMgaW4gdGhlIHBhdGg/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBOaXJh
diBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50
OjwvYj4ganVldmVzLCAxMyBkZSBmZWJyZXJvIGRlIDIwMTQgMTM6NTg8YnI+DQo8Yj5Ubzo8L2I+
IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5m
byBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5NYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVwb3J0
aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFzIHBvaW50ZWQgb3V0
IGJ5IExpb25lbCDigJMgdG8gY29uY2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJlYWNoZWQgdGhlIHJl
YWN0aW5nIG5vZGUsIGkuZS4gYWxsIHRoZSBpbnRyYS1zZXNzaW9uDQogbWVzc2FnZXMgbmVlZCBu
b3QgY29udGFpbiB0aGUgc2FtZSBvdmVybG9hZCByZXBvcnQsIGlmIHRoZSBzZXNzaW9uIGVzdGFi
bGlzaG1lbnQgbWVzc2FnZSBjb250YWlucyB0aGUgb3ZlcmxvYWQgcmVwb3J0LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+
U28geW91ciBub3RlIHJlZ2FyZGluZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRvIGFj
Y291bnQgdGhlIG5ldHdvcmsgZGVwbG95bWVudCBldGMuIGlzIG5vdCAxMDAlIGNvcnJlY3QuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkxldCBtZSBzaW1wbGlmeSwgaG9waW5nIGl0IHdp
bGwgc2F0aXNmeSB5b3VyIGNvbmNlcm4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSBy
ZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0
byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0DQo8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv
bG9yOnJlZCI+dGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJl
YWN0aW5nIG5vZGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpOb3RlIOKAkyBJbiBzb21lIGNhc2VzLCBlLmcuIHdoZW4g
dGhlcmUgYXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBv
cnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJk
ZWQgYnkgcmVhY3Rpbmcgbm9kZXMsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgbm90IGJlIGFibGUg
dG8gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBv
cnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMjQ0MDYxIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJh
di48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g
RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+
TWFyaWEgQ3J1eiBCYXJ0b2xvbWU8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5
IDEzLCAyMDE0IDI6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSB0aGluayB0aGVuIHdlIGFncmVlIG9uIHRoZSBwcm9wb3NlZCB0ZXh0OjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi
PkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVj
ZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy48YnI+DQo8YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0
aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3
ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4mbmJzcDsNCjxicj4NCjxicj4NCk5v
dGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVw
b3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0
IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNwOyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBi
ZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48
YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3Zl
cmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9y
dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHN0aWxsIHRoZXJl
IGFyZSBzb21lIGRpc2NyZXBhbmNpZXMgYWJvdXQgdGhlIG5vdGUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPk15IHByb3Bvc2FsIGlzIHRvIGtlZXAgaXQganVzdCBhcyBhbiBpbmRpY2F0
aW9uIG9mIHBvdGVudGlhbCAobWF5YmUgbm90IGFsbCkgc2l0dWF0aW9ucyB0aGF0IHNob3VsZCBi
ZSB0YWtlbiBpbnRvIGFjY291bnQgaWYgZXZlciBhbnkgaW1wbGVtZW50YXRpb24gbWF5IGNvbnNp
ZGVyDQogdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24gdGhhdCBhIHJlcG9ydGlu
ZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzLg0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlaW5nIGEgcmVjb21tZW5kYXRpb24gYW5k
IG5vdCBhIG11c3QsIGF0IGxlYXN0IEkgdGhpbmsgd2UgbmVlZCB0byBpbmRpY2F0ZSB3aGF0IG1h
eSBpbXBseSB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbi4NCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5UaGVuIG15IHByb3Bvc2FsIGlzIHRoZSBmb2xsb3dpbmcsIHRo
YXQgaW5jbHVkZXMgYSBtb2RpZmljYXRpb24gdG8gbGFzdCBzZW50ZW5jZSBhYm92ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90
IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3Vh
cmFudGVlIHRoYXQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMm
cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj50aGlzIG92ZXJsb2FkIHJlcG9ydCBp
cyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZTwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCk5vdGUg4oCT
dGhlIHJlcG9ydGluZyBub2RlIG1heSBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50IG5ldHdvcmsg
ZGVwbG95bWVudCBhbmQgcG90ZW50aWFsIGVycm9ycyBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGd1
YXJhbnRlZSB0aGF0IHNlbnQgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSBpbiB0aGUgcmVhY3Rp
bmcgbm9kZSwgZS5nLiB0aGVyZSBtYXkgYmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUg
cGF0aCBiZXR3ZWVuIHJlcG9ydGluZw0KIGFuZCByZWFjdGluZyBub2Rlczsgb3ZlcmxvYWQgcmVw
b3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVz4oCmPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj
bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P
biBCZWhhbGYgT2YgPC9iPlRST1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKTxicj4N
CjxiPlNlbnQ6PC9iPiBtacOpcmNvbGVzLCAxMiBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MTM8YnI+
DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3Jn
PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcg
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBz
dXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkN
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+T24gdGhpcyB0b3BpYywgbXkgdmlldyBpcyB0aGF0IHRoZSByZWFjdGluZyBu
b2RlIHNoYWxsICZuYnNwO3JlY2VpdmUg4oCcZW5vdWdo4oCdIE9MUnMgcGVyIHBlcmlvZCBvZiB0
aW1lIHRvIGVuc3VyZSB0aGUgZWZmaWNpZW5jeSBvZiB0aGUgdHJhZmZpYyAmbmJzcDtyZWR1Y3Rp
b24gbWVjaGFuaXNtDQogLiBBIHdheSB0byBhY2hpZXZlICZuYnNwO3RoZSDigJxlbm91Z2jigJ0g
aXMgdG8gaGF2ZSBhbiBPTFIgaW4gYWxsICZuYnNwO2Fuc3dlciAmbmJzcDttZXNzYWdlcyBhcyBw
cm9wb3NlZCBhbmQgdGhpcyBjYW4gdGhlIHJlY29tbWVuZGVkIHdheS4gTm93IGFzIE5pcmF2IHNh
aWQsIHRoZXJlIG1heSBiZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3aWxsIGJlaGF2ZSBkaWZmZXJl
bnRseSBhbmQgc2VuZCDigJxlbm91Z2jigJ0gT0xScyAmbmJzcDtidXQgbm90IGluIGFsbCBtZXNz
YWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkFzIGFsc28gTmlyYXYgbm90ZWQsICZuYnNwO0kgZG8gbm90IHdlbGwg
c2VlIHRoZSBuZWVkIHRvIHdyaXRlIGFkZGl0aW9uYWwgbm90ZXMgYXMgbWFueSBzaXR1YXRpb25z
IGNhbiBvY2N1ciBhbmQgJm5ic3A7YXJlIG5vdCBsaW1pdGVkIHRvIHRoZSBleGFtcGxlIG9mIHRo
ZSByZWFjdGluZw0KICZuYnNwO25vZGUgJm5ic3A7ZGlzY2FyZGluZyBPTFJzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KSmFjcXVlcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZu
YnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
ZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9i
PiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5k
QG9yYW5nZS5jb208L2E+PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDExIGbDqXZy
aWVyIDIwMTQgMTY6MzU8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IE1hcmlhIENydXogQmFydG9sb21l
OyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8
Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCwg
aXQgaXMgY29ycmVjdCENCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8
YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxNTowMDxi
cj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWwsIE5pcmF2LCBhbGwsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5NYXliZSB0aGUgbm90ZSBjb3VsZCBiZSBtb2RpZmllZDo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpOb3RlIOKAk3Ro
ZSByZWFjdGluZyBub2RlIGNvdWxkIGJlIGFueSBhZ2VudCBpbiB0aGUgcGF0aCwgYW5kIHRoYXQg
aW4gc29tZSBlcnJvciBzaXR1YXRpb25zIG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRl
ZCBieSByZWFjdGluZyBub2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSBhZGRlZCB0aGUgY2FzZSBPTFIgY291bGQgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5v
ZGVzLCBzaW5jZSBpdCBoaWdobGlnaHRzIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBzZXJ2ZXIgd2ls
bCBub3Qga25vdyB3aGV0aGVyIG9yIG5vdCBhIHZhbGlkIE9MUiBpcyByZWNlaXZlZA0KIGJ5IHJl
YWN0aW5nIG5vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KPGEgaHJl
Zj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2Uu
Y29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bWFpbHRv
Omxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gbWFydGVz
LCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MzY8YnI+DQo8Yj5Ubzo8L2I+IE1hcmlhIENydXog
QmFydG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwv
YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF0IGxl
YXN0LCBpdCBpcyBub3QgJnF1b3Q7dGhlIG9ubHkgc3VyZSB3YXkmcXVvdDsuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdlcyBwYXJ0
IG9mIHRoZSBzYW1lIHNlc3Npb24gKG9yIHBzZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNvIGJlIHVz
ZWQgYXMgaW5kaWNhdGlvbiBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRoYXQgdGhlIE9MUiBoYXMg
YmVlbg0KIHJlY2VpdmVkIGJ5IHRoZSByZWFjdGluZyBub2RlIChiZXNpZGVzIHRoZSByZWNlcHRp
b24gb2YgdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBpbiB0aGUgcmVxdWVzdCkuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IGlzIHdoeSBJIHdhcyBzYXlpbmcgdGhhdCB0aGlzIGNh
biBiZSBmaXhlZCBwZXIgYXBwbGljYXRpb24vc3lzdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w
cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUm
bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwv
Yj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkg
MTEgZsOpdnJpZXIgMjAxNCAxMTozMTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFp
bHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6
PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5G
aW5lIE5pcmF2LCBJIGFncmVlIHRoaXMgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IGludGVudGlvbiBpcyB0aGF0IGFueSByZWFkZXIg
cmVhbGl6ZXMgd2hhdCB0aGlzIGtub3dsZWRnZSBpbiB0aGUgc2VydmVyIGltcGxpZXMgd2hlbiB3
ZSB0YWxrIGFib3V0IGFnZW50cyBpbiB0aGUgcGF0aC4gVGhpcyBpcyB3aHkgSSB0aGluayB0aGlz
IG5vdGUgaXMgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k
b3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
d2luZG93dGV4dCI+IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90
QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8
L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjI2PGJyPg0KPGI+VG86PC9iPiBN
YXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRGltZV0gW2RpbWVdICMzMTog
U2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj5JIGRvIG5vdCBhZ3JlZSByZWdhcmRpbmcgdGhlIGNvbXBsZXhpdHkgc2luY2UgaXQgaXMg
aGlnaGx5IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0
MDYxIj5MZXRzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24u
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMjQ0MDYxIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE
RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlN
RSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmlhIENydXogQmFydG9s
b21lPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDM6NTQgUE08
YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYu
b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBoaWdobGlnaHQgY29t
cGxleGl0eSBmb3IgdGhlIHNlcnZlciB0byAmbmJzcDvigJw8L3NwYW4+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+
Z3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUNCiBhbHJlYWR5IGhhcyByZWNlaXZlZCB0
aGUgb3ZlcmxvYWQgcmVwb3J0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0
aGlzIGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRlZCBieSBTdGV2ZS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vTUNydXo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJl
Zj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5pcmF2IFNhbG90IChuc2Fsb3QpPGJyPg0K
PGI+U2VudDo8L2I+IG1hcnRlcywgMTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIwPGJyPg0KPGI+
VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwu
bW9yYW5kQG9yYW5nZS5jb208L2E+OyBTdGV2ZSBEb25vdmFuOw0KPGEgaHJlZj0ibWFpbHRvOmRp
bWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5JIGFtIGFsc28gZmluZSB3aXRoIFN0ZXZlJ3MgcHJvcG9z
ZWQgd29yZGluZyB0byByZWNvbW1lbmQgdGhlIGluY2x1c2lvbiBvZiBPTFIgYnV0IHRvIG5vdCBt
YW5kYXRlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzI0NDA2MSI+SSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgZm9sbG93aW5nIHRl
eHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIGFkZCBpdC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ob3RlIC0gdGhl
IG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0
aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdo
ZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJl
dHdlZW4NCiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUuPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPkkgcHJlZmVyIHRv
IHJlbW92ZSBpdCBzaW5jZSBJIGRvIG5vdCBzZWUgYXMgdmFsdWUgYWRkaXRpb24uDQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQw
NjEiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBo
cmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGll
dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNl
bnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEwOjEzIFBNPGJyPg0KPGI+VG86PC9i
PiBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRm
Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkknbSBmaW5lIHdpdGggYSByZWNvbW1lbmRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGhhdmUgYSBn
ZW5lcmFsIGNvbW1lbnQ6IHdoZW4gYSBNQVkgb3IgZXZlbiBhIFNIT1VMRCBhcHBseSwgaXQgZG9l
cyBub3QgbWVhbiB0aGF0IGl0IGlzIE5PVCB1cCB0byB0aGUgbm9kZSB0byBkbyBvciBub3QgdG8g
ZG8gc29tZXRoaW5nLiBJdCBkb2VzIG5vdCBtZWFuDQogdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxl
bWVudGF0aW9uIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGluc3Rh
bmNlLCBvdmVyIGEgZ2l2ZW4gaW50ZXJmYWNlLCB0aGUgcmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNh
biBzYXkgdGhhdCBzb21lIHN0YXRlcyBhcmUgbWFpbnRhaW5lZCBieSB0aGUgc2VydmVyLiBBbmQg
aXQgY291bGQgYmUgZGVjaWRlZCB0byBhZGQgc29tZSBvdmVybG9hZA0KIHJlbGF0ZWQgaW5mbyBp
biBzdWNoIHN0YXRlcy4gRm9yIGluc3RhbmNlIGFnYWluLCB0aGUgbm9kZSBjYW4gdXNlIHRoaXMg
c3RhdGUgdG8ga25vdyBpZiBhIHJlbW90ZSBub2RlIGhhdmUgYmVlbiBub3RpZmllZCBvciBub3Qg
Zm9yIGluc3RhbmNlLiBBbmQgaW4gc3VjaCBhIGNhc2UsIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVl
ZCB0byBpbmNsdWRlIGFuIE9MUiBpbiBlYWNoIG1lc3NhZ2UuIEl0IGlzIGp1c3QgZm9yIGlsbHVz
dHJhdGlvbi4gVGhlIHBvaW50DQogaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Ig
d2hpY2ggdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+SSBhZ3JlZSB0aGF0IGhhdmluZyB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBpcyBmaW5l
4oCmIGJ1dCBpdCBzaG91bGQgYmUgbm90IG1hbmRhdG9yeSBpbiBhbGwgY2FzZXMgSSB0aGluay4g
U28gT0sgZm9yIGEgJnF1b3Q7U0hPVUxEJnF1b3Q7IG9yICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbA0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFs8YSBocmVmPSJt
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
PC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IFN0ZXZlIERvbm92YW48YnI+DQo8Yj5FbnZvecOp
Jm5ic3A7OjwvYj4gbHVuZGkgMTAgZsOpdnJpZXIgMjAxNCAxNzoyMTxicj4NCjxiPsOAJm5ic3A7
OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGI+T2JqPC9iPjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6d2luZG93dGV4dCI+ZXQmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFJlOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbw0KIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVlIHdpdGggYm90aCBN
YXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pPGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgd2UgaGF2
ZSB3b3JkaW5nIHNheWluZyB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSB0
aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFsbCByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlYXNv
bnMgbGlzdGVkIGJ5IE1hcmlhIENydXouJm5ic3A7DQo8YnI+DQo8YnI+DQpJIGFsc28gc3VnZ2Vz
dCB0aGF0IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5v
ZGUga25vd3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3Zl
cmxvYWQgcmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi4mbmJz
cDsgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cg
dGhlIHJlcG9ydGluZyBub2RlIGtub3dzDQogYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcg
YWJvdXQgbmV0d29ya3MgYXJjaGl0ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtu
b3cuJm5ic3A7IFRoZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMgZm9y
IG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuPGJyPg0KPGJyPg0KPC9z
cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDss
JnF1b3Q7c2VyaWYmcXVvdDsiPldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVj
b21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLjxi
cj4NCjxicj4NCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSB3b3JkaW5nLCB3aGlj
aCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFzb25zIGZvciByZWNvbW1l
bmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBpbmNsdWRlZC48YnI+DQo8
YnI+DQotLS0tLTxicj4NCjxicj4NCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBh
bGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy48YnI+DQo8YnI+
DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9h
ZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4m
bmJzcDsNCjxicj4NCjxicj4NCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5j
bHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiBy
ZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNwOyBUaGUgb3Zlcmxv
YWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRv
ZXMgbm90IHN1cHBvcnQgRE9JQy48YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9v
c2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBp
dCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2
ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC48YnI+DQo8YnI+DQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3
YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rp
bmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0
aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNs
aWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkZSIj5PbiAyLzEwLzE0IDM6NTIgQU0sIE1hcmlhIENydXogQmFydG9sb21lIHdyb3RlOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGVs
bG8gTmlyYXYsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+QW55IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2ll
bmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBm
aXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBw
cm92aWRpbmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPllvdXIgcHJvcG9zZWQgdGV4dCZuYnNwOyA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDsg
QWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9k
ZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVk
IHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhl
IE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9y
dGVkLUZlYXR1cmUgQVZQLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPklmIHRoZSByZXBvcnRpbmcgaXMgbm90IGF3YXJlIGFib3V0IHdoZXRo
ZXIgb3Igbm90IG92ZXJsb2FkIHJlcG9ydCBpcyBwcm92aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9k
ZSwgYW5kIGl0IGRlY2lkZXMgKHNpbmNlIGl0IGlzIGEgJnF1b3Q7bWF5JnF1b3Q7KSB0byBkbyBu
b3Qgc2VuZCB0aGUgT0xSIGFnYWluLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gbWVjaGFuaXNt
IHdpbGwgbm90IHdvcmsgaW4gY2FzZSBPTFIgd2FzIG5vdCBwcm9wZXJseSByZWNlaXZlZCBieSBj
b3JyZXNwb25kaW5nIHBvdGVudGlhbCByZWFjdGluZyBub2Rlcy4gQW5kIHdlIG5lZWQgdG8gbm90
ZSB0aGF0ICZxdW90O3JlYWN0aW5nIG5vZGVzJnF1b3Q7IGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBj
bGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUg
YWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVh
Y3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4gPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlbiwgb24gb25lIGhhbmQg
aXQgaXMgbm90IHNpbXBsZSB0byBrbm93IHdoZW4gcmVhY3Rpbmcgbm9kZXMgaGF2ZSB2YWxpZCBP
TFIgaW5mbyAoYXMgZXhwbGFpbmVkIGJlbG93KSwgYnV0IGlmIE9MUiBpcyBub3Qgc2VudCBhZ2Fp
biAoYXMgcGVyIHlvdXIgcHJvcG9zZWQgJnF1b3Q7bWF5JnF1b3Q7KSB0aGVuIG9uZSBvciBtdWx0
aXBsZSByZWFjdGluZyBub2RlcyBkbyBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92
ZXJsb2FkIG1pdGlnYXRpb24gd2lsbCBub3Qgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVyZWZvcmUsIGluIG15IG9waW5pb24sIHRoZSBz
aW1wbGVzdCB3YXkgdG8gcHJvdmlkZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBpcyB0byBwcm92aWRl
IE9MUiBpbiBBTEwgYW5zd2Vycy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IE5pcmF2IFNhbG90
IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNhbG90QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxv
dEBjaXNjby5jb208L2E+XSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5TZW50OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IE1hcmlhIENy
dXogQmFydG9sb21lOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9y
ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5T
dWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CdXQg
TWFyaWEtQ3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5Ib3cgY2FuIHdlIHNheSB0aGF0ICZxdW90O2luY2x1ZGluZyB0aGUgT0xSIGluIGFsbCB0
aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZmaWNpZW50PyZxdW90OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkl0IGlzIHNpbXBsZSBm
b3Igc3VyZSBidXQgbm90IGVmZmljaWVudC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+QSBzbGlnaHRseSBkaWZmZXJlbnQgd29yZGluZyBmcm9tIHdo
YXQgSSBwcm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBoYXMgYSBu
ZXcgb3ZlcmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gYSByZWFjdGlu
ZyBub2RlIChieSB1cGRhdGluZyB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQg
b3IgYnkgcHJvdmlkaW5nIHRoZSBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1lKSwg
aXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250
YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGlu
ZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4g
dGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlz
IGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9k
ZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29u
dGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERp
TUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBNb25k
YXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDM6MDMgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmci
PmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+TmlyYXYsIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5JIHRoaW5rIHdlIHNob3VsZCBkZWZpbmUgYW4gYWNjdXJhdGUgYW5kIHJv
YnVzdCBzb2x1dGlvbiwgYXMgZWZmaWNpZW50IGFuZCBzaW1wbGUgYXMgcG9zc2libGUuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB1bmRlcnN0YW5k
IHlvdXIgcHJvcG9zYWwgYXMgYSBwdXJlICZxdW90O21heSZxdW90OywgYnV0IGxlYXZpbmcgaXQg
dXAgdG8gaW1wbGVtZW50YXRpb24gZG9lcyBub3QgYXNzdXJlIHJlYWN0aW5nIG5vZGUgaGFzIHZh
bGlkIE9MUiBpbmZvcm1hdGlvbiwgd2hhdCBpcyBiYXNpYyBmb3IgdGhpcyBtZWNoYW5pc20gdG8g
d29yay4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+L01DcnV6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEg
aHJlZj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9h
Pl08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50
OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VG86IE1hcmlhIENydXogQmFydG9sb21lOyA8
YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NYXJpYS1DcnV6LDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgZnVsbHkgYWdyZWUg
d2l0aCB5b3Ugb24gJnF1b3Q7c2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNvbWUgaW1w
b3J0YW50IGFkdmFudGFnZXMmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+QW5kIHdlIGFyZSBub3QgdHJ5aW5nIHRvIHByZXZlbnQgaXQgLSBh
dCBsZWFzdCB0aGF0IGlzIG15IGludGVudGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QnV0IHRoZSBtYWluIHF1ZXN0aW9uIGlzLCBhcmUgd2Ug
dHJ5aW5nIHRvIHByZXZlbnQgYW55IG90aGVyIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uLCB3aGlj
aCBtYXkgYmUgc21hcnRlciBhbmQgY2FuIGF2b2lkIGluY2x1ZGluZyByZWR1bmRhbnQgT0xSIGlu
IGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2U/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+TW9zdCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50
YXRpb24gb2Ygb3ZlcmxvYWQgY29udHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5z
d2VyIG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJlc3RyaWN0IHRo
ZSBkZXZlbG9wZXJzIHdoaWNoIGNhbiBjb21lIHVwIHdpdGggc29tZSBuaWNlIHR3ZWFrcyBhbmQg
dHJpY2tzIHRvIGF2b2lkIHNlbmRpbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gZXZlcnkgbWVz
c2FnZS4gQW5kIHRoaXMgaXMgd2hlcmUgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGFuZCBhdm9pZCBw
dXR0aW5nIHN1Y2ggcmVzdHJpY3Rpb25zIGluIHByb3RvY29sIGRlZmluaXRpb24uIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoYXQgZG8geW91IHRo
aW5rPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRo
aXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1Z2dlc3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Yg
d2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUgcmVwb3J0aW5nIG5vZGUgcG9pbnQgb2Ygdmll
dykuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVn
YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5O
aXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg
T2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6NTcgUE08
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEg
aHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGVsbG8gVWxyaWNoLCBOaXJhdiw8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGFncmVl
IHdpdGggVWxyaWNoIHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1B
WSwgYW5kIHdoZXRoZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3
ZXJzIHNoYWxsIG5vdCBiZSBqdXN0IGEgTUFZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPk9uIHRoZSBvdGhlciBoYW5kLCBjcml0ZXJpYSBwcm92aWRl
ZCBieSBVbHJpY2ggb24gd2hlbiBPTFIgaGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMgdGhlIHNlcnZl
ciBoYXMgc29tZSBrbm93bGVkZ2U6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YikgdGhlIHJlcG9ydGluZyBub2RlIGlz
IG5vdCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25v
d3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBl
eHBpcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5j
KSBvdGhlcndpc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5SZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJl
Y2VwdGlvbi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUg
dGhpcyBrbm93bGVkZ2U/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlRha2UgaW50byBhY2NvdW50IGFzIHdlbGwgdGhhdCBhICZxdW90O3JlYWN0aW5n
JnF1b3Q7IG5vZGUgbWF5IGJlIGJvdGggYW4gQWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMgc2Vy
dmljZSB0byBhIHJlYWxtIG9yIGFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBj
bGllbnQpJm5ic3A7IGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0
IHRoZSBTZXJ2ZXIgbWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMg
YSByZWFjdGluZyBub2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZl
ciBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBp
biB0aGUgY2hhaW4gdG8gdGhlIGZpbmFsIENsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0aGluayB0
aGF0IHNlbmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRh
Z2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0g
c3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikgaXMgc2lt
cGxlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t
IHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8g
c2VuZCBhbiBPTCB0byBhIHJlYWN0aW5nIG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBib3Ro
ZXIgd2hldGhlciBhbiByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9MUiBv
ciB3aGV0aGVyIHRoaXMgT0xSIGlzIHN0aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gc2VuZGluZyBh
biBhZGRpdGlvbmFsIEFWUCBpcyBub3QgcHJvY2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlz
b24gd2l0aCByZXF1aXJlZCBhYm92ZSBjaGVja3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgSW4g
ZmFjdCwgaW4gYW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVzdCBhbmQgbGVhc3QgY29t
cGxleCBpcyB0byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZmZWN0ZWQvYXBwbGljYWJs
ZSBub2RlcywgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7IGFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNhcmUgdG8gdGFrZSBhcHByb3By
aWF0ZSBhY3Rpb25zJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPi0gbW9yZSByb2J1c3Qgc29sdXRpb24sIGFzIG5vIG5lZWQgdG8gY2F0ZXIg
Zm9yIGFsbCB0aGUgY2hlY2tzIG9uIHRoZSBuZWVkIHRvIHNlbmQgaW5mb3JtYXRpb24sJm5ic3A7
IGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlzIGxvc3QsJm5ic3A7IOKA
pjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3Qg
cmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
Pi9NQ3J1ejxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBbPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFs
ZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogdmllcm5lcywgMDcgZGUgZmVicmVy
byBkZSAyMDE0IDEwOjU5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+VG86IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IDxhIGhyZWY9Im1haWx0
bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47
IGV4dCBTdGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBp
ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5TdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5OaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5JJ20gYWZyYWlkIHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRl
bnRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
JnF1b3Q7d2hlbiBpdCB3YW50cyB0byBwcm92aWRlL3VwZGF0ZS4uLi5pdCBzaGFsbCBpbmNsdWRl
Li4uJnF1b3Q7IHRyYW5zbGF0ZXMgdG8gJnF1b3Q7Li4uaXQgbWF5IGluY2x1ZGUuLi4mcXVvdDsu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7
aW4gb3RoZXIgY2FzZXMmcXVvdDsgaW4gdGhlIGdpdmVuIGNvbnRleHQgdHJhbnNsYXRlcyB0byAm
cXVvdDt3aGVuIGl0IGRvZXMgbm90IHdhbnQgdG8gcHJvdmlkZS91cGRhdGUuLi4mcXVvdDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZSBoYXZlIHRo
ZSBmb2xsb3dpbmcgY2FzZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5n
IG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5v
dCBvdmVybG9hZGVkIChpLmQuIGRvZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3Mg
dGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBp
cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jKSBv
dGhlcndpc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij5pbiBjYXNlIGEpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCByZXBsYXkgdGhl
IE9MUiBpbiBjYXNlIGIpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgb3IgbWF5IG5vdCB1cGRkYXRl
IHRoZSByZWFjdGluZyBub2RlIHdpdGggdGhlIGxhdGVzdCBPTFIgaW4gY2FzZSBjKSB0aGUgcmVw
b3J0aW5nIG5vZGUgTVVTVCBpbmNsdWRlIHRoZSBPTFIgaW4gdGhlIGFuc3dlciAodGhlIHJlcG9y
dGluZyBub2RlIGRvZXMgbm90IGtub3cgd2hldGhlciB0aGlzIGlzIGEgcmVwbGF5IG9yIGFuIHVw
ZGF0ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5V
bHJpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPkZyb206IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJl
Zj0ibWFpbHRvOm5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl08
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBU
aHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgNDo0OSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N
dW5pY2gpOyBleHQgPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlv
bmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjsgZXh0IFN0ZXZlIERvbm92YW47IDxhIGhyZWY9Im1h
aWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt
ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCBzZWVtcyB3ZSBhbGwgYXJlIG9uIHNhbWUg
cGFnZSBidXQgcHJvYmFibHkgdGhlIHByb3Bvc2VkIHdvcmRpbmcgYmVsb3cgaXMgbm90IHRoZSBi
ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhv
dyBhYm91dCB0aGUgZm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPldoZW4gdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRvIHByb3ZpZGUg
bmV3IG92ZXJsb2FkIHJlcG9ydCBvciB3YW50cyB0byB1cGRhdGUgdGhlIGVhcmxpZXIgcHJvdmlk
ZWQgb3ZlcmxvYWQgcmVwb3J0IHRvd2FyZHMgYSByZWFjdGluZyBub2RlLCBpdCBzaGFsbCBpbmNs
dWRlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3Vw
cG9ydGVkLUZlYXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5v
ZGUuIEFkZGl0aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgaXMgbm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92
aWRlZCB0byB0aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRl
IHRoZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKSBbPGEgaHJlZj0ibWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tIj5t
YWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAx
NCAzOjU3IFBNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VG86IGV4dCA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9u
ZWwubW9yYW5kQG9yYW5nZS5jb208L2E+OyBOaXJhdiBTYWxvdCAobnNhbG90KTsgZXh0IFN0ZXZl
IERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1Ympl
Y3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5pcmF2LCBM
aW9uZWwsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
SSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVEx
MCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzo8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4yJy4gdGhl
IHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTUFZ
IGRlY2lkZSBub3QgdG8gcmV0dXJuIGFuIE9MUiBpbiByZXNwb25zZSB0byByZXF1ZXN0cyB3aGlj
aCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQIGlmIGl0IGlzIGF3YXJlIHRo
YXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgZ290IHJlYXNvbmFibGUgb3ZlcmxvYWQg
Y29udHJvbCBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgbGF0ZXN0IE9MUiwgd2hpY2ggbWF5IGJlIGFu
IE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICZx
dW90O25vIG92ZXJsb2FkJnF1b3Q7LCBvciBhbiBvbGQmbmJzcDsgYnV0IHNvb24gZXhwaXJpbmcg
T0xSIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNl
IChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0
ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3Bv
bnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUg
QVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkg
ZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJs
b2FkIGNvbnRyb2wgd2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9k
ZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50
bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRl
IE9MUnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
VWxyaWNoJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogZXh0IDxhIGhyZWY9Im1haWx0bzpsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4gWzxhIGhy
ZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPm1haWx0bzpsaW9uZWwubW9yYW5k
QG9yYW5nZS5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAxMDoyMCBBTTxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvOiBOaXJhdiBT
YWxvdCAobnNhbG90KTsgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZl
IERvbm92YW47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1Ympl
Y3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tTWVz
c2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkRlJm5ic3A7OiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBk
ZSBOaXJhdiBTYWxvdCAobnNhbG90KSBFbnZvecOpJm5ic3A7OiBqZXVkaSA2IGbDqXZyaWVyIDIw
MTQgMTA6MDggw4AmbmJzcDs6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBT
dGV2ZSBEb25vdmFuOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9y
ZzwvYT4gT2JqZXQmbmJzcDs6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlVscmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i
RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5JIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiByZXBv
cnRpbmcgbm9kZSAmcXVvdDtvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0
aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBN
VVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5l
ZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHJlcG9ydGluZyBub2RlIG1heSBzaW1w
bHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xS
IHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0
aGUgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5bTE1dIEFncmVlLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJl
ZCBmb3IgdGhlIGRlZmF1bHQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LiBIb3cg
YW5kIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGRlY2lkZXMgdG8gaW5jbHVkZSB0aGUgT0xSIGlu
IHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBvbiB0aGUgYXBwbGljYXRpb24gb3Igb24gdGhlIGltcGxl
bWVudGF0aW9uLiBBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFzIHdlIGhhZCBk
aXNjdXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIHJlcG9ydGluZyBub2Rl
IHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5nIGF0IGVhY2ggcmVhY3Rpbmcgbm9kZSBhdCB0
aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3b3JkcywgdGhlIHJlcG9ydGluZyBub2RlIGNhbiBhbGxv
dyB0aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9MUiB0byBmYWNpbGl0YXRlIHNsb3cgcmFtcCBv
ZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJkcyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTE1dIEFncmVlPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlcmUgbWF5IGJlIG90aGVyIGNhc2Vz
LCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIGxhc3Qgb3Zlcmxv
YWQgc2l0dWF0aW9uIGVuZGVkIGxvbmcgdGltZSBiYWNrIGluIHRoZSBwYXN0LCB0aGVyZSBpcyBu
byBuZWVkIGZvciBpdCB0byBpbmNsdWRlIE9MUiBpZiBjdXJyZW50bHkgdGhlcmUgaXMgbm8gb3Zl
cmxvYWQgY29uZGl0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPltMTV0gQWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5SZXN0IG9mIHRoZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGgg
bWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W0xN
XSBBZ3JlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5p
Y2gpIFs8YSBocmVmPSJtYWlsdG86dWxyaWNoLndpZWhlQG5zbi5jb20iPm1haWx0bzp1bHJpY2gu
d2llaGVAbnNuLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE08bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogZXh0IFN0
ZXZlIERvbm92YW47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyA8YSBocmVmPSJtYWlsdG86ZGltZUBp
ZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRp
bmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhh
dCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5BY3R1YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmluY2lw
bGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEu
IExhY2sgb2YgT0xSIG1lYW5zICZxdW90O25vIGNoYW5nZSZxdW90OzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjIuIHRoZSByZXBvcnRpbmcgbm9kZSAo
bm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJl
dHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBu
b2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiBy
ZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICZxdW90O25v
IG92ZXJsb2FkJnF1b3Q7KTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikg
dGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkg
TVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWlu
ZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VWxyaWNoPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbTogRGlNRSBb
PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNl
c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3ZhbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFdlZG5lc2RheSwg
RmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPlRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgPGEgaHJlZj0ibWFp
bHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QWdyZWVkLiZuYnNwOyBUbyByZXN0YXRlIC0tIGxh
Y2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBvdmVy
bG9hZCBzdGF0ZSBmb3IgdGhlIGhvc3Qgb3IgcmVhbG0uJm5ic3A7IElmIHRoZXJlIGlzIGEgY3Vy
cmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgdGhlbiBpdCBjb250aW51ZXMgdG8gYXBwbHkg
dW50aWwgaXQgZWl0aGVyIHRpbWVzIG91dCBvciBpcyBleHBsaWNpdGx5IGNoYW5nZWQgd2l0aCBh
IG5ldyBvdmVybG9hZCByZXBvcnQuJm5ic3A7IElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3Rp
dmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGll
cyB0aGVyZSBpcyBubyBvdmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN0ZXZlPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T24gMi81LzE0IDk6MTkgQU0s
IE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQg
JnF1b3Q7c2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJs
b2FkZWQ/JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+V2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBzb21ldGltZSBiYWNrIGFuZCB0aG91Z2h0IHRo
YXQgaXQgaXMgcmVhc29uYWJsZSB0byBub3QgbWFuZGF0ZSB0aGUgc2VydmVyIHRvIGluY2x1ZGUg
dGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZS4gRS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMg
Y2FwYWJsZSBvZiB0cmFja2luZyB3aGF0IGlzIHNlbnQgdG8gd2hpY2ggY2xpZW50IGFuZCBoZW5j
ZSB3YW50cyB0byBhdm9pZCBzZW5kaW5nIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlZHVuZGFudC4g
QnV0IHRoaXMgaXMgb3B0aW9uYWwgaW1wbGVtZW50YXRpb24gYW5kIGF0IHRoZSBzYW1lIHRpbWUg
bmVlZCBub3QgYmUgcHJvaGliaXRlZCBmcm9tIHByb3RvY29sIHBvaW50IG9mIHZpZXcuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gYmFzaWNhbGx5
LCB0aGUgbGFjayBvZiBPTFIgc2hvdWxkIG5vdCBhZmZlY3QgdGhlIHByZXZpb3VzbHkgcmVjZWl2
ZWQgT0xSIGF0IHRoZSByZWFjdGluZyBub2RlLiBUaGUgcmVhY3Rpbmcgbm9kZSBjYW4gY29udGlu
dWUgdG8gcmVhY3QgYmFzZWQgb24gb2xkZXIgT0xSIHVudGlsIHRoZSBleHBpcnkgb2YgdGhlIHZh
bGlkaXR5LXBlcmlvZCBvciB3aGVuIHRoZSBleHBsaWNpdCBPTFIgd2l0aCAmcXVvdDswJnF1b3Q7
IG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbiBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3IgZmxleGli
bGUgaW1wbGVtZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBoYW5kbGlu
ZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gcm9tOiBEaU1FIFs8YSBocmVmPSJtYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g
QmVoYWxmIE9mIFN0ZXZlIERvbm92YW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6MDAg
UE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ubzog
PGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aW5saW5lPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T24gMi81LzE0IDc6NTcgQU0s
IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T2sgdGhlbiBsZXQncyBzdGF0ZSB0aGF0
IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGluIGFsbCBhbnN3ZXIg
bWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMgd2hpY2ggY29udGFp
biBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8gbG9hZCByZWR1Y3Rp
b24gaXMgcmVxdWVzdGVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5TUkQmZ3Q7IFdoeSBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZT8mbmJzcDsgU2hv
dWxkbid0IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk90aGVyIGNy
aXRlcmlhIGxpa2UgUkVRMTggb3IgUkVRMTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNSRCZndDsgUmVxdWly
aW5nIGFuIG92ZXJsb2FkIHJlcG9ydCBpbiBldmVyeSBhbnN3ZXIgZG9lcyBkaXJlY3RseSBicmVh
ayBSRVExMywgYnV0IHJlcXVpcmluZyBhbiBvdmVybG9hZGVkIG5vZGUgdG8gbG9vayBmb3IgYW4g
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IG1lc3NhZ2UgaXMgYWxzbyBz
dWJzdGFudGlhbCBhZGRpdGlvbmFsIHdvcmssIHBvdGVudGlhbGx5IG1vcmUgZXhwZW5zaXZlIHRo
YW4gaW5zZXJ0aW5nIE9MUnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Rm9yIG15IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rp
bmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2Vp
dmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9j
ZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2lu
ZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNr
IHRvbyBtaXNzIGEgbmV3IE9MUj88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5TUkQmZ3Q7IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlcXVlbmNl
IG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPkZyb206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhh
bGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAx
NCA1OjI3IEFNPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+VG86IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1l
QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPkkgc2hhcmUgdGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OaXJhdi48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZy
b206IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOmxp
b25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlbnQ6IFR1ZXNk
YXksIEZlYnJ1YXJ5IDA0LCAyMDE0IDk6MDcgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmci
PmRpbWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+SSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSBy
ZXBvcnRpbmcgbm9kZSBET0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvIHRoZSBv
cHRpb25zIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjEtIE9DLU9MUiBBVlAgaW4gZXZlcnkgYW5zd2VyPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Mi0gT0MtT25nb2luZy1UaHJvdHRsaW5n
LUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgJiM0MzsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dl
ciB3aGVuIHRoZSBjdXJyZW50IHRocm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVl
ZHMgdG8gYmUgdXBkYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5JZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBz
ZWVtcyB0aGUgYmVzdCBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5MaW9uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EZSZuYnNwOzogZGltZSBpc3N1
ZSB0cmFja2VyIFs8YSBocmVmPSJtYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYu
b3JnIj5tYWlsdG86dHJhYyYjNDM7ZGltZUB0cmFjLnRvb2xzLmlldGYub3JnPC9hPl08bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5FbnZvecOpJm5ic3A7
OiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7DgCZuYnNwOzogTU9SQU5EIExpb25lbCBJTVQvT0xOPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2MmbmJzcDs6
IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9iamV0Jm5ic3A7OiBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+IEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgdGhhdCBpcyZuYnNwOyB0byBiZSBpbmNsdWRlZCBieSB0aGUgcmVhY3Rpbmcg
RE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQmbmJzcDsgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nLiBUaGlzIEFWUCB3b3VsZCBpbmRpY2F0ZSB0aGUgU2VxdWVuY2UtTnVtYmVyPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IChUaW1lU3Rh
bXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3
YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gc3Vy
dml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5jZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBj
dXJyZW50bHkgbm8mbmJzcDsgdGhyb3R0bGluZyBpcyBwZXJmb3JtZWQuJm5ic3A7IFJlcG9ydGlu
ZyBET0lDIGVuZHBvaW50cyBtYXkgdXNlIHRoaXMmbmJzcDsgaW5mb3JtYXRpb24gaW4gb3JkZXIg
dG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVwZGF0ZSB0aGUmbmJzcDsgcmVh
Y3RpbmcgRE9JQyBlbmRwb2ludCB3aXRoIHRoZSBsYXRlc3QgT0xSLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJh
Y2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlJm5ic3A7IHJlcG9y
dGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkgYW5zd2VyIGFzIHRoZSByZXBv
cnRpbmcgRE9JQyZuYnNwOyBlbmRwb2ludCBjYW5ub3Qga25vdyB3aGV0aGVyIHRoZSByZWFjdGlu
ZyBET0lDIGVuZHBvaW50IGlzIGFjdHVhbGx5IGRvaW5nJm5ic3A7IHRoZSByaWdodCB0aGluZyB3
aXRoIHJlZ2FyZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNt
IGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgRE9JQyZuYnNw
OyBlbmRwb2ludCB0byBkZXRlY3QgYW5kIGNvcnJlY3QgaW5hcHByb3ByaWF0ZSB0aHJvdHRsaW5n
IGJ5IHRoZSByZWFjdGluZyZuYnNwOyBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIg
cmVhc29uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4gVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0byBhZGRyZXNzIFJFUSAxOCBm
cm9tIFJGQyA3MDY4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiBJbiBzdW1tYXJ5IGl0IGlzIHByb3Bvc2VkIHRvIGRlZmluZSB0aGUgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIHRvJm5ic3A7IGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdl
cyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkRpTUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0
Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNlIG1lc3NhZ2UgZXQgc2Vz
IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl
bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZm
dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6
IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhw
ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg
bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBP
cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs
dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh
dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk
LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp
cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug
aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n
ZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRp
TUUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij5EaU1FIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5E
aU1FQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZGltZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGlNRSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86
RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RpbWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZGltZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGlu
ZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Js
b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DZSBtZXNzYWdl
IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg
Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5wYXMgZXRyZSBkaWZm
dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6
IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmEgbCdleHBlZGl0ZXVy
IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl
cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T3JhbmdlIGRlY2xpbmUg
dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg
b3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu
IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl
Y3RlZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo
b3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz
c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5rIHlvdS48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMg
cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu
dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p
dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz
c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg
YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg
ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl
IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFu
ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg
aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli
dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp
cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu
b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv
ciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1l
c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0
aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlm
ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl
eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0
IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl
bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSBy
ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz
aWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv
ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5IHNob3VsZCBu
b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHlvdSBoYXZl
IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh
bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVk
LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp
ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_087A34937E64E74E848732CFF8354B9209774C42ESESSMB101erics_--


From lionel.morand@orange.com  Thu Feb 13 08:04:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41F01A0312 for ; Thu, 13 Feb 2014 08:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNql8KKHE8PS for ; Thu, 13 Feb 2014 08:04:38 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2F71A02EA for ; Thu, 13 Feb 2014 08:04:37 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id C88A6C0552; Thu, 13 Feb 2014 17:04:35 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A77C11580D5; Thu, 13 Feb 2014 17:04:35 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 17:04:35 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb768GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3wFAgA==
Date: Thu, 13 Feb 2014 16:04:34 +0000
Message-ID: <16264_1392307475_52FCED13_16264_6720_1_6B7134B31289DC4FAF731D844122B36E4A147C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209774C42@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774C42@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 16:04:43 -0000

VG8gY2hhbmdlIHRoZSBmb3JtYXQgOikNCg0KDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogQmFydG9sb21lDQpFbnZvecOp
wqA6IGpldWRpIDEzIGbDqXZyaWVyIDIwMTQgMTQ6MTgNCsOAwqA6IGRpbWVAaWV0Zi5vcmcNCk9i
amV0wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
Zw0KDQpOaXJhdiwNCg0KRG8geW91IGNvbnNpZGVyIHRoYXQgb3ZlcmxvYWQgcmVwb3J0cyBjYW4g
b25seSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMgd2hlbiB0aGVyZSBhcmUgYWdlbnRz
IGluIHRoZSBwYXRoPw0KDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNh
bG90QGNpc2NvLmNvbV0gDQpTZW50OiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAxNCAxMzo1
OA0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTWFyaWEt
Q3J1eiwNCg0KUmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5IHNpbXBsZSBtZWNoYW5pc20g4oCT
IGFzIHBvaW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8gY29uY2x1ZGUgdGhhdCByZXBvcnQgaGFz
IHJlYWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4gYWxsIHRoZSBpbnRyYS1zZXNzaW9uIG1l
c3NhZ2VzIG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3ZlcmxvYWQgcmVwb3J0LCBpZiB0aGUg
c2Vzc2lvbiBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFpbnMgdGhlIG92ZXJsb2FkIHJlcG9y
dC4NCg0KU28geW91ciBub3RlIHJlZ2FyZGluZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gdGFrZSBp
bnRvIGFjY291bnQgdGhlIG5ldHdvcmsgZGVwbG95bWVudCBldGMuIGlzIG5vdCAxMDAlIGNvcnJl
Y3QuDQpMZXQgbWUgc2ltcGxpZnksIGhvcGluZyBpdCB3aWxsIHNhdGlzZnkgeW91ciBjb25jZXJu
Lg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQg
cmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhpcyBv
dmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUuDQoN
Ck5vdGUg4oCTIEluIHNvbWUgY2FzZXMsIGUuZy4gd2hlbiB0aGVyZSBhcmUgb25lIG9yIG11bHRp
cGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9k
ZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlcywg
dGhlIHJlcG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCB0aGUg
cmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9ydC4NCg0KUmVnYXJkcywNCk5pcmF2
Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAx
NCAyOjMxIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkRlYXIgYWxsLA0KDQpJIHRoaW5r
IHRoZW4gd2UgYWdyZWUgb24gdGhlIHByb3Bvc2VkIHRleHQ6DQoNCkEgcmVwb3J0aW5nIG5vZGUg
TVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQg
cmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1
ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rp
bmcgbm9kZXMuwqAgDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVk
ZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFj
dGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LsKgIFRoZSBvdmVybG9hZCByZXBv
cnQgd2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qg
c3VwcG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQg
YW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVl
IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2Fk
IHJlcG9ydC4NCg0KQnV0IHN0aWxsIHRoZXJlIGFyZSBzb21lIGRpc2NyZXBhbmNpZXMgYWJvdXQg
dGhlIG5vdGUuDQpNeSBwcm9wb3NhbCBpcyB0byBrZWVwIGl0IGp1c3QgYXMgYW4gaW5kaWNhdGlv
biBvZiBwb3RlbnRpYWwgKG1heWJlIG5vdCBhbGwpIHNpdHVhdGlvbnMgdGhhdCBzaG91bGQgYmUg
dGFrZW4gaW50byBhY2NvdW50IGlmIGV2ZXIgYW55IGltcGxlbWVudGF0aW9uIG1heSBjb25zaWRl
ciB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiB0aGF0IGEgcmVwb3J0aW5nIG5v
ZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMuIA0KQmVp
bmcgYSByZWNvbW1lbmRhdGlvbiBhbmQgbm90IGEgbXVzdCwgYXQgbGVhc3QgSSB0aGluayB3ZSBu
ZWVkIHRvIGluZGljYXRlIHdoYXQgbWF5IGltcGx5IHRvIGRvIG5vdCBmb2xsb3cgdGhlIHJlY29t
bWVuZGF0aW9uLiANClRoZW4gbXkgcHJvcG9zYWwgaXMgdGhlIGZvbGxvd2luZywgdGhhdCBpbmNs
dWRlcyBhIG1vZGlmaWNhdGlvbiB0byBsYXN0IHNlbnRlbmNlIGFib3ZlOg0KDQpBIHJlcG9ydGlu
ZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVh
Y3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhpcyBvdmVybG9hZCByZXBvcnQg
aXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUuDQoNCk5vdGUg4oCTdGhlIHJl
cG9ydGluZyBub2RlIG1heSBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50IG5ldHdvcmsgZGVwbG95
bWVudCBhbmQgcG90ZW50aWFsIGVycm9ycyBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGd1YXJhbnRl
ZSB0aGF0IHNlbnQgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9k
ZSwgZS5nLiB0aGVyZSBtYXkgYmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBi
ZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5
IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlc+KApg0KDQoNCkZyb206IERpTUUgW21haWx0
bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUUk9UVElOLCBKRUFOLUpBQ1FV
RVMgKEpFQU4tSkFDUVVFUykNClNlbnQ6IG1pw6lyY29sZXMsIDEyIGRlIGZlYnJlcm8gZGUgMjAx
NCAxMToxMw0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpIaSANCg0KT24gdGhpcyB0b3BpYywg
bXkgdmlldyBpcyB0aGF0IHRoZSByZWFjdGluZyBub2RlIHNoYWxsIMKgcmVjZWl2ZSDigJxlbm91
Z2jigJ0gT0xScyBwZXIgcGVyaW9kIG9mIHRpbWUgdG8gZW5zdXJlIHRoZSBlZmZpY2llbmN5IG9m
IHRoZSB0cmFmZmljIMKgcmVkdWN0aW9uIG1lY2hhbmlzbSAuIEEgd2F5IHRvIGFjaGlldmUgwqB0
aGUg4oCcZW5vdWdo4oCdIGlzIHRvIGhhdmUgYW4gT0xSIGluIGFsbCDCoGFuc3dlciDCoG1lc3Nh
Z2VzIGFzIHByb3Bvc2VkIGFuZCB0aGlzIGNhbiB0aGUgcmVjb21tZW5kZWQgd2F5LiBOb3cgYXMg
TmlyYXYgc2FpZCwgdGhlcmUgbWF5IGJlIHByb3RvY29sIGRlc2lnbiB0aGF0IHdpbGwgYmVoYXZl
IGRpZmZlcmVudGx5IGFuZCBzZW5kIOKAnGVub3VnaOKAnSBPTFJzIMKgYnV0IG5vdCBpbiBhbGwg
bWVzc2FnZXMuDQoNCkFzIGFsc28gTmlyYXYgbm90ZWQsIMKgSSBkbyBub3Qgd2VsbCBzZWUgdGhl
IG5lZWQgdG8gd3JpdGUgYWRkaXRpb25hbCBub3RlcyBhcyBtYW55IHNpdHVhdGlvbnMgY2FuIG9j
Y3VyIGFuZCDCoGFyZSBub3QgbGltaXRlZCB0byB0aGUgZXhhbXBsZSBvZiB0aGUgcmVhY3Rpbmcg
wqBub2RlIMKgZGlzY2FyZGluZyBPTFJzLg0KDQpCZXN0IHJlZ2FyZHMNCg0KSkphY3F1ZXMgDQoN
Cg0KDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0
IGRlIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0KRW52b3nDqcKgOiBtYXJkaSAxMSBmw6l2cmll
ciAyMDE0IDE2OjM1DQrDgMKgOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0K
T2JqZXTCoDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCkF0IGxlYXN0LCBpdCBpcyBjb3JyZWN0ISDimLoNCg0KRGXCoDogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6IEJhcnRvbG9t
ZQ0KRW52b3nDqcKgOiBtYXJkaSAxMSBmw6l2cmllciAyMDE0IDE1OjAwDQrDgMKgOiBkaW1lQGll
dGYub3JnDQpPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KTGlvbmVsLCBOaXJhdiwgYWxsLA0KDQpNYXliZSB0aGUgbm90ZSBjb3Vs
ZCBiZSBtb2RpZmllZDoNCg0KTm90ZSDigJN0aGUgcmVhY3Rpbmcgbm9kZSBjb3VsZCBiZSBhbnkg
YWdlbnQgaW4gdGhlIHBhdGgsIGFuZCB0aGF0IGluIHNvbWUgZXJyb3Igc2l0dWF0aW9ucyBvdmVy
bG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMuDQoNCkkgYWRk
ZWQgdGhlIGNhc2UgT0xSIGNvdWxkIGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlcywgc2lu
Y2UgaXQgaGlnaGxpZ2h0cyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmVyIHdpbGwgbm90IGtu
b3cgd2hldGhlciBvciBub3QgYSB2YWxpZCBPTFIgaXMgcmVjZWl2ZWQgYnkgcmVhY3Rpbmcgbm9k
ZS4NCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KDQpGcm9tOiBsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb20gW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dIA0KU2VudDogbWFydGVzLCAx
MSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MzYNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGlt
ZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9u
Z29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2
ZWQgYSB0aHJvdHRsaW5nDQoNCkF0IGxlYXN0LCBpdCBpcyBub3QgInRoZSBvbmx5IHN1cmUgd2F5
Ii4NCkZvciBpbnN0YW5jZSwgc3Vic2VxdWVudCBtZXNzYWdlcyBwYXJ0IG9mIHRoZSBzYW1lIHNl
c3Npb24gKG9yIHBzZXVkby1zZXNzaW9uKSBjb3VsZCBhbHNvIGJlIHVzZWQgYXMgaW5kaWNhdGlv
biBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRoYXQgdGhlIE9MUiBoYXMgYmVlbiByZWNlaXZlZCBi
eSB0aGUgcmVhY3Rpbmcgbm9kZSAoYmVzaWRlcyB0aGUgcmVjZXB0aW9uIG9mIHRoZSBPQy1TdXBw
b3J0ZWQtRmVhdHVyZXMgaW4gdGhlIHJlcXVlc3QpLg0KSXQgaXMgd2h5IEkgd2FzIHNheWluZyB0
aGF0IHRoaXMgY2FuIGJlIGZpeGVkIHBlciBhcHBsaWNhdGlvbi9zeXN0ZW0uDQoNCkxpb25lbA0K
DQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl
IE1hcmlhIENydXogQmFydG9sb21lDQpFbnZvecOpwqA6IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQg
MTE6MzENCsOAwqA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpGaW5lIE5pcmF2LCBJIGFncmVlIHRo
aXMgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpNeSBpbnRlbnRpb24gaXMgdGhhdCBhbnkg
cmVhZGVyIHJlYWxpemVzIHdoYXQgdGhpcyBrbm93bGVkZ2UgaW4gdGhlIHNlcnZlciBpbXBsaWVz
IHdoZW4gd2UgdGFsayBhYm91dCBhZ2VudHMgaW4gdGhlIHBhdGguIFRoaXMgaXMgd2h5IEkgdGhp
bmsgdGhpcyBub3RlIGlzIGhlbHBmdWwuDQoNClJlZ2FyZHMNCi9NQ3J1eg0KDQpGcm9tOiBOaXJh
diBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dIA0KU2VudDogbWFydGVz
LCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MjYNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsg
ZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nDQoNCkkgZG8gbm90IGFncmVlIHJlZ2FyZGluZyB0aGUgY29tcGxl
eGl0eSBzaW5jZSBpdCBpcyBoaWdobHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpMZXRzIG5v
dCBtYWtlIGFueSBhc3N1bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24uDQoNClJlZ2FyZHMs
DQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAx
MSwgMjAxNCAzOjU0IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkhlbGxvLA0KDQpJIHRo
aW5rIGl0IGlzIGltcG9ydGFudCB0byBoaWdobGlnaHQgY29tcGxleGl0eSBmb3IgdGhlIHNlcnZl
ciB0byDCoOKAnGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJl
Y2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQu4oCdIA0KSSB0aGluayB0aGlzIGlzIHRoZSBwdXJw
b3NlIG9mIHRoZSBzZW50ZW5jZSBhZGRlZCBieSBTdGV2ZS4NCg0KQ2hlZXJzDQovTUNydXoNCg0K
RnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5p
cmF2IFNhbG90IChuc2Fsb3QpDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAx
MToyMA0KVG86IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgU3RldmUgRG9ub3ZhbjsgZGltZUBp
ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29p
bmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQg
YSB0aHJvdHRsaW5nDQoNCkkgYW0gYWxzbyBmaW5lIHdpdGggU3RldmUncyBwcm9wb3NlZCB3b3Jk
aW5nIHRvIHJlY29tbWVuZCB0aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQgdG8gbm90IG1hbmRhdGUg
aXQuDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBh
YnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBhZGQgaXQuDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXks
IHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcg
bm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5n
IG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVu
dCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KDQpJIHByZWZlciB0byByZW1vdmUgaXQgc2luY2Ug
SSBkbyBub3Qgc2VlIGFzIHZhbHVlIGFkZGl0aW9uLiANCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpG
cm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlv
bmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEw
OjEzIFBNDQpUbzogU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkknbSBmaW5l
IHdpdGggYSByZWNvbW1lbmRhdGlvbi4NCg0KQnV0IEkgaGF2ZSBhIGdlbmVyYWwgY29tbWVudDog
d2hlbiBhIE1BWSBvciBldmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQg
aXQgaXMgTk9UIHVwIHRvIHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0byBkbyBzb21ldGhpbmcuIEl0
IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi4N
CkZvciBpbnN0YW5jZSwgb3ZlciBhIGdpdmVuIGludGVyZmFjZSwgdGhlIHJlbGF0ZWQgc3BlY2lm
aWNhdGlvbiBjYW4gc2F5IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1haW50YWluZWQgYnkgdGhlIHNl
cnZlci4gQW5kIGl0IGNvdWxkIGJlIGRlY2lkZWQgdG8gYWRkIHNvbWUgb3ZlcmxvYWQgcmVsYXRl
ZCBpbmZvIGluIHN1Y2ggc3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBub2RlIGNhbiB1
c2UgdGhpcyBzdGF0ZSB0byBrbm93IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVuIG5vdGlmaWVk
IG9yIG5vdCBmb3IgaW5zdGFuY2UuIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNlcnZlciBkb2Vz
IG5vdCBuZWVkIHRvIGluY2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVzc2FnZS4gSXQgaXMganVzdCBm
b3IgaWxsdXN0cmF0aW9uLiBUaGUgcG9pbnQgaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNl
cyBmb3Igd2hpY2ggdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVk
Lg0KDQpJIGFncmVlIHRoYXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIGlzIGZpbmXi
gKYgYnV0IGl0IHNob3VsZCBiZSBub3QgbWFuZGF0b3J5IGluIGFsbCBjYXNlcyBJIHRoaW5rLiBT
byBPSyBmb3IgYSAiU0hPVUxEIiBvciAiUkVDT01NRU5ERUQiLg0KDQpSZWdhcmRzLA0KDQpMaW9u
ZWwgDQoNCkRlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh
cnQgZGUgU3RldmUgRG9ub3Zhbg0KRW52b3nDqcKgOiBsdW5kaSAxMCBmw6l2cmllciAyMDE0IDE3
OjIxDQrDgMKgOiBkaW1lQGlldGYub3JnDQpPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBhZ3JlZSB3aXRoIGJvdGggTWFyaWEg
Q3J1eiBhbmQgTmlyYXYuIDotKQ0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBoYXZlIHdvcmRpbmcgc2F5
aW5nIHRoZSByZWNvbW1lbmRlZCBhcHByb2FjaCBpcyB0byBpbmNsdWRlIHRoZSBvdmVybG9hZCBy
ZXBvcnQgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQgYnkg
TWFyaWEgQ3J1ei7CoCANCg0KSSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBpbmNsdWRlIE5pcmF2J3Mg
cHJvcG9zYWwgdGhhdCBpZiBhIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgYSByZWFjdGluZyBu
b2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IG1heSBj
aG9vc2UgdG8gbm90IHNlbmQgaXQgYWdhaW4uwqAgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGlu
Y2x1ZGluZyBhbnl0aGluZyBhYm91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIGJ1dCB3
ZSBzaG91bGQgaW5jbHVkZSB3b3JkaW5nIGFib3V0IG5ldHdvcmtzIGFyY2hpdGVjdHVyZXMgdGhh
dCBtYWtlIGl0IGRpZmZpY3VsdCB0byBrbm93LsKgIFRoZSBjYXNlIG9mIGFnZW50cyBhY3Rpbmcg
YXMgcmVhY3Rpbmcgbm9kZXMgZm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4
YW1wbGUuDQoNCldlIGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQg
YXBwcm9hY2ggaXMgbm90IHByZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLg0KDQpJIHByb3Bv
c2UgdGhlIGZvbGxvd2luZyBub3JtYXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1l
bnRlZCBieSBNYXJpYSBDcnV6J3MgcmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92
ZXJsb2FkIHJlcG9ydCBpcyBhbHdheXMgaW5jbHVkZWQuDQoNCi0tLS0tDQoNCkEgcmVwb3J0aW5n
IG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3Zl
cmxvYWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2Rl
IGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8g
cmVhY3Rpbmcgbm9kZXMuwqAgDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28g
aW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5v
biByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LsKgIFRoZSBvdmVybG9h
ZCByZXBvcnQgd2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9l
cyBub3Qgc3VwcG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90
IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3Vh
cmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92
ZXJsb2FkIHJlcG9ydC4NCg0KTm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3By
aWV0YXJ5IG1lY2hhbmlzbXMsIHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2Vp
dmVkIGFuIG92ZXJsb2FkIHJlcG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xp
ZW50IGFuZCB0aGVyZSBpcyBubyBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBv
cnRpbmcgbm9kZS4NCk9uIDIvMTAvMTQgMzo1MiBBTSwgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgd3Jv
dGU6DQpIZWxsbyBOaXJhdiwNCg0KQW55IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVu
dCBmYWN0b3JzLCBlZmZpY2llbmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBw
ZXJzcGVjdGl2ZXMsIGJ1dCBmaXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdl
IGFyZSBkZWZpbmluZyBpcyBwcm92aWRpbmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLg0K
DQpZb3VyIHByb3Bvc2VkIHRleHTCoCANCiIgQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywg
ZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2Fk
IHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVw
b3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSBy
ZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINCg0KSWYgdGhlIHJl
cG9ydGluZyBpcyBub3QgYXdhcmUgYWJvdXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0
IGlzIHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2Ug
aXQgaXMgYSAibWF5IikgdG8gZG8gbm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9h
ZCBtaXRpZ2F0aW9uIG1lY2hhbmlzbSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3Qg
cHJvcGVybHkgcmVjZWl2ZWQgYnkgY29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9k
ZXMuIEFuZCB3ZSBuZWVkIHRvIG5vdGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxkIGJlIG5v
dCBvbmx5IHRoZSBjbGllbnQsIGJ1dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9u
bHkgd2hlbiB0aGUgYWdlbnQgaXMgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdo
ZW4gaXQgaXMgcmVhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4g
DQpUaGVuLCBvbiBvbmUgaGFuZCBpdCBpcyBub3Qgc2ltcGxlIHRvIGtub3cgd2hlbiByZWFjdGlu
ZyBub2RlcyBoYXZlIHZhbGlkIE9MUiBpbmZvIChhcyBleHBsYWluZWQgYmVsb3cpLCBidXQgaWYg
T0xSIGlzIG5vdCBzZW50IGFnYWluIChhcyBwZXIgeW91ciBwcm9wb3NlZCAibWF5IikgdGhlbiBv
bmUgb3IgbXVsdGlwbGUgcmVhY3Rpbmcgbm9kZXMgZG8gbm90IGhhdmUgdGhlIHJlcXVpcmVkIE9M
UiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIHdpbGwgbm90IHdvcmsuDQoNClRoZXJlZm9yZSwg
aW4gbXkgb3BpbmlvbiwgdGhlIHNpbXBsZXN0IHdheSB0byBwcm92aWRlIHJlcXVpcmVkIGluZm9y
bWF0aW9uIGlzIHRvIHByb3ZpZGUgT0xSIGluIEFMTCBhbnN3ZXJzLg0KDQpCZXN0IHJlZ2FyZHMN
Ci9NQ3J1eg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmlyYXYgU2Fsb3Qg
KG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXSANClNlbnQ6IGx1bmVzLCAxMCBkZSBm
ZWJyZXJvIGRlIDIwMTQgMTA6NDINClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRm
Lm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCkJ1dCBNYXJpYS1DcnV6LA0KDQpIb3cgY2FuIHdlIHNheSB0aGF0ICJpbmNs
dWRpbmcgdGhlIE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlcyBpcyBzaW1wbGUgYW5kIGVm
ZmljaWVudD8iDQpJdCBpcyBzaW1wbGUgZm9yIHN1cmUgYnV0IG5vdCBlZmZpY2llbnQuIA0KDQpB
IHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGZyb20gd2hhdCBJIHByb3Bvc2VkIGVhcmxpZXIg
aXMsIFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhIG5ldyBvdmVybG9hZCByZXBvcnQgdGhh
dCBuZWVkcyB0byBiZSBwcm92aWRlZCB0byBhIHJlYWN0aW5nIG5vZGUgKGJ5IHVwZGF0aW5nIHRo
ZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCBvciBieSBwcm92aWRpbmcgdGhlIG92
ZXJsb2FkIHJlcG9ydCBmb3IgdGhlIGZpcnN0IHRpbWUpLCBpdCBzaGFsbCBpbmNsdWRlIE9MUiBp
biB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZl
YXR1cmUgQVZQLCB0b3dhcmRzIHRoZSBjb3JyZXNwb25kaW5nIHJlYWN0aW5nIG5vZGUuIEFkZGl0
aW9uYWxseSwgaW4gb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMg
bm90IGF3YXJlIGlmIHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBwcm92aWRlZCB0byB0
aGUgcmVhY3Rpbmcgbm9kZSwgdGhlIHJlcG9ydGluZyBub2RlIG1heSBpbmNsdWRlIHRoZSBPTFIg
aW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlIEFWUC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0
IDM6MDMgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAj
MzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVz
c2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsIGFsbCwNCg0KSSB0aGlu
ayB3ZSBzaG91bGQgZGVmaW5lIGFuIGFjY3VyYXRlIGFuZCByb2J1c3Qgc29sdXRpb24sIGFzIGVm
ZmljaWVudCBhbmQgc2ltcGxlIGFzIHBvc3NpYmxlLg0KSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9z
YWwgYXMgYSBwdXJlICJtYXkiLCBidXQgbGVhdmluZyBpdCB1cCB0byBpbXBsZW1lbnRhdGlvbiBk
b2VzIG5vdCBhc3N1cmUgcmVhY3Rpbmcgbm9kZSBoYXMgdmFsaWQgT0xSIGluZm9ybWF0aW9uLCB3
aGF0IGlzIGJhc2ljIGZvciB0aGlzIG1lY2hhbmlzbSB0byB3b3JrLiANCg0KQmVzdCByZWdhcmRz
DQovTUNydXoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pcmF2IFNhbG90
IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IGx1bmVzLCAxMCBkZSBm
ZWJyZXJvIGRlIDIwMTQgMTA6MTINClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRm
Lm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNCk1hcmlhLUNydXosDQoNCkkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ugb24gInNl
bmRpbmcgT0xSIGluIEFMTCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzIi4N
CkFuZCB3ZSBhcmUgbm90IHRyeWluZyB0byBwcmV2ZW50IGl0IC0gYXQgbGVhc3QgdGhhdCBpcyBt
eSBpbnRlbnRpb24uIA0KQnV0IHRoZSBtYWluIHF1ZXN0aW9uIGlzLCBhcmUgd2UgdHJ5aW5nIHRv
IHByZXZlbnQgYW55IG90aGVyIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uLCB3aGljaCBtYXkgYmUg
c21hcnRlciBhbmQgY2FuIGF2b2lkIGluY2x1ZGluZyByZWR1bmRhbnQgT0xSIGluIGFsbCB0aGUg
YW5zd2VyIG1lc3NhZ2U/DQoNCk1vc3QgcHJvYmFibHksIHRoZSB2ZXJ5IGZpcnN0IGltcGxlbWVu
dGF0aW9uIG9mIG92ZXJsb2FkIGNvbnRyb2wgd2lsbCBpbmNsdWRlIE9MUiBpbiBhbGwgdGhlIGFu
c3dlciBtZXNzYWdlcy4NCkJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBJIGRvIG5vdCB3YW50IHRvIHJl
c3RyaWN0IHRoZSBkZXZlbG9wZXJzIHdoaWNoIGNhbiBjb21lIHVwIHdpdGggc29tZSBuaWNlIHR3
ZWFrcyBhbmQgdHJpY2tzIHRvIGF2b2lkIHNlbmRpbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4g
ZXZlcnkgbWVzc2FnZS4gQW5kIHRoaXMgaXMgd2hlcmUgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGFu
ZCBhdm9pZCBwdXR0aW5nIHN1Y2ggcmVzdHJpY3Rpb25zIGluIHByb3RvY29sIGRlZmluaXRpb24u
IA0KV2hhdCBkbyB5b3UgdGhpbms/DQoNClRoaXMgYWxzbyB0aGUgcmVhc29uIEkgd2FzIHN1Z2dl
c3RpbmcgbG9vc2UgZGVzY3JpcHRpb24gb2Ygd2hlbiB0byBpbmNsdWRlIE9MUiAoZnJvbSB0aGUg
cmVwb3J0aW5nIG5vZGUgcG9pbnQgb2YgdmlldykuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KU2VudDogRnJpZGF5
LCBGZWJydWFyeSAwNywgMjAxNCA4OjU3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDog
UmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZv
IEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkhl
bGxvIFVscmljaCwgTmlyYXYsDQoNCkkgYWdyZWUgd2l0aCBVbHJpY2ggdGhhdCB0aGUgdGV4dCBw
cm92aWRlZCBieSBOaXJhdiBpcyBqdXN0IGEgTUFZLCBhbmQgd2hldGhlciBvciBub3QgdGhlIHNl
cnZlciBzZW5kcyBhbiBPTFIgaW4gYWxsIGFuc3dlcnMgc2hhbGwgbm90IGJlIGp1c3QgYSBNQVku
DQoNCk9uIHRoZSBvdGhlciBoYW5kLCBjcml0ZXJpYSBwcm92aWRlZCBieSBVbHJpY2ggb24gd2hl
biBPTFIgaGFzIHRvIGJlIHNlbnQgcmVxdWlyZXMgdGhlIHNlcnZlciBoYXMgc29tZSBrbm93bGVk
Z2U6DQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBo
YXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBu
b3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dz
IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhw
aXJlDQpjKSBvdGhlcndpc2UNCg0KUmVwb3J0aW5nIG5vZGUgbXVzdCBoYXZlIHNvbWUga25vd2xl
ZGdlIGFib3V0IE9MUiByZWNlcHRpb24vc3RhdHVzIGluIHJlYWN0aW5nIG5vZGUuIEhvdyBkb2Vz
IHNlcnZlciBhY3F1aXJlIHRoaXMga25vd2xlZGdlPyANClRha2UgaW50byBhY2NvdW50IGFzIHdl
bGwgdGhhdCBhICJyZWFjdGluZyIgbm9kZSBtYXkgYmUgYm90aCBhbiBBZ2VudCAoaW4gY2FzZSBp
dCBwcm92aWRlcyBzZXJ2aWNlIHRvIGEgcmVhbG0gb3IgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIG5v
bi1zdXBwb3J0aW5nIGNsaWVudCnCoCBhbmQgYSBDbGllbnQuIEluIHRoZSBjYXNlIG9mIEFnZW50
cywgaW4gZmFjdCB0aGUgU2VydmVyIG1heSBub3QgZXZlbiBrbm93IGlmIHRoaXMgaXMgZ29pbmcg
dG8gYWN0IGFzIGEgcmVhY3Rpbmcgbm9kZSBvciBqdXN0IHRyYW5zcGFyZW50bHksIGluIGZhY3Qs
IHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBoYXZlIGFueSBrbm93bGVkZ2UgYWJvdXQgd2hh
dCBhZ2VudHMgaW4gdGhlIGNoYWluIHRvIHRoZSBmaW5hbCBDbGllbnQuDQoNClRoZXJlZm9yZSwg
SSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgc2VuZGluZyBPTFIgaW4gQUxMIGFuc3dlcnMgaGFzIHNv
bWUgaW1wb3J0YW50IGFkdmFudGFnZXM6DQotIHN0YXRlLWxlc3MgaW1wbGVtZW50YXRpb24gKHRy
YW5zYWN0aW9uIG9yIHNlc3Npb24pIGlzIHNpbXBsZXIsDQotIHRoZSBzZXJ2ZXIgZG9lcyBub3Qg
bmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gc2VuZCBhbiBPTCB0byBhIHJlYWN0
aW5nIG5vZGUNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGJvdGhlciB3aGV0aGVyIGFu
IHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gT0xSIG9yIHdoZXRoZXIgdGhp
cyBPTFIgaXMgc3RpbGwgdmFsaWQgKGhhcyBub3QgZXhwaXJlZCkuDQotIHNlbmRpbmcgYW4gYWRk
aXRpb25hbCBBVlAgaXMgbm90IHByb2Nlc3NpbmcgY29uc3VtaW5nLCBpbiBjb21wYXJpc29uIHdp
dGggcmVxdWlyZWQgYWJvdmUgY2hlY2tzIChpZiB0aGlzIGlzIG5vdCBzZW50KS4gDQrCoCBJbiBm
YWN0LCBpbiBhbiBvdmVybG9hZCBzaXR1YXRpb24sIHRoZSBlYXNpZXN0IGFuZCBsZWFzdCBjb21w
bGV4IGlzIHRvIHNlbmQgaW5mb3JtYXRpb24gb3V0IHRvIGFsbCBhZmZlY3RlZC9hcHBsaWNhYmxl
IG5vZGVzLCANCsKgIGFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNhcmUgdG8gdGFrZSBhcHBy
b3ByaWF0ZSBhY3Rpb25zwqAgDQotIG1vcmUgcm9idXN0IHNvbHV0aW9uLCBhcyBubyBuZWVkIHRv
IGNhdGVyIGZvciBhbGwgdGhlIGNoZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5kIGluZm9ybWF0aW9u
LMKgIGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlzIGxvc3QswqAg4oCm
DQoNCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpDQpTZW50OiB2aWVybmVzLCAwNyBkZSBmZWJy
ZXJvIGRlIDIwMTQgMTA6NTkNClRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb207IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRs
aW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxp
bmcNCg0KTmlyYXYsDQoNCkknbSBhZnJhaWQgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHJl
ZmxlY3QgdGhlIGludGVudGlvbi4NCg0KIndoZW4gaXQgd2FudHMgdG8gcHJvdmlkZS91cGRhdGUu
Li4uaXQgc2hhbGwgaW5jbHVkZS4uLiIgdHJhbnNsYXRlcyB0byAiLi4uaXQgbWF5IGluY2x1ZGUu
Li4iLg0KDQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0IHRyYW5zbGF0ZXMg
dG8gIndoZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4uLiINCg0KDQpXZSBo
YXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6DQphKSB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhh
dCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVzdCBPTFINCmIpIHRo
ZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2VzIG5vdCB3YW50IGEg
dGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGdvdCBhbiBP
TFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlDQpjKSBvdGhlcndpc2UNCg0KaW4gY2FzZSBhKSB0aGUg
cmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFIgaW4gY2FzZSBiKSB0
aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUgcmVhY3Rpbmcgbm9k
ZSB3aXRoIHRoZSBsYXRlc3QgT0xSIGluIGNhc2UgYykgdGhlIHJlcG9ydGluZyBub2RlIE1VU1Qg
aW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcgbm9kZSBkb2VzIG5v
dCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIHJlcGxheSBvciBhbiB1cGRhdGUpDQoNClVscmljaA0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgTmlyYXYgU2Fsb3QgKG5z
YWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5
IDA2LCAyMDE0IDQ6NDkgUE0NClRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBl
eHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRm
Lm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmct
VGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0
aHJvdHRsaW5nDQoNClVscmljaCwNCg0KSXQgc2VlbXMgd2UgYWxsIGFyZSBvbiBzYW1lIHBhZ2Ug
YnV0IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5vdCB0aGUgYmVzdC4N
CkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLg0KDQpXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSB3YW50
cyB0byBwcm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQgb3Igd2FudHMgdG8gdXBkYXRlIHRoZSBl
YXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVhY3Rpbmcgbm9kZSwg
aXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250
YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGlu
ZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4g
dGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlz
IGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9k
ZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29u
dGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERF
L011bmljaCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBG
ZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNDQpUbzogZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bTsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3Jn
DQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcNCg0KTmlyYXYsIExpb25lbCwNCg0KSSBjYW4gdW5kZXJzdGFuZCBOaXJhdidzIGNvbmNl
cm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBhZGRyZXNzZWQgYnkg
dGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzoNCg0KMicuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8g
bWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVy
biBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1
cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2Rl
IGFscmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wgaW5mb3JtYXRpb24g
KGUuZy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVxdWVzdGluZyB0cmFm
ZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3ZlcmxvYWQiLCBvciBhbiBv
bGTCoCBidXQgc29vbiBleHBpcmluZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90
IG92ZXJsb2FkZWQpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUg
cmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNU
IHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBh
biBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkkgZG9uJ3QgYWdyZWUgd2l0aCBMaW9uZWxz
IGRvLXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJsb2FkIGNvbnRyb2wgd2lsbCBub3Qgd29y
ayB3aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBkYXRlIHJlYWN0aW5n
IG5vZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50bHkpIGF3YXJlIG9mIHRoZSBjdXJyZW50
IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRlIE9MUnMuDQoNClVscmljaMKgIA0KDQoN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBsaW9uZWwubW9yYW5kQG9y
YW5nZS5jb20gW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2Rh
eSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsg
V2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVA
aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBE
aU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNh
bG90IChuc2Fsb3QpIEVudm95w6nCoDogamV1ZGkgNiBmw6l2cmllciAyMDE0IDEwOjA4IMOAwqA6
IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1l
QGlldGYub3JnIE9iamV0wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1Pbmdv
aW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVk
IGEgdGhyb3R0bGluZw0KDQpVbHJpY2gsDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgZm9yY2luZyB0
aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2RlICJvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMg
bm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJs
b2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3Rz
IHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuIg0KVGhlIHJlcG9y
dGluZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5nIHRoYXQgdGhlIGVh
cmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rpbmcgbm9kZSB3aWxs
IHN0b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy4NCg0KW0xNXSBBZ3JlZS4gSW4gb3RoZXIgd29y
ZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0IG1lY2hhbmlzbSBk
ZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBk
ZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyIG1heSBkZXBlbmQgb24gdGhl
IGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVhc3QsIGl0IGlzIG15
IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4NCg0KQXMgd2UgaGFkIGRpc2N1c3NlZCBlYXJsaWVyLCB0
aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhwbGljaXRseSBzdG9w
IHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1lIHRpbWUuIEluIG90
aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBuYXR1cmFsIGV4cGly
eSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBzaWduYWxpbmcgdHJh
ZmZpYyB0b3dhcmRzIGl0Lg0KDQpbTE1dIEFncmVlDQoNClRoZXJlIG1heSBiZSBvdGhlciBjYXNl
cywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRoZSBsYXN0IG92ZXJs
b2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFzdCwgdGhlcmUgaXMg
bm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRoZXJlIGlzIG5vIG92
ZXJsb2FkIGNvbmRpdGlvbi4NCg0KW0xNXSBBZ3JlZQ0KDQpSZXN0IG9mIHRoZSBwcmluY2lwbGVz
IGJlbG93IGFyZSBmaW5lIHdpdGggbWUuDQoNCltMTV0gQWdyZWUNCg0KUmVnYXJkcywNCk5pcmF2
Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2llaGUsIFVscmljaCAoTlNO
IC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0KU2VudDogVGh1cnNk
YXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE0NClRvOiBleHQgU3RldmUgRG9ub3ZhbjsgTmly
YXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBY3R1YWxseSB3ZSBzZWVt
IHRvIGFncmVlIG9uIHR3byBwcmluY2lwbGVzOg0KMS4gTGFjayBvZiBPTFIgbWVhbnMgIm5vIGNo
YW5nZSINCjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRl
ZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8g
cmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBp
dCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCB0aGUgbGF0
ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZmaWMgcmVkdWN0aW9u
IG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIpOyBvdGhlcndpc2UgKGkuZS4gaWYg
aXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVy
IG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJl
cXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkNh
biBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uDQoNClVscmljaA0KDQpGcm9tOiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NClNl
bnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0KVG86IE5pcmF2IFNhbG90
IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQWdyZWVkLsKgIFRvIHJlc3RhdGUgLS0g
bGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRoZSBjdXJyZW50IG92
ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS7CoCBJZiB0aGVyZSBpcyBhIGN1cnJl
bnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVzIHRvIGFwcGx5IHVu
dGlsIGl0IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFuZ2VkIHdpdGggYSBu
ZXcgb3ZlcmxvYWQgcmVwb3J0LsKgIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRseSBhY3RpdmUgb3Zl
cmxvYWQgcmVwb3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgaW1wbGllcyB0aGVy
ZSBpcyBubyBvdmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQpTdGV2ZQ0KT24gMi81
LzE0IDk6MTkgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KSSBhZ3JlZSB3aXRoIFN0
ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIgYmUgaW50ZXJwcmV0
ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KwqANCldlIGhhZCBzb21lIGRpc2N1c3Npb24gc29tZXRp
bWUgYmFjayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbm90IG1hbmRhdGUg
dGhlIHNlcnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuIEUu
Zy4gd2hlbiB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hhdCBpcyBzZW50IHRv
IHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGluZyBpbmZvcm1hdGlv
biB3aGljaCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGltcGxlbWVudGF0aW9u
IGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQgZnJvbSBwcm90b2Nv
bCBwb2ludCBvZiB2aWV3Lg0KwqANClNvIGJhc2ljYWxseSwgdGhlIGxhY2sgb2YgT0xSIHNob3Vs
ZCBub3QgYWZmZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0aGUgcmVhY3Rpbmcg
bm9kZS4gVGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0IGJhc2VkIG9uIG9s
ZGVyIE9MUiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJpb2Qgb3Igd2hlbiB0
aGUgZXhwbGljaXQgT0xSIHdpdGggIjAiIG92ZXJsb2FkLW1ldHJpYyBpcyByZWNlaXZlZC4NCklu
IG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbiBhdCB0aGUg
cmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0aGUgcmVhY3Rpbmcg
bm9kZS4NCsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NClNlbnQ6IFdlZG5l
c2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODowMCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1Ympl
Y3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
wqANCmlubGluZQ0KT24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011
bmljaCkgd3JvdGU6DQpPayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0aW5nIG5vZGVzIE1V
U1QgaW5zZXJ0IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdlcyB0aGF0IGNvcnJl
c3BvbmQgdG8gcmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1G
ZWF0dXJlcyBBVlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyByZXF1ZXN0ZWQpLg0K
U1JEPiBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0IGxhY2sgb2YgYW4g
T0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCsKgDQrCoA0KT3RoZXIg
Y3JpdGVyaWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBtYXR0ZXIuDQpTUkQ+
IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2VyIGRvZXMgZGlyZWN0
bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBub2RlIHRvIGxvb2sg
Zm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVyeSBtZXNzYWdlIGlz
IGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxseSBtb3JlIGV4cGVu
c2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLg0KDQoNCsKgDQrCoA0KRm9yIG15IGNsYXJpZmljYXRp
b246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVxdWlyZWQgdG8gcHJv
Y2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUgcmVwbGF5cyBhbnl3
YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUgaW4g
b3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJzIGFuZCBhdCB0aGUg
c2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9MUj8NClNSRD4gVGhh
dCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoNCsKgDQrCoA0KwqAN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTZW50
OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBsaW9uZWwubW9yYW5k
QG9yYW5nZS5jb207IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkgc2hhcmUgdGhlIHNhbWUgb3Bp
bmlvbiBhcyBMaW9uZWwuDQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBUdWVzZGF5LCBGZWJy
dWFyeSAwNCwgMjAxNCA5OjA3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtE
aW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KSSB1bmRl
cnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBE
T0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28gdGhlIG9wdGlvbnMg
d291bGQgYmU6DQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0gT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIgQVZQIGluIHNvbWUg
YW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQgYnkgdGhlIGNsaWVu
dCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KwqANCklmIHRoZXJlIGlzIG5vIG90aGVyIGNyaXRlcmlv
biwgdGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KwqANCkxpb25lbA0KwqAN
Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1ZSB0cmFja2VyIFtt
YWlsdG86dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOpwqA6IG1hcmRpIDQg
ZsOpdnJpZXIgMjAxNCAwOTo0OQ0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBk
aW1lQGlldGYub3JnDQpPYmpldMKgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nDQrCoA0KIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBp
biByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIEl0IGhh
cyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgdGhhdCBpc8KgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBET0lDIGVuZHBvaW50
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdMKgIHN1cnZpdmVkIGEgdGhyb3R0bGluZy4gVGhpcyBB
VlAgd291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KIChUaW1lU3RhbXApIG9mIHRo
ZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGljaCB3YXMNCiBzdXJ2
aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGljYXRlcyB0aGF0IGN1
cnJlbnRseSBub8KgIHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLsKgIFJlcG9ydGluZyBET0lDIGVu
ZHBvaW50cyBtYXkgdXNlIHRoaXPCoCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBkZXRlY3Qgd2hl
dGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZcKgIHJlYWN0aW5nIERPSUMgZW5kcG9p
bnQgd2l0aCB0aGUgbGF0ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMgZmVlZGJhY2sgbWVjaGFu
aXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlwqAgcmVwb3J0aW5nIG5vZGUgdG8g
c2VuZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9ydGluZyBET0lDwqAg
ZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBp
cyBhY3R1YWxseSBkb2luZ8KgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2FyZCB0byB0aHJvdHRs
aW5nL25vdCB0aHJvdHRsaW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20gaW1wcm92ZXMgcm9i
dXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5kcG9pbnQgdG8gZGV0
ZWN0IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0aGUgcmVhY3RpbmfC
oCBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4NCiBUaGUgZmVlZGJh
Y2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZyb20gUkZDIDcwNjgu
DQogSW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCB0b8KgIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZy4NCsKgDQrCoA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN
CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu
Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg
ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh
dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs
ZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp
ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs
ZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj
ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv
ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRo
ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo
b3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl
IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp
ZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpE
aU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1h
aWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50
ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw
cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p
dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz
c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQg
bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs
ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNs
aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv
cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh
dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl
ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk
ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJl
IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl
biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN
CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu
Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg
ZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz
YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog
bGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg
cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp
YmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz
aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoN
ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7
DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg
YXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is
IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz
IGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp
YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs
c2lmaWVkLg0KVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg
am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz
IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBl
eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj
ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1
ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn
ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3Jhbmdl
IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs
IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh
Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv
biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry
aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg
YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBt
YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2
ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl
cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2
ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv
cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs
ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl
cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw
dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg
c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK
VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs
IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK
dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1
dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl
IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp
ZWQuClRoYW5rIHlvdS4KCg==


From maria.cruz.bartolome@ericsson.com  Thu Feb 13 08:12:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A801A0321 for ; Thu, 13 Feb 2014 08:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu_znp9nZ2e3 for ; Thu, 13 Feb 2014 08:12:27 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 020E21A0330 for ; Thu, 13 Feb 2014 08:12:25 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-1b-52fceee805f1
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 20.38.23809.8EEECF25; Thu, 13 Feb 2014 17:12:24 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 17:12:23 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3xHXAP++EOsg
Date: Thu, 13 Feb 2014 16:12:23 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774F1F@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <52F24ACE.6080501@usdonovans.com>  <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net>  <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209774C42@ESESSMB101.ericsson.se> <16264_1392307475_52FCED13_16264_6720_1_6B7134B31289DC4FAF731D844122B36E4A147C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <16264_1392307475_52FCED13_16264_6720_1_6B7134B31289DC4FAF731D844122B36E4A147C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvje6Ld3+CDC5fE7KY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGduf3GcvWNTKXLHn6yHWBsYlv5m6GDk5JARMJD79u8AOYYtJ XLi3nq2LkYtDSOAQo8TsLQ3MEM4SRolJ+5rZQKrYBOwkLp1+AdTNwSEioCxx+pcDSFhYoFzi 5aUrzCC2iECFxOetl5hAekUEfjFKnD2+gwUkwSKgKrH0wguwbbwCvhIXV/SwQiz4JiDx9MtU RhCHU6ANaPVDiFGMQDd9P7UG7FZmAXGJW0/mQ90tILFkz3lmCFtU4uXjf6wQtpLEotufwa5j FtCUWL9LH6JVUWJK90OoxYISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFSN7bmJmTnq50SZG YPAf3PJbdQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBYoJij 0bZvweGIWZMjxGoSxF7JO66+mOH28OXeC7VCu2fPUO9/HrrbtehxWNqW9wHRjQvfsCQ3ZR9J +TXN1LnKvDZQ0tpQMHXCsUt1X1gWBMg87la6q7P6xeZZKXcUU+K3C2zbsumq2+fPXWyTrsy+ P2/Ch33KMR+TA+zWiqdutRL3/DPN/ESXEktxRqKhFnNRcSIA03hjaUwCAAA=
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 16:12:35 -0000

SSBoYXZlIHJlY2VpdmVkIG1haWxzIG91dCBvZiBvcmRlci4uLiANCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSBbbWFpbHRvOmxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbV0gDQpTZW50OiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAx
NCAxNzowNQ0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0
OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
VG8gY2hhbmdlIHRoZSBmb3JtYXQgOikNCg0KDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogQmFydG9sb21lIEVudm95w6nC
oDogamV1ZGkgMTMgZsOpdnJpZXIgMjAxNCAxNDoxOCDDgMKgOiBkaW1lQGlldGYub3JnIE9iamV0
wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQpOaXJhdiwNCg0KRG8geW91IGNvbnNpZGVyIHRoYXQgb3ZlcmxvYWQgcmVwb3J0cyBjYW4gb25s
eSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMgd2hlbiB0aGVyZSBhcmUgYWdlbnRzIGlu
IHRoZSBwYXRoPw0KDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90
QGNpc2NvLmNvbV0NClNlbnQ6IGp1ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDEzOjU4DQpU
bzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpNYXJpYS1DcnV6
LA0KDQpSZXBvcnRpbmcgbm90ZSBtYXkgdXNlIHZlcnkgc2ltcGxlIG1lY2hhbmlzbSDigJMgYXMg
cG9pbnRlZCBvdXQgYnkgTGlvbmVsIOKAkyB0byBjb25jbHVkZSB0aGF0IHJlcG9ydCBoYXMgcmVh
Y2hlZCB0aGUgcmVhY3Rpbmcgbm9kZSwgaS5lLiBhbGwgdGhlIGludHJhLXNlc3Npb24gbWVzc2Fn
ZXMgbmVlZCBub3QgY29udGFpbiB0aGUgc2FtZSBvdmVybG9hZCByZXBvcnQsIGlmIHRoZSBzZXNz
aW9uIGVzdGFibGlzaG1lbnQgbWVzc2FnZSBjb250YWlucyB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0K
DQpTbyB5b3VyIG5vdGUgcmVnYXJkaW5nIHRoZSByZXBvcnRpbmcgbm9kZSB0byB0YWtlIGludG8g
YWNjb3VudCB0aGUgbmV0d29yayBkZXBsb3ltZW50IGV0Yy4gaXMgbm90IDEwMCUgY29ycmVjdC4N
CkxldCBtZSBzaW1wbGlmeSwgaG9waW5nIGl0IHdpbGwgc2F0aXNmeSB5b3VyIGNvbmNlcm4uDQoN
CkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBv
cnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGlzIG92ZXJs
b2FkIHJlcG9ydCBpcyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KTm90
ZSDigJMgSW4gc29tZSBjYXNlcywgZS5nLiB3aGVuIHRoZXJlIGFyZSBvbmUgb3IgbXVsdGlwbGUg
YWdlbnRzIGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlczsg
b3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLCB0aGUg
cmVwb3J0aW5nIG5vZGUgbWF5IG5vdCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFj
dGluZyBub2RlIGhhcyByZWNlaXZlZCB0aGUgcmVwb3J0Lg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoN
CkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN
YXJpYSBDcnV6IEJhcnRvbG9tZQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDI6
MzEgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KRGVhciBhbGwsDQoNCkkgdGhpbmsgdGhl
biB3ZSBhZ3JlZSBvbiB0aGUgcHJvcG9zZWQgdGV4dDoNCg0KQSByZXBvcnRpbmcgbm9kZSBNVVNU
IGVuc3VyZSB0aGF0IGFsbCByZWFjdGluZyBub2RlcyByZWNlaXZlIG5ldyBvdmVybG9hZCByZXBv
cnRzLg0KDQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBv
dmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBu
b2Rlcy7CoCANCg0KTm90ZSAtIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgYWxzbyBpbmNsdWRlIHRo
ZSBvdmVybG9hZCByZXBvcnQgaW4gYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gbm9uIHJlYWN0aW5n
IG5vZGVzIGlmIHRoYXQgaXMgbW9yZSBlZmZpY2llbnQuwqAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3
aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBw
b3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBv
dmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhh
dCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVw
b3J0Lg0KDQpCdXQgc3RpbGwgdGhlcmUgYXJlIHNvbWUgZGlzY3JlcGFuY2llcyBhYm91dCB0aGUg
bm90ZS4NCk15IHByb3Bvc2FsIGlzIHRvIGtlZXAgaXQganVzdCBhcyBhbiBpbmRpY2F0aW9uIG9m
IHBvdGVudGlhbCAobWF5YmUgbm90IGFsbCkgc2l0dWF0aW9ucyB0aGF0IHNob3VsZCBiZSB0YWtl
biBpbnRvIGFjY291bnQgaWYgZXZlciBhbnkgaW1wbGVtZW50YXRpb24gbWF5IGNvbnNpZGVyIHRv
IGRvIG5vdCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBp
bmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNzYWdlcy4gDQpCZWluZyBh
IHJlY29tbWVuZGF0aW9uIGFuZCBub3QgYSBtdXN0LCBhdCBsZWFzdCBJIHRoaW5rIHdlIG5lZWQg
dG8gaW5kaWNhdGUgd2hhdCBtYXkgaW1wbHkgdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVjb21tZW5k
YXRpb24uIA0KVGhlbiBteSBwcm9wb3NhbCBpcyB0aGUgZm9sbG93aW5nLCB0aGF0IGluY2x1ZGVz
IGEgbW9kaWZpY2F0aW9uIHRvIGxhc3Qgc2VudGVuY2UgYWJvdmU6DQoNCkEgcmVwb3J0aW5nIG5v
ZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGlu
ZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGlzIG92ZXJsb2FkIHJlcG9ydCBpcyBh
bHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KTm90ZSDigJN0aGUgcmVwb3J0
aW5nIG5vZGUgbWF5IG5lZWQgdG8gdGFrZSBpbnRvIGFjY291bnQgbmV0d29yayBkZXBsb3ltZW50
IGFuZCBwb3RlbnRpYWwgZXJyb3JzIGluIG9yZGVyIHRvIGJlIGFibGUgdG8gZ3VhcmFudGVlIHRo
YXQgc2VudCBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLCBl
LmcuIHRoZXJlIG1heSBiZSBvbmUgb3IgbXVsdGlwbGUgYWdlbnRzIGluIHRoZSBwYXRoIGJldHdl
ZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlczsgb3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUg
ZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVz4oCmDQoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRST1RUSU4sIEpFQU4tSkFDUVVFUyAo
SkVBTi1KQUNRVUVTKQ0KU2VudDogbWnDqXJjb2xlcywgMTIgZGUgZmVicmVybyBkZSAyMDE0IDEx
OjEzDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkhpIA0KDQpPbiB0aGlzIHRvcGljLCBteSB2
aWV3IGlzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgc2hhbGwgwqByZWNlaXZlIOKAnGVub3VnaOKA
nSBPTFJzIHBlciBwZXJpb2Qgb2YgdGltZSB0byBlbnN1cmUgdGhlIGVmZmljaWVuY3kgb2YgdGhl
IHRyYWZmaWMgwqByZWR1Y3Rpb24gbWVjaGFuaXNtIC4gQSB3YXkgdG8gYWNoaWV2ZSDCoHRoZSDi
gJxlbm91Z2jigJ0gaXMgdG8gaGF2ZSBhbiBPTFIgaW4gYWxsIMKgYW5zd2VyIMKgbWVzc2FnZXMg
YXMgcHJvcG9zZWQgYW5kIHRoaXMgY2FuIHRoZSByZWNvbW1lbmRlZCB3YXkuIE5vdyBhcyBOaXJh
diBzYWlkLCB0aGVyZSBtYXkgYmUgcHJvdG9jb2wgZGVzaWduIHRoYXQgd2lsbCBiZWhhdmUgZGlm
ZmVyZW50bHkgYW5kIHNlbmQg4oCcZW5vdWdo4oCdIE9MUnMgwqBidXQgbm90IGluIGFsbCBtZXNz
YWdlcy4NCg0KQXMgYWxzbyBOaXJhdiBub3RlZCwgwqBJIGRvIG5vdCB3ZWxsIHNlZSB0aGUgbmVl
ZCB0byB3cml0ZSBhZGRpdGlvbmFsIG5vdGVzIGFzIG1hbnkgc2l0dWF0aW9ucyBjYW4gb2NjdXIg
YW5kIMKgYXJlIG5vdCBsaW1pdGVkIHRvIHRoZSBleGFtcGxlIG9mIHRoZSByZWFjdGluZyDCoG5v
ZGUgwqBkaXNjYXJkaW5nIE9MUnMuDQoNCkJlc3QgcmVnYXJkcw0KDQpKSmFjcXVlcyANCg0KDQoN
CkRlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUg
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIEVudm95w6nCoDogbWFyZGkgMTEgZsOpdnJpZXIgMjAx
NCAxNjozNSDDgMKgOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZyBPYmpldMKg
OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
QXQgbGVhc3QsIGl0IGlzIGNvcnJlY3QhIOKYug0KDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogQmFydG9sb21lIEVudm95
w6nCoDogbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxNTowMCDDgMKgOiBkaW1lQGlldGYub3JnIE9i
amV0wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGlu
Zw0KDQpMaW9uZWwsIE5pcmF2LCBhbGwsDQoNCk1heWJlIHRoZSBub3RlIGNvdWxkIGJlIG1vZGlm
aWVkOg0KDQpOb3RlIOKAk3RoZSByZWFjdGluZyBub2RlIGNvdWxkIGJlIGFueSBhZ2VudCBpbiB0
aGUgcGF0aCwgYW5kIHRoYXQgaW4gc29tZSBlcnJvciBzaXR1YXRpb25zIG92ZXJsb2FkIHJlcG9y
dHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlcy4NCg0KSSBhZGRlZCB0aGUgY2Fz
ZSBPTFIgY291bGQgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLCBzaW5jZSBpdCBoaWdo
bGlnaHRzIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBzZXJ2ZXIgd2lsbCBub3Qga25vdyB3aGV0aGVy
IG9yIG5vdCBhIHZhbGlkIE9MUiBpcyByZWNlaXZlZCBieSByZWFjdGluZyBub2RlLg0KDQpCZXN0
IHJlZ2FyZHMNCi9NQ3J1eg0KDQoNCkZyb206IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSBbbWFp
bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbV0NClNlbnQ6IG1hcnRlcywgMTEgZGUgZmVicmVy
byBkZSAyMDE0IDExOjM2DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcN
ClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQpBdCBsZWFzdCwgaXQgaXMgbm90ICJ0aGUgb25seSBzdXJlIHdheSIuDQpGb3IgaW5z
dGFuY2UsIHN1YnNlcXVlbnQgbWVzc2FnZXMgcGFydCBvZiB0aGUgc2FtZSBzZXNzaW9uIChvciBw
c2V1ZG8tc2Vzc2lvbikgY291bGQgYWxzbyBiZSB1c2VkIGFzIGluZGljYXRpb24gZm9yIHRoZSBy
ZXBvcnRpbmcgbm9kZSB0aGF0IHRoZSBPTFIgaGFzIGJlZW4gcmVjZWl2ZWQgYnkgdGhlIHJlYWN0
aW5nIG5vZGUgKGJlc2lkZXMgdGhlIHJlY2VwdGlvbiBvZiB0aGUgT0MtU3VwcG9ydGVkLUZlYXR1
cmVzIGluIHRoZSByZXF1ZXN0KS4NCkl0IGlzIHdoeSBJIHdhcyBzYXlpbmcgdGhhdCB0aGlzIGNh
biBiZSBmaXhlZCBwZXIgYXBwbGljYXRpb24vc3lzdGVtLg0KDQpMaW9uZWwNCg0KRGXCoDogRGlN
RSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6
IEJhcnRvbG9tZSBFbnZvecOpwqA6IG1hcmRpIDExIGbDqXZyaWVyIDIwMTQgMTE6MzEgw4DCoDog
ZGltZUBpZXRmLm9yZyBPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KRmluZSBOaXJhdiwgSSBhZ3JlZSB0aGlzIGlzIGltcGxlbWVu
dGF0aW9uIHNwZWNpZmljLg0KTXkgaW50ZW50aW9uIGlzIHRoYXQgYW55IHJlYWRlciByZWFsaXpl
cyB3aGF0IHRoaXMga25vd2xlZGdlIGluIHRoZSBzZXJ2ZXIgaW1wbGllcyB3aGVuIHdlIHRhbGsg
YWJvdXQgYWdlbnRzIGluIHRoZSBwYXRoLiBUaGlzIGlzIHdoeSBJIHRoaW5rIHRoaXMgbm90ZSBp
cyBoZWxwZnVsLg0KDQpSZWdhcmRzDQovTUNydXoNCg0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxv
dCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJv
IGRlIDIwMTQgMTE6MjYNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0K
U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCkkgZG8gbm90IGFncmVlIHJlZ2FyZGluZyB0aGUgY29tcGxleGl0eSBzaW5jZSBpdCBp
cyBoaWdobHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpMZXRzIG5vdCBtYWtlIGFueSBhc3N1
bXB0aW9uIGluIHRoZSBwcm90b2NvbCBkZXNpZ24uDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJv
bTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlh
IENydXogQmFydG9sb21lDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCAzOjU0IFBN
DQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkhlbGxvLA0KDQpJIHRoaW5rIGl0IGlzIGltcG9y
dGFudCB0byBoaWdobGlnaHQgY29tcGxleGl0eSBmb3IgdGhlIHNlcnZlciB0byDCoOKAnGd1YXJh
bnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVy
bG9hZCByZXBvcnQu4oCdIA0KSSB0aGluayB0aGlzIGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBzZW50
ZW5jZSBhZGRlZCBieSBTdGV2ZS4NCg0KQ2hlZXJzDQovTUNydXoNCg0KRnJvbTogRGlNRSBbbWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5pcmF2IFNhbG90IChuc2Fs
b3QpDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyMA0KVG86IGxpb25l
bC5tb3JhbmRAb3JhbmdlLmNvbTsgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVj
dDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN
CkkgYW0gYWxzbyBmaW5lIHdpdGggU3RldmUncyBwcm9wb3NlZCB3b3JkaW5nIHRvIHJlY29tbWVu
ZCB0aGUgaW5jbHVzaW9uIG9mIE9MUiBidXQgdG8gbm90IG1hbmRhdGUgaXQuDQoNCkkgYW0gbm90
IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0LCBpZiBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vz
c2FyeSB0byBhZGQgaXQuDQpOb3RlIC0gdGhlIG9ubHkgc3VyZSB3YXksIHdpdGhvdXQgcHJvcHJp
ZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2
ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJlYWN0aW5nIG5vZGUgaXMgYSBjbGll
bnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlcG9y
dGluZyBub2RlLg0KDQpJIHByZWZlciB0byByZW1vdmUgaXQgc2luY2UgSSBkbyBub3Qgc2VlIGFz
IHZhbHVlIGFkZGl0aW9uLiANCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFu
Z2UuY29tDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEwOjEzIFBNDQpUbzogU3Rl
dmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkknbSBmaW5lIHdpdGggYSByZWNvbW1l
bmRhdGlvbi4NCg0KQnV0IEkgaGF2ZSBhIGdlbmVyYWwgY29tbWVudDogd2hlbiBhIE1BWSBvciBl
dmVuIGEgU0hPVUxEIGFwcGx5LCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgTk9UIHVwIHRv
IHRoZSBub2RlIHRvIGRvIG9yIG5vdCB0byBkbyBzb21ldGhpbmcuIEl0IGRvZXMgbm90IG1lYW4g
dGhhdCBpdCBpcyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIG9wdGlvbi4NCkZvciBpbnN0YW5jZSwg
b3ZlciBhIGdpdmVuIGludGVyZmFjZSwgdGhlIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbiBjYW4gc2F5
IHRoYXQgc29tZSBzdGF0ZXMgYXJlIG1haW50YWluZWQgYnkgdGhlIHNlcnZlci4gQW5kIGl0IGNv
dWxkIGJlIGRlY2lkZWQgdG8gYWRkIHNvbWUgb3ZlcmxvYWQgcmVsYXRlZCBpbmZvIGluIHN1Y2gg
c3RhdGVzLiBGb3IgaW5zdGFuY2UgYWdhaW4sIHRoZSBub2RlIGNhbiB1c2UgdGhpcyBzdGF0ZSB0
byBrbm93IGlmIGEgcmVtb3RlIG5vZGUgaGF2ZSBiZWVuIG5vdGlmaWVkIG9yIG5vdCBmb3IgaW5z
dGFuY2UuIEFuZCBpbiBzdWNoIGEgY2FzZSwgdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGlu
Y2x1ZGUgYW4gT0xSIGluIGVhY2ggbWVzc2FnZS4gSXQgaXMganVzdCBmb3IgaWxsdXN0cmF0aW9u
LiBUaGUgcG9pbnQgaXMgdGhhdCB5b3UgbWF5IGhhdmUgc29tZSBjYXNlcyBmb3Igd2hpY2ggdGhl
IE9MUiBpbiBldmVyeSBhbnN3ZXIgbWlnaHQgbm90IGJlIHJlcXVpcmVkLg0KDQpJIGFncmVlIHRo
YXQgaGF2aW5nIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2VyIGlzIGZpbmXigKYgYnV0IGl0IHNob3Vs
ZCBiZSBub3QgbWFuZGF0b3J5IGluIGFsbCBjYXNlcyBJIHRoaW5rLiBTbyBPSyBmb3IgYSAiU0hP
VUxEIiBvciAiUkVDT01NRU5ERUQiLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwgDQoNCkRlwqA6IERp
TUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgU3RldmUgRG9u
b3ZhbiBFbnZvecOpwqA6IGx1bmRpIDEwIGbDqXZyaWVyIDIwMTQgMTc6MjEgw4DCoDogZGltZUBp
ZXRmLm9yZyBPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KSSBhZ3JlZSB3aXRoIGJvdGggTWFyaWEgQ3J1eiBhbmQgTmlyYXYuIDot
KQ0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBoYXZlIHdvcmRpbmcgc2F5aW5nIHRoZSByZWNvbW1lbmRl
ZCBhcHByb2FjaCBpcyB0byBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYWxsIHJlc3Bv
bnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQgYnkgTWFyaWEgQ3J1ei7CoCANCg0K
SSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBpbmNsdWRlIE5pcmF2J3MgcHJvcG9zYWwgdGhhdCBpZiBh
IHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJl
Y2VpdmVkIGFuIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGl0IG1heSBjaG9vc2UgdG8gbm90IHNlbmQg
aXQgYWdhaW4uwqAgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGluZyBhbnl0aGluZyBh
Ym91dCBob3cgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIGJ1dCB3ZSBzaG91bGQgaW5jbHVkZSB3
b3JkaW5nIGFib3V0IG5ldHdvcmtzIGFyY2hpdGVjdHVyZXMgdGhhdCBtYWtlIGl0IGRpZmZpY3Vs
dCB0byBrbm93LsKgIFRoZSBjYXNlIG9mIGFnZW50cyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZXMg
Zm9yIG5vbiBzdXBwb3J0aW5nIGNsaWVudHMgYmVpbmcgb25lIGV4YW1wbGUuDQoNCldlIGFsc28g
bmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggaXMgbm90IHBy
ZWNsdWRlZCBieSBOaXJhdidzIHByb3Bvc2FsLg0KDQpJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBu
b3JtYXRpdmUgd29yZGluZywgd2hpY2ggY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBNYXJpYSBDcnV6
J3MgcmVhc29ucyBmb3IgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBh
bHdheXMgaW5jbHVkZWQuDQoNCi0tLS0tDQoNCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUg
dGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy4NCg0K
SXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQg
cmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuwqAg
DQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3Zlcmxv
YWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBp
ZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LsKgIFRoZSBvdmVybG9hZCByZXBvcnQgd2lsbCBqdXN0
IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBET0lD
Lg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQg
cmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJl
YWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0K
Tm90ZSAtIHRoZSBvbmx5IHN1cmUgd2F5LCB3aXRob3V0IHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMs
IHRvIGtub3cgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIGFuIG92ZXJsb2FkIHJl
cG9ydCBpcyB3aGVuIHRoZSByZWFjdGluZyBub2RlIGlzIGEgY2xpZW50IGFuZCB0aGVyZSBpcyBu
byBhZ2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXBvcnRpbmcgbm9kZS4NCk9uIDIv
MTAvMTQgMzo1MiBBTSwgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgd3JvdGU6DQpIZWxsbyBOaXJhdiwN
Cg0KQW55IHNvbHV0aW9uIHNob3VsZCBiYWxhbmNlIGRpZmZlcmVudCBmYWN0b3JzLCBlZmZpY2ll
bmN5IGNvdWxkIGJlIGRpc2N1c3NlZCBmcm9tIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMsIGJ1dCBm
aXJzdCB3ZSBuZWVkIHRvIGFzc3VyZSB0aGUgbWVjaGFuaXNtIHdlIGFyZSBkZWZpbmluZyBpcyBw
cm92aWRpbmcgdmFsaWQgT0xSIHRvIHJlYWN0aW5nIG5vZGVzLg0KDQpZb3VyIHByb3Bvc2VkIHRl
eHQNCiIgQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRp
bmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHBy
b3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1
ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0Mt
U3VwcG9ydGVkLUZlYXR1cmUgQVZQLiINCg0KSWYgdGhlIHJlcG9ydGluZyBpcyBub3QgYXdhcmUg
YWJvdXQgd2hldGhlciBvciBub3Qgb3ZlcmxvYWQgcmVwb3J0IGlzIHByb3ZpZGVkIHRvIHRoZSBy
ZWFjdGluZyBub2RlLCBhbmQgaXQgZGVjaWRlcyAoc2luY2UgaXQgaXMgYSAibWF5IikgdG8gZG8g
bm90IHNlbmQgdGhlIE9MUiBhZ2FpbiwgdGhlbiBvdmVybG9hZCBtaXRpZ2F0aW9uIG1lY2hhbmlz
bSB3aWxsIG5vdCB3b3JrIGluIGNhc2UgT0xSIHdhcyBub3QgcHJvcGVybHkgcmVjZWl2ZWQgYnkg
Y29ycmVzcG9uZGluZyBwb3RlbnRpYWwgcmVhY3Rpbmcgbm9kZXMuIEFuZCB3ZSBuZWVkIHRvIG5v
dGUgdGhhdCAicmVhY3Rpbmcgbm9kZXMiIGNvdWxkIGJlIG5vdCBvbmx5IHRoZSBjbGllbnQsIGJ1
dCBBTlkgYWdlbnQgdXNlZCBmb3Igcm91dGluZyAobm90IG9ubHkgd2hlbiB0aGUgYWdlbnQgaXMg
cHJvdmlkaW5nIHNlcnZpY2UgdG8gYSBSZWFsbSwgYnV0IHdoZW4gaXQgaXMgcmVhY3Rpbmcgb24g
YmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KS4gDQpUaGVuLCBvbiBvbmUgaGFuZCBp
dCBpcyBub3Qgc2ltcGxlIHRvIGtub3cgd2hlbiByZWFjdGluZyBub2RlcyBoYXZlIHZhbGlkIE9M
UiBpbmZvIChhcyBleHBsYWluZWQgYmVsb3cpLCBidXQgaWYgT0xSIGlzIG5vdCBzZW50IGFnYWlu
IChhcyBwZXIgeW91ciBwcm9wb3NlZCAibWF5IikgdGhlbiBvbmUgb3IgbXVsdGlwbGUgcmVhY3Rp
bmcgbm9kZXMgZG8gbm90IGhhdmUgdGhlIHJlcXVpcmVkIE9MUiwgdGhlbiBvdmVybG9hZCBtaXRp
Z2F0aW9uIHdpbGwgbm90IHdvcmsuDQoNClRoZXJlZm9yZSwgaW4gbXkgb3BpbmlvbiwgdGhlIHNp
bXBsZXN0IHdheSB0byBwcm92aWRlIHJlcXVpcmVkIGluZm9ybWF0aW9uIGlzIHRvIHByb3ZpZGUg
T0xSIGluIEFMTCBhbnN3ZXJzLg0KDQpCZXN0IHJlZ2FyZHMNCi9NQ3J1eg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fs
b3RAY2lzY28uY29tXQ0KU2VudDogbHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo0Mg0K
VG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQnV0IE1hcmlh
LUNydXosDQoNCkhvdyBjYW4gd2Ugc2F5IHRoYXQgImluY2x1ZGluZyB0aGUgT0xSIGluIGFsbCB0
aGUgYW5zd2VyIG1lc3NhZ2VzIGlzIHNpbXBsZSBhbmQgZWZmaWNpZW50PyINCkl0IGlzIHNpbXBs
ZSBmb3Igc3VyZSBidXQgbm90IGVmZmljaWVudC4gDQoNCkEgc2xpZ2h0bHkgZGlmZmVyZW50IHdv
cmRpbmcgZnJvbSB3aGF0IEkgcHJvcG9zZWQgZWFybGllciBpcywgV2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgaGFzIGEgbmV3IG92ZXJsb2FkIHJlcG9ydCB0aGF0IG5lZWRzIHRvIGJlIHByb3ZpZGVk
IHRvIGEgcmVhY3Rpbmcgbm9kZSAoYnkgdXBkYXRpbmcgdGhlIGVhcmxpZXIgcHJvdmlkZWQgb3Zl
cmxvYWQgcmVwb3J0IG9yIGJ5IHByb3ZpZGluZyB0aGUgb3ZlcmxvYWQgcmVwb3J0IGZvciB0aGUg
Zmlyc3QgdGltZSksIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhl
IHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAsIHRvd2FyZHMgdGhl
IGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25hbGx5LCBpbiBvdGhlciBjYXNl
cywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgYXdhcmUgaWYgdGhlIG92ZXJs
b2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSByZWFjdGluZyBub2RlLCB0aGUg
cmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgcmVzcG9uc2UsIHRvIHRo
ZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQpSZWdhcmRz
LA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xv
bWUNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMzowMyBQTQ0KVG86IGRpbWVAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZw0KDQpOaXJhdiwgYWxsLA0KDQpJIHRoaW5rIHdlIHNob3VsZCBkZWZpbmUgYW4g
YWNjdXJhdGUgYW5kIHJvYnVzdCBzb2x1dGlvbiwgYXMgZWZmaWNpZW50IGFuZCBzaW1wbGUgYXMg
cG9zc2libGUuDQpJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBhcyBhIHB1cmUgIm1heSIsIGJ1
dCBsZWF2aW5nIGl0IHVwIHRvIGltcGxlbWVudGF0aW9uIGRvZXMgbm90IGFzc3VyZSByZWFjdGlu
ZyBub2RlIGhhcyB2YWxpZCBPTFIgaW5mb3JtYXRpb24sIHdoYXQgaXMgYmFzaWMgZm9yIHRoaXMg
bWVjaGFuaXNtIHRvIHdvcmsuIA0KDQpCZXN0IHJlZ2FyZHMNCi9NQ3J1eg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fs
b3RAY2lzY28uY29tXQ0KU2VudDogbHVuZXMsIDEwIGRlIGZlYnJlcm8gZGUgMjAxNCAxMDoxMg0K
VG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1
eiwNCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSBvbiAic2VuZGluZyBPTFIgaW4gQUxMIGFuc3dl
cnMgaGFzIHNvbWUgaW1wb3J0YW50IGFkdmFudGFnZXMiLg0KQW5kIHdlIGFyZSBub3QgdHJ5aW5n
IHRvIHByZXZlbnQgaXQgLSBhdCBsZWFzdCB0aGF0IGlzIG15IGludGVudGlvbi4gDQpCdXQgdGhl
IG1haW4gcXVlc3Rpb24gaXMsIGFyZSB3ZSB0cnlpbmcgdG8gcHJldmVudCBhbnkgb3RoZXIgcG9z
c2libGUgaW1wbGVtZW50YXRpb24sIHdoaWNoIG1heSBiZSBzbWFydGVyIGFuZCBjYW4gYXZvaWQg
aW5jbHVkaW5nIHJlZHVuZGFudCBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZT8NCg0KTW9z
dCBwcm9iYWJseSwgdGhlIHZlcnkgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Ygb3ZlcmxvYWQgY29u
dHJvbCB3aWxsIGluY2x1ZGUgT0xSIGluIGFsbCB0aGUgYW5zd2VyIG1lc3NhZ2VzLg0KQnV0IGF0
IHRoZSBzYW1lIHRpbWUsIEkgZG8gbm90IHdhbnQgdG8gcmVzdHJpY3QgdGhlIGRldmVsb3BlcnMg
d2hpY2ggY2FuIGNvbWUgdXAgd2l0aCBzb21lIG5pY2UgdHdlYWtzIGFuZCB0cmlja3MgdG8gYXZv
aWQgc2VuZGluZyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBldmVyeSBtZXNzYWdlLiBBbmQgdGhp
cyBpcyB3aGVyZSB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYW5kIGF2b2lkIHB1dHRpbmcgc3VjaCBy
ZXN0cmljdGlvbnMgaW4gcHJvdG9jb2wgZGVmaW5pdGlvbi4gDQpXaGF0IGRvIHlvdSB0aGluaz8N
Cg0KVGhpcyBhbHNvIHRoZSByZWFzb24gSSB3YXMgc3VnZ2VzdGluZyBsb29zZSBkZXNjcmlwdGlv
biBvZiB3aGVuIHRvIGluY2x1ZGUgT0xSIChmcm9tIHRoZSByZXBvcnRpbmcgbm9kZSBwb2ludCBv
ZiB2aWV3KS4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IE1hcmlhIENydXogQmFydG9sb21lDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDg6
NTcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSGVsbG8gVWxyaWNoLCBOaXJhdiwNCg0K
SSBhZ3JlZSB3aXRoIFVscmljaCB0aGF0IHRoZSB0ZXh0IHByb3ZpZGVkIGJ5IE5pcmF2IGlzIGp1
c3QgYSBNQVksIGFuZCB3aGV0aGVyIG9yIG5vdCB0aGUgc2VydmVyIHNlbmRzIGFuIE9MUiBpbiBh
bGwgYW5zd2VycyBzaGFsbCBub3QgYmUganVzdCBhIE1BWS4NCg0KT24gdGhlIG90aGVyIGhhbmQs
IGNyaXRlcmlhIHByb3ZpZGVkIGJ5IFVscmljaCBvbiB3aGVuIE9MUiBoYXMgdG8gYmUgc2VudCBy
ZXF1aXJlcyB0aGUgc2VydmVyIGhhcyBzb21lIGtub3dsZWRnZToNCmEpIHRoZSByZXBvcnRpbmcg
bm9kZSBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IGdvdCB0aGUgbGF0
ZXN0IE9MUg0KYikgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkIChpLmQuIGRv
ZXMgbm90IHdhbnQgYSB0aHJvdHRsaW5nKSBhbmQga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9k
ZSBoYXMgZ290IGFuIE9MUiB0aGF0IHdpbGwgc29vbiBleHBpcmUNCmMpIG90aGVyd2lzZQ0KDQpS
ZXBvcnRpbmcgbm9kZSBtdXN0IGhhdmUgc29tZSBrbm93bGVkZ2UgYWJvdXQgT0xSIHJlY2VwdGlv
bi9zdGF0dXMgaW4gcmVhY3Rpbmcgbm9kZS4gSG93IGRvZXMgc2VydmVyIGFjcXVpcmUgdGhpcyBr
bm93bGVkZ2U/IA0KVGFrZSBpbnRvIGFjY291bnQgYXMgd2VsbCB0aGF0IGEgInJlYWN0aW5nIiBu
b2RlIG1heSBiZSBib3RoIGFuIEFnZW50IChpbiBjYXNlIGl0IHByb3ZpZGVzIHNlcnZpY2UgdG8g
YSByZWFsbSBvciBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgbm9uLXN1cHBvcnRpbmcgY2xpZW50KcKg
IGFuZCBhIENsaWVudC4gSW4gdGhlIGNhc2Ugb2YgQWdlbnRzLCBpbiBmYWN0IHRoZSBTZXJ2ZXIg
bWF5IG5vdCBldmVuIGtub3cgaWYgdGhpcyBpcyBnb2luZyB0byBhY3QgYXMgYSByZWFjdGluZyBu
b2RlIG9yIGp1c3QgdHJhbnNwYXJlbnRseSwgaW4gZmFjdCwgdGhlIHNlcnZlciBkb2VzIG5vdCBu
ZWVkIHRvIGhhdmUgYW55IGtub3dsZWRnZSBhYm91dCB3aGF0IGFnZW50cyBpbiB0aGUgY2hhaW4g
dG8gdGhlIGZpbmFsIENsaWVudC4NCg0KVGhlcmVmb3JlLCBJIGRlZmluaXRlbHkgdGhpbmsgdGhh
dCBzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRhbnQgYWR2YW50YWdl
czoNCi0gc3RhdGUtbGVzcyBpbXBsZW1lbnRhdGlvbiAodHJhbnNhY3Rpb24gb3Igc2Vzc2lvbikg
aXMgc2ltcGxlciwNCi0gdGhlIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGRldGVybWluZSB3aGV0
aGVyIG9yIG5vdCB0byBzZW5kIGFuIE9MIHRvIGEgcmVhY3Rpbmcgbm9kZQ0KLSB0aGUgc2VydmVy
IGRvZXMgbm90IG5lZWQgdG8gYm90aGVyIHdoZXRoZXIgYW4gcmVhY3Rpbmcgbm9kZSBoYXMgYWxy
ZWFkeSByZWNlaXZlZCBhbiBPTFIgb3Igd2hldGhlciB0aGlzIE9MUiBpcyBzdGlsbCB2YWxpZCAo
aGFzIG5vdCBleHBpcmVkKS4NCi0gc2VuZGluZyBhbiBhZGRpdGlvbmFsIEFWUCBpcyBub3QgcHJv
Y2Vzc2luZyBjb25zdW1pbmcsIGluIGNvbXBhcmlzb24gd2l0aCByZXF1aXJlZCBhYm92ZSBjaGVj
a3MgKGlmIHRoaXMgaXMgbm90IHNlbnQpLiANCsKgIEluIGZhY3QsIGluIGFuIG92ZXJsb2FkIHNp
dHVhdGlvbiwgdGhlIGVhc2llc3QgYW5kIGxlYXN0IGNvbXBsZXggaXMgdG8gc2VuZCBpbmZvcm1h
dGlvbiBvdXQgdG8gYWxsIGFmZmVjdGVkL2FwcGxpY2FibGUgbm9kZXMsDQrCoCBhbmQgdGhlIGxh
dHRlciBzaG91bGQgdGFrZSBjYXJlIHRvIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9ucw0KLSBtb3Jl
IHJvYnVzdCBzb2x1dGlvbiwgYXMgbm8gbmVlZCB0byBjYXRlciBmb3IgYWxsIHRoZSBjaGVja3Mg
b24gdGhlIG5lZWQgdG8gc2VuZCBpbmZvcm1hdGlvbizCoCBmb3Igc2l0dWF0aW9ucyB3aGVyZSBh
biBhbnN3ZXIgbWVzc2FnZSBpcyBsb3N0LMKgIOKApg0KDQoNCkJlc3QgcmVnYXJkcw0KL01DcnV6
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVu
aWNoKQ0KU2VudDogdmllcm5lcywgMDcgZGUgZmVicmVybyBkZSAyMDE0IDEwOjU5DQpUbzogZXh0
IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBleHQg
U3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LA0KDQpJJ20gYWZyYWlk
IHlvdXIgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoZSBpbnRlbnRpb24uDQoNCiJ3
aGVuIGl0IHdhbnRzIHRvIHByb3ZpZGUvdXBkYXRlLi4uLml0IHNoYWxsIGluY2x1ZGUuLi4iIHRy
YW5zbGF0ZXMgdG8gIi4uLml0IG1heSBpbmNsdWRlLi4uIi4NCg0KImluIG90aGVyIGNhc2VzIiBp
biB0aGUgZ2l2ZW4gY29udGV4dCB0cmFuc2xhdGVzIHRvICJ3aGVuIGl0IGRvZXMgbm90IHdhbnQg
dG8gcHJvdmlkZS91cGRhdGUuLi4iDQoNCg0KV2UgaGF2ZSB0aGUgZm9sbG93aW5nIGNhc2VzOg0K
YSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIGFs
cmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQpiKSB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IG92
ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90dGxpbmcpIGFuZCBrbm93cyB0aGF0
IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRoYXQgd2lsbCBzb29uIGV4cGlyZQ0K
Yykgb3RoZXJ3aXNlDQoNCmluIGNhc2UgYSkgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBtYXkg
bm90IHJlcGxheSB0aGUgT0xSIGluIGNhc2UgYikgdGhlIHJlcG9ydGluZyBub2RlIG1heSBvciBt
YXkgbm90IHVwZGRhdGUgdGhlIHJlYWN0aW5nIG5vZGUgd2l0aCB0aGUgbGF0ZXN0IE9MUiBpbiBj
YXNlIGMpIHRoZSByZXBvcnRpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5z
d2VyICh0aGUgcmVwb3J0aW5nIG5vZGUgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYSBy
ZXBsYXkgb3IgYW4gdXBkYXRlKQ0KDQpVbHJpY2gNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogZXh0IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2Nv
LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA0OjQ5IFBNDQpUbzogV2ll
aGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNv
bTsgZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpVbHJpY2gsDQoNCkl0
IHNlZW1zIHdlIGFsbCBhcmUgb24gc2FtZSBwYWdlIGJ1dCBwcm9iYWJseSB0aGUgcHJvcG9zZWQg
d29yZGluZyBiZWxvdyBpcyBub3QgdGhlIGJlc3QuDQpIb3cgYWJvdXQgdGhlIGZvbGxvd2luZy4N
Cg0KV2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgd2FudHMgdG8gcHJvdmlkZSBuZXcgb3ZlcmxvYWQg
cmVwb3J0IG9yIHdhbnRzIHRvIHVwZGF0ZSB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCBy
ZXBvcnQgdG93YXJkcyBhIHJlYWN0aW5nIG5vZGUsIGl0IHNoYWxsIGluY2x1ZGUgT0xSIGluIHRo
ZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZSBBVlAsIHRvd2FyZHMgdGhlIGNvcnJlc3BvbmRpbmcgcmVhY3Rpbmcgbm9kZS4gQWRkaXRpb25h
bGx5LCBpbiBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qg
YXdhcmUgaWYgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IHByb3ZpZGVkIHRvIHRoZSBy
ZWFjdGluZyBub2RlLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiB0
aGUgcmVzcG9uc2UsIHRvIHRoZSByZXF1ZXN0IGNvbnRhaW5pbmcgT0MtU3VwcG9ydGVkLUZlYXR1
cmUgQVZQLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86dWxyaWNoLndp
ZWhlQG5zbi5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMzo1NyBQTQ0K
VG86IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBl
eHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LCBMaW9uZWwsDQoN
CkkgY2FuIHVuZGVyc3RhbmQgTmlyYXYncyBjb25jZXJuIChhbHRob3VnaCB2aW9sYXRpbmcgUkVR
MTApIGFuZCBob3AgaXQgaXMgYWRkcmVzc2VkIGJ5IHRoZSBtb2RpZmllZCBwcmluY2lwbGUgMic6
DQoNCjInLiB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQg
b3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRvIHJl
cXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQg
aXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgcmVhc29uYWJs
ZSBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0aW9uIChlLmcuIHRoZSBsYXRlc3QgT0xSLCB3aGlj
aCBtYXkgYmUgYW4gT0xSIHJlcXVlc3RpbmcgdHJhZmZpYyByZWR1Y3Rpb24gb3IgYW4gT0xSIGlu
ZGljYXRpbmcgIm5vIG92ZXJsb2FkIiwgb3IgYW4gb2xkwqAgYnV0IHNvb24gZXhwaXJpbmcgT0xS
IHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBvdmVybG9hZGVkKTsgb3RoZXJ3aXNlIChp
LmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGluZyBub2RlIChubyBtYXR0ZXIg
d2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNl
cyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQ
Lg0KDQpJIGRvbid0IGFncmVlIHdpdGggTGlvbmVscyBkby13aGF0LXlvdS13YW50IGFwcHJvYWNo
LiBPdmVybG9hZCBjb250cm9sIHdpbGwgbm90IHdvcmsgd2hlbiB3ZSBhbGxvdyB0aGUgcmVwb3J0
aW5nIG5vZGUgbm90IHRvIHVwZGF0ZSByZWFjdGluZyBub2Rlcywgd2hpY2ggYXJlIG5vdCAoc3Vm
ZmljaWFudGx5KSBhd2FyZSBvZiB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0dXMsIHdpdGggdXAg
dG8gZGF0ZSBPTFJzLg0KDQpVbHJpY2jCoCANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFttYWlsdG86bGlvbmVsLm1v
cmFuZEBvcmFuZ2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDEwOjIw
IEFNDQpUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011
bmljaCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KDQoNCi0tLS0t
TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0Bp
ZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBOaXJhdiBTYWxvdCAobnNhbG90KSBFbnZvecOpwqA6IGpl
dWRpIDYgZsOpdnJpZXIgMjAxNCAxMDowOCDDgMKgOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N
dW5pY2gpOyBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZyBPYmpldMKgOiBSZTogW0Rp
bWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGlu
IHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KVWxyaWNoLA0K
DQpJIGFtIG5vdCBzdXJlIGFib3V0IGZvcmNpbmcgdGhpcyBiZWhhdmlvciBvbiByZXBvcnRpbmcg
bm9kZSAib3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJlcG9ydGlu
ZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCByZXR1cm4g
YW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4gT0MtU3Vw
cG9ydGVkLUZlYXR1cmUgQVZQLiINClRoZSByZXBvcnRpbmcgbm9kZSBtYXkgc2ltcGx5IG5vdCBp
bmNsdWRlIE9MUiBhc3N1bWluZyB0aGF0IHRoZSBlYXJsaWVyIHByb3ZpZGVkIE9MUiB3aWxsIGV4
cGlyZSBhbmQgdGhlIHJlYWN0aW5nIG5vZGUgd2lsbCBzdG9wIHRocm90dGxpbmcgdGhlIHRyYWZm
aWMuDQoNCltMTV0gQWdyZWUuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBub3QgZGVlbWVkIHJlcXVp
cmVkIGZvciB0aGUgZGVmYXVsdCBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQuIEhv
dyBhbmQgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgZGVjaWRlcyB0byBpbmNsdWRlIHRoZSBPTFIg
aW4gdGhlIGFuc3dlciBtYXkgZGVwZW5kIG9uIHRoZSBhcHBsaWNhdGlvbiBvciBvbiB0aGUgaW1w
bGVtZW50YXRpb24uIEF0IGxlYXN0LCBpdCBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuDQoN
CkFzIHdlIGhhZCBkaXNjdXNzZWQgZWFybGllciwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIHJl
cG9ydGluZyBub2RlIHRvIGV4cGxpY2l0bHkgc3RvcCB0aHJvdHRsaW5nIGF0IGVhY2ggcmVhY3Rp
bmcgbm9kZSBhdCB0aGUgc2FtZSB0aW1lLiBJbiBvdGhlciB3b3JkcywgdGhlIHJlcG9ydGluZyBu
b2RlIGNhbiBhbGxvdyB0aGUgbmF0dXJhbCBleHBpcnkgb2YgdGhlIE9MUiB0byBmYWNpbGl0YXRl
IHNsb3cgcmFtcCBvZiB0aGUgc2lnbmFsaW5nIHRyYWZmaWMgdG93YXJkcyBpdC4NCg0KW0xNXSBB
Z3JlZQ0KDQpUaGVyZSBtYXkgYmUgb3RoZXIgY2FzZXMsIGUuZy4gd2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUga25vd3MgdGhhdCB0aGUgbGFzdCBvdmVybG9hZCBzaXR1YXRpb24gZW5kZWQgbG9uZyB0
aW1lIGJhY2sgaW4gdGhlIHBhc3QsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGl0IHRvIGluY2x1ZGUg
T0xSIGlmIGN1cnJlbnRseSB0aGVyZSBpcyBubyBvdmVybG9hZCBjb25kaXRpb24uDQoNCltMTV0g
QWdyZWUNCg0KUmVzdCBvZiB0aGUgcHJpbmNpcGxlcyBiZWxvdyBhcmUgZmluZSB3aXRoIG1lLg0K
DQpbTE1dIEFncmVlDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgW21haWx0bzp1bHJp
Y2gud2llaGVAbnNuLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAyOjIz
IFBNDQpUbzogZXh0IFN0ZXZlIERvbm92YW47IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGll
dGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KQWN0dWFsbHkgd2Ugc2VlbSB0byBhZ3JlZSBvbiB0d28gcHJpbmNpcGxl
czoNCjEuIExhY2sgb2YgT0xSIG1lYW5zICJubyBjaGFuZ2UiDQoyLiB0aGUgcmVwb3J0aW5nIG5v
ZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNQVkgZGVjaWRlIG5vdCB0
byByZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBh
biBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAgaWYgaXQgaXMgYXdhcmUgdGhhdCB0aGUgcmVhY3Rp
bmcgbm9kZSBhbHJlYWR5IGhhcyBnb3QgdGhlIGxhdGVzdCBPTFIgKHdoaWNoIG1heSBiZSBhbiBP
TFIgcmVxdWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8g
b3ZlcmxvYWQiKTsgb3RoZXJ3aXNlIChpLmUuIGlmIGl0IGlzIG5vdCBhd2FyZS4uLikgdGhlIHJl
cG9ydGluZyBub2RlIChubyBtYXR0ZXIgd2hldGhlciBvdmVybG9hZGVkIG9yIG5vdCkgTVVTVCBy
ZXR1cm4gYW4gT0xSIGluIHJlc3BvbnNlcyB0byByZXF1ZXN0cyB3aGljaCBjb250YWluZWQgYW4g
T0MtU3VwcG9ydGVkLUZlYXR1cmUgQVZQLg0KDQpDYW4gcGVvcGxlIHBsZWFzZSBjb25maXJtLg0K
DQpVbHJpY2gNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1
LCAyMDE0IDQ6MzUgUE0NClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZw0K
U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCkFncmVlZC7CoCBUbyByZXN0YXRlIC0tIGxhY2sgb2YgYW4gb3ZlcmxvYWQgcmVwb3J0
IGRvZXMgbm90IGNoYW5nZSB0aGUgY3VycmVudCBvdmVybG9hZCBzdGF0ZSBmb3IgdGhlIGhvc3Qg
b3IgcmVhbG0uwqAgSWYgdGhlcmUgaXMgYSBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9y
dCB0aGVuIGl0IGNvbnRpbnVlcyB0byBhcHBseSB1bnRpbCBpdCBlaXRoZXIgdGltZXMgb3V0IG9y
IGlzIGV4cGxpY2l0bHkgY2hhbmdlZCB3aXRoIGEgbmV3IG92ZXJsb2FkIHJlcG9ydC7CoCBJZiB0
aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCB0aGVuIGxhY2sgb2Yg
YW4gb3ZlcmxvYWQgcmVwb3J0IGltcGxpZXMgdGhlcmUgaXMgbm8gb3ZlcmxvYWQgZm9yIHRoZSBo
b3N0IGFuZCByZWFsbS4NCg0KU3RldmUNCk9uIDIvNS8xNCA5OjE5IEFNLCBOaXJhdiBTYWxvdCAo
bnNhbG90KSB3cm90ZToNCkkgYWdyZWUgd2l0aCBTdGV2ZSBleGNlcHQgdGhlIHBhcnQgInNob3Vs
ZG7igJl0IGxhY2sgb2YgT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPyINCsKg
DQpXZSBoYWQgc29tZSBkaXNjdXNzaW9uIHNvbWV0aW1lIGJhY2sgYW5kIHRob3VnaHQgdGhhdCBp
dCBpcyByZWFzb25hYmxlIHRvIG5vdCBtYW5kYXRlIHRoZSBzZXJ2ZXIgdG8gaW5jbHVkZSB0aGUg
T0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlLiBFLmcuIHdoZW4gdGhlIHNlcnZlciBpcyBjYXBh
YmxlIG9mIHRyYWNraW5nIHdoYXQgaXMgc2VudCB0byB3aGljaCBjbGllbnQgYW5kIGhlbmNlIHdh
bnRzIHRvIGF2b2lkIHNlbmRpbmcgaW5mb3JtYXRpb24gd2hpY2ggaXMgcmVkdW5kYW50LiBCdXQg
dGhpcyBpcyBvcHRpb25hbCBpbXBsZW1lbnRhdGlvbiBhbmQgYXQgdGhlIHNhbWUgdGltZSBuZWVk
IG5vdCBiZSBwcm9oaWJpdGVkIGZyb20gcHJvdG9jb2wgcG9pbnQgb2Ygdmlldy4NCsKgDQpTbyBi
YXNpY2FsbHksIHRoZSBsYWNrIG9mIE9MUiBzaG91bGQgbm90IGFmZmVjdCB0aGUgcHJldmlvdXNs
eSByZWNlaXZlZCBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuIFRoZSByZWFjdGluZyBub2RlIGNh
biBjb250aW51ZSB0byByZWFjdCBiYXNlZCBvbiBvbGRlciBPTFIgdW50aWwgdGhlIGV4cGlyeSBv
ZiB0aGUgdmFsaWRpdHktcGVyaW9kIG9yIHdoZW4gdGhlIGV4cGxpY2l0IE9MUiB3aXRoICIwIiBv
dmVybG9hZC1tZXRyaWMgaXMgcmVjZWl2ZWQuDQpJbiBteSB2aWV3LCB0aGlzIGFsbG93cyBmb3Ig
ZmxleGlibGUgaW1wbGVtZW50YXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlIGFuZCBzb3VuZCBo
YW5kbGluZyBvZiBPTFIgYXQgdGhlIHJlYWN0aW5nIG5vZGUuDQrCoA0KUmVnYXJkcywNCk5pcmF2
Lg0KwqANCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDg6
MDAgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6
IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2Fn
ZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCsKgDQppbmxpbmUNCk9uIDIvNS8xNCA3OjU3
IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOg0KT2sgdGhlbiBsZXQn
cyBzdGF0ZSB0aGF0IHJlcG9ydGluZyBub2RlcyBNVVNUIGluc2VydCBhbiBPQy1PTFIgQVZQIGlu
IGFsbCBhbnN3ZXIgbWVzc2FnZXMgdGhhdCBjb3JyZXNwb25kIHRvIHJlcXVlc3QgbWVzc2FnZXMg
d2hpY2ggY29udGFpbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIChldmVuIHdoZW4gbm8g
bG9hZCByZWR1Y3Rpb24gaXMgcmVxdWVzdGVkKS4NClNSRD4gV2h5IGluIGV2ZXJ5IGFuc3dlciBt
ZXNzYWdlP8KgIFNob3VsZG4ndCBsYWNrIG9mIGFuIE9MUiBiZSBpbnRlcnByZXRlZCBhcyBub3Qg
b3ZlcmxvYWRlZD8NCg0KDQrCoA0KwqANCk90aGVyIGNyaXRlcmlhIGxpa2UgUkVRMTggb3IgUkVR
MTMgZG8gbm90IHNlZW0gdG8gbWF0dGVyLg0KU1JEPiBSZXF1aXJpbmcgYW4gb3ZlcmxvYWQgcmVw
b3J0IGluIGV2ZXJ5IGFuc3dlciBkb2VzIGRpcmVjdGx5IGJyZWFrIFJFUTEzLCBidXQgcmVxdWly
aW5nIGFuIG92ZXJsb2FkZWQgbm9kZSB0byBsb29rIGZvciBhbiBPQy1PbmdvaW5nLVRocm90dGxp
bmctSW5mbyBBVlAgaW4gZXZlcnkgbWVzc2FnZSBpcyBhbHNvIHN1YnN0YW50aWFsIGFkZGl0aW9u
YWwgd29yaywgcG90ZW50aWFsbHkgbW9yZSBleHBlbnNpdmUgdGhhbiBpbnNlcnRpbmcgT0xScy4N
Cg0KDQrCoA0KwqANCkZvciBteSBjbGFyaWZpY2F0aW9uOiBJIGd1ZXNzIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUgaXMgbm90IHJlcXVpcmVkIHRvIHByb2Nlc3MgZXZlcnkgc2luZ2xlIE9MUiByZWNl
aXZlZCAobW9zdCB3aWxsIGJlIHJlcGxheXMgYW55d2F5KS4gV2hhdCB3b3VsZCBiZSB0aGUgcHJv
Y2VkdXJlIGluIHRoZSByZWFjdGluZyBub2RlIGluIG9yZGVyIHRvIG1pbmltaXplIHByb2Nlc3Np
bmcgb2YgcmVwbGF5ZWQgT0xScyBhbmQgYXQgdGhlIHNhbWUgdGltZSBtaW5pbWl6ZSB0aGUgcmlz
ayB0b28gbWlzcyBhIG5ldyBPTFI/DQpTUkQ+IFRoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNl
cXVlbmNlIG51bWJlci4NCg0KDQrCoA0KwqANCsKgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IGV4dCBOaXJhdiBTYWxvdCAobnNhbG90KQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwg
MjAxNCA1OjI3IEFNDQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBkaW1lQGlldGYub3Jn
DQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcNCsKgDQpJIHNoYXJlIHRoZSBzYW1lIG9waW5pb24gYXMgTGlvbmVsLg0KwqANClJlZ2Fy
ZHMsDQpOaXJhdi4NCsKgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBb
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpb25lbC5tb3JhbmRA
b3JhbmdlLmNvbQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMTQgOTowNyBQTQ0KVG86
IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZWFsIGNvbmNl
cm4gaXMgd2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgRE9FUyBOT1QgaW5zZXJ0IHRoZSBPTFIgaW4g
ZXZlcnkgYW5zd2VyLiANClNvIHRoZSBvcHRpb25zIHdvdWxkIGJlOg0KMS0gT0MtT0xSIEFWUCBp
biBldmVyeSBhbnN3ZXINCjItIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVy
eSByZXF1ZXN0ICsgT0MtT0xSIEFWUCBpbiBzb21lIGFuc3dlciB3aGVuIHRoZSBjdXJyZW50IHRo
cm90dGxpbmcgcGVyZm9ybWVkIGJ5IHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4NCsKg
DQpJZiB0aGVyZSBpcyBubyBvdGhlciBjcml0ZXJpb24sIHRoZSBvcHRpb24gMSBzZWVtcyB0aGUg
YmVzdCBhcHByb2FjaC4NCsKgDQpMaW9uZWwNCsKgDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t
LS0NCkRlwqA6IGRpbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrZGltZUB0cmFjLnRvb2xz
LmlldGYub3JnXQ0KRW52b3nDqcKgOiBtYXJkaSA0IGbDqXZyaWVyIDIwMTQgMDk6NDkNCsOAwqA6
IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PCoDogZGltZUBpZXRmLm9yZw0KT2JqZXTCoDogW2Rp
bWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVz
dCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCiMzMTogU2VuZGluZyBP
Qy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1
cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCiBJdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBkZWZpbmUg
YW4gT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIHRoYXQgaXPCoCB0byBiZSBpbmNsdWRl
ZCBieSB0aGUgcmVhY3RpbmcgRE9JQyBlbmRwb2ludCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXTC
oCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuIFRoaXMgQVZQIHdvdWxkIGluZGljYXRlIHRoZSBTZXF1
ZW5jZS1OdW1iZXINCiAoVGltZVN0YW1wKSBvZiB0aGUgT0xSIGFjY29yZGluZyB0byB3aGljaCB0
aGUgdGhyb3R0bGluZyAod2hpY2ggd2FzDQogc3Vydml2ZWQpIGlzIHBlcmZvcm1lZC4gQWJzZW5j
ZSBvZiB0aGlzIEFWUCBpbmRpY2F0ZXMgdGhhdCBjdXJyZW50bHkgbm/CoCB0aHJvdHRsaW5nIGlz
IHBlcmZvcm1lZC7CoCBSZXBvcnRpbmcgRE9JQyBlbmRwb2ludHMgbWF5IHVzZSB0aGlzwqAgaW5m
b3JtYXRpb24gaW4gb3JkZXIgdG8gZGV0ZWN0IHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHVw
ZGF0ZSB0aGXCoCByZWFjdGluZyBET0lDIGVuZHBvaW50IHdpdGggdGhlIGxhdGVzdCBPTFIuDQog
QWJzZW5jZSBvZiB0aGlzIGZlZWRiYWNrIG1lY2hhbmlzbSB3b3VsZCByZXN1bHQgaW4gdGhlIG5l
ZWQgZm9yIHRoZcKgIHJlcG9ydGluZyBub2RlIHRvIHNlbmQgT0MtT0xSIEFWUHMgaW4gZXZlcnkg
YW5zd2VyIGFzIHRoZSByZXBvcnRpbmcgRE9JQ8KgIGVuZHBvaW50IGNhbm5vdCBrbm93IHdoZXRo
ZXIgdGhlIHJlYWN0aW5nIERPSUMgZW5kcG9pbnQgaXMgYWN0dWFsbHkgZG9pbmfCoCB0aGUgcmln
aHQgdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhyb3R0bGluZy9ub3QgdGhyb3R0bGluZy4NCiBUaGUg
ZmVlZGJhY2sgbWVjaGFuaXNtIGltcHJvdmVzIHJvYnVzdG5lc3MgYXMgaXQgYWxsb3dzIHRoZSBy
ZXBvcnRpbmcgRE9JQ8KgIGVuZHBvaW50IHRvIGRldGVjdCBhbmQgY29ycmVjdCBpbmFwcHJvcHJp
YXRlIHRocm90dGxpbmcgYnkgdGhlIHJlYWN0aW5nwqAgRE9JQyBlbmRwb2ludCAoY2F1c2VkIGJ5
IHdoYXRldmVyIHJlYXNvbikuDQogVGhlIGZlZWRiYWNrIG1lY2hhbmlzbSBhbHNvIGFsbG93cyB0
byBhZGRyZXNzIFJFUSAxOCBmcm9tIFJGQyA3MDY4Lg0KIEluIHN1bW1hcnkgaXQgaXMgcHJvcG9z
ZWQgdG8gZGVmaW5lIHRoZSBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgdG/CoCBiZSB1
c2VkIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcuDQrCoA0K
wqANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRp
TUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg
am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz
IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4
cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl
IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIg
ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz
IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRl
Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl
Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht
ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0
aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0
ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJl
Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg
ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBi
ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl
ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxp
c3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZGltZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRp
TUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RpbWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN
CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu
Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg
ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh
dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs
ZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp
ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs
ZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj
ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv
ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRo
ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo
b3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl
IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp
ZWQuDQpUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu
dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug
cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p
dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz
c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBs
ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl
Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGlu
ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt
ZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz
IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg
bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg
dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2
ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl
dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFs
dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt
b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNl
IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y
bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u
YyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv
bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz
aWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl
cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg
ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt
ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMg
bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkg
c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp
c2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl
IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo
bWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv
ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu
DQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50
ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw
cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0
ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz
YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxl
IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj
dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5l
IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l
IG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg
bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt
YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZl
ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0
ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0
ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v
ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0K


From lionel.morand@orange.com  Thu Feb 13 08:13:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144F61A0341 for ; Thu, 13 Feb 2014 08:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcPQ1SjohyGV for ; Thu, 13 Feb 2014 08:13:48 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B386B1A0344 for ; Thu, 13 Feb 2014 08:13:44 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4C78E22C206; Thu, 13 Feb 2014 17:13:43 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 399B935C078; Thu, 13 Feb 2014 17:13:43 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 17:13:42 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb768GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3wFAgP++EOiA/3wQ10A=
Date: Thu, 13 Feb 2014 16:13:42 +0000
Message-ID: <10976_1392308023_52FCEF37_10976_8076_1_6B7134B31289DC4FAF731D844122B36E4A14BA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <16264_1392307475_52FCED13_16264_6720_1_6B7134B31289DC4FAF731D844122B36E4A147C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209774F1F@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774F1F@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.13.101215
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 16:13:59 -0000

QmVjYXVzZSB5b3VyIGVtYWlscyBhcmUgdG9vIGhlYXZ5Li4uIGFuZCBibG9ja2VkIDopDQpQbGVh
c2UgdXNlIHRleHQgZm9ybWF0Lg0KDQpMaW9uZWwNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t
LS0tDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0
IGRlIE1hcmlhIENydXogQmFydG9sb21lDQpFbnZvecOpwqA6IGpldWRpIDEzIGbDqXZyaWVyIDIw
MTQgMTc6MTINCsOAwqA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt
ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJIGhhdmUgcmVjZWl2ZWQgbWFp
bHMgb3V0IG9mIG9yZGVyLi4uIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
XSANClNlbnQ6IGp1ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDE3OjA1DQpUbzogTWFyaWEg
Q3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt
ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpUbyBjaGFuZ2UgdGhlIGZvcm1h
dCA6KQ0KDQoNCkRlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh
IHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgRW52b3nDqcKgOiBqZXVkaSAxMyBmw6l2cmll
ciAyMDE0IDE0OjE4IMOAwqA6IGRpbWVAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtEaW1lXSBbZGlt
ZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0
IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LA0KDQpEbyB5b3Ug
Y29uc2lkZXIgdGhhdCBvdmVybG9hZCByZXBvcnRzIGNhbiBvbmx5IGJlIGRpc2NhcmRlZCBieSBy
ZWFjdGluZyBub2RlcyB3aGVuIHRoZXJlIGFyZSBhZ2VudHMgaW4gdGhlIHBhdGg/DQoNCg0KRnJv
bTogTmlyYXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KU2VudDog
anVldmVzLCAxMyBkZSBmZWJyZXJvIGRlIDIwMTQgMTM6NTgNClRvOiBNYXJpYSBDcnV6IEJhcnRv
bG9tZTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5k
aW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRo
YXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk1hcmlhLUNydXosDQoNClJlcG9ydGluZyBub3Rl
IG1heSB1c2UgdmVyeSBzaW1wbGUgbWVjaGFuaXNtIOKAkyBhcyBwb2ludGVkIG91dCBieSBMaW9u
ZWwg4oCTIHRvIGNvbmNsdWRlIHRoYXQgcmVwb3J0IGhhcyByZWFjaGVkIHRoZSByZWFjdGluZyBu
b2RlLCBpLmUuIGFsbCB0aGUgaW50cmEtc2Vzc2lvbiBtZXNzYWdlcyBuZWVkIG5vdCBjb250YWlu
IHRoZSBzYW1lIG92ZXJsb2FkIHJlcG9ydCwgaWYgdGhlIHNlc3Npb24gZXN0YWJsaXNobWVudCBt
ZXNzYWdlIGNvbnRhaW5zIHRoZSBvdmVybG9hZCByZXBvcnQuDQoNClNvIHlvdXIgbm90ZSByZWdh
cmRpbmcgdGhlIHJlcG9ydGluZyBub2RlIHRvIHRha2UgaW50byBhY2NvdW50IHRoZSBuZXR3b3Jr
IGRlcGxveW1lbnQgZXRjLiBpcyBub3QgMTAwJSBjb3JyZWN0Lg0KTGV0IG1lIHNpbXBsaWZ5LCBo
b3BpbmcgaXQgd2lsbCBzYXRpc2Z5IHlvdXIgY29uY2Vybi4NCg0KQSByZXBvcnRpbmcgbm9kZSBN
QVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5v
ZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVh
ZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLg0KDQpOb3RlIOKAkyBJbiBzb21lIGNhc2Vz
LCBlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGgg
YmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1h
eSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkg
bm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2Vp
dmVkIHRoZSByZXBvcnQuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFydG9sb21l
DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgMjozMSBQTQ0KVG86IGRpbWVAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZw0KDQpEZWFyIGFsbCwNCg0KSSB0aGluayB0aGVuIHdlIGFncmVlIG9uIHRoZSBw
cm9wb3NlZCB0ZXh0Og0KDQpBIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJl
YWN0aW5nIG5vZGVzIHJlY2VpdmUgbmV3IG92ZXJsb2FkIHJlcG9ydHMuDQoNCkl0IGlzIHJlY29t
bWVuZGVkIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4g
YWxsIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIHJlYWN0aW5nIG5vZGVzLsKgIA0KDQpOb3RlIC0g
dGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBp
biBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rpbmcgbm9kZXMgaWYgdGhhdCBpcyBt
b3JlIGVmZmljaWVudC7CoCBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBiZSBpZ25vcmVk
IGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy4NCg0KQSByZXBv
cnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBh
IHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2Rl
IGFscmVhZHkgaGFzIHJlY2VpdmVkIHRoZSBvdmVybG9hZCByZXBvcnQuDQoNCkJ1dCBzdGlsbCB0
aGVyZSBhcmUgc29tZSBkaXNjcmVwYW5jaWVzIGFib3V0IHRoZSBub3RlLg0KTXkgcHJvcG9zYWwg
aXMgdG8ga2VlcCBpdCBqdXN0IGFzIGFuIGluZGljYXRpb24gb2YgcG90ZW50aWFsIChtYXliZSBu
b3QgYWxsKSBzaXR1YXRpb25zIHRoYXQgc2hvdWxkIGJlIHRha2VuIGludG8gYWNjb3VudCBpZiBl
dmVyIGFueSBpbXBsZW1lbnRhdGlvbiBtYXkgY29uc2lkZXIgdG8gZG8gbm90IGZvbGxvdyB0aGUg
cmVjb21tZW5kYXRpb24gdGhhdCBhIHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVw
b3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzLiANCkJlaW5nIGEgcmVjb21tZW5kYXRpb24gYW5k
IG5vdCBhIG11c3QsIGF0IGxlYXN0IEkgdGhpbmsgd2UgbmVlZCB0byBpbmRpY2F0ZSB3aGF0IG1h
eSBpbXBseSB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbi4gDQpUaGVuIG15IHBy
b3Bvc2FsIGlzIHRoZSBmb2xsb3dpbmcsIHRoYXQgaW5jbHVkZXMgYSBtb2RpZmljYXRpb24gdG8g
bGFzdCBzZW50ZW5jZSBhYm92ZToNCg0KQSByZXBvcnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5v
dCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1
YXJhbnRlZSB0aGF0IHRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgYWN0aXZlIGluIHRo
ZSByZWFjdGluZyBub2RlLg0KDQpOb3RlIOKAk3RoZSByZXBvcnRpbmcgbm9kZSBtYXkgbmVlZCB0
byB0YWtlIGludG8gYWNjb3VudCBuZXR3b3JrIGRlcGxveW1lbnQgYW5kIHBvdGVudGlhbCBlcnJv
cnMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCBzZW50IG92ZXJsb2FkIHJl
cG9ydCBpcyBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUsIGUuZy4gdGhlcmUgbWF5IGJlIG9u
ZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJl
YWN0aW5nIG5vZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rp
bmcgbm9kZXPigKYNCg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpDQpTZW50
OiBtacOpcmNvbGVzLCAxMiBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MTMNClRvOiBkaW1lQGlldGYu
b3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1U
aHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRo
cm90dGxpbmcNCg0KSGkgDQoNCk9uIHRoaXMgdG9waWMsIG15IHZpZXcgaXMgdGhhdCB0aGUgcmVh
Y3Rpbmcgbm9kZSBzaGFsbCDCoHJlY2VpdmUg4oCcZW5vdWdo4oCdIE9MUnMgcGVyIHBlcmlvZCBv
ZiB0aW1lIHRvIGVuc3VyZSB0aGUgZWZmaWNpZW5jeSBvZiB0aGUgdHJhZmZpYyDCoHJlZHVjdGlv
biBtZWNoYW5pc20gLiBBIHdheSB0byBhY2hpZXZlIMKgdGhlIOKAnGVub3VnaOKAnSBpcyB0byBo
YXZlIGFuIE9MUiBpbiBhbGwgwqBhbnN3ZXIgwqBtZXNzYWdlcyBhcyBwcm9wb3NlZCBhbmQgdGhp
cyBjYW4gdGhlIHJlY29tbWVuZGVkIHdheS4gTm93IGFzIE5pcmF2IHNhaWQsIHRoZXJlIG1heSBi
ZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3aWxsIGJlaGF2ZSBkaWZmZXJlbnRseSBhbmQgc2VuZCDi
gJxlbm91Z2jigJ0gT0xScyDCoGJ1dCBub3QgaW4gYWxsIG1lc3NhZ2VzLg0KDQpBcyBhbHNvIE5p
cmF2IG5vdGVkLCDCoEkgZG8gbm90IHdlbGwgc2VlIHRoZSBuZWVkIHRvIHdyaXRlIGFkZGl0aW9u
YWwgbm90ZXMgYXMgbWFueSBzaXR1YXRpb25zIGNhbiBvY2N1ciBhbmQgwqBhcmUgbm90IGxpbWl0
ZWQgdG8gdGhlIGV4YW1wbGUgb2YgdGhlIHJlYWN0aW5nIMKgbm9kZSDCoGRpc2NhcmRpbmcgT0xS
cy4NCg0KQmVzdCByZWdhcmRzDQoNCkpKYWNxdWVzIA0KDQoNCg0KRGXCoDogRGlNRSBbbWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb20gRW52b3nDqcKgOiBtYXJkaSAxMSBmw6l2cmllciAyMDE0IDE2OjM1IMOAwqA6IE1hcmlh
IENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnIE9iamV0wqA6IFJlOiBbRGltZV0gW2RpbWVd
ICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBt
ZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBdCBsZWFzdCwgaXQgaXMgY29y
cmVjdCEg4pi6DQoNCkRlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERl
IGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgRW52b3nDqcKgOiBtYXJkaSAxMSBmw6l2
cmllciAyMDE0IDE1OjAwIMOAwqA6IGRpbWVAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtEaW1lXSBb
ZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1
ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkxpb25lbCwgTmlyYXYs
IGFsbCwNCg0KTWF5YmUgdGhlIG5vdGUgY291bGQgYmUgbW9kaWZpZWQ6DQoNCk5vdGUg4oCTdGhl
IHJlYWN0aW5nIG5vZGUgY291bGQgYmUgYW55IGFnZW50IGluIHRoZSBwYXRoLCBhbmQgdGhhdCBp
biBzb21lIGVycm9yIHNpdHVhdGlvbnMgb3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVk
IGJ5IHJlYWN0aW5nIG5vZGVzLg0KDQpJIGFkZGVkIHRoZSBjYXNlIE9MUiBjb3VsZCBiZSBkaXNj
YXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMsIHNpbmNlIGl0IGhpZ2hsaWdodHMgYSBzaXR1YXRpb24g
d2hlcmUgdGhlIHNlcnZlciB3aWxsIG5vdCBrbm93IHdoZXRoZXIgb3Igbm90IGEgdmFsaWQgT0xS
IGlzIHJlY2VpdmVkIGJ5IHJlYWN0aW5nIG5vZGUuDQoNCkJlc3QgcmVnYXJkcw0KL01DcnV6DQoN
Cg0KRnJvbTogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFttYWlsdG86bGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tXQ0KU2VudDogbWFydGVzLCAxMSBkZSBmZWJyZXJvIGRlIDIwMTQgMTE6MzYNClRv
OiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1l
XSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBy
ZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkF0IGxlYXN0LCBp
dCBpcyBub3QgInRoZSBvbmx5IHN1cmUgd2F5Ii4NCkZvciBpbnN0YW5jZSwgc3Vic2VxdWVudCBt
ZXNzYWdlcyBwYXJ0IG9mIHRoZSBzYW1lIHNlc3Npb24gKG9yIHBzZXVkby1zZXNzaW9uKSBjb3Vs
ZCBhbHNvIGJlIHVzZWQgYXMgaW5kaWNhdGlvbiBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRoYXQg
dGhlIE9MUiBoYXMgYmVlbiByZWNlaXZlZCBieSB0aGUgcmVhY3Rpbmcgbm9kZSAoYmVzaWRlcyB0
aGUgcmVjZXB0aW9uIG9mIHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgaW4gdGhlIHJlcXVlc3Qp
Lg0KSXQgaXMgd2h5IEkgd2FzIHNheWluZyB0aGF0IHRoaXMgY2FuIGJlIGZpeGVkIHBlciBhcHBs
aWNhdGlvbi9zeXN0ZW0uDQoNCkxpb25lbA0KDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogQmFydG9sb21lIEVudm95w6nC
oDogbWFyZGkgMTEgZsOpdnJpZXIgMjAxNCAxMTozMSDDgMKgOiBkaW1lQGlldGYub3JnIE9iamV0
wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmct
SW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0K
DQpGaW5lIE5pcmF2LCBJIGFncmVlIHRoaXMgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpN
eSBpbnRlbnRpb24gaXMgdGhhdCBhbnkgcmVhZGVyIHJlYWxpemVzIHdoYXQgdGhpcyBrbm93bGVk
Z2UgaW4gdGhlIHNlcnZlciBpbXBsaWVzIHdoZW4gd2UgdGFsayBhYm91dCBhZ2VudHMgaW4gdGhl
IHBhdGguIFRoaXMgaXMgd2h5IEkgdGhpbmsgdGhpcyBub3RlIGlzIGhlbHBmdWwuDQoNClJlZ2Fy
ZHMNCi9NQ3J1eg0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBj
aXNjby5jb21dDQpTZW50OiBtYXJ0ZXMsIDExIGRlIGZlYnJlcm8gZGUgMjAxNCAxMToyNg0KVG86
IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBkbyBub3QgYWdy
ZWUgcmVnYXJkaW5nIHRoZSBjb21wbGV4aXR5IHNpbmNlIGl0IGlzIGhpZ2hseSBpbXBsZW1lbnRh
dGlvbiBzcGVjaWZpYy4NCkxldHMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gaW4gdGhlIHByb3Rv
Y29sIGRlc2lnbi4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNl
bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDM6NTQgUE0NClRvOiBkaW1lQGlldGYub3Jn
DQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJv
dHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90
dGxpbmcNCg0KSGVsbG8sDQoNCkkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGhpZ2hsaWdodCBj
b21wbGV4aXR5IGZvciB0aGUgc2VydmVyIHRvIMKg4oCcZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0
aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC7igJ0gDQpJ
IHRoaW5rIHRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHNlbnRlbmNlIGFkZGVkIGJ5IFN0ZXZl
Lg0KDQpDaGVlcnMNCi9NQ3J1eg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgTmlyYXYgU2Fsb3QgKG5zYWxvdCkNClNlbnQ6IG1hcnRlcywg
MTEgZGUgZmVicmVybyBkZSAyMDE0IDExOjIwDQpUbzogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t
OyBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KSSBhbSBhbHNvIGZpbmUgd2l0
aCBTdGV2ZSdzIHByb3Bvc2VkIHdvcmRpbmcgdG8gcmVjb21tZW5kIHRoZSBpbmNsdXNpb24gb2Yg
T0xSIGJ1dCB0byBub3QgbWFuZGF0ZSBpdC4NCg0KSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgZm9s
bG93aW5nIHRleHQsIGlmIGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIGFkZCBpdC4NCk5v
dGUgLSB0aGUgb25seSBzdXJlIHdheSwgd2l0aG91dCBwcm9wcmlldGFyeSBtZWNoYW5pc21zLCB0
byBrbm93IHRoYXQgYSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCBhbiBvdmVybG9hZCByZXBv
cnQgaXMgd2hlbiB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBhIGNsaWVudCBhbmQgdGhlcmUgaXMgbm8g
YWdlbnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVwb3J0aW5nIG5vZGUuDQoNCkkgcHJl
ZmVyIHRvIHJlbW92ZSBpdCBzaW5jZSBJIGRvIG5vdCBzZWUgYXMgdmFsdWUgYWRkaXRpb24uIA0K
DQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NClNlbnQ6IE1vbmRh
eSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MTMgUE0NClRvOiBTdGV2ZSBEb25vdmFuOyBkaW1lQGll
dGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KSSdtIGZpbmUgd2l0aCBhIHJlY29tbWVuZGF0aW9uLg0KDQpCdXQgSSBo
YXZlIGEgZ2VuZXJhbCBjb21tZW50OiB3aGVuIGEgTUFZIG9yIGV2ZW4gYSBTSE9VTEQgYXBwbHks
IGl0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBOT1QgdXAgdG8gdGhlIG5vZGUgdG8gZG8gb3Ig
bm90IHRvIGRvIHNvbWV0aGluZy4gSXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IGlzIG9ubHkgYW4g
aW1wbGVtZW50YXRpb24gb3B0aW9uLg0KRm9yIGluc3RhbmNlLCBvdmVyIGEgZ2l2ZW4gaW50ZXJm
YWNlLCB0aGUgcmVsYXRlZCBzcGVjaWZpY2F0aW9uIGNhbiBzYXkgdGhhdCBzb21lIHN0YXRlcyBh
cmUgbWFpbnRhaW5lZCBieSB0aGUgc2VydmVyLiBBbmQgaXQgY291bGQgYmUgZGVjaWRlZCB0byBh
ZGQgc29tZSBvdmVybG9hZCByZWxhdGVkIGluZm8gaW4gc3VjaCBzdGF0ZXMuIEZvciBpbnN0YW5j
ZSBhZ2FpbiwgdGhlIG5vZGUgY2FuIHVzZSB0aGlzIHN0YXRlIHRvIGtub3cgaWYgYSByZW1vdGUg
bm9kZSBoYXZlIGJlZW4gbm90aWZpZWQgb3Igbm90IGZvciBpbnN0YW5jZS4gQW5kIGluIHN1Y2gg
YSBjYXNlLCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaW5jbHVkZSBhbiBPTFIgaW4gZWFj
aCBtZXNzYWdlLiBJdCBpcyBqdXN0IGZvciBpbGx1c3RyYXRpb24uIFRoZSBwb2ludCBpcyB0aGF0
IHlvdSBtYXkgaGF2ZSBzb21lIGNhc2VzIGZvciB3aGljaCB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dl
ciBtaWdodCBub3QgYmUgcmVxdWlyZWQuDQoNCkkgYWdyZWUgdGhhdCBoYXZpbmcgdGhlIE9MUiBp
biBldmVyeSBhbnN3ZXIgaXMgZmluZeKApiBidXQgaXQgc2hvdWxkIGJlIG5vdCBtYW5kYXRvcnkg
aW4gYWxsIGNhc2VzIEkgdGhpbmsuIFNvIE9LIGZvciBhICJTSE9VTEQiIG9yICJSRUNPTU1FTkRF
RCIuDQoNClJlZ2FyZHMsDQoNCkxpb25lbCANCg0KRGXCoDogRGlNRSBbbWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2ZSBEb25vdmFuIEVudm95w6nCoDogbHVu
ZGkgMTAgZsOpdnJpZXIgMjAxNCAxNzoyMSDDgMKgOiBkaW1lQGlldGYub3JnIE9iamV0wqA6IFJl
OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpJIGFn
cmVlIHdpdGggYm90aCBNYXJpYSBDcnV6IGFuZCBOaXJhdi4gOi0pDQoNCkkgc3VnZ2VzdCB0aGF0
IHdlIGhhdmUgd29yZGluZyBzYXlpbmcgdGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIGlzIHRvIGlu
Y2x1ZGUgdGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRo
ZSByZWFzb25zIGxpc3RlZCBieSBNYXJpYSBDcnV6LsKgIA0KDQpJIGFsc28gc3VnZ2VzdCB0aGF0
IHdlIGluY2x1ZGUgTmlyYXYncyBwcm9wb3NhbCB0aGF0IGlmIGEgcmVwb3J0aW5nIG5vZGUga25v
d3MgdGhhdCBhIHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQg
cmVwb3J0IHRoZW4gaXQgbWF5IGNob29zZSB0byBub3Qgc2VuZCBpdCBhZ2Fpbi7CoCBJIGRvbid0
IHRoaW5rIHdlIG5lZWQgdG8gaW5jbHVkaW5nIGFueXRoaW5nIGFib3V0IGhvdyB0aGUgcmVwb3J0
aW5nIG5vZGUga25vd3MgYnV0IHdlIHNob3VsZCBpbmNsdWRlIHdvcmRpbmcgYWJvdXQgbmV0d29y
a3MgYXJjaGl0ZWN0dXJlcyB0aGF0IG1ha2UgaXQgZGlmZmljdWx0IHRvIGtub3cuwqAgVGhlIGNh
c2Ugb2YgYWdlbnRzIGFjdGluZyBhcyByZWFjdGluZyBub2RlcyBmb3Igbm9uIHN1cHBvcnRpbmcg
Y2xpZW50cyBiZWluZyBvbmUgZXhhbXBsZS4NCg0KV2UgYWxzbyBuZWVkIHRvIG1ha2Ugc3VyZSB0
aGF0IHRoZSByZWNvbW1lbmRlZCBhcHByb2FjaCBpcyBub3QgcHJlY2x1ZGVkIGJ5IE5pcmF2J3Mg
cHJvcG9zYWwuDQoNCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSB3b3JkaW5nLCB3
aGljaCBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IE1hcmlhIENydXoncyByZWFzb25zIGZvciByZWNv
bW1lbmRpbmcgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFsd2F5cyBpbmNsdWRlZC4NCg0K
LS0tLS0NCg0KQSByZXBvcnRpbmcgbm9kZSBNVVNUIGVuc3VyZSB0aGF0IGFsbCByZWFjdGluZyBu
b2RlcyByZWNlaXZlIG5ldyBvdmVybG9hZCByZXBvcnRzLg0KDQpJdCBpcyByZWNvbW1lbmRlZCB0
aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3
ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy7CoCANCg0KTm90ZSAtIHRoZSByZXBv
cnRpbmcgbm9kZSBtYXkgYWxzbyBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYW5zd2Vy
IG1lc3NhZ2VzIHNlbnQgdG8gbm9uIHJlYWN0aW5nIG5vZGVzIGlmIHRoYXQgaXMgbW9yZSBlZmZp
Y2llbnQuwqAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERp
YW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5v
ZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGlu
ZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5
IGhhcyByZWNlaXZlZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0KDQpOb3RlIC0gdGhlIG9ubHkgc3Vy
ZSB3YXksIHdpdGhvdXQgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcywgdG8ga25vdyB0aGF0IGEgcmVh
Y3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgYW4gb3ZlcmxvYWQgcmVwb3J0IGlzIHdoZW4gdGhlIHJl
YWN0aW5nIG5vZGUgaXMgYSBjbGllbnQgYW5kIHRoZXJlIGlzIG5vIGFnZW50IGJldHdlZW4gdGhl
IGNsaWVudCBhbmQgdGhlIHJlcG9ydGluZyBub2RlLg0KT24gMi8xMC8xNCAzOjUyIEFNLCBNYXJp
YSBDcnV6IEJhcnRvbG9tZSB3cm90ZToNCkhlbGxvIE5pcmF2LA0KDQpBbnkgc29sdXRpb24gc2hv
dWxkIGJhbGFuY2UgZGlmZmVyZW50IGZhY3RvcnMsIGVmZmljaWVuY3kgY291bGQgYmUgZGlzY3Vz
c2VkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0aXZlcywgYnV0IGZpcnN0IHdlIG5lZWQgdG8gYXNz
dXJlIHRoZSBtZWNoYW5pc20gd2UgYXJlIGRlZmluaW5nIGlzIHByb3ZpZGluZyB2YWxpZCBPTFIg
dG8gcmVhY3Rpbmcgbm9kZXMuDQoNCllvdXIgcHJvcG9zZWQgdGV4dA0KIiBBZGRpdGlvbmFsbHks
IGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2Fy
ZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0
aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBy
ZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBB
VlAuIg0KDQpJZiB0aGUgcmVwb3J0aW5nIGlzIG5vdCBhd2FyZSBhYm91dCB3aGV0aGVyIG9yIG5v
dCBvdmVybG9hZCByZXBvcnQgaXMgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIGFuZCBp
dCBkZWNpZGVzIChzaW5jZSBpdCBpcyBhICJtYXkiKSB0byBkbyBub3Qgc2VuZCB0aGUgT0xSIGFn
YWluLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gbWVjaGFuaXNtIHdpbGwgbm90IHdvcmsgaW4g
Y2FzZSBPTFIgd2FzIG5vdCBwcm9wZXJseSByZWNlaXZlZCBieSBjb3JyZXNwb25kaW5nIHBvdGVu
dGlhbCByZWFjdGluZyBub2Rlcy4gQW5kIHdlIG5lZWQgdG8gbm90ZSB0aGF0ICJyZWFjdGluZyBu
b2RlcyIgY291bGQgYmUgbm90IG9ubHkgdGhlIGNsaWVudCwgYnV0IEFOWSBhZ2VudCB1c2VkIGZv
ciByb3V0aW5nIChub3Qgb25seSB3aGVuIHRoZSBhZ2VudCBpcyBwcm92aWRpbmcgc2VydmljZSB0
byBhIFJlYWxtLCBidXQgd2hlbiBpdCBpcyByZWFjdGluZyBvbiBiZWhhbGYgb2YgYSBub24tc3Vw
cG9ydGluZyBjbGllbnQpLiANClRoZW4sIG9uIG9uZSBoYW5kIGl0IGlzIG5vdCBzaW1wbGUgdG8g
a25vdyB3aGVuIHJlYWN0aW5nIG5vZGVzIGhhdmUgdmFsaWQgT0xSIGluZm8gKGFzIGV4cGxhaW5l
ZCBiZWxvdyksIGJ1dCBpZiBPTFIgaXMgbm90IHNlbnQgYWdhaW4gKGFzIHBlciB5b3VyIHByb3Bv
c2VkICJtYXkiKSB0aGVuIG9uZSBvciBtdWx0aXBsZSByZWFjdGluZyBub2RlcyBkbyBub3QgaGF2
ZSB0aGUgcmVxdWlyZWQgT0xSLCB0aGVuIG92ZXJsb2FkIG1pdGlnYXRpb24gd2lsbCBub3Qgd29y
ay4NCg0KVGhlcmVmb3JlLCBpbiBteSBvcGluaW9uLCB0aGUgc2ltcGxlc3Qgd2F5IHRvIHByb3Zp
ZGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdG8gcHJvdmlkZSBPTFIgaW4gQUxMIGFuc3dlcnMu
DQoNCkJlc3QgcmVnYXJkcw0KL01DcnV6DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQpTZW50
OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQyDQpUbzogTWFyaWEgQ3J1eiBCYXJ0
b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpCdXQgTWFyaWEtQ3J1eiwNCg0KSG93IGNhbiB3
ZSBzYXkgdGhhdCAiaW5jbHVkaW5nIHRoZSBPTFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMg
aXMgc2ltcGxlIGFuZCBlZmZpY2llbnQ/Ig0KSXQgaXMgc2ltcGxlIGZvciBzdXJlIGJ1dCBub3Qg
ZWZmaWNpZW50LiANCg0KQSBzbGlnaHRseSBkaWZmZXJlbnQgd29yZGluZyBmcm9tIHdoYXQgSSBw
cm9wb3NlZCBlYXJsaWVyIGlzLCBXaGVuIHRoZSByZXBvcnRpbmcgbm9kZSBoYXMgYSBuZXcgb3Zl
cmxvYWQgcmVwb3J0IHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gYSByZWFjdGluZyBub2Rl
IChieSB1cGRhdGluZyB0aGUgZWFybGllciBwcm92aWRlZCBvdmVybG9hZCByZXBvcnQgb3IgYnkg
cHJvdmlkaW5nIHRoZSBvdmVybG9hZCByZXBvcnQgZm9yIHRoZSBmaXJzdCB0aW1lKSwgaXQgc2hh
bGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUgcmVxdWVzdCBjb250YWluaW5n
IE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUgY29ycmVzcG9uZGluZyByZWFj
dGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJl
cG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVh
ZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkg
aW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhlIHJlcXVlc3QgY29udGFpbmlu
ZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KU2VudDogTW9uZGF5LCBG
ZWJydWFyeSAxMCwgMjAxNCAzOjAzIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2
LCBhbGwsDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGRlZmluZSBhbiBhY2N1cmF0ZSBhbmQgcm9idXN0
IHNvbHV0aW9uLCBhcyBlZmZpY2llbnQgYW5kIHNpbXBsZSBhcyBwb3NzaWJsZS4NCkkgdW5kZXJz
dGFuZCB5b3VyIHByb3Bvc2FsIGFzIGEgcHVyZSAibWF5IiwgYnV0IGxlYXZpbmcgaXQgdXAgdG8g
aW1wbGVtZW50YXRpb24gZG9lcyBub3QgYXNzdXJlIHJlYWN0aW5nIG5vZGUgaGFzIHZhbGlkIE9M
UiBpbmZvcm1hdGlvbiwgd2hhdCBpcyBiYXNpYyBmb3IgdGhpcyBtZWNoYW5pc20gdG8gd29yay4g
DQoNCkJlc3QgcmVnYXJkcw0KL01DcnV6DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQpTZW50
OiBsdW5lcywgMTAgZGUgZmVicmVybyBkZSAyMDE0IDEwOjEyDQpUbzogTWFyaWEgQ3J1eiBCYXJ0
b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpNYXJpYS1DcnV6LA0KDQpJIGZ1bGx5IGFncmVl
IHdpdGggeW91IG9uICJzZW5kaW5nIE9MUiBpbiBBTEwgYW5zd2VycyBoYXMgc29tZSBpbXBvcnRh
bnQgYWR2YW50YWdlcyIuDQpBbmQgd2UgYXJlIG5vdCB0cnlpbmcgdG8gcHJldmVudCBpdCAtIGF0
IGxlYXN0IHRoYXQgaXMgbXkgaW50ZW50aW9uLiANCkJ1dCB0aGUgbWFpbiBxdWVzdGlvbiBpcywg
YXJlIHdlIHRyeWluZyB0byBwcmV2ZW50IGFueSBvdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlv
biwgd2hpY2ggbWF5IGJlIHNtYXJ0ZXIgYW5kIGNhbiBhdm9pZCBpbmNsdWRpbmcgcmVkdW5kYW50
IE9MUiBpbiBhbGwgdGhlIGFuc3dlciBtZXNzYWdlPw0KDQpNb3N0IHByb2JhYmx5LCB0aGUgdmVy
eSBmaXJzdCBpbXBsZW1lbnRhdGlvbiBvZiBvdmVybG9hZCBjb250cm9sIHdpbGwgaW5jbHVkZSBP
TFIgaW4gYWxsIHRoZSBhbnN3ZXIgbWVzc2FnZXMuDQpCdXQgYXQgdGhlIHNhbWUgdGltZSwgSSBk
byBub3Qgd2FudCB0byByZXN0cmljdCB0aGUgZGV2ZWxvcGVycyB3aGljaCBjYW4gY29tZSB1cCB3
aXRoIHNvbWUgbmljZSB0d2Vha3MgYW5kIHRyaWNrcyB0byBhdm9pZCBzZW5kaW5nIHRoZSBzYW1l
IGluZm9ybWF0aW9uIGluIGV2ZXJ5IG1lc3NhZ2UuIEFuZCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQg
dG8gYmUgY2FyZWZ1bCBhbmQgYXZvaWQgcHV0dGluZyBzdWNoIHJlc3RyaWN0aW9ucyBpbiBwcm90
b2NvbCBkZWZpbml0aW9uLiANCldoYXQgZG8geW91IHRoaW5rPw0KDQpUaGlzIGFsc28gdGhlIHJl
YXNvbiBJIHdhcyBzdWdnZXN0aW5nIGxvb3NlIGRlc2NyaXB0aW9uIG9mIHdoZW4gdG8gaW5jbHVk
ZSBPTFIgKGZyb20gdGhlIHJlcG9ydGluZyBub2RlIHBvaW50IG9mIHZpZXcpLg0KDQpSZWdhcmRz
LA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xv
bWUNClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDcsIDIwMTQgODo1NyBQTQ0KVG86IGRpbWVAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZw0KDQpIZWxsbyBVbHJpY2gsIE5pcmF2LA0KDQpJIGFncmVlIHdpdGggVWxyaWNo
IHRoYXQgdGhlIHRleHQgcHJvdmlkZWQgYnkgTmlyYXYgaXMganVzdCBhIE1BWSwgYW5kIHdoZXRo
ZXIgb3Igbm90IHRoZSBzZXJ2ZXIgc2VuZHMgYW4gT0xSIGluIGFsbCBhbnN3ZXJzIHNoYWxsIG5v
dCBiZSBqdXN0IGEgTUFZLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgY3JpdGVyaWEgcHJvdmlkZWQg
YnkgVWxyaWNoIG9uIHdoZW4gT0xSIGhhcyB0byBiZSBzZW50IHJlcXVpcmVzIHRoZSBzZXJ2ZXIg
aGFzIHNvbWUga25vd2xlZGdlOg0KYSkgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIHRoYXQgdGhl
IHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgZ290IHRoZSBsYXRlc3QgT0xSDQpiKSB0aGUgcmVw
b3J0aW5nIG5vZGUgaXMgbm90IG92ZXJsb2FkZWQgKGkuZC4gZG9lcyBub3Qgd2FudCBhIHRocm90
dGxpbmcpIGFuZCBrbm93cyB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyBnb3QgYW4gT0xSIHRo
YXQgd2lsbCBzb29uIGV4cGlyZQ0KYykgb3RoZXJ3aXNlDQoNClJlcG9ydGluZyBub2RlIG11c3Qg
aGF2ZSBzb21lIGtub3dsZWRnZSBhYm91dCBPTFIgcmVjZXB0aW9uL3N0YXR1cyBpbiByZWFjdGlu
ZyBub2RlLiBIb3cgZG9lcyBzZXJ2ZXIgYWNxdWlyZSB0aGlzIGtub3dsZWRnZT8gDQpUYWtlIGlu
dG8gYWNjb3VudCBhcyB3ZWxsIHRoYXQgYSAicmVhY3RpbmciIG5vZGUgbWF5IGJlIGJvdGggYW4g
QWdlbnQgKGluIGNhc2UgaXQgcHJvdmlkZXMgc2VydmljZSB0byBhIHJlYWxtIG9yIGFjdGluZyBv
biBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBjbGllbnQpwqAgYW5kIGEgQ2xpZW50LiBJbiB0
aGUgY2FzZSBvZiBBZ2VudHMsIGluIGZhY3QgdGhlIFNlcnZlciBtYXkgbm90IGV2ZW4ga25vdyBp
ZiB0aGlzIGlzIGdvaW5nIHRvIGFjdCBhcyBhIHJlYWN0aW5nIG5vZGUgb3IganVzdCB0cmFuc3Bh
cmVudGx5LCBpbiBmYWN0LCB0aGUgc2VydmVyIGRvZXMgbm90IG5lZWQgdG8gaGF2ZSBhbnkga25v
d2xlZGdlIGFib3V0IHdoYXQgYWdlbnRzIGluIHRoZSBjaGFpbiB0byB0aGUgZmluYWwgQ2xpZW50
Lg0KDQpUaGVyZWZvcmUsIEkgZGVmaW5pdGVseSB0aGluayB0aGF0IHNlbmRpbmcgT0xSIGluIEFM
TCBhbnN3ZXJzIGhhcyBzb21lIGltcG9ydGFudCBhZHZhbnRhZ2VzOg0KLSBzdGF0ZS1sZXNzIGlt
cGxlbWVudGF0aW9uICh0cmFuc2FjdGlvbiBvciBzZXNzaW9uKSBpcyBzaW1wbGVyLA0KLSB0aGUg
c2VydmVyIGRvZXMgbm90IG5lZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQg
YW4gT0wgdG8gYSByZWFjdGluZyBub2RlDQotIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBi
b3RoZXIgd2hldGhlciBhbiByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGFuIE9M
UiBvciB3aGV0aGVyIHRoaXMgT0xSIGlzIHN0aWxsIHZhbGlkIChoYXMgbm90IGV4cGlyZWQpLg0K
LSBzZW5kaW5nIGFuIGFkZGl0aW9uYWwgQVZQIGlzIG5vdCBwcm9jZXNzaW5nIGNvbnN1bWluZywg
aW4gY29tcGFyaXNvbiB3aXRoIHJlcXVpcmVkIGFib3ZlIGNoZWNrcyAoaWYgdGhpcyBpcyBub3Qg
c2VudCkuIA0KwqAgSW4gZmFjdCwgaW4gYW4gb3ZlcmxvYWQgc2l0dWF0aW9uLCB0aGUgZWFzaWVz
dCBhbmQgbGVhc3QgY29tcGxleCBpcyB0byBzZW5kIGluZm9ybWF0aW9uIG91dCB0byBhbGwgYWZm
ZWN0ZWQvYXBwbGljYWJsZSBub2RlcywNCsKgIGFuZCB0aGUgbGF0dGVyIHNob3VsZCB0YWtlIGNh
cmUgdG8gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb25zDQotIG1vcmUgcm9idXN0IHNvbHV0aW9uLCBh
cyBubyBuZWVkIHRvIGNhdGVyIGZvciBhbGwgdGhlIGNoZWNrcyBvbiB0aGUgbmVlZCB0byBzZW5k
IGluZm9ybWF0aW9uLMKgIGZvciBzaXR1YXRpb25zIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdlIGlz
IGxvc3QswqAg4oCmDQoNCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpDQpTZW50OiB2aWVybmVz
LCAwNyBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NTkNClRvOiBleHQgTmlyYXYgU2Fsb3QgKG5zYWxv
dCk7IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb207IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1l
QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25n
b2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZl
ZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsDQoNCkknbSBhZnJhaWQgeW91ciBwcm9wb3NlZCB0ZXh0
IGRvZXMgbm90IHJlZmxlY3QgdGhlIGludGVudGlvbi4NCg0KIndoZW4gaXQgd2FudHMgdG8gcHJv
dmlkZS91cGRhdGUuLi4uaXQgc2hhbGwgaW5jbHVkZS4uLiIgdHJhbnNsYXRlcyB0byAiLi4uaXQg
bWF5IGluY2x1ZGUuLi4iLg0KDQoiaW4gb3RoZXIgY2FzZXMiIGluIHRoZSBnaXZlbiBjb250ZXh0
IHRyYW5zbGF0ZXMgdG8gIndoZW4gaXQgZG9lcyBub3Qgd2FudCB0byBwcm92aWRlL3VwZGF0ZS4u
LiINCg0KDQpXZSBoYXZlIHRoZSBmb2xsb3dpbmcgY2FzZXM6DQphKSB0aGUgcmVwb3J0aW5nIG5v
ZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFkeSBnb3QgdGhlIGxhdGVz
dCBPTFINCmIpIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3Qgb3ZlcmxvYWRlZCAoaS5kLiBkb2Vz
IG5vdCB3YW50IGEgdGhyb3R0bGluZykgYW5kIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUg
aGFzIGdvdCBhbiBPTFIgdGhhdCB3aWxsIHNvb24gZXhwaXJlDQpjKSBvdGhlcndpc2UNCg0KaW4g
Y2FzZSBhKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgcmVwbGF5IHRoZSBPTFIg
aW4gY2FzZSBiKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG9yIG1heSBub3QgdXBkZGF0ZSB0aGUg
cmVhY3Rpbmcgbm9kZSB3aXRoIHRoZSBsYXRlc3QgT0xSIGluIGNhc2UgYykgdGhlIHJlcG9ydGlu
ZyBub2RlIE1VU1QgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSBhbnN3ZXIgKHRoZSByZXBvcnRpbmcg
bm9kZSBkb2VzIG5vdCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIHJlcGxheSBvciBhbiB1cGRhdGUp
DQoNClVscmljaA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgTmly
YXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KU2VudDogVGh1cnNk
YXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDQ6NDkgUE0NClRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBE
RS9NdW5pY2gpOyBleHQgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBleHQgU3RldmUgRG9ub3Zh
bjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5n
IE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQg
c3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNClVscmljaCwNCg0KSXQgc2VlbXMgd2UgYWxsIGFyZSBv
biBzYW1lIHBhZ2UgYnV0IHByb2JhYmx5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93IGlzIG5v
dCB0aGUgYmVzdC4NCkhvdyBhYm91dCB0aGUgZm9sbG93aW5nLg0KDQpXaGVuIHRoZSByZXBvcnRp
bmcgbm9kZSB3YW50cyB0byBwcm92aWRlIG5ldyBvdmVybG9hZCByZXBvcnQgb3Igd2FudHMgdG8g
dXBkYXRlIHRoZSBlYXJsaWVyIHByb3ZpZGVkIG92ZXJsb2FkIHJlcG9ydCB0b3dhcmRzIGEgcmVh
Y3Rpbmcgbm9kZSwgaXQgc2hhbGwgaW5jbHVkZSBPTFIgaW4gdGhlIHJlc3BvbnNlLCB0byB0aGUg
cmVxdWVzdCBjb250YWluaW5nIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCwgdG93YXJkcyB0aGUg
Y29ycmVzcG9uZGluZyByZWFjdGluZyBub2RlLiBBZGRpdGlvbmFsbHksIGluIG90aGVyIGNhc2Vz
LCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBhd2FyZSBpZiB0aGUgb3Zlcmxv
YWQgcmVwb3J0IGlzIGFscmVhZHkgcHJvdmlkZWQgdG8gdGhlIHJlYWN0aW5nIG5vZGUsIHRoZSBy
ZXBvcnRpbmcgbm9kZSBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIHRoZSByZXNwb25zZSwgdG8gdGhl
IHJlcXVlc3QgY29udGFpbmluZyBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNClJlZ2FyZHMs
DQpOaXJhdi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdpZWhlLCBVbHJp
Y2ggKE5TTiAtIERFL011bmljaCkgW21haWx0bzp1bHJpY2gud2llaGVAbnNuLmNvbV0NClNlbnQ6
IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCAzOjU3IFBNDQpUbzogZXh0IGxpb25lbC5tb3Jh
bmRAb3JhbmdlLmNvbTsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGV4dCBTdGV2ZSBEb25vdmFuOyBk
aW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0Mt
T25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2
aXZlZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsIExpb25lbCwNCg0KSSBjYW4gdW5kZXJzdGFuZCBO
aXJhdidzIGNvbmNlcm4gKGFsdGhvdWdoIHZpb2xhdGluZyBSRVExMCkgYW5kIGhvcCBpdCBpcyBh
ZGRyZXNzZWQgYnkgdGhlIG1vZGlmaWVkIHByaW5jaXBsZSAyJzoNCg0KMicuIHRoZSByZXBvcnRp
bmcgbm9kZSAobm8gbWF0dGVyIHdoZXRoZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUg
bm90IHRvIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFp
bmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSBy
ZWFjdGluZyBub2RlIGFscmVhZHkgaGFzIGdvdCByZWFzb25hYmxlIG92ZXJsb2FkIGNvbnRyb2wg
aW5mb3JtYXRpb24gKGUuZy4gdGhlIGxhdGVzdCBPTFIsIHdoaWNoIG1heSBiZSBhbiBPTFIgcmVx
dWVzdGluZyB0cmFmZmljIHJlZHVjdGlvbiBvciBhbiBPTFIgaW5kaWNhdGluZyAibm8gb3Zlcmxv
YWQiLCBvciBhbiBvbGTCoCBidXQgc29vbiBleHBpcmluZyBPTFIgd2hlbiB0aGUgcmVwb3J0aW5n
IG5vZGUgaXMgbm90IG92ZXJsb2FkZWQpOyBvdGhlcndpc2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3
YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3aGV0aGVyIG92ZXJsb2FkZWQg
b3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNo
IGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAuDQoNCkkgZG9uJ3QgYWdyZWUg
d2l0aCBMaW9uZWxzIGRvLXdoYXQteW91LXdhbnQgYXBwcm9hY2guIE92ZXJsb2FkIGNvbnRyb2wg
d2lsbCBub3Qgd29yayB3aGVuIHdlIGFsbG93IHRoZSByZXBvcnRpbmcgbm9kZSBub3QgdG8gdXBk
YXRlIHJlYWN0aW5nIG5vZGVzLCB3aGljaCBhcmUgbm90IChzdWZmaWNpYW50bHkpIGF3YXJlIG9m
IHRoZSBjdXJyZW50IG92ZXJsb2FkIHN0YXR1cywgd2l0aCB1cCB0byBkYXRlIE9MUnMuDQoNClVs
cmljaMKgIA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBsaW9u
ZWwubW9yYW5kQG9yYW5nZS5jb20gW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dDQpT
ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgMTA6MjAgQU0NClRvOiBOaXJhdiBTYWxv
dCAobnNhbG90KTsgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IFN0ZXZlIERv
bm92YW47IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t
LS0tDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0
IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95w6nCoDogamV1ZGkgNiBmw6l2cmllciAyMDE0
IDEwOjA4IMOAwqA6IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk7IGV4dCBTdGV2ZSBE
b25vdmFuOyBkaW1lQGlldGYub3JnIE9iamV0wqA6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2Vu
ZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0
aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpVbHJpY2gsDQoNCkkgYW0gbm90IHN1cmUgYWJv
dXQgZm9yY2luZyB0aGlzIGJlaGF2aW9yIG9uIHJlcG9ydGluZyBub2RlICJvdGhlcndpc2UgKGku
ZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1hdHRlciB3
aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVzcG9uc2Vz
IHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZSBBVlAu
Ig0KVGhlIHJlcG9ydGluZyBub2RlIG1heSBzaW1wbHkgbm90IGluY2x1ZGUgT0xSIGFzc3VtaW5n
IHRoYXQgdGhlIGVhcmxpZXIgcHJvdmlkZWQgT0xSIHdpbGwgZXhwaXJlIGFuZCB0aGUgcmVhY3Rp
bmcgbm9kZSB3aWxsIHN0b3AgdGhyb3R0bGluZyB0aGUgdHJhZmZpYy4NCg0KW0xNXSBBZ3JlZS4g
SW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBkZWVtZWQgcmVxdWlyZWQgZm9yIHRoZSBkZWZhdWx0
IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gSG93IGFuZCB3aGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBkZWNpZGVzIHRvIGluY2x1ZGUgdGhlIE9MUiBpbiB0aGUgYW5zd2VyIG1heSBk
ZXBlbmQgb24gdGhlIGFwcGxpY2F0aW9uIG9yIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gQXQgbGVh
c3QsIGl0IGlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4NCg0KQXMgd2UgaGFkIGRpc2N1c3Nl
ZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZXhw
bGljaXRseSBzdG9wIHRocm90dGxpbmcgYXQgZWFjaCByZWFjdGluZyBub2RlIGF0IHRoZSBzYW1l
IHRpbWUuIEluIG90aGVyIHdvcmRzLCB0aGUgcmVwb3J0aW5nIG5vZGUgY2FuIGFsbG93IHRoZSBu
YXR1cmFsIGV4cGlyeSBvZiB0aGUgT0xSIHRvIGZhY2lsaXRhdGUgc2xvdyByYW1wIG9mIHRoZSBz
aWduYWxpbmcgdHJhZmZpYyB0b3dhcmRzIGl0Lg0KDQpbTE1dIEFncmVlDQoNClRoZXJlIG1heSBi
ZSBvdGhlciBjYXNlcywgZS5nLiB3aGVuIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyB0aGF0IHRo
ZSBsYXN0IG92ZXJsb2FkIHNpdHVhdGlvbiBlbmRlZCBsb25nIHRpbWUgYmFjayBpbiB0aGUgcGFz
dCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQgdG8gaW5jbHVkZSBPTFIgaWYgY3VycmVudGx5IHRo
ZXJlIGlzIG5vIG92ZXJsb2FkIGNvbmRpdGlvbi4NCg0KW0xNXSBBZ3JlZQ0KDQpSZXN0IG9mIHRo
ZSBwcmluY2lwbGVzIGJlbG93IGFyZSBmaW5lIHdpdGggbWUuDQoNCltMTV0gQWdyZWUNCg0KUmVn
YXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2llaGUs
IFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSBbbWFpbHRvOnVscmljaC53aWVoZUBuc24uY29tXQ0K
U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDI6MjMgUE0NClRvOiBleHQgU3RldmUg
RG9ub3ZhbjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJF
OiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBB
VlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpBY3R1
YWxseSB3ZSBzZWVtIHRvIGFncmVlIG9uIHR3byBwcmluY2lwbGVzOg0KMS4gTGFjayBvZiBPTFIg
bWVhbnMgIm5vIGNoYW5nZSINCjIuIHRoZSByZXBvcnRpbmcgbm9kZSAobm8gbWF0dGVyIHdoZXRo
ZXIgb3ZlcmxvYWRlZCBvciBub3QpIE1BWSBkZWNpZGUgbm90IHRvIHJldHVybiBhbiBPTFIgaW4g
cmVzcG9uc2UgdG8gcmVxdWVzdHMgd2hpY2ggY29udGFpbmVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0
dXJlIEFWUCBpZiBpdCBpcyBhd2FyZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGFscmVhZHkgaGFz
IGdvdCB0aGUgbGF0ZXN0IE9MUiAod2hpY2ggbWF5IGJlIGFuIE9MUiByZXF1ZXN0aW5nIHRyYWZm
aWMgcmVkdWN0aW9uIG9yIGFuIE9MUiBpbmRpY2F0aW5nICJubyBvdmVybG9hZCIpOyBvdGhlcndp
c2UgKGkuZS4gaWYgaXQgaXMgbm90IGF3YXJlLi4uKSB0aGUgcmVwb3J0aW5nIG5vZGUgKG5vIG1h
dHRlciB3aGV0aGVyIG92ZXJsb2FkZWQgb3Igbm90KSBNVVNUIHJldHVybiBhbiBPTFIgaW4gcmVz
cG9uc2VzIHRvIHJlcXVlc3RzIHdoaWNoIGNvbnRhaW5lZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVy
ZSBBVlAuDQoNCkNhbiBwZW9wbGUgcGxlYXNlIGNvbmZpcm0uDQoNClVscmljaA0KDQpGcm9tOiBE
aU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZl
IERvbm92YW4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDozNSBQTQ0KVG86
IE5pcmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KQWdyZWVkLsKgIFRv
IHJlc3RhdGUgLS0gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQgZG9lcyBub3QgY2hhbmdlIHRo
ZSBjdXJyZW50IG92ZXJsb2FkIHN0YXRlIGZvciB0aGUgaG9zdCBvciByZWFsbS7CoCBJZiB0aGVy
ZSBpcyBhIGN1cnJlbnRseSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gaXQgY29udGludWVz
IHRvIGFwcGx5IHVudGlsIGl0IGVpdGhlciB0aW1lcyBvdXQgb3IgaXMgZXhwbGljaXRseSBjaGFu
Z2VkIHdpdGggYSBuZXcgb3ZlcmxvYWQgcmVwb3J0LsKgIElmIHRoZXJlIGlzIG5vIGN1cnJlbnRs
eSBhY3RpdmUgb3ZlcmxvYWQgcmVwb3J0IHRoZW4gbGFjayBvZiBhbiBvdmVybG9hZCByZXBvcnQg
aW1wbGllcyB0aGVyZSBpcyBubyBvdmVybG9hZCBmb3IgdGhlIGhvc3QgYW5kIHJlYWxtLg0KDQpT
dGV2ZQ0KT24gMi81LzE0IDk6MTkgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KSSBh
Z3JlZSB3aXRoIFN0ZXZlIGV4Y2VwdCB0aGUgcGFydCAic2hvdWxkbuKAmXQgbGFjayBvZiBPTFIg
YmUgaW50ZXJwcmV0ZWQgYXMgbm90IG92ZXJsb2FkZWQ/Ig0KwqANCldlIGhhZCBzb21lIGRpc2N1
c3Npb24gc29tZXRpbWUgYmFjayBhbmQgdGhvdWdodCB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8g
bm90IG1hbmRhdGUgdGhlIHNlcnZlciB0byBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkgYW5zd2Vy
IG1lc3NhZ2UuIEUuZy4gd2hlbiB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgdHJhY2tpbmcgd2hh
dCBpcyBzZW50IHRvIHdoaWNoIGNsaWVudCBhbmQgaGVuY2Ugd2FudHMgdG8gYXZvaWQgc2VuZGlu
ZyBpbmZvcm1hdGlvbiB3aGljaCBpcyByZWR1bmRhbnQuIEJ1dCB0aGlzIGlzIG9wdGlvbmFsIGlt
cGxlbWVudGF0aW9uIGFuZCBhdCB0aGUgc2FtZSB0aW1lIG5lZWQgbm90IGJlIHByb2hpYml0ZWQg
ZnJvbSBwcm90b2NvbCBwb2ludCBvZiB2aWV3Lg0KwqANClNvIGJhc2ljYWxseSwgdGhlIGxhY2sg
b2YgT0xSIHNob3VsZCBub3QgYWZmZWN0IHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBhdCB0
aGUgcmVhY3Rpbmcgbm9kZS4gVGhlIHJlYWN0aW5nIG5vZGUgY2FuIGNvbnRpbnVlIHRvIHJlYWN0
IGJhc2VkIG9uIG9sZGVyIE9MUiB1bnRpbCB0aGUgZXhwaXJ5IG9mIHRoZSB2YWxpZGl0eS1wZXJp
b2Qgb3Igd2hlbiB0aGUgZXhwbGljaXQgT0xSIHdpdGggIjAiIG92ZXJsb2FkLW1ldHJpYyBpcyBy
ZWNlaXZlZC4NCkluIG15IHZpZXcsIHRoaXMgYWxsb3dzIGZvciBmbGV4aWJsZSBpbXBsZW1lbnRh
dGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUgYW5kIHNvdW5kIGhhbmRsaW5nIG9mIE9MUiBhdCB0
aGUgcmVhY3Rpbmcgbm9kZS4NCsKgDQpSZWdhcmRzLA0KTmlyYXYuDQrCoA0KRnJvbTogRGlNRSBb
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4N
ClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODowMCBQTQ0KVG86IGRpbWVAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5n
LVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEg
dGhyb3R0bGluZw0KwqANCmlubGluZQ0KT24gMi81LzE0IDc6NTcgQU0sIFdpZWhlLCBVbHJpY2gg
KE5TTiAtIERFL011bmljaCkgd3JvdGU6DQpPayB0aGVuIGxldCdzIHN0YXRlIHRoYXQgcmVwb3J0
aW5nIG5vZGVzIE1VU1QgaW5zZXJ0IGFuIE9DLU9MUiBBVlAgaW4gYWxsIGFuc3dlciBtZXNzYWdl
cyB0aGF0IGNvcnJlc3BvbmQgdG8gcmVxdWVzdCBtZXNzYWdlcyB3aGljaCBjb250YWluIGFuIE9D
LVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgKGV2ZW4gd2hlbiBubyBsb2FkIHJlZHVjdGlvbiBpcyBy
ZXF1ZXN0ZWQpLg0KU1JEPiBXaHkgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2U/wqAgU2hvdWxkbid0
IGxhY2sgb2YgYW4gT0xSIGJlIGludGVycHJldGVkIGFzIG5vdCBvdmVybG9hZGVkPw0KDQoNCsKg
DQrCoA0KT3RoZXIgY3JpdGVyaWEgbGlrZSBSRVExOCBvciBSRVExMyBkbyBub3Qgc2VlbSB0byBt
YXR0ZXIuDQpTUkQ+IFJlcXVpcmluZyBhbiBvdmVybG9hZCByZXBvcnQgaW4gZXZlcnkgYW5zd2Vy
IGRvZXMgZGlyZWN0bHkgYnJlYWsgUkVRMTMsIGJ1dCByZXF1aXJpbmcgYW4gb3ZlcmxvYWRlZCBu
b2RlIHRvIGxvb2sgZm9yIGFuIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiBldmVy
eSBtZXNzYWdlIGlzIGFsc28gc3Vic3RhbnRpYWwgYWRkaXRpb25hbCB3b3JrLCBwb3RlbnRpYWxs
eSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGluc2VydGluZyBPTFJzLg0KDQoNCsKgDQrCoA0KRm9yIG15
IGNsYXJpZmljYXRpb246IEkgZ3Vlc3MgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBpcyBub3QgcmVx
dWlyZWQgdG8gcHJvY2VzcyBldmVyeSBzaW5nbGUgT0xSIHJlY2VpdmVkIChtb3N0IHdpbGwgYmUg
cmVwbGF5cyBhbnl3YXkpLiBXaGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUgaW4gdGhlIHJlYWN0
aW5nIG5vZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgcHJvY2Vzc2luZyBvZiByZXBsYXllZCBPTFJz
IGFuZCBhdCB0aGUgc2FtZSB0aW1lIG1pbmltaXplIHRoZSByaXNrIHRvbyBtaXNzIGEgbmV3IE9M
Uj8NClNSRD4gVGhhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQoN
CsKgDQrCoA0KwqANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE5pcmF2IFNhbG90IChu
c2Fsb3QpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDU6MjcgQU0NClRvOiBs
aW9uZWwubW9yYW5kQG9yYW5nZS5jb207IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KwqANCkkgc2hhcmUg
dGhlIHNhbWUgb3BpbmlvbiBhcyBMaW9uZWwuDQrCoA0KUmVnYXJkcywNCk5pcmF2Lg0KwqANCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tDQpTZW50OiBU
dWVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNCA5OjA3IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQrCoA0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlYWwgY29uY2VybiBpcyB3aGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBET0VTIE5PVCBpbnNlcnQgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIuIA0KU28g
dGhlIG9wdGlvbnMgd291bGQgYmU6DQoxLSBPQy1PTFIgQVZQIGluIGV2ZXJ5IGFuc3dlcg0KMi0g
T0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIGV2ZXJ5IHJlcXVlc3QgKyBPQy1PTFIg
QVZQIGluIHNvbWUgYW5zd2VyIHdoZW4gdGhlIGN1cnJlbnQgdGhyb3R0bGluZyBwZXJmb3JtZWQg
YnkgdGhlIGNsaWVudCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KwqANCklmIHRoZXJlIGlzIG5vIG90
aGVyIGNyaXRlcmlvbiwgdGhlIG9wdGlvbiAxIHNlZW1zIHRoZSBiZXN0IGFwcHJvYWNoLg0KwqAN
Ckxpb25lbA0KwqANCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGltZSBpc3N1
ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1lQHRyYWMudG9vbHMuaWV0Zi5vcmddDQpFbnZvecOp
wqA6IG1hcmRpIDQgZsOpdnJpZXIgMjAxNCAwOTo0OQ0Kw4DCoDogTU9SQU5EIExpb25lbCBJTVQv
T0xODQpDY8KgOiBkaW1lQGlldGYub3JnDQpPYmpldMKgOiBbZGltZV0gIzMxOiBTZW5kaW5nIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vy
dml2ZWQgYSB0aHJvdHRsaW5nDQrCoA0KIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGlu
Zy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5n
DQrCoA0KIEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGRlZmluZSBhbiBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgdGhhdCBpc8KgIHRvIGJlIGluY2x1ZGVkIGJ5IHRoZSByZWFjdGluZyBE
T0lDIGVuZHBvaW50IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdMKgIHN1cnZpdmVkIGEgdGhyb3R0
bGluZy4gVGhpcyBBVlAgd291bGQgaW5kaWNhdGUgdGhlIFNlcXVlbmNlLU51bWJlcg0KIChUaW1l
U3RhbXApIG9mIHRoZSBPTFIgYWNjb3JkaW5nIHRvIHdoaWNoIHRoZSB0aHJvdHRsaW5nICh3aGlj
aCB3YXMNCiBzdXJ2aXZlZCkgaXMgcGVyZm9ybWVkLiBBYnNlbmNlIG9mIHRoaXMgQVZQIGluZGlj
YXRlcyB0aGF0IGN1cnJlbnRseSBub8KgIHRocm90dGxpbmcgaXMgcGVyZm9ybWVkLsKgIFJlcG9y
dGluZyBET0lDIGVuZHBvaW50cyBtYXkgdXNlIHRoaXPCoCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0
byBkZXRlY3Qgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gdXBkYXRlIHRoZcKgIHJlYWN0aW5n
IERPSUMgZW5kcG9pbnQgd2l0aCB0aGUgbGF0ZXN0IE9MUi4NCiBBYnNlbmNlIG9mIHRoaXMgZmVl
ZGJhY2sgbWVjaGFuaXNtIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmVlZCBmb3IgdGhlwqAgcmVwb3J0
aW5nIG5vZGUgdG8gc2VuZCBPQy1PTFIgQVZQcyBpbiBldmVyeSBhbnN3ZXIgYXMgdGhlIHJlcG9y
dGluZyBET0lDwqAgZW5kcG9pbnQgY2Fubm90IGtub3cgd2hldGhlciB0aGUgcmVhY3RpbmcgRE9J
QyBlbmRwb2ludCBpcyBhY3R1YWxseSBkb2luZ8KgIHRoZSByaWdodCB0aGluZyB3aXRoIHJlZ2Fy
ZCB0byB0aHJvdHRsaW5nL25vdCB0aHJvdHRsaW5nLg0KIFRoZSBmZWVkYmFjayBtZWNoYW5pc20g
aW1wcm92ZXMgcm9idXN0bmVzcyBhcyBpdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBET0lDwqAgZW5k
cG9pbnQgdG8gZGV0ZWN0IGFuZCBjb3JyZWN0IGluYXBwcm9wcmlhdGUgdGhyb3R0bGluZyBieSB0
aGUgcmVhY3RpbmfCoCBET0lDIGVuZHBvaW50IChjYXVzZWQgYnkgd2hhdGV2ZXIgcmVhc29uKS4N
CiBUaGUgZmVlZGJhY2sgbWVjaGFuaXNtIGFsc28gYWxsb3dzIHRvIGFkZHJlc3MgUkVRIDE4IGZy
b20gUkZDIDcwNjguDQogSW4gc3VtbWFyeSBpdCBpcyBwcm9wb3NlZCB0byBkZWZpbmUgdGhlIE9D
LU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCB0b8KgIGJlIHVzZWQgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZy4NCsKgDQrCoA0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRp
TUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u
dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0
IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz
YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy
LCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z
aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu
dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z
YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g
TWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv
bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl
ZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg
d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp
biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl
IGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp
cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl
ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRp
TUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFp
bGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2RpbWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMg
cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu
dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1
c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog
cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBl
ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt
ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9y
YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0
ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg
YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt
YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRp
c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k
ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWls
cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg
aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p
ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg
ZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg
YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl
dWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1
ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1
c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls
aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj
aS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk
ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5
IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo
b3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy
cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k
IGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v
dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y
IGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll
Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll
bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2Vz
LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj
dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0
ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz
YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5n
ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl
LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp
b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry
aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg
YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBt
YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2
ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly
IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk
b2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh
dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1
aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl
IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz
Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp
dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp
Lg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl
bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg
bGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv
dXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy
b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg
aXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90
IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig
ZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh
Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u
cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg
ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg
dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl
cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu
dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl
cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl
IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug
YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl
ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu
b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0
aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz
IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz
IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91
LgoK


From maria.cruz.bartolome@ericsson.com  Thu Feb 13 08:16:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEC71A0301 for ; Thu, 13 Feb 2014 08:16:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbAoPzXyAjA5 for ; Thu, 13 Feb 2014 08:16:30 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 350581A02BF for ; Thu, 13 Feb 2014 08:16:17 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-08-52fcefd01749
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id DD.37.04853.0DFECF25; Thu, 13 Feb 2014 17:16:16 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 17:16:15 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3xHXAP++EOsg/3wyCwD++FMZMA==
Date: Thu, 13 Feb 2014 16:16:15 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774F35@ESESSMB101.ericsson.se>
References: <16264_1392307475_52FCED13_16264_6720_1_6B7134B31289DC4FAF731D844122B36E4A147C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209774F1F@ESESSMB101.ericsson.se> <10976_1392308023_52FCEF37_10976_8076_1_6B7134B31289DC4FAF731D844122B36E4A14BA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <10976_1392308023_52FCEF37_10976_8076_1_6B7134B31289DC4FAF731D844122B36E4A14BA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje6F93+CDC4vF7eY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGfc3nmUvmMRacX7vXdYGxgbWLkZODgkBE4m1ex+xQdhiEhfu rQeyuTiEBE4wSvSs3cIC4SxhlOg8vAqsik3ATuLS6RdMXYwcHCICyhKnfzmAhIUFyiVeXrrC DGKLCFRIfN56iQmkV0Sgi0niwv+9YAkWAVWJmcvug9m8Ar4SbxsOQG07yiRxcd8tZhCHU6CN UWLKjNfsIFWMQDd9P7WGCcRmFhCXuPVkPhPErQISS/acZ4awRSVePv4H9Y+SxKLbn8GuYxbQ lFi/Sx+iVVFiSvdDdojFghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2RxanFxbrqRgV5u em6JXmpRZnJxcX6eXnHqJkZgdBzc8ttoB+PJPfaHGKU5WJTEea+z1gQJCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYOxYVsbz0azgB5+w5Y81q7d7Fbidtb/UlqeykFX82PMN19J/+Kex7ol2 OFYv+V89uD07fHOHVnDtUZ07FjulCxicxQ+JX+2as07n1/bpUp9mLOneK7kjdm3B1SNrNPYe nnTQVWv72/Dzz/3v/qldas+b6Xo9/u0/zl2bs/bvCPVfU/4qTlTR10yJpTgj0VCLuag4EQCr lpjXXAIAAA==
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2014 16:16:32 -0000

TGlvbmVsLi4uIGhhdmUgeW91IGNhbGxlZCBteSBlbWFpbHMgImhlYXZ5IiEhISB5b3UgZGFyZSEh
IDotKQ0KDQpJIHNpbXBseSByZXBsaWVkLi4uIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIFttYWlsdG86bGlvbmVsLm1vcmFuZEBv
cmFuZ2UuY29tXSANClNlbnQ6IGp1ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDE3OjE0DQpU
bzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRGlt
ZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4g
cmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpCZWNhdXNlIHlv
dXIgZW1haWxzIGFyZSB0b28gaGVhdnkuLi4gYW5kIGJsb2NrZWQgOikgUGxlYXNlIHVzZSB0ZXh0
IGZvcm1hdC4NCg0KTGlvbmVsDQoNCg0K


From nobody Fri Feb 14 00:46:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01161A0151 for ; Fri, 14 Feb 2014 00:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_p3i7niY_tM for ; Fri, 14 Feb 2014 00:46:24 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 323281A0136 for ; Fri, 14 Feb 2014 00:46:24 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1E8kKpP016103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 Feb 2014 02:46:22 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1E8kKpj018584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 09:46:20 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 09:46:20 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE88aqIYhHfy6k2vf6t9AbBIc5quSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8ICAABIAAIAAoHoQ
Date: Fri, 14 Feb 2014 08:46:19 +0000
Message-ID: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>
In-Reply-To: <52FCB76E.6020202@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026686E4FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Czr_GmJ_hOnD7U1PJdKNGEUZ-co
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 08:46:32 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026686E4FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi MCruz, Steve

I here  answer Steve and MCruz mails

About Steve, I have not said the reporting "needs" to send a 0% reduction v=
alid
( it is an implementation choice of the reporting node to choose the % valu=
es it puts in OLR), I simply says  to not forbid it.

In an overload condition, a behavior example is that the reporting , by its=
 own logic (not standardised) , determines the % reduction  value it send i=
n OLRs, and then will observe the effect of this OLR in the evolution of th=
e received  traffic that  the reacting has throttled. Reporting will then d=
ecides to keep, increase or decrease the OLR %value .When we come to the en=
d of overload, the reporting still receiving throttled traffic, will consid=
er that it does  not more need to request a % reduction.

-          One way is to send an OLR with validity period to 0 to indicate =
the end of the overload condition, but it does this without having yet rece=
ived unthrottled  traffic that in some case may nevertheless  request to im=
mediately send again an OLR requesting reduction, meaning that reporting, h=
aving terminated  an overload condition, will  immediately restart another =
one. This a way to proceed as Steve described , I do not say it does not wo=
rk

-          The way I describe is that  reporting  sends a 0% value to see t=
he effect of this new value on the traffic it will receive (that will be un=
throttled), before concluding  to the end of the overload , and if neverthe=
less the received unthrottled  traffic still require to send  OLRs,  report=
ing will not conclude to the end of overload condition  and again generate =
OLRs with a non zero % value.

On the reacting, if it receives a 0% value, it simply does nothing,

I remind  I agree with the proposal  that the end of the Overlaod condition=
 is determined by the Value 0 of the Validity period , or the end of the  e=
xpiry timer, but is not linked to the 0%  traffic reduction

Developers, have various possibilities in the  way   to manage the  overloa=
d condition  and the OLRS they send, I think that DOIC should leave flexibi=
lity.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 13 f=E9vrier 2014 13:16
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

JJ,

Why does the reacting node need to send a reduction percentage of zero to d=
etermine if it is stable?  Can't the reacting node just do its normal check=
ing for overload after sending the validity period of zero?  If it finds th=
e need for reduction of traffic, it can just send a new overload report.

Steve
On 2/13/14 4:43 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi MCruz

AS  Ben proposed, and I agree,   value of zero (0) for the Validity period =
indicates that an existing overload condition has ended and that the report=
ing node is in a stable condition.
An important word is "stable".

When the traffic peak on client side having created the overload decreases,=
   the reporting node progressively diminishes the % traffic reduction in O=
LRs it sends  towards clients taking care to minimize the possible oscillat=
ions. At a certain time ,  server will consider that it can indicate no tra=
ffic reduction to clients. Then is it stable?  there may be different imple=
mentation dependent  ways for the server to decide the situation is stable;=
  one is to send 0% in OLRs and wait a certain number of seconds (not 24 ho=
urs) to check if situation is stable  and then put the validity timer to 0 =
(or leaves the expiry timer  expire). I do not see why to forbid this  way =
to test the stable condition.

So the end of overload condition, as Ben proposed,  can remain ONLY based o=
n Validity  duration value 0 (or timer expiry), not on the value 0 of the %=
 reduction (so a bit different from Nirav statement, but in line with Ulric=
h comment) . The value 0% of the traffic reduction is not forbidden as a po=
ssible  way to check the stability condition .

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56
=C0 : dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hello all,

I think proposal to use just Validity-Duration=3D0 to end overload mainly h=
as the intention to simplify and avoid the checks you just listed below.
If we allow both, it means that the case Ulrich mentioned is valid, and eve=
n with 0% reduction OLR info cannot be deleted until Validity time expires,=
 even we could receive a new OLR in sequence. Even, the reporting needs sti=
ll to keep Validity timer on for this OLR.
I think this does not provide any added value but simply makes things a bit=
 more complex. What could be the reason to keep 0% reduction but a Validity=
 of a few hours (e.g.)?

Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: jueves, 13 de febrero de 2014 10:24
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I am OK with Ulrich

JJacques


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56
=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@=
ietf.org list
Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also agree with the principle.

One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-          0 reduction, non-zero validity period =3D> Valid. The reacting n=
ode can ignore the validity period if reduction is 0.

-          Non-zero reduction, 0 validity period =3D> Valid. The reacting n=
ode can ignore the reduction if validity period is 0.

-          0 reduction, 0 validity period =3D> Valid as well. Generally, th=
is is what the reporting node will use to indicate the end of overload cond=
ition.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



_______________________________________________
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


--_000_E194C2E18676714DACA9C3A2516265D2026686E4FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi MCruz, Steve


 <=
/p>

I here  answer Steve=
 and MCruz mails


 <=
/p>

About Steve, I have not s=
aid the reporting “needs” to send a 0% reduction valid


( it is an implementation=
 choice of the reporting node to choose the % values it puts in OLR), I sim=
ply says  to not forbid it.


 <=
/p>

In an overload condition,=
 a behavior example is that the reporting , by its own logic (not standardi=
sed) , determines the % reduction  value it send in OLRs,
 and then will observe the effect of this OLR in the evolution of the recei=
ved  traffic that  the reacting has throttled. Reporting will the=
n decides to keep, increase or decrease the OLR %value .When we come to the=
 end of overload, the reporting still receiving
 throttled traffic, will consider that it does  not more need to reque=
st a % reduction.


- =
;        
One way is to sen=
d an OLR with validity period to 0 to indicate the end of the overload cond=
ition, but it does this without having yet received unthrottled
  traffic that in some case may nevertheless  request to immediat=
ely send again an OLR requesting reduction, meaning that reporting, having =
terminated  an overload condition, will  immediately restart anot=
her one. This a way to proceed as Steve described ,
 I do not say it does not work


- =
;        
The way I describ=
e is that  reporting  sends a 0% value to see the effect of this =
new value on the traffic it will receive (that will be unthrottled),
 before concluding  to the end of the overload , and if nevertheless t=
he received unthrottled  traffic still require to send  OLRs, &nb=
sp;reporting will not conclude to the end of overload condition  and a=
gain generate OLRs with a non zero % value.



 <=
/p>

On the reacting, if it re=
ceives a 0% value, it simply does nothing,



 <=
/p>

I remind  I agree wi=
th the proposal  that the end of the Overlaod condition is determined =
by the Value 0 of the Validity period , or the end of the  expiry
 timer, but is not linked to the 0%  traffic reduction  


 <=
/p>

Developers, have various =
possibilities in the  way   to manage the  overload con=
dition  and the OLRS they send, I think that DOIC should leave flexibi=
lity.


 <=
/p>

Best regards


 <=
/p>

JJacques  


    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;  


 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : jeudi 13 f=E9vrier 2014 13:16

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


JJ,



Why does the reacting node need to send a reduction percentage of zero to d=
etermine if it is stable?  Can't the reacting node just do its normal =
checking for overload after sending the validity period of zero?  If i=
t finds the need for reduction of traffic,
 it can just send a new overload report.



Steve




On 2/13/14 4:43 AM, TROTTIN, JEAN-=
JACQUES (JEAN-JACQUES) wrote:






Hi MCruz


 =



AS  Ben proposed, an=
d I agree,   value of zero (0) for the Validity period indicates =
that an existing overload condition has ended and that the reporting node
 is in a stable condition.


An important word is R=
20;stable”.


 <=
/p>

When the traffic peak on =
client side having created the overload decreases,   the reportin=
g node progressively diminishes the % traffic reduction in OLRs it
 sends  towards clients taking care to minimize the possible oscillati=
ons. At a certain time ,  server will consider that it can indicate no=
 traffic reduction to clients. Then is it stable?  there may be differ=
ent implementation dependent  ways for the server
 to decide the situation is stable;  one is to send 0% in OLRs and wai=
t a certain number of seconds (not 24 hours) to check if situation is stabl=
e  and then put the validity timer to 0 (or leaves the expiry timer &n=
bsp;expire). I do not see why to forbid this  way
 to test the stable condition.


 <=
/p>

So the end of overload co=
ndition, as Ben proposed,  can remain ONLY based on Validity  dur=
ation value 0 (or timer expiry), not on the value 0 of the % reduction
 (so a bit different from Nirav statement, but in line with Ulrich comment)=
 . The value 0% of the traffic reduction is not forbidden as a possible &nb=
sp;way to check the stability condition .


 <=
/p>

Best regards



 =



JJacques


 =



 =







De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56

=C0 : dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Hello all,


 <=
/p>

I think proposal to use j=
ust Validity-Duration=3D0 to end overload mainly has the intention to simpl=
ify and avoid the checks you just listed below.


If we allow both, it mean=
s that the case Ulrich mentioned is valid, and even with 0% reduction OLR i=
nfo cannot be deleted until Validity time expires, even
 we could receive a new OLR in sequence. Even, the reporting needs still to=
 keep Validity timer on for this OLR.


I think this does not pro=
vide any added value but simply makes things a bit more complex. What could=
 be the reason to keep 0% reduction but a Validity of a
 few hours (e.g.)?


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: jueves, 13 de febrero de 2014 10:24

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I am OK with Ulrich


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56

=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES); 
dime@ietf.org list

Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


I also agree with the pri=
nciple.


 <=
/p>

One minor clarification:<=
/span>


0%-reduction with non-zer=
o validity period is valid but validity period cannot be ignored: as long a=
s not expired the sequence number needs to be stored for
 future checking; once expired, sequence number must not be used for future=
 checking.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Nirav Salot (nsalot)

Sent: Thursday, February 13, 2014 4:11 AM

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I also tend to agree with=
 JJ below.


Unless there is a strong =
reason, no point in forbidding the use of 0% reduction – which can al=
so indicate end of overload condition.


 <=
/p>

May be we can clarify tha=
t 0% reduction and/or 0 validity period indicates end of overload. In my vi=
ew, both are valid for the use, individually and together.
 So,


-      =
   
0 reduction, non-=
zero validity period =3D> Valid. The reacting node can ignore the validi=
ty period if reduction is 0.


-      =
   
Non-zero reductio=
n, 0 validity period =3D> Valid. The reacting node can ignore the reduct=
ion if validity period is 0.


-      =
   
0 reduction, 0 va=
lidity period =3D> Valid as well. Generally, this is what the reporting =
node will use to indicate the end of overload condition.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)=



 <=
/p>

Best regards<=
/span>


 =



JJacques



 =



 =







De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
o:p>


 <=
/p>

The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.

 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 <=
/p>

This comment affects as w=
ell clause 5.5.2:


 <=
/p>

  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:




On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_E194C2E18676714DACA9C3A2516265D2026686E4FR712WXCHMBA12z_--


From nobody Fri Feb 14 01:06:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD521A01E4 for ; Fri, 14 Feb 2014 01:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5MN1EHjStc3 for ; Fri, 14 Feb 2014 01:05:46 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1E1A0123 for ; Fri, 14 Feb 2014 01:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36184; q=dns/txt; s=iport; t=1392368745; x=1393578345; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EZMidQCHeFrGYXCJavry2fYEbhB+e2Sk9WlV6AyxiXs=; b=il7lbUmQONUGHuTul5ozSMnBwEoMolzcPw54dbTfWBevsfWssxSn0NRE ESTb+jJvsyARCIBr4kjkkZoi9XNlxGcxw453uz6lGd83PMi3LfdGf06cy bPko6JHxqH/2jT1rFQluD3dN4XTbck5FwdxK5QQqO2YWlW336kdZu+ElE 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmUFAAzb/VKtJV2c/2dsb2JhbABZgkJEOFeDArwwGH4WdIIlAQEBBCMKXAIBCBEEAQELCwsBAgQDAgICMBQJCAIEARIIh32meaF+F45INwEGBIJlNYEUBJRDjkaHRoFvgT6CKg
X-IronPort-AV: E=Sophos;i="4.95,843,1384300800";  d="scan'208,217";a="304064893"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 14 Feb 2014 09:05:44 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1E95imD015164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 09:05:44 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.86]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 03:05:44 -0600
From: "Nirav Salot (nsalot)" 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3y9MUP++Q/+g/3wfuAD+93c9sA==
Date: Fri, 14 Feb 2014 09:05:43 +0000
Message-ID: 
References:  <087A34937E64E74E848732CFF8354B9209774E01@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209774E01@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.45.37]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6DC0Cxmbrcdx10ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aAW8ZsNnExunjfFBspNw9G1I3cA
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 09:05:53 -0000

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

TWFyaWEtQ3J1eiwNCg0KSSBhbSBmaW5lIHdpdGggdGhlIHByb3Bvc2FsIGJlbG93Lg0KDQpSZWdh
cmRzLA0KTmlyYXYuDQoNCkZyb206IE1hcmlhIENydXogQmFydG9sb21lIFttYWlsdG86bWFyaWEu
Y3J1ei5iYXJ0b2xvbWVAZXJpY3Nzb24uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEz
LCAyMDE0IDg6MzggUE0NClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZw0K
U3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0
bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRs
aW5nDQoNCk5pcmF2LA0KDQpMZXQgbWUga25vdyBpZiBmb2xsb3dpbmcgcmVwaHJhc2luZyBzdGls
bCBjb252ZXlzIHRoZSBtZWFuaW5nIHlvdSB3YW50IHRvIGNvdmVyOg0KDQpOb3RlIOKAkyBJbiBz
b21lIGNhc2VzIChlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4g
dGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzLCBvciB3aGVuIG92
ZXJsb2FkIHJlcG9ydHMgYXJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2RlcykgdGhlIHJlcG9y
dGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcg
bm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9ydC4NCg0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNh
bG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5jb21dDQpTZW50OiBqdWV2ZXMsIDEzIGRlIGZlYnJl
cm8gZGUgMjAxNCAxNTo1Ng0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3Jn
PG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBT
ZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2Vz
IHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk1hcmlhLUNydXosDQoNCk1heSBiZSBmb2xs
b3dpbmcgZm9ybWF0dGluZyBvZiB0aGUgbm90ZSBoZWxwcz8NCkEgcmVwb3J0aW5nIG5vZGUgTUFZ
IGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2Rl
IGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGlzIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5
IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KTm90ZSDigJMgSW4gc29tZSBjYXNlcyAo
ZS5nLiB3aGVuIHRoZXJlIGFyZSBvbmUgb3IgbXVsdGlwbGUgYWdlbnRzIGluIHRoZSBwYXRoIGJl
dHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlcywgb3ZlcmxvYWQgcmVwb3J0cyBtYXkg
YmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5v
dCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZl
ZCB0aGUgcmVwb3J0Lg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0K
U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDY6NTAgUE0NClRvOiBkaW1lQGlldGYu
b3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LA0KDQpEbyB5b3UgY29uc2lk
ZXIgdGhhdCBvdmVybG9hZCByZXBvcnRzIGNhbiBvbmx5IGJlIGRpc2NhcmRlZCBieSByZWFjdGlu
ZyBub2RlcyB3aGVuIHRoZXJlIGFyZSBhZ2VudHMgaW4gdGhlIHBhdGg/DQoNCg0KRnJvbTogTmly
YXYgU2Fsb3QgKG5zYWxvdCkgW21haWx0bzpuc2Fsb3RAY2lzY28uY29tXQ0KU2VudDoganVldmVz
LCAxMyBkZSBmZWJyZXJvIGRlIDIwMTQgMTM6NTgNClRvOiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsg
ZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRGltZV0g
W2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVx
dWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpNYXJpYS1DcnV6LA0K
DQpSZXBvcnRpbmcgbm90ZSBtYXkgdXNlIHZlcnkgc2ltcGxlIG1lY2hhbmlzbSDigJMgYXMgcG9p
bnRlZCBvdXQgYnkgTGlvbmVsIOKAkyB0byBjb25jbHVkZSB0aGF0IHJlcG9ydCBoYXMgcmVhY2hl
ZCB0aGUgcmVhY3Rpbmcgbm9kZSwgaS5lLiBhbGwgdGhlIGludHJhLXNlc3Npb24gbWVzc2FnZXMg
bmVlZCBub3QgY29udGFpbiB0aGUgc2FtZSBvdmVybG9hZCByZXBvcnQsIGlmIHRoZSBzZXNzaW9u
IGVzdGFibGlzaG1lbnQgbWVzc2FnZSBjb250YWlucyB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0KDQpT
byB5b3VyIG5vdGUgcmVnYXJkaW5nIHRoZSByZXBvcnRpbmcgbm9kZSB0byB0YWtlIGludG8gYWNj
b3VudCB0aGUgbmV0d29yayBkZXBsb3ltZW50IGV0Yy4gaXMgbm90IDEwMCUgY29ycmVjdC4NCkxl
dCBtZSBzaW1wbGlmeSwgaG9waW5nIGl0IHdpbGwgc2F0aXNmeSB5b3VyIGNvbmNlcm4uDQoNCkEg
cmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQg
dG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGlzIG92ZXJsb2Fk
IHJlcG9ydCBpcyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0KTm90ZSDi
gJMgSW4gc29tZSBjYXNlcywgZS5nLiB3aGVuIHRoZXJlIGFyZSBvbmUgb3IgbXVsdGlwbGUgYWdl
bnRzIGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlczsgb3Zl
cmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzLCB0aGUgcmVw
b3J0aW5nIG5vZGUgbWF5IG5vdCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGlu
ZyBub2RlIGhhcyByZWNlaXZlZCB0aGUgcmVwb3J0Lg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZy
b206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJp
YSBDcnV6IEJhcnRvbG9tZQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDI6MzEg
UE0NClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6
IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFW
UCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCkRlYXIg
YWxsLA0KDQpJIHRoaW5rIHRoZW4gd2UgYWdyZWUgb24gdGhlIHByb3Bvc2VkIHRleHQ6DQoNCkEg
cmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVjZWl2
ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhIHJlcG9y
dGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2Vz
IHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5
IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50
IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiAgVGhlIG92
ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhh
dCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0
byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNh
biBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZlZCB0
aGUgb3ZlcmxvYWQgcmVwb3J0Lg0KDQpCdXQgc3RpbGwgdGhlcmUgYXJlIHNvbWUgZGlzY3JlcGFu
Y2llcyBhYm91dCB0aGUgbm90ZS4NCk15IHByb3Bvc2FsIGlzIHRvIGtlZXAgaXQganVzdCBhcyBh
biBpbmRpY2F0aW9uIG9mIHBvdGVudGlhbCAobWF5YmUgbm90IGFsbCkgc2l0dWF0aW9ucyB0aGF0
IHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgaWYgZXZlciBhbnkgaW1wbGVtZW50YXRpb24g
bWF5IGNvbnNpZGVyIHRvIGRvIG5vdCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIHRoYXQgYSBy
ZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBtZXNz
YWdlcy4NCkJlaW5nIGEgcmVjb21tZW5kYXRpb24gYW5kIG5vdCBhIG11c3QsIGF0IGxlYXN0IEkg
dGhpbmsgd2UgbmVlZCB0byBpbmRpY2F0ZSB3aGF0IG1heSBpbXBseSB0byBkbyBub3QgZm9sbG93
IHRoZSByZWNvbW1lbmRhdGlvbi4NClRoZW4gbXkgcHJvcG9zYWwgaXMgdGhlIGZvbGxvd2luZywg
dGhhdCBpbmNsdWRlcyBhIG1vZGlmaWNhdGlvbiB0byBsYXN0IHNlbnRlbmNlIGFib3ZlOg0KDQpB
IHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0
IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhpcyBvdmVybG9h
ZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGUuDQoNCk5vdGUg
4oCTdGhlIHJlcG9ydGluZyBub2RlIG1heSBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50IG5ldHdv
cmsgZGVwbG95bWVudCBhbmQgcG90ZW50aWFsIGVycm9ycyBpbiBvcmRlciB0byBiZSBhYmxlIHRv
IGd1YXJhbnRlZSB0aGF0IHNlbnQgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSBpbiB0aGUgcmVh
Y3Rpbmcgbm9kZSwgZS5nLiB0aGVyZSBtYXkgYmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0
aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJl
cG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlc+KApg0KDQoNCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6
MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl
dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0K
CXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZh
bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLlByZm9ybWF0SFRNTCwgbGkuUHJmb3Jt
YXRIVE1MLCBkaXYuUHJmb3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg
SFRNTCI7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
VGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs
ZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9
DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJ
e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0
ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpz
cGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N
CnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls
U3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzQNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM1DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s
b3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUzNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMzcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h
aWxTdHlsZTM4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5bGUzOQ0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlNDANCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
IjsNCgljb2xvcjojMjQ0MDYxO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+TWFyaWEtQ3J1eiw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
NDQwNjEiPkkgYW0gZmluZSB3aXRoIHRoZSBwcm9wb3NhbCBiZWxvdy48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPlJlZ2Fy
ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk5pcmF2LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMjQ0MDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBNYXJpYSBDcnV6IEJhcnRvbG9t
ZSBbbWFpbHRvOm1hcmlhLmNydXouYmFydG9sb21lQGVyaWNzc29uLmNvbV0NCjxicj4NCjxiPlNl
bnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgODozOCBQTTxicj4NCjxiPlRvOjwv
Yj4gTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUkU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5pcmF2LDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGV0IG1lIGtu
b3cgaWYgZm9sbG93aW5nIHJlcGhyYXNpbmcgc3RpbGwgY29udmV5cyB0aGUgbWVhbmluZyB5b3Ug
d2FudCB0byBjb3Zlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ob3RlIOKAkyBJbiBz
b21lIGNhc2VzIChlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4g
dGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzLA0KPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90
Oztjb2xvcjpyZWQiPm9yIHdoZW4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+b3ZlcmxvYWQgcmVwb3J0cw0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZx
dW90Oztjb2xvcjpyZWQiPmFyZSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5kaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9k
ZXMpIHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBvcnQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOndpbmRvd3RleHQiPiBOaXJhdiBTYWxvdCAobnNhbG90KSBbPGEgaHJlZj0ibWFpbHRv
Om5zYWxvdEBjaXNjby5jb20iPm1haWx0bzpuc2Fsb3RAY2lzY28uY29tPC9hPl0NCjxicj4NCjxi
PlNlbnQ6PC9iPiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAxNCAxNTo1Njxicj4NCjxiPlRv
OjwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3Jn
Ij5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzI0NDA2MSI+TWFyaWEtQ3J1eiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPk1heSBiZSBmb2xsb3dpbmcgZm9ybWF0
dGluZyBvZiB0aGUgbm90ZSBoZWxwcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1
b3Q7c2VyaWYmcXVvdDsiPkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBh
biBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUg
dGhhdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90Oywm
cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPnRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFscmVh
ZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KTm90ZSDigJMgSW4gc29t
ZSBjYXNlcyAoZS5nLiB3aGVuIHRoZXJlIGFyZSBvbmUgb3IgbXVsdGlwbGUgYWdlbnRzIGluIHRo
ZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlcywgb3ZlcmxvYWQgcmVw
b3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzKSB0aGUgcmVwb3J0aW5nIG5v
ZGUgbWF5IG5vdCBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhh
cyByZWNlaXZlZCB0aGUgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzI0NDA2MSI+TmlyYXYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6d2luZG93dGV4dCI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0
Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m
IDwvYj5NYXJpYSBDcnV6IEJhcnRvbG9tZTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVi
cnVhcnkgMTMsIDIwMTQgNjo1MCBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRp
bWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
RGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAg
aW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaXJhdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvIHlvdSBjb25zaWRlciB0
aGF0IG92ZXJsb2FkIHJlcG9ydHMgY2FuIG9ubHkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5v
ZGVzIHdoZW4gdGhlcmUgYXJlIGFnZW50cyBpbiB0aGUgcGF0aD88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3
aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+IE5pcmF2IFNhbG90IChuc2Fsb3QpIFs8YSBocmVmPSJtYWlsdG86bnNh
bG90QGNpc2NvLmNvbSI+bWFpbHRvOm5zYWxvdEBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu
dDo8L2I+IGp1ZXZlcywgMTMgZGUgZmVicmVybyBkZSAyMDE0IDEzOjU4PGJyPg0KPGI+VG86PC9i
PiBNYXJpYSBDcnV6IEJhcnRvbG9tZTsgPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRp
bWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRGltZV0gW2RpbWVdICMz
MTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNz
YWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MjQ0MDYxIj5NYXJpYS1DcnV6LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+UmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5
IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFzIHBvaW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8gY29u
Y2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJlYWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4gYWxs
IHRoZSBpbnRyYS1zZXNzaW9uDQogbWVzc2FnZXMgbmVlZCBub3QgY29udGFpbiB0aGUgc2FtZSBv
dmVybG9hZCByZXBvcnQsIGlmIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgbWVzc2FnZSBjb250
YWlucyB0aGUgb3ZlcmxvYWQgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI0NDA2MSI+U28geW91ciBub3RlIHJlZ2FyZGlu
ZyB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIG5ldHdvcmsgZGVw
bG95bWVudCBldGMuIGlzIG5vdCAxMDAlIGNvcnJlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
NDQwNjEiPkxldCBtZSBzaW1wbGlmeSwgaG9waW5nIGl0IHdpbGwgc2F0aXNmeSB5b3VyIGNvbmNl
cm4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSByZXBvcnRpbmcgbm9kZSBNQVkgY2hv
b3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0aW5nIG5vZGUgaWYg
aXQgY2FuIGd1YXJhbnRlZSB0aGF0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+dGhpcyBvdmVybG9h
ZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5vZGU8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7
Ij4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+
DQpOb3RlIOKAkyBJbiBzb21lIGNhc2VzLCBlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBtdWx0
aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5v
ZGVzOyBvdmVybG9hZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMs
IHRoZSByZXBvcnRpbmcgbm9kZSBtYXkgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQgdGhl
IHJlYWN0aW5nIG5vZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBvcnQuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMyNDQwNjEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5SZWdhcmRz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjQ0MDYxIj5OaXJhdi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzI0NDA2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gRGlNRSBbPGEgaHJlZj0ibWFpbHRv
OmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5d
DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmlhIENydXogQmFydG9sb21lPGJyPg0KPGI+U2VudDo8
L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAyOjMxIFBNPGJyPg0KPGI+VG86PC9iPiA8
YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhy
b3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJv
dHRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSB0aGluayB0aGVuIHdlIGFncmVlIG9uIHRoZSBwcm9wb3NlZCB0ZXh0OjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZS
IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi
PkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMgcmVj
ZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy48YnI+DQo8YnI+DQpJdCBpcyByZWNvbW1lbmRlZCB0
aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3
ZXIgbWVzc2FnZXMgc2VudCB0byByZWFjdGluZyBub2Rlcy4mbmJzcDsNCjxicj4NCjxicj4NCk5v
dGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVw
b3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0
IGlzIG1vcmUgZWZmaWNpZW50LiZuYnNwOyBUaGUgb3ZlcmxvYWQgcmVwb3J0IHdpbGwganVzdCBi
ZSBpZ25vcmVkIGJ5IGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9JQy48
YnI+DQo8YnI+DQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3Zl
cmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQg
dGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMgcmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9y
dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1
b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHN0aWxsIHRoZXJl
IGFyZSBzb21lIGRpc2NyZXBhbmNpZXMgYWJvdXQgdGhlIG5vdGUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPk15IHByb3Bvc2FsIGlzIHRvIGtlZXAgaXQganVzdCBhcyBhbiBpbmRpY2F0
aW9uIG9mIHBvdGVudGlhbCAobWF5YmUgbm90IGFsbCkgc2l0dWF0aW9ucyB0aGF0IHNob3VsZCBi
ZSB0YWtlbiBpbnRvIGFjY291bnQgaWYgZXZlciBhbnkgaW1wbGVtZW50YXRpb24gbWF5IGNvbnNp
ZGVyDQogdG8gZG8gbm90IGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24gdGhhdCBhIHJlcG9ydGlu
ZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzLg0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlaW5nIGEgcmVjb21tZW5kYXRpb24gYW5k
IG5vdCBhIG11c3QsIGF0IGxlYXN0IEkgdGhpbmsgd2UgbmVlZCB0byBpbmRpY2F0ZSB3aGF0IG1h
eSBpbXBseSB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbi4NCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5UaGVuIG15IHByb3Bvc2FsIGlzIHRoZSBmb2xsb3dpbmcsIHRo
YXQgaW5jbHVkZXMgYSBtb2RpZmljYXRpb24gdG8gbGFzdCBzZW50ZW5jZSBhYm92ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90
IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3Vh
cmFudGVlIHRoYXQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMm
cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj50aGlzIG92ZXJsb2FkIHJlcG9ydCBp
cyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZTwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCk5vdGUg4oCT
dGhlIHJlcG9ydGluZyBub2RlIG1heSBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50IG5ldHdvcmsg
ZGVwbG95bWVudCBhbmQgcG90ZW50aWFsIGVycm9ycyBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGd1
YXJhbnRlZSB0aGF0IHNlbnQgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSBpbiB0aGUgcmVhY3Rp
bmcgbm9kZSwgZS5nLiB0aGVyZSBtYXkgYmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUg
cGF0aCBiZXR3ZWVuIHJlcG9ydGluZw0KIGFuZCByZWFjdGluZyBub2Rlczsgb3ZlcmxvYWQgcmVw
b3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVz4oCmPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_A9CA33BB78081F478946E4F34BF9AAA014D6DC0Cxmbrcdx10ciscoc_--


From nobody Fri Feb 14 01:09:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE87A1A01B3; Fri, 14 Feb 2014 01:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9THqM4nzcoF; Fri, 14 Feb 2014 01:09:00 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 847311A0115; Fri, 14 Feb 2014 01:08:59 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D40DA10580; Fri, 14 Feb 2014 10:08:57 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id C1A231057E; Fri, 14 Feb 2014 10:08:57 +0100 (CET)
Message-ID: <52FDDD10.1050306@restena.lu>
Date: Fri, 14 Feb 2014 10:08:32 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "radext@ietf.org" 
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com>
In-Reply-To: <20140214084329.10393.78739.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
X-Forwarded-Message-Id: <20140214084329.10393.78739.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P"
X-Virus-Scanned: ClamAV
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bj3JoMnR572QdS_7uHPiDAub2gY
Cc: abfab@ietf.org, "dime@ietf.org" , "" 
Subject: [Dime] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 09:09:03 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P
Content-Type: multipart/mixed;
 boundary="------------010603070305000203040701"

This is a multi-part message in MIME format.
--------------010603070305000203040701
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

I've just submitted an -00 on a topic that we've been struggling with in
ABFAB recently (but which exists in every EAP-over-AAA scenario, not
limited to ABFAB).

http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapide=
ntity-00.txt

Abstract:
   There are some subtle considerations for an EAP peer regarding the
   content of the EAP-Response/Identity packet when authenticating with
   EAP to an EAP server.  This document describes two such
   considerations and suggests workarounds to the associated problems.

The issue touches multiple areas and working groups (EAP, EAP methods,
RADIUS, Diameter) so I had to do a guesstimate for a proper home. I
would think radext is the best match, cc'ing abfab and dime, and also
emu even though it's shutting down).

If you recall those in-depth discussions about fixing either EAP methods
to use UTF-8, or why EAP Identity would need to be restrained to UTF-8
even if a method doesn't do it, then yes: the draft is about that.

In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057:
"Circumstances might require that applications need to perform
conversion of identities from an application specific character set to
UTF-8 or another character set required by a particular EAP method."

Which was enough to get the document through IESG, but this should
better be fixed more generally for every EAP use case; hence this new dra=
ft.

It's short and concise - I'd appreciate if you could give it a read and
comment.

If there's still free time on the agenda, I would also merrily discuss
it in London.

Greetings,

Stefan Winter

P.S.: Don't miss my other submission about an EAP Configuration File
Format, which I've been told to submit to ops-area/opsawg:

http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/

Annoucement here:
http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html

-------- Original Message --------
Subject: New Version Notification for
draft-winter-radext-populating-eapidentity-00.txt
Date: Fri, 14 Feb 2014 00:43:29 -0800
From: internet-drafts@ietf.org
To: Stefan Winter , "Stefan Winter"



A new version of I-D, draft-winter-radext-populating-eapidentity-00.txt
has been successfully submitted by Stefan Winter and posted to the
IETF repository.

Name:		draft-winter-radext-populating-eapidentity
Revision:	00
Title:		Considerations regarding the correct use of EAP-Response/Identity=

Document date:	2014-02-14
Group:		Individual Submission
Pages:		6
URL:
http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapide=
ntity-00.txt
Status:
https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidenti=
ty/
Htmlized:
http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00


Abstract:
   There are some subtle considerations for an EAP peer regarding the
   content of the EAP-Response/Identity packet when authenticating with
   EAP to an EAP server.  This document describes two such
   considerations and suggests workarounds to the associated problems.





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

The IETF Secretariat




--------------010603070305000203040701
Content-Type: application/pgp-keys;
 name="0x8A39DC66.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x8A39DC66.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)

mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je
miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb
Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr
b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj
l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB
e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/
3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg
BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a
smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl
97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C
BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB
tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50
ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo
R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0
qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++
/qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt
y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5
9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22
lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2
CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa
9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY
n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT
aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl
8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o
vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp
n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe
qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK
BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj
8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj
mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC
iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU
dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+
2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr
NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/
PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR
4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU
TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu
DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN
jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK
UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv
/o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp
jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv
JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf
C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+
od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi
u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+
km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m
5zP5og=3D=3D
=3D3NUt
-----END PGP PUBLIC KEY BLOCK-----

--------------010603070305000203040701--

--kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS/d0RAAoJEMDeajWKOdxmUIoP/2H8SlgdcBJ5j3fRtpG9xaFY
FgWs/hdm2cHVRySVM7MvGyvs+/RU1qbNVDodzQcmDrXW1IWT1oPqt0/YGK9PCNIf
X8w3qiHwJt7A79+LlMwb1I6bmVzUxpAJuL+Ya+E4Z9/WF4c5RMkbmMGR3z6xwO2P
ou+o4/R6IqZGkz5l8ZSqpBW25NqxxBFyI4phMKH/Ap/9XDM4QzOlf7J2AP3uoLk2
Jywo7IrM+THqvZzDcU5lwXlL3YwGVQ/lFgkZnyHSHlmUDSc0v45OShnDZF3Y+YRt
7rmloG4NopJWB8fA/rFVrFa9kyDEP2nTVxMrlf5SBHg0oKpXUzqE/Bis+XmiW+3D
yxsUz2vc6CI1CUSf6qQLnc8Mt7ntTKV5kwuTeJW3l4zfMrEhqvad2g7UIc3uWqhh
Ei8F03ZShOX33Og7EX8aPVGO7x5/VNr4SJC53rn1nP2GPogFTX3Yv0LXe/R0JR/Z
YBtfwAmJk1kvcVi1yNz/Bknfa+8rOV4ow16NR5fSeO2UWcX3I9ocJDuTevRbmBNQ
GXovUncKbKjdQ5Fwkj4JD+2QQ26njrM3knSp39v6ij2fIZa2bK+NltN6GvFO1i0H
/80Hy0fSvD/DtTfsgEIzzouL4/sJPWuktNxb/amnJzA626KH+5HCeJ/bH5o3gVSg
qhVa1A5pJ50NqEJ8pBEz
=6yo0
-----END PGP SIGNATURE-----

--kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P--


From nobody Fri Feb 14 01:23:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C44D1A00C0 for ; Fri, 14 Feb 2014 01:23:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjRsxMnoSLgz for ; Fri, 14 Feb 2014 01:23:00 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B51A61A00BA for ; Fri, 14 Feb 2014 01:22:59 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 10BAC3B4200; Fri, 14 Feb 2014 10:22:58 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E915C27C06F; Fri, 14 Feb 2014 10:22:57 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 10:22:57 +0100
From: 
To: "Nirav Salot (nsalot)" , Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3y9MUP++Q/+g/3wfuAD+93c9sP3u7OdQ
Date: Fri, 14 Feb 2014 09:22:57 +0000
Message-ID: <30818_1392369778_52FDE071_30818_9638_1_6B7134B31289DC4FAF731D844122B36E4A309D@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References:  <087A34937E64E74E848732CFF8354B9209774E01@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.80914
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gZY2-pbiZjEqFBrmrxRIK4k9pqg
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 09:23:06 -0000

SGkgYWxsLA0KDQpJIGRvbid0IHRoaW5rIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBtYXkvY2FuL3dv
dWxkIGxpa2UgdG8gZW5zdXJlL2Nob29zZS9ndWFyYW50ZWUgYW55dGhpbmcgOikNCkknbSBvayB3
aXRoIHRoZSBpbnRlbnRpb24gb2YgdGhlIHRleHQgYnV0IHdlIG1heSBwcm9iYWJseSB3b3JkIGl0
IGluIGEgZGlmZmVyZW50IHdheS4NCg0KTW9yZW92ZXIsIHRoZSBmaXJzdCBzZW50ZW5jZSBpcyBz
b21laG93IGluY29ycmVjdC4gTm90IGFsbCB0aGUgcmVhY3Rpbmcgbm9kZXMgbmVlZCB0byBiZSBh
d2FyZSBvZiB0aGUgbmV3IHN0YXR1cy4gT25seSB0aG9zZSB3aGljaCBoYXZlIHJlY2VpdmVkIGEg
cHJldmlvdXMgT0xSIGFyZSB0YXJnZXRlZC4gSSB0aGluayB0aGF0IHRoZSByZXF1aXJlbWVudCBp
cyB0aGF0IHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXMgc2hhcmUgdGhlIG1vc3QgdXAtdG8t
ZGF0ZSBpbmZvIGFuZCB0aGVyZWZvcmUgaXQgaXMgcmVjb21tZW5kZWQgdG8gc2VuZCB0aGUgT0xS
IGluIGV2ZXJ5IGFuc3dlci4NCg0KSSBoYXZlIGEgY29tbWVudCBhbnl3YXkgb24gdGhlIGZvbGxv
d2luZyBub3RlOg0KDQpOb3RlIC0gdGhlIHJlcG9ydGluZyBub2RlIG1heSBhbHNvIGluY2x1ZGUg
dGhlIG92ZXJsb2FkIHJlcG9ydCBpbiBhbnN3ZXIgbWVzc2FnZXMgc2VudCB0byBub24gcmVhY3Rp
bmcgbm9kZXMgaWYgdGhhdCBpcyBtb3JlIGVmZmljaWVudC4gIFRoZSBvdmVybG9hZCByZXBvcnQg
d2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRlciBub2RlIHRoYXQgZG9lcyBub3Qgc3Vw
cG9ydCBET0lDLg0KDQpUaGlzIGlzIGNvbnRyYWRpY3RpbmcgdGhlIHN0YXRlbWVudCBnaXZlbiBp
biA1LjMuMjoNCg0KICAgVGhlIGFuc3dlciBtZXNzYWdlIGluaXRpYXRpbmcgZW5kcG9pbnQgTVVT
VCBOT1QgaW5jbHVkZSBhbnkgb3ZlcmxvYWQNCiAgIGNvbnRyb2wgc29sdXRpb24gZGVmaW5lZCBB
VlBzIGludG8gaXRzIGFuc3dlciBtZXNzYWdlcyBpZiB0aGUgcmVxdWVzdA0KICAgbWVzc2FnZSBp
bml0aWF0aW5nIGVuZHBvaW50IGhhcyBub3QgaW5kaWNhdGVkIHN1cHBvcnQgYXQgdGhlDQogICBi
ZWdpbm5pbmcgb2YgdGhlIGNyZWF0ZWQgc2Vzc2lvbiAob3IgdHJhbnNhY3Rpb24gaW4gYSBjYXNl
IG9mIG5vbi0NCiAgIHNlc3Npb24gc3RhdGUgbWFpbnRhaW5pbmcgYXBwbGljYXRpb25zKS4gIFRo
ZSBzYW1lIGFsc28gYXBwbGllcyBpZg0KICAgbm9uZSBvZiB0aGUgYW5ub3VuY2VkIGNhcGFiaWxp
dGllcyBtYXRjaCBiZXR3ZWVuIHRoZSB0d28gZW5kcG9pbnRzLg0KDQpSZWdhcmRzLA0KDQpMaW9u
ZWwNCg0KKioqKioqKioqKioqKioqKioqKioqKioNCg0KRGXCoDogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBOaXJhdiBTYWxvdCAobnNhbG90KQ0KRW52
b3nDqcKgOiB2ZW5kcmVkaSAxNCBmw6l2cmllciAyMDE0IDEwOjA2DQrDgMKgOiBNYXJpYSBDcnV6
IEJhcnRvbG9tZTsgZGltZUBpZXRmLm9yZw0KT2JqZXTCoDogUmU6IFtEaW1lXSBbZGltZV0gIzMx
OiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1lc3Nh
Z2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk1hcmlhLUNydXosDQoNCkkgYW0gZmlu
ZSB3aXRoIHRoZSBwcm9wb3NhbCBiZWxvdy4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBN
YXJpYSBDcnV6IEJhcnRvbG9tZSBbbWFpbHRvOm1hcmlhLmNydXouYmFydG9sb21lQGVyaWNzc29u
LmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgODozOCBQTQ0KVG86IE5p
cmF2IFNhbG90IChuc2Fsb3QpOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtk
aW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVl
c3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTmlyYXYsDQoNCkxldCBt
ZSBrbm93IGlmIGZvbGxvd2luZyByZXBocmFzaW5nIHN0aWxsIGNvbnZleXMgdGhlIG1lYW5pbmcg
eW91IHdhbnQgdG8gY292ZXI6DQoNCk5vdGUg4oCTIEluIHNvbWUgY2FzZXMgKGUuZy4gd2hlbiB0
aGVyZSBhcmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9y
dGluZyBhbmQgcmVhY3Rpbmcgbm9kZXMsIG9yIHdoZW4gb3ZlcmxvYWQgcmVwb3J0cyBhcmUgZGlz
Y2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzKSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5vdCBiZSBh
YmxlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCB0aGUg
cmVwb3J0Lg0KDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNp
c2NvLmNvbV0gDQpTZW50OiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAxNCAxNTo1Ng0KVG86
IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVd
IFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJl
cXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1eiwN
Cg0KTWF5IGJlIGZvbGxvd2luZyBmb3JtYXR0aW5nIG9mIHRoZSBub3RlIGhlbHBzPw0KQSByZXBv
cnRpbmcgbm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBh
IHJlYWN0aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoaXMgb3ZlcmxvYWQgcmVw
b3J0IGlzIGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLg0KDQpOb3RlIOKAkyBJ
biBzb21lIGNhc2VzIChlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMg
aW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzLCBvdmVybG9h
ZCByZXBvcnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMpIHRoZSByZXBvcnRp
bmcgbm9kZSBtYXkgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5v
ZGUgaGFzIHJlY2VpdmVkIHRoZSByZXBvcnQuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTog
RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENy
dXogQmFydG9sb21lDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNjo1MCBQTQ0K
VG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGlu
ZyBPQy1PbmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0
IHN1cnZpdmVkIGEgdGhyb3R0bGluZw0KDQpOaXJhdiwNCg0KRG8geW91IGNvbnNpZGVyIHRoYXQg
b3ZlcmxvYWQgcmVwb3J0cyBjYW4gb25seSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMg
d2hlbiB0aGVyZSBhcmUgYWdlbnRzIGluIHRoZSBwYXRoPw0KDQoNCkZyb206IE5pcmF2IFNhbG90
IChuc2Fsb3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0gDQpTZW50OiBqdWV2ZXMsIDEzIGRl
IGZlYnJlcm8gZGUgMjAxNCAxMzo1OA0KVG86IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGll
dGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2lu
Zy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBh
IHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1eiwNCg0KUmVwb3J0aW5nIG5vdGUgbWF5IHVzZSB2ZXJ5
IHNpbXBsZSBtZWNoYW5pc20g4oCTIGFzIHBvaW50ZWQgb3V0IGJ5IExpb25lbCDigJMgdG8gY29u
Y2x1ZGUgdGhhdCByZXBvcnQgaGFzIHJlYWNoZWQgdGhlIHJlYWN0aW5nIG5vZGUsIGkuZS4gYWxs
IHRoZSBpbnRyYS1zZXNzaW9uIG1lc3NhZ2VzIG5lZWQgbm90IGNvbnRhaW4gdGhlIHNhbWUgb3Zl
cmxvYWQgcmVwb3J0LCBpZiB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IG1lc3NhZ2UgY29udGFp
bnMgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0KU28geW91ciBub3RlIHJlZ2FyZGluZyB0aGUgcmVw
b3J0aW5nIG5vZGUgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIG5ldHdvcmsgZGVwbG95bWVudCBl
dGMuIGlzIG5vdCAxMDAlIGNvcnJlY3QuDQpMZXQgbWUgc2ltcGxpZnksIGhvcGluZyBpdCB3aWxs
IHNhdGlzZnkgeW91ciBjb25jZXJuLg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8g
bm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4g
Z3VhcmFudGVlIHRoYXQgdGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4g
dGhlIHJlYWN0aW5nIG5vZGUuDQoNCk5vdGUg4oCTIEluIHNvbWUgY2FzZXMsIGUuZy4gd2hlbiB0
aGVyZSBhcmUgb25lIG9yIG11bHRpcGxlIGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9y
dGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRl
ZCBieSByZWFjdGluZyBub2RlcywgdGhlIHJlcG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0
byBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9y
dC4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUNClNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAxMywgMjAxNCAyOjMxIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVj
dDogUmU6IFtEaW1lXSBbZGltZV0gIzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1J
bmZvIEFWUCBpbiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoN
CkRlYXIgYWxsLA0KDQpJIHRoaW5rIHRoZW4gd2UgYWdyZWUgb24gdGhlIHByb3Bvc2VkIHRleHQ6
DQoNCkEgcmVwb3J0aW5nIG5vZGUgTVVTVCBlbnN1cmUgdGhhdCBhbGwgcmVhY3Rpbmcgbm9kZXMg
cmVjZWl2ZSBuZXcgb3ZlcmxvYWQgcmVwb3J0cy4NCg0KSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBh
IHJlcG9ydGluZyBub2RlIGluY2x1ZGUgb3ZlcmxvYWQgcmVwb3J0cyBpbiBhbGwgYW5zd2VyIG1l
c3NhZ2VzIHNlbnQgdG8gcmVhY3Rpbmcgbm9kZXMuwqAgDQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5n
IG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNz
YWdlcyBzZW50IHRvIG5vbiByZWFjdGluZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50
LsKgIFRoZSBvdmVybG9hZCByZXBvcnQgd2lsbCBqdXN0IGJlIGlnbm9yZWQgYnkgYSBEaWFtZXRl
ciBub2RlIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBET0lDLg0KDQpBIHJlcG9ydGluZyBub2RlIE1B
WSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3ZlcmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9k
ZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgYWxyZWFkeSBoYXMg
cmVjZWl2ZWQgdGhlIG92ZXJsb2FkIHJlcG9ydC4NCg0KQnV0IHN0aWxsIHRoZXJlIGFyZSBzb21l
IGRpc2NyZXBhbmNpZXMgYWJvdXQgdGhlIG5vdGUuDQpNeSBwcm9wb3NhbCBpcyB0byBrZWVwIGl0
IGp1c3QgYXMgYW4gaW5kaWNhdGlvbiBvZiBwb3RlbnRpYWwgKG1heWJlIG5vdCBhbGwpIHNpdHVh
dGlvbnMgdGhhdCBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50IGlmIGV2ZXIgYW55IGltcGxl
bWVudGF0aW9uIG1heSBjb25zaWRlciB0byBkbyBub3QgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlv
biB0aGF0IGEgcmVwb3J0aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBh
bnN3ZXIgbWVzc2FnZXMuIA0KQmVpbmcgYSByZWNvbW1lbmRhdGlvbiBhbmQgbm90IGEgbXVzdCwg
YXQgbGVhc3QgSSB0aGluayB3ZSBuZWVkIHRvIGluZGljYXRlIHdoYXQgbWF5IGltcGx5IHRvIGRv
IG5vdCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uLiANClRoZW4gbXkgcHJvcG9zYWwgaXMgdGhl
IGZvbGxvd2luZywgdGhhdCBpbmNsdWRlcyBhIG1vZGlmaWNhdGlvbiB0byBsYXN0IHNlbnRlbmNl
IGFib3ZlOg0KDQpBIHJlcG9ydGluZyBub2RlIE1BWSBjaG9vc2UgdG8gbm90IHNlbmQgYW4gb3Zl
cmxvYWQgcmVwb3J0IHRvIGEgcmVhY3Rpbmcgbm9kZSBpZiBpdCBjYW4gZ3VhcmFudGVlIHRoYXQg
dGhpcyBvdmVybG9hZCByZXBvcnQgaXMgYWxyZWFkeSBhY3RpdmUgaW4gdGhlIHJlYWN0aW5nIG5v
ZGUuDQoNCk5vdGUg4oCTdGhlIHJlcG9ydGluZyBub2RlIG1heSBuZWVkIHRvIHRha2UgaW50byBh
Y2NvdW50IG5ldHdvcmsgZGVwbG95bWVudCBhbmQgcG90ZW50aWFsIGVycm9ycyBpbiBvcmRlciB0
byBiZSBhYmxlIHRvIGd1YXJhbnRlZSB0aGF0IHNlbnQgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2
ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSwgZS5nLiB0aGVyZSBtYXkgYmUgb25lIG9yIG11bHRpcGxl
IGFnZW50cyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHJlcG9ydGluZyBhbmQgcmVhY3Rpbmcgbm9kZXM7
IG92ZXJsb2FkIHJlcG9ydHMgbWF5IGJlIGRpc2NhcmRlZCBieSByZWFjdGluZyBub2Rlc+KApg0K
DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv
bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl
dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg
c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1
ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu
c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh
bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u
c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu
IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u
ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk
IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3
aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu
b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv
ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==


From nobody Fri Feb 14 02:07:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9F11A01F9 for ; Fri, 14 Feb 2014 02:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhp7syhvx2iA for ; Fri, 14 Feb 2014 02:07:11 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB31A01EC for ; Fri, 14 Feb 2014 02:07:11 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1EA77Hx026730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 Feb 2014 04:07:09 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EA74NF024384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 11:07:06 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 11:07:05 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb/qgZCc+pd4WU6PPq6Pjc7gSpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3y9MUP++VE6A/3ylYgD++B2GgP3wNjyA++BTQsA=
Date: Fri, 14 Feb 2014 10:07:04 +0000
Message-ID: 
References:  <087A34937E64E74E848732CFF8354B9209774E01@ESESSMB101.ericsson.se>  <30818_1392369778_52FDE071_30818_9638_1_6B7134B31289DC4FAF731D844122B36E4A309D@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <30818_1392369778_52FDE071_30818_9638_1_6B7134B31289DC4FAF731D844122B36E4A309D@PEXCVZYM13.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: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Joi9dhBT6qeilsGmpRkjXuAxuBo
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 10:07:14 -0000

SGkgYWxsDQoNCkkgaGF2ZSBhbm90aGVyIHJlbWFyayB0byBhZGQgdG8gTGlvbmVsJ3Mgb25lIG9u
IDUuMy4yLg0KDQpJZiBhIHJlYWN0aW5nIG5vZGUgZG9lcyBub3QgaW5kaWNhdGUgT0MtU3VwcG9y
dGVkIGZlYXR1cmVzIGluIHRoZSBjcmVhdGlvbiByZXF1ZXN0IG9mIHNlc3Npb24gMShyZXN1bHRp
bmcsIGFzIGFjY29yZGluZyB0byA1LjMuMiwgaW4gbm8gT0xSIGluIHRoZSBhbnN3ZXJzIGJvdW5k
IHRvIHRoaXMgc2Vzc2lvbikgYnV0IHB1dHMgT0MtU3VwcG9ydGVkIGZlYXR1cmVzIGluICB0aGUg
Y3JlYXRpb24gcmVxdWVzdCBvZiBzZXNzaW9uIDIsIHdvdWxkIGl0IG1lYW4gdGhhdCBPdmVybG9h
ZCBjb250cm9sICh0aHJvdHRsaW5nKSBpbiB0aGUgcmVhY3Rpbmcgbm9kZSBhcHBsaWVzIG9ubHkg
dG8gU2Vzc2lvbiAyIHJlcXVlc3RzIGJ1dCBub3QgdG8gc2Vzc2lvbjE/IEkgdGhvdWdodCB3ZSBk
ZWNpZGVkIHRoYXQgdGhlIHF1ZXN0aW9uIG9mIE9MUiBwZXIgc2Vzc2lvbiBvciBncm91cCBvZiBz
ZXNzaW9uIHdhcyBub3QgZm9yIHRoaXMgZHJhZnQgYnV0IGZvciBmdXJ0aGVyIHN0dWR5LiBDbGFy
aWZpY2F0aW9uIHNlZW1zIG5lZWRlZC4NCg0KQmVzdCByZWdhcmRzDQoNCkpKYWNxdWVzICAgDQoN
Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogRGlNRSBbbWFpbHRvOmRpbWUtYm91
bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NCkVu
dm95w6nCoDogdmVuZHJlZGkgMTQgZsOpdnJpZXIgMjAxNCAxMDoyMw0Kw4DCoDogTmlyYXYgU2Fs
b3QgKG5zYWxvdCk7IE1hcmlhIENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpPYmpldMKg
OiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUlu
Zm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0K
SGkgYWxsLA0KDQpJIGRvbid0IHRoaW5rIHRoYXQgYSByZXBvcnRpbmcgbm9kZSBtYXkvY2FuL3dv
dWxkIGxpa2UgdG8gZW5zdXJlL2Nob29zZS9ndWFyYW50ZWUgYW55dGhpbmcgOikgSSdtIG9rIHdp
dGggdGhlIGludGVudGlvbiBvZiB0aGUgdGV4dCBidXQgd2UgbWF5IHByb2JhYmx5IHdvcmQgaXQg
aW4gYSBkaWZmZXJlbnQgd2F5Lg0KDQpNb3Jlb3ZlciwgdGhlIGZpcnN0IHNlbnRlbmNlIGlzIHNv
bWVob3cgaW5jb3JyZWN0LiBOb3QgYWxsIHRoZSByZWFjdGluZyBub2RlcyBuZWVkIHRvIGJlIGF3
YXJlIG9mIHRoZSBuZXcgc3RhdHVzLiBPbmx5IHRob3NlIHdoaWNoIGhhdmUgcmVjZWl2ZWQgYSBw
cmV2aW91cyBPTFIgYXJlIHRhcmdldGVkLiBJIHRoaW5rIHRoYXQgdGhlIHJlcXVpcmVtZW50IGlz
IHRoYXQgcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2RlcyBzaGFyZSB0aGUgbW9zdCB1cC10by1k
YXRlIGluZm8gYW5kIHRoZXJlZm9yZSBpdCBpcyByZWNvbW1lbmRlZCB0byBzZW5kIHRoZSBPTFIg
aW4gZXZlcnkgYW5zd2VyLg0KDQpJIGhhdmUgYSBjb21tZW50IGFueXdheSBvbiB0aGUgZm9sbG93
aW5nIG5vdGU6DQoNCk5vdGUgLSB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IGFsc28gaW5jbHVkZSB0
aGUgb3ZlcmxvYWQgcmVwb3J0IGluIGFuc3dlciBtZXNzYWdlcyBzZW50IHRvIG5vbiByZWFjdGlu
ZyBub2RlcyBpZiB0aGF0IGlzIG1vcmUgZWZmaWNpZW50LiAgVGhlIG92ZXJsb2FkIHJlcG9ydCB3
aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBw
b3J0IERPSUMuDQoNClRoaXMgaXMgY29udHJhZGljdGluZyB0aGUgc3RhdGVtZW50IGdpdmVuIGlu
IDUuMy4yOg0KDQogICBUaGUgYW5zd2VyIG1lc3NhZ2UgaW5pdGlhdGluZyBlbmRwb2ludCBNVVNU
IE5PVCBpbmNsdWRlIGFueSBvdmVybG9hZA0KICAgY29udHJvbCBzb2x1dGlvbiBkZWZpbmVkIEFW
UHMgaW50byBpdHMgYW5zd2VyIG1lc3NhZ2VzIGlmIHRoZSByZXF1ZXN0DQogICBtZXNzYWdlIGlu
aXRpYXRpbmcgZW5kcG9pbnQgaGFzIG5vdCBpbmRpY2F0ZWQgc3VwcG9ydCBhdCB0aGUNCiAgIGJl
Z2lubmluZyBvZiB0aGUgY3JlYXRlZCBzZXNzaW9uIChvciB0cmFuc2FjdGlvbiBpbiBhIGNhc2Ug
b2Ygbm9uLQ0KICAgc2Vzc2lvbiBzdGF0ZSBtYWludGFpbmluZyBhcHBsaWNhdGlvbnMpLiAgVGhl
IHNhbWUgYWxzbyBhcHBsaWVzIGlmDQogICBub25lIG9mIHRoZSBhbm5vdW5jZWQgY2FwYWJpbGl0
aWVzIG1hdGNoIGJldHdlZW4gdGhlIHR3byBlbmRwb2ludHMuDQoNClJlZ2FyZHMsDQoNCkxpb25l
bA0KDQoqKioqKioqKioqKioqKioqKioqKioqKg0KDQpEZcKgOiBEaU1FIFttYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChuc2Fsb3QpIEVudm95
w6nCoDogdmVuZHJlZGkgMTQgZsOpdnJpZXIgMjAxNCAxMDowNiDDgMKgOiBNYXJpYSBDcnV6IEJh
cnRvbG9tZTsgZGltZUBpZXRmLm9yZyBPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMzE6IFNl
bmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3QgbWVzc2FnZXMg
dGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1eiwNCg0KSSBhbSBmaW5lIHdp
dGggdGhlIHByb3Bvc2FsIGJlbG93Lg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IE1hcmlh
IENydXogQmFydG9sb21lIFttYWlsdG86bWFyaWEuY3J1ei5iYXJ0b2xvbWVAZXJpY3Nzb24uY29t
XQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDg6MzggUE0NClRvOiBOaXJhdiBT
YWxvdCAobnNhbG90KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0g
IzMxOiBTZW5kaW5nIE9DLU9uZ29pbmctVGhyb3R0bGluZy1JbmZvIEFWUCBpbiByZXF1ZXN0IG1l
c3NhZ2VzIHRoYXQgc3Vydml2ZWQgYSB0aHJvdHRsaW5nDQoNCk5pcmF2LA0KDQpMZXQgbWUga25v
dyBpZiBmb2xsb3dpbmcgcmVwaHJhc2luZyBzdGlsbCBjb252ZXlzIHRoZSBtZWFuaW5nIHlvdSB3
YW50IHRvIGNvdmVyOg0KDQpOb3RlIOKAkyBJbiBzb21lIGNhc2VzIChlLmcuIHdoZW4gdGhlcmUg
YXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhlIHBhdGggYmV0d2VlbiByZXBvcnRpbmcg
YW5kIHJlYWN0aW5nIG5vZGVzLCBvciB3aGVuIG92ZXJsb2FkIHJlcG9ydHMgYXJlIGRpc2NhcmRl
ZCBieSByZWFjdGluZyBub2RlcykgdGhlIHJlcG9ydGluZyBub2RlIG1heSBub3QgYmUgYWJsZSB0
byBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgcmVjZWl2ZWQgdGhlIHJlcG9y
dC4NCg0KDQpGcm9tOiBOaXJhdiBTYWxvdCAobnNhbG90KSBbbWFpbHRvOm5zYWxvdEBjaXNjby5j
b21dDQpTZW50OiBqdWV2ZXMsIDEzIGRlIGZlYnJlcm8gZGUgMjAxNCAxNTo1Ng0KVG86IE1hcmlh
IENydXogQmFydG9sb21lOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtkaW1l
XSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQIGluIHJlcXVlc3Qg
bWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KTWFyaWEtQ3J1eiwNCg0KTWF5
IGJlIGZvbGxvd2luZyBmb3JtYXR0aW5nIG9mIHRoZSBub3RlIGhlbHBzPw0KQSByZXBvcnRpbmcg
bm9kZSBNQVkgY2hvb3NlIHRvIG5vdCBzZW5kIGFuIG92ZXJsb2FkIHJlcG9ydCB0byBhIHJlYWN0
aW5nIG5vZGUgaWYgaXQgY2FuIGd1YXJhbnRlZSB0aGF0IHRoaXMgb3ZlcmxvYWQgcmVwb3J0IGlz
IGFscmVhZHkgYWN0aXZlIGluIHRoZSByZWFjdGluZyBub2RlLg0KDQpOb3RlIOKAkyBJbiBzb21l
IGNhc2VzIChlLmcuIHdoZW4gdGhlcmUgYXJlIG9uZSBvciBtdWx0aXBsZSBhZ2VudHMgaW4gdGhl
IHBhdGggYmV0d2VlbiByZXBvcnRpbmcgYW5kIHJlYWN0aW5nIG5vZGVzLCBvdmVybG9hZCByZXBv
cnRzIG1heSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMpIHRoZSByZXBvcnRpbmcgbm9k
ZSBtYXkgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFz
IHJlY2VpdmVkIHRoZSByZXBvcnQuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KRnJvbTogRGlNRSBb
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmlhIENydXogQmFy
dG9sb21lDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNjo1MCBQTQ0KVG86IGRp
bWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1P
bmdvaW5nLVRocm90dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZp
dmVkIGEgdGhyb3R0bGluZw0KDQpOaXJhdiwNCg0KRG8geW91IGNvbnNpZGVyIHRoYXQgb3Zlcmxv
YWQgcmVwb3J0cyBjYW4gb25seSBiZSBkaXNjYXJkZWQgYnkgcmVhY3Rpbmcgbm9kZXMgd2hlbiB0
aGVyZSBhcmUgYWdlbnRzIGluIHRoZSBwYXRoPw0KDQoNCkZyb206IE5pcmF2IFNhbG90IChuc2Fs
b3QpIFttYWlsdG86bnNhbG90QGNpc2NvLmNvbV0NClNlbnQ6IGp1ZXZlcywgMTMgZGUgZmVicmVy
byBkZSAyMDE0IDEzOjU4DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWU7IGRpbWVAaWV0Zi5vcmcN
ClN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICMzMTogU2VuZGluZyBPQy1PbmdvaW5nLVRocm90
dGxpbmctSW5mbyBBVlAgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IHN1cnZpdmVkIGEgdGhyb3R0
bGluZw0KDQpNYXJpYS1DcnV6LA0KDQpSZXBvcnRpbmcgbm90ZSBtYXkgdXNlIHZlcnkgc2ltcGxl
IG1lY2hhbmlzbSDigJMgYXMgcG9pbnRlZCBvdXQgYnkgTGlvbmVsIOKAkyB0byBjb25jbHVkZSB0
aGF0IHJlcG9ydCBoYXMgcmVhY2hlZCB0aGUgcmVhY3Rpbmcgbm9kZSwgaS5lLiBhbGwgdGhlIGlu
dHJhLXNlc3Npb24gbWVzc2FnZXMgbmVlZCBub3QgY29udGFpbiB0aGUgc2FtZSBvdmVybG9hZCBy
ZXBvcnQsIGlmIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgbWVzc2FnZSBjb250YWlucyB0aGUg
b3ZlcmxvYWQgcmVwb3J0Lg0KDQpTbyB5b3VyIG5vdGUgcmVnYXJkaW5nIHRoZSByZXBvcnRpbmcg
bm9kZSB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgbmV0d29yayBkZXBsb3ltZW50IGV0Yy4gaXMg
bm90IDEwMCUgY29ycmVjdC4NCkxldCBtZSBzaW1wbGlmeSwgaG9waW5nIGl0IHdpbGwgc2F0aXNm
eSB5b3VyIGNvbmNlcm4uDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2Vu
ZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50
ZWUgdGhhdCB0aGlzIG92ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVh
Y3Rpbmcgbm9kZS4NCg0KTm90ZSDigJMgSW4gc29tZSBjYXNlcywgZS5nLiB3aGVuIHRoZXJlIGFy
ZSBvbmUgb3IgbXVsdGlwbGUgYWdlbnRzIGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFu
ZCByZWFjdGluZyBub2Rlczsgb3ZlcmxvYWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJl
YWN0aW5nIG5vZGVzLCB0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5vdCBiZSBhYmxlIHRvIGd1YXJh
bnRlZSB0aGF0IHRoZSByZWFjdGluZyBub2RlIGhhcyByZWNlaXZlZCB0aGUgcmVwb3J0Lg0KDQpS
ZWdhcmRzLA0KTmlyYXYuDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KU2VudDogVGh1cnNkYXksIEZl
YnJ1YXJ5IDEzLCAyMDE0IDI6MzEgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W0RpbWVdIFtkaW1lXSAjMzE6IFNlbmRpbmcgT0MtT25nb2luZy1UaHJvdHRsaW5nLUluZm8gQVZQ
IGluIHJlcXVlc3QgbWVzc2FnZXMgdGhhdCBzdXJ2aXZlZCBhIHRocm90dGxpbmcNCg0KRGVhciBh
bGwsDQoNCkkgdGhpbmsgdGhlbiB3ZSBhZ3JlZSBvbiB0aGUgcHJvcG9zZWQgdGV4dDoNCg0KQSBy
ZXBvcnRpbmcgbm9kZSBNVVNUIGVuc3VyZSB0aGF0IGFsbCByZWFjdGluZyBub2RlcyByZWNlaXZl
IG5ldyBvdmVybG9hZCByZXBvcnRzLg0KDQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgcmVwb3J0
aW5nIG5vZGUgaW5jbHVkZSBvdmVybG9hZCByZXBvcnRzIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMg
c2VudCB0byByZWFjdGluZyBub2Rlcy7CoCANCg0KTm90ZSAtIHRoZSByZXBvcnRpbmcgbm9kZSBt
YXkgYWxzbyBpbmNsdWRlIHRoZSBvdmVybG9hZCByZXBvcnQgaW4gYW5zd2VyIG1lc3NhZ2VzIHNl
bnQgdG8gbm9uIHJlYWN0aW5nIG5vZGVzIGlmIHRoYXQgaXMgbW9yZSBlZmZpY2llbnQuwqAgVGhl
IG92ZXJsb2FkIHJlcG9ydCB3aWxsIGp1c3QgYmUgaWdub3JlZCBieSBhIERpYW1ldGVyIG5vZGUg
dGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMuDQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29z
ZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCByZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0
IGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSBhbHJlYWR5IGhhcyByZWNlaXZl
ZCB0aGUgb3ZlcmxvYWQgcmVwb3J0Lg0KDQpCdXQgc3RpbGwgdGhlcmUgYXJlIHNvbWUgZGlzY3Jl
cGFuY2llcyBhYm91dCB0aGUgbm90ZS4NCk15IHByb3Bvc2FsIGlzIHRvIGtlZXAgaXQganVzdCBh
cyBhbiBpbmRpY2F0aW9uIG9mIHBvdGVudGlhbCAobWF5YmUgbm90IGFsbCkgc2l0dWF0aW9ucyB0
aGF0IHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgaWYgZXZlciBhbnkgaW1wbGVtZW50YXRp
b24gbWF5IGNvbnNpZGVyIHRvIGRvIG5vdCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIHRoYXQg
YSByZXBvcnRpbmcgbm9kZSBpbmNsdWRlIG92ZXJsb2FkIHJlcG9ydHMgaW4gYWxsIGFuc3dlciBt
ZXNzYWdlcy4gDQpCZWluZyBhIHJlY29tbWVuZGF0aW9uIGFuZCBub3QgYSBtdXN0LCBhdCBsZWFz
dCBJIHRoaW5rIHdlIG5lZWQgdG8gaW5kaWNhdGUgd2hhdCBtYXkgaW1wbHkgdG8gZG8gbm90IGZv
bGxvdyB0aGUgcmVjb21tZW5kYXRpb24uIA0KVGhlbiBteSBwcm9wb3NhbCBpcyB0aGUgZm9sbG93
aW5nLCB0aGF0IGluY2x1ZGVzIGEgbW9kaWZpY2F0aW9uIHRvIGxhc3Qgc2VudGVuY2UgYWJvdmU6
DQoNCkEgcmVwb3J0aW5nIG5vZGUgTUFZIGNob29zZSB0byBub3Qgc2VuZCBhbiBvdmVybG9hZCBy
ZXBvcnQgdG8gYSByZWFjdGluZyBub2RlIGlmIGl0IGNhbiBndWFyYW50ZWUgdGhhdCB0aGlzIG92
ZXJsb2FkIHJlcG9ydCBpcyBhbHJlYWR5IGFjdGl2ZSBpbiB0aGUgcmVhY3Rpbmcgbm9kZS4NCg0K
Tm90ZSDigJN0aGUgcmVwb3J0aW5nIG5vZGUgbWF5IG5lZWQgdG8gdGFrZSBpbnRvIGFjY291bnQg
bmV0d29yayBkZXBsb3ltZW50IGFuZCBwb3RlbnRpYWwgZXJyb3JzIGluIG9yZGVyIHRvIGJlIGFi
bGUgdG8gZ3VhcmFudGVlIHRoYXQgc2VudCBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlIGluIHRo
ZSByZWFjdGluZyBub2RlLCBlLmcuIHRoZXJlIG1heSBiZSBvbmUgb3IgbXVsdGlwbGUgYWdlbnRz
IGluIHRoZSBwYXRoIGJldHdlZW4gcmVwb3J0aW5nIGFuZCByZWFjdGluZyBub2Rlczsgb3Zlcmxv
YWQgcmVwb3J0cyBtYXkgYmUgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVz4oCmDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu
aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l
IGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z
IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2
ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx
dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz
dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp
bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy
Y2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp
ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi
eSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0
aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl
cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu
ZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu
b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv
ciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo=


From nobody Fri Feb 14 02:20:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042B61A017B for ; Fri, 14 Feb 2014 02:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kNkupxMNlhS for ; Fri, 14 Feb 2014 02:20:23 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49C1A01C3 for ; Fri, 14 Feb 2014 02:20:18 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-55-52fdede05c5d
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6F.88.04249.0EDEDF25; Fri, 14 Feb 2014 11:20:16 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 11:20:15 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpquSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8ICAABIAAIAAoHoQgADcMfA=
Date: Fri, 14 Feb 2014 10:20:15 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209775207ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje6Dt3+DDLZOVraY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXfO7GQtaD/HUnHnwRKmBsZznSxdjJwcEgImEu2zN7FD2GIS F+6tZ+ti5OIQEjjCKHFu42MWCGcJo8Sy76vZQKrYBOwkLp1+wdTFyMEhIqAhseJEJkhYWMBb 4seHy0wgtoiAj0Rv4xE2CHsTo8TmFTIgNouAqsS0SUvBlvEK+ErsnLWRCWL+Dw6J11OfgDVw CsRKfOj4B1bECHTR91NrwIYyC4hL3HoynwniUgGJJXvOM0PYohIvH/9jhbCVJFZsv8QIUZ8v cXrdL1aIZYISJ2c+YZnAKDILyahZSMpmISmDiOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWZPEF jOyrGDmKU4uTctONDDYxAuPl4JbfFjsYL/+1OcQozcGiJM778a1zkJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQZGn7Nq28OPuV6z1jr99pzM58jK/3VTTs3ofqf1nOnI17v7pz/nZwj8LhrO 9bf1zVRhbrX9DfHfc6Q+LkutTV2YVZvQ8C3S+yPvRretBVO37HY2+8607OjWxyferZguvijk tuOFO9t+bq+PM/M0ilD8+sdpoSlXiOBM3+uT/gfPDF/XyilTESLOpMRSnJFoqMVcVJwIADic CEhlAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_lMu9idf5Uy3p-wcmNmzjtgXgHQ
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 10:20:32 -0000

--_000_087A34937E64E74E848732CFF8354B9209775207ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Jean-Jacques,

I understand your concerns.
However, I think same precautions in the process to return back to a situat=
ion where throttling is not requested, can be achieved without allowing "0%=
".
On one hand, DOIC-enabled reporting node should supervise constantly how re=
ceived  traffic is affecting its overload, in order to be able to request a=
 reduction when required. It should not only be done during the new Validit=
yDuration when 0% was requested.
A part from that, gradual increase of allowed traffic is always possible (w=
ithout 0%), since even reporting node could use 10%... 5%, 3%, 1%.

However, I do not think this subject is critical. 0% could be acceptable by=
 me if you (all) still think this is preferable.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: viernes, 14 de febrero de 2014 9:46
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hi MCruz, Steve

I here  answer Steve and MCruz mails

About Steve, I have not said the reporting "needs" to send a 0% reduction v=
alid
( it is an implementation choice of the reporting node to choose the % valu=
es it puts in OLR), I simply says  to not forbid it.

In an overload condition, a behavior example is that the reporting , by its=
 own logic (not standardised) , determines the % reduction  value it send i=
n OLRs, and then will observe the effect of this OLR in the evolution of th=
e received  traffic that  the reacting has throttled. Reporting will then d=
ecides to keep, increase or decrease the OLR %value .When we come to the en=
d of overload, the reporting still receiving throttled traffic, will consid=
er that it does  not more need to request a % reduction.

-        One way is to send an OLR with validity period to 0 to indicate th=
e end of the overload condition, but it does this without having yet receiv=
ed unthrottled  traffic that in some case may nevertheless  request to imme=
diately send again an OLR requesting reduction, meaning that reporting, hav=
ing terminated  an overload condition, will  immediately restart another on=
e. This a way to proceed as Steve described , I do not say it does not work

-        The way I describe is that  reporting  sends a 0% value to see the=
 effect of this new value on the traffic it will receive (that will be unth=
rottled), before concluding  to the end of the overload , and if neverthele=
ss the received unthrottled  traffic still require to send  OLRs,  reportin=
g will not conclude to the end of overload condition  and again generate OL=
Rs with a non zero % value.

On the reacting, if it receives a 0% value, it simply does nothing,

I remind  I agree with the proposal  that the end of the Overlaod condition=
 is determined by the Value 0 of the Validity period , or the end of the  e=
xpiry timer, but is not linked to the 0%  traffic reduction

Developers, have various possibilities in the  way   to manage the  overloa=
d condition  and the OLRS they send, I think that DOIC should leave flexibi=
lity.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 13 f=E9vrier 2014 13:16
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

JJ,

Why does the reacting node need to send a reduction percentage of zero to d=
etermine if it is stable?  Can't the reacting node just do its normal check=
ing for overload after sending the validity period of zero?  If it finds th=
e need for reduction of traffic, it can just send a new overload report.

Steve
On 2/13/14 4:43 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi MCruz

AS  Ben proposed, and I agree,   value of zero (0) for the Validity period =
indicates that an existing overload condition has ended and that the report=
ing node is in a stable condition.
An important word is "stable".

When the traffic peak on client side having created the overload decreases,=
   the reporting node progressively diminishes the % traffic reduction in O=
LRs it sends  towards clients taking care to minimize the possible oscillat=
ions. At a certain time ,  server will consider that it can indicate no tra=
ffic reduction to clients. Then is it stable?  there may be different imple=
mentation dependent  ways for the server to decide the situation is stable;=
  one is to send 0% in OLRs and wait a certain number of seconds (not 24 ho=
urs) to check if situation is stable  and then put the validity timer to 0 =
(or leaves the expiry timer  expire). I do not see why to forbid this  way =
to test the stable condition.

So the end of overload condition, as Ben proposed,  can remain ONLY based o=
n Validity  duration value 0 (or timer expiry), not on the value 0 of the %=
 reduction (so a bit different from Nirav statement, but in line with Ulric=
h comment) . The value 0% of the traffic reduction is not forbidden as a po=
ssible  way to check the stability condition .

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56
=C0 : dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hello all,

I think proposal to use just Validity-Duration=3D0 to end overload mainly h=
as the intention to simplify and avoid the checks you just listed below.
If we allow both, it means that the case Ulrich mentioned is valid, and eve=
n with 0% reduction OLR info cannot be deleted until Validity time expires,=
 even we could receive a new OLR in sequence. Even, the reporting needs sti=
ll to keep Validity timer on for this OLR.
I think this does not provide any added value but simply makes things a bit=
 more complex. What could be the reason to keep 0% reduction but a Validity=
 of a few hours (e.g.)?

Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: jueves, 13 de febrero de 2014 10:24
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I am OK with Ulrich

JJacques


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56
=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@=
ietf.org list
Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also agree with the principle.

One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,

-        0 reduction, non-zero validity period =3D> Valid. The reacting nod=
e can ignore the validity period if reduction is 0.

-        Non-zero reduction, 0 validity period =3D> Valid. The reacting nod=
e can ignore the reduction if validity period is 0.

-        0 reduction, 0 validity period =3D> Valid as well. Generally, this=
 is what the reporting node will use to indicate the end of overload condit=
ion.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of =
0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still s=
ending OLR eg with  5% reduction    will consider to no request anymore tra=
ffic reduction but without being yet sure if  it will be  stable (end of ov=
erload condition as Ben reminded means stable  situation without traffic re=
duction ) , so server  can send 0% reduction OLR  but with a validity durat=
ion different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic wi=
th the client is 1000 request per second this means 10 requests throttled p=
er second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (c=
f Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22
=C0 : ext Maria Cruz Bartolome; dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overl=
oad.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value =3D=3D 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.i=
etf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundr=
ed (100).  Values greater than 100 are interpreted as 100.  The value of 10=
0 means that no traffic is expected, i.e. the reporting node is under a sev=
ere load and ceases to process any new messages. The Reduction-Percentage A=
VP MUST be present in an overload report that uses the default abatement al=
gorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen > wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell > wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen > wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell > wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen > wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker > wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons=
:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows a sim=
pler implementation.



_______________________________________________
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


--_000_087A34937E64E74E848732CFF8354B9209775207ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Jean-Jacques,<=
/o:p>


 <=
/p>

I understand your concern=
s.


However, I think same pre=
cautions in the process to return back to a situation where throttling is n=
ot requested, can be achieved without allowing “0%”.



On one hand, DOIC-enabled=
 reporting node should supervise constantly how received  traffic is a=
ffecting its overload, in order to be able to request a reduction
 when required. It should not only be done during the new ValidityDuration =
when 0% was requested.


A part from that, gradual=
 increase of allowed traffic is always possible (without 0%), since even re=
porting node could use 10%... 5%, 3%, 1%.


 <=
/p>

However, I do not think t=
his subject is critical. 0% could be acceptable by me if you (all) still th=
ink this is preferable.


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: viernes, 14 de febrero de 2014 9:46

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Hi MCruz, Steve


 <=
/p>

I here  answer Steve=
 and MCruz mails


 <=
/p>

About Steve, I have not s=
aid the reporting “needs” to send a 0% reduction valid


( it is an implementation=
 choice of the reporting node to choose the % values it puts in OLR), I sim=
ply says  to not forbid it.


 <=
/p>

In an overload condition,=
 a behavior example is that the reporting , by its own logic (not standardi=
sed) , determines the % reduction  value it send in OLRs,
 and then will observe the effect of this OLR in the evolution of the recei=
ved  traffic that  the reacting has throttled. Reporting will the=
n decides to keep, increase or decrease the OLR %value .When we come to the=
 end of overload, the reporting still receiving
 throttled traffic, will consider that it does  not more need to reque=
st a % reduction.


- =
;      
One way is to sen=
d an OLR with validity period to 0 to indicate the end of the overload cond=
ition, but it does this without having yet received unthrottled
  traffic that in some case may nevertheless  request to immediat=
ely send again an OLR requesting reduction, meaning that reporting, having =
terminated  an overload condition, will  immediately restart anot=
her one. This a way to proceed as Steve described ,
 I do not say it does not work


- =
;      
The way I describ=
e is that  reporting  sends a 0% value to see the effect of this =
new value on the traffic it will receive (that will be unthrottled),
 before concluding  to the end of the overload , and if nevertheless t=
he received unthrottled  traffic still require to send  OLRs, &nb=
sp;reporting will not conclude to the end of overload condition  and a=
gain generate OLRs with a non zero % value.



 <=
/p>

On the reacting, if it re=
ceives a 0% value, it simply does nothing,



 <=
/p>

I remind  I agree wi=
th the proposal  that the end of the Overlaod condition is determined =
by the Value 0 of the Validity period , or the end of the  expiry
 timer, but is not linked to the 0%  traffic reduction  


 <=
/p>

Developers, have various =
possibilities in the  way   to manage the  overload con=
dition  and the OLRS they send, I think that DOIC should leave flexibi=
lity.


 <=
/p>

Best regards


 <=
/p>

JJacques  


    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;  


 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : jeudi 13 f=E9vrier 2014 13:16

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


JJ,



Why does the reacting node need to send a reduction percentage of zero to d=
etermine if it is stable?  Can't the reacting node just do its normal =
checking for overload after sending the validity period of zero?  If i=
t finds the need for reduction of traffic,
 it can just send a new overload report.



Steve




On 2/13/14 4:43 AM, TROTTIN, JEAN-=
JACQUES (JEAN-JACQUES) wrote:






Hi MCruz


 =



AS  Ben proposed, an=
d I agree,   value of zero (0) for the Validity period indicates =
that an existing overload condition has ended and that the reporting node
 is in a stable condition.


An important word is R=
20;stable”.


 <=
/p>

When the traffic peak on =
client side having created the overload decreases,   the reportin=
g node progressively diminishes the % traffic reduction in OLRs it
 sends  towards clients taking care to minimize the possible oscillati=
ons. At a certain time ,  server will consider that it can indicate no=
 traffic reduction to clients. Then is it stable?  there may be differ=
ent implementation dependent  ways for the server
 to decide the situation is stable;  one is to send 0% in OLRs and wai=
t a certain number of seconds (not 24 hours) to check if situation is stabl=
e  and then put the validity timer to 0 (or leaves the expiry timer &n=
bsp;expire). I do not see why to forbid this  way
 to test the stable condition.


 <=
/p>

So the end of overload co=
ndition, as Ben proposed,  can remain ONLY based on Validity  dur=
ation value 0 (or timer expiry), not on the value 0 of the % reduction
 (so a bit different from Nirav statement, but in line with Ulrich comment)=
 . The value 0% of the traffic reduction is not forbidden as a possible &nb=
sp;way to check the stability condition .


 <=
/p>

Best regards



 =



JJacques


 =



 =







De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : jeudi 13 f=E9vrier 2014 10:56

=C0 : dime@ietf.org list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Hello all,


 <=
/p>

I think proposal to use j=
ust Validity-Duration=3D0 to end overload mainly has the intention to simpl=
ify and avoid the checks you just listed below.


If we allow both, it mean=
s that the case Ulrich mentioned is valid, and even with 0% reduction OLR i=
nfo cannot be deleted until Validity time expires, even
 we could receive a new OLR in sequence. Even, the reporting needs still to=
 keep Validity timer on for this OLR.


I think this does not pro=
vide any added value but simply makes things a bit more complex. What could=
 be the reason to keep 0% reduction but a Validity of a
 few hours (e.g.)?


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: jueves, 13 de febrero de 2014 10:24

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I am OK with Ulrich


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Envoy=E9 : jeudi 13 f=E9vrier 2014 09:56

=C0 : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES); 
dime@ietf.org list

Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


I also agree with the pri=
nciple.


 <=
/p>

One minor clarification:<=
/span>


0%-reduction with non-zer=
o validity period is valid but validity period cannot be ignored: as long a=
s not expired the sequence number needs to be stored for
 future checking; once expired, sequence number must not be used for future=
 checking.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Nirav Salot (nsalot)

Sent: Thursday, February 13, 2014 4:11 AM

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I also tend to agree with=
 JJ below.


Unless there is a strong =
reason, no point in forbidding the use of 0% reduction – which can al=
so indicate end of overload condition.


 <=
/p>

May be we can clarify tha=
t 0% reduction and/or 0 validity period indicates end of overload. In my vi=
ew, both are valid for the use, individually and together.
 So,


-      =
 
0 reduction, non-=
zero validity period =3D> Valid. The reacting node can ignore the validi=
ty period if reduction is 0.


-      =
 
Non-zero reductio=
n, 0 validity period =3D> Valid. The reacting node can ignore the reduct=
ion if validity period is 0.


-      =
 
0 reduction, 0 va=
lidity period =3D> Valid as well. Generally, this is what the reporting =
node will use to indicate the end of overload condition.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Thursday, February 13, 2014 2:18 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear all



 <=
/p>

On this ticket,  I a=
gree on Ben’s  proposal  to use the Validity period of 0 to=
 indicate the end of overload.


But about the value of 0%=
 reduction why to forbid it ?


 <=
/p>

In the process to  r=
eturn to normal traffic conditions, the  server still sending OLR eg w=
ith  5% reduction    will consider to no request anymor=
e traffic reduction
 but without being yet sure if  it will be  stable (end of overlo=
ad condition as Ben reminded means stable  situation without traffic r=
eduction ) , so server  can send 0% reduction OLR  but with a val=
idity duration different from 0.



Otherwise it has to  =
;use 1% throttling to check stability and if traffic with the client is 100=
0 request per second this means 10 requests throttled per second
 which should not be throttled.


In addition, we do not ne=
ed to handle the 0% reduction  as an error case (cf Mcruz mail)=



 <=
/p>

Best regards<=
/span>


 =



JJacques



 =



 =







De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mercredi 12 f=E9vrier 2014 10:22

=C0 : ext Maria Cruz Bartolome; dime@ietf.org list

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


Thank you for the clarifi=
cation.


I agree.


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 10:13 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Dear Ulrich, all,<=
o:p>


 <=
/p>

The proposal was to use O=
C-Validity-Duration AVP =3D0 to indicate end of overload, since this could =
be generally applied to any algorithm.


Then, Reduction-Percentag=
e =3D 0 should be considered as invalid.


I found this reasonable.<=
/span>


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: Wiehe, U=
lrich (NSN - DE/Munich) [mailto:ulr=
ich.wiehe@nsn.com]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:57

To: Maria Cruz Bartolome; dime@ietf=
.org list

Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I’m con=
fused,


 =



I thought that people wer=
e in favour of allowing 0 to indicate end of overload.

 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Wednesday, February 12, 2014 9:44 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben, all,


 <=
/p>

This comment affects as w=
ell clause 5.5.2:


 <=
/p>

  =
; value =3D=3D 0


 


  =
;    Indicates explicitly the end of overload condition and =
the


  =
;    reacting node SHOULD NOT apply the traffic abatement al=
gorithm


  =
;    procedures anymore for the given reporting node (or rea=
lm).


 =



This should be modified t=
o explain this value is not valid and what is the expected behavior (i.e. i=
t is discarded).


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: martes, 11 de febrero de 2014 14:54

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


Ben,

 <=
/p>

This approach sounds reas=
onable to me.


But I would like to clari=
fy what should be the behavior if a Reduction-Percentage=3D0 is received. T=
his is an invalid value, then I presume it should be discarded
 by client. 


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





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

Sent: martes, 11 de febrero de 2014 0:56

To: Jouni Korhonen

Cc: dime@ietf.org list; 
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 




So, here's some proposed text. (intentionally ignori=
ng the related discussion about handling invalid values):






 






Section 4.5, first paragraph, last 2 sentences:=







 






Old:






 






Validity duration values 0 (i.e., 0 seconds) and abo=
ve 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration value=
s are treated as if the OC-Validity-Duration AVP were not present.






 






New:






 






Validity duration values above 86400 MUST NOT be use=
d. Invalid validity duration values are treated as if the OC-Validity-Durat=
ion AVP were not present. A value of zero (0) indicates that an existing ov=
erload condition has ended and that
 the reporting node is in a stable condition.






 






Section 4.7, 2nd paragraph:






 






Old:






 








 The value of the Reduction-Percentage AVP is b=
etween one (1) and one hundred (100).  Values greater than 100 are int=
erpreted as 100.  The value of 100 means that no traffic is expected, =
i.e. the reporting node is under a severe load and
 ceases to process any new messages. The Reduction-Percentage AVP MUST be p=
resent in an overload report that uses the default abatement algorithm.








 










Note that there is no zero (0) value defined for the=
 Reduction-Percentage AVP. A zero value would logically indicate that no ov=
erload abatement is requested. Instead, reporting nodes use a OC-Validity-D=
uration AVP value of zero (0) to indicate
 the end of an overload condition. [Section 4.5]










 






 






 






 






 






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Just post it here.






On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com> wrote:


Okay. Does that mean =
we should assign the issue to me in the tracker?



On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




Ben,



Propose some text and we can see how it fits in.



- Jouni





On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:




On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:




On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wro=
te:


#45: Why is a validity duration of 0 disallowed?



Section 4.5 disallows a validity duration of zero. Why do we want to

disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.<=
br>
(We currently use a reduction percentage of zero to end an overload

condition--but that's specific to the loss algorithm and might not make

sense for all future ones.)




Right. Avoiding two ways of ending overload condition was the reason.

I am OK to have validity duration 0 as an additional method ending the

overload condition based on the reasoning above.




I would go further and make duration 0 the _preferred_ way, for two reasons=
:



1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)



2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload condition. This allows =
a simpler implementation.


 


 




_______________________________________________

DiME mailing list

DiME@ietf.org

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


 









_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_087A34937E64E74E848732CFF8354B9209775207ESESSMB101erics_--


From nobody Fri Feb 14 04:18:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900A71A021B for ; Fri, 14 Feb 2014 04:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plaOqgYlMd_T for ; Fri, 14 Feb 2014 04:17:57 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 290861A0212 for ; Fri, 14 Feb 2014 04:17:55 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1ECHp1g009107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 13:17:51 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1ECHeaK028119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 13:17:51 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 14 Feb 2014 13:17:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 13:17:40 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYIAAHLvQgAAuN4CAAYuNgIABjxoQ
Date: Fri, 14 Feb 2014 12:17:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com>
In-Reply-To: <52FCC20F.5000900@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.104]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3556DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 26416
X-purgate-ID: 151667::1392380272-00001A6F-1EFC5730/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rFnmQqCggbV-8QiceVK4Ry2qoh4
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 12:18:01 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3556DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,
For my clarification:
Your proposal is to mark OC-Supported-Feature AVPs when inserted to answer =
messages by an agent?

If so, the reacting node can associate unmarked Supported-Features AVPs wit=
h the server (orig-host) and can discard marked Supported-Features AVPs.

Is that understanding correct?

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 13, 2014 2:01 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

This could be addressed by adding the requirement that an OC-Supported-Feat=
ures AVP AVP that is inserted by an agent be marked as such.

Steve
On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

The reacting node (when receiving OC-Supported-Features AVP in an answer) k=
nows that the corresponding request took a path towards the server on which=
 there is a reporting node (which supports DOIC). It does not know whether =
this reporting node is the server or an agent and it does not know whether =
subsequent requests will take the same path or a different path on which th=
ere may be no reporting node.

Consequently the presence of OC-Supported-Features AVP in an answer does no=
t tell you anything usefull on which to base behaviour for subsequent reque=
sts targeted to the same server.



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Wednesday, February 12, 2014 10:56 AM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s



Ulrich,

Thanks for your response, see comments please



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: mi=E9rcoles, 12 de febrero de 2014 9:14

To: Maria Cruz Bartolome; dime@ietf.org list

Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s



I understand your point but I'm not really convinced.



1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.

[MCruz] I agree. But one of the 3GPP requirements is to improve reacting no=
de overload mitigation based on implicit indications (as described by TR), =
therefore any 3GPP application that will support new "Overload mitigation" =
feature (or whatever may be the name), shall improve its procedures with th=
is objective. It is expected as well, that this new 3GPP "Overload mitigati=
on" feature makes use of our DOIC, and then it is very beneficial that the =
reacting node could identify at any moment whether or not the reporting nod=
e supports DOIC, since procedures to be implemented could be potentially di=
fferent.



2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?

[MCruz] Reacting node receives reporting node Supported-Features. Regardles=
s the reporting node is either an agent or a server, in case the reacting n=
ode needs to treat "implicit indications" (like TOO_BUSY), expected reactio=
n may depend on whether or not reporting node supports DOIC. This informati=
on is very beneficial to determine the most appropriate reaction.





-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Tuesday, February 11, 2014 9:21 PM

To: dime@ietf.org list

Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s



I agree with Ben here.

The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.



In fact, we have already included this as a requirement  in our 3GPP TR:



6.3.3    Implicit Overload Indication

6.3.3.1  Introduction

IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.

However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.

At least the following indications may be considered:

- DIAMETER_TOO_BUSY protocol error:

Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.

- Lack of response:

In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.







-----Original Message-----

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

Sent: martes, 11 de febrero de 2014 16:55

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org list

Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s





On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



1) I want the reacting node to be able to learn if a (potentially)

reporting node supports DOIC, even when that node is not in overload.

I don't want to specify any particular behavior for that knowledge,

but I suspect implementations may want to treat DOIC compliant servers

in some way differently than they do non-DOIC servers. For example, I

might have a configured rate limit for non-DOIC peers, but use a

higher (or no) limit for peers that are known to support DOIC (and can

thus speak for themselves.) sounds like a new requirement;

where does it come from? I would have thought that there is no need to

distinguish between

a) DOIC not supported and therefore no traffic reduction requested,

and

b) DOIC supported, but not in overload and therefore no traffic

reduction requested





At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.



In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.



_______________________________________________

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




--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3556DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

For my clarification:


Your propo=
sal is to mark OC-Supported-Feature AVPs when inserted to answer messages b=
y an agent?


 =
;


If so, the=
 reacting node can associate unmarked Supported-Features AVPs with the serv=
er (orig-host) and can discard marked Supported-Features AVPs.


 =
;


Is that un=
derstanding correct?


 =
;


Ulrich


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Thursday, February 13, 2014 2:01 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer =
messages






 


This could be address=
ed by adding the requirement that an OC-Supported-Features AVP AVP that is =
inserted by an agent be marked as such.



Steve




On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






The reacting node (when receiving OC-Supported-Features AVP in an answ=
er) knows that the corresponding request took a path towards the server on =
which there is a reporting node (which supports DOIC). It does not know whe=
ther this reporting node is the server or an agent and it does not know whe=
ther subsequent requests will take the same path or a different path on whi=
ch there may be no reporting node. 


Consequently the presence of OC-Supported-Features AVP in an answer do=
es not tell you anything usefull on which to base behaviour for subsequent =
requests targeted to the same server.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Wednesday, February 12, 2014 10:56 AM


To: dime@ietf.org list=



Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer me=
ssages


 


Ulrich,


Thanks for your response, see comments please


 


Best regards


/MCruz


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: mi=E9rcoles, 12 de febrero de 2014 9:14


To: Maria Cruz Bartolome; dime@ietf.o=
rg list


Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer me=
ssages


 


I understand your point but I'm not really convinced.


 


1. implicit indications (like answer message with result code TOO_BUSY=
 and without piggybacked OLR or Lack of response) should be taken into acco=
unt by reacting nodes independent from DOIC-support of the server.


[MCruz] I agree. But one of the 3GPP requirements is to improve reacti=
ng node overload mitigation based on implicit indications (as described by =
TR), therefore any 3GPP application that will support new "Overload mi=
tigation" feature (or whatever may be the name), shall improve its pro=
cedures with this objective. It is expected as well, that this new 3GPP &qu=
ot;Overload mitigation" feature makes use of our DOIC, and then it is =
very beneficial that the reacting node could identify at any moment whether=
 or not the reporting node supports DOIC, since procedures to be implemente=
d could be potentially different.


 


2. How would the reacting node know whether the OC-Supported-Features =
AVP received in an answer indicates the features supported by the server (i=
dentified by the origin-host received in the answer) or the features suppor=
ted by an agent on the path? 


[MCruz] Reacting node receives reporting node Supported-Features. Rega=
rdless the reporting node is either an agent or a server, in case the react=
ing node needs to treat "implicit indications" (like TOO_BUSY), e=
xpected reaction may depend on whether or not reporting node supports DOIC.=
 This information is very beneficial to determine the most appropriate reac=
tion.


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Tuesday, February 11, 2014 9:21 PM


To: dime@ietf.org list=



Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer me=
ssages


 


I agree with Ben here.


The mechanism is meant to work in mixed scenarios and it is relevant f=
or the reacting node to know whether or not a server supports DOIC, since t=
he reacting node should be able to mitigate this server overload as well wh=
en this server does not support DOIC.


 


In fact, we have already included this as a requirement  in our 3=
GPP TR:


 


6.3.3    Implicit Overload Indication


6.3.3.1  Introduction


IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of=
 implicit indications and the inadequacy of this approach for large, divers=
e networks.


However, a Diameter client may receive some overload indications as de=
fined in Diameter base specification IETF RFC 6733 [2] and then it is recom=
mended that the client uses them to mitigate overload situation. This may h=
appen even if involved server and client support the new CN Overload mechan=
ism under definition, but client handling of such indications is even more =
important when the new mechanism is not supported by either client or serve=
r.


At least the following indications may be considered:


- DIAMETER_TOO_BUSY protocol error:


Diameter base specification IETF RFC 6733 [2] does not suggest that th=
e receipt of a protocol error DIAMETER_TOO_BUSY response should affect futu=
re Diameter messages in any way, then it may be relevant for some applicati=
ons to define the behavior that best mitigate the overload situation, takin=
g into account application specifics, operator deployments.... For example,=
 MME may implement a mitigation procedure based on the rate of received DIA=
METER_TOO_BUSY protocol error from HSS.


- Lack of response:


In case of overload the server may react dropping the requests without=
 any Diameter error message being returned, what may imply retransmissions =
in the client side, negatively impacting overload. Therefore, for each appl=
ication, it should be analyzed how to mitigate overload in this situation. =
For example, the client may consider avoiding retransmissions when a number=
 of messages have not been answered.


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Ben Campbell


Sent: martes, 11 de febrero de 2014 16:55


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org list=



Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer me=
ssages


 


 


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:


 




1) I want the reacting node to be able to learn if a (potentially) 


reporting node supports DOIC, even when that node is not in overload.<=
o:p>


I don't want to specify any particular behavior for that knowledge, 


but I suspect implementations may want to treat DOIC compliant servers=
 


in some way differently than they do non-DOIC servers. For example, I =



might have a configured rate limit for non-DOIC peers, but use a =



higher (or no) limit for peers that are known to support DOIC (and can=
 


thus speak for themselves.) <Ulrich>sounds like a new requiremen=
t; 


where does it come from? I would have thought that there is no need to=
 


distinguish between


a) DOIC not supported and therefore no traffic reduction requested, 


and


b) DOIC supported, but not in overload and therefore no traffic <=
/o:p>


reduction requested</Ulrich>


 




 


At one point, I thought we agreed as a group that a reacting node shou=
ld be able to identify if a (potential) reporting node supported the mechan=
ism. But in any case, we have a requirement that the mechanism must work in=
 a mixed environment, where some nodes support it and some don't. It's much=
 _easier_ to meet that requirement if we can tell what nodes support it and=
 what don't. 


 


In general, a reacting node can assume that a server that supports DOI=
C, but hasn't reported overload is not overloaded. It can make no such assu=
mption about a server that doesn't support DOIC. If it does not know the di=
fference between a non-overloaded server and a non-supporting server, it mu=
st assume all such servers are non-supporting. It ends up simply knowing th=
at some servers _are_ overloaded, and some other servers _might_be_ overloa=
ded.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3556DEMUMBX014nsnin_--


From nobody Fri Feb 14 06:17:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281B41A0265 for ; Fri, 14 Feb 2014 06:16:58 -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
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 Gnd8x3oBBQ-3 for ; Fri, 14 Feb 2014 06:16:56 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3A1A022D for ; Fri, 14 Feb 2014 06:16:56 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58485 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WEJZO-00010F-Ee for dime@ietf.org; Fri, 14 Feb 2014 06:16:54 -0800
Message-ID: <52FE254E.4020708@usdonovans.com>
Date: Fri, 14 Feb 2014 08:16:46 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
References: <20140214141253.5531.44452.idtracker@ietfa.amsl.com>
In-Reply-To: <20140214141253.5531.44452.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140214141253.5531.44452.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------040201060408030806070404"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DXZzFD9vsjO80Ynesy-NqZPc7P4
Subject: [Dime] Fwd: New Version Notification for draft-donovan-dime-agent-overload-01.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 14:16:58 -0000

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

FYI


-------- Original Message --------
Subject: 	New Version Notification for
draft-donovan-dime-agent-overload-01.txt
Date: 	Fri, 14 Feb 2014 06:12:53 -0800
From: 	internet-drafts@ietf.org
To: 	Steve Donovan , Steve Donovan




A new version of I-D, draft-donovan-dime-agent-overload-01.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-dime-agent-overload
Revision:	01
Title:		Diameter Agent Overload
Document date:	2014-02-14
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-01.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload/
Htmlized:       http://tools.ietf.org/html/draft-donovan-dime-agent-overload-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-donovan-dime-agent-overload-01

Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  The extension addresses the handling of
   agent overload.

Requirements
                                                                                  


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

The IETF Secretariat





--------------040201060408030806070404
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    FYI

    


      

      -------- Original Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-donovan-dime-agent-overload-01.txt
          

          

            Date: 
            Fri, 14 Feb 2014 06:12:53 -0800
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Steve Donovan <srdonovan@usdonovans.com>, Steve
              Donovan <srdonovan@usdonovans.com>
          

        
      

      

      

      
A new version of I-D, draft-donovan-dime-agent-overload-01.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-dime-agent-overload
Revision:	01
Title:		Diameter Agent Overload
Document date:	2014-02-14
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-01.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload/
Htmlized:       http://tools.ietf.org/html/draft-donovan-dime-agent-overload-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-donovan-dime-agent-overload-01

Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  The extension addresses the handling of
   agent overload.

Requirements
                                                                                  


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

The IETF Secretariat




      

    

    

  


--------------040201060408030806070404--


From nobody Fri Feb 14 06:18:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807271A0267 for ; Fri, 14 Feb 2014 06:18:54 -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
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 e2SzFYEdG_c7 for ; Fri, 14 Feb 2014 06:18:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 253A11A02A9 for ; Fri, 14 Feb 2014 06:18:41 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58486 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WEJb6-0003PI-SH for dime@ietf.org; Fri, 14 Feb 2014 06:18:39 -0800
Message-ID: <52FE25B8.2010709@usdonovans.com>
Date: Fri, 14 Feb 2014 08:18:32 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
References: <20140214141534.22116.6307.idtracker@ietfa.amsl.com>
In-Reply-To: <20140214141534.22116.6307.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140214141534.22116.6307.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------020708070504040801060605"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uowVWEhRQp3BRkxjqZt5Hu6AXQk
Subject: [Dime] Fwd: New Version Notification for draft-donovan-dime-doc-rate-control-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 14:18:54 -0000

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

The referenced draft proposes an extension to Diameter overload to
support rate based control. 

Regards,

Steve

-------- Original Message --------
Subject: 	New Version Notification for
draft-donovan-dime-doc-rate-control-00.txt
Date: 	Fri, 14 Feb 2014 06:15:34 -0800
From: 	internet-drafts@ietf.org
To: 	Steve Donovan , Steve Donovan
, Eric Noel




A new version of I-D, draft-donovan-dime-doc-rate-control-00.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-dime-doc-rate-control
Revision:	00
Title:		Diameter Overload Rate Control
Document date:	2014-02-14
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-donovan-dime-doc-rate-control-00.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-doc-rate-control/
Htmlized:       http://tools.ietf.org/html/draft-donovan-dime-doc-rate-control-00


Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  This extension adds a new overload
   control algorithm.  This algorithm allows for a server to specify a
   maximum rate at which Diameter requests are sent to the server.

Requirements
                                                                                  


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

The IETF Secretariat





--------------020708070504040801060605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    The referenced draft
      proposes an extension to Diameter overload to support rate based
      control.  

      

      Regards,

      

      Steve

    
    


      -------- Original Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-donovan-dime-doc-rate-control-00.txt
          

          

            Date: 
            Fri, 14 Feb 2014 06:15:34 -0800
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Steve Donovan <srdonovan@usdonovans.com>, Steve
              Donovan <srdonovan@usdonovans.com>, Eric Noel
              <unknown-email-Eric-Noel@ietfa.amsl.com>
          

        
      

      

      

      
A new version of I-D, draft-donovan-dime-doc-rate-control-00.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-dime-doc-rate-control
Revision:	00
Title:		Diameter Overload Rate Control
Document date:	2014-02-14
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-donovan-dime-doc-rate-control-00.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-doc-rate-control/
Htmlized:       http://tools.ietf.org/html/draft-donovan-dime-doc-rate-control-00


Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  This extension adds a new overload
   control algorithm.  This algorithm allows for a server to specify a
   maximum rate at which Diameter requests are sent to the server.

Requirements
                                                                                  


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

The IETF Secretariat




      

    

    

  


--------------020708070504040801060605--


From nobody Fri Feb 14 06:46:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51621A028B for ; Fri, 14 Feb 2014 06:46:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcA9YyiC9-NM for ; Fri, 14 Feb 2014 06:46:49 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DF3E61A0262 for ; Fri, 14 Feb 2014 06:46:48 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 94593324172; Fri, 14 Feb 2014 15:46:46 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 70BF635C0AF; Fri, 14 Feb 2014 15:46:46 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 15:46:46 +0100
From: 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYIAAHLvQgAAuN4CAAYuNgIABjxoQgAAvXuA=
Date: Fri, 14 Feb 2014 14:46:45 +0000
Message-ID: <10158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XtqKMydiHN8BsAe9fPHklt82sYc
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 14:46:53 -0000

Hi,

I think that two points are mixed:

1) For efficiency, a DOIC-enabled client should be able to mitigate (possib=
le) overload situation even if explicit indication is not received from the=
 network.
2) DOIC-enabled clients having a different behavior regarding support or no=
t of DOIC by server.

if I agree with the first one, I disagree with the second one. The basic as=
sumption is that a DOIC client will not throttle the traffic in absence of =
overload indication (explicit or implicit). And throttling will be performe=
d as soon as an indication is received (explicit or implicit) if the client=
 is designed for that (it supports DOIC or/and default behavior has been de=
fined on reception of TOO_BUSY or non-response).

It is the only thing that matters today.

Regards,

Lionel

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 13:18
=C0=A0: ext Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es

Steve,
For my clarification:
Your proposal is to mark OC-Supported-Feature AVPs when inserted to answer =
messages by an agent?

If so, the reacting node can associate unmarked Supported-Features AVPs wit=
h the server (orig-host) and can discard marked Supported-Features AVPs.

Is that understanding correct?

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 13, 2014 2:01 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

This could be addressed by adding the requirement that an OC-Supported-Feat=
ures AVP AVP that is inserted by an agent be marked as such.

Steve
On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
The reacting node (when receiving OC-Supported-Features AVP in an answer) k=
nows that the corresponding request took a path towards the server on which=
 there is a reporting node (which supports DOIC). It does not know whether =
this reporting node is the server or an agent and it does not know whether =
subsequent requests will take the same path or a different path on which th=
ere may be no reporting node.=20
Consequently the presence of OC-Supported-Features AVP in an answer does no=
t tell you anything usefull on which to base behaviour for subsequent reque=
sts targeted to the same server.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:56 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting no=
de overload mitigation based on implicit indications (as described by TR), =
therefore any 3GPP application that will support new "Overload mitigation" =
feature (or whatever may be the name), shall improve its procedures with th=
is objective. It is expected as well, that this new 3GPP "Overload mitigati=
on" feature makes use of our DOIC, and then it is very beneficial that the =
reacting node could identify at any moment whether or not the reporting nod=
e supports DOIC, since procedures to be implemented could be potentially di=
fferent.

2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?=20
[MCruz] Reacting node receives reporting node Supported-Features. Regardles=
s the reporting node is either an agent or a server, in case the reacting n=
ode needs to treat "implicit indications" (like TOO_BUSY), expected reactio=
n may depend on whether or not reporting node supports DOIC. This informati=
on is very beneficial to determine the most appropriate reaction.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement=A0 in our 3GPP TR:

6.3.3=A0=A0=A0 Implicit Overload Indication
6.3.3.1=A0 Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
- DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
- Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

1) I want the reacting node to be able to learn if a (potentially)=20
reporting node supports DOIC, even when that node is not in overload.
I don't want to specify any particular behavior for that knowledge,=20
but I suspect implementations may want to treat DOIC compliant servers=20
in some way differently than they do non-DOIC servers. For example, I=20
might have a configured rate limit for non-DOIC peers, but use a=20
higher (or no) limit for peers that are known to support DOIC (and can=20
thus speak for themselves.) sounds like a new requirement;=20
where does it come from? I would have thought that there is no need to=20
distinguish between
a) DOIC not supported and therefore no traffic reduction requested,=20
and
b) DOIC supported, but not in overload and therefore no traffic=20
reduction requested


At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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



___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 14 06:59:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957041A02C5 for ; Fri, 14 Feb 2014 06:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIFFn1BYIvvL for ; Fri, 14 Feb 2014 06:59:25 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C4C911A0282 for ; Fri, 14 Feb 2014 06:59:24 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1EExL2A021464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 15:59:22 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1EExL9i031194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 15:59:21 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 15:59:21 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext lionel.morand@orange.com" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYIAAHLvQgAAuN4CAAYuNgIABjxoQgAAvXuCAAATecA==
Date: Fri, 14 Feb 2014 14:59:19 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net> <10158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <10158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.104]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 11028
X-purgate-ID: 151667::1392389962-00001A6F-671F5DDE/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/27yeJFkygZHQsjSk1McEOpqBy0c
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 14:59:28 -0000

Did you mean "while I agree with the first one ..."?

-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Sent: Friday, February 14, 2014 3:47 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

Hi,

I think that two points are mixed:

1) For efficiency, a DOIC-enabled client should be able to mitigate (possib=
le) overload situation even if explicit indication is not received from the=
 network.
2) DOIC-enabled clients having a different behavior regarding support or no=
t of DOIC by server.

if I agree with the first one, I disagree with the second one. The basic as=
sumption is that a DOIC client will not throttle the traffic in absence of =
overload indication (explicit or implicit). And throttling will be performe=
d as soon as an indication is received (explicit or implicit) if the client=
 is designed for that (it supports DOIC or/and default behavior has been de=
fined on reception of TOO_BUSY or non-response).

It is the only thing that matters today.

Regards,

Lionel

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 13:18
=C0=A0: ext Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es

Steve,
For my clarification:
Your proposal is to mark OC-Supported-Feature AVPs when inserted to answer =
messages by an agent?

If so, the reacting node can associate unmarked Supported-Features AVPs wit=
h the server (orig-host) and can discard marked Supported-Features AVPs.

Is that understanding correct?

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 13, 2014 2:01 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

This could be addressed by adding the requirement that an OC-Supported-Feat=
ures AVP AVP that is inserted by an agent be marked as such.

Steve
On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
The reacting node (when receiving OC-Supported-Features AVP in an answer) k=
nows that the corresponding request took a path towards the server on which=
 there is a reporting node (which supports DOIC). It does not know whether =
this reporting node is the server or an agent and it does not know whether =
subsequent requests will take the same path or a different path on which th=
ere may be no reporting node.=20
Consequently the presence of OC-Supported-Features AVP in an answer does no=
t tell you anything usefull on which to base behaviour for subsequent reque=
sts targeted to the same server.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:56 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting no=
de overload mitigation based on implicit indications (as described by TR), =
therefore any 3GPP application that will support new "Overload mitigation" =
feature (or whatever may be the name), shall improve its procedures with th=
is objective. It is expected as well, that this new 3GPP "Overload mitigati=
on" feature makes use of our DOIC, and then it is very beneficial that the =
reacting node could identify at any moment whether or not the reporting nod=
e supports DOIC, since procedures to be implemented could be potentially di=
fferent.

2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?=20
[MCruz] Reacting node receives reporting node Supported-Features. Regardles=
s the reporting node is either an agent or a server, in case the reacting n=
ode needs to treat "implicit indications" (like TOO_BUSY), expected reactio=
n may depend on whether or not reporting node supports DOIC. This informati=
on is very beneficial to determine the most appropriate reaction.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement=A0 in our 3GPP TR:

6.3.3=A0=A0=A0 Implicit Overload Indication
6.3.3.1=A0 Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
- DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
- Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

1) I want the reacting node to be able to learn if a (potentially)=20
reporting node supports DOIC, even when that node is not in overload.
I don't want to specify any particular behavior for that knowledge,=20
but I suspect implementations may want to treat DOIC compliant servers=20
in some way differently than they do non-DOIC servers. For example, I=20
might have a configured rate limit for non-DOIC peers, but use a=20
higher (or no) limit for peers that are known to support DOIC (and can=20
thus speak for themselves.) sounds like a new requirement;=20
where does it come from? I would have thought that there is no need to=20
distinguish between
a) DOIC not supported and therefore no traffic reduction requested,=20
and
b) DOIC supported, but not in overload and therefore no traffic=20
reduction requested


At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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



___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 14 07:17:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACFC1A02A7 for ; Fri, 14 Feb 2014 07:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBUjaYgQHBhm for ; Fri, 14 Feb 2014 07:17:19 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D74561A028F for ; Fri, 14 Feb 2014 07:17:17 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E53F822C4CA; Fri, 14 Feb 2014 16:17:15 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BD6E423807D; Fri, 14 Feb 2014 16:17:15 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 16:17:15 +0100
From: 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYIAAHLvQgAAuN4CAAYuNgIABjxoQgAAvXuCAAATecIAABcaQ
Date: Fri, 14 Feb 2014 15:17:14 +0000
Message-ID: <27859_1392391035_52FE337B_27859_566_1_6B7134B31289DC4FAF731D844122B36E4A3BB9@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net> <10158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iusgBy1QpiBmWkILYDmvIT0Fk4o
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 15:17:24 -0000

Yes! :)

-----Message d'origine-----
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 15:59
=C0=A0: MORAND Lionel IMT/OLN; ext Steve Donovan; dime@ietf.org
Objet=A0: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es

Did you mean "while I agree with the first one ..."?

-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Sent: Friday, February 14, 2014 3:47 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Hi,

I think that two points are mixed:

1) For efficiency, a DOIC-enabled client should be able to mitigate (possib=
le) overload situation even if explicit indication is not received from the=
 network.
2) DOIC-enabled clients having a different behavior regarding support or no=
t of DOIC by server.

if I agree with the first one, I disagree with the second one. The basic as=
sumption is that a DOIC client will not throttle the traffic in absence of =
overload indication (explicit or implicit). And throttling will be performe=
d as soon as an indication is received (explicit or implicit) if the client=
 is designed for that (it supports DOIC or/and default behavior has been de=
fined on reception of TOO_BUSY or non-response).

It is the only thing that matters today.

Regards,

Lionel

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 13:18
=C0=A0: ext Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es

Steve,
For my clarification:
Your proposal is to mark OC-Supported-Feature AVPs when inserted to answer =
messages by an agent?

If so, the reacting node can associate unmarked Supported-Features AVPs wit=
h the server (orig-host) and can discard marked Supported-Features AVPs.

Is that understanding correct?

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 13, 2014 2:01 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

This could be addressed by adding the requirement that an OC-Supported-Feat=
ures AVP AVP that is inserted by an agent be marked as such.

Steve
On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
The reacting node (when receiving OC-Supported-Features AVP in an answer) k=
nows that the corresponding request took a path towards the server on which=
 there is a reporting node (which supports DOIC). It does not know whether =
this reporting node is the server or an agent and it does not know whether =
subsequent requests will take the same path or a different path on which th=
ere may be no reporting node.=20
Consequently the presence of OC-Supported-Features AVP in an answer does no=
t tell you anything usefull on which to base behaviour for subsequent reque=
sts targeted to the same server.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:56 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting no=
de overload mitigation based on implicit indications (as described by TR), =
therefore any 3GPP application that will support new "Overload mitigation" =
feature (or whatever may be the name), shall improve its procedures with th=
is objective. It is expected as well, that this new 3GPP "Overload mitigati=
on" feature makes use of our DOIC, and then it is very beneficial that the =
reacting node could identify at any moment whether or not the reporting nod=
e supports DOIC, since procedures to be implemented could be potentially di=
fferent.

2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?=20
[MCruz] Reacting node receives reporting node Supported-Features. Regardles=
s the reporting node is either an agent or a server, in case the reacting n=
ode needs to treat "implicit indications" (like TOO_BUSY), expected reactio=
n may depend on whether or not reporting node supports DOIC. This informati=
on is very beneficial to determine the most appropriate reaction.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement=A0 in our 3GPP TR:

6.3.3=A0=A0=A0 Implicit Overload Indication
6.3.3.1=A0 Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
- DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
- Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

1) I want the reacting node to be able to learn if a (potentially)=20
reporting node supports DOIC, even when that node is not in overload.
I don't want to specify any particular behavior for that knowledge,=20
but I suspect implementations may want to treat DOIC compliant servers=20
in some way differently than they do non-DOIC servers. For example, I=20
might have a configured rate limit for non-DOIC peers, but use a=20
higher (or no) limit for peers that are known to support DOIC (and can=20
thus speak for themselves.) sounds like a new requirement;=20
where does it come from? I would have thought that there is no need to=20
distinguish between
a) DOIC not supported and therefore no traffic reduction requested,=20
and
b) DOIC supported, but not in overload and therefore no traffic=20
reduction requested


At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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



___________________________________________________________________________=
______________________________________________

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.


From nobody Fri Feb 14 07:23:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2DA1A0274 for ; Fri, 14 Feb 2014 07:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WfwremI2YTl for ; Fri, 14 Feb 2014 07:23:51 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7761A0293 for ; Fri, 14 Feb 2014 07:23:50 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1EFNlGj029059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 16:23:47 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1EFNkBV023993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 16:23:47 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 16:23:46 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext lionel.morand@orange.com" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPI+wAa0SZ1wdbvEGvoj4P8RAtnpquWNQA///zv4CAAAOJAIAAOu8AgACYz4CAAQwyUP//+rWAgABZnNCAAMPUYIAAHLvQgAAuN4CAAYuNgIABjxoQgAAvXuCAAATecIAABcaQgAAA03A=
Date: Fri, 14 Feb 2014 15:23:46 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B35EC@DEMUMBX014.nsn-intra.net>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net> <10158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net> <27859_1392391035_52FE337B_27859_566_1_6B7134B31289DC4FAF731D844122B36E4A3BB9@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <27859_1392391035_52FE337B_27859_566_1_6B7134B31289DC4FAF731D844122B36E4A3BB9@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.157]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 12672
X-purgate-ID: 151667::1392391428-00001A6F-68AB921E/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BMGsKq-R2Mo6vhgLMG6w_uI-UVA
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 15:23:56 -0000

I agree

-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Sent: Friday, February 14, 2014 4:17 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

Yes! :)

-----Message d'origine-----
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 15:59
=C0=A0: MORAND Lionel IMT/OLN; ext Steve Donovan; dime@ietf.org
Objet=A0: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es

Did you mean "while I agree with the first one ..."?

-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Sent: Friday, February 14, 2014 3:47 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

Hi,

I think that two points are mixed:

1) For efficiency, a DOIC-enabled client should be able to mitigate (possib=
le) overload situation even if explicit indication is not received from the=
 network.
2) DOIC-enabled clients having a different behavior regarding support or no=
t of DOIC by server.

if I agree with the first one, I disagree with the second one. The basic as=
sumption is that a DOIC client will not throttle the traffic in absence of =
overload indication (explicit or implicit). And throttling will be performe=
d as soon as an indication is received (explicit or implicit) if the client=
 is designed for that (it supports DOIC or/and default behavior has been de=
fined on reception of TOO_BUSY or non-response).

It is the only thing that matters today.

Regards,

Lionel

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 13:18
=C0=A0: ext Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es

Steve,
For my clarification:
Your proposal is to mark OC-Supported-Feature AVPs when inserted to answer =
messages by an agent?

If so, the reacting node can associate unmarked Supported-Features AVPs wit=
h the server (orig-host) and can discard marked Supported-Features AVPs.

Is that understanding correct?

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Thursday, February 13, 2014 2:01 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

This could be addressed by adding the requirement that an OC-Supported-Feat=
ures AVP AVP that is inserted by an agent be marked as such.

Steve
On 2/12/14 6:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
The reacting node (when receiving OC-Supported-Features AVP in an answer) k=
nows that the corresponding request took a path towards the server on which=
 there is a reporting node (which supports DOIC). It does not know whether =
this reporting node is the server or an agent and it does not know whether =
subsequent requests will take the same path or a different path on which th=
ere may be no reporting node.=20
Consequently the presence of OC-Supported-Features AVP in an answer does no=
t tell you anything usefull on which to base behaviour for subsequent reque=
sts targeted to the same server.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:56 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and =
without piggybacked OLR or Lack of response) should be taken into account b=
y reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting no=
de overload mitigation based on implicit indications (as described by TR), =
therefore any 3GPP application that will support new "Overload mitigation" =
feature (or whatever may be the name), shall improve its procedures with th=
is objective. It is expected as well, that this new 3GPP "Overload mitigati=
on" feature makes use of our DOIC, and then it is very beneficial that the =
reacting node could identify at any moment whether or not the reporting nod=
e supports DOIC, since procedures to be implemented could be potentially di=
fferent.

2. How would the reacting node know whether the OC-Supported-Features AVP r=
eceived in an answer indicates the features supported by the server (identi=
fied by the origin-host received in the answer) or the features supported b=
y an agent on the path?=20
[MCruz] Reacting node receives reporting node Supported-Features. Regardles=
s the reporting node is either an agent or a server, in case the reacting n=
ode needs to treat "implicit indications" (like TOO_BUSY), expected reactio=
n may depend on whether or not reporting node supports DOIC. This informati=
on is very beneficial to determine the most appropriate reaction.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 11, 2014 9:21 PM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for th=
e reacting node to know whether or not a server supports DOIC, since the re=
acting node should be able to mitigate this server overload as well when th=
is server does not support DOIC.

In fact, we have already included this as a requirement=A0 in our 3GPP TR:

6.3.3=A0=A0=A0 Implicit Overload Indication
6.3.3.1=A0 Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of impl=
icit indications and the inadequacy of this approach for large, diverse net=
works.
However, a Diameter client may receive some overload indications as defined=
 in Diameter base specification IETF RFC 6733 [2] and then it is recommende=
d that the client uses them to mitigate overload situation. This may happen=
 even if involved server and client support the new CN Overload mechanism u=
nder definition, but client handling of such indications is even more impor=
tant when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
- DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the rec=
eipt of a protocol error DIAMETER_TOO_BUSY response should affect future Di=
ameter messages in any way, then it may be relevant for some applications t=
o define the behavior that best mitigate the overload situation, taking int=
o account application specifics, operator deployments.... For example, MME =
may implement a mitigation procedure based on the rate of received DIAMETER=
_TOO_BUSY protocol error from HSS.
- Lack of response:
In case of overload the server may react dropping the requests without any =
Diameter error message being returned, what may imply retransmissions in th=
e client side, negatively impacting overload. Therefore, for each applicati=
on, it should be analyzed how to mitigate overload in this situation. For e=
xample, the client may consider avoiding retransmissions when a number of m=
essages have not been answered.



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer message=
s


On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

1) I want the reacting node to be able to learn if a (potentially)=20
reporting node supports DOIC, even when that node is not in overload.
I don't want to specify any particular behavior for that knowledge,=20
but I suspect implementations may want to treat DOIC compliant servers=20
in some way differently than they do non-DOIC servers. For example, I=20
might have a configured rate limit for non-DOIC peers, but use a=20
higher (or no) limit for peers that are known to support DOIC (and can=20
thus speak for themselves.) sounds like a new requirement;=20
where does it come from? I would have thought that there is no need to=20
distinguish between
a) DOIC not supported and therefore no traffic reduction requested,=20
and
b) DOIC supported, but not in overload and therefore no traffic=20
reduction requested


At one point, I thought we agreed as a group that a reacting node should be=
 able to identify if a (potential) reporting node supported the mechanism. =
But in any case, we have a requirement that the mechanism must work in a mi=
xed environment, where some nodes support it and some don't. It's much _eas=
ier_ to meet that requirement if we can tell what nodes support it and what=
 don't.=20

In general, a reacting node can assume that a server that supports DOIC, bu=
t hasn't reported overload is not overloaded. It can make no such assumptio=
n about a server that doesn't support DOIC. If it does not know the differe=
nce between a non-overloaded server and a non-supporting server, it must as=
sume all such servers are non-supporting. It ends up simply knowing that so=
me servers _are_ overloaded, and some other servers _might_be_ overloaded.

_______________________________________________
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



___________________________________________________________________________=
______________________________________________

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.


From nobody Fri Feb 14 07:53:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343971A02BA for ; Fri, 14 Feb 2014 07:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ2r79qEasUs for ; Fri, 14 Feb 2014 07:53:25 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 60A991A025E for ; Fri, 14 Feb 2014 07:53:24 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id CF1233B44DC; Fri, 14 Feb 2014 16:53:21 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B26B43840E2; Fri, 14 Feb 2014 16:53:21 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 16:53:21 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE88aqIYhHfy6k2vf6t9AbBIc5quSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8ICAABIAAIAAoHoQgADRmYCAAGkdsA==
Date: Fri, 14 Feb 2014 15:53:21 +0000
Message-ID: <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jiuGmfer7trkZMssmORfXR_gf9w
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 15:53:29 -0000

Hi,

I'm ok for the following cases:

-	0 reduction, non-zero validity period =3D> Valid (taking into account Ulr=
ich's comment).=20

-	0 reduction, 0 validity period =3D> Valid as well. Generally, this is wha=
t the reporting node will use to indicate the end of overload condition.

However, I have a comment on this one:

-	Non-zero reduction, 0 validity period =3D> Valid. The reacting node can i=
gnore the reduction if validity period is 0.

If we are OK with the first one (R=3D0, V>=3D0), I think that the case abov=
e should be considered as invalid because there is NO reason to send a redu=
ction that will not be stored by the reacting node. The received OLR should=
 be discarded and the running OLR state should not be updated. We can't eve=
n say here that the validity time prevails on the reduction as there is no =
way to appraise the consistency of the information.

In other words, I think that we should have the following cases:

-	non-zero reduction, non-zero validity period =3D> Valid
-	0 reduction, non-zero validity period =3D> Valid (not blocking)
-	0 reduction, 0 validity period =3D> Valid
-	non-zero reduction, 0 validity period =3D> Invalid

Does it make sense?

Lionel

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 11:20
=C0=A0: dime@ietf.org list
Objet=A0: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hello Jean-Jacques,

I understand your concerns.
However, I think same precautions in the process to return back to a situat=
ion where throttling is not requested, can be achieved without allowing "0%=
".=20
On one hand, DOIC-enabled reporting node should supervise constantly how re=
ceived =A0traffic is affecting its overload, in order to be able to request=
 a reduction when required. It should not only be done during the new Valid=
ityDuration when 0% was requested.
A part from that, gradual increase of allowed traffic is always possible (w=
ithout 0%), since even reporting node could use 10%... 5%, 3%, 1%.

However, I do not think this subject is critical. 0% could be acceptable by=
 me if you (all) still think this is preferable.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: viernes, 14 de febrero de 2014 9:46
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hi MCruz, Steve

I here =A0answer Steve and MCruz mails

About Steve, I have not said the reporting "needs" to send a 0% reduction v=
alid
( it is an implementation choice of the reporting node to choose the % valu=
es it puts in OLR), I simply says =A0to not forbid it.

In an overload condition, a behavior example is that the reporting , by its=
 own logic (not standardised) , determines the % reduction =A0value it send=
 in OLRs, and then will observe the effect of this OLR in the evolution of =
the received =A0traffic that =A0the reacting has throttled. Reporting will =
then decides to keep, increase or decrease the OLR %value .When we come to =
the end of overload, the reporting still receiving throttled traffic, will =
consider that it does =A0not more need to request a % reduction.
- One way is to send an OLR with validity period to 0 to indicate the end o=
f the overload condition, but it does this without having yet received unth=
rottled =A0traffic that in some case may nevertheless =A0request to immedia=
tely send again an OLR requesting reduction, meaning that reporting, having=
 terminated =A0an overload condition, will =A0immediately restart another o=
ne. This a way to proceed as Steve described , I do not say it does not work
- The way I describe is that =A0reporting =A0sends a 0% value to see the ef=
fect of this new value on the traffic it will receive (that will be unthrot=
tled), before concluding =A0to the end of the overload , and if nevertheles=
s the received unthrottled =A0traffic still require to send =A0OLRs, =A0rep=
orting will not conclude to the end of overload condition =A0and again gene=
rate OLRs with a non zero % value.=20

On the reacting, if it receives a 0% value, it simply does nothing,=20

I remind =A0I agree with the proposal =A0that the end of the Overlaod condi=
tion is determined by the Value 0 of the Validity period , or the end of th=
e =A0expiry timer, but is not linked to the 0% =A0traffic reduction =A0

Developers, have various possibilities in the =A0way =A0=A0to manage the =
=A0overload condition =A0and the OLRS they send, I think that DOIC should l=
eave flexibility.

Best regards

JJacques =A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: jeudi 13 f=E9vrier 2014 13:16
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

JJ,

Why does the reacting node need to send a reduction percentage of zero to d=
etermine if it is stable?=A0 Can't the reacting node just do its normal che=
cking for overload after sending the validity period of zero?=A0 If it find=
s the need for reduction of traffic, it can just send a new overload report.

Steve
On 2/13/14 4:43 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi MCruz
=A0
AS =A0Ben proposed, and I agree, =A0=A0value of zero (0) for the Validity p=
eriod indicates that an existing overload condition has ended and that the =
reporting node is in a stable condition.
An important word is "stable".
=A0
When the traffic peak on client side having created the overload decreases,=
 =A0=A0the reporting node progressively diminishes the % traffic reduction =
in OLRs it sends =A0towards clients taking care to minimize the possible os=
cillations. At a certain time , =A0server will consider that it can indicat=
e no traffic reduction to clients. Then is it stable? =A0there may be diffe=
rent implementation dependent =A0ways for the server to decide the situatio=
n is stable; =A0one is to send 0% in OLRs and wait a certain number of seco=
nds (not 24 hours) to check if situation is stable =A0and then put the vali=
dity timer to 0 (or leaves the expiry timer =A0expire). I do not see why to=
 forbid this =A0way to test the stable condition.
=A0
So the end of overload condition, as Ben proposed, =A0can remain ONLY based=
 on Validity =A0duration value 0 (or timer expiry), not on the value 0 of t=
he % reduction (so a bit different from Nirav statement, but in line with U=
lrich comment) . The value 0% of the traffic reduction is not forbidden as =
a possible =A0way to check the stability condition .
=A0
Best regards=20
=A0
JJacques
=A0
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: jeudi 13 f=E9vrier 2014 10:56
=C0=A0: dime@ietf.org list
Objet=A0: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
Hello all,
=A0
I think proposal to use just Validity-Duration=3D0 to end overload mainly h=
as the intention to simplify and avoid the checks you just listed below.
If we allow both, it means that the case Ulrich mentioned is valid, and eve=
n with 0% reduction OLR info cannot be deleted until Validity time expires,=
 even we could receive a new OLR in sequence. Even, the reporting needs sti=
ll to keep Validity timer on for this OLR.
I think this does not provide any added value but simply makes things a bit=
 more complex. What could be the reason to keep 0% reduction but a Validity=
 of a few hours (e.g.)?
=A0
Best regards
/MCruz
=A0
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: jueves, 13 de febrero de 2014 10:24
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
I am OK with Ulrich
=A0
JJacques
=A0
=A0
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Envoy=E9=A0: jeudi 13 f=E9vrier 2014 09:56
=C0=A0: ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dim=
e@ietf.org list
Objet=A0: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
I also agree with the principle.
=A0
One minor clarification:
0%-reduction with non-zero validity period is valid but validity period can=
not be ignored: as long as not expired the sequence number needs to be stor=
ed for future checking; once expired, sequence number must not be used for =
future checking.
=A0
Ulrich
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa=
lot)
Sent: Thursday, February 13, 2014 4:11 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduc=
tion - which can also indicate end of overload condition.
=A0
May be we can clarify that 0% reduction and/or 0 validity period indicates =
end of overload. In my view, both are valid for the use, individually and t=
ogether. So,
- 0 reduction, non-zero validity period =3D> Valid. The reacting node can i=
gnore the validity period if reduction is 0.
- Non-zero reduction, 0 validity period =3D> Valid. The reacting node can i=
gnore the reduction if validity period is 0.
- 0 reduction, 0 validity period =3D> Valid as well. Generally, this is wha=
t the reporting node will use to indicate the end of overload condition.=20
=A0
Regards,
Nirav.
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
Dear all=20
=A0
On this ticket, =A0I agree on Ben's =A0proposal =A0to use the Validity peri=
od of 0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?
=A0
In the process to =A0return to normal traffic conditions, the =A0server sti=
ll sending OLR eg with =A05% reduction =A0=A0=A0will consider to no request=
 anymore traffic reduction but without being yet sure if =A0it will be =A0s=
table (end of overload condition as Ben reminded means stable =A0situation =
without traffic reduction ) , so server =A0can send 0% reduction OLR=A0 but=
 with a validity duration different from 0.=20
Otherwise it has to =A0use 1% throttling to check stability and if traffic =
with the client is 1000 request per second this means 10 requests throttled=
 per second which should not be throttled.
In addition, we do not need to handle the 0% reduction =A0as an error case =
(cf Mcruz mail)
=A0
Best regards
=A0
JJacques=20
=A0
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: mercredi 12 f=E9vrier 2014 10:22
=C0=A0: ext Maria Cruz Bartolome; dime@ietf.org list
Objet=A0: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
Thank you for the clarification.
I agree.
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
Dear Ulrich, all,
=A0
The proposal was to use OC-Validity-Duration AVP =3D0 to indicate end of ov=
erload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage =3D 0 should be considered as invalid.
I found this reasonable.
=A0
Best regards
/MCruz
=A0
=A0
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: mi=E9rcoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
I'm confused,
=A0
I thought that people were in favour of allowing 0 to indicate end of overl=
oad.
=A0
Ulrich
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
Ben, all,
=A0
This comment affects as well clause 5.5.2:
=A0
=A0=A0 value =3D=3D 0
=A0
=A0=A0=A0=A0=A0 Indicates explicitly the end of overload condition and the
=A0=A0=A0=A0=A0 reacting node SHOULD NOT apply the traffic abatement algori=
thm
=A0=A0 =A0=A0=A0procedures anymore for the given reporting node (or realm).
=A0
This should be modified to explain this value is not valid and what is the =
expected behavior (i.e. it is discarded).
=A0
Best regards
/MCruz
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
Ben,
=A0
This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Perc=
entage=3D0 is received. This is an invalid value, then I presume it should =
be discarded by client.=20
=A0
Regards
/MCruz
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
So, here's some proposed text. (intentionally ignoring the related discussi=
on about handling invalid values):
=A0
Section 4.5, first paragraph, last 2 sentences:
=A0
Old:
=A0
Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hour=
s) MUST NOT be used. Invalid validity duration values are treated as if the=
 OC-Validity-Duration AVP were not present.
=A0
New:
=A0
Validity duration values above 86400 MUST NOT be used. Invalid validity dur=
ation values are treated as if the OC-Validity-Duration AVP were not presen=
t. A value of zero (0) indicates that an existing overload condition has en=
ded and that the reporting node is in a stable condition.
=A0
Section 4.7, 2nd paragraph:
=A0
Old:
=A0
=A0The value of the Reduction-Percentage AVP is between one (1) and one hun=
dred (100). =A0Values greater than 100 are interpreted as 100. =A0The value=
 of 100 means that no traffic is expected, i.e. the reporting node is under=
 a severe load and ceases to process any new messages. The Reduction-Percen=
tage AVP MUST be present in an overload report that uses the default abatem=
ent algorithm.
=A0
Note that there is no zero (0) value defined for the Reduction-Percentage A=
VP. A zero value would logically indicate that no overload abatement is req=
uested. Instead, reporting nodes use a OC-Validity-Duration AVP value of ze=
ro (0) to indicate the end of an overload condition. [Section 4.5]
=A0
=A0
=A0
=A0
=A0

On Feb 10, 2014, at 4:12 PM, Jouni Korhonen  wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell  wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen  wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker  wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons:

1) It's algorithm independent. (reduction-percentage of 0 is specific to al=
gorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantica=
lly identical to the expiration of an overload=A0condition. This allows a s=
impler implementation.
=A0
=A0

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

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


___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 14 07:59:29 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941B11A02D3 for ; Fri, 14 Feb 2014 07:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYp7i1KkXESv for ; Fri, 14 Feb 2014 07:59:12 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id C9D611A0270 for ; Fri, 14 Feb 2014 07:59:07 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 8F8C1C07DC; Fri, 14 Feb 2014 16:59:05 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6EE8E158074; Fri, 14 Feb 2014 16:59:05 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 16:59:05 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime]	[dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
Thread-Index: AQHPKLbE07qhhbGvPUaTK20cvjaLSpq06ehg
Date: Fri, 14 Feb 2014 15:59:04 +0000
Message-ID: <20943_1392393545_52FE3D49_20943_19289_1_6B7134B31289DC4FAF731D844122B36E4A3EC7@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com>
In-Reply-To: <52FCB9D6.3070908@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4A3EC7PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.113015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/E5Uo1sYRkstHZHn785AoQ2H4OFE
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 15:59:20 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4A3EC7PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree.

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 13 f=E9vrier 2014 13:26
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR

Jouni,

The important thing is to define the properties.  There should be no harm i=
n giving one suggested implementation.

Steve
On 2/11/14 4:42 PM, Jouni Korhonen wrote:



If the NTP is only going to be guidance when building the globally

and eternally unique sequence number, IMHO better not mention NTP

then at all. Just include the required properties below. One less

mandatory reference..



- Jouni





On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome  wrote:



It sounds reasonable to me as well.

/MCruz



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

Sent: lunes, 10 de febrero de 2014 14:59

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



+1

On 2/10/14 7:47 AM, lionel.morand@orange.com wrote:

I would add, maybe even before the format (NTP time based), that the real r=
equirements for the sequence-number are:



- Globally/eternally unique

- increase monotonically over time, including over a reboot (as remind by S=
teve)



The NTP time based type is just a guidance provided by the draft on how to =
generate sequence numbers with such properties.



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen

Envoy=E9 : samedi 8 f=E9vrier 2014 11:33

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR





Sounds acceptable. Would the following then work for all:



o clarify that once the overload report expires there is no

  reason to remember anything about it

o the sequence number would be similar to session-id.. based

  on the NTP time + any vendor specific data to make it

  "globally and eternally unique".



- Jouni







On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Steve,



sounds like an acceptable proposal which allows to come back to sync after =
OLR expiry.

This requires however an update of clause 5.5.2 to clearly state

Once the overload report expires there is no reason to remember anything ab=
out it and the next overload report received could, conceivably have any va=
lue.





Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Thursday, February 06, 2014 4:50 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



A couple of things -



The requirement is that the sequence number increase monotonically over tim=
e, including over a reboot.  Use of NTP time is one way of doing this but i=
s not the only way.  Someone could, for instance, use a time stamp to set t=
he sequence number for the first overload report sent after a reboot and th=
en increment the sequence number value by one for each subsequent overload =
report sent.  This actually has better properties than an NTP time stamp as=
 it would take much longer to roll over.  One could also create a global se=
quence number service that is not tied to time and have a Diameter server q=
uery that global sequence number server after each reboot.



We also have a duration timer on overload reports.  This gives us one way t=
o reset.  It should only be required to remember the sequence number of an =
active overload report.  Once the overload report expires there is no reaso=
n to remember anything about it and the next overload report received could=
, conceivably have any value.



The requirement we need is similar to the session-id in the base Diameter s=
pecification.  The wording there is -- "The Session-Id MUST be globally and=
 eternally unique".  We just need eternally as the spacial differentiation =
is based on the context of the message carrying the overload report.



It would be perfectly valid for the DOIC draft to suggest the use of NTP ti=
mestamps to populate the sequence number but it should be worded in a simil=
ar fashion as the Diameter base RFC -- The Session-Id includes a mandatory =
portion and an implementation-defined portion; a recommended format for the=
 implementation-defined portion is outlined below ..."



Steve



On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I cannot understand what is the problem with mandating timestamp.

But I can see interoperability problems with the current definition:



Assume the sender sends sequence numbers

1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....

but the receicer for any reason receives

1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....

The receiver would accept

1, 1, ... 1, 2, 2, ... 2, 3, 30000

and then silently discards

3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....

with no way to come back to sync.



Are we sure that this cannot happen?



Mandating timestamp for sequence number generation at the sender and plausi=
bility checking (i.e. received value must be between stored value and time =
of reception) for the receiver may not be the only way to solve the problem=
. But in the moment I don't see another way.



Ulrich





-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell

Sent: Wednesday, February 05, 2014 4:57 PM

To: ext lionel.morand@orange.com

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



My point is, we have an interop requirement that the sequence number always=
 increases over time scope. We do not have the interop requirement that the=
 sequence number be implemented as a time stamp. A time stamp is probably a=
 good way to  meet the interop requirements, but it is not, in itself, an i=
nterop requirement.



On Feb 5, 2014, at 9:53 AM,   wr=
ote:



Not sure to understand: if there is a kind of "interop requirement", it is =
a case for a "MUST".

We are not violating anything.



Reporting and reacting nodes will just rely on the Diameter interfaces to k=
now how to handle the received sequence-number. So any MUST on the format o=
f the sequence-number is acceptable if it avoids interop issues.



-----Message d'origine-----

De : Ben Campbell [mailto:ben@nostrum.com]

Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47

=C0 : MORAND Lionel IMT/OLN

Cc : Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR



I concur with Steve on this one. Using a time stamp is a good way to meet t=
he requirements, but it's not our job to normatively state an implementatio=
n. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Sect=
ion 6 of 2119 includes the following:



"In particular, [normative requirements] MUST only be used where it is

  actually required for interoperation or to limit behavior which has

  potential for causing harm (e.g., limiting retransmisssions)  "



The only appropriate reason to require a timestamp would be if we expected =
peers to interpret the field as a point in time. OTOH, it would be perfectl=
y reasonable to state the actual interop requirements, then add a non-norma=
tive (probably indented) paragraph suggesting that a timestamp is a good wa=
y to do this.



On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:



I think the out-of-sync failover described by Ulrich is a good use case to =
mandate a specific semantic.



Is there any specific NOT to mandate the use of NTP timestamps if it is a s=
imple way to solve the possible issues and please everyone?



Lionel



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR



How the sequence number is implemented is an implementation decision.  Ther=
e is no reason to mandate that is be an NTP timestamp.  That should be incl=
uded only as one way of addressing the requirement.



Steve



On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:

I also agree.



Regards,

Nirav.



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange=
.com

Sent: Tuesday, February 04, 2014 11:50 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



The existing wording seems actually fuzzy.

If it is "like an NTP timestamp", be proud and say it loud!



In summary: ok with the proposal if it clarifies this handling of this sequ=
ence-number.



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:50

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR



#32: Sequence-Number Time-Stamp values within OC-OLR



The -01 draft says in clause 4.4:

   From the functionality point of view, the OC-Sequence-Number AVP MUST

   be used as a non-volatile increasing counter between two overload

   control endpoints (neglecting the fact that the contents of the AVP

   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only

   required to be unique between two overload control endpoints.

   Sequence numbers are treated in uni-directional manner, i.e. two

   sequence numbers on each direction between two endpoints are not

   related or correlated.



   When generating sequence numbers, the new sequence number MUST be

   greater than any sequence number previously seen between two

   endpoints within a time window that tolerates the wraparound of the

   NTP timestamp (i.e. approximately 68 years).





With this mechanism it is difficult to get back to sync once you are out  o=
f sync (for whatever reason).

It is proposed to mandate that the Sequence Number is a real 64-bit NTP  ti=
mestamp (RFC5905) indicating the point in time when the OLR was created,  a=
nd to mandate that  OLRs with a time stamp higher than time of reception  m=
ust be ignored by the reacting node.





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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



_______________________________________________

DiME mailing list

DiME@ietf.org

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4A3EC7PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I agree.


 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : jeudi 13 f=E9vrier 2014 13:26

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp value=
s within OC-OLR






 


Jouni,



The important thing is to define the properties.  There should be no h=
arm in giving one suggested implementation.



Steve




On 2/11/14 4:42 PM, Jouni Korhonen wrote:=







 


If the NTP is only going to be guidance when building the globally


and eternally unique sequence number, IMHO better not mention NTP=



then at all. Just include the required properties below. One less=



mandatory reference..


 


- Jouni


 


 


On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>=
 wrote:


 




It sounds reasonable to me as well.


/MCruz


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Steve Donovan


Sent: lunes, 10 de febrero de 2014 14:59


To: dime@ietf.org


Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


+1


On 2/10/14 7:47 AM, lionel=
.morand@orange.com wrote:


I would add, maybe even before the format (NTP time based), that the r=
eal requirements for the sequence-number are:


 


- Globally/eternally unique


- increase monotonically over time, including over a reboot (as remind=
 by Steve) 


 


The NTP time based type is just a guidance provided by the draft on ho=
w to generate sequence numbers with such properties.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Jouni Korhonen


Envoy=E9 : samedi 8 f=E9vrier 2014 11:33


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


 


Sounds acceptable. Would the following then work for all:

 


o clarify that once the overload report expires there is no=



  reason to remember anything about it


o the sequence number would be similar to session-id.. based 


  on the NTP time + any vendor specific data to make it =



  "globally and eternally unique".


 


- Jouni


 


 


 


On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 


Steve,


 


sounds like an acceptable proposal which allows to come back to sync a=
fter OLR expiry.


This requires however an update of clause 5.5.2 to clearly state<=
/o:p>


Once the overload report expires there is no reason to remember anythi=
ng about it and the next overload report received could, conceivably have a=
ny value. 


 


 


Ulrich


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Thursday, February 06, 2014 4:50 PM


To: dime@ietf.org


Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


A couple of things - 


 


The requirement is that the sequence number increase monotonically ove=
r time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time=
 stamp to set the sequence number for the first overload report sent after =
a reboot and then increment the sequence number value by one for each subse=
quent overload report sent.  This actually has better properties than =
an NTP time stamp as it would take much longer to roll over.  One coul=
d also create a global sequence number service that is not tied to time and=
 have a Diameter server query that global sequence number server after each=
 reboot.


 


We also have a duration timer on overload reports.  This gives us=
 one way to reset.  It should only be required to remember the sequenc=
e number of an active overload report.  Once the overload report expir=
es there is no reason to remember anything about it and the next overload r=
eport received could, conceivably have any value. 


 


The requirement we need is similar to the session-id in the base Diame=
ter specification.  The wording there is -- "The Session-Id MUST =
be globally and eternally unique".  We just need eternally as the=
 spacial differentiation is based on the context of the message carrying th=
e overload report.


 


It would be perfectly valid for the DOIC draft to suggest the use of N=
TP timestamps to populate the sequence number but it should be worded in a =
similar fashion as the Diameter base RFC -- The Session-Id includes a manda=
tory portion and an implementation-defined portion; a recommended format fo=
r the implementation-defined portion is outlined below ..."=



 


Steve


 


On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I cannot understand what is the problem with mandating timestamp.=



But I can see interoperability problems with the current definition:


 


Assume the sender sends sequence numbers


1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 


but the receicer for any reason receives 


1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,...=
. 


The receiver would accept


1, 1, ... 1, 2, 2, ... 2, 3, 30000


and then silently discards


3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 


with no way to come back to sync.


 


Are we sure that this cannot happen?


 


Mandating timestamp for sequence number generation at the sender and p=
lausibility checking (i.e. received value must be between stored value and =
time of reception) for the receiver may not be the only way to solve the pr=
oblem. But in the moment I don't see another way.


 


Ulrich


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Ben Campbell


Sent: Wednesday, February 05, 2014 4:57 PM


To: ext lionel.morand@oran=
ge.com


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


My point is, we have an interop requirement that the sequence number a=
lways increases over time scope. We do not have the interop requirement tha=
t the sequence number be implemented as a time stamp. A time stamp is proba=
bly a good way to  meet the interop requirements, but it is not, in it=
self, an interop requirement.


 


On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:


 


Not sure to understand: if there is a kind of "interop requiremen=
t", it is a case for a "MUST".


We are not violating anything.


 


Reporting and reacting nodes will just rely on the Diameter interfaces=
 to know how to handle the received sequence-number. So any MUST on the for=
mat of the sequence-number is acceptable if it avoids interop issues.<=
/o:p>


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] 


Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47


=C0 : MORAND Lionel IMT/OLN


Cc : Steve Donovan; dime@ietf.org=



Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


I concur with Steve on this one. Using a time stamp is a good way to m=
eet the requirements, but it's not our job to normatively state an implemen=
tation. In fact, it violates an RFC 2119 "MUST" level requirement=
 to do so. Section 6 of 2119 includes the following:


 


"In particular, [normative requirements] MUST only be used where =
it is


  actually required for interoperation or to limit behavior which=
 has


  potential for causing harm (e.g., limiting retransmisssions)&nb=
sp; "


 


The only appropriate reason to require a timestamp would be if we expe=
cted peers to interpret the field as a point in time. OTOH, it would be per=
fectly reasonable to state the actual interop requirements, then add a non-=
normative (probably indented) paragraph suggesting that a timestamp is a go=
od way to do this.


 


On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:


 


I think the out-of-sync failover described by Ulrich is a good use cas=
e to mandate a specific semantic.


 


Is there any specific NOT to mandate the use of NTP timestamps if it i=
s a simple way to solve the possible issues and please everyone?=



 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


How the sequence number is implemented is an implementation decision.&=
nbsp; There is no reason to mandate that is be an NTP timestamp.  That=
 should be included only as one way of addressing the requirement.


 


Steve


 


On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:


I also agree.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: Tuesday, February 04, 2014 11:50 PM


To: dime@ietf.org


Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


The existing wording seems actually fuzzy.


If it is "like an NTP timestamp", be proud and say it loud!<=
o:p>


 


In summary: ok with the proposal if it clarifies this handling of this=
 sequence-number.


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]


Envoy=E9 : mardi 4 f=E9vrier 2014 09:50


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


 


#32: Sequence-Number Time-Stamp values within OC-OLR


 


The -01 draft says in clause 4.4:


   From the functionality point of view, the OC-Sequence-Num=
ber AVP MUST


   be used as a non-volatile increasing counter between two =
overload


   control endpoints (neglecting the fact that the contents =
of the AVP


   is a 64-bit NTP timestamp [RFC5905]).  The sequence =
number is only


   required to be unique between two overload control endpoi=
nts.


   Sequence numbers are treated in uni-directional manner, i=
.e. two


   sequence numbers on each direction between two endpoints =
are not


   related or correlated.


 


   When generating sequence numbers, the new sequence n=
umber MUST be


   greater than any sequence number previously seen between =
two


   endpoints within a time window that tolerates the wraparo=
und of the


   NTP timestamp (i.e. approximately 68 years).

 


 


With this mechanism it is difficult to get back to sync once you are o=
ut  of sync (for whatever reason).


It is proposed to mandate that the Sequence Number is a real 64-bit NT=
P  timestamp (RFC5905) indicating the point in time when the OLR was c=
reated,  and to mandate that  OLRs with a time stamp higher than =
time of reception  must be ignored by the reacting node.

 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4A3EC7PEXCVZYM13corpora_--


From nobody Fri Feb 14 07:59:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262271A0270 for ; Fri, 14 Feb 2014 07:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWZJuzz-6GbS for ; Fri, 14 Feb 2014 07:59:35 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 152AD1A02D3 for ; Fri, 14 Feb 2014 07:59:27 -0800 (PST)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id C9FBD190325; Fri, 14 Feb 2014 16:59:24 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id B45A0C805D; Fri, 14 Feb 2014 16:59:24 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 16:59:24 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
Thread-Index: AQHPKLbqX+PM3sXXYUm3dvZo0JTU4pq06f8w
Date: Fri, 14 Feb 2014 15:59:24 +0000
Message-ID: <14774_1392393564_52FE3D5C_14774_9113_1_6B7134B31289DC4FAF731D844122B36E4A3ED6@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>  <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B3055@DEMUMBX014.nsn-intra.net> <52FCBA0F.1060503@usdonovans.com>
In-Reply-To: <52FCBA0F.1060503@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4A3ED6PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.115116
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kJTYODhYhZvgXAjg0zIqseaCMQM
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 15:59:41 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4A3ED6PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

And I agree too.

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 13 f=E9vrier 2014 13:27
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR

Ulrich,

I agree, we should say must not remember.  Otherwise it will be more diffic=
ult to get back into syncronization.

Steve
On 2/12/14 7:28 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Maybe its worth to explicitly say that "... there is no reason to remember =
anything about it" includes "no need for reacting nodes to remember sequenc=
e numbers of expired OLRs" or even mandate that sequence numbers of expired=
 OLRs must not be remembered by reacting nodes.

Ulrich



-----Original Message-----

From: ext lionel.morand@orange.com [mailto=
:lionel.morand@orange.com]

Sent: Monday, February 10, 2014 2:48 PM

To: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: RE: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



I would add, maybe even before the format (NTP time based), that the real r=
equirements for the sequence-number are:



- Globally/eternally unique

- increase monotonically over time, including over a reboot (as remind by S=
teve)



The NTP time based type is just a guidance provided by the draft on how to =
generate sequence numbers with such properties.



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen

Envoy=E9 : samedi 8 f=E9vrier 2014 11:33

=C0 : Wiehe, Ulrich (NSN - DE/Munich)

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR





Sounds acceptable. Would the following then work for all:



o clarify that once the overload report expires there is no

  reason to remember anything about it

o the sequence number would be similar to session-id.. based

  on the NTP time + any vendor specific data to make it

  "globally and eternally unique".



- Jouni







On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Steve,



sounds like an acceptable proposal which allows to come back to sync after =
OLR expiry.

This requires however an update of clause 5.5.2 to clearly state

Once the overload report expires there is no reason to remember anything ab=
out it and the next overload report received could, conceivably have any va=
lue.





Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Thursday, February 06, 2014 4:50 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



A couple of things -



The requirement is that the sequence number increase monotonically over tim=
e, including over a reboot.  Use of NTP time is one way of doing this but i=
s not the only way.  Someone could, for instance, use a time stamp to set t=
he sequence number for the first overload report sent after a reboot and th=
en increment the sequence number value by one for each subsequent overload =
report sent.  This actually has better properties than an NTP time stamp as=
 it would take much longer to roll over.  One could also create a global se=
quence number service that is not tied to time and have a Diameter server q=
uery that global sequence number server after each reboot.



We also have a duration timer on overload reports.  This gives us one way t=
o reset.  It should only be required to remember the sequence number of an =
active overload report.  Once the overload report expires there is no reaso=
n to remember anything about it and the next overload report received could=
, conceivably have any value.



The requirement we need is similar to the session-id in the base Diameter s=
pecification.  The wording there is -- "The Session-Id MUST be globally and=
 eternally unique".  We just need eternally as the spacial differentiation =
is based on the context of the message carrying the overload report.



It would be perfectly valid for the DOIC draft to suggest the use of NTP ti=
mestamps to populate the sequence number but it should be worded in a simil=
ar fashion as the Diameter base RFC -- The Session-Id includes a mandatory =
portion and an implementation-defined portion; a recommended format for the=
 implementation-defined portion is outlined below ..."



Steve



On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I cannot understand what is the problem with mandating timestamp.

But I can see interoperability problems with the current definition:



Assume the sender sends sequence numbers

1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....

but the receicer for any reason receives

1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....

The receiver would accept

1, 1, ... 1, 2, 2, ... 2, 3, 30000

and then silently discards

3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....

with no way to come back to sync.



Are we sure that this cannot happen?



Mandating timestamp for sequence number generation at the sender and plausi=
bility checking (i.e. received value must be between stored value and time =
of reception) for the receiver may not be the only way to solve the problem=
. But in the moment I don't see another way.



Ulrich





-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell

Sent: Wednesday, February 05, 2014 4:57 PM

To: ext lionel.morand@orange.com

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



My point is, we have an interop requirement that the sequence number always=
 increases over time scope. We do not have the interop requirement that the=
 sequence number be implemented as a time stamp. A time stamp is probably a=
 good way to  meet the interop requirements, but it is not, in itself, an i=
nterop requirement.



On Feb 5, 2014, at 9:53 AM,   wr=
ote:



Not sure to understand: if there is a kind of "interop requirement", it is =
a case for a "MUST".

We are not violating anything.



Reporting and reacting nodes will just rely on the Diameter interfaces to k=
now how to handle the received sequence-number. So any MUST on the format o=
f the sequence-number is acceptable if it avoids interop issues.



-----Message d'origine-----

De : Ben Campbell [mailto:ben@nostrum.com]

Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47

=C0 : MORAND Lionel IMT/OLN

Cc : Steve Donovan; dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR



I concur with Steve on this one. Using a time stamp is a good way to meet t=
he requirements, but it's not our job to normatively state an implementatio=
n. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Sect=
ion 6 of 2119 includes the following:



"In particular, [normative requirements] MUST only be used where it is

  actually required for interoperation or to limit behavior which has

  potential for causing harm (e.g., limiting retransmisssions)  "



The only appropriate reason to require a timestamp would be if we expected =
peers to interpret the field as a point in time. OTOH, it would be perfectl=
y reasonable to state the actual interop requirements, then add a non-norma=
tive (probably indented) paragraph suggesting that a timestamp is a good wa=
y to do this.



On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:



I think the out-of-sync failover described by Ulrich is a good use case to =
mandate a specific semantic.



Is there any specific NOT to mandate the use of NTP timestamps if it is a s=
imple way to solve the possible issues and please everyone?



Lionel



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-=
OLR



How the sequence number is implemented is an implementation decision.  Ther=
e is no reason to mandate that is be an NTP timestamp.  That should be incl=
uded only as one way of addressing the requirement.



Steve



On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:

I also agree.



Regards,

Nirav.



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange=
.com

Sent: Tuesday, February 04, 2014 11:50 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR



The existing wording seems actually fuzzy.

If it is "like an NTP timestamp", be proud and say it loud!



In summary: ok with the proposal if it clarifies this handling of this sequ=
ence-number.



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Envoy=E9 : mardi 4 f=E9vrier 2014 09:50

=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR



#32: Sequence-Number Time-Stamp values within OC-OLR



The -01 draft says in clause 4.4:

   From the functionality point of view, the OC-Sequence-Number AVP MUST

   be used as a non-volatile increasing counter between two overload

   control endpoints (neglecting the fact that the contents of the AVP

   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only

   required to be unique between two overload control endpoints.

   Sequence numbers are treated in uni-directional manner, i.e. two

   sequence numbers on each direction between two endpoints are not

   related or correlated.



   When generating sequence numbers, the new sequence number MUST be

   greater than any sequence number previously seen between two

   endpoints within a time window that tolerates the wraparound of the

   NTP timestamp (i.e. approximately 68 years).





With this mechanism it is difficult to get back to sync once you are out  o=
f sync (for whatever reason).

It is proposed to mandate that the Sequence Number is a real 64-bit NTP  ti=
mestamp (RFC5905) indicating the point in time when the OLR was created,  a=
nd to mandate that  OLRs with a time stamp higher than time of reception  m=
ust be ignored by the reacting node.





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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



_______________________________________________

DiME mailing list

DiME@ietf.org

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4A3ED6PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











And I agree too.


 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : jeudi 13 f=E9vrier 2014 13:27

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp value=
s within OC-OLR






 


Ulrich,



I agree, we should say must not remember.  Otherwise it will be more d=
ifficult to get back into syncronization.



Steve




On 2/12/14 7:28 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Maybe its worth to explicitly say that "... there is no reason to=
 remember anything about it" includes "no need for reacting nodes=
 to remember sequence numbers of expired OLRs" or even mandate that se=
quence numbers of expired OLRs must not be remembered by reacting nodes.


Ulrich


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com] 


Sent: Monday, February 10, 2014 2:48 PM


To: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org


Subject: RE: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


I would add, maybe even before the format (NTP time based), that the r=
eal requirements for the sequence-number are:


 


- Globally/eternally unique


- increase monotonically over time, including over a reboot (as remind=
 by Steve) 


 


The NTP time based type is just a guidance provided by the draft on ho=
w to generate sequence numbers with such properties.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Jouni Korhonen


Envoy=E9 : samedi 8 f=E9vrier 2014 11:33


=C0 : Wiehe, Ulrich (NSN - DE/Munich)


Cc : dime@ietf.org


Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR


 


 


Sounds acceptable. Would the following then work for all:

 


o clarify that once the overload report expires there is no=



  reason to remember anything about it


o the sequence number would be similar to session-id.. based 


  on the NTP time + any vendor specific data to make it =



  "globally and eternally unique".


 


- Jouni


 


 


 


On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Steve,


 


sounds like an acceptable proposal which allows to come back to sync a=
fter OLR expiry.


This requires however an update of clause 5.5.2 to clearly state<=
/o:p>


Once the overload report expires there is no reason to remember anythi=
ng about it and the next overload report received could, conceivably have a=
ny value. 


 


 


Ulrich


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Thursday, February 06, 2014 4:50 PM


To: dime@ietf.org


Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


A couple of things - 


 


The requirement is that the sequence number increase monotonically ove=
r time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time=
 stamp to set the sequence number for the first overload report sent after =
a reboot and then increment the sequence number value by one for each subse=
quent overload report sent.  This actually has better properties than =
an NTP time stamp as it would take much longer to roll over.  One coul=
d also create a global sequence number service that is not tied to time and=
 have a Diameter server query that global sequence number server after each=
 reboot.


 


We also have a duration timer on overload reports.  This gives us=
 one way to reset.  It should only be required to remember the sequenc=
e number of an active overload report.  Once the overload report expir=
es there is no reason to remember anything about it and the next overload r=
eport received could, conceivably have any value. 


 


The requirement we need is similar to the session-id in the base Diame=
ter specification.  The wording there is -- "The Session-Id MUST =
be globally and eternally unique".  We just need eternally as the=
 spacial differentiation is based on the context of the message carrying th=
e overload report.


 


It would be perfectly valid for the DOIC draft to suggest the use of N=
TP timestamps to populate the sequence number but it should be worded in a =
similar fashion as the Diameter base RFC -- The Session-Id includes a manda=
tory portion and an implementation-defined portion; a recommended format fo=
r the implementation-defined portion is outlined below ..."=



 


Steve


 


On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I cannot understand what is the problem with mandating timestamp.=



But I can see interoperability problems with the current definition:


 


Assume the sender sends sequence numbers


1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 


but the receicer for any reason receives 


1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,...=
. 


The receiver would accept


1, 1, ... 1, 2, 2, ... 2, 3, 30000


and then silently discards


3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 


with no way to come back to sync.


 


Are we sure that this cannot happen?


 


Mandating timestamp for sequence number generation at the sender and p=
lausibility checking (i.e. received value must be between stored value and =
time of reception) for the receiver may not be the only way to solve the pr=
oblem. But in the moment I don't see another way.


 


Ulrich


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Ben Campbell


Sent: Wednesday, February 05, 2014 4:57 PM


To: ext lionel.morand@oran=
ge.com


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


My point is, we have an interop requirement that the sequence number a=
lways increases over time scope. We do not have the interop requirement tha=
t the sequence number be implemented as a time stamp. A time stamp is proba=
bly a good way to  meet the interop requirements, but it is not, in it=
self, an interop requirement.


 


On Feb 5, 2014, at 9:53 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:


 


Not sure to understand: if there is a kind of "interop requiremen=
t", it is a case for a "MUST".


We are not violating anything.


 


Reporting and reacting nodes will just rely on the Diameter interfaces=
 to know how to handle the received sequence-number. So any MUST on the for=
mat of the sequence-number is acceptable if it avoids interop issues.<=
/o:p>


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] 


Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47


=C0 : MORAND Lionel IMT/OLN


Cc : Steve Donovan; dime@ietf.org=



Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


I concur with Steve on this one. Using a time stamp is a good way to m=
eet the requirements, but it's not our job to normatively state an implemen=
tation. In fact, it violates an RFC 2119 "MUST" level requirement=
 to do so. Section 6 of 2119 includes the following:


 


"In particular, [normative requirements] MUST only be used where =
it is


  actually required for interoperation or to limit behavior which=
 has


  potential for causing harm (e.g., limiting retransmisssions)&nb=
sp; "


 


The only appropriate reason to require a timestamp would be if we expe=
cted peers to interpret the field as a point in time. OTOH, it would be per=
fectly reasonable to state the actual interop requirements, then add a non-=
normative (probably indented) paragraph suggesting that a timestamp is a go=
od way to do this.


 


On Feb 5, 2014, at 9:37 AM, lionel.morand@orange.com wrote:


 


I think the out-of-sync failover described by Ulrich is a good use cas=
e to mandate a specific semantic.


 


Is there any specific NOT to mandate the use of NTP timestamps if it i=
s a simple way to solve the possible issues and please everyone?=



 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34


=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR


 


How the sequence number is implemented is an implementation decision.&=
nbsp; There is no reason to mandate that is be an NTP timestamp.  That=
 should be included only as one way of addressing the requirement.


 


Steve


 


On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:


I also agree.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: Tuesday, February 04, 2014 11:50 PM


To: dime@ietf.org


Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR


 


The existing wording seems actually fuzzy.


If it is "like an NTP timestamp", be proud and say it loud!<=
o:p>


 


In summary: ok with the proposal if it clarifies this handling of this=
 sequence-number.


 


Lionel


 


-----Message d'origine-----


De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]


Envoy=E9 : mardi 4 f=E9vrier 2014 09:50


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


 


#32: Sequence-Number Time-Stamp values within OC-OLR


 


The -01 draft says in clause 4.4:


   From the functionality point of view, the OC-Sequence-Num=
ber AVP MUST


   be used as a non-volatile increasing counter between two =
overload


   control endpoints (neglecting the fact that the contents =
of the AVP


   is a 64-bit NTP timestamp [RFC5905]).  The sequence =
number is only


   required to be unique between two overload control endpoi=
nts.


   Sequence numbers are treated in uni-directional manner, i=
.e. two


   sequence numbers on each direction between two endpoints =
are not


   related or correlated.


 


   When generating sequence numbers, the new sequence n=
umber MUST be


   greater than any sequence number previously seen between =
two


   endpoints within a time window that tolerates the wraparo=
und of the


   NTP timestamp (i.e. approximately 68 years).

 


 


With this mechanism it is difficult to get back to sync once you are o=
ut  of sync (for whatever reason).


It is proposed to mandate that the Sequence Number is a real 64-bit NT=
P  timestamp (RFC5905) indicating the point in time when the OLR was c=
reated,  and to mandate that  OLRs with a time stamp higher than =
time of reception  must be ignored by the reacting node.

 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4A3ED6PEXCVZYM13corpora_--


From nobody Fri Feb 14 08:11:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250A21A02AF; Fri, 14 Feb 2014 08:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8IA8fJyqrna; Fri, 14 Feb 2014 08:11:25 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C47C81A02ED; Fri, 14 Feb 2014 08:11:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 15B5B20680; Fri, 14 Feb 2014 11:07:36 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfFT4m4NwPMr; Fri, 14 Feb 2014 11:07:35 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 14 Feb 2014 11:07:35 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 960CB83E59; Fri, 14 Feb 2014 11:11:15 -0500 (EST)
From: Sam Hartman 
To: Stefan Winter 
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu>
Date: Fri, 14 Feb 2014 11:11:15 -0500
In-Reply-To: <52FDDD10.1050306@restena.lu> (Stefan Winter's message of "Fri, 14 Feb 2014 10:08:32 +0100")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jfRfqDaKIMCGKDXQuBtZC99D6cY
Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" 
Subject: Re: [Dime] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 16:11:31 -0000

Hi.
My life has been hectic, and I completely dropped the ball on this!
Thanks for doing this.


From nobody Fri Feb 14 09:47:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3471A031F for ; Fri, 14 Feb 2014 09:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOOqiuskY_3O for ; Fri, 14 Feb 2014 09:47:46 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4C1A030E for ; Fri, 14 Feb 2014 09:47:45 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 987D01B8336; Fri, 14 Feb 2014 18:47:43 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 7BFA5384072; Fri, 14 Feb 2014 18:47:43 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 18:47:43 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #52: Throttling not needed to be based on previous history
Thread-Index: AQHPKLrHNzhgchTFqE2RKeEWc2MY3Zq1CD2w
Date: Fri, 14 Feb 2014 17:47:42 +0000
Message-ID: <7292_1392400063_52FE56BF_7292_8122_1_6B7134B31289DC4FAF731D844122B36E4A431E@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097745AF@ESESSMB101.ericsson.se> <52FCC094.8030406@usdonovans.com>
In-Reply-To: <52FCC094.8030406@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4A431EPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.113015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KaE6WK7U-aJbP645Dl1bBVIwu4U
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 17:47:49 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4A431EPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

OK

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 13 f=E9vrier 2014 13:55
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #52: Throttling not needed to be based on previou=
s history

+1
On 2/12/14 7:34 AM, Maria Cruz Bartolome wrote:

Thanks Jouni, I didn't realize.

One more correction added



Proposal:

Indicates that the reporting node urges the reacting node to reduce

its traffic by a given percentage. For example if the

reacting node would send 100 packets to the                        <---

reporting node, then a reception of OC-Reduction-Percentage value of

10 would mean that from now on the reacting node MUST only send

90 packets instead of 100. How the reacting node achieves the "true       <=
---

reduction" transactions leading to the sent request messages is up to

the implementation. The reacting node MAY simply drop every 10th

packet from its output queue and let the generic application logic try

to recover from it.





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: mi=E9rcoles, 12 de febrero de 2014 10:36

To: Maria Cruz Bartolome

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previo=
us history





Fine by me.. though you then need to apply the same change to the rest of t=
his paragraph, not only the first one.



Also, please update this additional concern into the issue tracker issue #5=
2.



- Jouni



On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome  wrote:



Same comment also applies to following paragraph in 5.5.2



Now:

  0 < value < 100



     Indicates that the reporting node urges the reacting node to

     reduce its traffic by a given percentage.  For example if the

     reacting node has been sending 100 packets per second to the

     reporting node, then a reception of OC-Reduction-Percentage value

     of 10 would mean that from now on the reacting node MUST only send

     90 packets per second.  How the reacting node achieves the "true

     reduction" transactions leading to the sent request messages is up

     to the implementation.  The reacting node MAY simply drop every

     10th packet from its output queue and let the generic application

     logic try to recover from it.0 < value < 100



Proposal:

Indicates that the reporting node urges the reacting node to reduce

its traffic by a given percentage. For example if the

reacting node would send 100 packets to the                        <---

reporting node, then a reception of OC-Reduction-Percentage value of

10 would mean that from now on the reacting node MUST only send

90 packets per second. How the reacting node achieves the "true

reduction" transactions leading to the sent request messages is up to

the implementation. The reacting node MAY simply drop every 10th

packet from its output queue and let the generic application logic try

to recover from it.





We should not specify a rates for the simple loss algorithm. It's up to the=
 implementation how to reduce, but no time unit has to be specified.







-----Original Message-----

From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]

Sent: mi=E9rcoles, 12 de febrero de 2014 9:13

To: Maria Cruz Bartolome

Cc: dime@ietf.org

Subject: [dime] #52: Throttling not needed to be based on previous

history



#52: Throttling not needed to be based on previous history



Now (chapter 4.7):

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would have sent.



Proposal:

The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  and =
describes the percentage of the traffic that the sender is  requested to re=
duce, compared to what it otherwise would send.





The intention is to avoid that anyone may interpret reacting node is  requi=
red to consider history of sent information when throttling.



--

-----------------------------------------------+----------------------

-----------------------------------------------+--

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

    Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                              |   Keywords:

-----------------------------------------------+----------------------

-----------------------------------------------+--

-----------------------------------------------+---



Ticket URL: 

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4A431EPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











OK


 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : jeudi 13 f=E9vrier 2014 13:55

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #52: Throttling not needed to be base=
d on previous history






 


+1




On 2/12/14 7:34 AM, Maria Cruz Bartolome wrote:=







Thanks Jouni, I didn't realize.


One more correction added


 




Proposal:


Indicates that the reporting node urges the reacting node to reduce 


its traffic by a given percentage. For example if the


reacting node would send 100 packets to the    &nb=
sp;            =
       <---


reporting node, then a reception of OC-Reduction-Percentage value of <=
o:p>


10 would mean that from now on the reacting node MUST only send


90 packets instead of 100. How the reacting node achieves the "tr=
ue       <---


reduction" transactions leading to the sent request messages is u=
p to 


the implementation. The reacting node MAY simply drop every 10th =



packet from its output queue and let the generic application logic try=
 


to recover from it.




 


 


-----Original Message-----


From: Jouni Korhonen [mailto=
:jouni.nospam@gmail.com] 


Sent: mi=E9rcoles, 12 de febrero de 2014 10:36


To: Maria Cruz Bartolome


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on p=
revious history


 


 


Fine by me.. though you then need to apply the same change to the rest=
 of this paragraph, not only the first one.


 


Also, please update this additional concern into the issue tracker iss=
ue #52.


 


- Jouni


 


On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>=
 wrote:


 




Same comment also applies to following paragraph in 5.5.2

 


Now:


  0 < value < 100


 


     Indicates that the reporting node urges the r=
eacting node to


     reduce its traffic by a given percentage.&nbs=
p; For example if the


     reacting node has been sending 100 packets pe=
r second to the


     reporting node, then a reception of OC-Reduct=
ion-Percentage value


     of 10 would mean that from now on the reactin=
g node MUST only send


     90 packets per second.  How the reacting=
 node achieves the "true


     reduction" transactions leading to the s=
ent request messages is up


     to the implementation.  The reacting nod=
e MAY simply drop every


     10th packet from its output queue and let the=
 generic application


     logic try to recover from it.0 < value <=
; 100


 


Proposal:


Indicates that the reporting node urges the reacting node to reduce 


its traffic by a given percentage. For example if the


reacting node would send 100 packets to the    &nb=
sp;            =
       <---


reporting node, then a reception of OC-Reduction-Percentage value of <=
o:p>


10 would mean that from now on the reacting node MUST only send


90 packets per second. How the reacting node achieves the "true <=
o:p>


reduction" transactions leading to the sent request messages is u=
p to 


the implementation. The reacting node MAY simply drop every 10th =



packet from its output queue and let the generic application logic try=
 


to recover from it.


 


 


We should not specify a rates for the simple loss algorithm. It's up t=
o the implementation how to reduce, but no time unit has to be specified. <=
o:p>


 


 


 


-----Original Message-----


From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]


Sent: mi=E9rcoles, 12 de febrero de 2014 9:13


To: Maria Cruz Bartolome


Cc: dime@ietf.org


Subject: [dime] #52: Throttling not needed to be based on previous 


history


 


#52: Throttling not needed to be based on previous history<=
/pre>

 


Now (chapter 4.7):


   The OC-Reduction-Percentage AVP (AVP code TBD8) is type o=
f Unsigned32


   and describes the percentage of the traffic that the send=
er is


   requested to reduce, compared to what it otherwise would =
have sent.


 


Proposal:


The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32&=
nbsp; and describes the percentage of the traffic that the sender is  =
requested to reduce, compared to what it otherwise would send.

 


 


The intention is to avoid that anyone may interpret reacting node is&n=
bsp; required to consider history of sent information when throttling.=



 


--


-----------------------------------------------+------------------=
----


-----------------------------------------------+--


-----------------------------------------------+---

Reporter:  m=
aria.cruz.bartolome@ericsson.com  |      =
Owner:  MCruz


    Type:  defect     &nb=
sp;            =
           |  Bartol=
om=E9


Priority:  major         =
            &nb=
sp;        |    =
; Status:  new


Component:  draft-docdt-dime-ovli     &n=
bsp;        |  Milestone:


Severity:  Active WG Document      =
           |  &=
nbsp; Version:  1.0


           &nbs=
p;            &=
nbsp;           &nbs=
p;         |   Keywords:<=
o:p>


-----------------------------------------------+------------------=
----


-----------------------------------------------+--


-----------------------------------------------+---

 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/52>


dime <http://tools.ietf.=
org/wg/dime/>


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4A431EPEXCVZYM13corpora_--


From nobody Fri Feb 14 13:24:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204E71A0405 for ; Fri, 14 Feb 2014 13:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGD_6KZYoju8 for ; Fri, 14 Feb 2014 13:24:15 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A84BF1A03EE for ; Fri, 14 Feb 2014 13:24:13 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ELO7BC052013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 15:24:09 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B92097745AF@ESESSMB101.ericsson.se>
Date: Fri, 14 Feb 2014 15:24:07 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F08E5F1-0FDA-44D6-B129-42D0A58F51C6@nostrum.com>
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097745AF@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_jbrzhBNneENPm3-ZF_hpoxj6vQ
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 21:24:17 -0000

+1

On Feb 12, 2014, at 7:34 AM, Maria Cruz Bartolome =
 wrote:

> Thanks Jouni, I didn't realize.
> One more correction added
>=20
>> Proposal:
>> Indicates that the reporting node urges the reacting node to reduce=20=

>> its traffic by a given percentage. For example if the
>> reacting node would send 100 packets to the				=
<---
>> reporting node, then a reception of OC-Reduction-Percentage value of=20=

>> 10 would mean that from now on the reacting node MUST only send
>> 90 packets instead of 100. How the reacting node achieves the "true   =
    <---
>> reduction" transactions leading to the sent request messages is up to=20=

>> the implementation. The reacting node MAY simply drop every 10th=20
>> packet from its output queue and let the generic application logic =
try=20
>> to recover from it.
>=20
>=20
> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: mi=E9rcoles, 12 de febrero de 2014 10:36
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on =
previous history
>=20
>=20
> Fine by me.. though you then need to apply the same change to the rest =
of this paragraph, not only the first one.
>=20
> Also, please update this additional concern into the issue tracker =
issue #52.
>=20
> - Jouni
>=20
> On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Same comment also applies to following paragraph in 5.5.2
>>=20
>> Now:
>>  0 < value < 100
>>=20
>>     Indicates that the reporting node urges the reacting node to
>>     reduce its traffic by a given percentage.  For example if the
>>     reacting node has been sending 100 packets per second to the
>>     reporting node, then a reception of OC-Reduction-Percentage value
>>     of 10 would mean that from now on the reacting node MUST only =
send
>>     90 packets per second.  How the reacting node achieves the "true
>>     reduction" transactions leading to the sent request messages is =
up
>>     to the implementation.  The reacting node MAY simply drop every
>>     10th packet from its output queue and let the generic application
>>     logic try to recover from it.0 < value < 100
>>=20
>> Proposal:
>> Indicates that the reporting node urges the reacting node to reduce=20=

>> its traffic by a given percentage. For example if the
>> reacting node would send 100 packets to the				=
<---
>> reporting node, then a reception of OC-Reduction-Percentage value of=20=

>> 10 would mean that from now on the reacting node MUST only send
>> 90 packets per second. How the reacting node achieves the "true=20
>> reduction" transactions leading to the sent request messages is up to=20=

>> the implementation. The reacting node MAY simply drop every 10th=20
>> packet from its output queue and let the generic application logic =
try=20
>> to recover from it.
>>=20
>>=20
>> We should not specify a rates for the simple loss algorithm. It's up =
to the implementation how to reduce, but no time unit has to be =
specified.=20
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>> Sent: mi=E9rcoles, 12 de febrero de 2014 9:13
>> To: Maria Cruz Bartolome
>> Cc: dime@ietf.org
>> Subject: [dime] #52: Throttling not needed to be based on previous=20
>> history
>>=20
>> #52: Throttling not needed to be based on previous history
>>=20
>> Now (chapter 4.7):
>>   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of =
Unsigned32
>>   and describes the percentage of the traffic that the sender is
>>   requested to reduce, compared to what it otherwise would have sent.
>>=20
>> Proposal:
>> The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 =
 and describes the percentage of the traffic that the sender is  =
requested to reduce, compared to what it otherwise would send.
>>=20
>>=20
>> The intention is to avoid that anyone may interpret reacting node is  =
required to consider history of sent information when throttling.
>>=20
>> --
>> =
-----------------------------------------------+----------------------
>> -----------------------------------------------+--
>> -----------------------------------------------+---
>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>    Type:  defect                             |  Bartolom=E9
>> Priority:  major                              |     Status:  new
>> Component:  draft-docdt-dime-ovli              |  Milestone:
>> Severity:  Active WG Document                 |    Version:  1.0
>>                                              |   Keywords:
>> =
-----------------------------------------------+----------------------
>> -----------------------------------------------+--
>> -----------------------------------------------+---
>>=20
>> Ticket URL: 
>> dime 
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 14 13:28:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD341A0428 for ; Fri, 14 Feb 2014 13:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNtPcdfBAIRn for ; Fri, 14 Feb 2014 13:28:23 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B331D1A041E for ; Fri, 14 Feb 2014 13:28:10 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ELS7Ca052224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 15:28:08 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <52FCB9D6.3070908@usdonovans.com>
Date: Fri, 14 Feb 2014 15:28:06 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <2771A62F-E982-4A31-A827-E2C4AC14132B@nostrum.com>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cGAEdXvRse-TCkuPRKT3syjY9qI
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within	OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 21:28:31 -0000

+1. It doesn't even have to be "suggested" in the since of a =
(non-normative) recommendation. It can merely be an example of an =
approach which meets the stated requirements.

On Feb 13, 2014, at 6:25 AM, Steve Donovan  =
wrote:

> Jouni,
>=20
> The important thing is to define the properties.  There should be no =
harm in giving one suggested implementation.
>=20
> Steve
>=20
> On 2/11/14 4:42 PM, Jouni Korhonen wrote:
>> If the NTP is only going to be guidance when building the globally
>> and eternally unique sequence number, IMHO better not mention NTP
>> then at all. Just include the required properties below. One less
>> mandatory reference..
>>=20
>> - Jouni
>>=20
>>=20
>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome=20
>> 
>>  wrote:
>>=20
>>=20
>>> It sounds reasonable to me as well.
>>> /MCruz
>>> =20
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Steve Donovan
>>> Sent: lunes, 10 de febrero de 2014 14:59
>>> To:=20
>>> dime@ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>> =20
>>> +1
>>> On 2/10/14 7:47 AM,=20
>>> lionel.morand@orange.com
>>>  wrote:
>>> I would add, maybe even before the format (NTP time based), that the =
real requirements for the sequence-number are:
>>> =20
>>> - Globally/eternally unique
>>> - increase monotonically over time, including over a reboot (as =
remind by Steve)=20
>>> =20
>>> The NTP time based type is just a guidance provided by the draft on =
how to generate sequence numbers with such properties.
>>> =20
>>> Lionel
>>> =20
>>> -----Message d'origine-----
>>> De : DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] De la part de Jouni Korhonen
>>> Envoy=E9 : samedi 8 f=E9vrier 2014 11:33
>>> =C0 : Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc :=20
>>> dime@ietf.org
>>>=20
>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>> =20
>>> =20
>>> Sounds acceptable. Would the following then work for all:
>>> =20
>>> o clarify that once the overload report expires there is no
>>>   reason to remember anything about it
>>> o the sequence number would be similar to session-id.. based=20
>>>   on the NTP time + any vendor specific data to make it=20
>>>   "globally and eternally unique".
>>> =20
>>> - Jouni
>>> =20
>>> =20
>>> =20
>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>> 
>>>  wrote:
>>> =20
>>> Steve,
>>> =20
>>> sounds like an acceptable proposal which allows to come back to sync =
after OLR expiry.
>>> This requires however an update of clause 5.5.2 to clearly state
>>> Once the overload report expires there is no reason to remember =
anything about it and the next overload report received could, =
conceivably have any value.=20
>>> =20
>>> =20
>>> Ulrich
>>> =20
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of ext Steve Donovan
>>> Sent: Thursday, February 06, 2014 4:50 PM
>>> To:=20
>>> dime@ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>> =20
>>> A couple of things -=20
>>> =20
>>> The requirement is that the sequence number increase monotonically =
over time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time =
stamp to set the sequence number for the first overload report sent =
after a reboot and then increment the sequence number value by one for =
each subsequent overload report sent.  This actually has better =
properties than an NTP time stamp as it would take much longer to roll =
over.  One could also create a global sequence number service that is =
not tied to time and have a Diameter server query that global sequence =
number server after each reboot.
>>> =20
>>> We also have a duration timer on overload reports.  This gives us =
one way to reset.  It should only be required to remember the sequence =
number of an active overload report.  Once the overload report expires =
there is no reason to remember anything about it and the next overload =
report received could, conceivably have any value.=20
>>> =20
>>> The requirement we need is similar to the session-id in the base =
Diameter specification.  The wording there is -- "The Session-Id MUST be =
globally and eternally unique".  We just need eternally as the spacial =
differentiation is based on the context of the message carrying the =
overload report.
>>> =20
>>> It would be perfectly valid for the DOIC draft to suggest the use of =
NTP timestamps to populate the sequence number but it should be worded =
in a similar fashion as the Diameter base RFC -- The Session-Id includes =
a mandatory portion and an implementation-defined portion; a recommended =
format for the implementation-defined portion is outlined below ..."
>>> =20
>>> Steve
>>> =20
>>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> I cannot understand what is the problem with mandating timestamp.
>>> But I can see interoperability problems with the current definition:
>>> =20
>>> Assume the sender sends sequence numbers
>>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>> but the receicer for any reason receives=20
>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20=

>>> The receiver would accept
>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>>> and then silently discards
>>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
>>> with no way to come back to sync.
>>> =20
>>> Are we sure that this cannot happen?
>>> =20
>>> Mandating timestamp for sequence number generation at the sender and =
plausibility checking (i.e. received value must be between stored value =
and time of reception) for the receiver may not be the only way to solve =
the problem. But in the moment I don't see another way.
>>> =20
>>> Ulrich
>>> =20
>>> =20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of ext Ben Campbell
>>> Sent: Wednesday, February 05, 2014 4:57 PM
>>> To: ext=20
>>> lionel.morand@orange.com
>>>=20
>>> Cc:=20
>>> dime@ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>> =20
>>> My point is, we have an interop requirement that the sequence number =
always increases over time scope. We do not have the interop requirement =
that the sequence number be implemented as a time stamp. A time stamp is =
probably a good way to  meet the interop requirements, but it is not, in =
itself, an interop requirement.
>>> =20
>>> On Feb 5, 2014, at 9:53 AM,=20
>>>  
>>>  wrote:
>>> =20
>>> Not sure to understand: if there is a kind of "interop requirement", =
it is a case for a "MUST".
>>> We are not violating anything.
>>> =20
>>> Reporting and reacting nodes will just rely on the Diameter =
interfaces to know how to handle the received sequence-number. So any =
MUST on the format of the sequence-number is acceptable if it avoids =
interop issues.
>>> =20
>>> -----Message d'origine-----
>>> De : Ben Campbell [
>>> mailto:ben@nostrum.com
>>> ]=20
>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
>>> =C0 : MORAND Lionel IMT/OLN
>>> Cc : Steve Donovan;=20
>>> dime@ietf.org
>>>=20
>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>> =20
>>> I concur with Steve on this one. Using a time stamp is a good way to =
meet the requirements, but it's not our job to normatively state an =
implementation. In fact, it violates an RFC 2119 "MUST" level =
requirement to do so. Section 6 of 2119 includes the following:
>>> =20
>>> "In particular, [normative requirements] MUST only be used where it =
is
>>>   actually required for interoperation or to limit behavior which =
has
>>>   potential for causing harm (e.g., limiting retransmisssions)  "
>>> =20
>>> The only appropriate reason to require a timestamp would be if we =
expected peers to interpret the field as a point in time. OTOH, it would =
be perfectly reasonable to state the actual interop requirements, then =
add a non-normative (probably indented) paragraph suggesting that a =
timestamp is a good way to do this.
>>> =20
>>> On Feb 5, 2014, at 9:37 AM,=20
>>> lionel.morand@orange.com
>>>  wrote:
>>> =20
>>> I think the out-of-sync failover described by Ulrich is a good use =
case to mandate a specific semantic.
>>> =20
>>> Is there any specific NOT to mandate the use of NTP timestamps if it =
is a simple way to solve the possible issues and please everyone?
>>> =20
>>> Lionel
>>> =20
>>> De : DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] De la part de Steve Donovan
>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
>>> =C0 :=20
>>> dime@ietf.org
>>>=20
>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>> =20
>>> How the sequence number is implemented is an implementation =
decision.  There is no reason to mandate that is be an NTP timestamp.  =
That should be included only as one way of addressing the requirement.
>>> =20
>>> Steve
>>> =20
>>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>>> I also agree.
>>> =20
>>> Regards,
>>> Nirav.
>>> =20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
>>>=20
>>> Sent: Tuesday, February 04, 2014 11:50 PM
>>> To:=20
>>> dime@ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>> =20
>>> The existing wording seems actually fuzzy.
>>> If it is "like an NTP timestamp", be proud and say it loud!
>>> =20
>>> In summary: ok with the proposal if it clarifies this handling of =
this sequence-number.
>>> =20
>>> Lionel
>>> =20
>>> -----Message d'origine-----
>>> De : dime issue tracker [
>>> mailto:trac+dime@trac.tools.ietf.org
>>> ]
>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
>>> =C0 : MORAND Lionel IMT/OLN
>>> Cc :=20
>>> dime@ietf.org
>>>=20
>>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>> =20
>>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>> =20
>>> The -01 draft says in clause 4.4:
>>>    =46rom the functionality point of view, the OC-Sequence-Number =
AVP MUST
>>>    be used as a non-volatile increasing counter between two overload
>>>    control endpoints (neglecting the fact that the contents of the =
AVP
>>>    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is =
only
>>>    required to be unique between two overload control endpoints.
>>>    Sequence numbers are treated in uni-directional manner, i.e. two
>>>    sequence numbers on each direction between two endpoints are not
>>>    related or correlated.
>>> =20
>>>    When generating sequence numbers, the new sequence number MUST be
>>>    greater than any sequence number previously seen between two
>>>    endpoints within a time window that tolerates the wraparound of =
the
>>>    NTP timestamp (i.e. approximately 68 years).
>>> =20
>>> =20
>>> With this mechanism it is difficult to get back to sync once you are =
out  of sync (for whatever reason).
>>> It is proposed to mandate that the Sequence Number is a real 64-bit =
NTP  timestamp (RFC5905) indicating the point in time when the OLR was =
created,  and to mandate that  OLRs with a time stamp higher than time =
of reception  must be ignored by the reacting node.
>>> =20
>>> =20
>>> =
__________________________________________________________________________=
_______________________________________________
>>> =20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>> =20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =20
>>> =20
>>> =
__________________________________________________________________________=
_______________________________________________
>>> =20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>> =20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =20
>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =20
>>> =
__________________________________________________________________________=
_______________________________________________
>>> =20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>> =20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =20
>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>>=20
>> 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


From nobody Fri Feb 14 13:34:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723C11A0342 for ; Fri, 14 Feb 2014 13:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl-f79sAiPLh for ; Fri, 14 Feb 2014 13:34:47 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE091A023F for ; Fri, 14 Feb 2014 13:34:47 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ELYfsm052512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 15:34:43 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se>
Date: Fri, 14 Feb 2014 15:34:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B11C543-5FFA-4AC4-97CD-F17750E54757@nostrum.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pgmbuh0hATPKXTIcjOwssMcZqrY
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 21:34:49 -0000

That's fine with me. I don't think we have to specify what to do for =
every possible way a peer can mess up, but it doesn't hurt to do so =
here.

So on reflection, there's a couple of approaches here:

a) Go ahead and allow 0, but still use the Validity-Duration as the =
"official" way to turn off an overload condition. A "0" would create an =
overload state of "overloaded, zero reduction", which seems nonsensical =
but harmless, other than possibly causing strange things to show up in =
logs or alarms.

b) Ignore the OLR due to the invalid value.

I lean towards b, to be consistent with my comments about values > 100. =
This will create a side effect, however, that if a peer sends 0 in the =
expectation of turning off the reduction, it will have no effect and the =
previous Reduction-Percentage will stand.=20



On Feb 11, 2014, at 7:53 AM, Maria Cruz Bartolome =
 wrote:

> Ben,
> =20
> This approach sounds reasonable to me.
> But I would like to clarify what should be the behavior if a =
Reduction-Percentage=3D0 is received. This is an invalid value, then I =
presume it should be discarded by client.
> =20
> Regards
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: martes, 11 de febrero de 2014 0:56
> To: Jouni Korhonen
> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?
> =20
> So, here's some proposed text. (intentionally ignoring the related =
discussion about handling invalid values):
> =20
> Section 4.5, first paragraph, last 2 sentences:
> =20
> Old:
> =20
> Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 =
hours) MUST NOT be used. Invalid validity duration values are treated as =
if the OC-Validity-Duration AVP were not present.
> =20
> New:
> =20
> Validity duration values above 86400 MUST NOT be used. Invalid =
validity duration values are treated as if the OC-Validity-Duration AVP =
were not present. A value of zero (0) indicates that an existing =
overload condition has ended and that the reporting node is in a stable =
condition.
> =20
> Section 4.7, 2nd paragraph:
> =20
> Old:
> =20
>  The value of the Reduction-Percentage AVP is between one (1) and one =
hundred (100).  Values greater than 100 are interpreted as 100.  The =
value of 100 means that no traffic is expected, i.e. the reporting node =
is under a severe load and ceases to process any new messages. The =
Reduction-Percentage AVP MUST be present in an overload report that uses =
the default abatement algorithm.
> =20
> Note that there is no zero (0) value defined for the =
Reduction-Percentage AVP. A zero value would logically indicate that no =
overload abatement is requested. Instead, reporting nodes use a =
OC-Validity-Duration AVP value of zero (0) to indicate the end of an =
overload condition. [Section 4.5]
> =20
> =20
> =20
> =20
> =20
>=20
> On Feb 10, 2014, at 4:12 PM, Jouni Korhonen  =
wrote:
>=20
>=20
> Just post it here.
>=20
>=20
>=20
> On Feb 10, 2014, at 6:25 PM, Ben Campbell  wrote:
>=20
>=20
> Okay. Does that mean we should assign the issue to me in the tracker?
>=20
> On Feb 10, 2014, at 10:06 AM, Jouni Korhonen  =
wrote:
>=20
>=20
>=20
> Ben,
>=20
> Propose some text and we can see how it fits in.
>=20
> - Jouni
>=20
>=20
> On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:
>=20
>=20
>=20
> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  =
wrote:
>=20
>=20
>=20
> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>=20
>=20
> #45: Why is a validity duration of 0 disallowed?
>=20
> Section 4.5 disallows a validity duration of zero. Why do we want to
> disallow that? It would allow a quick way of ending any existing =
overload
> condition without worrying about the semantics of the abatement =
algorithm.
> (We currently use a reduction percentage of zero to end an overload
> condition--but that's specific to the loss algorithm and might not =
make
> sense for all future ones.)
>=20
> Right. Avoiding two ways of ending overload condition was the reason.
> I am OK to have validity duration 0 as an additional method ending the
> overload condition based on the reasoning above.
>=20
>=20
> I would go further and make duration 0 the _preferred_ way, for two =
reasons:
>=20
> 1) It's algorithm independent. (reduction-percentage of 0 is specific =
to algorithms that use reduction percentage.)
>=20
> 2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.
>=20
>=20
> =20
> =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 14 13:45:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FC11A0422 for ; Fri, 14 Feb 2014 13:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlCt367HInHz for ; Fri, 14 Feb 2014 13:45:11 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D98AC1A0415 for ; Fri, 14 Feb 2014 13:45:10 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ELj4HD053042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 15:45:06 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5B11C543-5FFA-4AC4-97CD-F17750E54757@nostrum.com>
Date: Fri, 14 Feb 2014 15:45:04 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>  <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <5B11C543-5FFA-4AC4-97CD-F17750E54757@nostrum.com>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DLGIU7e5VoxEq_Auws-66i1vIpU
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 21:45:13 -0000

Oops, this is what I get for responding before I finish reading the =
whole thread. I think that particular horse has been sufficiently =
beaten.

On Feb 14, 2014, at 3:34 PM, Ben Campbell  wrote:

> That's fine with me. I don't think we have to specify what to do for =
every possible way a peer can mess up, but it doesn't hurt to do so =
here.
>=20
> So on reflection, there's a couple of approaches here:
>=20
> a) Go ahead and allow 0, but still use the Validity-Duration as the =
"official" way to turn off an overload condition. A "0" would create an =
overload state of "overloaded, zero reduction", which seems nonsensical =
but harmless, other than possibly causing strange things to show up in =
logs or alarms.
>=20
> b) Ignore the OLR due to the invalid value.
>=20
> I lean towards b, to be consistent with my comments about values > =
100. This will create a side effect, however, that if a peer sends 0 in =
the expectation of turning off the reduction, it will have no effect and =
the previous Reduction-Percentage will stand.=20
>=20
>=20
>=20
> On Feb 11, 2014, at 7:53 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Ben,
>>=20
>> This approach sounds reasonable to me.
>> But I would like to clarify what should be the behavior if a =
Reduction-Percentage=3D0 is received. This is an invalid value, then I =
presume it should be discarded by client.
>>=20
>> Regards
>> /MCruz
>>=20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>> Sent: martes, 11 de febrero de 2014 0:56
>> To: Jouni Korhonen
>> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?
>>=20
>> So, here's some proposed text. (intentionally ignoring the related =
discussion about handling invalid values):
>>=20
>> Section 4.5, first paragraph, last 2 sentences:
>>=20
>> Old:
>>=20
>> Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., =
24 hours) MUST NOT be used. Invalid validity duration values are treated =
as if the OC-Validity-Duration AVP were not present.
>>=20
>> New:
>>=20
>> Validity duration values above 86400 MUST NOT be used. Invalid =
validity duration values are treated as if the OC-Validity-Duration AVP =
were not present. A value of zero (0) indicates that an existing =
overload condition has ended and that the reporting node is in a stable =
condition.
>>=20
>> Section 4.7, 2nd paragraph:
>>=20
>> Old:
>>=20
>> The value of the Reduction-Percentage AVP is between one (1) and one =
hundred (100).  Values greater than 100 are interpreted as 100.  The =
value of 100 means that no traffic is expected, i.e. the reporting node =
is under a severe load and ceases to process any new messages. The =
Reduction-Percentage AVP MUST be present in an overload report that uses =
the default abatement algorithm.
>>=20
>> Note that there is no zero (0) value defined for the =
Reduction-Percentage AVP. A zero value would logically indicate that no =
overload abatement is requested. Instead, reporting nodes use a =
OC-Validity-Duration AVP value of zero (0) to indicate the end of an =
overload condition. [Section 4.5]
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Feb 10, 2014, at 4:12 PM, Jouni Korhonen  =
wrote:
>>=20
>>=20
>> Just post it here.
>>=20
>>=20
>>=20
>> On Feb 10, 2014, at 6:25 PM, Ben Campbell  wrote:
>>=20
>>=20
>> Okay. Does that mean we should assign the issue to me in the tracker?
>>=20
>> On Feb 10, 2014, at 10:06 AM, Jouni Korhonen  =
wrote:
>>=20
>>=20
>>=20
>> Ben,
>>=20
>> Propose some text and we can see how it fits in.
>>=20
>> - Jouni
>>=20
>>=20
>> On Feb 10, 2014, at 5:53 PM, Ben Campbell  wrote:
>>=20
>>=20
>>=20
>> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen  =
wrote:
>>=20
>>=20
>>=20
>> On Feb 7, 2014, at 11:54 PM, dime issue tracker =
 wrote:
>>=20
>>=20
>> #45: Why is a validity duration of 0 disallowed?
>>=20
>> Section 4.5 disallows a validity duration of zero. Why do we want to
>> disallow that? It would allow a quick way of ending any existing =
overload
>> condition without worrying about the semantics of the abatement =
algorithm.
>> (We currently use a reduction percentage of zero to end an overload
>> condition--but that's specific to the loss algorithm and might not =
make
>> sense for all future ones.)
>>=20
>> Right. Avoiding two ways of ending overload condition was the reason.
>> I am OK to have validity duration 0 as an additional method ending =
the
>> overload condition based on the reasoning above.
>>=20
>>=20
>> I would go further and make duration 0 the _preferred_ way, for two =
reasons:
>>=20
>> 1) It's algorithm independent. (reduction-percentage of 0 is specific =
to algorithms that use reduction percentage.)
>>=20
>> 2) Explicit signaling of the end of an overload condition becomes =
semantically identical to the expiration of an overload condition. This =
allows a simpler implementation.
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From nobody Fri Feb 14 13:52:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C021A0449 for ; Fri, 14 Feb 2014 13:51:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLLp090zLq3A for ; Fri, 14 Feb 2014 13:51:50 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A23671A0428 for ; Fri, 14 Feb 2014 13:51:48 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ELphPJ053328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 15:51:44 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Fri, 14 Feb 2014 15:51:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com>  <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: "ext lionel.morand@orange.com" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/e6b7cDn_GCxEgM53BsQJU1BTnF8
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 21:51:51 -0000

On Feb 14, 2014, at 9:53 AM, lionel.morand@orange.com wrote:

> In other words, I think that we should have the following cases:
>=20
> -	non-zero reduction, non-zero validity period =3D> Valid
> -	0 reduction, non-zero validity period =3D> Valid (not blocking)
> -	0 reduction, 0 validity period =3D> Valid
> -	non-zero reduction, 0 validity period =3D> Invalid
>=20
> Does it make sense?


I don't think so.

The idea is that setting Validity-Period to zero ends an overload =
condition, without regard to the algorithm. Reduction-Percentage is =
specific to the default algorithm. I don't think we need to create an =
algorithm-specific rule here, at least not normatively. So I would say =
that a Validity-Period of zero ends overload, without regard to the =
algorithm, or any algorithm specific values.

I recognize that interacts with my previous comment about ignoring OLRs =
that have invalid Reduction-Percentage values, in that you could have =
silly things like [reduction-percentage=3D14732, validity-period=3D0]. =
In that case, I think the validity period would take precedent over the =
invalid reduction-percentage.


From nobody Fri Feb 14 13:59:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA64A1A036D for ; Fri, 14 Feb 2014 13:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1JuVGbl12jM for ; Fri, 14 Feb 2014 13:59:50 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C148E1A03FB for ; Fri, 14 Feb 2014 13:59:42 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ELxZpP053598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 15:59:37 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net>
Date: Fri, 14 Feb 2014 15:59:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <13009_1391526065_52F100B1_13009_2160_1_6B7134B31289DC4FAF731D844122B36E4770B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8sjW0Na5RINfrUYqn220bEO3bhU
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 21:59:52 -0000

On Feb 12, 2014, at 2:14 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> I understand your point but I'm not really convinced.
>=20
> 1. implicit indications (like answer message with result code TOO_BUSY =
and without piggybacked OLR or Lack of response) should be taken into =
account by reacting nodes independent from DOIC-support of the server.
> 2. How would the reacting node know whether the OC-Supported-Features =
AVP received in an answer indicates the features supported by the server =
(identified by the origin-host received in the answer) or the features =
supported by an agent on the path?=20
>=20

I think that, if an agent inserts OC-Supported-Features, that makes the =
agent the overload endpoint. If upstream servers that do not implement =
DOIC show implicit signs of overload, one hopes that agent will take =
action (whether that action means rejecting traffic, or originating an =
OLR back towards the client.)

So in this case, the reacting nodes peer "overload endpoint" is the =
agent. It knows the peer overload endpoint supports DOIC, and behaves =
accordingly.


From nobody Fri Feb 14 14:07:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9291A016A for ; Fri, 14 Feb 2014 14:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYeGqeQTs8iE for ; Fri, 14 Feb 2014 14:06:52 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C26931A01CD for ; Fri, 14 Feb 2014 14:06:46 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1EM6gq9054101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 16:06:44 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net>
Date: Fri, 14 Feb 2014 16:06:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net> <1! 0158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NMCt0zwp95BOs3pqSkuMKy1ZczI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 22:06:54 -0000

On Feb 14, 2014, at 8:59 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> I think that two points are mixed:
>=20
> 1) For efficiency, a DOIC-enabled client should be able to mitigate =
(possible) overload situation even if explicit indication is not =
received from the network.
> 2) DOIC-enabled clients having a different behavior regarding support =
or not of DOIC by server.
>=20
> if I agree with the first one, I disagree with the second one. The =
basic assumption is that a DOIC client will not throttle the traffic in =
absence of overload indication (explicit or implicit). And throttling =
will be performed as soon as an indication is received (explicit or =
implicit) if the client is designed for that (it supports DOIC or/and =
default behavior has been defined on reception of TOO_BUSY or =
non-response).
>=20
> It is the only thing that matters today.

I disagree, for  reasons stated earlier. In summary, the requirement =
that reacting nodes be able to take different action depending on =
whether an opposite endpoint supports DOIC is a direct implication of =
requirements 16 and 18 of RFC 7068.=


From nobody Fri Feb 14 14:12:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF36A1A0028 for ; Fri, 14 Feb 2014 14:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPjruIF5RIrf for ; Fri, 14 Feb 2014 14:12:43 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id F097B1A004A for ; Fri, 14 Feb 2014 14:12:42 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1EMCXGP054473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 16:12:34 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Fri, 14 Feb 2014 16:12:32 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>  
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cQb4TkkaWT86O8nW3T9iVPXYELM
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 22:12:45 -0000

I actually prefer making it mandatory. The cost of adding it is =
trivial--even more so for a reporting node that only supports the =
default. The value of having it is less opportunity for interop errors.

On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  =
wrote:

>=20
> Agree that it is a small optimization, which I put there
> because at the beginning there seemed to be a lot of worry
> on every extra AVP ;-)
>=20
> I prefer having the AVP optional but with a default value
> just like it is now. We have the same for the reduction
> percentage and the validity time as well.
>=20
> - Jouni
>=20
> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:
>=20
>> Hi Mcruz
>>=20
>> The current description indicates that when not present the OLR is of =
type Host, which was fine for me and keeps my preference.=20
>> We may have  deployments where Realm OLR is not used, or where =
statistically the HOST type is the most frequent, so to have the grouped =
OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a =
small optimization.
>>=20
>> Best regards
>>=20
>> JJacques=20
>>=20
>>=20
>>=20
>>=20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de =
lionel.morand@orange.com
>> Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46
>> =C0 : dime@ietf.org; maria.cruz.bartolome@ericsson.com
>> Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>=20
>> Hi Maria Cruz,
>>=20
>> I'm assuming that you mean "required" instead of "mandatory", right?
>>=20
>> So instead of:
>>=20
>>  OC-OLR ::=3D < AVP Header: TBD2 >
>>             < OC-Sequence-Number >
>>             [ OC-Report-Type ]
>>             [ OC-Reduction-Percentage ]
>>             [ OC-Validity-Duration ]
>>           * [ AVP ]
>>=20
>> You would prefer:
>>=20
>>  OC-OLR ::=3D < AVP Header: TBD2 >
>>             < OC-Sequence-Number >
>>             { OC-Report-Type }
>>             [ OC-Reduction-Percentage ]
>>             [ OC-Validity-Duration ]
>>           * [ AVP ]
>>=20
>> And I'm fine with this proposal.
>>=20
>> Cheers,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue =
tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 : =
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] =
[dime] #54: OC-Report-Type as mandatory AVP
>>=20
>> #54: OC-Report-Type as mandatory AVP
>>=20
>> Now in chapter 4.6:
>>=20
>>   The default value of the OC-Report-Type AVP is 0 (i.e. the host
>>   report).
>>=20
>> This AVP is always required, right? Then, I think it is more precise =
that  we define this AVP as mandatory.
>>=20
>> --=20
>> =
-----------------------------------------------+------------------------
>> -----------------------------------------------+---
>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>    Type:  defect                             |  Bartolom=E9
>> Priority:  major                              |     Status:  new
>> Component:  draft-docdt-dime-ovli              |  Milestone:
>> Severity:  Active WG Document                 |    Version:  1.0
>>                                              |   Keywords:
>> =
-----------------------------------------------+------------------------
>> -----------------------------------------------+---
>>=20
>> Ticket URL: 
>> dime 
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 14 14:22:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA31A01E0 for ; Fri, 14 Feb 2014 14:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnJln7hDbVji for ; Fri, 14 Feb 2014 14:21:53 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A16D11A0252 for ; Fri, 14 Feb 2014 14:21:52 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1EMLYmd054863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 16:21:44 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <52FCBBF7.7000700@usdonovans.com>
Date: Fri, 14 Feb 2014 16:21:27 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <32578_1392038726_52F8D345_32578_229_1_6B7134B31289DC4FAF731D844122B36E4974D3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qEd4YAv1Xm9RkYMGs5OPPtAqGWw
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 22:21:54 -0000

(Apologies for coming late to this thread)

On Feb 13, 2014, at 6:35 AM, Steve Donovan  =
wrote:

> Ok, Ok, no reason to gang up on me. :-)
> What we have here is an overload report to reduce realm routed =
requests.  I think we should be explicit in the draft to define it as =
such.
>=20

At the risk of joining the anti-Steve gang, I feel the need to belatedly =
mention that my personal intent way back when we talked about the =
mixed-state problem was that realm reports applied to realm-routed =
requests.=20

> I am still concerned that we do not have a way to indicate overload of =
the realm as a whole.  I'll enter a new trouble ticket to capture this =
issue.
>=20

I do not object to adding that ability. Would it be a new OLR type? If =
so, would it need to go in the base draft or could it be an extension?

> Steve


From nobody Fri Feb 14 14:30:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570D11A01B4 for ; Fri, 14 Feb 2014 14:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2gJ0oj22hyf for ; Fri, 14 Feb 2014 14:30:07 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37FFA1A00A7 for ; Fri, 14 Feb 2014 14:30:07 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1EMTuFj055196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 16:30:03 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <52F91354.4090101@usdonovans.com>
Date: Fri, 14 Feb 2014 16:29:52 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <80595915-0FB5-456B-B2B6-67CC86C0B975@nostrum.com>
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F9056B.6010405@usdonovans.com> <10970_1392053371_52F90C7A_10970_2992_1_6B7134B31289DC4FAF731D844122B36E497E39@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F91354.4090101@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QEnM0kRoXJF-8NqDaYkj9lt7Qlo
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Feb 2014 22:30:09 -0000

On Feb 10, 2014, at 11:58 AM, Steve Donovan  =
wrote:

> I agree that a clarification is needed on what it means to be "treated =
as is the OC-Validity-Duration AVP was not present".  It would e better =
to say:
>=20
>   "Invalid validity duration values are given the default value".
>=20
>=20

+1.

I recognize this is different from what I said about reduction =
percentage. My reasoning is, if the sender includes an invalid duration, =
we don't know the intended duration. But since there is a default =
duration, we can assume it. Reduction-Percentage, however, has no such =
default (nor should it.). If we get an invalid reduction percentage, we =
really have no idea what the sender intended us to do.


>=20
> Steve
>=20
> On 2/10/14 11:29 AM, lionel.morand@orange.com wrote:
>> Hi Steve,
>> =20
>> About the OC-Validity-Reduction AVP values greater than 24 hours, it =
is said that the default value 5s applies.
>> =20
>> I was therefore wondering if it should be also considered as an error =
and therefore discarded. It is a real open question. Not an issue per se =
as I'm fine with the existing text. I was reacting on the reason for =
change explained by Ben.
>> =20
>> Regards,
>> =20
>> Lionel
>> =20
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>> Envoy=E9 : lundi 10 f=E9vrier 2014 17:59
>> =C0 : dime@ietf.org
>> Objet : Re: [Dime] [dime] #47: reduction percentages greater than 100 =
should be ignored
>> =20
>> It is possible, the range defined is zero to 24 hours.  I think the =
text is correct as it says that a value out of this range should be =
ignored.
>>=20
>> Steve
>>=20
>> On 2/10/14 10:50 AM, Ben Campbell wrote:
>> =20
>> On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:
>> =20
>> Hi Ben,
>> =20
>> OK with this statement.
>> But if it is agreed, would it mean that the same consideration should =
apply for the OC-Validity-Duration AVP values?
>> =20
>> =20
>> I'm not sure I follow the question. Is it possible to send an invalid =
OC-Validity-Duration value?
>> =20
>> Lionel
>> =20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue =
tracker
>> Envoy=E9 : vendredi 7 f=E9vrier 2014 23:05
>> =C0 : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
>> Cc : dime@ietf.org
>> Objet : [Dime] [dime] #47: reduction percentages greater than 100 =
should be ignored
>> =20
>> #47: reduction percentages greater than 100 should be ignored
>> =20
>> Section 4.7 says " [Reduction-Percentage] Values greater than 100 are
>> interpreted as 100."
>> =20
>> An OLR with an invalid value should be ignored. An invalid value =
indicates
>> incorrect behavior on the part of the sender. In this case, it's not =
safe
>> to assume we know what the sender really intended.
>> =20
>> --=20
>> =
-------------------------+------------------------------------------------=
-
>> Reporter:               |      Owner:  draft-docdt-dime-
>>  ben@nostrum.com        |  ovli@tools.ietf.org
>>     Type:  defect       |     Status:  new
>> Priority:  minor        |  Milestone:
>> Component:  draft-       |    Version:  1.0
>>  docdt-dime-ovli        |   Keywords:
>> Severity:  Active WG    |
>>  Document               |
>> =
-------------------------+------------------------------------------------=
-
>> =20
>> Ticket URL: 
>> dime 
>> =20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>> =20
>> =
__________________________________________________________________________=
_______________________________________________
>> =20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>> =20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>> =20
>> =20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>> =20
>> =20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 14 15:29:29 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09B1A04E7; Fri, 14 Feb 2014 15:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9vp76qi_dF1; Fri, 14 Feb 2014 15:29:21 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5291A04C1; Fri, 14 Feb 2014 15:29:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140214232920.5714.50989.idtracker@ietfa.amsl.com>
Date: Fri, 14 Feb 2014 15:29:20 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LaL9EbTTBe7P7DYNZrsyIj0Eb1k
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-03.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Feb 2014 23:29:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

        Title           : Diameter Group Signaling
        Authors         : Mark Jones
                          Marco Liebsch
                          Lionel Morand
	Filename        : draft-ietf-dime-group-signaling-03.txt
	Pages           : 28
	Date            : 2014-02-14

Abstract:
   In large network deployments, a single Diameter peer can support over
   a million concurrent Diameter sessions.  Recent use cases have
   revealed the need for Diameter peers to apply the same operation to a
   large group of Diameter sessions concurrently.  The Diameter base
   protocol commands operate on a single session so these use cases
   could result in many thousands of command exchanges to enforce the
   same operation on each session in the group.  In order to reduce
   signaling, it would be desirable to enable bulk operations on all (or
   part of) the sessions managed by a Diameter peer using a single or a
   few command exchanges.  This document specifies the Diameter protocol
   extensions to achieve this signaling optimization.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-group-signaling-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-group-signaling-03


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

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


From nobody Fri Feb 14 22:15:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ECB1A0041 for ; Fri, 14 Feb 2014 22:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R15s7Jgv-kWw for ; Fri, 14 Feb 2014 22:14:55 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 030EC1A003D for ; Fri, 14 Feb 2014 22:14:54 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6A5DA3243F9; Sat, 15 Feb 2014 07:14:52 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4CD414C056; Sat, 15 Feb 2014 07:14:52 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 15 Feb 2014 07:14:51 +0100
From: 
To: Ben Campbell , "Wiehe, Ulrich (NSN - DE/Munich)" 
Thread-Topic: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
Thread-Index: AQHPKdEKa0SZ1wdbvEGvoj4P8RAtnpq10DMg
Date: Sat, 15 Feb 2014 06:14:50 +0000
Message-ID: <28646_1392444892_52FF05DC_28646_16198_1_6B7134B31289DC4FAF731D844122B36E4A5F9C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net> <1! 0158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.212114
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Hi7Jqe83i2N9FMabnov6j7AQWJ4
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 15 Feb 2014 06:14:58 -0000

   REQ 16: The solution is likely to be deployed incrementally.  The
           solution MUST support a mixed environment where some, but not
           all, nodes implement it.

   REQ 18: In a mixed environment of nodes that support the solution and
           nodes that do not, the solution MUST NOT preclude elements
           that support overload control from treating elements that do
           not support overload control in an equitable fashion relative
           to those that do.  Users and operators of nodes that do not
           support the solution MUST NOT unfairly benefit from the
           solution.  The solution specification SHOULD provide guidance
           to implementors for dealing with elements not supporting
           overload control.

Theses requirements are also fulfilled if servers or agents are able to han=
dle clients that do not support DOIC and if client and agents are able to r=
eact to implicit overload indication received from the network.

In summary, I really don't see what is missing.

Lionel


-----Message d'origine-----
De=A0: Ben Campbell [mailto:ben@nostrum.com]=20
Envoy=E9=A0: vendredi 14 f=E9vrier 2014 23:07
=C0=A0: Wiehe, Ulrich (NSN - DE/Munich)
Cc=A0: MORAND Lionel IMT/OLN; ext Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messag=
es


On Feb 14, 2014, at 8:59 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> I think that two points are mixed:
>=20
> 1) For efficiency, a DOIC-enabled client should be able to mitigate (poss=
ible) overload situation even if explicit indication is not received from t=
he network.
> 2) DOIC-enabled clients having a different behavior regarding support or =
not of DOIC by server.
>=20
> if I agree with the first one, I disagree with the second one. The basic =
assumption is that a DOIC client will not throttle the traffic in absence o=
f overload indication (explicit or implicit). And throttling will be perfor=
med as soon as an indication is received (explicit or implicit) if the clie=
nt is designed for that (it supports DOIC or/and default behavior has been =
defined on reception of TOO_BUSY or non-response).
>=20
> It is the only thing that matters today.

I disagree, for  reasons stated earlier. In summary, the requirement that r=
eacting nodes be able to take different action depending on whether an oppo=
site endpoint supports DOIC is a direct implication of requirements 16 and =
18 of RFC 7068.

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Sat Feb 15 15:03:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0621A02F1; Sat, 15 Feb 2014 15:03:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mbIDKgxaEOC; Sat, 15 Feb 2014 15:03:06 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD261A00F5; Sat, 15 Feb 2014 15:03:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D7118224017A; Sun, 16 Feb 2014 00:03:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugd6qGcOh1Du; Sun, 16 Feb 2014 00:03:03 +0100 (CET)
Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 717112240128; Sun, 16 Feb 2014 00:03:02 +0100 (CET)
Message-ID: <52FFF22A.5010802@deployingradius.com>
Date: Sat, 15 Feb 2014 18:03:06 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stefan Winter 
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu>
In-Reply-To: <52FDDD10.1050306@restena.lu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/G7fOfiGpfT1hCyQy0WzAJkSluR8
Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" 
Subject: Re: [Dime] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 15 Feb 2014 23:03:08 -0000

  Some comments:

Section 3:

   ... EAP-
   Response/Identity does not carry encoding information itself, so a
   conversion between a non-UTF-8 encoding and UTF-8 is not possible for
   the AAA entity doing the EAP-Response/Identity to User-Name copying.

  I'm unsure about this.  The EAP-Response/Identity field is *supposed*
to be UTF-8.  So if it's not, the supplicant is non-compliant, and
anything can happen.

  I think the recommendation here for EAP to RADIUS gateways (e.g.
Access Points) is to do as little translation as possible.  They should
just copy the Identity blob into the User-Name attribute.

  The next paragraph does explain why this is a problem, but the quoted
text above seems misleading to me.  The AAA entity *can* copy the
EAP-Response/Identity to User-Name.  It's just data, so that copying is
always possible.


   Consequence: If an EAP method's username is not encoded in UTF-8, and

  I would suggest "user identifier", to avoid confusion with User-Name.

   the EAP peer verbatimly uses that method's notion of a username for
   its EAP-Response/Identity field, then the AAA entity is forced to
   violate its own specification because it has to, but can not use
   UTF-8 for its own User-Name attribute.  This jeopardizes the
   subsequent EAP authentication as a whole; request routing may fail or
   lead to a wrong destinationi, or the AAA payload may be discarded by
   the recipient due to the malformedness of the User-Name attribute.


  That is all true.  I would note that the EAP-Response/Identity field
does *not* have to be taken from the EAP methods user identifier field.
 They can be completely different.

  That should be noted here.  Where the EAP methods user identifier
field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible
string for the EAP-Response/Identity field.  How it gets that string is
implementation dependent. :(

Section 4:

   Where usernames between configured EAP types in an EAP peer differ,
   the EAP peer can not rely on the EAP type negotiation mechanism alone
   to provide useful results.  If an EAP authentication gets rejected,
   the EAP peer SHOULD re-try the authentication using a different EAP-
   Response/Identity than before.  The EAP peer SHOULD try all usernames
   from the entire set of configured EAP types before declaring final
   authentication failure.

  I see why this can be necessary, but it's ugly.

   EAP peers need to maintain state on the encoding of the usernames
   which are used in their locally configured EAP types.  When
   constructing an EAP-Response/Identity from that username information,
   they SHOULD (re-)encode that username as UTF-8 and use the resulting
   value for the EAP-Response/Identity.  If the EAP type is configured
   for the use of anonymous outer identities, the desired outer identity
   should also be (re-)encoded in UTF-8 encoding before being put into
   the EAP-Response/Identity.

 I would add "or allow the provisioning of an EAP-Response/Identity
field independent form the EAP method user identifier"

Section 5

  It may be worth noting that supplicants should try the most secure EAP
methods first (i.e. ones with anonymous outer identity).  If those fail,
they should proceed to more insecure methods.  This prevents leakage.

  Also, supplicants could cache information about successful
authentications.  If the system appears to be "the same" as one where
EAP method X previously worked, it makes sense to start off with EAP
method X.

  How the supplicant determines that this is "the same" system is a
subject for discussion.

  Alan DeKok.


From nobody Mon Feb 17 01:02:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1961A0148; Mon, 17 Feb 2014 01:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.853
X-Spam-Level: 
X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.548, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKl3Z80X3Cp0; Mon, 17 Feb 2014 01:02:46 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id AACFC1A02C3; Mon, 17 Feb 2014 01:02:45 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id EC64E10580; Mon, 17 Feb 2014 10:02:41 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id D12F91057E; Mon, 17 Feb 2014 10:02:41 +0100 (CET)
Message-ID: <5301D017.8060302@restena.lu>
Date: Mon, 17 Feb 2014 10:02:15 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Alan DeKok 
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com>
In-Reply-To: <52FFF22A.5010802@deployingradius.com>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K"
X-Virus-Scanned: ClamAV
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KVL1VBXlIMma9B787vL9f66C2Wc
Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" 
Subject: Re: [Dime] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 09:02:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K
Content-Type: multipart/mixed;
 boundary="------------050000050108010500010704"

This is a multi-part message in MIME format.
--------------050000050108010500010704
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

> Section 3:
>=20
>    ... EAP-
>    Response/Identity does not carry encoding information itself, so a
>    conversion between a non-UTF-8 encoding and UTF-8 is not possible fo=
r
>    the AAA entity doing the EAP-Response/Identity to User-Name copying.=

>=20
>   I'm unsure about this.  The EAP-Response/Identity field is *supposed*=

> to be UTF-8.  So if it's not, the supplicant is non-compliant, and
> anything can happen.

Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1
on the "Identity" packet does not mention UTF-8 for the *Response* at all=
=2E

It mentions that the *request* MAY contain displayable text, which needs
to be UTF-8 if present.

For response, no encoding is mandated. The RFC even mentions weirdnesses
such as an intermediate NUL character followed by "various options" -
but only notes them, they are not forbidden. The use of such a construct
breaks the UTF-8 requirement.

I totally agree that anything besides UTF-8 in the Response is a bad
idea, and these days hopefully a seldom find - but it should be said
someplace that it's outright forbidden.

Which reminds me that my text speaks of SHOULD NOT in the
recommendations (given that I've preliminarily aimed for BCP status, I
found a MUST NOT not to be fitting; but maybe it is more spot on
nontheless).

>   I think the recommendation here for EAP to RADIUS gateways (e.g.
> Access Points) is to do as little translation as possible.  They should=

> just copy the Identity blob into the User-Name attribute.

And do what if they find that the blob is not UTF-8? Drop the packet?
Forward anyway?

>   The next paragraph does explain why this is a problem, but the quoted=

> text above seems misleading to me.  The AAA entity *can* copy the
> EAP-Response/Identity to User-Name.  It's just data, so that copying is=

> always possible.

Sure; but you create a malformed packet with it - so everybody who
consumes that data is at a gamble.

>    Consequence: If an EAP method's username is not encoded in UTF-8, an=
d
>=20
>   I would suggest "user identifier", to avoid confusion with User-Name.=


Sure, no problem.

>    the EAP peer verbatimly uses that method's notion of a username for
>    its EAP-Response/Identity field, then the AAA entity is forced to
>    violate its own specification because it has to, but can not use
>    UTF-8 for its own User-Name attribute.  This jeopardizes the
>    subsequent EAP authentication as a whole; request routing may fail o=
r
>    lead to a wrong destinationi, or the AAA payload may be discarded by=

>    the recipient due to the malformedness of the User-Name attribute.
>=20
>=20
>   That is all true.  I would note that the EAP-Response/Identity field
> does *not* have to be taken from the EAP methods user identifier field.=

>  They can be completely different.

Will do (the completely different content would be the outer identity).

>   That should be noted here.  Where the EAP methods user identifier
> field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible
> string for the EAP-Response/Identity field.  How it gets that string is=

> implementation dependent. :(

Yes, that's why I wrote the (somewhat hollow) statement that it "needs
to maintain state of the encoding used". How it does that... no spec can
mandate.

> Section 4:
>=20
>    Where usernames between configured EAP types in an EAP peer differ,
>    the EAP peer can not rely on the EAP type negotiation mechanism alon=
e
>    to provide useful results.  If an EAP authentication gets rejected,
>    the EAP peer SHOULD re-try the authentication using a different EAP-=

>    Response/Identity than before.  The EAP peer SHOULD try all username=
s
>    from the entire set of configured EAP types before declaring final
>    authentication failure.
>=20
>   I see why this can be necessary, but it's ugly.

I totally agree that it's ugly. Adding "Note: That is ugly." to the spec
doesn't provide much added value though :-)

I feel strong about stating the problem though. We had an actual
real-life support case from a device manufacturer whose handset
customers couldn't use eduroam and the manufacturer said our RADIUS
infrastructure is broken, because it always rejects before they can even
try the configured EAP-TTLS that the user sets.

It was totally unthinkable for them that someone would not have a
business relationship with 3GPP and that always trying the same 3GPP
user identifier when starting EAP would lead nowhere.

After a lot of explaining and escalation to some senior engineering, we
could make that clear, and the firmware got a fix. Having this described
in an RFC to point to will certainly help if such states of mind pop up
again someplace in the future.

>    EAP peers need to maintain state on the encoding of the usernames
>    which are used in their locally configured EAP types.  When
>    constructing an EAP-Response/Identity from that username information=
,
>    they SHOULD (re-)encode that username as UTF-8 and use the resulting=

>    value for the EAP-Response/Identity.  If the EAP type is configured
>    for the use of anonymous outer identities, the desired outer identit=
y
>    should also be (re-)encoded in UTF-8 encoding before being put into
>    the EAP-Response/Identity.
>=20
>  I would add "or allow the provisioning of an EAP-Response/Identity
> field independent form the EAP method user identifier"

Well... that degree of freedom exists - outer ID *is* independent from
the EAP method's user identifier.

I'm not sure what the effect of this (third!) notion of (non-)identity
could add? The example of the 3GPP vs. realm.example shows that there
may well be *no* common EAP-Response/Identity which actually fits all
configured EAP types.

> Section 5
>=20
>   It may be worth noting that supplicants should try the most secure EA=
P
> methods first (i.e. ones with anonymous outer identity).  If those fail=
,
> they should proceed to more insecure methods.  This prevents leakage.

Good idea!

>   Also, supplicants could cache information about successful
> authentications.  If the system appears to be "the same" as one where
> EAP method X previously worked, it makes sense to start off with EAP
> method X.
>=20
>   How the supplicant determines that this is "the same" system is a
> subject for discussion.

Interesting thought, and a bit complex. I suggest we discuss this when
the draft gets adopted in ... "some" working group. Suggestions welcome :=
-)

Greetings,

Stefan Winter


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education=
 Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66

--------------050000050108010500010704
Content-Type: application/pgp-keys;
 name="0x8A39DC66.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x8A39DC66.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)

mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je
miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb
Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr
b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj
l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB
e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/
3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg
BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a
smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl
97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C
BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB
tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50
ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo
R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0
qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++
/qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt
y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5
9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22
lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2
CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa
9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY
n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT
aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl
8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o
vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp
n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe
qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK
BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj
8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj
mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC
iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU
dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+
2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr
NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/
PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR
4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU
TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu
DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN
jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK
UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv
/o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp
jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv
JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf
C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+
od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi
u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+
km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m
5zP5og=3D=3D
=3D3NUt
-----END PGP PUBLIC KEY BLOCK-----

--------------050000050108010500010704--

--gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTAdAXAAoJEMDeajWKOdxmX44P/jsmlCv0nGs46+wfLCtki4yv
++3m3QiE8jk5KW1Vd2YV0ybTljPCbkZCD+w35cZmFY3yGGeyM8jxvo+GHiInmnf3
BKuK4yI2FpgjE0PZUpPNqYXKRr6FlKEUnPPqsr70xPCie/g+d8M+9MW+fOIwpxqt
J24O7M98jDv6cJfLS2GbEDcqg4s/PjGIeSogveQKLsoaQaDaoMRhJmdzt2CyXbZt
UyA4CxjxiBEgKVNjkXsM0XW74a5RMOJCelLNXYGAflp2RAoQ2kzg/qJJdXz2d3ZX
6L6AF6Qs5fH2haLq+zj0lVUlyUN+6RlN1yEuZQxOzqGhvpf1fIyM1tKnivEwtq4x
KdCPE7/EoNkSVkKEfeHkqOHulKuL3WeYcDrHJTCq24CMYSM1H+8WKkLcDDSrNmqy
IQhdkdjoi2cZba4UP1MVeTi6yCdEx68yYfd/CyaUdw5Kdqg1ydnEgdf8e+TuCr4O
oqrE136Py9qXahfs7DT0f84pE1n9k6Bl99zVy8NkBVHx0z+PyEftyRsIcwVn48ED
zx9DPfT6KCgT2eP4d0f+5Vt9cIZJHoiJKVJhUmqFdXXhyV3aRShIlHRQToybqUHu
R/tshmg5A30Mwe6wgAqPEpAP31SRYbv/hS4QEsVk0RclAvkP4ShAXOmUrK/ODrZ+
HNGDPwAa+s1R8Fhlvtrk
=s/V4
-----END PGP SIGNATURE-----

--gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K--


From nobody Mon Feb 17 05:37:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE9C1A04D8; Mon, 17 Feb 2014 05:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtfUAvyaNWGU; Mon, 17 Feb 2014 05:37:03 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 082B21A01EA; Mon, 17 Feb 2014 05:37:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8817D2240186; Mon, 17 Feb 2014 14:36:28 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmzz3aXNsDPi; Mon, 17 Feb 2014 14:36:28 +0100 (CET)
Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 39D6C22400A9; Mon, 17 Feb 2014 14:36:27 +0100 (CET)
Message-ID: <5302105C.6070103@deployingradius.com>
Date: Mon, 17 Feb 2014 08:36:28 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stefan Winter 
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu>
In-Reply-To: <5301D017.8060302@restena.lu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3rhq6NpiQqBroZ_KFmb5sAs5nWM
Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" 
Subject: Re: [Dime] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 13:37:06 -0000

Stefan Winter wrote:
> Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1
> on the "Identity" packet does not mention UTF-8 for the *Response* at all.
> 
> It mentions that the *request* MAY contain displayable text, which needs
> to be UTF-8 if present.

  That's worse than I remembered.

> For response, no encoding is mandated. The RFC even mentions weirdnesses
> such as an intermediate NUL character followed by "various options" -
> but only notes them, they are not forbidden. The use of such a construct
> breaks the UTF-8 requirement.
> 
> I totally agree that anything besides UTF-8 in the Response is a bad
> idea, and these days hopefully a seldom find - but it should be said
> someplace that it's outright forbidden.

  I agree.

>>   I think the recommendation here for EAP to RADIUS gateways (e.g.
>> Access Points) is to do as little translation as possible.  They should
>> just copy the Identity blob into the User-Name attribute.
> 
> And do what if they find that the blob is not UTF-8? Drop the packet?
> Forward anyway?

  Forward anyways.  It's what they do now.  We can't mandate that 10^9
EAP supplicants upgrade.  It's probably easier to fix the AAA
infrastructure to work with broken clients.

> I feel strong about stating the problem though. We had an actual
> real-life support case from a device manufacturer whose handset
> customers couldn't use eduroam and the manufacturer said our RADIUS
> infrastructure is broken, because it always rejects before they can even
> try the configured EAP-TTLS that the user sets.

  Weird.

> It was totally unthinkable for them that someone would not have a
> business relationship with 3GPP and that always trying the same 3GPP
> user identifier when starting EAP would lead nowhere.

  That's just dumb.  The way sane vendors deal with this is that they
allow the user to choose which identity to use.  It's ridiculous for the
vendor to force a particular identity on the user / device.

> After a lot of explaining and escalation to some senior engineering, we
> could make that clear, and the firmware got a fix. Having this described
> in an RFC to point to will certainly help if such states of mind pop up
> again someplace in the future.

  Yes.  The RFCs are unfortunately silent on a wide variety of topics.
RFC 2865 even says:

      The secret MUST NOT be empty (length 0) since this would allow
      packets to be trivially forged.

  Because I ran into a vendor who didn't allow admins to set a shared
secret... and always used a zero-length string.  It *was* allowed in RFC
2158.  I poked the RADIUS WG, and everyone was appalled.

>>  I would add "or allow the provisioning of an EAP-Response/Identity
>> field independent form the EAP method user identifier"
> 
> Well... that degree of freedom exists - outer ID *is* independent from
> the EAP method's user identifier.

  The idea was to allow *provisioning* of the Response/Identity.
Automatically deriving it from the method-specific "user identity" is
just as bad as automatically using a 3GPP identity.

> Interesting thought, and a bit complex. I suggest we discuss this when
> the draft gets adopted in ... "some" working group. Suggestions welcome :-)

  I'd support a "roaming inter-operations" WG.  Some of the documents
now in RADEXT could move there, and maybe DIME.  This document could
live there.

  The goal for the WG would be to define inter-domain standards for
authentication, accounting, EAP, etc.

  Alan DeKok.


From nobody Mon Feb 17 08:04:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E71A1A050E for ; Mon, 17 Feb 2014 08:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmpOam7SzKIU for ; Mon, 17 Feb 2014 08:04:29 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2A32A1A03D2 for ; Mon, 17 Feb 2014 08:04:28 -0800 (PST)
Received: from localhost ([127.0.0.1]:59105 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WFQg6-0007TH-Ix; Mon, 17 Feb 2014 17:04:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 17 Feb 2014 16:04:18 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/55
Message-ID: <066.8875fa1c8b7c849ad37eea1864d456e0@trac.tools.ietf.org>
X-Trac-Ticket-ID: 55
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qz4F1FJ5hH_onF6nlu88htNFN78
Cc: dime@ietf.org
Subject: [Dime] [dime] #55: Lack of overload control for realm overload condition
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@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, 17 Feb 2014 16:04:31 -0000

#55: Lack of overload control for realm overload condition

 The current definition of behavior for the handling of the realm overload
 report types is to throttle only requests that contain the realm (in the
 destination-realm) indicated in the realm overload report but do not
 contain a destination-host AVP.  This is really throttling of "realm
 routed requests", not throttling of traffic to the realm.

 Requirement 31 in the Diameter Overload requirements defined in RFC 7068
 includes the must requirement to be able to handle overload of the realm.
 The current draft does not address this requirement as there is currently
 no way to indicate that a realm is overloaded and to request throttling of
 all traffic to that realm.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-docdt-dime-ovli    |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Mon Feb 17 08:13:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D322B1A025F for ; Mon, 17 Feb 2014 08:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RqHoMhaoPzK for ; Mon, 17 Feb 2014 08:13:29 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 786611A0250 for ; Mon, 17 Feb 2014 08:13:29 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49228 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFQoq-0002fv-Fe; Mon, 17 Feb 2014 08:13:24 -0800
Message-ID: <5302351F.6050902@usdonovans.com>
Date: Mon, 17 Feb 2014 10:13:19 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ben Campbell 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090500070603070303040602"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HklDU0JW5nXqMCm2x12BiljYQHI
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 16:13:31 -0000

This is a multi-part message in MIME format.
--------------090500070603070303040602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I do think it would be a new report type, as it would require different
behavior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this
is the correct approach.  We are creating a good number of relatively
small extensions.  It might lead to the need to pull them all together
in a future version of the DOIC draft/RFC.

Steve

On 2/14/14 4:21 PM, Ben Campbell wrote:
> (Apologies for coming late to this thread)
>
> On Feb 13, 2014, at 6:35 AM, Steve Donovan  wrote:
>
>> Ok, Ok, no reason to gang up on me. :-)
>> What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.
>>
> At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 
>
>> I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.
>>
> I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?
>
>> Steve
>


--------------090500070603070303040602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I do think it would be a
      new report type, as it would require different behavior from reacting
      nodes.

      

      I'm ok with this being in a separate extension if the group thinks
      this is the correct approach.  We are creating a good number of
      relatively small extensions.  It might lead to the need to pull
      them all together in a future version of the DOIC draft/RFC.

      

      Steve

      

    
    
On 2/14/14 4:21 PM, Ben Campbell wrote:

    

    

      
(Apologies for coming late to this thread)

On Feb 13, 2014, at 6:35 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
Ok, Ok, no reason to gang up on me. :-)
What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.



      

      
At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 



      

        
I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.



      

      
I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?



      

        
Steve


      

      



    

    

  


--------------090500070603070303040602--


From nobody Mon Feb 17 08:18:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640EF1A04FC for ; Mon, 17 Feb 2014 08:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUEgFnrc4LGz for ; Mon, 17 Feb 2014 08:18:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 397441A04E5 for ; Mon, 17 Feb 2014 08:18:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49236 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFQtu-0008S1-1J for dime@ietf.org; Mon, 17 Feb 2014 08:18:35 -0800
Message-ID: <5302365A.8080408@usdonovans.com>
Date: Mon, 17 Feb 2014 10:18:34 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com>
In-Reply-To: <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com>
Content-Type: multipart/alternative; boundary="------------010301010406000201050004"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0gnHUP1nq6nB4qopm8G3VzEALd0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 16:18:39 -0000

This is a multi-part message in MIME format.
--------------010301010406000201050004
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

+1
On 2/14/14 3:51 PM, Ben Campbell wrote:
> On Feb 14, 2014, at 9:53 AM, lionel.morand@orange.com wrote:
>
>> In other words, I think that we should have the following cases:
>>
>> -	non-zero reduction, non-zero validity period => Valid
>> -	0 reduction, non-zero validity period => Valid (not blocking)
>> -	0 reduction, 0 validity period => Valid
>> -	non-zero reduction, 0 validity period => Invalid
>>
>> Does it make sense?
>
> I don't think so.
>
> The idea is that setting Validity-Period to zero ends an overload condition, without regard to the algorithm. Reduction-Percentage is specific to the default algorithm. I don't think we need to create an algorithm-specific rule here, at least not normatively. So I would say that a Validity-Period of zero ends overload, without regard to the algorithm, or any algorithm specific values.
>
> I recognize that interacts with my previous comment about ignoring OLRs that have invalid Reduction-Percentage values, in that you could have silly things like [reduction-percentage=14732, validity-period=0]. In that case, I think the validity period would take precedent over the invalid reduction-percentage.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------010301010406000201050004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    
On 2/14/14 3:51 PM, Ben Campbell wrote:

    

    

      
On Feb 14, 2014, at 9:53 AM, lionel.morand@orange.com wrote:



      

        
In other words, I think that we should have the following cases:

-	non-zero reduction, non-zero validity period => Valid
-	0 reduction, non-zero validity period => Valid (not blocking)
-	0 reduction, 0 validity period => Valid
-	non-zero reduction, 0 validity period => Invalid

Does it make sense?


      

      

I don't think so.

The idea is that setting Validity-Period to zero ends an overload condition, without regard to the algorithm. Reduction-Percentage is specific to the default algorithm. I don't think we need to create an algorithm-specific rule here, at least not normatively. So I would say that a Validity-Period of zero ends overload, without regard to the algorithm, or any algorithm specific values.

I recognize that interacts with my previous comment about ignoring OLRs that have invalid Reduction-Percentage values, in that you could have silly things like [reduction-percentage=14732, validity-period=0]. In that case, I think the validity period would take precedent over the invalid reduction-percentage.

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



    

    

  


--------------010301010406000201050004--


From nobody Mon Feb 17 08:39:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EC11A0405; Mon, 17 Feb 2014 08:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KAtie8bmloj; Mon, 17 Feb 2014 08:33:50 -0800 (PST)
Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 401751A03FF; Mon, 17 Feb 2014 08:33:50 -0800 (PST)
Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D71261A9CA0A_30239EAB; Mon, 17 Feb 2014 16:33:46 +0000 (GMT)
Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id AC36F1A9CA0E_30239EAF; Mon, 17 Feb 2014 16:33:46 +0000 (GMT)
Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 16:33:46 +0000
From: Josh Howlett 
To: Alan DeKok , Stefan Winter 
Thread-Topic: [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
Thread-Index: AQHPK792HMF1Fx9jgkuwstO/NcK195q5cwYAgAAxggA=
Date: Mon, 17 Feb 2014 16:33:45 +0000
Message-ID: 
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> <5302105C.6070103@deployingradius.com>
In-Reply-To: <5302105C.6070103@deployingradius.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [194.82.140.76]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6B98CB3B6689F04E92AEB0557FCCB94F@ukerna.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LGcJpKAGrz6SefYXI4th-N_9Aps
X-Mailman-Approved-At: Mon, 17 Feb 2014 08:39:22 -0800
Cc: "radext@ietf.org" , "abfab@ietf.org" , "dime@ietf.org" , "" 
Subject: Re: [Dime] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 16:33:52 -0000

>
>> Interesting thought, and a bit complex. I suggest we discuss this when
>> the draft gets adopted in ... "some" working group. Suggestions welcome
>>:-)
>
>  I'd support a "roaming inter-operations" WG.  Some of the documents
>now in RADEXT could move there, and maybe DIME.  This document could
>live there.
>
>  The goal for the WG would be to define inter-domain standards for
>authentication, accounting, EAP, etc.

+1, excellent idea. draft-wierenga-ietf-eduroam, if generalised, could
provide a good basis on which to define the issues that need addressing.
If it were broader than "roaming" then ABFAB could also fall into scope.

Josh.



Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20
not-for-profit company which is registered in England under No. 2881024=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238


From nobody Mon Feb 17 09:43:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5811A0405 for ; Mon, 17 Feb 2014 09:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLb5BYJSq_dJ for ; Mon, 17 Feb 2014 09:43:43 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 04EFC1A00FB for ; Mon, 17 Feb 2014 09:43:42 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1HHhcmI007808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Feb 2014 11:43:39 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1HHhbfE010989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 18:43:37 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 17 Feb 2014 18:43:37 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE88aqIYhHfy6k2vf6t9AbBIc5quSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8ICAABIAAIAAoHoQgADRmYCAAGkdsIAAWBQAgARZ6wCAACdQ4A==
Date: Mon, 17 Feb 2014 17:43:37 +0000
Message-ID: 
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com>
In-Reply-To: <5302365A.8080408@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026697BCFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/UIl12YzRINJhvO0ZheKcE1h8cH8
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 17:43:46 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026697BCFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I am OK with the 3 first Lionel's statements.

Regarding the 4th one (non-zero reduction, 0 validity period =3D> Invalid),=
 I think that, as Ben proposed,  the zero validity  period prevails whateve=
r the value of traffic reduction %.

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 17 f=E9vrier 2014 17:19
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

+1
On 2/14/14 3:51 PM, Ben Campbell wrote:



On Feb 14, 2014, at 9:53 AM, lionel.morand@orange.com wrote:



In other words, I think that we should have the following cases:



-  non-zero reduction, non-zero validity period =3D> Valid

-  0 reduction, non-zero validity period =3D> Valid (not blocking)

-  0 reduction, 0 validity period =3D> Valid

-  non-zero reduction, 0 validity period =3D> Invalid



Does it make sense?





I don't think so.



The idea is that setting Validity-Period to zero ends an overload condition=
, without regard to the algorithm. Reduction-Percentage is specific to the =
default algorithm. I don't think we need to create an algorithm-specific ru=
le here, at least not normatively. So I would say that a Validity-Period of=
 zero ends overload, without regard to the algorithm, or any algorithm spec=
ific values.



I recognize that interacts with my previous comment about ignoring OLRs tha=
t have invalid Reduction-Percentage values, in that you could have silly th=
ings like [reduction-percentage=3D14732, validity-period=3D0]. In that case=
, I think the validity period would take precedent over the invalid reducti=
on-percentage.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_E194C2E18676714DACA9C3A2516265D2026697BCFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

I am OK with the 3 first =
Lionel’s statements.


 <=
/p>

Regarding the 4th one (non-zero reduction, 0 validity period =3D> Invalid), I think th=
at, as Ben proposed,  the zero validity  period prevails whatever
 the value of traffic reduction %.  


 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 17 f=E9vrier 2014 17:19

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 =
disallowed?






 


+1




On 2/14/14 3:51 PM, Ben Campbell wrote:





 


On Feb 14, 2014, at 9:53 AM, lionel.morand@orange.com wrote:


 




In other words, I think that we should have the following cases:<=
/o:p>


 


-  non-zero reduction, non-zero validity period =3D> Valid


-  0 reduction, non-zero validity period =3D> Valid (not block=
ing)


-  0 reduction, 0 validity period =3D> Valid


-  non-zero reduction, 0 validity period =3D> Invalid


 


Does it make sense?




 


 


I don't think so.


 


The idea is that setting Validity-Period to zero ends an overload cond=
ition, without regard to the algorithm. Reduction-Percentage is specific to=
 the default algorithm. I don't think we need to create an algorithm-specif=
ic rule here, at least not normatively. So I would say that a Validity-Peri=
od of zero ends overload, without regard to the algorithm, or any algorithm=
 specific values.


 


I recognize that interacts with my previous comment about ignoring OLR=
s that have invalid Reduction-Percentage values, in that you could have sil=
ly things like [reduction-percentage=3D14732, validity-period=3D0]. In that=
 case, I think the validity period would take precedent over the invalid re=
duction-percentage.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_E194C2E18676714DACA9C3A2516265D2026697BCFR712WXCHMBA12z_--


From nobody Mon Feb 17 09:53:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05E41A0527 for ; Mon, 17 Feb 2014 09:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUmjDUORaO5L for ; Mon, 17 Feb 2014 09:53:20 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 55C771A051E for ; Mon, 17 Feb 2014 09:53:20 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1HHrGva015833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Feb 2014 11:53:17 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1HHrFcq018829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 18:53:15 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 17 Feb 2014 18:53:15 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIcx34wrZRRvx1EKFdFq4TjstmpqmsICAgAAE6ICAABUugIACvZWAgAAwCoCAADL/AIAEjBxA///7RACAABhCgIABTnoAgAACQICAADisgIAADXYAgAAEyICAAAGagIAAZP8wgAAbz4CAAnLKgIACNiuAgARQJICAACoWIA==
Date: Mon, 17 Feb 2014 17:53:14 +0000
Message-ID: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>
In-Reply-To: <5302351F.6050902@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026697DEFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Cnf-HYXNg5VGR5Izn06yISQyB8g
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 17:53:23 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026697DEFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I share the view to analyze the overload of the realm as a whole in a separ=
ate extension  and see if this lead to another report type.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 17 f=E9vrier 2014 17:13
=C0 : Ben Campbell
Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I do think it would be a new report type, as it would require different beh=
avior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively small ex=
tensions.  It might lead to the need to pull them all together in a future =
version of the DOIC draft/RFC.

Steve
On 2/14/14 4:21 PM, Ben Campbell wrote:

(Apologies for coming late to this thread)



On Feb 13, 2014, at 6:35 AM, Steve Donovan  wrote:



Ok, Ok, no reason to gang up on me. :-)

What we have here is an overload report to reduce realm routed requests.  I=
 think we should be explicit in the draft to define it as such.





At the risk of joining the anti-Steve gang, I feel the need to belatedly me=
ntion that my personal intent way back when we talked about the mixed-state=
 problem was that realm reports applied to realm-routed requests.



I am still concerned that we do not have a way to indicate overload of the =
realm as a whole.  I'll enter a new trouble ticket to capture this issue.





I do not object to adding that ability. Would it be a new OLR type? If so, =
would it need to go in the base draft or could it be an extension?



Steve






--_000_E194C2E18676714DACA9C3A2516265D2026697DEFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

I share the view to analy=
ze the overload of the realm as a whole in a separate extension  and s=
ee if this lead to another report type.


 <=
/p>

Best regards


 <=
/p>

JJacques



  


 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 17 f=E9vrier 2014 17:13

=C0 : Ben Campbell

Cc : dime@ietf.org list

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
o:p>






 


I do think it would b=
e a new report type, as it would require different behavior from reacting n=
odes.



I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively sma=
ll extensions.  It might lead to the need to pull them all together in=
 a future version of the DOIC draft/RFC.



Steve




On 2/14/14 4:21 PM, Ben Campbell wrote:





(Apologies for coming late to this thread)


 


On Feb 13, 2014, at 6:35 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Ok, Ok, no reason to gang up on me. :-)


What we have here is an overload report to reduce realm routed request=
s.  I think we should be explicit in the draft to define it as such.


 




 


At the risk of joining the anti-Steve gang, I feel the need to belated=
ly mention that my personal intent way back when we talked about the mixed-=
state problem was that realm reports applied to realm-routed requests. 


 




I am still concerned that we do not have a way to indicate overload of=
 the realm as a whole.  I'll enter a new trouble ticket to capture thi=
s issue.


 




 


I do not object to adding that ability. Would it be a new OLR type? If=
 so, would it need to go in the base draft or could it be an extension?


 




Steve




 


 




 






--_000_E194C2E18676714DACA9C3A2516265D2026697DEFR712WXCHMBA12z_--


From nobody Mon Feb 17 10:08:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6BC1A0101 for ; Mon, 17 Feb 2014 10:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEB72-TQ4COm for ; Mon, 17 Feb 2014 10:08:10 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7721A002C for ; Mon, 17 Feb 2014 10:08:09 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id C0E1C2DC11F; Mon, 17 Feb 2014 19:08:06 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A642235C090; Mon, 17 Feb 2014 19:08:06 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 19:08:06 +0100
From: 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPK/vsaYTCEYEr3kWQnSaFR4Y26Jq5pteAgAAU3oA=
Date: Mon, 17 Feb 2014 18:08:05 +0000
Message-ID: <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/megMpzlVFL-Dd-hbX8aQtAloAuc
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 18:08:12 -0000

I would like to highlight that my proposal is not related to the default Re=
duction-percentage algo.

Whatever the ago used, I think that an OLR can only be sent for two purpose=
s:
- Send an indication of overload situation
- Send an indication of end of the overload situation

For me, providing both indications in the same message would be a non-sense=
. And I don't understand why the validity period would prevail in that case.

Now, if what is argued by Ben and supported by JJ and Steve is clear for th=
e rest of the group, I will not fight.

Regards,

lionel

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
Envoy=E9=A0: lundi 17 f=E9vrier 2014 18:44
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Hi
=A0
I am OK with the 3 first Lionel's statements.
=A0
Regarding the 4th one (non-zero reduction, 0 validity period =3D> Invalid),=
 I think that, as Ben proposed, =A0the zero validity =A0period prevails wha=
tever the value of traffic reduction %. =A0
=A0
Best regards
=A0
JJacques=20
=A0
=A0
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: lundi 17 f=E9vrier 2014 17:19
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
=A0
+1
On 2/14/14 3:51 PM, Ben Campbell wrote:
=A0
On Feb 14, 2014, at 9:53 AM, lionel.morand@orange.com wrote:
=A0
In other words, I think that we should have the following cases:
=A0
-=A0 non-zero reduction, non-zero validity period =3D> Valid
-=A0 0 reduction, non-zero validity period =3D> Valid (not blocking)
-=A0 0 reduction, 0 validity period =3D> Valid
-=A0 non-zero reduction, 0 validity period =3D> Invalid
=A0
Does it make sense?
=A0
=A0
I don't think so.
=A0
The idea is that setting Validity-Period to zero ends an overload condition=
, without regard to the algorithm. Reduction-Percentage is specific to the =
default algorithm. I don't think we need to create an algorithm-specific ru=
le here, at least not normatively. So I would say that a Validity-Period of=
 zero ends overload, without regard to the algorithm, or any algorithm spec=
ific values.
=A0
I recognize that interacts with my previous comment about ignoring OLRs tha=
t have invalid Reduction-Percentage values, in that you could have silly th=
ings like [reduction-percentage=3D14732, validity-period=3D0]. In that case=
, I think the validity period would take precedent over the invalid reducti=
on-percentage.
=A0
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
=A0
=A0

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Mon Feb 17 10:45:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713A11A03FB for ; Mon, 17 Feb 2014 10:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0z80w135rdZ for ; Mon, 17 Feb 2014 10:44:58 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DCD801A0239 for ; Mon, 17 Feb 2014 10:44:57 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1HIipSG013085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 12:44:53 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Mon, 17 Feb 2014 12:44:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <579DC2BE-CC3C-43E6-819C-ADB7B1182CED@nostrum.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com>  <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: "ext lionel.morand@orange.com" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ncy9MCNZWRcq2NCDFOxCFKAnerU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 18:44:59 -0000

On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com wrote:

> I would like to highlight that my proposal is not related to the =
default Reduction-percentage algo.
>=20
> Whatever the ago used, I think that an OLR can only be sent for two =
purposes:
> - Send an indication of overload situation
> - Send an indication of end of the overload situation
>=20
> For me, providing both indications in the same message would be a =
non-sense. And I don't understand why the validity period would prevail =
in that case.

So here's the question: Let's assume a reporting node sends you an OLR =
using the "loss" algorithm, a reduction-percentage of 50%, and a =
Validity-Duration of 10 minutes. 5 minutes later, it sends you a new OLR =
with an invalid reduction percentage and a Validity-Duration of 0.

What's the current overload state?

What if the second OLR used the "rate" algorithm, with a valid value, =
but still had a validity duration of 0. Does that change anything?

I am arguing that, in both cases, the second OLR ends the overload =
period.

I'm actually okay if we have a normative statement to the effect that =
the reporting node MUST NOT send an invalid reduction percentage, and =
that a reacting node MUST ignore an OLR with an invalid value _except_ =
for the case of a validity-duration set to zero.

This all comes down to how much guessing we are willing to do about the =
intent of the sender when one receives an invalid OLR. I think it's =
reasonable to guess that a zero validity duration means to end an =
overload condition, without regard to the rest of the message. I _don't_ =
think it's reasonable to try to guess what the sender meant with an =
invalid reduction percentage, when the validity period is non-zero.

Another, perhaps simpler, approach would be to assert that the reception =
of _any_ invalid OLR automatically ends any existing overload condition. =
(I'm not necessarily arguing for that--it's just something to think =
about.)

>=20
> Now, if what is argued by Ben and supported by JJ and Steve is clear =
for the rest of the group, I will not fight.

... but the fighting is the fun part :-)=


From nobody Tue Feb 18 02:11:37 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794D31A0627 for ; Tue, 18 Feb 2014 02:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ2EsKaEl0GX for ; Tue, 18 Feb 2014 02:11:29 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6186A1A061F for ; Tue, 18 Feb 2014 02:11:24 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-dd-530331c8d481
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id B4.2E.04853.8C133035; Tue, 18 Feb 2014 11:11:20 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Tue, 18 Feb 2014 11:11:20 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAlWmMf1mPE0uklIAv2DU+a5qmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDg///ya4CAAEgwoIAFPwgvgAQ/M4CAABvrAIABIJ2g
Date: Tue, 18 Feb 2014 10:11:20 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>  <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209783450ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje4JQ+Zgg44mK4u5vSvYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0XD6BVPB8cSKm/smszQwbgrtYuTkkBAwkZi5YzcjhC0mceHe erYuRg4OIYETjBI/mLoYuYDMxYwSk1d9YgapYROwk7gENAekRkRAWeL0LweQsLCAvcTXG2fA SkQEHCTWPD/JAtIrIjCNUWLtwlZWkASLgKrE2YeXwHbxCvhKnJ5ynw1iQR+HxOazzewgCU6B WInd21cwgdiMQAd9P7UGzGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKYStKXJ2+HKo+X+LM lh8sEMsEJU7OfMIygVFkFpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZ VzFKFqcWF+emGxno5abnluilFmUmFxfn5+kVp25iBMbSwS2/jXYwntxjf4hRmoNFSZz3OmtN kJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG9BuVTq6Sx20KFrnkCcT/9dLI5PwVsa2V1+hh 7DSbp5tPnOD6xn4kPFh52bODKec0nb5Zqv7x3C/Bc0x1g49PmPKXCWtdo+4sOXQ2o2pNkVCC f6BUKZNtsmZ2r/x6IZVdskFaf1fG3T08tWzmr0/ibR0qk68EyZ7mquy/7XcwiGm+2EQFW10l luKMREMt5qLiRACNr7yDcwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-HO8gOdkQtLjZvXeQBLwcbL9t0I
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 10:11:35 -0000

--_000_087A34937E64E74E848732CFF8354B9209783450ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,

Overload of the realm is one of the use cases that is required by 3GPP appl=
ications.
And I think this should be part of the basic mechanism, or?

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 17 de febrero de 2014 18:53
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi

I share the view to analyze the overload of the realm as a whole in a separ=
ate extension  and see if this lead to another report type.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 17 f=E9vrier 2014 17:13
=C0 : Ben Campbell
Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I do think it would be a new report type, as it would require different beh=
avior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively small ex=
tensions.  It might lead to the need to pull them all together in a future =
version of the DOIC draft/RFC.

Steve
On 2/14/14 4:21 PM, Ben Campbell wrote:

(Apologies for coming late to this thread)



On Feb 13, 2014, at 6:35 AM, Steve Donovan  wrote:



Ok, Ok, no reason to gang up on me. :-)

What we have here is an overload report to reduce realm routed requests.  I=
 think we should be explicit in the draft to define it as such.





At the risk of joining the anti-Steve gang, I feel the need to belatedly me=
ntion that my personal intent way back when we talked about the mixed-state=
 problem was that realm reports applied to realm-routed requests.



I am still concerned that we do not have a way to indicate overload of the =
realm as a whole.  I'll enter a new trouble ticket to capture this issue.





I do not object to adding that ability. Would it be a new OLR type? If so, =
would it need to go in the base draft or could it be an extension?



Steve






--_000_087A34937E64E74E848732CFF8354B9209783450ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello all,


 <=
/p>

Overload of the realm is =
one of the use cases that is required by 3GPP applications.


And I think this should b=
e part of the basic mechanism, or?


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: lunes, 17 de febrero de 2014 18:53

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


Hi


 <=
/p>

I share the view to analy=
ze the overload of the realm as a whole in a separate extension  and s=
ee if this lead to another report type.


 <=
/p>

Best regards


 <=
/p>

JJacques



  


 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 17 f=E9vrier 2014 17:13

=C0 : Ben Campbell

Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
o:p>






 


I do think it would b=
e a new report type, as it would require different behavior from reacting n=
odes.



I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively sma=
ll extensions.  It might lead to the need to pull them all together in=
 a future version of the DOIC draft/RFC.



Steve




On 2/14/14 4:21 PM, Ben Campbell wrote:





(Apologies for coming late to this thread)


 


On Feb 13, 2014, at 6:35 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Ok, Ok, no reason to gang up on me. :-)


What we have here is an overload report to reduce realm routed request=
s.  I think we should be explicit in the draft to define it as such.


 




 


At the risk of joining the anti-Steve gang, I feel the need to belated=
ly mention that my personal intent way back when we talked about the mixed-=
state problem was that realm reports applied to realm-routed requests. 


 




I am still concerned that we do not have a way to indicate overload of=
 the realm as a whole.  I'll enter a new trouble ticket to capture thi=
s issue.


 




 


I do not object to adding that ability. Would it be a new OLR type? If=
 so, would it need to go in the base draft or could it be an extension?


 




Steve




 


 




 






--_000_087A34937E64E74E848732CFF8354B9209783450ESESSMB101erics_--


From nobody Tue Feb 18 04:35:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552251A0497 for ; Tue, 18 Feb 2014 04:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJyd9LI_JIIj for ; Tue, 18 Feb 2014 04:35:30 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id CD7341A01B5 for ; Tue, 18 Feb 2014 04:35:29 -0800 (PST)
Received: from localhost ([127.0.0.1]:38199 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WFjtI-0003HY-TB; Tue, 18 Feb 2014 13:35:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-docdt-dime-ovli@tools.ietf.org, ulrich.wiehe@nsn.com
X-Trac-Project: dime
Date: Tue, 18 Feb 2014 12:35:12 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/56
Message-ID: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org>
X-Trac-Ticket-ID: 56
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ulrich.wiehe@nsn.com,  dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bz2LqmaYJruDffFmtjYnoFTGf7k
Cc: dime@ietf.org
Subject: [Dime] [dime] #56: Bad Description of Overload Control State
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 12:35:32 -0000

#56: Bad Description of Overload Control State

 The description of Overload Control State in clause 5.5.1 is inaccurate,
 incomplete and could be misleading. It does not differentiate between
 Overload Control State in a reacting node versus Overload Control State in
 a reporting node. It also does not describe how Overload Control States
 are maintained.

 It is proposed to replace current text with the following:


 5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node (client) maintains per supported Diameter application
    a host-type Overload Control State for each Destination-Host towards
    which it sends host-type requests and a realm-type Overload Control
 State
    for each Destination-Realm toward which it sends realm-type requests.
    A host-type Overload Control State may be identified by the pair of
    Application-Id and Destination-Host; a realm-type Overload Control
 State
    may be identified by the pair of Application-Id and Destination-Realm.
    The host-type/realm-type Overload Control State for a given pair of
    Application and Destination-Host / Destination-Realm could include the
    information as shown in table 1/table 2.

    

    Agents that take the role of a reacting node on behalf of clients MUST
    maintain Overload Control States per client.

    5.5.1.2   Overload Control States for reporting nodes

    A reporting node (server) maintains per supported Diameter application
    an Overload Control State for each Origin-Host from which it receives
    requests that contain an (explicit or implicit) indication of
    OLR_DEFAULT_ALGO support.

    A reporting node (agent that is configured to take the role of a
    reporting node for a given realm) maintains per supported Diameter
    application an Overload Control State for each Origin-Host from which
 it
    receives realm-type requests (of that given realm) that contain an
    (explicit or implicit) indication of OLR_DEFAULT_ALGO support.

    A Overload Control State may be identified by the pair of Application-
 Id
    and Origin-Host.

    The Overload Control State for a given pair of Application and Origin-
    Host could include the information as shown in table 3.
    

    Note: For nodes that support other features than just OLR_DEFAULT_ALGO
    the Overload Control State definitions may need to be extended.

    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS with OCS-Id = (x,A) when
 receiving
    an answer message of application x containing an Orig-Host of A and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS with OCS-Id = (x,A) when
 receiving
    an answer message of application x containing an Orig-Realm of A and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS with OCS-Id = (x,A) when
    receiving an answer message of application x containing an Orig-Host of
    A and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS with OCS-Id = (x,A) when
    receiving an answer message of application x containing an Orig-Realm
 of
    A and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS with OCS-Id = (x,A) when receiving a
    request (indicating support of OLR_DEFAULT_ALGO) of application x
    containing an Orig-Host of A unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS with OCS-Id = (x,A) when they detect the
    need to modify the requested amount of application x traffic reduction
    generated by A.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-docdt-dime-
  ulrich.wiehe@nsn.com   |  ovli@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  draft-       |    Version:
  docdt-dime-ovli        |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Tue Feb 18 04:48:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC01A0437 for ; Tue, 18 Feb 2014 04:48:23 -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
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 Qi2H3w7DbqN9 for ; Tue, 18 Feb 2014 04:48:21 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id B42B01A047A for ; Tue, 18 Feb 2014 04:48:20 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51589 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFk5w-0002f0-Sq for dime@ietf.org; Tue, 18 Feb 2014 04:48:17 -0800
Message-ID: <53035690.1070702@usdonovans.com>
Date: Tue, 18 Feb 2014 06:48:16 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------030804050308000802070805"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EKpU6WJjfTLeT4mfXiyhgHzf5YI
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 12:48:24 -0000

This is a multi-part message in MIME format.
--------------030804050308000802070805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

It shouldn't be much work to add realm overload to the draft.  We would
need to do the following (at a minimum):

- Change that name of the current realm report to something like
"realm-routed".
- Create a new report type of name realm that applies to all traffic
routed to the realm.
- Add a few words in the reporting node section about generation of
realm reports.
- Define the interaction between realm, realm-routed and host report
types.  This is probably the most difficult part that is likely to
require some discussion.

Other then the section on interactions between report types, I don't
think this impacts the existing text so it should fold in pretty cleanly.

I'd be happy to take the first shot at this to be included in the -02
version of the draft if there is consensus to add it.

Steve

On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:
>
> Hello all,
>
>  
>
> Overload of the realm is one of the use cases that is required by 3GPP
> applications.
>
> And I think this should be part of the basic mechanism, or?
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* lunes, 17 de febrero de 2014 18:53
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> Hi
>
>  
>
> I share the view to analyze the overload of the realm as a whole in a
> separate extension  and see if this lead to another report type.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>   
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* lundi 17 février 2014 17:13
> *À :* Ben Campbell
> *Cc :* dime@ietf.org  list
> *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> I do think it would be a new report type, as it would require
> different behavior from reacting nodes.
>
> I'm ok with this being in a separate extension if the group thinks
> this is the correct approach.  We are creating a good number of
> relatively small extensions.  It might lead to the need to pull them
> all together in a future version of the DOIC draft/RFC.
>
> Steve
>
> On 2/14/14 4:21 PM, Ben Campbell wrote:
>
>     (Apologies for coming late to this thread)
>
>      
>
>     On Feb 13, 2014, at 6:35 AM, Steve Donovan   wrote:
>
>      
>
>         Ok, Ok, no reason to gang up on me. :-)
>
>         What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.
>
>          
>
>      
>
>     At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 
>
>      
>
>         I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.
>
>          
>
>      
>
>     I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?
>
>      
>
>         Steve
>
>      
>
>      
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------030804050308000802070805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    It shouldn't be much work
      to add realm overload to the draft.  We would need to do the following
      (at a minimum):

      

      - Change that name of the current realm report to something like
      "realm-routed".

      - Create a new report type of name realm that applies to all
      traffic routed to the realm.

      - Add a few words in the reporting node section about generation
      of realm reports.

      - Define the interaction between realm, realm-routed and host
      report types.  This is probably the most difficult part that is
      likely to require some discussion.

      

      Other then the section on interactions between report types, I
      don't think this impacts the existing text so it should fold in
      pretty cleanly.

      

      I'd be happy to take the first shot at this to be included in the
      -02 version of the draft if there is consensus to add it.

      

      Steve

      

    
    
On 2/18/14 4:11 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello
            all,

        
 

        
Overload
            of the realm is one of the use cases that is required by
            3GPP applications.

        
And
            I think this should be part of the basic mechanism, or?

        
 

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: lunes, 17 de febrero de 2014 18:53

                To: dime@ietf.org

                Subject: Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
Hi

        
 

        
I
            share the view to analyze the overload of the realm as a
            whole in a separate extension  and see if this lead to
            another report type.

        
 

        
Best
            regards

        
 

        
JJacques
            

        
  

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : lundi 17 février 2014 17:13

                À : Ben Campbell

                Cc : dime@ietf.org list

                Objet : Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
I do think it
          would be a new report type, as it would require different
          behavior from reacting nodes.

          

          I'm ok with this being in a separate extension if the group
          thinks this is the correct approach.  We are creating a good
          number of relatively small extensions.  It might lead to the
          need to pull them all together in a future version of the DOIC
          draft/RFC.

          

          Steve

        

          
On 2/14/14 4:21 PM, Ben Campbell wrote:

        

        

          
(Apologies for coming late to this thread)

          
 

          
On Feb 13, 2014, at 6:35 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

          
 

          

            
Ok, Ok, no reason to gang up on me. :-)

            
What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.

            
 

          

          
 

          
At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 

          
 

          

            
I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.

            
 

          

          
 

          
I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?

          
 

          

            
Steve

          

          
 

          
 

        

        
 

      

      

      

      

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


    

    

  


--------------030804050308000802070805--


From nobody Tue Feb 18 05:41:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D58C1A04C8 for ; Tue, 18 Feb 2014 05:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmha3Es9MQe1 for ; Tue, 18 Feb 2014 05:41:51 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6848A1A01C2 for ; Tue, 18 Feb 2014 05:41:49 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1IDfjM3011261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 14:41:45 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1IDfiuB009275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 14:41:45 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 14:41:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPLKfaNBG2qkbh0kelPIaMQYlrnZq6+hlQ
Date: Tue, 18 Feb 2014 13:41:43 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com>
In-Reply-To: <53035690.1070702@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.126]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3A60DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 18927
X-purgate-ID: 151667::1392730905-00005322-C100E584/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5U8MK-sq_ByTR36YOLfBEqYfZ5k
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 13:41:57 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3A60DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

first of all I would like to better understand the usecase especially on th=
e reporting side.
Which node would act as a reporting node generating new realm-type reports?
How would this node detect that the complete realm is in overload (and what=
 does that mean? All servers in the realm, also clients? Agents? )?
Would this node be (logically) a single node? If not, how to synchronize di=
fferent new-realm-type reporting nodes so that they don't report different =
things to the same reacting node?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 18, 2014 1:48 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

It shouldn't be much work to add realm overload to the draft.  We would nee=
d to do the following (at a minimum):

- Change that name of the current realm report to something like "realm-rou=
ted".
- Create a new report type of name realm that applies to all traffic routed=
 to the realm.
- Add a few words in the reporting node section about generation of realm r=
eports.
- Define the interaction between realm, realm-routed and host report types.=
  This is probably the most difficult part that is likely to require some d=
iscussion.

Other then the section on interactions between report types, I don't think =
this impacts the existing text so it should fold in pretty cleanly.

I'd be happy to take the first shot at this to be included in the -02 versi=
on of the draft if there is consensus to add it.

Steve
On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:
Hello all,

Overload of the realm is one of the use cases that is required by 3GPP appl=
ications.
And I think this should be part of the basic mechanism, or?

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 17 de febrero de 2014 18:53
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi

I share the view to analyze the overload of the realm as a whole in a separ=
ate extension  and see if this lead to another report type.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 17 f=E9vrier 2014 17:13
=C0 : Ben Campbell
Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I do think it would be a new report type, as it would require different beh=
avior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively small ex=
tensions.  It might lead to the need to pull them all together in a future =
version of the DOIC draft/RFC.

Steve
On 2/14/14 4:21 PM, Ben Campbell wrote:

(Apologies for coming late to this thread)



On Feb 13, 2014, at 6:35 AM, Steve Donovan  wrote:



Ok, Ok, no reason to gang up on me. :-)

What we have here is an overload report to reduce realm routed requests.  I=
 think we should be explicit in the draft to define it as such.





At the risk of joining the anti-Steve gang, I feel the need to belatedly me=
ntion that my personal intent way back when we talked about the mixed-state=
 problem was that realm reports applied to realm-routed requests.



I am still concerned that we do not have a way to indicate overload of the =
realm as a whole.  I'll enter a new trouble ticket to capture this issue.





I do not object to adding that ability. Would it be a new OLR type? If so, =
would it need to go in the base draft or could it be an extension?



Steve









_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3A60DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

first of a=
ll I would like to better understand the usecase especially on the reportin=
g side.


Which node=
 would act as a reporting node generating new realm-type reports?


How would =
this node detect that the complete realm is in overload (and what does that=
 mean? All servers in the realm, also clients? Agents? )?=



Would this=
 node be (logically) a single node? If not, how to synchronize different ne=
w-realm-type reporting nodes so that they don’t report different
 things to the same reacting node?


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, February 18, 2014 1:48 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


It shouldn't be much =
work to add realm overload to the draft.  We would need to do the foll=
owing (at a minimum):



- Change that name of the current realm report to something like "real=
m-routed".

- Create a new report type of name realm that applies to all traffic routed=
 to the realm.

- Add a few words in the reporting node section about generation of realm r=
eports.

- Define the interaction between realm, realm-routed and host report types.=
  This is probably the most difficult part that is likely to require s=
ome discussion.



Other then the section on interactions between report types, I don't think =
this impacts the existing text so it should fold in pretty cleanly.



I'd be happy to take the first shot at this to be included in the -02 versi=
on of the draft if there is consensus to add it.



Steve




On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:=







Hello all,


 <=
/p>

Overload of the realm is =
one of the use cases that is required by 3GPP applications.


And I think this should b=
e part of the basic mechanism, or?


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: lunes, 17 de febrero de 2014 18:53

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP






 


Hi


 <=
/p>

I share the view to analy=
ze the overload of the realm as a whole in a separate extension  and s=
ee if this lead to another report type.


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



  <=
/o:p>


 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 17 f=E9vrier 2014 17:13

=C0 : Ben Campbell

Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I do think it would b=
e a new report type, as it would require different behavior from reacting n=
odes.



I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively sma=
ll extensions.  It might lead to the need to pull them all together in=
 a future version of the DOIC draft/RFC.



Steve




On 2/14/14 4:21 PM, Ben Campbell wrote:





(Apologies for coming late to this thread)


 


On Feb 13, 2014, at 6:35 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Ok, Ok, no reason to gang up on me. :-)


What we have here is an overload report to reduce realm routed request=
s.  I think we should be explicit in the draft to define it as such.


 




 


At the risk of joining the anti-Steve gang, I feel the need to belated=
ly mention that my personal intent way back when we talked about the mixed-=
state problem was that realm reports applied to realm-routed requests. 


 




I am still concerned that we do not have a way to indicate overload of=
 the realm as a whole.  I'll enter a new trouble ticket to capture thi=
s issue.


 




 


I do not object to adding that ability. Would it be a new OLR type? If=
 so, would it need to go in the base draft or could it be an extension?


 




Steve




 


 




 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3A60DEMUMBX014nsnin_--


From nobody Tue Feb 18 06:54:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93CD1A04F5 for ; Tue, 18 Feb 2014 06:54:50 -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
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 rKyIXucS9hNO for ; Tue, 18 Feb 2014 06:54:47 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 878EC1A03DC for ; Tue, 18 Feb 2014 06:54:47 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51876 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFm4C-0003K1-JA; Tue, 18 Feb 2014 06:54:42 -0800
Message-ID: <5303742C.50902@usdonovans.com>
Date: Tue, 18 Feb 2014 08:54:36 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------070304020609070605090806"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/F7w2QHMV8rZRFZjllhM_kkoEc-w
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 14:54:51 -0000

This is a multi-part message in MIME format.
--------------070304020609070605090806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Ulrich,

All good questions.

I mapped out the use case in a previous email with discussing the
realm-routed overload report type. 

Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm
hoping someone involved in the discussions that lead to that requirement
can speak up on the use case driving the need for realm reports.

The means of detection is out of scope for the DOIC draft, just as it is
for host and realm-routed report types.  We should, however, include
wording to explain how it might be done. 

A few bullet points outlining a proposed solution.  I can put together a
couple of slides explaining this if it would be helpful.

- The method of detection can be based on the collected status of
Diameter nodes in the realm.  It can also be based on the status of the
underlying network.  For instance, if there is a network outage that
reduces the effective throughput of the signaling network, the best
method for handling this might be to signal a realm overload report.

- The network element detecting the realm status is out of scope for the
DOIC document.

- The Diameter node that reports realm overload can be any Diameter node
and is up to the service provider to define.  Assuming we are using
Diameter answer messages to transport the realm reports, it would need
to be either all agents or all servers.  This is to guarantee that all
reacting nodes get the report.

- The method that the reporting node is told that the realm is
overloaded, triggering the realm overload report, is out of scope for
this document.

- Reacting nodes should listen to only one realm overload reporting
node.  It is up to the implementation of the realm overload detection
element to make sure that all reporting nodes have the same state.

One way to model this is for an external element being responsible for
detecting realm overload and signaling the realm overload reporting
nodes of the status using an out of bands mechanism.  All realm overload
reporting nodes would be responsible for sending realm overload
reports.  Reacting nodes would only listen to one of the reporting nodes.

There are also security considerations similar to host reports, except
that an attack using realm overload reports has a much bigger impact
than an attack using host reports.

Steve

On 2/18/14 7:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> first of all I would like to better understand the usecase especially
> on the reporting side.
>
> Which node would act as a reporting node generating new realm-type
> reports?
>
> How would this node detect that the complete realm is in overload (and
> what does that mean? All servers in the realm, also clients? Agents? )?
>
> Would this node be (logically) a single node? If not, how to
> synchronize different new-realm-type reporting nodes so that they
> don't report different things to the same reacting node?
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, February 18, 2014 1:48 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> It shouldn't be much work to add realm overload to the draft.  We
> would need to do the following (at a minimum):
>
> - Change that name of the current realm report to something like
> "realm-routed".
> - Create a new report type of name realm that applies to all traffic
> routed to the realm.
> - Add a few words in the reporting node section about generation of
> realm reports.
> - Define the interaction between realm, realm-routed and host report
> types.  This is probably the most difficult part that is likely to
> require some discussion.
>
> Other then the section on interactions between report types, I don't
> think this impacts the existing text so it should fold in pretty cleanly.
>
> I'd be happy to take the first shot at this to be included in the -02
> version of the draft if there is consensus to add it.
>
> Steve
>
> On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:
>
>     Hello all,
>
>      
>
>     Overload of the realm is one of the use cases that is required by
>     3GPP applications.
>
>     And I think this should be part of the basic mechanism, or?
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN,
>     JEAN-JACQUES (JEAN-JACQUES)
>     *Sent:* lunes, 17 de febrero de 2014 18:53
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     Hi
>
>      
>
>     I share the view to analyze the overload of the realm as a whole
>     in a separate extension  and see if this lead to another report type.
>
>      
>
>     Best regards
>
>      
>
>     JJacques
>
>       
>
>      
>
>     *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve
>     Donovan
>     *Envoyé :* lundi 17 février 2014 17:13
>     *À :* Ben Campbell
>     *Cc :* dime@ietf.org  list
>     *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     I do think it would be a new report type, as it would require
>     different behavior from reacting nodes.
>
>     I'm ok with this being in a separate extension if the group thinks
>     this is the correct approach.  We are creating a good number of
>     relatively small extensions.  It might lead to the need to pull
>     them all together in a future version of the DOIC draft/RFC.
>
>     Steve
>
>     On 2/14/14 4:21 PM, Ben Campbell wrote:
>
>         (Apologies for coming late to this thread)
>
>          
>
>         On Feb 13, 2014, at 6:35 AM, Steve Donovan   wrote:
>
>          
>
>             Ok, Ok, no reason to gang up on me. :-)
>
>             What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.
>
>              
>
>          
>
>         At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 
>
>          
>
>             I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.
>
>              
>
>          
>
>         I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?
>
>          
>
>             Steve
>
>          
>
>          
>
>      
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>  
>


--------------070304020609070605090806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      All good questions.

      

      I mapped out the use case in a previous email with discussing the
      realm-routed overload report type.  

      

      Maria Cruz also indicated that this is a 3GPP DOC requirement. 
      I'm hoping someone involved in the discussions that lead to that
      requirement can speak up on the use case driving the need for
      realm reports.

      

      The means of detection is out of scope for the DOIC draft, just as
      it is for host and realm-routed report types.  We should, however,
      include wording to explain how it might be done.  

      

      A few bullet points outlining a proposed solution.  I can put
      together a couple of slides explaining this if it would be
      helpful.

      

      - The method of detection can be based on the collected status of
      Diameter nodes in the realm.  It can also be based on the status
      of the underlying network.  For instance, if there is a network
      outage that reduces the effective throughput of the signaling
      network, the best method for handling this might be to signal a
      realm overload report.

      

      - The network element detecting the realm status is out of scope
      for the DOIC document.

      

      - The Diameter node that reports realm overload can be any
      Diameter node and is up to the service provider to define. 
      Assuming we are using Diameter answer messages to transport the
      realm reports, it would need to be either all agents or all
      servers.  This is to guarantee that all reacting nodes get the
      report.

      

      - The method that the reporting node is told that the realm is
      overloaded, triggering the realm overload report, is out of scope
      for this document.

      

      - Reacting nodes should listen to only one realm overload
      reporting node.  It is up to the implementation of the realm
      overload detection element to make sure that all reporting nodes
      have the same state.

      

      One way to model this is for an external element being responsible
      for detecting realm overload and signaling the realm overload
      reporting nodes of the status using an out of bands mechanism. 
      All realm overload reporting nodes would be responsible for
      sending realm overload reports.  Reacting nodes would only listen
      to one of the reporting nodes.

      

      There are also security considerations similar to host reports,
      except that an attack using realm overload reports has a much
      bigger impact than an attack using host reports.

      

      Steve

      

    
    
On 2/18/14 7:41 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
first of all I would like to better understand
            the usecase especially on the reporting side.

        
Which node would act as a reporting node
            generating new realm-type reports?

        
How would this node detect that the complete
            realm is in overload (and what does that mean? All servers
            in the realm, also clients? Agents? )?

        
Would this node be (logically) a single node?
            If not, how to synchronize different new-realm-type
            reporting nodes so that they don’t report different things
            to the same reacting node?

        
 

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Tuesday, February 18, 2014 1:48 PM

                To: dime@ietf.org

                Subject: Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
It shouldn't
          be much work to add realm overload to the draft.  We would
          need to do the following (at a minimum):

          

          - Change that name of the current realm report to something
          like "realm-routed".

          - Create a new report type of name realm that applies to all
          traffic routed to the realm.

          - Add a few words in the reporting node section about
          generation of realm reports.

          - Define the interaction between realm, realm-routed and host
          report types.  This is probably the most difficult part that
          is likely to require some discussion.

          

          Other then the section on interactions between report types, I
          don't think this impacts the existing text so it should fold
          in pretty cleanly.

          

          I'd be happy to take the first shot at this to be included in
          the -02 version of the draft if there is consensus to add it.

          

          Steve

        

          
On 2/18/14 4:11 AM, Maria Cruz Bartolome
            wrote:

        

        

          
Hello
              all,

          
 

          
Overload
              of the realm is one of the use cases that is required by
              3GPP applications.

          
And
              I think this should be part of the basic mechanism, or?

          
 

          
Best
              regards

          
/MCruz

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of TROTTIN, JEAN-JACQUES
                  (JEAN-JACQUES)

                  Sent: lunes, 17 de febrero de 2014 18:53

                  To: dime@ietf.org

                  Subject: Re: [Dime] [dime] #34: Semantics of
                  OC-Report-Type AVP

            

          

          
 

          
Hi

          
 

          
I
              share the view to analyze the overload of the realm as a
              whole in a separate extension  and see if this lead to
              another report type.

          
 

          
Best
              regards

          
 

          
JJacques
            

          
  

          
 

          

            

              
De : DiME [mailto:dime-bounces@ietf.org]
                  De la part de Steve Donovan

                  Envoyé : lundi 17 février 2014 17:13

                  À : Ben Campbell

                  Cc : dime@ietf.org list

                  Objet : Re: [Dime] [dime] #34: Semantics of
                  OC-Report-Type AVP

            

          

          
 

          
I do think
            it would be a new report type, as it would require different
            behavior from reacting nodes.

            

            I'm ok with this being in a separate extension if the group
            thinks this is the correct approach.  We are creating a good
            number of relatively small extensions.  It might lead to the
            need to pull them all together in a future version of the
            DOIC draft/RFC.

            

            Steve

          

            
On 2/14/14 4:21 PM, Ben Campbell wrote:

          

          

            
(Apologies for coming late to this thread)

            
 

            
On Feb 13, 2014, at 6:35 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

            
 

            

              
Ok, Ok, no reason to gang up on me. :-)

              
What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.

              
 

            

            
 

            
At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 

            
 

            

              
I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.

              
 

            

            
 

            
I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?

            
 

            

              
Steve

            

            
 

            
 

          

          
 

          


            

            

            

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

        

        
 

      

    

    

  


--------------070304020609070605090806--


From nobody Tue Feb 18 07:20:12 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D051A0692; Tue, 18 Feb 2014 07:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C0VS2oHqUD4; Tue, 18 Feb 2014 07:20:02 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 670A61A0209; Tue, 18 Feb 2014 07:20:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 61D4C20686; Tue, 18 Feb 2014 10:16:04 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lSYdUSYgdp2; Tue, 18 Feb 2014 10:16:02 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 18 Feb 2014 10:16:02 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B49F1837F1; Tue, 18 Feb 2014 10:19:53 -0500 (EST)
From: Sam Hartman 
To: Alan DeKok 
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> <5302105C.6070103@deployingradius.com>
Date: Tue, 18 Feb 2014 10:19:53 -0500
In-Reply-To: <5302105C.6070103@deployingradius.com> (Alan DeKok's message of "Mon, 17 Feb 2014 08:36:28 -0500")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lkDrafhsFfimfF51b6b-7h5rUYs
Cc: abfab@ietf.org, "dime@ietf.org" , "" , "radext@ietf.org" 
Subject: Re: [Dime] [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 15:20:08 -0000

>>>>> "Alan" == Alan DeKok  writes:


    Alan>   The idea was to allow *provisioning* of the
    Alan> Response/Identity.  Automatically deriving it from the
    Alan> method-specific "user identity" is just as bad as
    Alan> automatically using a 3GPP identity.

Unfortunately in contexts like ABFAB, you're only going to have one
username.
I appreciate that there are environments where you need a different
outer username, but I think we want to be moving towards anonymous outer
usernames derived from the realm, and I do not support a spec that would
make that more difficult.


From nobody Tue Feb 18 10:04:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1431A00FB for ; Tue, 18 Feb 2014 10:04:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEMs2fDha32K for ; Tue, 18 Feb 2014 10:04:50 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id E51431A00D4 for ; Tue, 18 Feb 2014 10:04:49 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1II4irx019488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Feb 2014 12:04:46 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1II4iuD018958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 19:04:44 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 18 Feb 2014 19:04:44 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIcx34wrZRRvx1EKFdFq4TjstmpqmsICAgAAE6ICAABUugIACvZWAgAAwCoCAADL/AIAEjBxA///7RACAABhCgIABTnoAgAACQICAADisgIAADXYAgAAEyICAAAGagIAAZP8wgAAbz4CAAnLKgIACNiuAgARQJICAACoWIIABAxwAgAAr2ACAAA7vgIAAFF0AgAAfMYA=
Date: Tue, 18 Feb 2014 18:04:43 +0000
Message-ID: 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com>
In-Reply-To: <5303742C.50902@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202669A38FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rq44BGL1XsN9-uhiDAoanXsvo6s
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 18:04:55 -0000

--_000_E194C2E18676714DACA9C3A2516265D202669A38FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all


1)      I come back on this Steve's comment : "Define the interaction betwe=
en realm, realm-routed and host report types.  This is probably the most di=
fficult part that is likely to require some discussion".
This joins one of  my remarks about the overlapping between different repor=
ts in a previous mail and drives to the use cases regarding realm overload:


-          If realm overload is due to server overload, I would think that =
 our current  mechanism dealing with host report and realm (alias realm-rou=
ted) report will address / solve server overload  and in consequence indire=
ctly  address / solve  this overload realm  case

-          if realm overload is due to the overload of Diameter agents, we =
have discussion and a Steve's  proposal   about  Agent overload. I would al=
so think that by addressing / solving the DA overload, it would also addres=
s and solve this overload realm  case.

-          About an underlying  network congestion (eg due to network outag=
e), here REQ 13 mentions that "The solution MUST NOT interfere with the con=
gestion control mechanisms of underlying transport protocols". So here I am=
 also questioning if  we may have  duplication or overlapping, and what to =
do .

-          Have we other realm overload use cases?

So my current thinking is  we have first  to identify the various realm  ov=
erload use cases and see those actually justifying to add new mechanisms.


2)      I share Ulrich's questions  on how to deal with realm overload. Ste=
ve's  answer introduces a high complexity about detecting , evaluate the re=
alm overload  and then which DA are acting etc. The fact to consider many o=
f these points out of the scope does not suppress this complexity (which in=
 addition occurs in an overloaded environment...) . So  I come back to my p=
oint 1 about the use cases to address  and the use of the mechanisms for se=
rver and DA overload

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 18 f=E9vrier 2014 15:55
=C0 : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Ulrich,

All good questions.

I mapped out the use case in a previous email with discussing the realm-rou=
ted overload report type.

Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm hoping =
someone involved in the discussions that lead to that requirement can speak=
 up on the use case driving the need for realm reports.

The means of detection is out of scope for the DOIC draft, just as it is fo=
r host and realm-routed report types.  We should, however, include wording =
to explain how it might be done.

A few bullet points outlining a proposed solution.  I can put together a co=
uple of slides explaining this if it would be helpful.

- The method of detection can be based on the collected status of Diameter =
nodes in the realm.  It can also be based on the status of the underlying n=
etwork.  For instance, if there is a network outage that reduces the effect=
ive throughput of the signaling network, the best method for handling this =
might be to signal a realm overload report.

- The network element detecting the realm status is out of scope for the DO=
IC document.

- The Diameter node that reports realm overload can be any Diameter node an=
d is up to the service provider to define.  Assuming we are using Diameter =
answer messages to transport the realm reports, it would need to be either =
all agents or all servers.  This is to guarantee that all reacting nodes ge=
t the report.

- The method that the reporting node is told that the realm is overloaded, =
triggering the realm overload report, is out of scope for this document.

- Reacting nodes should listen to only one realm overload reporting node.  =
It is up to the implementation of the realm overload detection element to m=
ake sure that all reporting nodes have the same state.

One way to model this is for an external element being responsible for dete=
cting realm overload and signaling the realm overload reporting nodes of th=
e status using an out of bands mechanism.  All realm overload reporting nod=
es would be responsible for sending realm overload reports.  Reacting nodes=
 would only listen to one of the reporting nodes.

There are also security considerations similar to host reports, except that=
 an attack using realm overload reports has a much bigger impact than an at=
tack using host reports.

Steve
On 2/18/14 7:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

first of all I would like to better understand the usecase especially on th=
e reporting side.
Which node would act as a reporting node generating new realm-type reports?
How would this node detect that the complete realm is in overload (and what=
 does that mean? All servers in the realm, also clients? Agents? )?
Would this node be (logically) a single node? If not, how to synchronize di=
fferent new-realm-type reporting nodes so that they don't report different =
things to the same reacting node?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 18, 2014 1:48 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

It shouldn't be much work to add realm overload to the draft.  We would nee=
d to do the following (at a minimum):

- Change that name of the current realm report to something like "realm-rou=
ted".
- Create a new report type of name realm that applies to all traffic routed=
 to the realm.
- Add a few words in the reporting node section about generation of realm r=
eports.
- Define the interaction between realm, realm-routed and host report types.=
  This is probably the most difficult part that is likely to require some d=
iscussion.

Other then the section on interactions between report types, I don't think =
this impacts the existing text so it should fold in pretty cleanly.

I'd be happy to take the first shot at this to be included in the -02 versi=
on of the draft if there is consensus to add it.

Steve
On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:
Hello all,

Overload of the realm is one of the use cases that is required by 3GPP appl=
ications.
And I think this should be part of the basic mechanism, or?

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 17 de febrero de 2014 18:53
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi

I share the view to analyze the overload of the realm as a whole in a separ=
ate extension  and see if this lead to another report type.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 17 f=E9vrier 2014 17:13
=C0 : Ben Campbell
Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I do think it would be a new report type, as it would require different beh=
avior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively small ex=
tensions.  It might lead to the need to pull them all together in a future =
version of the DOIC draft/RFC.

Steve
On 2/14/14 4:21 PM, Ben Campbell wrote:

(Apologies for coming late to this thread)



On Feb 13, 2014, at 6:35 AM, Steve Donovan  wrote:



Ok, Ok, no reason to gang up on me. :-)

What we have here is an overload report to reduce realm routed requests.  I=
 think we should be explicit in the draft to define it as such.





At the risk of joining the anti-Steve gang, I feel the need to belatedly me=
ntion that my personal intent way back when we talked about the mixed-state=
 problem was that realm reports applied to realm-routed requests.



I am still concerned that we do not have a way to indicate overload of the =
realm as a whole.  I'll enter a new trouble ticket to capture this issue.





I do not object to adding that ability. Would it be a new OLR type? If so, =
would it need to go in the base draft or could it be an extension?



Steve










_______________________________________________

DiME mailing list

DiME@ietf.org

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



--_000_E194C2E18676714DACA9C3A2516265D202669A38FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi all<=
/p>

 <=
/p>


1)  &=
nbsp;  
I come back on th=
is Steve’s comment : “Define the interaction between rea=
lm, realm-routed and host report types.  This is probably the most
 difficult part that is likely to require some discussion”. 


This joins one of  m=
y remarks about the overlapping between different reports in a previous mai=
l and drives to the use cases regarding realm overload:

 <=
/p>

- =
;        
If realm overload=
 is due to server overload, I would think that  our current  mech=
anism dealing with host report and realm (alias realm-routed) report
 will address / solve server overload  and in consequence indirectly &=
nbsp;address / solve  this overload realm  case=



- =
;        
if realm overload=
 is due to the overload of Diameter agents, we have discussion and a Steve&=
#8217;s  proposal   about  Agent overload. I would also=
 think
 that by addressing / solving the DA overload, it would also address and so=
lve this overload realm  case.



- =
;        
About an underlyi=
ng  network congestion (eg due to network outage), here REQ 13 mention=
s that “The solution MUST NOT interfere with the congestion
 control mechanisms of underlying transport protocols”. So here I am =
also questioning if  we may have  duplication or overlapping, and=
 what to do .


- =
;        
Have we other rea=
lm overload use cases?



 <=
/p>

So my current thinking is=
  we have first  to identify the various realm  overload use=
 cases and see those actually justifying to add new mechanisms.<=
/span>


 <=
/p>


2)  &=
nbsp;  
I share Ulrich=
217;s questions  on how to deal with realm overload. Steve’s &nb=
sp;answer introduces a high complexity about detecting , evaluate the realm
 overload  and then which DA are acting etc. The fact to consider many=
 of these points out of the scope does not suppress this complexity (which =
in addition occurs in an overloaded environment…) . So  I come b=
ack to my point 1 about the use cases to address
  and the use of the mechanisms for server and DA overload  


 


Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 18 f=E9vrier 2014 15:55

=C0 : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
o:p>






 


Ulrich,



All good questions.



I mapped out the use case in a previous email with discussing the realm-rou=
ted overload report type. 




Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm ho=
ping someone involved in the discussions that lead to that requirement can =
speak up on the use case driving the need for realm reports.



The means of detection is out of scope for the DOIC draft, just as it is fo=
r host and realm-routed report types.  We should, however, include wor=
ding to explain how it might be done. 




A few bullet points outlining a proposed solution.  I can put together=
 a couple of slides explaining this if it would be helpful.



- The method of detection can be based on the collected status of Diameter =
nodes in the realm.  It can also be based on the status of the underly=
ing network.  For instance, if there is a network outage that reduces =
the effective throughput of the signaling
 network, the best method for handling this might be to signal a realm over=
load report.



- The network element detecting the realm status is out of scope for the DO=
IC document.



- The Diameter node that reports realm overload can be any Diameter node an=
d is up to the service provider to define.  Assuming we are using Diam=
eter answer messages to transport the realm reports, it would need to be ei=
ther all agents or all servers.  This
 is to guarantee that all reacting nodes get the report.



- The method that the reporting node is told that the realm is overloaded, =
triggering the realm overload report, is out of scope for this document.


- Reacting nodes should listen to only one realm overload reporting node.&n=
bsp; It is up to the implementation of the realm overload detection element=
 to make sure that all reporting nodes have the same state.



One way to model this is for an external element being responsible for dete=
cting realm overload and signaling the realm overload reporting nodes of th=
e status using an out of bands mechanism.  All realm overload reportin=
g nodes would be responsible for sending
 realm overload reports.  Reacting nodes would only listen to one of t=
he reporting nodes.



There are also security considerations similar to host reports, except that=
 an attack using realm overload reports has a much bigger impact than an at=
tack using host reports.



Steve




On 2/18/14 7:41 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve,<=
/p>

 <=
/p>

first of all I would like=
 to better understand the usecase especially on the reporting side.<=
o:p>


Which node would act as a=
 reporting node generating new realm-type reports?


How would this node detec=
t that the complete realm is in overload (and what does that mean? All serv=
ers in the realm, also clients? Agents? )?


Would this node be (logic=
ally) a single node? If not, how to synchronize different new-realm-type re=
porting nodes so that they don’t report different things
 to the same reacting node?


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, February 18, 2014 1:48 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP






 


It shouldn't be much =
work to add realm overload to the draft.  We would need to do the foll=
owing (at a minimum):



- Change that name of the current realm report to something like "real=
m-routed".

- Create a new report type of name realm that applies to all traffic routed=
 to the realm.

- Add a few words in the reporting node section about generation of realm r=
eports.

- Define the interaction between realm, realm-routed and host report types.=
  This is probably the most difficult part that is likely to require s=
ome discussion.



Other then the section on interactions between report types, I don't think =
this impacts the existing text so it should fold in pretty cleanly.



I'd be happy to take the first shot at this to be included in the -02 versi=
on of the draft if there is consensus to add it.



Steve




On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:=







Hello all,


 <=
/p>

Overload of the realm is =
one of the use cases that is required by 3GPP applications.


And I think this should b=
e part of the basic mechanism, or?


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: lunes, 17 de febrero de 2014 18:53

To: dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP






 


Hi


 <=
/p>

I share the view to analy=
ze the overload of the realm as a whole in a separate extension  and s=
ee if this lead to another report type.


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



  <=
/o:p>


 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 17 f=E9vrier 2014 17:13

=C0 : Ben Campbell

Cc : dime@ietf.org list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP<=
/span>






 


I do think it would b=
e a new report type, as it would require different behavior from reacting n=
odes.



I'm ok with this being in a separate extension if the group thinks this is =
the correct approach.  We are creating a good number of relatively sma=
ll extensions.  It might lead to the need to pull them all together in=
 a future version of the DOIC draft/RFC.



Steve




On 2/14/14 4:21 PM, Ben Campbell wrote:





(Apologies for coming late to this thread)


 


On Feb 13, 2014, at 6:35 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Ok, Ok, no reason to gang up on me. :-)


What we have here is an overload report to reduce realm routed request=
s.  I think we should be explicit in the draft to define it as such.


 




 


At the risk of joining the anti-Steve gang, I feel the need to belated=
ly mention that my personal intent way back when we talked about the mixed-=
state problem was that realm reports applied to realm-routed requests. 


 




I am still concerned that we do not have a way to indicate overload of=
 the realm as a whole.  I'll enter a new trouble ticket to capture thi=
s issue.


 




 


I do not object to adding that ability. Would it be a new OLR type? If=
 so, would it need to go in the base draft or could it be an extension?


 




Steve




 


 




 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 






--_000_E194C2E18676714DACA9C3A2516265D202669A38FR712WXCHMBA12z_--


From nobody Tue Feb 18 11:48:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1667F1A052B for ; Tue, 18 Feb 2014 11:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XTlsHqow7CK for ; Tue, 18 Feb 2014 11:48:55 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id D1A5A1A053D for ; Tue, 18 Feb 2014 11:48:54 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id E099D19079E for ; Tue, 18 Feb 2014 20:48:50 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id C2FFF15815E for ; Tue, 18 Feb 2014 20:48:50 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 20:48:50 +0100
From: 
To: "DiME@ietf.org" 
Thread-Topic: Closing some issues on overload control
Thread-Index: Ac8s4nH63JgbDztaS9mDzPNVlg2tjQ==
Date: Tue, 18 Feb 2014 19:48:50 +0000
Message-ID: <2425_1392752930_5303B922_2425_17885_1_jcyy7dj4qrc7r3u9p8nxbrhf.1392752924682@email.android.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="utf-8"
Content-ID: <0B58F1E377F5944C8D3D9E5C328DFD98@adroot.infra.ftgroup>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.18.170015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NEGoYChEFpLgNRCHrrmux49LVHs
Subject: [Dime] Closing some issues on overload control
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 19:48:57 -0000

SGksCgpJdCB0b29rIHNvbWUgdGltZXMgdG8gdHJpZ2dlciB0aGUgdXNlIG9mIHRoZSBpc3N1ZSB0
cmFja2VyIGJ1dCBmaW5hbGx5IGEgbG90IG9mIHRpY2tldHMgd2VyZSBjcmVhdGVkIGFuZCBuZXcg
b25lcyBhcmUgc3RpbGwgY29taW5nLgoKSW4gb3JkZXIgdG8gcHJvZ3Jlc3MsIGl0IHdpbGwgYmUg
YWxzbyBhIGdvb2QgaWRlYSB0byBjbG9zZSB0aWNrZXRzIHdoZW4gYSBjb25jbHVzaW9uIGhhcyBi
ZWVuIHJlYWNoZWQuCgpJIHdvdWxkIHByb3Bvc2UgdGhhdCB0aWNrZXQgaW5pdGlhdG9ycyB0cmFj
ayB0aGUgY29uY2x1c2lvbnMgdGhhdCBjb3VsZCBiZWVuIGdpdmVuLCBwcm9wb3NlIGEgY29uY2x1
c2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBjbG9zZSB0aGUgdGlja2V0KHMpIG9uIHRoZSBp
c3N1ZSB0cmFja2VyLiBUaGlzIHdpbGwgaGVscCB0aGUgcHJlcGFyYXRpb24gb2YgdGhlIGRpbWUg
c2Vzc2lvbiBhdCB0aGUgbmV4dCBJRVRGIG1lZXRpbmcuCgpDaGVlcnMsCgpMaW9uZWwgCgpFbnZv
ecOpIGRlcHVpcyBtb24gU29ueSBYcGVyaWEgU1AgZCdPcmFuZ2UKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn
ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z
IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl
dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2
b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy
CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50
ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy
YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug
YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk
IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v
dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ
ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo
ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg
ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg
dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu
Cgo=


From nobody Wed Feb 19 00:44:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14691A0080 for ; Wed, 19 Feb 2014 00:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR9w0N5DHFzw for ; Wed, 19 Feb 2014 00:44:49 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C92ED1A0190 for ; Wed, 19 Feb 2014 00:44:48 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1J8ii0B024450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Feb 2014 09:44:44 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1J8iitB021574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Feb 2014 09:44:44 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 19 Feb 2014 09:44:44 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 09:44:43 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" 
Thread-Topic: Issue#29 proposed conclusion
Thread-Index: Ac8tTtW08OOXi3GFTYCACj/qENR9Rg==
Date: Wed, 19 Feb 2014 08:44:43 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.126]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3B73DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2770
X-purgate-ID: 151667::1392799484-00003660-0CE3EB51/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cd9oBeP2z-xoVOiAt0tuUG-Fmoo
Subject: [Dime] Issue#29 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 08:44:51 -0000

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

#29: OC-Sequence-Number in OC-Supported-Features

Dear all,

I have received comments from Lionel, Jouni and Steve;
I understand that Lionel and myself support removal of OC-Sequence-Number A=
VP from OC-Supported-Features AVP while Jouni has no strong view.  I'm not =
sure whether Steve is convinced by the response given to his comments.

In summary I dare to propose that we conclude in favour of removing OC-Sequ=
ence-Number from OC-Supported-Features.

Ulrich


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











#29: OC-Sequence-Number in OC-Supported-Features


&nbs=
p;


Dear=
 all,


&nbs=
p;


I ha=
ve received comments from Lionel, Jouni and Steve; 


I un=
derstand that Lionel and myself support removal of OC-Sequence-Number AVP f=
rom OC-Supported-Features AVP while Jouni has no strong view.  I’=
;m not sure whether Steve is convinced by the response
given to his comments.


&nbs=
p;


In s=
ummary I dare to propose that we conclude in favour of removing OC-Sequence=
-Number from OC-Supported-Features.


&nbs=
p;


Ulri=
ch


&nbs=
p;





--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3B73DEMUMBX014nsnin_--


From nobody Wed Feb 19 01:28:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9BE1A009E for ; Wed, 19 Feb 2014 01:28:41 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVRQkRB-DnRk for ; Wed, 19 Feb 2014 01:28:39 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BE6DE1A008D for ; Wed, 19 Feb 2014 01:28:38 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id p9so96724lbv.6 for ; Wed, 19 Feb 2014 01:28:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=9oytu0vx3viIPwsYQAaQOLkGrGdorT/RMNsJaqtEeq0=; b=vrgSc1pJDI/ltp0ped2YN/zubtPYR+oPA2+jIP3g2+KdwNwMxUaEtT/Hl+MurXInYw truMF1tH819oW33UPR7umpuAfscFms2j1DDrWepLzpAKoSNGqT9zj4H+U0Z8o4wRFYMj nwgPAsyk/KBF7+gIHxweugCl4mJAVT5E7xNhySyD7sjL66Auo1ixtEQWxzX5vHntnQGW AsRC0Z7mNVxxTbqNyuIugfTqafClCqW58iTaYCbUcwwU8O+aaUMnqVRDpGDtDhDlFDsv 7LQSkMp1OHLgtU433xtIbo4EPm63DX9ORpG4G8FaZ5388B0+qsBh1VM8yxvB077BMqxW HCKQ==
X-Received: by 10.152.164.166 with SMTP id yr6mr25564145lab.1.1392802114915; Wed, 19 Feb 2014 01:28:34 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id gb8sm26846454lbc.13.2014.02.19.01.28.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 01:28:34 -0800 (PST)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 19 Feb 2014 11:28:31 +0200
Message-Id: 
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Cp458n2bnz_6WO53GObGFcdtVfI
Subject: [Dime] Draft agenda for IETF#89 DIME meeting
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 09:28:41 -0000

Folks,

Slightly late as always..
http://www.ietf.org/proceedings/89/agenda/agenda-89-dime

We have reserved as much time as possible for the overload
topic.

Agenda comments/change requests asap, please.


- Jouni & Lionel

**


DIME WG IETF 89 Agenda =20

Chairs:
Jouni Korhonen 
Lionel Morand@ 

Jabber room: dime at jabber.ietf.org (Please join)
THURSDAY, March 6, 2014
0900-1130  Morning Session I (150 mins)
Richmond/Chelsea/Tower

09:00 - 09:10, Preliminaries (10 minutes)
------------------------------------------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

 o draft-ietf-dime-app-design-guide-21   -> IESG
 o draft-ietf-dime-e2e-sec-req-01        -> About ready -> WGLC
 o draft-ietf-dime-group-signaling-03    -> in WG
 o draft-ietf-dime-ovli-01               -> in WG
 o draft-ietf-dime-pmip6-lr-18           -> AUTH48
 o draft-ietf-dime-rfc4005bis-14         -> AUTH48

Working group draft discussion (20 minutes)
-------------------------------------------

09:10 - 09:30 Diameter Group Signaling, Marco (20 minutes)
https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/

Chartered individual draft discussion (15 minutes)
--------------------------------------------------

09:30 - 09:45 Diameter Congestion and Filter Attributes, Brent (15 =
minutes)
=
https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attribut=
es/

Diamater Overload discussion (80 minutes)
-----------------------------------------

09:45 - 11:05 Diameter Overload Indication Conveyance, Jouni/Steve (80 =
minutes)
https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/


+ 15 mins buffer / break..

Wrap-up (10 minutes)
--------------------
11:20 - 11:30 Next Steps: WG Chairs & ADs (10 minutes)=20
WG Goals/Milestones status, next steps=20=


From nobody Wed Feb 19 01:57:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8031A0396 for ; Wed, 19 Feb 2014 01:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GCCUq0TTiFj for ; Wed, 19 Feb 2014 01:57:45 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5805E1A00B7 for ; Wed, 19 Feb 2014 01:57:45 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1J9vfgJ014283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Feb 2014 10:57:41 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1J9veaa017287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Feb 2014 10:57:40 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 19 Feb 2014 10:57:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 10:57:40 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org list" 
Thread-Topic: Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3g==
Date: Wed, 19 Feb 2014 09:57:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.126]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3BCFDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3013
X-purgate-ID: 151667::1392803861-00005322-CBAD230C/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DA2CWGbOIfkkHd7uWXhhf0jILrg
Subject: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 09:57:48 -0000

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

#30: OC-Supported-Features AVP in answer messages

Dear all,

It may be too early to finaly conclude on this one.

It seems we have consensus in the following: Absence of Supported-Features-=
AVP from an answer message MUST not result in reacting nodes to cease sendi=
ng of any DOIC related AVPs in subsequent requests.

It is still open whether we can remove OC-Supported-Features from answer me=
ssages. However we seem to agree that the meaning of OC-OLR AVP is not depe=
ndent from any OC-Supported-Features AVP within the same answer.

The open question seems to be whether it is required for reacting nodes to =
do different throttlings based on implicit signals towards a) non-supportin=
g destinations  and b) supporting but not traffic-reduction-requesting dest=
inations. If required it seems also be clear that an additional indication =
is needed to indicate whether the OC-Supported-Feature AVP was inserted by =
the server (host) or by an agent (realm).

Ulrich


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











#30: OC-Supported-Features AVP in answer messages


 


Dear all,


 


It may be too early to finaly conclude on this one.


 


It seems we have consensus in the following: Absence of Supported-Feat=
ures-AVP from an answer message MUST not result in reacting nodes to cease =
sending of any DOIC related AVPs in subsequent requests.


 


It is still open whether we can remove OC-Supported-Features from answ=
er messages. However we seem to agree that the meaning of OC-OLR AVP is not=
 dependent from any OC-Supported-Features AVP within the same answer.


 


The open question seems to be whether it is required for reacting node=
s to do different throttlings based on implicit signals towards a) non-supp=
orting destinations  and b) supporting but not traffic-reduction-reque=
sting destinations. If required it seems
also be clear that an additional indication is needed to indicate whether t=
he OC-Supported-Feature AVP was inserted by the server (host) or by an agen=
t (realm).


 


Ulrich


 





--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3BCFDEMUMBX014nsnin_--


From nobody Wed Feb 19 02:25:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C061A00BF for ; Wed, 19 Feb 2014 02:25:01 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMHUajbBj2OK for ; Wed, 19 Feb 2014 02:24:59 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1961A0457 for ; Wed, 19 Feb 2014 02:24:59 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id y1so142599lam.13 for ; Wed, 19 Feb 2014 02:24:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=04gI+z22/S1b3kWWT19weuuUlKKKefm1UCtl6g3KUy8=; b=X5O3pY/n+zNgKVNoMaSvLjZidxcrGjZPT77mSeZqqByI4sutCDBVoTgwLePNqpp7zq jMf1UfsemfPbLSX73Pz51+20/JWi4VHf6WiUVnowzJR5SepPvZHMZPCAT604uDAtCqod UaugQ+VcBjNPoXr+1BcRcr4eTErzd6OJu3wU0sNAz+kTi4S74ksfgwytEWc+WBFlQOct ZSJ43/HZ6ji7oONVP28fKlbDJAXD4h0pyMmC7qkU7ubkrPRQO4lg3PO0OWajInFDGKJS M8NSjze9oiyMuO2rmqz/uEwI0dpvSGjaGxxb/+BdJCDvKjtLtIQrzqWQP4iEAJi0vSEN w01w==
X-Received: by 10.152.26.135 with SMTP id l7mr1510530lag.43.1392805495689; Wed, 19 Feb 2014 02:24:55 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id cu8sm27010171lbb.12.2014.02.19.02.24.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 02:24:49 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>
Date: Wed, 19 Feb 2014 12:24:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_XlvWalx7utgP5fSYVC9d9sWFRk
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 10:25:01 -0000

On Feb 19, 2014, at 11:57 AM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> #30: OC-Supported-Features AVP in answer messages
> =20
> Dear all,
> =20
> It may be too early to finaly conclude on this one.
> =20
> It seems we have consensus in the following: Absence of =
Supported-Features-AVP from an answer message MUST not result in =
reacting nodes to cease sending of any DOIC related AVPs in subsequent =
requests.

This is OK.

> =20
> It is still open whether we can remove OC-Supported-Features from =
answer messages. However we seem to agree that the meaning of OC-OLR AVP =
is not dependent from any OC-Supported-Features AVP within the same =
answer.

I do not agree that the OC-OLR meaning is not dependant on the =
OC-Supported-Features in the answer.

> The open question seems to be whether it is required for reacting =
nodes to do different throttlings based on implicit signals towards a) =
non-supporting destinations  and b) supporting but not =
traffic-reduction-requesting destinations. If required it seems also be =
clear that an additional indication is needed to indicate whether the =
OC-Supported-Feature AVP was inserted by the server (host) or by an =
agent (realm).

Right.


- Jouni

> =20
> Ulrich
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Feb 19 03:25:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D996C1A058D for ; Wed, 19 Feb 2014 03:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-kXioomPyBy for ; Wed, 19 Feb 2014 03:25:00 -0800 (PST)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1A1A058A for ; Wed, 19 Feb 2014 03:25:00 -0800 (PST)
Received: by mail-pd0-f178.google.com with SMTP id fp1so255923pdb.9 for ; Wed, 19 Feb 2014 03:24:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:to:from:reply-to:subject:message-id:mime-version :content-transfer-encoding:content-type; bh=pzMI8+V3MspsllLspBD1kro1XwC0aF8TseOB23eoW/M=; b=I1K/r0aY5FwNJ9FSZADbesrBEDzg6PLWPnBBTbk767fqe0N9bwH5GcPegfDw5Ld+cv dTHijyUiAjAG6HhGQVzhwTvW//DkOTjowk41/DXl8jdbvP2cIaw3yqF/kZUNKhJ8NIyQ w0U0pw9GgeHycyKsiBu5v7v60c5icEBw1wzngsV9RhqhwNB1HYdUz6fbNUpauK0VP7W5 AtXTrDgW45YYpa0b6Uq8Lakobso+mBUMDCE2t4FjV6dx/QfDz2aai3wUVIzWUHSX6fen p3x9IG1rnHUDaA2Ip0DXSjwJ7281pweFsutk+7mY/8sdIMKlxkot7qKjJMaNLIBCh3oq c2uA==
X-Received: by 10.68.200.74 with SMTP id jq10mr1549436pbc.169.1392809097580; Wed, 19 Feb 2014 03:24:57 -0800 (PST)
Received: from www.queryhome.com (ec2-54-214-12-95.us-west-2.compute.amazonaws.com. [54.214.12.95]) by mx.google.com with ESMTPSA id qw8sm64760135pbb.27.2014.02.19.03.24.56 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 19 Feb 2014 03:24:56 -0800 (PST)
Date: Wed, 19 Feb 2014 11:24:55 +0000
To: dime@ietf.org
From: Kevin Peterson 
Message-ID: 
X-Priority: 3
X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net)
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZfrDz3-iIixbh733wLbXT50WmQM
Subject: [Dime] I have a doubt in Failover and Fallback mechanisms present under DIAMETER.
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Kevin Peterson 
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2014 11:25:02 -0000

Hi, 

Failover and Fallback procedures we know very well.

Suppose initial message was supposed to send to primary peer, but peer went down and message has been forwarded to Secondary peer i.e. Failover. Now suppose if Primary Peer has come up and according to DIAMETER theory the message should go to primary peer. So the next message will be Update message. Which will have the same session id which was used with the initial message. 

Now my doubt is how the primary peer will recognize the session-id of update message. Because it has no info for that session. The session was created with the secondary peer. 

Thanks,
Kevin Peterson



From nobody Wed Feb 19 04:37:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C21A05B4 for ; Wed, 19 Feb 2014 04:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT1MriSL4giO for ; Wed, 19 Feb 2014 04:37:53 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE11A0593 for ; Wed, 19 Feb 2014 04:37:52 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1JCblKM018693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Feb 2014 13:37:47 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1JCbl73004083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 13:37:47 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 13:37:47 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNA=
Date: Wed, 19 Feb 2014 12:37:46 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.126]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2988
X-purgate-ID: 151667::1392813468-00003660-57A5DBAC/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AOr5HqMhfg5WNP4yS1a_75DNG_I
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 12:37:56 -0000

Hi Jouni,

thank you for your reply, and sorry for not having correctly summarized the=
 status with regard to dependencies between OC-OLR AVP and OC-Supported-Fea=
tures AVP in an answer message.

I would like to further discuss this aspect.
My understanding is: as long as only OLR_DEFAULT_ALGO (0x0000000000000001) =
is supported, there is no such dependency.
Furthermore: even with the introduction of Rate-control in draft-donovan-di=
me-doc-rate-control-00, no such dependency is introduced.=20
An OLR is a loss-type OLR when it contains a Reduction-Percentage and it's =
a rate-type OLR when it contains an OC-Maximum-Rate AVP (see draft-donovan-=
dime-doc-rate-control-00 clause 4.1).

A future extension may introduce such dependency (although I don't think it=
's a good idea) e.g. by saying that an OLR is a new-feature-type OLR when t=
he OC-Supported-Features AVP in the same answer message indicates support o=
f new-feature, and a loss-type OLR otherwise; however this is subject to be=
 specified in the extension spec, not in draft-ietf-dime-ovli.

Summary: currently no dependency; currently dependency is no reason to have=
 OC-Supported-Feature in anwers; new feature may introduce the dependency a=
nd consequently introduce OC-Supported-Feature in answer.

Ulrich





-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, February 19, 2014 11:25 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Feb 19, 2014, at 11:57 AM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> #30: OC-Supported-Features AVP in answer messages
> =20
> Dear all,
> =20
> It may be too early to finaly conclude on this one.
> =20
> It seems we have consensus in the following: Absence of Supported-Feature=
s-AVP from an answer message MUST not result in reacting nodes to cease sen=
ding of any DOIC related AVPs in subsequent requests.

This is OK.

> =20
> It is still open whether we can remove OC-Supported-Features from answer =
messages. However we seem to agree that the meaning of OC-OLR AVP is not de=
pendent from any OC-Supported-Features AVP within the same answer.

I do not agree that the OC-OLR meaning is not dependant on the OC-Supported=
-Features in the answer.

> The open question seems to be whether it is required for reacting nodes t=
o do different throttlings based on implicit signals towards a) non-support=
ing destinations  and b) supporting but not traffic-reduction-requesting de=
stinations. If required it seems also be clear that an additional indicatio=
n is needed to indicate whether the OC-Supported-Feature AVP was inserted b=
y the server (host) or by an agent (realm).

Right.


- Jouni

> =20
> Ulrich
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Feb 19 04:55:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBF1A047F; Wed, 19 Feb 2014 04:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level: 
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVeakirrNeCU; Wed, 19 Feb 2014 04:32:24 -0800 (PST)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 71D691A05A6; Wed, 19 Feb 2014 04:32:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 6D31B3FB60; Wed, 19 Feb 2014 13:32:20 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon21.um.es
Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TU9C1ZrztsuG; Wed, 19 Feb 2014 13:32:20 +0100 (CET)
Received: from inf-205-172.inf.um.es (inf-205-172.inf.um.es [155.54.205.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 662313FB5F; Wed, 19 Feb 2014 13:32:16 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Rafa Marin Lopez 
In-Reply-To: <52FDDD10.1050306@restena.lu>
Date: Wed, 19 Feb 2014 13:32:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6347417E-BFC9-426E-B15F-09E9B1C50925@um.es>
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu>
To: Stefan Winter 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dW3dNSXAj5c71Gviq1p2sOiSKGo
X-Mailman-Approved-At: Wed, 19 Feb 2014 04:55:22 -0800
Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" , Rafa Marin Lopez 
Subject: Re: [Dime] [abfab] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 12:32:28 -0000

Hi Stefan:

I have taken a look to this draft. Regarding the conversion to UTF-8 =
nothing to say.

Regarding=20

"1.  The choice of identity to send in EAP-Response/Identity may have
       detrimental effects on the subsequent EAP type negotiation."

as far as I remember, it was discussed long time ago as a problem of =
network selection (http://tools.ietf.org/html/rfc5113). See section 2.2. =
Identity Selection. Your approach here (if I properly understood) seems =
to allow the user to try all the identities before reporting an error =
(note that this may imply association/dissociation processes at =
link-layer to re-start the whole authentication process). The approach =
there is to provide the user with the required information to select the =
right username.=20

In the particular case of WiFi networks it would be also good to take a =
look to IEEE 802.11u and hotspot 2.0 (e.g. these slides, which you may =
already know, are interesting =
http://www.terena.org/activities/tf-mobility/meetings/26/07-11u-Dave.pptx)=


Just my 0.02 cents.

Best Regards.

P.D: Btw, I agree with Alan: it would good to have a "roaming =
inter-operations" WG.=20

P.D.2: Among other things, it would be also good if some information =
about accessible realms from a NAS could be provided in a dynamic way to =
the peer.=20


El 14/02/2014, a las 10:08, Stefan Winter  =
escribi=F3:

> Hello,
>=20
> I've just submitted an -00 on a topic that we've been struggling with =
in
> ABFAB recently (but which exists in every EAP-over-AAA scenario, not
> limited to ABFAB).
>=20
> =
http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapiden=
tity-00.txt
>=20
> Abstract:
>   There are some subtle considerations for an EAP peer regarding the
>   content of the EAP-Response/Identity packet when authenticating with
>   EAP to an EAP server.  This document describes two such
>   considerations and suggests workarounds to the associated problems.
>=20
> The issue touches multiple areas and working groups (EAP, EAP methods,
> RADIUS, Diameter) so I had to do a guesstimate for a proper home. I
> would think radext is the best match, cc'ing abfab and dime, and also
> emu even though it's shutting down).
>=20
> If you recall those in-depth discussions about fixing either EAP =
methods
> to use UTF-8, or why EAP Identity would need to be restrained to UTF-8
> even if a method doesn't do it, then yes: the draft is about that.
>=20
> In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057:
> "Circumstances might require that applications need to perform
> conversion of identities from an application specific character set to
> UTF-8 or another character set required by a particular EAP method."
>=20
> Which was enough to get the document through IESG, but this should
> better be fixed more generally for every EAP use case; hence this new =
draft.
>=20
> It's short and concise - I'd appreciate if you could give it a read =
and
> comment.
>=20
> If there's still free time on the agenda, I would also merrily discuss
> it in London.
>=20
> Greetings,
>=20
> Stefan Winter
>=20
> P.S.: Don't miss my other submission about an EAP Configuration File
> Format, which I've been told to submit to ops-area/opsawg:
>=20
> http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/
>=20
> Annoucement here:
> http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html
>=20
> -------- Original Message --------
> Subject: New Version Notification for
> draft-winter-radext-populating-eapidentity-00.txt
> Date: Fri, 14 Feb 2014 00:43:29 -0800
> From: internet-drafts@ietf.org
> To: Stefan Winter , "Stefan Winter"
> 
>=20
>=20
> A new version of I-D, =
draft-winter-radext-populating-eapidentity-00.txt
> has been successfully submitted by Stefan Winter and posted to the
> IETF repository.
>=20
> Name:		draft-winter-radext-populating-eapidentity
> Revision:	00
> Title:		Considerations regarding the correct use of =
EAP-Response/Identity
> Document date:	2014-02-14
> Group:		Individual Submission
> Pages:		6
> URL:
> =
http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapiden=
tity-00.txt
> Status:
> =
https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidentit=
y/
> Htmlized:
> =
http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00
>=20
>=20
> Abstract:
>   There are some subtle considerations for an EAP peer regarding the
>   content of the EAP-Response/Identity packet when authenticating with
>   EAP to an EAP server.  This document describes two such
>   considerations and suggests workarounds to the associated problems.
>=20
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20
>=20
>=20
> <0x8A39DC66.asc>_______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------





From nobody Wed Feb 19 06:17:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C11A05B6 for ; Wed, 19 Feb 2014 06:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlqq5SEFvYPV for ; Wed, 19 Feb 2014 06:17:18 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B8E101A0491 for ; Wed, 19 Feb 2014 06:17:16 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1JEHBqc002255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Feb 2014 15:17:11 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1JEH9rp022177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Feb 2014 15:17:10 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 19 Feb 2014 15:17:09 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 15:17:09 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org list" 
Thread-Topic: Issue#31 status
Thread-Index: Ac8tfUYIV82WBUGEQQ+YDsLcVKoJfQ==
Date: Wed, 19 Feb 2014 14:17:09 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.126]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2488
X-purgate-ID: 151667::1392819431-00003660-FBA4AC7B/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/C3f3hoSlW5A0aH_e0cmKdpBop2I
Subject: [Dime] Issue#31 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 14:17:20 -0000

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

#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that surviv=
ed a throttling

Dear all,

I did not receive much support for the proposal to define an OC-Ongoing-Thr=
ottling-Info AVP in request messages that survived a throttlting.

However, we seem to agree on some principles:

Missing OLR in answer means "no change"; it does not mean "no overload/no t=
hrottling requested"

Reporting nodes SHOULD include OLR in every answer that it sends in respons=
e to a request message which indicated OLR_DEFAULT_ALGO support unless the =
reporting node has very good reasons not to do so. Exact wording is not yet=
 agreed.

Ulrich




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











#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that s=
urvived a throttling


 


Dear all,


 


I did not receive much support for the proposal to define an OC-Ongoin=
g-Throttling-Info AVP in request messages that survived a throttlting.

 


However, we seem to agree on some principles:


 


Missing OLR in answer means “no change”; it does not mean =
“no overload/no throttling requested”


 


Reporting nodes SHOULD include OLR in every answer that it sends in re=
sponse to a request message which indicated OLR_DEFAULT_ALGO suppo=
rt unless the reporting node has very
good reasons not to do so. Exact wording is not yet agreed. 


 


Ulrich


 


 


 





--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7DEMUMBX014nsnin_--


From nobody Wed Feb 19 07:34:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0C71A032A for ; Wed, 19 Feb 2014 07:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgzp1vN_mdF2 for ; Wed, 19 Feb 2014 07:34:05 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF0B1A032C for ; Wed, 19 Feb 2014 07:34:04 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1JFY02s017379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Feb 2014 16:34:00 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1JFY06q024755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Feb 2014 16:34:00 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 19 Feb 2014 16:33:59 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 16:33:59 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" 
Thread-Topic: Issue#32 status
Thread-Index: Ac8tiAGtvQe9mwQAS968RUS8ackr7w==
Date: Wed, 19 Feb 2014 15:33:58 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.126]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3D63DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2481
X-purgate-ID: 151667::1392824040-00003660-1BFEE95F/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OlPzVwvhhFKPEoUfInWIVwvREyE
Subject: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 15:34:07 -0000

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

#32: Sequence-Number Time-Stamp values within OC-OLR

I understand that we agreed the following principles:

Sequence-Number is of type Time, however the value need not correspond to t=
he point in time of generation.

When generated, a new sequence number must be  greater than any sequence nu=
mber previously generated by the same node (including over a reboot of that=
 node)

When received, a sequence number is used to detect outdates/replays/freshne=
ss.

Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.


I did not understand the requirement for globally uniqueness as introduced =
by Jouni.
Can Jouni please explain.

Ulrich




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











#32: Sequence-Number Time-Stamp values within OC-OLR


 


I understand that we agreed the following principles:


 


Sequence-Number is of type Time, however the value need not correspond=
 to the point in time of generation.


 


When generated, a new sequence number must be  greater than any s=
equence number previously generated by the same node (including over a rebo=
ot of that node)


 


When received, a sequence number is used to detect outdates/replays/fr=
eshness.


 


Sequence numbers of expired OLRs MUST NOT be remembered by reacting no=
des.


 


 


I did not understand the requirement for globally uniqueness as introd=
uced by Jouni.


Can Jouni please explain.


 


Ulrich


 


 


 





--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3D63DEMUMBX014nsnin_--


From nobody Wed Feb 19 12:11:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B0D1A04C1 for ; Wed, 19 Feb 2014 12:11:29 -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
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 No0lCqothWB9 for ; Wed, 19 Feb 2014 12:11:24 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 510531A04F7 for ; Wed, 19 Feb 2014 12:11:24 -0800 (PST)
Received: from 130.sub-70-196-5.myvzw.com ([70.196.5.130]:1063 helo=[192.168.43.20]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGDUE-0004xi-Rh for dime@ietf.org; Wed, 19 Feb 2014 12:11:20 -0800
Message-ID: <53050FE6.2090800@usdonovans.com>
Date: Wed, 19 Feb 2014 14:11:18 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------010008060602030804010205"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PqvyLxe-h4ot9i4_K0XVf9RmvO8
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 20:11:29 -0000

This is a multi-part message in MIME format.
--------------010008060602030804010205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

See comments inline.

Steve

On 2/19/14 9:33 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> #32: Sequence-Number Time-Stamp values within OC-OLR
>  
> I understand that we agreed the following principles:
>  
> Sequence-Number is of type Time, however the value need not correspond
> to the point in time of generation.
SRD> I don't agree that the type should be time.  It should be of type
Unsigned64.  A time stamp can be inserted into it but we should not
prevent simple sequence numbers.  I agree with the remainder of the
statement.
>  
> When generated, a new sequence number must be  greater than any
> sequence number previously generated by the same node (including over
> a reboot of that node)
SRD> Agreed
>  
> When received, a sequence number is used to detect
> outdates/replays/freshness.
SRD> Agreed
>  
> Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.
SRD> Agreed
>  
>  
> I did not understand the requirement for globally uniqueness as
> introduced by Jouni.
> Can Jouni please explain.
>  
> Ulrich
>  
>  
>  
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------010008060602030804010205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      See comments inline.

      

      Steve

      

    
    
On 2/19/14 9:33 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      
      
          
#32: Sequence-Number Time-Stamp values within OC-OLR

          
 

          
I understand that we agreed the following principles:

          
 

          
Sequence-Number is of type Time, however the value need
            not correspond to the point in time of generation.

        

    SRD> I don't agree that
          the type should be time.  It should be of type Unsigned64.  A
          time stamp can be inserted into it but we should not prevent
          simple sequence numbers.  I agree with the remainder of the
          statement.

    

          
 

          
When generated, a new sequence number must be  greater
            than any sequence number previously generated by the same
            node (including over a reboot of that node)

        

    SRD> Agreed

    

          
 

          
When received, a sequence number is used to detect
            outdates/replays/freshness.

        

    SRD> Agreed

    

          
 

          
Sequence numbers of expired OLRs MUST NOT be remembered
            by reacting nodes.

        

    SRD> Agreed

    

          
 

          
 

          
I did not understand the requirement for globally
            uniqueness as introduced by Jouni.

          
Can Jouni please explain.

          
 

          
Ulrich

          
 

          
 

          
 

        
      

      

      

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


    

    

  


--------------010008060602030804010205--


From nobody Wed Feb 19 12:12:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD21A04C1 for ; Wed, 19 Feb 2014 12:12:30 -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
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 qXtk9Y4iQPid for ; Wed, 19 Feb 2014 12:12:28 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id DB5761A0167 for ; Wed, 19 Feb 2014 12:12:28 -0800 (PST)
Received: from 130.sub-70-196-5.myvzw.com ([70.196.5.130]:1066 helo=[192.168.43.20]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGDVH-0006UU-UX for dime@ietf.org; Wed, 19 Feb 2014 12:12:25 -0800
Message-ID: <53051027.1050608@usdonovans.com>
Date: Wed, 19 Feb 2014 14:12:23 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------030406060603060209040406"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qHRzw7AFRzw4UTlmxBvjk90fJT8
Subject: Re: [Dime] Issue#31 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 20:12:31 -0000

This is a multi-part message in MIME format.
--------------030406060603060209040406
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Agreed

On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that
> survived a throttling
>  
> Dear all,
>  
> I did not receive much support for the proposal to define an
> OC-Ongoing-Throttling-Info AVP in request messages that survived a
> throttlting.
>  
> However, we seem to agree on some principles:
>  
> Missing OLR in answer means "no change"; it does not mean "no
> overload/no throttling requested"
>  
> Reporting nodes SHOULD include OLR in every answer that it sends in
> response to a request message which indicated OLR_DEFAULT_ALGO support
> unless the reporting node has very good reasons not to do so. Exact
> wording is not yet agreed.
>  
> Ulrich
>  
>  
>  
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------030406060603060209040406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Agreed

      

    
    
On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      
      
          
#31: Sending OC-Ongoing-Throttling-Info AVP in request
            messages that survived a throttling

          
 

          
Dear all,

          
 

          
I did not receive much support for the proposal to define
            an OC-Ongoing-Throttling-Info AVP in request messages that
            survived a throttlting.

          
 

          
However, we seem to agree on some principles:

          
 

          
Missing OLR in answer means “no change”; it does not mean
            “no overload/no throttling requested”

          
 

          
Reporting nodes SHOULD include OLR in every answer that
            it sends in response to a request message which indicated OLR_DEFAULT_ALGO
              support unless the reporting node has very
            good reasons not to do so. Exact wording is not yet agreed.
          

          
 

          
Ulrich

          
 

          
 

          
 

        
      

      

      

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


    

    

  


--------------030406060603060209040406--


From nobody Wed Feb 19 12:22:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4413D1A022E for ; Wed, 19 Feb 2014 12:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0fM0K3_gfbl for ; Wed, 19 Feb 2014 12:22:24 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 250D41A0401 for ; Wed, 19 Feb 2014 12:22:24 -0800 (PST)
Received: from 130.sub-70-196-5.myvzw.com ([70.196.5.130]:1063 helo=[192.168.43.20]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGDep-0003Yf-UG; Wed, 19 Feb 2014 12:22:16 -0800
Message-ID: <53051277.3090301@usdonovans.com>
Date: Wed, 19 Feb 2014 14:22:15 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
References: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org>
In-Reply-To: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------070004040102040207080603"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/H_MC2tjhRw2_NW7w-F7Eeu4mRNs
Subject: Re: [Dime] [dime] #24: Terminology and Abbreviations
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 20:22:25 -0000

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

There has been no discussion of this ticket.

I propose that the definition of Diameter layer load balancing be removed.

I propose removing the definition of Topology Hiding, as it has meanings
outside of the context of Diameter overload.

I also propose that we remove any discussion of agents acting as server
front ends or topology hiders.  I propose instead to have a discussion
in section 5.5 outlining the requirements for an agent to take on the
role of a reporting node for host reports.

Regards,

Steve

On 1/28/14 2:13 PM, dime issue tracker wrote:
> #24: Terminology and Abbreviations
>
>  This applies to draft-ietf-dime-ovli.
>
>  Section 2. contains a definition of Diameter layer Load Balancing that
>  does not appear to be needed.  This was originally included as one of the
>  features of a Server Front End.  Given that SFE has been removed this can
>  be removed as well.
>
>  The definition of Topology Hiding is the generic Diameter topology hiding
>  definition.  This is different than the server identity hiding that an
>  agent might optionally do.  We should probably remove this definition and
>  insert a definition of server identity hiding for an agent that is
>  aggregating overload state across a server farm.
>


--------------070004040102040207080603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    There has been no
      discussion of this ticket.

      

      I propose that the definition of Diameter layer load balancing be
      removed.

      

      I propose removing the definition of Topology Hiding, as it has
      meanings outside of the context of Diameter overload.

      

      I also propose that we remove any discussion of agents acting as
      server front ends or topology hiders.  I propose instead to have a
      discussion in section 5.5 outlining the requirements for an agent
      to take on the role of a reporting node for host reports.

      

      Regards,

      

      Steve

      

    
    
On 1/28/14 2:13 PM, dime issue tracker
      wrote:

    

    

      
#24: Terminology and Abbreviations

 This applies to draft-ietf-dime-ovli.

 Section 2. contains a definition of Diameter layer Load Balancing that
 does not appear to be needed.  This was originally included as one of the
 features of a Server Front End.  Given that SFE has been removed this can
 be removed as well.

 The definition of Topology Hiding is the generic Diameter topology hiding
 definition.  This is different than the server identity hiding that an
 agent might optionally do.  We should probably remove this definition and
 insert a definition of server identity hiding for an agent that is
 aggregating overload state across a server farm.



    

    

  


--------------070004040102040207080603--


From nobody Wed Feb 19 12:29:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDEA1A04C1 for ; Wed, 19 Feb 2014 12:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaSEWGkA9JaL for ; Wed, 19 Feb 2014 12:29:44 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 16BD11A057F for ; Wed, 19 Feb 2014 12:29:44 -0800 (PST)
Received: from 130.sub-70-196-5.myvzw.com ([70.196.5.130]:1066 helo=[192.168.43.20]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGDlx-0004WP-RZ for dime@ietf.org; Wed, 19 Feb 2014 12:29:40 -0800
Message-ID: <53051431.9000800@usdonovans.com>
Date: Wed, 19 Feb 2014 14:29:37 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org>
In-Reply-To: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------070408000306040802060100"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2Tpm4nXKrg0JK5uaip1JRvX7G70
Subject: Re: [Dime] [dime] #25: Section 3.1.5 Diameter Agent Behavior
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 20:29:45 -0000

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

There has been no discussion of this ticket.

After further thought, I propose that this section be removed and the
requirements for agents acting as reporting nodes for host reports be
included in section 5.5.

If the section is kept then I propose removing the term "topology
hiding" and use server front end instead.  If we take this approach then
we need to have a definition of SFE in the terminology section.

Steve


On 1/28/14 2:18 PM, dime issue tracker wrote:
> #25: Section 3.1.5 Diameter Agent Behavior
>
>  This applies to draft-ietf-dime-ovli.
>
>  There are a number of concepts mentioned in this section that are not
>  sufficiently defined.  This includes Server Front End, topology hiding SFE
>  and back-to-back agent.
>
>  I suggest that we add the definition of SFE back to the terminology
>  section.
>
>  I also suggest that we start using the term "Server Identity Hiding" and
>  not use the term Topology Hiding.  Topology Hiding has a meaning outside
>  of DOIC that does not fit for DOIC.
>
>  I also think we should remove the concept of back-to-back agent.
>


--------------070408000306040802060100
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    There has been no
      discussion of this ticket.

      

      After further thought, I propose that this section be removed and
      the requirements for agents acting as reporting nodes for host
      reports be included in section 5.5.

      

      If the section is kept then I propose removing the term "topology
      hiding" and use server front end instead.  If we take this
      approach then we need to have a definition of SFE in the terminology
      section.

      

      Steve

      

      

    
    
On 1/28/14 2:18 PM, dime issue tracker
      wrote:

    

    

      
#25: Section 3.1.5 Diameter Agent Behavior

 This applies to draft-ietf-dime-ovli.

 There are a number of concepts mentioned in this section that are not
 sufficiently defined.  This includes Server Front End, topology hiding SFE
 and back-to-back agent.

 I suggest that we add the definition of SFE back to the terminology
 section.

 I also suggest that we start using the term "Server Identity Hiding" and
 not use the term Topology Hiding.  Topology Hiding has a meaning outside
 of DOIC that does not fit for DOIC.

 I also think we should remove the concept of back-to-back agent.



    

    

  


--------------070408000306040802060100--


From nobody Wed Feb 19 12:54:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBD51A04F2 for ; Wed, 19 Feb 2014 12:54:24 -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
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-kblkbsPD2X for ; Wed, 19 Feb 2014 12:54:22 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA721A0418 for ; Wed, 19 Feb 2014 12:54:22 -0800 (PST)
Received: from 130.sub-70-196-5.myvzw.com ([70.196.5.130]:1057 helo=[192.168.43.20]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGE9o-0003xy-2C for dime@ietf.org; Wed, 19 Feb 2014 12:54:18 -0800
Message-ID: <530519F7.1010207@usdonovans.com>
Date: Wed, 19 Feb 2014 14:54:15 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org>
In-Reply-To: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------090104000005040207030900"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lc2wNdhKmSaZ6UD1AgX0enbqGgk
Subject: Re: [Dime] [dime] #23: DOIC behavior for realm overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Feb 2014 20:54:24 -0000

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

We've had a lot of discussion of this topic.

I believe that we reached agreement that we currently have two types of
reports:

- Host report that applies to requests sent to a destination-host
- Realm report that applies requests routed to a realm that do not have
a specified destination-host (realm-routed requests)

We also have proposed wording on the interaction between these report
types. 

I propose that the second be renamed to realm-routed reports.

A separate ticket has been opened on the need for a third report type
that would apply to all request routed to a realm, independent of
whether a request contains a destination-host AVP.

Steve

On 1/21/14 9:24 AM, dime issue tracker wrote:
> #23: DOIC behavior for realm overload
>
>  This applies to draft-ietf-dime-ovli-01, which does not show up in the
>  Component drop down menu.
>
>  The current assumption in the -01 draft is inconsistent in the definition
>  of behavior of behavior by a reacting node when it receives a realm
>  overload report.
>
>  Section 4.6 says overload treatment should apply to all request bound for
>  the overloaded realm.
>
>  Section 5.5.2 is not clear and there have been interpretations that a
>  realm overload report only applies to requests that contain the realm and
>  do not contain a destination-host AVP.
>
>  Section 5.5.2 should be updated to be consistent with section 4.6.
>


--------------090104000005040207030900
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    We've had a lot of
      discussion of this topic.

      

      I believe that we reached agreement that we currently have two
      types of reports:

      

      - Host report that applies to requests sent to a destination-host

      - Realm report that applies requests routed to a realm that do not
      have a specified destination-host (realm-routed requests)

      

      We also have proposed wording on the interaction between these
      report types.  

      

      I propose that the second be renamed to realm-routed reports.

      

      A separate ticket has been opened on the need for a third report
      type that would apply to all request routed to a realm,
      independent of whether a request contains a destination-host AVP.

      

      Steve

      

    
    
On 1/21/14 9:24 AM, dime issue tracker
      wrote:

    

    

      
#23: DOIC behavior for realm overload

 This applies to draft-ietf-dime-ovli-01, which does not show up in the
 Component drop down menu.

 The current assumption in the -01 draft is inconsistent in the definition
 of behavior of behavior by a reacting node when it receives a realm
 overload report.

 Section 4.6 says overload treatment should apply to all request bound for
 the overloaded realm.

 Section 5.5.2 is not clear and there have been interpretations that a
 realm overload report only applies to requests that contain the realm and
 do not contain a destination-host AVP.

 Section 5.5.2 should be updated to be consistent with section 4.6.



    

    

  


--------------090104000005040207030900--


From nobody Thu Feb 20 01:00:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0DC1A0049 for ; Thu, 20 Feb 2014 01:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sknk7GdpvxHr for ; Thu, 20 Feb 2014 01:00:17 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9E71A003D for ; Thu, 20 Feb 2014 01:00:16 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1K9056P000676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Feb 2014 10:00:06 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1K905qw025514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 10:00:05 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 20 Feb 2014 10:00:04 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 10:00:04 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#32 status
Thread-Index: Ac8tiAGtvQe9mwQAS968RUS8ackr7wAHlw0AABv/01A=
Date: Thu, 20 Feb 2014 09:00:03 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3E8A@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <53050FE6.2090800@usdonovans.com>
In-Reply-To: <53050FE6.2090800@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.126]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3E8ADEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 12736
X-purgate-ID: 151667::1392886808-00003660-1EECB37C/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JM6le7euGcHgO1dDEqx0L3ZixZc
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 09:00:21 -0000

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

Steve,

I'm ok with Unsinged64 but then the second principle that says "...must be =
 greater ..." needs some enhancements to cover the overflow.

Ulrich





From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, February 19, 2014 9:11 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#32 status

Ulrich,

See comments inline.

Steve
On 2/19/14 9:33 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
#32: Sequence-Number Time-Stamp values within OC-OLR

I understand that we agreed the following principles:

Sequence-Number is of type Time, however the value need not correspond to t=
he point in time of generation.
SRD> I don't agree that the type should be time.  It should be of type Unsi=
gned64.  A time stamp can be inserted into it but we should not prevent sim=
ple sequence numbers.  I agree with the remainder of the statement.


When generated, a new sequence number must be  greater than any sequence nu=
mber previously generated by the same node (including over a reboot of that=
 node)
SRD> Agreed


When received, a sequence number is used to detect outdates/replays/freshne=
ss.
SRD> Agreed


Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.
SRD> Agreed



I did not understand the requirement for globally uniqueness as introduced =
by Jouni.
Can Jouni please explain.

Ulrich







_______________________________________________

DiME mailing list

DiME@ietf.org

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


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











Steve,


 =
;


I’m =
ok with Unsinged64 but then the second principle that says “…must
 be  greater …&=
#8221; needs some enhancements to cover the overflow.


 =
;


Ulrich


 =
;


 =
;


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Wednesday, February 19, 2014 9:11 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#32 status






 


Ulrich,



See comments inline.



Steve




On 2/19/14 9:33 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:








#32: Sequence-Number Time-Stamp values =
within OC-OLR






 






I understand that we agreed the followi=
ng principles:






 






Sequence-Number is of type Time, howeve=
r the value need not correspond to the point in time of generation.






SRD> I don't agree that the type should be time. =
; It should be of type Unsigned64.  A time stamp can be inserted into =
it but we should not prevent simple sequence numbers.  I agree with th=
e
 remainder of the statement.








 






When generated, a new sequence number m=
ust be  greater than any sequence number previously generated by the s=
ame node (including over a reboot of that node)




SRD> Agreed








 






When received, a sequence number is use=
d to detect outdates/replays/freshness.




SRD> Agreed








 






Sequence numbers of expired OLRs MUST N=
OT be remembered by reacting nodes.




SRD> Agreed








 






 






I did not understand the requirement fo=
r globally uniqueness as introduced by Jouni.






Can Jouni please explain.






 






Ulrich






 






 






 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3E8ADEMUMBX014nsnin_--


From nobody Thu Feb 20 02:52:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0DD1A00B0 for ; Thu, 20 Feb 2014 02:51:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IBo6KkEPUVE for ; Thu, 20 Feb 2014 02:51:57 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC0A1A0072 for ; Thu, 20 Feb 2014 02:51:56 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-a8-5305de479b0f
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E5.86.04853.74ED5035; Thu, 20 Feb 2014 11:51:52 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 11:51:51 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #25: Section 3.1.5 Diameter Agent Behavior
Thread-Index: AQHPLbFTvFcqfjVsjE6LjesyeHyOBpq99xjg
Date: Thu, 20 Feb 2014 10:51:51 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209783CFA@ESESSMB101.ericsson.se>
References: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org> <53051431.9000800@usdonovans.com>
In-Reply-To: <53051431.9000800@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209783CFAESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvja7HPdZggw/3OSzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu8j3ewFE4Irrp69wNLA+Cagi5GTQ0LAROLh01ZmCFtM4sK9 9WxdjFwcQgInGCVmP3rGCOEsZpQ4snMTC0gVm4CdxKXTL5i6GDk4RASUJU7/cgAJCwu4Ssx6 088OYosIuEnMmL2SFaLESGJVhwtImEVAVWLvuy1MIDavgK/EjgsrGUFsIYEsiWtTmtlAbE4B PYnvM0+A2YxA93w/tQasnllAXOLWk/lMEHcKSCzZcx7qZlGJl4//sULYShIrtl9ihKjPl5j1 7T4bxC5BiZMzn7BMYBSZhWTULCRls5CUzQK6mllAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUX MLKvYpQsTi0uzk03MtDLTc8t0UstykwuLs7P0ytO3cQIjKODW34b7WA8ucf+EKM0B4uSOO91 1pogIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwrjz0X+a1dMv1YU+YOtubmOY8ap96U8bwR +M4rUebjw9s+gmsmXOZzSG5Tuxhg7Hyqomj2SecDXkLGpwonzI/LyK9OPBR5w+GSuVNJufT1 v6E22W72BpJn9mvsY3JabHdQLmeescj35vtmL8rXprDoeUi26CVsj7eRWuvkkbXdv0R8+7aw tUosxRmJhlrMRcWJAIMJwxRxAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/85jkLKUIfdVsB3H6qOhazE1J2rs
Subject: Re: [Dime] [dime] #25: Section 3.1.5 Diameter Agent Behavior
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 10:51:59 -0000

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

SGVsbG8gU3RldmUsIGFsbCwNCg0KVGhlIGludGVudGlvbiBvZiBjaGFwdGVycyAzLjEuNSBhbmQg
NS41IGlzIHRvdGFsbHkgZGlmZmVyZW50Lg0KSW4gb3JkZXIgdG8gYmUgYWJsZSB0byBhZ3JlZSBv
ciBkaXNhZ3JlZSBJIHdvdWxkIG5lZWQgdG8gaGF2ZSBhIHdyaXR0ZW4gcHJvcG9zYWwgb2YgdGhl
IGNoYW5nZXMgYW5kIGFuIGV4cGxhbmF0aW9uIG9mIHRoZSByZWFzb24gZm9yIHRoZXNlIGNoYW5n
ZXMuDQoNCkJlc3QgcmVnYXJkcw0KL01DcnV6DQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBtacOpcmNv
bGVzLCAxOSBkZSBmZWJyZXJvIGRlIDIwMTQgMjE6MzANClRvOiBkaW1lQGlldGYub3JnDQpTdWJq
ZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMjU6IFNlY3Rpb24gMy4xLjUgRGlhbWV0ZXIgQWdlbnQg
QmVoYXZpb3INCg0KVGhlcmUgaGFzIGJlZW4gbm8gZGlzY3Vzc2lvbiBvZiB0aGlzIHRpY2tldC4N
Cg0KQWZ0ZXIgZnVydGhlciB0aG91Z2h0LCBJIHByb3Bvc2UgdGhhdCB0aGlzIHNlY3Rpb24gYmUg
cmVtb3ZlZCBhbmQgdGhlIHJlcXVpcmVtZW50cyBmb3IgYWdlbnRzIGFjdGluZyBhcyByZXBvcnRp
bmcgbm9kZXMgZm9yIGhvc3QgcmVwb3J0cyBiZSBpbmNsdWRlZCBpbiBzZWN0aW9uIDUuNS4NCg0K
SWYgdGhlIHNlY3Rpb24gaXMga2VwdCB0aGVuIEkgcHJvcG9zZSByZW1vdmluZyB0aGUgdGVybSAi
dG9wb2xvZ3kgaGlkaW5nIiBhbmQgdXNlIHNlcnZlciBmcm9udCBlbmQgaW5zdGVhZC4gIElmIHdl
IHRha2UgdGhpcyBhcHByb2FjaCB0aGVuIHdlIG5lZWQgdG8gaGF2ZSBhIGRlZmluaXRpb24gb2Yg
U0ZFIGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLg0KDQpTdGV2ZQ0KDQpPbiAxLzI4LzE0IDI6
MTggUE0sIGRpbWUgaXNzdWUgdHJhY2tlciB3cm90ZToNCg0KIzI1OiBTZWN0aW9uIDMuMS41IERp
YW1ldGVyIEFnZW50IEJlaGF2aW9yDQoNCg0KDQogVGhpcyBhcHBsaWVzIHRvIGRyYWZ0LWlldGYt
ZGltZS1vdmxpLg0KDQoNCg0KIFRoZXJlIGFyZSBhIG51bWJlciBvZiBjb25jZXB0cyBtZW50aW9u
ZWQgaW4gdGhpcyBzZWN0aW9uIHRoYXQgYXJlIG5vdA0KDQogc3VmZmljaWVudGx5IGRlZmluZWQu
ICBUaGlzIGluY2x1ZGVzIFNlcnZlciBGcm9udCBFbmQsIHRvcG9sb2d5IGhpZGluZyBTRkUNCg0K
IGFuZCBiYWNrLXRvLWJhY2sgYWdlbnQuDQoNCg0KDQogSSBzdWdnZXN0IHRoYXQgd2UgYWRkIHRo
ZSBkZWZpbml0aW9uIG9mIFNGRSBiYWNrIHRvIHRoZSB0ZXJtaW5vbG9neQ0KDQogc2VjdGlvbi4N
Cg0KDQoNCiBJIGFsc28gc3VnZ2VzdCB0aGF0IHdlIHN0YXJ0IHVzaW5nIHRoZSB0ZXJtICJTZXJ2
ZXIgSWRlbnRpdHkgSGlkaW5nIiBhbmQNCg0KIG5vdCB1c2UgdGhlIHRlcm0gVG9wb2xvZ3kgSGlk
aW5nLiAgVG9wb2xvZ3kgSGlkaW5nIGhhcyBhIG1lYW5pbmcgb3V0c2lkZQ0KDQogb2YgRE9JQyB0
aGF0IGRvZXMgbm90IGZpdCBmb3IgRE9JQy4NCg0KDQoNCiBJIGFsc28gdGhpbmsgd2Ugc2hvdWxk
IHJlbW92ZSB0aGUgY29uY2VwdCBvZiBiYWNrLXRvLWJhY2sgYWdlbnQuDQoNCg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv
Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M
IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s
b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ
Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y
PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBTdGV2ZSwgYWxsLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
VGhlIGludGVudGlvbiBvZiBjaGFwdGVycyAzLjEuNSBhbmQgNS41IGlzIHRvdGFsbHkgZGlmZmVy
ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBvcmRlciB0byBiZSBhYmxlIHRv
IGFncmVlIG9yIGRpc2FncmVlIEkgd291bGQgbmVlZCB0byBoYXZlIGEgd3JpdHRlbiBwcm9wb3Nh
bCBvZiB0aGUgY2hhbmdlcyBhbmQgYW4gZXhwbGFuYXRpb24gb2YgdGhlIHJlYXNvbiBmb3IgdGhl
c2UgY2hhbmdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4vTUNydXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv
d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3
aW5kb3d0ZXh0Ij4gRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl
aGFsZiBPZiA8L2I+U3RldmUgRG9ub3Zhbjxicj4NCjxiPlNlbnQ6PC9iPiBtacOpcmNvbGVzLCAx
OSBkZSBmZWJyZXJvIGRlIDIwMTQgMjE6MzA8YnI+DQo8Yj5Ubzo8L2I+IGRpbWVAaWV0Zi5vcmc8
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzI1OiBTZWN0aW9uIDMuMS41
IERpYW1ldGVyIEFnZW50IEJlaGF2aW9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGVyZSBoYXMgYmVl
biBubyBkaXNjdXNzaW9uIG9mIHRoaXMgdGlja2V0Ljxicj4NCjxicj4NCkFmdGVyIGZ1cnRoZXIg
dGhvdWdodCwgSSBwcm9wb3NlIHRoYXQgdGhpcyBzZWN0aW9uIGJlIHJlbW92ZWQgYW5kIHRoZSBy
ZXF1aXJlbWVudHMgZm9yIGFnZW50cyBhY3RpbmcgYXMgcmVwb3J0aW5nIG5vZGVzIGZvciBob3N0
IHJlcG9ydHMgYmUgaW5jbHVkZWQgaW4gc2VjdGlvbiA1LjUuPGJyPg0KPGJyPg0KSWYgdGhlIHNl
Y3Rpb24gaXMga2VwdCB0aGVuIEkgcHJvcG9zZSByZW1vdmluZyB0aGUgdGVybSAmcXVvdDt0b3Bv
bG9neSBoaWRpbmcmcXVvdDsgYW5kIHVzZSBzZXJ2ZXIgZnJvbnQgZW5kIGluc3RlYWQuJm5ic3A7
IElmIHdlIHRha2UgdGhpcyBhcHByb2FjaCB0aGVuIHdlIG5lZWQgdG8gaGF2ZSBhIGRlZmluaXRp
b24gb2YgU0ZFIGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLjxicj4NCjxicj4NClN0ZXZlPGJy
Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
MS8yOC8xNCAyOjE4IFBNLCBkaW1lIGlzc3VlIHRyYWNrZXIgd3JvdGU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHByZT4jMjU6IFNlY3Rpb24gMy4xLjUgRGlhbWV0ZXIgQWdlbnQgQmVoYXZp
b3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4g
VGhpcyBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtZGltZS1vdmxpLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiBUaGVyZSBhcmUgYSBudW1iZXIgb2Yg
Y29uY2VwdHMgbWVudGlvbmVkIGluIHRoaXMgc2VjdGlvbiB0aGF0IGFyZSBub3Q8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gc3VmZmljaWVudGx5IGRlZmluZWQuJm5ic3A7IFRoaXMgaW5jbHVkZXMg
U2VydmVyIEZyb250IEVuZCwgdG9wb2xvZ3kgaGlkaW5nIFNGRTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiBhbmQgYmFjay10by1iYWNrIGFnZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiBJIHN1Z2dlc3QgdGhhdCB3ZSBhZGQgdGhlIGRlZmlu
aXRpb24gb2YgU0ZFIGJhY2sgdG8gdGhlIHRlcm1pbm9sb2d5PG86cD48L286cD48L3ByZT4NCjxw
cmU+IHNlY3Rpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+IEkgYWxzbyBzdWdnZXN0IHRoYXQgd2Ugc3RhcnQgdXNpbmcgdGhlIHRlcm0gJnF1
b3Q7U2VydmVyIElkZW50aXR5IEhpZGluZyZxdW90OyBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gbm90IHVzZSB0aGUgdGVybSBUb3BvbG9neSBIaWRpbmcuJm5ic3A7IFRvcG9sb2d5IEhpZGlu
ZyBoYXMgYSBtZWFuaW5nIG91dHNpZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gb2YgRE9JQyB0
aGF0IGRvZXMgbm90IGZpdCBmb3IgRE9JQy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gSSBhbHNvIHRoaW5rIHdlIHNob3VsZCByZW1vdmUgdGhl
IGNvbmNlcHQgb2YgYmFjay10by1iYWNrIGFnZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_087A34937E64E74E848732CFF8354B9209783CFAESESSMB101erics_--


From nobody Thu Feb 20 04:21:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116011A012C for ; Thu, 20 Feb 2014 04:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7g1_pjdPRWF for ; Thu, 20 Feb 2014 04:21:47 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 746FD1A0129 for ; Thu, 20 Feb 2014 04:21:47 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1KCLf1w008880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Feb 2014 13:21:41 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1KCLfR5001868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Feb 2014 13:21:41 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 13:21:40 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" 
Thread-Topic: Issue#34 proposed conclusion
Thread-Index: Ac8uNk44t1M7hFZ/QmmpkV/c0TZ7sA==
Date: Thu, 20 Feb 2014 12:21:40 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F31@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.119]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3F31DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1682
X-purgate-ID: 151667::1392898902-00003660-840179DB/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SWOUIfywN1AzWA-Bj-XOhkAFq88
Subject: [Dime] Issue#34 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 12:21:50 -0000

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

#34: Semantics of OC-Report-Type AVP

Dear all,

Apart from potentially renaming "realm report" to something else (I don't l=
ike "realm routed report" as its not the report that is realm-routed) I bel=
ieve we finally agreed to accept the text as proposed in ticket#34 and repl=
ace the corresponding text from clause 4.6.

Ulrich




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











#34: Semantics of OC-Report-Type AVP


 


Dear all,


 


Apart from potentially renaming “realm report” to somethin=
g else (I don’t like “realm routed report” as its not the=
 report that is realm-routed) I believe we finally agreed to accept the tex=
t as proposed in ticket#34 and replace the corresponding text
from clause 4.6.


 


Ulrich


 


 


 





--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3F31DEMUMBX014nsnin_--


From nobody Thu Feb 20 04:42:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D2B1A0137 for ; Thu, 20 Feb 2014 04:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHmEPW5Vcuy8 for ; Thu, 20 Feb 2014 04:41:46 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 05BB61A013C for ; Thu, 20 Feb 2014 04:41:45 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1KCffmD010896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Feb 2014 13:41:41 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1KCfeiB007472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Feb 2014 13:41:40 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 20 Feb 2014 13:41:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 13:41:40 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" 
Thread-Topic: Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBg==
Date: Thu, 20 Feb 2014 12:41:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.119]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3F63DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1874
X-purgate-ID: 151667::1392900101-00005322-07380963/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9yDfWeT5WZZ-BLrrnMXXXaLLRCI
Subject: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 12:41:51 -0000

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

#35: additional report types are proposed

Dear all,

I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:

When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

Ulrich





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











#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional report types. However=
, we agreed to add clarifying text to clause 5.5 as follows:


 


W=
hen an agent received an OLR in response to a request initiated by a client=
 not supporting DOIC, this agent needs to bind the received OLR to the orig=
in-host of the client.


 


Ulrich


 


 


 


 





--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3F63DEMUMBX014nsnin_--


From nobody Thu Feb 20 08:16:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323A01A01E5 for ; Thu, 20 Feb 2014 08:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 ipA38CAE_49f for ; Thu, 20 Feb 2014 08:16:56 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 519071A01E3 for ; Thu, 20 Feb 2014 08:16:56 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-2d-53062a7410d9
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 16.7F.04249.47A26035; Thu, 20 Feb 2014 17:16:52 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 17:16:50 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: #50: OC-OLR AVP implicit info - proposed conclusion
Thread-Index: Ac8uVwmX8kyxnXq1RqWJDX1E3tlbrQ==
Date: Thu, 20 Feb 2014 16:16:50 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209783E82@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+JvjW6JFluwwcwzghZze1ewWUxZ8YfJ gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mq4d+Y+U8EN7ooPjx4wNTBu4O5i5OSQEDCR OLfoDBuELSZx4d56IJuLQ0jgCKPE5B9rWEESQgKLGSXuPYkGsdkE7CQunX7B1MXIwSEiUCIx tU0XxBQWsJFYdpUJpEJEwFHi0/VLLBC2nsTm0x/AxrMIqEr8OngQrJNXwFfi2m0FkDAj0Nbv p9aAtTILiEvcejKfCeIaAYkle84zQ9iiEi8f/2OFsJUkVmy/xAgyhllAU2L9Ln2IVkWJKd0P 2UFsXgFBiZMzn7BMYBSehWTqLISOWUg6ZiHpWMDIsoqRozi1OCk33chgEyMwpA9u+W2xg/Hy X5tDjNIcLErivB/fOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPT/spchPm/VresP5goo FDqbnxaoXWs7ea+o0kyPrZf575c4bc4P/X1WUH7Vhz1CfT3zfFqeB0q783+VM71w6nGwSeti j9xX3swL1qcprfg0c/v3KsHCm5IOP9OuF+Rcq1jas6t3gynTswl7MraZ3JQJPr7oLKOlaKjD H0fLLxNX8EvbcGyc6aDEUpyRaKjFXFScCAAjssMXNwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XsRj6E-oP3he6iyvD9CWxo-pzz8
Subject: [Dime] #50: OC-OLR AVP implicit info - proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 16:16:58 -0000

DQpIZWxsbyBhbGwsDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgZm9sbG93aW5nIGNv
bmNsdXNpb24gaXMgcmVhY2hlZDoNCg0KIE5vdyAoY2hhcHRlciA0LjMpOg0KDQogICAgVGhlIE9D
LU9MUiBBVlAgZG9lcyBub3QgY29udGFpbiBleHBsaWNpdCBpbmZvcm1hdGlvbiB0byB3aGljaA0K
ICAgIGFwcGxpY2F0aW9uIGl0IGFwcGxpZXMgdG8gYW5kIHdobyBpbnNlcnRlZCB0aGUgQVZQIG9y
IHdob20gdGhlDQogICAgc3BlY2lmaWMgT0MtT0xSIEFWUCBjb25jZXJucyB0by4gQm90aCB0aGVz
ZSBpbmZvcm1hdGlvbiBpcw0KICAgIGltcGxpY2l0bHkgbGVhcm5lZCBmcm9tIHRoZSBlbmNhcHN1
bGF0aW5nIERpYW1ldGVyIG1lc3NhZ2UvY29tbWFuZC4NCiAgICBUaGUgYXBwbGljYXRpb24gdGhl
IE9DLU9MUiBBVlAgYXBwbGllcyB0byBpcyB0aGUgc2FtZSBhcyB0aGUNCiAgICBBcHBsaWNhdGlv
bi1JZCBmb3VuZCBpbiB0aGUgRGlhbWV0ZXIgbWVzc2FnZSBoZWFkZXIuICBUaGUgaWRlbnRpdHkN
CiAgICB0aGUgT0MtT0xSIEFWUCBjb25jZXJucyBpcyBkZXRlcm1pbmVkIGZyb20gdGhlIE9yaWdp
bi1Ib3N0IEFWUCBmb3VuZA0KICAgIGZyb20gdGhlIGVuY2Fwc3VsYXRpbmcgRGlhbWV0ZXIgY29t
bWFuZC4NCg0KV2lsbCBiZSByZXBsYWNlZCBieToNCg0KVGhlIE9DLU9MUiBBVlAgZG9lcyBub3Qg
Y29udGFpbiBleHBsaWNpdGx5IGFsbCBpbmZvcm1hdGlvbiBuZWVkZWQgYnkgDQp0aGUgcmVhY3Rp
bmcgbm9kZSBpbiBvcmRlciB0byBkZWNpZGUgd2hldGhlciBhIHN1YnNlcXVlbnQgcmVxdWVzdCBt
dXN0IA0KdW5kZXJnbyBhIHRocm90dGxpbmcgcHJvY2VzcyB3aXRoIHRoZSByZWNlaXZlZCByZWR1
Y3Rpb24gcGVyY2VudGFnZS4NClRoZSB2YWx1ZSBvZiB0aGUgT0MtUmVwb3J0LVR5cGUgQVZQIHdp
dGhpbiB0aGUgT0MtT0xSIEFWUCBpbmRpY2F0ZXMgDQp3aGljaCBpbXBsaWNpdCBpbmZvcm1hdGlv
biBpcyByZWxldmFudCBmb3IgdGhpcyBkZWNpc2lvbiAoc2VlIGNsYXVzZSA0LjYpLg0KDQoNClRo
aXMgY29uY2x1c2lvbiBpcyBiYXNlZCBvbiBwcm9wb3NlZCBjb25jbHVzaW9uIGZvciAjSXNzdWUg
MzQNCg0KDQo=


From nobody Thu Feb 20 14:30:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E701A0326 for ; Thu, 20 Feb 2014 14:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2LQhp91DIJQ for ; Thu, 20 Feb 2014 14:30:37 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 760211A0324 for ; Thu, 20 Feb 2014 14:30:37 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMUCXp007679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:30:13 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Thu, 20 Feb 2014 16:30:12 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <04C7D3C5-1113-49A7-85EE-62D0DEF7795F@nostrum.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SKFDsPnZASqr-7ohtwA8y8Hxf-Q
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:30:40 -0000

On Feb 18, 2014, at 12:04 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) =
 wrote:

> Hi all
> =20
> 1)      I come back on this Steve=92s comment : =93Define the =
interaction between realm, realm-routed and host report types.  This is =
probably the most difficult part that is likely to require some =
discussion=94.

I don't think that's necessarily hard as long as you aren't mixing =
algorithms. I think you will get close enough for our purposes if you =
apply the "most restrictive" active report to any requests that fall =
into the overlap of more than one active report. You could get into =
cross-set calculations, but I don't think the gain in precision would be =
enough to make it worth the complexity.

OTOH, I don't know what it means to have an overlap between "loss" and =
"rate". I'd lean towards forbidding that sort of thing, but I'm not sure =
if it can really be prevented.
=20

> This joins one of  my remarks about the overlapping between different =
reports in a previous mail and drives to the use cases regarding realm =
overload:
> =20
> -          If realm overload is due to server overload, I would think =
that  our current  mechanism dealing with host report and realm (alias =
realm-routed) report will address / solve server overload  and in =
consequence indirectly  address / solve  this overload realm  case
> -          if realm overload is due to the overload of Diameter =
agents, we have discussion and a Steve=92s  proposal   about  Agent =
overload. I would also think that by addressing / solving the DA =
overload, it would also address and solve this overload realm  case.
> -          About an underlying  network congestion (eg due to network =
outage), here REQ 13 mentions that =93The solution MUST NOT interfere =
with the congestion control mechanisms of underlying transport =
protocols=94. So here I am also questioning if  we may have  duplication =
or overlapping, and what to do .

Nothing proposed so far would _interfere_ with with transport congestion =
control mechanisms.=20


> -          Have we other realm overload use cases?
> =20
> So my current thinking is  we have first  to identify the various =
realm  overload use cases and see those actually justifying to add new =
mechanisms.
> =20

I think Steve has offered reasonable justification, especially if 3GPP =
already has this requirement.

I also think this is important for cross-realm cases, where one realm =
may not want to share any more detail than "reduce traffic to my entire =
realm".


> 2)      I share Ulrich=92s questions  on how to deal with realm =
overload. Steve=92s  answer introduces a high complexity about detecting =
, evaluate the realm overload  and then which DA are acting etc. The =
fact to consider many of these points out of the scope does not suppress =
this complexity (which in addition occurs in an overloaded environment=85)=
 . So  I come back to my point 1 about the use cases to address  and the =
use of the mechanisms for server and DA overload =20

Steve's answers do the opposite--he basically says that those details =
are out of scope for the IETF. (That doesn't prevent 3GPP from coming up =
with some.) There are lots of ways one might determine the overload for =
a realm. It's completely unnecessary to standardize them.

> =20
> Best regards
> =20
> JJacques
> =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : mardi 18 f=E9vrier 2014 15:55
> =C0 : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> Ulrich,
>=20
> All good questions.
>=20
> I mapped out the use case in a previous email with discussing the =
realm-routed overload report type. =20
>=20
> Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm =
hoping someone involved in the discussions that lead to that requirement =
can speak up on the use case driving the need for realm reports.
>=20
> The means of detection is out of scope for the DOIC draft, just as it =
is for host and realm-routed report types.  We should, however, include =
wording to explain how it might be done. =20
>=20
> A few bullet points outlining a proposed solution.  I can put together =
a couple of slides explaining this if it would be helpful.
>=20
> - The method of detection can be based on the collected status of =
Diameter nodes in the realm.  It can also be based on the status of the =
underlying network.  For instance, if there is a network outage that =
reduces the effective throughput of the signaling network, the best =
method for handling this might be to signal a realm overload report.
>=20
> - The network element detecting the realm status is out of scope for =
the DOIC document.
>=20
> - The Diameter node that reports realm overload can be any Diameter =
node and is up to the service provider to define.  Assuming we are using =
Diameter answer messages to transport the realm reports, it would need =
to be either all agents or all servers.  This is to guarantee that all =
reacting nodes get the report.
>=20
> - The method that the reporting node is told that the realm is =
overloaded, triggering the realm overload report, is out of scope for =
this document.
>=20
> - Reacting nodes should listen to only one realm overload reporting =
node.  It is up to the implementation of the realm overload detection =
element to make sure that all reporting nodes have the same state.
>=20
> One way to model this is for an external element being responsible for =
detecting realm overload and signaling the realm overload reporting =
nodes of the status using an out of bands mechanism.  All realm overload =
reporting nodes would be responsible for sending realm overload reports. =
 Reacting nodes would only listen to one of the reporting nodes.
>=20
> There are also security considerations similar to host reports, except =
that an attack using realm overload reports has a much bigger impact =
than an attack using host reports.
>=20
> Steve
>=20
> On 2/18/14 7:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> first of all I would like to better understand the usecase especially =
on the reporting side.
> Which node would act as a reporting node generating new realm-type =
reports?
> How would this node detect that the complete realm is in overload (and =
what does that mean? All servers in the realm, also clients? Agents? )?
> Would this node be (logically) a single node? If not, how to =
synchronize different new-realm-type reporting nodes so that they don=92t =
report different things to the same reacting node?
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Tuesday, February 18, 2014 1:48 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> It shouldn't be much work to add realm overload to the draft.  We =
would need to do the following (at a minimum):
>=20
> - Change that name of the current realm report to something like =
"realm-routed".
> - Create a new report type of name realm that applies to all traffic =
routed to the realm.
> - Add a few words in the reporting node section about generation of =
realm reports.
> - Define the interaction between realm, realm-routed and host report =
types.  This is probably the most difficult part that is likely to =
require some discussion.
>=20
> Other then the section on interactions between report types, I don't =
think this impacts the existing text so it should fold in pretty =
cleanly.
>=20
> I'd be happy to take the first shot at this to be included in the -02 =
version of the draft if there is consensus to add it.
>=20
> Steve
>=20
> On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:
> Hello all,
> =20
> Overload of the realm is one of the use cases that is required by 3GPP =
applications.
> And I think this should be part of the basic mechanism, or?
> =20
> Best regards
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, =
JEAN-JACQUES (JEAN-JACQUES)
> Sent: lunes, 17 de febrero de 2014 18:53
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> Hi
> =20
> I share the view to analyze the overload of the realm as a whole in a =
separate extension  and see if this lead to another report type.
> =20
> Best regards
> =20
> JJacques
>  =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : lundi 17 f=E9vrier 2014 17:13
> =C0 : Ben Campbell
> Cc : dime@ietf.org list
> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> I do think it would be a new report type, as it would require =
different behavior from reacting nodes.
>=20
> I'm ok with this being in a separate extension if the group thinks =
this is the correct approach.  We are creating a good number of =
relatively small extensions.  It might lead to the need to pull them all =
together in a future version of the DOIC draft/RFC.
>=20
> Steve
>=20
> On 2/14/14 4:21 PM, Ben Campbell wrote:
> (Apologies for coming late to this thread)
> =20
> On Feb 13, 2014, at 6:35 AM, Steve Donovan  =
wrote:
> =20
> Ok, Ok, no reason to gang up on me. :-)
> What we have here is an overload report to reduce realm routed =
requests.  I think we should be explicit in the draft to define it as =
such.
> =20
> =20
> At the risk of joining the anti-Steve gang, I feel the need to =
belatedly mention that my personal intent way back when we talked about =
the mixed-state problem was that realm reports applied to realm-routed =
requests.=20
> =20
> I am still concerned that we do not have a way to indicate overload of =
the realm as a whole.  I'll enter a new trouble ticket to capture this =
issue.
> =20
> =20
> I do not object to adding that ability. Would it be a new OLR type? If =
so, would it need to go in the base draft or could it be an extension?
> =20
> Steve
> =20
> =20
> =20
>=20
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Feb 20 14:31:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7CA1A0328 for ; Thu, 20 Feb 2014 14:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqX9015voj9w for ; Thu, 20 Feb 2014 14:31:29 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A7D141A032E for ; Thu, 20 Feb 2014 14:31:26 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMVK4V007833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:31:22 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net>
Date: Thu, 20 Feb 2014 16:31:21 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lEdRN8vU1XzptU1mVXriNSXsS2o
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue#29 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:31:30 -0000

I concur with removing the sequence number from OC-Supported-Features.

On Feb 19, 2014, at 2:44 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> #29: OC-Sequence-Number in OC-Supported-Features
> =20
> Dear all,
> =20
> I have received comments from Lionel, Jouni and Steve;
> I understand that Lionel and myself support removal of =
OC-Sequence-Number AVP from OC-Supported-Features AVP while Jouni has no =
strong view.  I=92m not sure whether Steve is convinced by the response =
given to his comments.
> =20
> In summary I dare to propose that we conclude in favour of removing =
OC-Sequence-Number from OC-Supported-Features.
> =20
> Ulrich
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Feb 20 14:33:19 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C2E1A032E for ; Thu, 20 Feb 2014 14:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEoXJ6siSbnZ for ; Thu, 20 Feb 2014 14:33:17 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1321B1A0328 for ; Thu, 20 Feb 2014 14:33:17 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMXBQs008074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:33:13 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <53051027.1050608@usdonovans.com>
Date: Thu, 20 Feb 2014 16:33:12 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net> <53051027.1050608@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IUzvr3kWu_B0P1AVb-3DEPB_nlg
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#31 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:33:18 -0000

+1

On Feb 19, 2014, at 2:12 PM, Steve Donovan  =
wrote:

> Agreed
>=20
> On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that =
survived a throttling
>> =20
>> Dear all,
>> =20
>> I did not receive much support for the proposal to define an =
OC-Ongoing-Throttling-Info AVP in request messages that survived a =
throttlting.
>> =20
>> However, we seem to agree on some principles:
>> =20
>> Missing OLR in answer means =93no change=94; it does not mean =93no =
overload/no throttling requested=94
>> =20
>> Reporting nodes SHOULD include OLR in every answer that it sends in =
response to a request message which indicatedOLR_DEFAULT_ALGO support =
unless the reporting node has very good reasons not to do so. Exact =
wording is not yet agreed.
>> =20
>> Ulrich
>> =20
>> =20
>> =20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Feb 20 14:33:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B871A0326 for ; Thu, 20 Feb 2014 14:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNfNFX2a-On8 for ; Thu, 20 Feb 2014 14:33:45 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 324791A02C1 for ; Thu, 20 Feb 2014 14:33:45 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMXBQt008074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:33:40 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <53051277.3090301@usdonovans.com>
Date: Thu, 20 Feb 2014 16:33:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org> <53051277.3090301@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/UMdTULxKCuoNyKn9KiYKuy6TPYQ
Cc: "dime@ietf.org list" , draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #24: Terminology and Abbreviations
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:33:47 -0000

+1

On Feb 19, 2014, at 2:22 PM, Steve Donovan  =
wrote:

> There has been no discussion of this ticket.
>=20
> I propose that the definition of Diameter layer load balancing be =
removed.
>=20
> I propose removing the definition of Topology Hiding, as it has =
meanings outside of the context of Diameter overload.
>=20
> I also propose that we remove any discussion of agents acting as =
server front ends or topology hiders.  I propose instead to have a =
discussion in section 5.5 outlining the requirements for an agent to =
take on the role of a reporting node for host reports.
>=20
> Regards,
>=20
> Steve
>=20
> On 1/28/14 2:13 PM, dime issue tracker wrote:
>> #24: Terminology and Abbreviations
>>=20
>>  This applies to draft-ietf-dime-ovli.
>>=20
>>  Section 2. contains a definition of Diameter layer Load Balancing =
that
>>  does not appear to be needed.  This was originally included as one =
of the
>>  features of a Server Front End.  Given that SFE has been removed =
this can
>>  be removed as well.
>>=20
>>  The definition of Topology Hiding is the generic Diameter topology =
hiding
>>  definition.  This is different than the server identity hiding that =
an
>>  agent might optionally do.  We should probably remove this =
definition and
>>  insert a definition of server identity hiding for an agent that is
>>  aggregating overload state across a server farm.
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Feb 20 14:34:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B721A032E for ; Thu, 20 Feb 2014 14:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODb_yL3YOBpZ for ; Thu, 20 Feb 2014 14:34:13 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3A41A02C1 for ; Thu, 20 Feb 2014 14:34:13 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMXBQu008074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:34:09 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530519F7.1010207@usdonovans.com>
Date: Thu, 20 Feb 2014 16:34:09 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> <530519F7.1010207@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/w0kPL9dVDj-C4as-lAwLg1zJ9mw
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #23: DOIC behavior for realm overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:34:20 -0000

+1

On Feb 19, 2014, at 2:54 PM, Steve Donovan  =
wrote:

> We've had a lot of discussion of this topic.
>=20
> I believe that we reached agreement that we currently have two types =
of reports:
>=20
> - Host report that applies to requests sent to a destination-host
> - Realm report that applies requests routed to a realm that do not =
have a specified destination-host (realm-routed requests)
>=20
> We also have proposed wording on the interaction between these report =
types. =20
>=20
> I propose that the second be renamed to realm-routed reports.
>=20
> A separate ticket has been opened on the need for a third report type =
that would apply to all request routed to a realm, independent of =
whether a request contains a destination-host AVP.
>=20
> Steve
>=20
> On 1/21/14 9:24 AM, dime issue tracker wrote:
>> #23: DOIC behavior for realm overload
>>=20
>>  This applies to draft-ietf-dime-ovli-01, which does not show up in =
the
>>  Component drop down menu.
>>=20
>>  The current assumption in the -01 draft is inconsistent in the =
definition
>>  of behavior of behavior by a reacting node when it receives a realm
>>  overload report.
>>=20
>>  Section 4.6 says overload treatment should apply to all request =
bound for
>>  the overloaded realm.
>>=20
>>  Section 5.5.2 is not clear and there have been interpretations that =
a
>>  realm overload report only applies to requests that contain the =
realm and
>>  do not contain a destination-host AVP.
>>=20
>>  Section 5.5.2 should be updated to be consistent with section 4.6.
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Feb 20 14:43:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E75B1A0319 for ; Thu, 20 Feb 2014 14:43:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbcSzK64sHN4 for ; Thu, 20 Feb 2014 14:43:21 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 653C61A0304 for ; Thu, 20 Feb 2014 14:43:21 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMhF1e008666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:43:16 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <53050FE6.2090800@usdonovans.com>
Date: Thu, 20 Feb 2014 16:43:16 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E45B36C-AB19-4869-A73B-4BA98B4ED0A4@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <53050FE6.2090800@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5z8pUEAcuINARErAfUcPC3dTOXQ
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:43:22 -0000

On Feb 19, 2014, at 2:11 PM, Steve Donovan  =
wrote:

>>> Sequence-Number is of type Time, however the value need not =
correspond to the point in time of generation.
>> SRD> I don't agree that the type should be time.  It should be of =
type Unsigned64.  A time stamp can be inserted into it but we should not =
prevent simple sequence numbers.  I agree with the remainder of the =
statement.
>=20


+1. Making it type Time implies that the recipient can do something time =
related with the value. That is not the case here.


From nobody Thu Feb 20 14:45:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5372C1A0327 for ; Thu, 20 Feb 2014 14:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc_Rnpi7Ddd2 for ; Thu, 20 Feb 2014 14:45:48 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 341261A02F2 for ; Thu, 20 Feb 2014 14:45:48 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMjeQ3008850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:45:41 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B9209783CFA@ESESSMB101.ericsson.se>
Date: Thu, 20 Feb 2014 16:45:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <875BBB99-E4BB-4764-941B-9F83D54683B6@nostrum.com>
References: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org> <53051431.9000800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209783CFA@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XQWOA4dh41vbsZNQcH-tcEuHxaI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #25: Section 3.1.5 Diameter Agent Behavior
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:45:50 -0000

I am working on some a proposal for some new "overview of operation" =
language that might help here. Unfortunately, I don't know if I will =
have it in time for the meeting, but I will try.

On Feb 20, 2014, at 4:51 AM, Maria Cruz Bartolome =
 wrote:

> Hello Steve, all,
> =20
> The intention of chapters 3.1.5 and 5.5 is totally different.
> In order to be able to agree or disagree I would need to have a =
written proposal of the changes and an explanation of the reason for =
these changes.
> =20
> Best regards
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: mi=E9rcoles, 19 de febrero de 2014 21:30
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #25: Section 3.1.5 Diameter Agent Behavior
> =20
> There has been no discussion of this ticket.
>=20
> After further thought, I propose that this section be removed and the =
requirements for agents acting as reporting nodes for host reports be =
included in section 5.5.
>=20
> If the section is kept then I propose removing the term "topology =
hiding" and use server front end instead.  If we take this approach then =
we need to have a definition of SFE in the terminology section.
>=20
> Steve
>=20
>=20
> On 1/28/14 2:18 PM, dime issue tracker wrote:
> #25: Section 3.1.5 Diameter Agent Behavior
> =20
>  This applies to draft-ietf-dime-ovli.
> =20
>  There are a number of concepts mentioned in this section that are not
>  sufficiently defined.  This includes Server Front End, topology =
hiding SFE
>  and back-to-back agent.
> =20
>  I suggest that we add the definition of SFE back to the terminology
>  section.
> =20
>  I also suggest that we start using the term "Server Identity Hiding" =
and
>  not use the term Topology Hiding.  Topology Hiding has a meaning =
outside
>  of DOIC that does not fit for DOIC.
> =20
>  I also think we should remove the concept of back-to-back agent.
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Feb 20 14:55:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A31A030D for ; Thu, 20 Feb 2014 14:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6YCVzPgXo1S for ; Thu, 20 Feb 2014 14:54:55 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E5EC71A0328 for ; Thu, 20 Feb 2014 14:54:53 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMsmEi009151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:54:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net>
Date: Thu, 20 Feb 2014 16:54:49 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h9uCVOdnIEIhN_8t0XkSiyjV-Eo
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 22:54:57 -0000

On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> #35: additional report types are proposed
> =20
> Dear all,
> =20
> I believe we can conclude, not to add additional report types. =
However, we agreed to add clarifying text to clause 5.5 as follows:
> =20
> When an agent received an OLR in response to a request initiated by a =
client not supporting DOIC, this agent needs to bind the received OLR to =
the origin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client. =
If there's an intervening DOIC agent, then the agent, not the client, is =
the reacting node from the server's perspective. But, short of adding an =
origin-host type, nothing binds the OLR to a particular client, =
regardless of DOIC support at the clients.

 Whether or not the client also supports DOIC doesn't change that. For =
DOIC-supporting clients, the agent has the additional option of reducing =
traffic by asking the clients to reduce traffic (making them reacting =
nodes from the perspective of the _agent_, but not the server.)  It =
doesn't have that option for non-DOIC clients.=


From nobody Thu Feb 20 15:16:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BFF1A033D for ; Thu, 20 Feb 2014 15:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4kjRVScBSef for ; Thu, 20 Feb 2014 15:16:33 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B8BE71A0304 for ; Thu, 20 Feb 2014 15:16:33 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KNGRHa010149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 17:16:29 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5303742C.50902@usdonovans.com>
Date: Thu, 20 Feb 2014 17:16:29 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KYNBDklR2mRvwGMjavQURM3WPLY
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Feb 2014 23:16:35 -0000

On Feb 18, 2014, at 8:54 AM, Steve Donovan  =
wrote:

> Ulrich,
>=20
> All good questions.
>=20
> I mapped out the use case in a previous email with discussing the =
realm-routed overload report type. =20
>=20
> Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm =
hoping someone involved in the discussions that lead to that requirement =
can speak up on the use case driving the need for realm reports.
>=20
> The means of detection is out of scope for the DOIC draft, just as it =
is for host and realm-routed report types.  We should, however, include =
wording to explain how it might be done. =20
>=20
> A few bullet points outlining a proposed solution.  I can put together =
a couple of slides explaining this if it would be helpful.
>=20
> - The method of detection can be based on the collected status of =
Diameter nodes in the realm.  It can also be based on the status of the =
underlying network.  For instance, if there is a network outage that =
reduces the effective throughput of the signaling network, the best =
method for handling this might be to signal a realm overload report.
>=20
> - The network element detecting the realm status is out of scope for =
the DOIC document.
>=20
> - The Diameter node that reports realm overload can be any Diameter =
node and is up to the service provider to define.  Assuming we are using =
Diameter answer messages to transport the realm reports, it would need =
to be either all agents or all servers.  This is to guarantee that all =
reacting nodes get the report.

I think "any Diameter node" is too broad. It has to be node that is, at =
least sometimes, in the path for requests for that particular =
realm+application.  (Although I note that explicit realm and application =
AVPs in an OLR would fix that ;-)  )

>=20
> - The method that the reporting node is told that the realm is =
overloaded, triggering the realm overload report, is out of scope for =
this document.
>=20

Agreed, although one possible way to do it would be for the reporting =
node to be an agent that infers general realm overload based on upstream =
overload information.

> - Reacting nodes should listen to only one realm overload reporting =
node.  It is up to the implementation of the realm overload detection =
element to make sure that all reporting nodes have the same state.

I think this should be restated that realm reports should only be _sent_ =
by reporting nodes that have full knowledge of and authority for the =
realm's overload state. But there's no requirement that there be only =
one, just that if there are more than one they don't contradict each =
other.

>=20
> One way to model this is for an external element being responsible for =
detecting realm overload and signaling the realm overload reporting =
nodes of the status using an out of bands mechanism.  All realm overload =
reporting nodes would be responsible for sending realm overload reports. =
 Reacting nodes would only listen to one of the reporting nodes.
>=20
> There are also security considerations similar to host reports, except =
that an attack using realm overload reports has a much bigger impact =
than an attack using host reports.

Yep. IIRC, We already have language in the security considerations that =
reacting nodes need to properly authorize sources of OLRs. That applies =
here as well.

(Maybe it's time to propose an "all-realms" report type :-) )



From nobody Thu Feb 20 22:27:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D0F1A043C for ; Thu, 20 Feb 2014 22:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLcCqO6ZHqXC for ; Thu, 20 Feb 2014 22:27:34 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDFD1A043B for ; Thu, 20 Feb 2014 22:27:34 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1L6RSeC020335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2014 07:27:28 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1L6RScb022609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 07:27:28 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 07:27:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 07:27:27 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: #50: OC-OLR AVP implicit info - proposed conclusion
Thread-Index: Ac8uVwmX8kyxnXq1RqWJDX1E3tlbrQAduffA
Date: Fri, 21 Feb 2014 06:27:26 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B407C@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B9209783E82@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209783E82@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1526
X-purgate-ID: 151667::1392964048-00005322-D3AAA245/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/R2zLqyFx76YrHS7jz9_sd57jauE
Subject: Re: [Dime] #50: OC-OLR AVP implicit info - proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 06:27:37 -0000

I agree
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, February 20, 2014 5:17 PM
To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: [Dime] #50: OC-OLR AVP implicit info - proposed conclusion


Hello all,

My understanding is that the following conclusion is reached:

 Now (chapter 4.3):

    The OC-OLR AVP does not contain explicit information to which
    application it applies to and who inserted the AVP or whom the
    specific OC-OLR AVP concerns to. Both these information is
    implicitly learned from the encapsulating Diameter message/command.
    The application the OC-OLR AVP applies to is the same as the
    Application-Id found in the Diameter message header.  The identity
    the OC-OLR AVP concerns is determined from the Origin-Host AVP found
    from the encapsulating Diameter command.

Will be replaced by:

The OC-OLR AVP does not contain explicitly all information needed by=20
the reacting node in order to decide whether a subsequent request must=20
undergo a throttling process with the received reduction percentage.
The value of the OC-Report-Type AVP within the OC-OLR AVP indicates=20
which implicit information is relevant for this decision (see clause 4.6).


This conclusion is based on proposed conclusion for #Issue 34


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


From nobody Thu Feb 20 22:49:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12AB1A0446 for ; Thu, 20 Feb 2014 22:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1c_I4pPdHio for ; Thu, 20 Feb 2014 22:48:57 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 05FF81A027C for ; Thu, 20 Feb 2014 22:48:56 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1L6mqW0030413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2014 07:48:52 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1L6mqNS029023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 07:48:52 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 07:48:51 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 07:48:51 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPLKfaNBG2qkbh0kelPIaMQYlrnZq6+hlQgAAOggCAA7DjgIAAjlUw
Date: Fri, 21 Feb 2014 06:48:51 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B40AB@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com>
In-Reply-To: <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3906
X-purgate-ID: 151667::1392965332-00005322-F91A6043/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AJ1MEDz5gSyrAYJ9MpcHNLm-x48
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 06:48:59 -0000

Ben, Steve, all

Let's conclude on #34.
The particular question under discussion here actually belongs to #55

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Friday, February 21, 2014 12:16 AM
To: Steve Donovan
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 18, 2014, at 8:54 AM, Steve Donovan  wrote=
:

> Ulrich,
>=20
> All good questions.
>=20
> I mapped out the use case in a previous email with discussing the realm-r=
outed overload report type. =20
>=20
> Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm hopin=
g someone involved in the discussions that lead to that requirement can spe=
ak up on the use case driving the need for realm reports.
>=20
> The means of detection is out of scope for the DOIC draft, just as it is =
for host and realm-routed report types.  We should, however, include wordin=
g to explain how it might be done. =20
>=20
> A few bullet points outlining a proposed solution.  I can put together a =
couple of slides explaining this if it would be helpful.
>=20
> - The method of detection can be based on the collected status of Diamete=
r nodes in the realm.  It can also be based on the status of the underlying=
 network.  For instance, if there is a network outage that reduces the effe=
ctive throughput of the signaling network, the best method for handling thi=
s might be to signal a realm overload report.
>=20
> - The network element detecting the realm status is out of scope for the =
DOIC document.
>=20
> - The Diameter node that reports realm overload can be any Diameter node =
and is up to the service provider to define.  Assuming we are using Diamete=
r answer messages to transport the realm reports, it would need to be eithe=
r all agents or all servers.  This is to guarantee that all reacting nodes =
get the report.

I think "any Diameter node" is too broad. It has to be node that is, at lea=
st sometimes, in the path for requests for that particular realm+applicatio=
n.  (Although I note that explicit realm and application AVPs in an OLR wou=
ld fix that ;-)  )

>=20
> - The method that the reporting node is told that the realm is overloaded=
, triggering the realm overload report, is out of scope for this document.
>=20

Agreed, although one possible way to do it would be for the reporting node =
to be an agent that infers general realm overload based on upstream overloa=
d information.

> - Reacting nodes should listen to only one realm overload reporting node.=
  It is up to the implementation of the realm overload detection element to=
 make sure that all reporting nodes have the same state.

I think this should be restated that realm reports should only be _sent_ by=
 reporting nodes that have full knowledge of and authority for the realm's =
overload state. But there's no requirement that there be only one, just tha=
t if there are more than one they don't contradict each other.

>=20
> One way to model this is for an external element being responsible for de=
tecting realm overload and signaling the realm overload reporting nodes of =
the status using an out of bands mechanism.  All realm overload reporting n=
odes would be responsible for sending realm overload reports.  Reacting nod=
es would only listen to one of the reporting nodes.
>=20
> There are also security considerations similar to host reports, except th=
at an attack using realm overload reports has a much bigger impact than an =
attack using host reports.

Yep. IIRC, We already have language in the security considerations that rea=
cting nodes need to properly authorize sources of OLRs. That applies here a=
s well.

(Maybe it's time to propose an "all-realms" report type :-) )



From nobody Thu Feb 20 23:07:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E281A044F for ; Thu, 20 Feb 2014 23:07:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNcLfD3D6_DQ for ; Thu, 20 Feb 2014 23:07:29 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEB21A044D for ; Thu, 20 Feb 2014 23:07:28 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1L77MtX027589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2014 08:07:22 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1L77Mbk007920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 08:07:22 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 08:07:22 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 08:07:21 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #23: DOIC behavior for realm overload
Thread-Index: AQHPLbTFPh1oaJJHT0SOiCu4+4jwgpq/SZaw
Date: Fri, 21 Feb 2014 07:07:21 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B40C7@DEMUMBX014.nsn-intra.net>
References: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> <530519F7.1010207@usdonovans.com>
In-Reply-To: <530519F7.1010207@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2698
X-purgate-ID: 151667::1392966443-00003660-83D5EDFC/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/azWOgnqNnmkRq5E_JQf4eQI0s60
Subject: Re: [Dime] [dime] #23: DOIC behavior for realm overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 07:07:31 -0000

U3RldmUsDQoNCnNlZSBpbmxpbmUuDQpVbHJpY2gNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuDQpTZW50OiBX
ZWRuZXNkYXksIEZlYnJ1YXJ5IDE5LCAyMDE0IDk6NTQgUE0NClRvOiBkaW1lQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW0RpbWVdIFtkaW1lXSAjMjM6IERPSUMgYmVoYXZpb3IgZm9yIHJlYWxtIG92
ZXJsb2FkDQoNCldlJ3ZlIGhhZCBhIGxvdCBvZiBkaXNjdXNzaW9uIG9mIHRoaXMgdG9waWMuDQoN
CkkgYmVsaWV2ZSB0aGF0IHdlIHJlYWNoZWQgYWdyZWVtZW50IHRoYXQgd2UgY3VycmVudGx5IGhh
dmUgdHdvIHR5cGVzIG9mIHJlcG9ydHM6DQoNCi0gSG9zdCByZXBvcnQgdGhhdCBhcHBsaWVzIHRv
IHJlcXVlc3RzIHNlbnQgdG8gYSBkZXN0aW5hdGlvbi1ob3N0DQotIFJlYWxtIHJlcG9ydCB0aGF0
IGFwcGxpZXMgcmVxdWVzdHMgcm91dGVkIHRvIGEgcmVhbG0gdGhhdCBkbyBub3QgaGF2ZSBhIHNw
ZWNpZmllZCBkZXN0aW5hdGlvbi1ob3N0IChyZWFsbS1yb3V0ZWQgcmVxdWVzdHMpDQoNCjxVbHJp
Y2g+IEkgYWdyZWU8L1VscmljaD4NCg0KV2UgYWxzbyBoYXZlIHByb3Bvc2VkIHdvcmRpbmcgb24g
dGhlIGludGVyYWN0aW9uIGJldHdlZW4gdGhlc2UgcmVwb3J0IHR5cGVzLsKgIA0KDQo8VWxyaWNo
PiBjYW4geW91IHBsZWFzZSByZW1pbmQgbWUgd2hhdCB0aGF0IHByb3Bvc2VkIHdvcmRpbmcgaXMu
IE15IGN1cnJlbnQgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZXJlIGlzIG5vIGludGVyYWN0aW9u
IGJldHdlZW4gdGhlc2UgdHdvIHJlcG9ydCB0eXBlczwvVWxyaWNoPg0KDQpJIHByb3Bvc2UgdGhh
dCB0aGUgc2Vjb25kIGJlIHJlbmFtZWQgdG8gcmVhbG0tcm91dGVkIHJlcG9ydHMuDQoNCjxVbHJp
Y2g+IG5vIHN0cm9uZyB2aWV3LCBidXQgbXkgcHJlZmVyZW5jZSBpcyBpbiBmYXZvdXIgb2YgImFi
c2VudC1ob3N0IHJlcG9ydHMiPC9VbHJpY2g+DQoNCkEgc2VwYXJhdGUgdGlja2V0IGhhcyBiZWVu
IG9wZW5lZCBvbiB0aGUgbmVlZCBmb3IgYSB0aGlyZCByZXBvcnQgdHlwZSB0aGF0IHdvdWxkIGFw
cGx5IHRvIGFsbCByZXF1ZXN0IHJvdXRlZCB0byBhIHJlYWxtLCBpbmRlcGVuZGVudCBvZiB3aGV0
aGVyIGEgcmVxdWVzdCBjb250YWlucyBhIGRlc3RpbmF0aW9uLWhvc3QgQVZQLg0KPFVscmljaD4g
SSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyAjNTU8L1VscmljaD4NCg0KU3RldmUNCk9uIDEvMjEv
MTQgOToyNCBBTSwgZGltZSBpc3N1ZSB0cmFja2VyIHdyb3RlOg0KIzIzOiBET0lDIGJlaGF2aW9y
IGZvciByZWFsbSBvdmVybG9hZA0KDQogVGhpcyBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtZGltZS1v
dmxpLTAxLCB3aGljaCBkb2VzIG5vdCBzaG93IHVwIGluIHRoZQ0KIENvbXBvbmVudCBkcm9wIGRv
d24gbWVudS4NCg0KIFRoZSBjdXJyZW50IGFzc3VtcHRpb24gaW4gdGhlIC0wMSBkcmFmdCBpcyBp
bmNvbnNpc3RlbnQgaW4gdGhlIGRlZmluaXRpb24NCiBvZiBiZWhhdmlvciBvZiBiZWhhdmlvciBi
eSBhIHJlYWN0aW5nIG5vZGUgd2hlbiBpdCByZWNlaXZlcyBhIHJlYWxtDQogb3ZlcmxvYWQgcmVw
b3J0Lg0KDQogU2VjdGlvbiA0LjYgc2F5cyBvdmVybG9hZCB0cmVhdG1lbnQgc2hvdWxkIGFwcGx5
IHRvIGFsbCByZXF1ZXN0IGJvdW5kIGZvcg0KIHRoZSBvdmVybG9hZGVkIHJlYWxtLg0KDQogU2Vj
dGlvbiA1LjUuMiBpcyBub3QgY2xlYXIgYW5kIHRoZXJlIGhhdmUgYmVlbiBpbnRlcnByZXRhdGlv
bnMgdGhhdCBhDQogcmVhbG0gb3ZlcmxvYWQgcmVwb3J0IG9ubHkgYXBwbGllcyB0byByZXF1ZXN0
cyB0aGF0IGNvbnRhaW4gdGhlIHJlYWxtIGFuZA0KIGRvIG5vdCBjb250YWluIGEgZGVzdGluYXRp
b24taG9zdCBBVlAuDQoNCiBTZWN0aW9uIDUuNS4yIHNob3VsZCBiZSB1cGRhdGVkIHRvIGJlIGNv
bnNpc3RlbnQgd2l0aCBzZWN0aW9uIDQuNi4NCg0KDQo=


From nobody Fri Feb 21 00:34:43 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14781A04DF for ; Fri, 21 Feb 2014 00:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC6zTMRHZcOn for ; Fri, 21 Feb 2014 00:34:40 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3F47B1A04C3 for ; Fri, 21 Feb 2014 00:34:39 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-b3-53070f9b8e51
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 3F.FF.04853.B9F07035; Fri, 21 Feb 2014 09:34:35 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 09:34:35 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #51: OC-Supported-Features in requests - conclusions
Thread-Index: Ac8u33cKdOS3EczGTrmu8FoNG7zaWg==
Date: Fri, 21 Feb 2014 08:34:34 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvje5sfvZggzdN+hZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY07PdfaCzUwV/+dNYG5g/M7YxcjJISFgItH5cwsLhC0mceHe erYuRi4OIYETjBITpyxghXAWM0p03j7BBFLFJmAncen0CyCbg0NEQFni9C8HkLCwgIvEpaVz wQaJCHhKdDVtgrL1JFb/OcIGYrMIqEq0Xt7ODtLKK+ArsWh6MkiYEWjv91NrwKYzC4hL3Hoy nwniHgGJJXvOM0PYohIvH/9jhbCVJFZsv8QIUa8jsWD3JzYIW1ti2cLXYPW8AoISJ2c+YZnA KDwLydhZSFpmIWmZhaRlASPLKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2MwEA/uOW3 0Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA47YZNYt0xkRnz Lhcnr9/HeSEl/rrfZt9V11Y5zjq4L+wu81mb+rRCqbofhSsr7YpOHJ9yqcBcLVpJJdq69eiO Sfekj/5cNnVFa6lPti3X7LbFW1qDtct2XOz6up+xXP/vk6ydue6+98Wu69hHtW10MebL+hQ4 /1Rj0/qQO6ptHIILVPKnrC9TYinOSDTUYi4qTgQASnwnUEICAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qwB19TDKEkBUzi9890j0zoV7Lk0
Subject: [Dime]  #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 08:34:42 -0000

#51: OC-Supported-Features in requests
=20
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter
 message a DOIC
 supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
replace SHOULD by MUST


From nobody Fri Feb 21 00:40:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8661A0011 for ; Fri, 21 Feb 2014 00:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUT86f1rotvA for ; Fri, 21 Feb 2014 00:40:29 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0C45F1A000A for ; Fri, 21 Feb 2014 00:40:28 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-42-530710f850ec
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A5.88.10875.8F017035; Fri, 21 Feb 2014 09:40:24 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 09:40:24 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6w==
Date: Fri, 21 Feb 2014 08:40:23 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvje4PAfZggwW9OhZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+nFTUwFx/gr1sy+wdbA+J67i5GTQ0LARGJNdxc7hC0mceHe erYuRi4OIYFDjBIdHecYIZzFjBJTrrSygFSxCdhJXDr9gqmLkYNDREBZ4vQvB5CwsECkxILf v9hAbBGBOImm0y2sELaexN/HtxlBbBYBVYmWlfsZQVp5BXwlLt7NAgkzAu39fmoNE4jNLCAu cevJfCaIewQkluw5zwxhi0q8fPyPFcJWklix/RIjRL2OxILdn9ggbG2JZQtfg9XzCghKnJz5 hGUCo/AsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAoP44JbfujsYT50TOcQozcGiJM77 4a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGaGbV+YIuJmVcFxocFt8Mf96t+b+2m+fa ecO9Tc4O+pOfVkTvD8y7+lRj5o4fM7o4X5UuMlvSGhM508VDWqud315soq/i6osLp+nzmipK TtUNOazzZJHxh60LO4wXXWf0jWd1dImxOfGBNeiLd8ozUZ0ux0yJCyeFpA8XmFubvH3Xttlb 9rESS3FGoqEWc1FxIgC7X0aGMAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_W2blwtd_UJvz6frlo8qsSRZpLQ
Subject: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 08:40:31 -0000

#52: Throttling not needed to be based on previous history
=20
Following agreement is reached:

 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.
=20
 Proposal:
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 =20
   and describes the percentage of the traffic that the sender is =20
   requested to reduce, compared to what it otherwise would send.          =
        <----
=20
=20
 Now (chapter 5.5.2):
      Indicates that the reporting node urges the reacting node to
      reduce its traffic by a given percentage.  For example if the
      reacting node has been sending 100 packets per second to the
      reporting node, then a reception of OC-Reduction-Percentage value
      of 10 would mean that from now on the reacting node MUST only send
      90 packets per second.  How the reacting node achieves the "true
      reduction" transactions leading to the sent request messages is up
      to the implementation.  The reacting node MAY simply drop every
      10th packet from its output queue and let the generic application
      logic try to recover from it.0 < value < 100

  Proposal:
 Indicates that the reporting node urges the reacting node to reduce=20
 its traffic by a given percentage. For example if the
 reacting node would send 100 packets to the				<---
 reporting node, then a reception of OC-Reduction-Percentage value of=20
 10 would mean that from now on the reacting node MUST only send
 90 packets instead of 100. How the reacting node achieves the "true       =
<---
 reduction" transactions leading to the sent request messages is up to=20
 the implementation. The reacting node MAY simply drop every 10th=20
 packet from its output queue and let the generic application logic try=20
 to recover from it.


From nobody Fri Feb 21 00:51:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC501A04BD for ; Fri, 21 Feb 2014 00:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANy5ccPJquf5 for ; Fri, 21 Feb 2014 00:51:36 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 614C31A0070 for ; Fri, 21 Feb 2014 00:51:36 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-00-530713936d26
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 9A.62.04853.39317035; Fri, 21 Feb 2014 09:51:31 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 09:51:31 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [dime] #53: 5.5.2 chapter typo? - conclusion
Thread-Index: Ac8u4hyhyFipAfuqQZK1Yn82LVgN9A==
Date: Fri, 21 Feb 2014 08:51:30 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784033@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvje5kYfZgg3nHTC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxspPu1kLHrBWbFlykLWB8QxrFyMnh4SAicSP95OZIWwxiQv3 1rN1MXJxCAmcYJSYfeI2O4SzmFHicdM3dpAqNgE7iUunXzB1MXJwiAgoS5z+5QASFhYwlfh/ aicTiC0iYCVx9u9hdghbT+L/g22MIOUsAqoS535LgYR5BXwl1q57wwZiMwLt/X5qDVgrs4C4 xK0n85kg7hGQWLLnPNRtohIvH/+DullJYsX2S2AjmQU0Jdbv0odoVZSY0v2QHWK8oMTJmU9Y JjAKz0IydRZCxywkHbOQdCxgZFnFKFmcWlycm25koJebnluil1qUmVxcnJ+nV5y6iREY5Ae3 /DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGDel2h/bdWR1 eOX00oQOsX0zHHRazhh+m/T36Bf5nxK5MtNuruuqPMcW15ByRVb8z/2pC7I6f3Nf694sVTJN 7CMn+3eRl2d436Scctrx9dPWbRuWXhJPn++06ZeIfkrQlmVFC19rbhCKf2q/6cjmdV9ME+9c +fh/naD2nvbu7tPLVf5NuWf52uOsEktxRqKhFnNRcSIAOQYWREACAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QR-skJwaRgrNEWQiRbpk8m_QgFo
Subject: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 08:51:37 -0000

DQojNTM6IDUuNS4yIGNoYXB0ZXIgdHlwbz8NCg0KRm9sbG93aW5nIHRleHQgd2lsbCBiZSBkZWxl
dGVkOg0KDQogICAgLi4uLi4uLi4uICBJZiB0aGUgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUA0K
ICAgIGlzIHJlY2VpdmVkIGZvciB0aGUgZmlyc3QgdGltZSBmb3IgdGhlIHJlcG9ydGluZyBub2Rl
IG9yIHRoZSBPQy0NCiAgICBTZXF1ZW5jZS1OdW1iZXIgQVZQIHZhbHVlIGlzIGxlc3MgdGhhbiB0
aGUgcHJldmlvdXNseSByZWNlaXZlZC8NCiAgICByZWNvcmRlZCBvbmUgKGFuZCBpcyBvdXRzaWRl
IHRoZSB2YWxpZCBvdmVyZmxvdyB3aW5kb3cpLCB0aGVuIGVpdGhlcg0KICAgIHRoZSBzZXF1ZW5j
ZSBudW1iZXIgaXMgc3RhbGUgKGUuZy4gYW4gaW50ZW50aW9uYWwgb3IgdW5pbnRlbnRpb25hbA0K
ICAgIHJlcGxheSkgYW5kIFNIT1VMRCBiZSBzaWxlbnRseSBkaXNjYXJkZWQuDQoNCiBBcyBsb25n
IGFzLCB0aGUgc2l0dWF0aW9ucyB0aGF0IGl0IHJlZmVycyBhcmUgY292ZXJlZCBsYXRlciBpbiB0
aGUgc2FtZSBjaGFwdGVyLg0KDQoNCg==


From nobody Fri Feb 21 01:06:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373A01A000E for ; Fri, 21 Feb 2014 01:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MhKFsAZphRN for ; Fri, 21 Feb 2014 01:06:53 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F33BC1A000A for ; Fri, 21 Feb 2014 01:06:52 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1L96kk1009321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2014 10:06:47 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1L96eQ7007897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 10:06:46 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 10:06:44 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 10:06:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Issue#32 status
Thread-Index: Ac8tiAGtvQe9mwQAS968RUS8ackr7wAHlw0AADeZSgAAFGQfsA==
Date: Fri, 21 Feb 2014 09:06:43 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4106@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <53050FE6.2090800@usdonovans.com> <4E45B36C-AB19-4869-A73B-4BA98B4ED0A4@nostrum.com>
In-Reply-To: <4E45B36C-AB19-4869-A73B-4BA98B4ED0A4@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1618
X-purgate-ID: 151667::1392973607-00003660-82872FF8/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cWO1OEd-YYVbvtBm9xjnO1Xmi3Y
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 09:06:56 -0000

Ben,

my preference for Time was based on the assumtion that it implicitly covers=
 the overflow   (see RFC 6733 clause 4.3.1).

I'm ok with Unsigned64, but then we need to address overflow more precisely=
, e.g.:

For the reacting node: a newly received sequence number Sn must be consider=
ed fresher than a stored sequence number Ss if and only if Ss < Sn < Ss+2^6=
3 or Sn < Ss-2^63.
For the reporting node: when Sl is the last generated sequence number and S=
o is the oldest potentially not yet expired sequence number, a newly genera=
ted sequence number Sn must comply with ( Sl < Sn < Sl+2^63 or Sn < sl-2^63=
 )and( So < Sn < So+2^63 or Sn < So-2^63 ).

Ulrich




-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Thursday, February 20, 2014 11:43 PM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#32 status


On Feb 19, 2014, at 2:11 PM, Steve Donovan  wrote=
:

>>> Sequence-Number is of type Time, however the value need not correspond =
to the point in time of generation.
>> SRD> I don't agree that the type should be time.  It should be of type U=
nsigned64.  A time stamp can be inserted into it but we should not prevent =
simple sequence numbers.  I agree with the remainder of the statement.
>=20


+1. Making it type Time implies that the recipient can do something time re=
lated with the value. That is not the case here.

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


From nobody Fri Feb 21 01:19:17 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11E41A04F6 for ; Fri, 21 Feb 2014 01:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAq8BAADVQK4 for ; Fri, 21 Feb 2014 01:19:14 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DC18C1A0048 for ; Fri, 21 Feb 2014 01:19:13 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1L9J8cj003757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2014 10:19:08 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1L9J7Ql006734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 10:19:08 +0100
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 10:19:07 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 10:19:07 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime]  #51: OC-Supported-Features in requests - conclusions
Thread-Index: Ac8u33cKdOS3EczGTrmu8FoNG7zaWgABUhNQ
Date: Fri, 21 Feb 2014 09:19:06 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 935
X-purgate-ID: 151667::1392974348-00003660-C6215DD0/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GKH09U_PLqP3DltOIPdcwJznjHs
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 09:19:16 -0000

I do not agree
I think the conclusion was to say:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.

For OC-Supported-Features AVP in answer messages refer to issue #30.

Ulrich =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Friday, February 21, 2014 9:35 AM
To: dime@ietf.org
Subject: [Dime] #51: OC-Supported-Features in requests - conclusions

#51: OC-Supported-Features in requests
=20
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter
 message a DOIC
 supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
replace SHOULD by MUST

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


From nobody Fri Feb 21 01:23:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349DD1A04F8 for ; Fri, 21 Feb 2014 01:23:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 b9w_Qxu-IdDo for ; Fri, 21 Feb 2014 01:23:33 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id AD68F1A01B0 for ; Fri, 21 Feb 2014 01:23:32 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-42-53071b1047ba
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.C0.04249.01B17035; Fri, 21 Feb 2014 10:23:28 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 10:23:27 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime]  #51: OC-Supported-Features in requests - conclusions
Thread-Index: AQHPLuX68aES9cpBlkeq6x7MGvA5R5q/boKg
Date: Fri, 21 Feb 2014 09:23:26 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvja6ANHuwQds/UYu5vSvYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsebMXcaCubwVdzsvMDcw/uDqYuTkkBAwkfh1op8dwhaTuHBv PVsXIxeHkMARRomexdcYIZzFjBJHdnxnBaliE7CTuHT6BVMXIweHiICyxOlfDiCmsICnxKs1 YHNEBLwkJi24yQxhG0lsOz0JzGYRUJXoWXKUBcTmFfCVePf4JtT4yYwSe3bcZAWZwykQIHFp JS9IDSPQPd9PrWECsZkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/7FC2EoSK7ZfYoSo15FYsPsT G4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGjuLU4qTcdCODTYzAsD+4 5bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZHxw6U1W+vF 368/z31ca6paZMreM5MXvk38unnLof733sWiYfc6NE9eEV0r0ad7bLHQldyquncb3xnUTZpa 8tPG9+/cIt2NCr2ne66kCCkn3LF9eCm03+z/vA+Xr3MeZO4JmTPz25/4jxd+dJe80zD4oN5S wtzwlnXSj6ftM+4EC3iJzV95qDxfiaU4I9FQi7moOBEAcgRADkkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/50gIqhs_aloOrB4_-ViCyVQ8ozc
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 09:23:35 -0000

Yes, sorry about this, this was my understanding as well but I provided a w=
rong rephrasing.
My understanding is the following conclusions is reached:

#51: OC-Supported-Features in requests

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.


-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: viernes, 21 de febrero de 2014 10:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

I do not agree
I think the conclusion was to say:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.

For OC-Supported-Features AVP in answer messages refer to issue #30.

Ulrich =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Friday, February 21, 2014 9:35 AM
To: dime@ietf.org
Subject: [Dime] #51: OC-Supported-Features in requests - conclusions

#51: OC-Supported-Features in requests
=20
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
replace SHOULD by MUST

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


From nobody Fri Feb 21 01:48:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0740F1A04D3 for ; Fri, 21 Feb 2014 01:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDcESWtJmWkY for ; Fri, 21 Feb 2014 01:47:53 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E13FC1A0452 for ; Fri, 21 Feb 2014 01:47:52 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-82-530720c3b2d8
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B1.38.23809.3C027035; Fri, 21 Feb 2014 10:47:48 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 10:47:46 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPKdHmQtBV/d0cbEW2/a46j08/xpq/f2cw
Date: Fri, 21 Feb 2014 09:47:46 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com>
In-Reply-To: <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje4RBfZgg+YNXBZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/O6LcwF04wrTm+8ytbAeFuji5GTQ0LARGLG7lVMELaYxIV7 69m6GLk4hAQOMUrs/fAGylnMKPHowS0WkCo2ATuJS6dfAHVwcIgIKEuc/uUAEhYWsJe4cH02 K4gtIuAg8X32eUYI20hi2b/pYAtYBFQl1q3ZzwZi8wr4Sjx+9oMVYv5vJom5O6+BNXACDbp/ 8TRYAyPQRd9PrQGzmQXEJW49mQ91qYDEkj3nmSFsUYmXj/+xQthKEiu2X2KEqNeTuDF1ChuE rS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAwD+45bfq DsY750QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXGZdRPT8h+5qWtq 9tptnvpvgYeK1TvJjoSwRYsF9jwW3Sm+4kDS3vAfZ9w4eGU81RXdXTtf/n9y16X1F5fGzbU3 JPUmnppn8MnsfdZeX84Xfy6c4n+xeUqU00G93auuFWa4tirflrS59f60Vf0jhed2BlYHVMze fvlqkp2YsvP19t+zdoppy5spsRRnJBpqMRcVJwIAP/LVYEoCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sbXZ625pDZNzacIXPDU13D1QMas
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 09:47:57 -0000

Hello all,

I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.

I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: viernes, 14 de febrero de 2014 23:13
To: Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.

On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:

>=20
> Agree that it is a small optimization, which I put there because at=20
> the beginning there seemed to be a lot of worry on every extra AVP ;-)
>=20
> I prefer having the AVP optional but with a default value just like it=20
> is now. We have the same for the reduction percentage and the validity=20
> time as well.
>=20
> - Jouni
>=20
> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:
>=20
>> Hi Mcruz
>>=20
>> The current description indicates that when not present the OLR is of ty=
pe Host, which was fine for me and keeps my preference.=20
>> We may have  deployments where Realm OLR is not used, or where statistic=
ally the HOST type is the most frequent, so to have the grouped OLR-AVP con=
taining a minimum of AVPs minimizes parsing. I agree it is a small optimiza=
tion.
>>=20
>> Best regards
>>=20
>> JJacques
>>=20
>>=20
>>=20
>>=20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de=20
>> lionel.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0=
 :=20
>> dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]=20
>> [dime] #54: OC-Report-Type as mandatory AVP
>>=20
>> Hi Maria Cruz,
>>=20
>> I'm assuming that you mean "required" instead of "mandatory", right?
>>=20
>> So instead of:
>>=20
>>  OC-OLR ::=3D < AVP Header: TBD2 >
>>             < OC-Sequence-Number >
>>             [ OC-Report-Type ]
>>             [ OC-Reduction-Percentage ]
>>             [ OC-Validity-Duration ]
>>           * [ AVP ]
>>=20
>> You would prefer:
>>=20
>>  OC-OLR ::=3D < AVP Header: TBD2 >
>>             < OC-Sequence-Number >
>>             { OC-Report-Type }
>>             [ OC-Reduction-Percentage ]
>>             [ OC-Validity-Duration ]
>>           * [ AVP ]
>>=20
>> And I'm fine with this proposal.
>>=20
>> Cheers,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue=20
>> tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :=20
>> maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime]=20
>> [dime] #54: OC-Report-Type as mandatory AVP
>>=20
>> #54: OC-Report-Type as mandatory AVP
>>=20
>> Now in chapter 4.6:
>>=20
>>   The default value of the OC-Report-Type AVP is 0 (i.e. the host
>>   report).
>>=20
>> This AVP is always required, right? Then, I think it is more precise tha=
t  we define this AVP as mandatory.
>>=20
>> --
>> -----------------------------------------------+---------------------
>> -----------------------------------------------+---
>> -----------------------------------------------+---
>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>    Type:  defect                             |  Bartolom=E9
>> Priority:  major                              |     Status:  new
>> Component:  draft-docdt-dime-ovli              |  Milestone:
>> Severity:  Active WG Document                 |    Version:  1.0
>>                                              |   Keywords:
>> -----------------------------------------------+---------------------
>> -----------------------------------------------+---
>> -----------------------------------------------+---
>>=20
>> Ticket URL: 
>> dime 
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _____________________________________________________________________
>> ____________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations confi=
dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites =
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil=
lez 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. Merc=
i.
>>=20
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law; they should not be distributed, u=
sed or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> 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
> _______________________________________________
> 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 Fri Feb 21 01:58:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94B51A043D for ; Fri, 21 Feb 2014 01:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 wUE_Lil2uKH9 for ; Fri, 21 Feb 2014 01:58:29 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C832C1A0436 for ; Fri, 21 Feb 2014 01:58:28 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-c5-5307234003b0
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id ED.65.04249.04327035; Fri, 21 Feb 2014 10:58:24 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 10:58:23 +0100
From: Maria Cruz Bartolome 
To: "draft-docdt-dime-ovli@tools.ietf.org" , "dime@ietf.org list" 
Thread-Topic: [Dime] [dime] #24: Terminology and Abbreviations
Thread-Index: AQHPLbBO8ZksuYOyOUeQ8Ojozux3Bpq+q3iAgADPaDA=
Date: Fri, 21 Feb 2014 09:58:22 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978411B@ESESSMB101.ericsson.se>
References: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org> <53051277.3090301@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvja6DMnuwwa4H4hZze1ewWUxZ8YfJ gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MrYd6KbsWCFYMXaDTINjL18XYycHBICJhIz 121mhrDFJC7cW8/WxcjFISRwhFHi3v0PLBDOYkaJPS8+s4BUsQnYSVw6/YIJxBYRqJRoPHkb LC4sYCtx5Uk/K0TcTmLmn7VQNVYStw9dB4uzCKhKzH91B2gbBwevgK/E62P1EPPnM0r82vmN HaSGU8BeYsupj2D1jEAXfT+1BmwOs4C4xK0n85kgLhWQWLLnPNTVohIvH/9jhbCVJFZsv8QI Ua8jsWD3JzYIW1ti2cLXYPW8AoISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkaO4tTipNx0 I4NNjMBoOLjlt8UOxst/bQ4xSnOwKInzfnzrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB 8eqMW3O/FcmaHNyV9UFT4OS1xL9/GQ3O/ZfjE+p5/Mvt/PoHyhIiUgfreRV027a1cK7gnTL3 7dpFPs0TPO9uO/Wh7oV4l8/byxuT387lenV0++EYfZlrzy9mmya3n4uaK3dM1yl4Aovfx2D2 XwWV/VsEvliuuXd54jYB8VlzvjQYrl+drKXd9F6JpTgj0VCLuag4EQBECkL/VAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fDBshXYvuvO4CDfKfMu6nNEjPXU
Subject: Re: [Dime] [dime] #24: Terminology and Abbreviations
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 09:58:32 -0000

Hello,

I agree about the information removal mentioned.
About new text on 5.5, this may be helpful, but agreement should be based o=
n specific text provided...
Cheers
/MCruz


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: jueves, 20 de febrero de 2014 23:34
To: Steve Donovan
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #24: Terminology and Abbreviations

+1

On Feb 19, 2014, at 2:22 PM, Steve Donovan  wrote=
:

> There has been no discussion of this ticket.
>=20
> I propose that the definition of Diameter layer load balancing be removed=
.
>=20
> I propose removing the definition of Topology Hiding, as it has meanings =
outside of the context of Diameter overload.
>=20
> I also propose that we remove any discussion of agents acting as server f=
ront ends or topology hiders.  I propose instead to have a discussion in se=
ction 5.5 outlining the requirements for an agent to take on the role of a =
reporting node for host reports.
>=20
> Regards,
>=20
> Steve
>=20
> On 1/28/14 2:13 PM, dime issue tracker wrote:
>> #24: Terminology and Abbreviations
>>=20
>>  This applies to draft-ietf-dime-ovli.
>>=20
>>  Section 2. contains a definition of Diameter layer Load Balancing=20
>> that  does not appear to be needed.  This was originally included as=20
>> one of the  features of a Server Front End.  Given that SFE has been=20
>> removed this can  be removed as well.
>>=20
>>  The definition of Topology Hiding is the generic Diameter topology=20
>> hiding  definition.  This is different than the server identity=20
>> hiding that an  agent might optionally do.  We should probably remove=20
>> this definition and  insert a definition of server identity hiding=20
>> for an agent that is  aggregating overload state across a server farm.
>>=20
>>=20
>=20
> _______________________________________________
> 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 Fri Feb 21 02:48:43 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80471A009A for ; Fri, 21 Feb 2014 02:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ftwg1S1YTXz0 for ; Fri, 21 Feb 2014 02:48:40 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CE1461A0505 for ; Fri, 21 Feb 2014 02:48:39 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1LAmYxW025046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2014 11:48:34 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1LAmXlb018893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 11:48:33 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 11:48:33 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 11:48:33 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1A=
Date: Fri, 21 Feb 2014 10:48:32 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com>
In-Reply-To: <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3085
X-purgate-ID: 151667::1392979714-00003660-5FF6213E/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aZQevopHR95qHwdq_YIwiwOn-bU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 10:48:43 -0000

Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client
Here I disagree. We have the 3GPP requirement to allow requesting different=
 amount of reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35
3. introduce the binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> #35: additional report types are proposed
> =20
> Dear all,
> =20
> I believe we can conclude, not to add additional report types. However, w=
e agreed to add clarifying text to clause 5.5 as follows:
> =20
> When an agent received an OLR in response to a request initiated by a cli=
ent not supporting DOIC, this agent needs to bind the received OLR to the o=
rigin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention
 If there's an intervening DOIC agent, then the agent, not the client, is t=
he reacting node from the server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node
 But, short of adding an origin-host type, nothing binds the OLR to a parti=
cular client, regardless of DOIC support at the clients.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.


From nobody Fri Feb 21 07:03:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE741A0179 for ; Fri, 21 Feb 2014 07:03:39 -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
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 jHn9qPTmf_Qo for ; Fri, 21 Feb 2014 07:03:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8A01A0172 for ; Fri, 21 Feb 2014 07:03:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54610 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGrdU-0008Ly-4L for dime@ietf.org; Fri, 21 Feb 2014 07:03:33 -0800
Message-ID: <53076AC3.60201@usdonovans.com>
Date: Fri, 21 Feb 2014 09:03:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org> <53051277.3090301@usdonovans.com>  <087A34937E64E74E848732CFF8354B920978411B@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978411B@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------010407060305050404020201"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/u3_wpmU96dGMnYtVcxjvMVmydXU
Subject: Re: [Dime] [dime] #24: Terminology and Abbreviations
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 15:03:39 -0000

This is a multi-part message in MIME format.
--------------010407060305050404020201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Maria Cruz,

I agree with the need to have text before agreement is reached on that text.

Steve

On 2/21/14 3:58 AM, Maria Cruz Bartolome wrote:
> Hello,
>
> I agree about the information removal mentioned.
> About new text on 5.5, this may be helpful, but agreement should be based on specific text provided...
> Cheers
> /MCruz
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: jueves, 20 de febrero de 2014 23:34
> To: Steve Donovan
> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #24: Terminology and Abbreviations
>
> +1
>
> On Feb 19, 2014, at 2:22 PM, Steve Donovan  wrote:
>
>> There has been no discussion of this ticket.
>>
>> I propose that the definition of Diameter layer load balancing be removed.
>>
>> I propose removing the definition of Topology Hiding, as it has meanings outside of the context of Diameter overload.
>>
>> I also propose that we remove any discussion of agents acting as server front ends or topology hiders.  I propose instead to have a discussion in section 5.5 outlining the requirements for an agent to take on the role of a reporting node for host reports.
>>
>> Regards,
>>
>> Steve
>>
>> On 1/28/14 2:13 PM, dime issue tracker wrote:
>>> #24: Terminology and Abbreviations
>>>
>>>  This applies to draft-ietf-dime-ovli.
>>>
>>>  Section 2. contains a definition of Diameter layer Load Balancing 
>>> that  does not appear to be needed.  This was originally included as 
>>> one of the  features of a Server Front End.  Given that SFE has been 
>>> removed this can  be removed as well.
>>>
>>>  The definition of Topology Hiding is the generic Diameter topology 
>>> hiding  definition.  This is different than the server identity 
>>> hiding that an  agent might optionally do.  We should probably remove 
>>> this definition and  insert a definition of server identity hiding 
>>> for an agent that is  aggregating overload state across a server farm.
>>>
>>>
>> _______________________________________________
>> 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
>


--------------010407060305050404020201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      I agree with the need to have text before agreement is reached on
      that text.

      

      Steve

      

    
    
On 2/21/14 3:58 AM, Maria Cruz
      Bartolome wrote:

    

    

      
Hello,

I agree about the information removal mentioned.
About new text on 5.5, this may be helpful, but agreement should be based on specific text provided...
Cheers
/MCruz


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: jueves, 20 de febrero de 2014 23:34
To: Steve Donovan
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #24: Terminology and Abbreviations

+1

On Feb 19, 2014, at 2:22 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
There has been no discussion of this ticket.

I propose that the definition of Diameter layer load balancing be removed.

I propose removing the definition of Topology Hiding, as it has meanings outside of the context of Diameter overload.

I also propose that we remove any discussion of agents acting as server front ends or topology hiders.  I propose instead to have a discussion in section 5.5 outlining the requirements for an agent to take on the role of a reporting node for host reports.

Regards,

Steve

On 1/28/14 2:13 PM, dime issue tracker wrote:


        

          
#24: Terminology and Abbreviations

 This applies to draft-ietf-dime-ovli.

 Section 2. contains a definition of Diameter layer Load Balancing 
that  does not appear to be needed.  This was originally included as 
one of the  features of a Server Front End.  Given that SFE has been 
removed this can  be removed as well.

 The definition of Topology Hiding is the generic Diameter topology 
hiding  definition.  This is different than the server identity 
hiding that an  agent might optionally do.  We should probably remove 
this definition and  insert a definition of server identity hiding 
for an agent that is  aggregating overload state across a server farm.




        

        
_______________________________________________
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



    

    

  


--------------010407060305050404020201--


From nobody Fri Feb 21 07:06:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACF81A0185 for ; Fri, 21 Feb 2014 07:06:06 -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
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 Qa8n1u4zzKJg for ; Fri, 21 Feb 2014 07:06:05 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5501A0172 for ; Fri, 21 Feb 2014 07:06:05 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54617 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGrfr-0002xu-UR for dime@ietf.org; Fri, 21 Feb 2014 07:06:01 -0800
Message-ID: <53076B57.90607@usdonovans.com>
Date: Fri, 21 Feb 2014 09:05:59 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------020602050901090308000000"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JuPNsA1Yi5FkrqGCA4wju5v4yt8
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 15:06:06 -0000

This is a multi-part message in MIME format.
--------------020602050901090308000000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

+1
On 2/21/14 3:23 AM, Maria Cruz Bartolome wrote:
> Yes, sorry about this, this was my understanding as well but I provided a wrong rephrasing.
> My understanding is the following conclusions is reached:
>
> #51: OC-Supported-Features in requests
>
>  Now:
>  The OC-Supported-Features AVP SHOULD be included into every Diameter  message a DOIC  supporting node sends (and intends to use for DOIC purposes).
>  
> Proposal:
> The OC-Supported-Features AVP MUST be included into every Diameter request message a DOIC supporting node sends.
>
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
> Sent: viernes, 21 de febrero de 2014 10:19
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions
>
> I do not agree
> I think the conclusion was to say:
> The OC-Supported-Features AVP MUST be included into every Diameter request message a DOIC supporting node sends.
>
> For OC-Supported-Features AVP in answer messages refer to issue #30.
>
> Ulrich  
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
> Sent: Friday, February 21, 2014 9:35 AM
> To: dime@ietf.org
> Subject: [Dime] #51: OC-Supported-Features in requests - conclusions
>
> #51: OC-Supported-Features in requests
>  
> My understanding is the following conclusions is reached:
>
>  Now:
>  The OC-Supported-Features AVP SHOULD be included into every Diameter  message a DOIC  supporting node sends (and intends to use for DOIC purposes).
>  
> Proposal:
> replace SHOULD by MUST
>
> _______________________________________________
> 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
>


--------------020602050901090308000000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    
On 2/21/14 3:23 AM, Maria Cruz
      Bartolome wrote:

    

    

      
Yes, sorry about this, this was my understanding as well but I provided a wrong rephrasing.
My understanding is the following conclusions is reached:

#51: OC-Supported-Features in requests

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  message a DOIC  supporting node sends (and intends to use for DOIC purposes).
 
Proposal:
The OC-Supported-Features AVP MUST be included into every Diameter request message a DOIC supporting node sends.


-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: viernes, 21 de febrero de 2014 10:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

I do not agree
I think the conclusion was to say:
The OC-Supported-Features AVP MUST be included into every Diameter request message a DOIC supporting node sends.

For OC-Supported-Features AVP in answer messages refer to issue #30.

Ulrich  

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Friday, February 21, 2014 9:35 AM
To: dime@ietf.org
Subject: [Dime] #51: OC-Supported-Features in requests - conclusions

#51: OC-Supported-Features in requests
 
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  message a DOIC  supporting node sends (and intends to use for DOIC purposes).
 
Proposal:
replace SHOULD by MUST

_______________________________________________
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



    

    

  


--------------020602050901090308000000--


From nobody Fri Feb 21 07:33:14 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206F11A018F for ; Fri, 21 Feb 2014 07:33:13 -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
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 yMqRjp6yeDd4 for ; Fri, 21 Feb 2014 07:33:11 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id CA71A1A017D for ; Fri, 21 Feb 2014 07:33:11 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54892 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGs5u-0001lf-VB for dime@ietf.org; Fri, 21 Feb 2014 07:33:07 -0800
Message-ID: <530771A6.4030002@usdonovans.com>
Date: Fri, 21 Feb 2014 09:32:54 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <087A34937E64E74E848732CFF8354B9209784033@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784033@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------000005080704040101070902"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/D2wI0mDwBV4Vaplp-inunY0V4f8
Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 15:33:13 -0000

This is a multi-part message in MIME format.
--------------000005080704040101070902
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Maria Cruz,

I think we need to see the replacement text before concluding this ticket.

Steve

On 2/21/14 2:51 AM, Maria Cruz Bartolome wrote:
> #53: 5.5.2 chapter typo?
>
> Following text will be deleted:
>
>     .........  If the OC-Supported-Features AVP
>     is received for the first time for the reporting node or the OC-
>     Sequence-Number AVP value is less than the previously received/
>     recorded one (and is outside the valid overflow window), then either
>     the sequence number is stale (e.g. an intentional or unintentional
>     replay) and SHOULD be silently discarded.
>
>  As long as, the situations that it refers are covered later in the same chapter.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------000005080704040101070902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      I think we need to see the replacement text before concluding this
      ticket.

      

      Steve

      

    
    
On 2/21/14 2:51 AM, Maria Cruz
      Bartolome wrote:

    

    

      
#53: 5.5.2 chapter typo?

Following text will be deleted:

    .........  If the OC-Supported-Features AVP
    is received for the first time for the reporting node or the OC-
    Sequence-Number AVP value is less than the previously received/
    recorded one (and is outside the valid overflow window), then either
    the sequence number is stale (e.g. an intentional or unintentional
    replay) and SHOULD be silently discarded.

 As long as, the situations that it refers are covered later in the same chapter.


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



    

    

  


--------------000005080704040101070902--


From nobody Fri Feb 21 07:37:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9155E1A0316 for ; Fri, 21 Feb 2014 07:37:01 -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
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 4PgbTvqRBZ5O for ; Fri, 21 Feb 2014 07:36:59 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id B68BE1A01B7 for ; Fri, 21 Feb 2014 07:36:58 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54899 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGs9i-0006Mf-1l for dime@ietf.org; Fri, 21 Feb 2014 07:36:54 -0800
Message-ID: <53077290.8080501@usdonovans.com>
Date: Fri, 21 Feb 2014 09:36:48 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------040509040706040808000208"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AJG93XT-L1mqN9DAGEVTKWQaUwk
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 15:37:01 -0000

This is a multi-part message in MIME format.
--------------040509040706040808000208
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Maria Cruz,

I support your suggested changes.  I have one further suggested change
below.

Steve

On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
> #52: Throttling not needed to be based on previous history
>  
> Following agreement is reached:
>
>  Now (chapter 4.7):
>     The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
>     and describes the percentage of the traffic that the sender is
>     requested to reduce, compared to what it otherwise would have sent.
>  
>  Proposal:
>    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  
>    and describes the percentage of the traffic that the sender is  
>    requested to reduce, compared to what it otherwise would send.                  <----
>  
>  
>  Now (chapter 5.5.2):
>       Indicates that the reporting node urges the reacting node to
>       reduce its traffic by a given percentage.  For example if the
>       reacting node has been sending 100 packets per second to the
>       reporting node, then a reception of OC-Reduction-Percentage value
>       of 10 would mean that from now on the reacting node MUST only send
>       90 packets per second.  How the reacting node achieves the "true
>       reduction" transactions leading to the sent request messages is up
>       to the implementation.  The reacting node MAY simply drop every
>       10th packet from its output queue and let the generic application
>       logic try to recover from it.0 < value < 100
>
>   Proposal:
>  Indicates that the reporting node urges the reacting node to reduce 
>  its traffic by a given percentage. For example if the
>  reacting node would send 100 packets to the				<---
>  reporting node, then a reception of OC-Reduction-Percentage value of 
>  10 would mean that from now on the reacting node MUST only send
>  90 packets instead of 100. How the reacting node achieves the "true       <---
>  reduction" transactions leading to the sent request messages is up to 
>  the implementation. The reacting node MAY simply drop every 10th 
>  packet from its output queue and let the generic application logic try 
>  to recover from it.
SRD> Replace "from now on" in the above with "for the period that the
overload report is active"
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------040509040706040808000208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      I support your suggested changes.  I have one further suggested
      change below.

      

      Steve

      

    
    
On 2/21/14 2:40 AM, Maria Cruz
      Bartolome wrote:

    

    

      
#52: Throttling not needed to be based on previous history
 
Following agreement is reached:

 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.
 
 Proposal:
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  
   and describes the percentage of the traffic that the sender is  
   requested to reduce, compared to what it otherwise would send.                  <----
 
 
 Now (chapter 5.5.2):
      Indicates that the reporting node urges the reacting node to
      reduce its traffic by a given percentage.  For example if the
      reacting node has been sending 100 packets per second to the
      reporting node, then a reception of OC-Reduction-Percentage value
      of 10 would mean that from now on the reacting node MUST only send
      90 packets per second.  How the reacting node achieves the "true
      reduction" transactions leading to the sent request messages is up
      to the implementation.  The reacting node MAY simply drop every
      10th packet from its output queue and let the generic application
      logic try to recover from it.0 < value < 100

  Proposal:
 Indicates that the reporting node urges the reacting node to reduce 
 its traffic by a given percentage. For example if the
 reacting node would send 100 packets to the				<---
 reporting node, then a reception of OC-Reduction-Percentage value of 
 10 would mean that from now on the reacting node MUST only send
 90 packets instead of 100. How the reacting node achieves the "true       <---
 reduction" transactions leading to the sent request messages is up to 
 the implementation. The reacting node MAY simply drop every 10th 
 packet from its output queue and let the generic application logic try 
 to recover from it.

    

    SRD> Replace "from now on" in the above with "for the period that
    the overload report is active"

    

      

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



    

    

  


--------------040509040706040808000208--


From nobody Fri Feb 21 07:42:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663D41A02E7 for ; Fri, 21 Feb 2014 07:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ09GCCEksx6 for ; Fri, 21 Feb 2014 07:42:30 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC301A019A for ; Fri, 21 Feb 2014 07:42:29 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-bc-530773e0dce5
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id C0.37.04853.0E377035; Fri, 21 Feb 2014 16:42:24 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 16:42:24 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
Thread-Index: Ac8u4hyhyFipAfuqQZK1Yn82LVgN9AAL7G4AAAJgB0A=
Date: Fri, 21 Feb 2014 15:42:22 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978435A@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B9209784033@ESESSMB101.ericsson.se> <530771A6.4030002@usdonovans.com>
In-Reply-To: <530771A6.4030002@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920978435AESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvje6DYvZgg8OPdCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrfLz1gKdtlUvPwxi6mBsc+0i5GTQ0LAROJM32pmCFtM4sK9 9WxdjFwcQgInGCX2dJxignAWM0r8unmRCaSKTcBO4tLpF0A2B4eIgLLE6V8OIGFhAQeJ1vXv oMKOEsvOOYGERQSsJL423WABCbMIqEpc/qMOYvIK+Er0HHIDMYUECiX+nXIBKeYU0JP43dcO toYR6Jjvp9aA2cwC4hK3nsxngjhSQGLJnvNQB4tKvHz8jxXCVpJYdPszVH2+xJYv39hAbF4B QYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjJLFqcXF uelGBnq56bkleqlFmcnFxfl5esWpmxiBMXRwy2+jHYwn99gfYpTmYFES573OWhMkJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgbG9R/bCQvWfLkflfwr72b9b1NabGWuWqbeTee3Uzo/7gmsX F0TweFnJBxgKNHAZTnvCW7rJuOdq3K8sr4XqMj8Lnu3xev84YF6olrnL23mVJxZaMB1P0ypv Fd+Z9Jrj5ZfKv8sLRWLXRTs9Puqy7EWxtwBngYnSHanU2CSuo2/N38jemFIoocRSnJFoqMVc VJwIAH/1u8xvAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0lPYZDWRizSc1ox2OWTAHA3a9Cg
Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 15:42:32 -0000

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

Steve,

Extracted text is duplicated now, this paragraph I referred is simply wrong=
.
But I agree duplicated text should be revised due to issue#29, but this is =
up to this ticket to provide the alternative text.

Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: viernes, 21 de febrero de 2014 16:33
To: dime@ietf.org
Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion

Maria Cruz,

I think we need to see the replacement text before concluding this ticket.

Steve
On 2/21/14 2:51 AM, Maria Cruz Bartolome wrote:



#53: 5.5.2 chapter typo?



Following text will be deleted:



    .........  If the OC-Supported-Features AVP

    is received for the first time for the reporting node or the OC-

    Sequence-Number AVP value is less than the previously received/

    recorded one (and is outside the valid overflow window), then either

    the sequence number is stale (e.g. an intentional or unintentional

    replay) and SHOULD be silently discarded.



 As long as, the situations that it refers are covered later in the same ch=
apter.





_______________________________________________

DiME mailing list

DiME@ietf.org

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




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











Steve,



 <=
/p>

Extracted text is duplica=
ted now, this paragraph I referred is simply wrong.


But I agree duplicated te=
xt should be revised due to issue#29, but this is up to this ticket to prov=
ide the alternative text.


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





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

Sent: viernes, 21 de febrero de 2014 16:33

To: dime@ietf.org

Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion






 


Maria Cruz,



I think we need to see the replacement text before concluding this ticket.<=
br>


Steve




On 2/21/14 2:51 AM, Maria Cruz Bartolome wrote:=







 


#53: 5.5.2 chapter typo?


 


Following text will be deleted:


 


    .........  If the OC-Supported-Features AVP


    is received for the first time for the reporting no=
de or the OC-


    Sequence-Number AVP value is less than the previous=
ly received/


    recorded one (and is outside the valid overflow win=
dow), then either


    the sequence number is stale (e.g. an intentional o=
r unintentional


    replay) and SHOULD be silently discarded.


 


 As long as, the situations that it refers are covered later in the sa=
me chapter.


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_087A34937E64E74E848732CFF8354B920978435AESESSMB101erics_--


From nobody Fri Feb 21 07:43:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9071A02CC for ; Fri, 21 Feb 2014 07:43:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-yPBglvzsLm for ; Fri, 21 Feb 2014 07:43:53 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 760341A019A for ; Fri, 21 Feb 2014 07:43:53 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1LFhlfs050069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 09:43:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net>
Date: Fri, 21 Feb 2014 09:43:49 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K-mRqvG_PqBbz53EhzgkfBo-uoM
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 15:43:55 -0000

On Feb 21, 2014, at 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> the proposed conclusion was based on comments received so far (from =
Lionel, Nirav, Steve, MCruz, JJ).=20
> Now you seem to address two points:
> a) There is no dependency to DOIC support of the client.
> To address this I would like to propose rewording of the clarifying =
text for 5.5. as follows:
>=20
> When an agent takes the role of a reacting node, the agent needs to =
bind a received OLR to the origin host of the client that initiated the =
request which corresponds to the answer containing the OLR.=20
>=20
> This would cover not only the case where an agent takes the role of =
the reacting node on behalf of a (or several) non supporting client, but =
also the case where an agent is configured to take the role of a =
reporting node (for realm-type reports) towards the client and at the =
same time the role of a reacting node towards the server.
>=20
> b) There is no binding of the OLR to the orig-host of the client
> Here I disagree. We have the 3GPP requirement to allow requesting =
different amount of reduction from different clients, and I think we =
have 3 options:
> 1. ignore the 3GPP requirement
> 2. introduce new report types as originally proposed in #35
> 3. introduce the binding between OLR and orig-host of the client.
>=20
> So far I understood that people favoured option 3.

That approach implies the 3GPP requirement is the _only_ case. The =
result is, a DOIC agent cannot apply a single OLR to requests from =
multiple clients, ever. I don't think that's what we want.=20

I agree there may be times the server wants to send an OLR for a =
specific client, but I don't think it's the default case. I think that =
case would be better handled by a new report type, or by a new optional =
AVP that includes the targeted client's, so that an agent can apply the =
report to requests that include that identity as the Origin-Host. =20


From nobody Fri Feb 21 07:53:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662A71A031C for ; Fri, 21 Feb 2014 07:53:08 -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
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 6cJOnXQa87am for ; Fri, 21 Feb 2014 07:53:06 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id BC5FC1A01BE for ; Fri, 21 Feb 2014 07:53:06 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54947 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGsPJ-0001FD-RT for dime@ietf.org; Fri, 21 Feb 2014 07:53:02 -0800
Message-ID: <53077659.1030909@usdonovans.com>
Date: Fri, 21 Feb 2014 09:52:57 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------040000060801090100000403"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/n_mqVnmQeQ0jtdaFnZAZFFmrr9c
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 15:53:08 -0000

This is a multi-part message in MIME format.
--------------040000060801090100000403
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

I have a couple of concerns with this approach, as currently outlined. 

First, how do we handle the case where there are multiple DOIC
supporting agents between the non supporting client and the reporting
node.  This, I guess, is a general question, not just applying to this
proposal.  I suggest we capture in the agent behavior section that is
currently missing wording indicating that the first supporting agent
that receives the request must be the reacting node for that
non-supporting client.  Subsequent DOIC supporting agents must not be
the reacting node for the non-supporting client.

We need to think through the ramifications of having multiple agents
being the reacting node for the same non supporting clients, as this
could easily happen in networks where multiple agents are involved in a
single transaction.  On the surface it doesn't seem to be an issue for
the loss algorithm, but this might not be the case with other algorithms.

My other concern is that this puts a lot of extra onus on the agent even
for the case where the reporting node does not want to differentiate
overload reports.  To this end I suggest we add an indication in the OLR
marking the reports that are specific to just the Origin-Host in the
request.  Absence of the "single-client-only" AVP would mean that the
report applies to all clients.  Presence of the AVP would indicate that
the OLR applies to the Origin-Host.

Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ben,
>
> the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
> Now you seem to address two points:
> a) There is no dependency to DOIC support of the client.
> To address this I would like to propose rewording of the clarifying text for 5.5. as follows:
>
> When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 
>
> This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.
>
> b) There is no binding of the OLR to the orig-host of the client
> Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
> 1. ignore the 3GPP requirement
> 2. introduce new report types as originally proposed in #35
> 3. introduce the binding between OLR and orig-host of the client.
>
> So far I understood that people favoured option 3.
>
> See also inline.
>
> Ulrich
>
>
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com] 
> Sent: Thursday, February 20, 2014 11:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] Issue#35 conclusion
>
>
> On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>
>> #35: additional report types are proposed
>>  
>> Dear all,
>>  
>> I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>>  
>> When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.
> I do not agree.
>
> You proposal implies that the server's OLR only applies to that client.
> exactly, that was the intention
>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
>  the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node
>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>  the binding is always there, regardless of DOIC support at the client
>
>  Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------040000060801090100000403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I have a couple of concerns with this approach, as currently
      outlined.  

      

      First, how do we handle the case where there are multiple DOIC
      supporting agents between the non supporting client and the
      reporting node.  This, I guess, is a general question, not just
      applying to this proposal.  I suggest we capture in the agent
      behavior section that is currently missing wording indicating that
      the first supporting agent that receives the request must be the
      reacting node for that non-supporting client.  Subsequent DOIC
      supporting agents must not be the reacting node for the
      non-supporting client.

      

      We need to think through the ramifications of having multiple
      agents being the reacting node for the same non supporting
      clients, as this could easily happen in networks where multiple
      agents are involved in a single transaction.  On the surface it
      doesn't seem to be an issue for the loss algorithm, but this might
      not be the case with other algorithms.

      

      My other concern is that this puts a lot of extra onus on the
      agent even for the case where the reporting node does not want to
      differentiate overload reports.  To this end I suggest we add an
      indication in the OLR marking the reports that are specific to
      just the Origin-Host in the request.  Absence of the
      "single-client-only" AVP would mean that the report applies to all
      clients.  Presence of the AVP would indicate that the OLR applies
      to the Origin-Host.

      

      Steve

      

    
    
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Ben,

the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text for 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 

This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client
Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35
3. introduce the binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:



      

        
#35: additional report types are proposed
 
Dear all,
 
I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
 
When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.


      

      
I do not agree.

You proposal implies that the server's OLR only applies to that client.
<Ulrich>exactly, that was the intention</Ulrich>
 If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>
 But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.

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



    

    

  


--------------040000060801090100000403--


From nobody Fri Feb 21 08:01:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1414C1A0279 for ; Fri, 21 Feb 2014 08:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ps_CfpUeeuX for ; Fri, 21 Feb 2014 08:01:11 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id F1FFB1A03C8 for ; Fri, 21 Feb 2014 08:01:10 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54957 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGsXB-0002fj-7L for dime@ietf.org; Fri, 21 Feb 2014 08:01:06 -0800
Message-ID: <53077841.9010003@usdonovans.com>
Date: Fri, 21 Feb 2014 10:01:05 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070605050509060101020208"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/62VQR117IfvYQ7YPzS_hoivpkRo
Subject: [Dime] Agent overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 16:01:12 -0000

This is a multi-part message in MIME format.
--------------070605050509060101020208
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

At the Vancouver IETF meeting I believe there was consensus that Agent
overload needs to be addressed by the DIME working group.

The group wasn't ready to make a decision as to whether it should be
done as a separate document or if it should be incorporated into the
base DOIC specification.

I would like to request guidance from the working group on these two
options. 

My preference is to incorporate agent overload into the base DOIC
specification.

If that is not done then I propose we make the agent overload draft a
working group item.

Regards,

Steve

--------------070605050509060101020208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    At the Vancouver IETF
      meeting I believe there was consensus that Agent overload needs to
      be addressed by the DIME working group.

      

      The group wasn't ready to make a decision as to whether it should
      be done as a separate document or if it should be incorporated
      into the base DOIC specification.

      

      I would like to request guidance from the working group on these two
      options.  

      

      My preference is to incorporate agent overload into the base DOIC
      specification.

      

      If that is not done then I propose we make the agent overload
      draft a working group item.

      

      Regards,

      

      Steve

    
  


--------------070605050509060101020208--


From nobody Fri Feb 21 08:05:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006C41A01E9 for ; Fri, 21 Feb 2014 08:04:58 -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
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 DgCbEwTamXH3 for ; Fri, 21 Feb 2014 08:04:57 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDE1A01DC for ; Fri, 21 Feb 2014 08:04:57 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54966 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGsak-0007Bs-TT for dime@ietf.org; Fri, 21 Feb 2014 08:04:53 -0800
Message-ID: <5307791E.6060900@usdonovans.com>
Date: Fri, 21 Feb 2014 10:04:46 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040909000404070302020801"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oTBkcvtcMW4BDcXRDOX5yKyY6Cg
Subject: Re: [Dime] Draft agenda for IETF#89 DIME meeting
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 16:04:59 -0000

This is a multi-part message in MIME format.
--------------040909000404070302020801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jouni,
Lionel,

I don't know if these items need to be agenda items for the meeting but
I would like to get a sense from the working group for the direction we
should take on agent overload (see previous email).  I also propose that
draft-donovan-dime-doc-rate-control-00.txt be made a working group item.

Steve

On 2/19/14 3:28 AM, Jouni Korhonen wrote:
> Folks,
>
> Slightly late as always..
> http://www.ietf.org/proceedings/89/agenda/agenda-89-dime
>
> We have reserved as much time as possible for the overload
> topic.
>
> Agenda comments/change requests asap, please.
>
>
> - Jouni & Lionel
>
> **
>
>
> DIME WG IETF 89 Agenda  
>
> Chairs:
> Jouni Korhonen 
> Lionel Morand@ 
>
> Jabber room: dime at jabber.ietf.org (Please join)
> THURSDAY, March 6, 2014
> 0900-1130  Morning Session I (150 mins)
> Richmond/Chelsea/Tower
>
> 09:00 - 09:10, Preliminaries (10 minutes)
> ------------------------------------------
> Audio/Video & Remote Presentation Debugging
> Note Well
> Note Takers
> Jabber scribe
> Agenda bash
> Document Status
>
>  o draft-ietf-dime-app-design-guide-21   -> IESG
>  o draft-ietf-dime-e2e-sec-req-01        -> About ready -> WGLC
>  o draft-ietf-dime-group-signaling-03    -> in WG
>  o draft-ietf-dime-ovli-01               -> in WG
>  o draft-ietf-dime-pmip6-lr-18           -> AUTH48
>  o draft-ietf-dime-rfc4005bis-14         -> AUTH48
>
> Working group draft discussion (20 minutes)
> -------------------------------------------
>
> 09:10 - 09:30 Diameter Group Signaling, Marco (20 minutes)
> https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/
>
> Chartered individual draft discussion (15 minutes)
> --------------------------------------------------
>
> 09:30 - 09:45 Diameter Congestion and Filter Attributes, Brent (15 minutes)
> https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attributes/
>
> Diamater Overload discussion (80 minutes)
> -----------------------------------------
>
> 09:45 - 11:05 Diameter Overload Indication Conveyance, Jouni/Steve (80 minutes)
> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/
>
>
> + 15 mins buffer / break..
>
> Wrap-up (10 minutes)
> --------------------
> 11:20 - 11:30 Next Steps: WG Chairs & ADs (10 minutes) 
> WG Goals/Milestones status, next steps 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------040909000404070302020801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jouni,

      Lionel,

      

      I don't know if these items need to be agenda items for the
      meeting but I would like to get a sense from the working group for
      the direction we should take on agent overload (see previous
      email).  I also propose that
      draft-donovan-dime-doc-rate-control-00.txt be made a working group
      item.

      

      Steve

      

    
    
On 2/19/14 3:28 AM, Jouni Korhonen
      wrote:

    

    

      
Folks,

Slightly late as always..
http://www.ietf.org/proceedings/89/agenda/agenda-89-dime

We have reserved as much time as possible for the overload
topic.

Agenda comments/change requests asap, please.


- Jouni & Lionel

**


DIME WG IETF 89 Agenda  

Chairs:
Jouni Korhonen <jouni.korhonen at broadcom.com>
Lionel Morand@ <lionel.morand at orange.com>

Jabber room: dime at jabber.ietf.org (Please join)
THURSDAY, March 6, 2014
0900-1130  Morning Session I (150 mins)
Richmond/Chelsea/Tower

09:00 - 09:10, Preliminaries (10 minutes)
------------------------------------------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

 o draft-ietf-dime-app-design-guide-21   -> IESG
 o draft-ietf-dime-e2e-sec-req-01        -> About ready -> WGLC
 o draft-ietf-dime-group-signaling-03    -> in WG
 o draft-ietf-dime-ovli-01               -> in WG
 o draft-ietf-dime-pmip6-lr-18           -> AUTH48
 o draft-ietf-dime-rfc4005bis-14         -> AUTH48

Working group draft discussion (20 minutes)
-------------------------------------------

09:10 - 09:30 Diameter Group Signaling, Marco (20 minutes)
https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/

Chartered individual draft discussion (15 minutes)
--------------------------------------------------

09:30 - 09:45 Diameter Congestion and Filter Attributes, Brent (15 minutes)
https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attributes/

Diamater Overload discussion (80 minutes)
-----------------------------------------

09:45 - 11:05 Diameter Overload Indication Conveyance, Jouni/Steve (80 minutes)
https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/


+ 15 mins buffer / break..

Wrap-up (10 minutes)
--------------------
11:20 - 11:30 Next Steps: WG Chairs & ADs (10 minutes) 
WG Goals/Milestones status, next steps 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



    

    

  


--------------040909000404070302020801--


From nobody Fri Feb 21 09:20:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D62B1A04B3 for ; Fri, 21 Feb 2014 09:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level: 
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjuUGTDaKRhM for ; Fri, 21 Feb 2014 09:20:44 -0800 (PST)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE31A051D for ; Fri, 21 Feb 2014 09:20:10 -0800 (PST)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 6ca87035.0.5405377.00-2325.15175802.nbfkord-smmo05.seg.att.com (envelope-from );  Fri, 21 Feb 2014 17:20:07 +0000 (UTC)
X-MXL-Hash: 53078ac7278fb4e4-c69ba86ec2360f88fc2b04547d6fc62229bc2564
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LHK50Q018468; Fri, 21 Feb 2014 12:20:06 -0500
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LHJqes018149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 12:19:58 -0500
Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 21 Feb 2014 17:19:32 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 12:19:32 -0500
From: "DOLLY, MARTIN C" 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Draft agenda for IETF#89 DIME meeting
Thread-Index: AQHPLx6yoqnH2ofAn0mcmbRjMXEpYZq/81SQ
Date: Fri, 21 Feb 2014 17:19:32 +0000
Message-ID: 
References:  <5307791E.6060900@usdonovans.com>
In-Reply-To: <5307791E.6060900@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.175.80.145]
Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560259C123MISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=XGV5Eq1BtFEA:10 a=ofMgfj31e3cA:10 a=674JCT6vZqcA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=xbXZOFFDr]
X-AnalysisOut: [QkA:10 a=48vgC7mUAAAA:8 a=Q-fNiiVtAAAA:8 a=z9tbli-vAAAA:8 ]
X-AnalysisOut: [a=VuKgwOuuVv8V_OfwByIA:9 a=CjuIK1q_8ugA:10 a=cIzyYUatB-UA:]
X-AnalysisOut: [10 a=W_a9NTmGv3gA:10 a=lZB815dzVvQA:10 a=Gz3uW3Cl3td7wWlQ:]
X-AnalysisOut: [21 a=WEEjNpNx3YsrR4HV:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8]
X-AnalysisOut: [ a=ioPVD3_yAM-YuZqlEmIA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A]
X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=KJWTI-yioXs0RoaL]
X-AnalysisOut: [:21 a=V3uHDPEaay_SdgQF:21 a=pwNegZfRR2ppwliA:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qdcUWD09SuORoPuCxxPYKJHvMKo
Subject: Re: [Dime] Draft agenda for IETF#89 DIME meeting
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:20:47 -0000

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

AT&T supports the rate-control be on the agenda.

In addition, the base solution needs to take into account information neede=
d to be conveyed for a rate based control versus the default.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, February 21, 2014 11:05 AM
To: dime@ietf.org
Subject: Re: [Dime] Draft agenda for IETF#89 DIME meeting

Jouni,
Lionel,

I don't know if these items need to be agenda items for the meeting but I w=
ould like to get a sense from the working group for the direction we should=
 take on agent overload (see previous email).  I also propose that draft-do=
novan-dime-doc-rate-control-00.txt be made a working group item.

Steve
On 2/19/14 3:28 AM, Jouni Korhonen wrote:

Folks,



Slightly late as always..

http://www.ietf.org/proceedings/89/agenda/agenda-89-dime



We have reserved as much time as possible for the overload

topic.



Agenda comments/change requests asap, please.





- Jouni & Lionel



**





DIME WG IETF 89 Agenda



Chairs:

Jouni Korhonen 

Lionel Morand@ 



Jabber room: dime at jabber.ietf.org (Please join)

THURSDAY, March 6, 2014

0900-1130  Morning Session I (150 mins)

Richmond/Chelsea/Tower



09:00 - 09:10, Preliminaries (10 minutes)

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

Audio/Video & Remote Presentation Debugging

Note Well

Note Takers

Jabber scribe

Agenda bash

Document Status



 o draft-ietf-dime-app-design-guide-21   -> IESG

 o draft-ietf-dime-e2e-sec-req-01        -> About ready -> WGLC

 o draft-ietf-dime-group-signaling-03    -> in WG

 o draft-ietf-dime-ovli-01               -> in WG

 o draft-ietf-dime-pmip6-lr-18           -> AUTH48

 o draft-ietf-dime-rfc4005bis-14         -> AUTH48



Working group draft discussion (20 minutes)

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



09:10 - 09:30 Diameter Group Signaling, Marco (20 minutes)

https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/



Chartered individual draft discussion (15 minutes)

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



09:30 - 09:45 Diameter Congestion and Filter Attributes, Brent (15 minutes)

https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attribute=
s/



Diamater Overload discussion (80 minutes)

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



09:45 - 11:05 Diameter Overload Indication Conveyance, Jouni/Steve (80 minu=
tes)

https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/





+ 15 mins buffer / break..



Wrap-up (10 minutes)

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

11:20 - 11:30 Next Steps: WG Chairs & ADs (10 minutes)

WG Goals/Milestones status, next steps

_______________________________________________

DiME mailing list

DiME@ietf.org

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




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











AT&T supports the rat=
e-control be on the agenda.


 <=
/p>

In addition, the base sol=
ution needs to take into account information needed to be conveyed for a ra=
te based control versus the default.


 <=
/p>





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

Sent: Friday, February 21, 2014 11:05 AM

To: dime@ietf.org

Subject: Re: [Dime] Draft agenda for IETF#89 DIME meeting=







 


Jouni,

Lionel,



I don't know if these items need to be agenda items for the meeting but I w=
ould like to get a sense from the working group for the direction we should=
 take on agent overload (see previous email).  I also propose that dra=
ft-donovan-dime-doc-rate-control-00.txt
 be made a working group item.



Steve




On 2/19/14 3:28 AM, Jouni Korhonen wrote:=







Folks,


 


Slightly late as always..


h=
ttp://www.ietf.org/proceedings/89/agenda/agenda-89-dime

 


We have reserved as much time as possible for the overload<=
/pre>

topic.


 


Agenda comments/change requests asap, please.


 


 


- Jouni & Lionel


 


**


 


 


DIME WG IETF 89 Agenda  


 


Chairs:


Jouni Korhonen <jouni.korhonen at broadcom.com>


Lionel Morand@ <lionel.morand at orange.com>


 


Jabber room: dime at jabber.ietf.org (Please join)


THURSDAY, March 6, 2014


0900-1130  Morning Session I (150 mins)


Richmond/Chelsea/Tower


 


09:00 - 09:10, Preliminaries (10 minutes)


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


Audio/Video & Remote Presentation Debugging


Note Well


Note Takers


Jabber scribe


Agenda bash


Document Status


 


 o draft-ietf-dime-app-design-guide-21   -> IESG


 o draft-ietf-dime-e2e-sec-req-01       =
 -> About ready -> WGLC


 o draft-ietf-dime-group-signaling-03    -> in WG


 o draft-ietf-dime-ovli-01       &n=
bsp;       -> in WG


 o draft-ietf-dime-pmip6-lr-18      &nbs=
p;    -> AUTH48


 o draft-ietf-dime-rfc4005bis-14      &n=
bsp;  -> AUTH48


 


Working group draft discussion (20 minutes)


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


 


09:10 - 09:30 Diameter Group Signaling, Marco (20 minutes)<=
/pre>

https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/


 


Chartered individual draft discussion (15 minutes)


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


 


09:30 - 09:45 Diameter Congestion and Filter Attributes, Brent (15 min=
utes)


https://datatracker.ietf.org/doc/draft-bertz-dime-conge=
stion-flow-attributes/


 


Diamater Overload discussion (80 minutes)


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


 


09:45 - 11:05 Diameter Overload Indication Conveyance, Jouni/Steve (80=
 minutes)


htt=
ps://datatracker.ietf.org/doc/draft-ietf-dime-ovli/


 


 


+ 15 mins buffer / break..


 


Wrap-up (10 minutes)


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


11:20 - 11:30 Next Steps: WG Chairs & ADs (10 minutes) =



WG Goals/Milestones status, next steps 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_E42CCDDA6722744CB241677169E836560259C123MISOUT7MSGUSR9I_--


From nobody Fri Feb 21 09:21:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E450C1A04C6 for ; Fri, 21 Feb 2014 09:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_FRkIjCBg27 for ; Fri, 21 Feb 2014 09:21:35 -0800 (PST)
Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com [15.201.208.55]) by ietfa.amsl.com (Postfix) with ESMTP id ECF0C1A047E for ; Fri, 21 Feb 2014 09:21:34 -0800 (PST)
Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3427.houston.hp.com (Postfix) with ESMTPS id F3AF33ED for ; Fri, 21 Feb 2014 17:21:30 +0000 (UTC)
Received: from G9W3617.americas.hpqcorp.net (16.216.186.52) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 17:20:19 +0000
Received: from G9W0747.americas.hpqcorp.net ([169.254.4.56]) by G9W3617.americas.hpqcorp.net ([16.216.186.52]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 17:20:19 +0000
From: "Askerup, Anders" 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] #51: OC-Supported-Features in requests - conclusions
Thread-Index: AQHPLuX+sF59CaBstE+joJsbC6KYmZq/b1kAgACEbiA=
Date: Fri, 21 Feb 2014 17:20:19 +0000
Message-ID: <602542051F40544EB188D494F506C2494792FB28@G9W0747.americas.hpqcorp.net>
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.210.48.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZKwjcElg-rSnVxJwGIFwHkxhLKU
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:21:37 -0000

Is the intent that it covers both the reporting nodes and reacting nodes, i=
.e. both Client and Server supporting DOIC must include the OC-Supported-Fe=
atures AVP if they support DOIC?

/Anders =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Friday, February 21, 2014 3:23 AM
To: dime@ietf.org
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

Yes, sorry about this, this was my understanding as well but I provided a w=
rong rephrasing.
My understanding is the following conclusions is reached:

#51: OC-Supported-Features in requests

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.


-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: viernes, 21 de febrero de 2014 10:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

I do not agree
I think the conclusion was to say:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.

For OC-Supported-Features AVP in answer messages refer to issue #30.

Ulrich =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Friday, February 21, 2014 9:35 AM
To: dime@ietf.org
Subject: [Dime] #51: OC-Supported-Features in requests - conclusions

#51: OC-Supported-Features in requests
=20
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
replace SHOULD by MUST

_______________________________________________
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 Fri Feb 21 09:25:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8F81A0487 for ; Fri, 21 Feb 2014 09:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twZ5oD_0aQC3 for ; Fri, 21 Feb 2014 09:25:00 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC4E1A01EB for ; Fri, 21 Feb 2014 09:25:00 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1LHOsGo010549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Feb 2014 11:24:55 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1LHOrd9008548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 18:24:54 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 21 Feb 2014 18:24:54 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
Thread-Index: Ac8u4hyhyFipAfuqQZK1Yn82LVgN9AAL7G4AAAJgB0AAA05dsA==
Date: Fri, 21 Feb 2014 17:24:53 +0000
Message-ID: 
References: <087A34937E64E74E848732CFF8354B9209784033@ESESSMB101.ericsson.se> <530771A6.4030002@usdonovans.com> <087A34937E64E74E848732CFF8354B920978435A@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978435A@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266A213FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/G_w4H6SNQr4r7noqPlAwgyazC9A
Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:25:03 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266A213FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi MCruz

The text  you propose to remove deals with the Seq number within  OC-Suppor=
ted features, because of duplication with another text, but this other text=
 text relates to the seq number handling within the OC-OLR AVP.
I think we can keep two texts, one for the seq number  within OC-Supported =
features  and another one for  the seq number  within OC-OLR AVP,. We will =
then see how the text  for seq number  within OC-Supported features evolves=
 with the #29  outputs.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:42
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion

Steve,

Extracted text is duplicated now, this paragraph I referred is simply wrong=
.
But I agree duplicated text should be revised due to issue#29, but this is =
up to this ticket to provide the alternative text.

Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: viernes, 21 de febrero de 2014 16:33
To: dime@ietf.org
Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion

Maria Cruz,

I think we need to see the replacement text before concluding this ticket.

Steve
On 2/21/14 2:51 AM, Maria Cruz Bartolome wrote:



#53: 5.5.2 chapter typo?



Following text will be deleted:



    .........  If the OC-Supported-Features AVP

    is received for the first time for the reporting node or the OC-

    Sequence-Number AVP value is less than the previously received/

    recorded one (and is outside the valid overflow window), then either

    the sequence number is stale (e.g. an intentional or unintentional

    replay) and SHOULD be silently discarded.



 As long as, the situations that it refers are covered later in the same ch=
apter.





_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_E194C2E18676714DACA9C3A2516265D20266A213FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi MCruz


 <=
/p>

The text  you propos=
e to remove deals with the Seq number within  OC-Supported features, b=
ecause of duplication with another text, but this other text text
 relates to the seq number handling within the OC-OLR AVP.


I think we can keep two t=
exts, one for the seq number  within OC-Supported features  and a=
nother one for  the seq number  within OC-OLR AVP,. We will then =
see
 how the text  for seq number  within OC-Supported features evolv=
es with the #29  outputs.


 <=
/p>

Best regards


 <=
/p>

JJacques  


 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:42

=C0 : dime@ietf.org

Objet : Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion=







 


Steve,



 <=
/p>

Extracted text is duplica=
ted now, this paragraph I referred is simply wrong.


But I agree duplicated te=
xt should be revised due to issue#29, but this is up to this ticket to prov=
ide the alternative text.


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: viernes, 21 de febrero de 2014 16:33

To: dime@ietf.org

Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion






 


Maria Cruz,



I think we need to see the replacement text before concluding this ticket.<=
br>


Steve




On 2/21/14 2:51 AM, Maria Cruz Bartolome wrote:=







 


#53: 5.5.2 chapter typo?


 


Following text will be deleted:


 


    .........  If the OC-Supported-Features AVP


    is received for the first time for the reporting no=
de or the OC-


    Sequence-Number AVP value is less than the previous=
ly received/


    recorded one (and is outside the valid overflow win=
dow), then either


    the sequence number is stale (e.g. an intentional o=
r unintentional


    replay) and SHOULD be silently discarded.


 


 As long as, the situations that it refers are covered later in the sa=
me chapter.


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_E194C2E18676714DACA9C3A2516265D20266A213FR712WXCHMBA12z_--


From nobody Fri Feb 21 09:30:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383C91A0553 for ; Fri, 21 Feb 2014 09:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA7dXdkCm3aE for ; Fri, 21 Feb 2014 09:30:20 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8C79F1A01DC for ; Fri, 21 Feb 2014 09:30:20 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 5C6CF2DC1A2; Fri, 21 Feb 2014 18:30:16 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2D86027C0C4; Fri, 21 Feb 2014 18:30:16 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 18:30:15 +0100
From: 
To: "Askerup, Anders" , Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] #51: OC-Supported-Features in requests - conclusions
Thread-Index: AQHPLuX+hLRw+v0oi0isM3SaOUzTt5q/b1kAgACEbiCAAAMpcA==
Date: Fri, 21 Feb 2014 17:30:14 +0000
Message-ID: <21534_1393003816_53078D28_21534_757_1_6B7134B31289DC4FAF731D844122B36E4B6274@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se> <602542051F40544EB188D494F506C2494792FB28@G9W0747.americas.hpqcorp.net>
In-Reply-To: <602542051F40544EB188D494F506C2494792FB28@G9W0747.americas.hpqcorp.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BkjRVcEn3xStqR9GjKXzu9n2bj4
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:30:23 -0000

Hi Anders,

The clarification on the expected behavior of reporting node is covered in =
issue #30 :)

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Askerup, Anders
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 18:20
=C0=A0: Maria Cruz Bartolome; dime@ietf.org
Objet=A0: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

Is the intent that it covers both the reporting nodes and reacting nodes, i=
.e. both Client and Server supporting DOIC must include the OC-Supported-Fe=
atures AVP if they support DOIC?

/Anders=20=20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Friday, February 21, 2014 3:23 AM
To: dime@ietf.org
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

Yes, sorry about this, this was my understanding as well but I provided a w=
rong rephrasing.
My understanding is the following conclusions is reached:

#51: OC-Supported-Features in requests

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.


-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: viernes, 21 de febrero de 2014 10:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

I do not agree
I think the conclusion was to say:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.

For OC-Supported-Features AVP in answer messages refer to issue #30.

Ulrich=20=20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Friday, February 21, 2014 9:35 AM
To: dime@ietf.org
Subject: [Dime] #51: OC-Supported-Features in requests - conclusions

#51: OC-Supported-Features in requests
=20
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
replace SHOULD by MUST

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 21 09:30:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7B31A0552 for ; Fri, 21 Feb 2014 09:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wnJ2cfXlIuo for ; Fri, 21 Feb 2014 09:30:32 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 57D251A0204 for ; Fri, 21 Feb 2014 09:30:32 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 799DB2AC4AB; Fri, 21 Feb 2014 18:30:27 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 511461580D8; Fri, 21 Feb 2014 18:30:27 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 18:30:26 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] #51: OC-Supported-Features in requests - conclusions
Thread-Index: AQHPLxZ1hLRw+v0oi0isM3SaOUzTt5q/9wOQ
Date: Fri, 21 Feb 2014 17:30:26 +0000
Message-ID: <16056_1393003827_53078D33_16056_14282_1_6B7134B31289DC4FAF731D844122B36E4B6282@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se> <53076B57.90607@usdonovans.com>
In-Reply-To: <53076B57.90607@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4B6282PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.21.102115
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/I7XSCgBt0NXdwFHgcyenSCAaalA
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:30:37 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4B6282PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:06
=C0 : dime@ietf.org
Objet : Re: [Dime] #51: OC-Supported-Features in requests - conclusions

+1
On 2/21/14 3:23 AM, Maria Cruz Bartolome wrote:

Yes, sorry about this, this was my understanding as well but I provided a w=
rong rephrasing.

My understanding is the following conclusions is reached:



#51: OC-Supported-Features in requests



 Now:

 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).



Proposal:

The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.





-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: viernes, 21 de febrero de 2014 10:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions



I do not agree

I think the conclusion was to say:

The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.



For OC-Supported-Features AVP in answer messages refer to issue #30.



Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Friday, February 21, 2014 9:35 AM

To: dime@ietf.org

Subject: [Dime] #51: OC-Supported-Features in requests - conclusions



#51: OC-Supported-Features in requests



My understanding is the following conclusions is reached:



 Now:

 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).



Proposal:

replace SHOULD by MUST



_______________________________________________

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4B6282PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











+1<=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:06

=C0 : dime@ietf.org

Objet : Re: [Dime] #51: OC-Supported-Features in requests - con=
clusions






 


+1




On 2/21/14 3:23 AM, Maria Cruz Bartolome wrote:=







Yes, sorry about this, this was my understanding as well but I provide=
d a wrong rephrasing.


My understanding is the following conclusions is reached:

 


#51: OC-Supported-Features in requests


 


 Now:


 The OC-Supported-Features AVP SHOULD be included into every Diameter&=
nbsp; message a DOIC  supporting node sends (and intends to use for DO=
IC purposes).


 


Proposal:


The OC-Supported-Features AVP MUST be included into every Diameter req=
uest message a DOIC supporting node sends.


 


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: viernes, 21 de febrero de 2014 10:19


To: Maria Cruz Bartolome; dime@ietf.o=
rg


Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusio=
ns


 


I do not agree


I think the conclusion was to say:


The OC-Supported-Features AVP MUST be included into every Diameter req=
uest message a DOIC supporting node sends.


 


For OC-Supported-Features AVP in answer messages refer to issue #30.


 


Ulrich  


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Friday, February 21, 2014 9:35 AM


To: dime@ietf.org


Subject: [Dime] #51: OC-Supported-Features in requests - conclusions


 


#51: OC-Supported-Features in requests


 


My understanding is the following conclusions is reached:

 


 Now:


 The OC-Supported-Features AVP SHOULD be included into every Diameter&=
nbsp; message a DOIC  supporting node sends (and intends to use for DO=
IC purposes).


 


Proposal:


replace SHOULD by MUST


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4B6282PEXCVZYM13corpora_--


From nobody Fri Feb 21 09:33:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69E51A0555 for ; Fri, 21 Feb 2014 09:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoBZVOyenbXb for ; Fri, 21 Feb 2014 09:33:20 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB61A01DC for ; Fri, 21 Feb 2014 09:33:20 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id BBE193B4256; Fri, 21 Feb 2014 18:33:15 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 990541580C3; Fri, 21 Feb 2014 18:33:15 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 18:33:15 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: AQHPLxrE9U7pejS/tE+Q/EgvGuCjI5q/97eA
Date: Fri, 21 Feb 2014 17:33:14 +0000
Message-ID: <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com>
In-Reply-To: <53077290.8080501@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4B629FPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.21.102115
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Kuk5p1P0xS8lMJset0eMM9IoO0Y
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:33:24 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4B629FPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1 (including Steve comment)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

Maria Cruz,

I support your suggested changes.  I have one further suggested change belo=
w.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:

#52: Throttling not needed to be based on previous history



Following agreement is reached:



 Now (chapter 4.7):

    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

    and describes the percentage of the traffic that the sender is

    requested to reduce, compared to what it otherwise would have sent.



 Proposal:

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would send.          =
        <----





 Now (chapter 5.5.2):

      Indicates that the reporting node urges the reacting node to

      reduce its traffic by a given percentage.  For example if the

      reacting node has been sending 100 packets per second to the

      reporting node, then a reception of OC-Reduction-Percentage value

      of 10 would mean that from now on the reacting node MUST only send

      90 packets per second.  How the reacting node achieves the "true

      reduction" transactions leading to the sent request messages is up

      to the implementation.  The reacting node MAY simply drop every

      10th packet from its output queue and let the generic application

      logic try to recover from it.0 < value < 100



  Proposal:

 Indicates that the reporting node urges the reacting node to reduce

 its traffic by a given percentage. For example if the

 reacting node would send 100 packets to the                          <---

 reporting node, then a reception of OC-Reduction-Percentage value of

 10 would mean that from now on the reacting node MUST only send

 90 packets instead of 100. How the reacting node achieves the "true       =
<---

 reduction" transactions leading to the sent request messages is up to

 the implementation. The reacting node MAY simply drop every 10th

 packet from its output queue and let the generic application logic try

 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"






_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4B629FPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











+1 (including Steve c=
omment)


 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


Maria Cruz,



I support your suggested changes.  I have one further suggested change=
 below.



Steve




On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:=







#52: Throttling not needed to be based on previous history<=
/pre>

 


Following agreement is reached:


 


 Now (chapter 4.7):


    The OC-Reduction-Percentage AVP (AVP code TBD8) is =
type of Unsigned32


    and describes the percentage of the traffic that th=
e sender is


    requested to reduce, compared to what it otherwise =
would have sent.


 


 Proposal:


   The OC-Reduction-Percentage AVP (AVP code TBD8) is type o=
f Unsigned32  


   and describes the percentage of the traffic that the=
 sender is  


   requested to reduce, compared to what it otherwise w=
ould send.           =
;       <----


 


 


 Now (chapter 5.5.2):


      Indicates that the reporting node urges=
 the reacting node to


      reduce its traffic by a given percentag=
e.  For example if the


      reacting node has been sending 100 pack=
ets per second to the


      reporting node, then a reception of OC-=
Reduction-Percentage value


      of 10 would mean that from now on the r=
eacting node MUST only send


      90 packets per second.  How the re=
acting node achieves the "true


      reduction" transactions leading to=
 the sent request messages is up


      to the implementation.  The reacti=
ng node MAY simply drop every


      10th packet from its output queue and l=
et the generic application


      logic try to recover from it.0 < val=
ue < 100


 


  Proposal:


 Indicates that the reporting node urges the reacting node to reduce <=
o:p>


 its traffic by a given percentage. For example if the=



 reacting node would send 100 packets to the    &n=
bsp;            =
;         <---


 reporting node, then a reception of OC-Reduction-Percentage value of =



 10 would mean that from now on the reacting node MUST only send<=
o:p>


 90 packets instead of 100. How the reacting node achieves the "t=
rue       <---


 reduction" transactions leading to the sent request messages is =
up to 


 the implementation. The reacting node MAY simply drop every 10th=
 


 packet from its output queue and let the generic application log=
ic try 


 to recover from it.




SRD> Replace "from now on" in the above=
 with "for the period that the overload report is active"






 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4B629FPEXCVZYM13corpora_--


From nobody Fri Feb 21 09:33:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C6A1A0554 for ; Fri, 21 Feb 2014 09:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level: 
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf49Aq-bgEpv for ; Fri, 21 Feb 2014 09:33:23 -0800 (PST)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF111A0553 for ; Fri, 21 Feb 2014 09:33:22 -0800 (PST)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id edd87035.0.5415544.00-2177.15204563.nbfkord-smmo05.seg.att.com (envelope-from );  Fri, 21 Feb 2014 17:33:18 +0000 (UTC)
X-MXL-Hash: 53078dde1814ad6b-f401320fd0cdda3e04c8345f62689d9b7bb5b035
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LHXHh0005090; Fri, 21 Feb 2014 12:33:18 -0500
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LHX7BK004775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 12:33:12 -0500
Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 21 Feb 2014 17:32:50 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 12:32:50 -0500
From: "DOLLY, MARTIN C" 
To: "lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] #51: OC-Supported-Features in requests - conclusions
Thread-Index: AQHPLxZ1hLRw+v0oi0isM3SaOUzTt5q/9wOQgAAAnYA=
Date: Fri, 21 Feb 2014 17:32:49 +0000
Message-ID: 
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se> <53076B57.90607@usdonovans.com> <16056_1393003827_53078D33_16056_14282_1_6B7134B31289DC4FAF731D844122B36E4B6282@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <16056_1393003827_53078D33_16056_14282_1_6B7134B31289DC4FAF731D844122B36E4B6282@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.175.80.145]
Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560259C406MISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=rfGoQfdUtSUA:10 a=ofMgfj31e3cA:10 a=674JCT6vZqcA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=lARpexBee]
X-AnalysisOut: [C0A:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=02K0Y2VpAAAA:8 ]
X-AnalysisOut: [a=YrZSAqJbcsq49oSL0I0A:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:]
X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=zwC7bnKO5xoA:10 a=i3UpFkP1DebNM5VB:]
X-AnalysisOut: [21 a=T0OeDJk0nKZKFJSe:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8]
X-AnalysisOut: [ a=cw8pqW1q8k_GDMI4vV8A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A]
X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=Eg51EOiEwA6I40cC]
X-AnalysisOut: [:21 a=R-Woa8sNJoIHZLB5:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6GVIqc91gkUVQm_UXQm6cNHGCNE
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:33:26 -0000

--_000_E42CCDDA6722744CB241677169E836560259C406MISOUT7MSGUSR9I_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My understanding as well

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange=
.com
Sent: Friday, February 21, 2014 12:30 PM
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

+1

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:06
=C0 : dime@ietf.org
Objet : Re: [Dime] #51: OC-Supported-Features in requests - conclusions

+1
On 2/21/14 3:23 AM, Maria Cruz Bartolome wrote:

Yes, sorry about this, this was my understanding as well but I provided a w=
rong rephrasing.

My understanding is the following conclusions is reached:



#51: OC-Supported-Features in requests



 Now:

 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).



Proposal:

The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.





-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: viernes, 21 de febrero de 2014 10:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions



I do not agree

I think the conclusion was to say:

The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.



For OC-Supported-Features AVP in answer messages refer to issue #30.



Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Friday, February 21, 2014 9:35 AM

To: dime@ietf.org

Subject: [Dime] #51: OC-Supported-Features in requests - conclusions



#51: OC-Supported-Features in requests



My understanding is the following conclusions is reached:



 Now:

 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).



Proposal:

replace SHOULD by MUST



_______________________________________________

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




___________________________________________________________________________=
______________________________________________



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_E42CCDDA6722744CB241677169E836560259C406MISOUT7MSGUSR9I_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











My understanding as well<=
o:p>


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of lionel.morand@orange.com

Sent: Friday, February 21, 2014 12:30 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclus=
ions






 


+1=



 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:06

=C0 : dime@ietf.org

Objet : Re: [Dime] #51: OC-Supported-Features in requests - con=
clusions






 


+1




On 2/21/14 3:23 AM, Maria Cruz Bar=
tolome wrote:






Yes, sorry about this, this was my understanding as =
well but I provided a wrong rephrasing.


My understanding is the following conclusions is rea=
ched:


 


#51: OC-Supported-Features in requests


 


 Now:


 The OC-Supported-Features AVP SHOULD be included in=
to every Diameter  message a DOIC  supporting node sends (and int=
ends to use for DOIC purposes).


 


Proposal:


The OC-Supported-Features AVP MUST be included into =
every Diameter request message a DOIC supporting node sends.


 


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: viernes, 21 de febrero de 2014 10:19


To: Maria Cruz Bartolome; dime@ietf.org


Subject: RE: [Dime] #51: OC-Supported-Features in re=
quests - conclusions


 


I do not agree


I think the conclusion was to say:=



The OC-Supported-Features AVP MUST be included into =
every Diameter request message a DOIC supporting node sends.


 


For OC-Supported-Features AVP in answer messages ref=
er to issue #30.


 


Ulrich  


 


-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Friday, February 21, 2014 9:35 AM


To: dime@ietf.org


Subject: [Dime] #51: OC-Supported-Features in reques=
ts - conclusions


 


#51: OC-Supported-Features in requests


 


My understanding is the following conclusions is rea=
ched:


 


 Now:


 The OC-Supported-Features AVP SHOULD be included in=
to every Diameter  message a DOIC  supporting node sends (and int=
ends to use for DOIC purposes).


 


Proposal:


replace SHOULD by MUST


 


_______________________________________________=



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


 




 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_E42CCDDA6722744CB241677169E836560259C406MISOUT7MSGUSR9I_--


From nobody Fri Feb 21 09:50:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B791A019C for ; Fri, 21 Feb 2014 09:50:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwrQJoFuNtXE for ; Fri, 21 Feb 2014 09:50:48 -0800 (PST)
Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com [15.201.208.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0531A01E4 for ; Fri, 21 Feb 2014 09:50:48 -0800 (PST)
Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3427.houston.hp.com (Postfix) with ESMTPS id 6C48533D; Fri, 21 Feb 2014 17:50:44 +0000 (UTC)
Received: from G9W3615.americas.hpqcorp.net (16.216.186.50) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 17:49:17 +0000
Received: from G9W0747.americas.hpqcorp.net ([169.254.4.56]) by G9W3615.americas.hpqcorp.net ([16.216.186.50]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 17:49:17 +0000
From: "Askerup, Anders" 
To: "lionel.morand@orange.com" , "Maria Cruz Bartolome" , "dime@ietf.org" 
Thread-Topic: [Dime] #51: OC-Supported-Features in requests - conclusions
Thread-Index: AQHPLuX+sF59CaBstE+joJsbC6KYmZq/b1kAgACEbiCAAAOVAIAABLZA
Date: Fri, 21 Feb 2014 17:49:16 +0000
Message-ID: <602542051F40544EB188D494F506C2494792FBAD@G9W0747.americas.hpqcorp.net>
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se> <602542051F40544EB188D494F506C2494792FB28@G9W0747.americas.hpqcorp.net> <21534_1393003816_53078D28_21534_757_1_6B7134B31289DC4FAF731D844122B36E4B6274@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <21534_1393003816_53078D28_21534_757_1_6B7134B31289DC4FAF731D844122B36E4B6274@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.210.48.37]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NZJV7JawteRGKaVI_v8bxDmiGmE
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:50:51 -0000

Lionel,

but issue #30 is about the Answer message isn't? My question is if a Server=
 sending a Request message must it include the OC-Supported-Features AVP or=
 not?

/Anders

-----Original Message-----
From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Sent: Friday, February 21, 2014 11:30 AM
To: Askerup, Anders; Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

Hi Anders,

The clarification on the expected behavior of reporting node is covered in =
issue #30 :)

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Askerup, Anders
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 18:20
=C0=A0: Maria Cruz Bartolome; dime@ietf.org
Objet=A0: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

Is the intent that it covers both the reporting nodes and reacting nodes, i=
.e. both Client and Server supporting DOIC must include the OC-Supported-Fe=
atures AVP if they support DOIC?

/Anders =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Friday, February 21, 2014 3:23 AM
To: dime@ietf.org
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

Yes, sorry about this, this was my understanding as well but I provided a w=
rong rephrasing.
My understanding is the following conclusions is reached:

#51: OC-Supported-Features in requests

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.


-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: viernes, 21 de febrero de 2014 10:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

I do not agree
I think the conclusion was to say:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.

For OC-Supported-Features AVP in answer messages refer to issue #30.

Ulrich =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Friday, February 21, 2014 9:35 AM
To: dime@ietf.org
Subject: [Dime] #51: OC-Supported-Features in requests - conclusions

#51: OC-Supported-Features in requests
=20
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
replace SHOULD by MUST

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 21 10:11:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839801A0559 for ; Fri, 21 Feb 2014 10:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-PkHK6rOAtt for ; Fri, 21 Feb 2014 10:11:12 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3039B1A0204 for ; Fri, 21 Feb 2014 10:11:12 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1LIB6c6013228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Feb 2014 12:11:07 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1LIB6lN023975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 19:11:06 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 21 Feb 2014 19:11:06 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAA==
Date: Fri, 21 Feb 2014 18:11:05 +0000
Message-ID: 
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.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: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266A27DFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LIvm0Fqp2dq3ebtoL23FFebke-c
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 18:11:19 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266A27DFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi MCruz, Steve

I also agree on the "would send " instead of the "would have sent"  for sur=
e.  But I have  a small concern/ clarification  about the Steve comment on =
  "for the period that the overload report is active" and the example to wh=
ich it refers.

During the time the OLR is active, which may be rather long,  the traffic t=
he reacting node would send may be 100 packet  when it has just received th=
e OLR. A bit later, the traffic it would send could be 120 (or 80), and fro=
m the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  whi=
ch I agree. This is in line  with the every 10th packet dropping  on which =
I also agree.

As the text   would  be written with the Steve modification , we may unders=
tand it is  80 Packet during all the time  the OLR is active. Not yet think=
 to an alternative text, but first to see if you agree with my remark.

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com
Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33
=C0 : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

+1 (including Steve comment)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

Maria Cruz,

I support your suggested changes.  I have one further suggested change belo=
w.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:

#52: Throttling not needed to be based on previous history



Following agreement is reached:



 Now (chapter 4.7):

    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

    and describes the percentage of the traffic that the sender is

    requested to reduce, compared to what it otherwise would have sent.



 Proposal:

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would send.          =
        <----





 Now (chapter 5.5.2):

      Indicates that the reporting node urges the reacting node to

      reduce its traffic by a given percentage.  For example if the

      reacting node has been sending 100 packets per second to the

      reporting node, then a reception of OC-Reduction-Percentage value

      of 10 would mean that from now on the reacting node MUST only send

      90 packets per second.  How the reacting node achieves the "true

      reduction" transactions leading to the sent request messages is up

      to the implementation.  The reacting node MAY simply drop every

      10th packet from its output queue and let the generic application

      logic try to recover from it.0 < value < 100



  Proposal:

 Indicates that the reporting node urges the reacting node to reduce

 its traffic by a given percentage. For example if the

 reacting node would send 100 packets to the                          <---

 reporting node, then a reception of OC-Reduction-Percentage value of

 10 would mean that from now on the reacting node MUST only send

 90 packets instead of 100. How the reacting node achieves the "true       =
<---

 reduction" transactions leading to the sent request messages is up to

 the implementation. The reacting node MAY simply drop every 10th

 packet from its output queue and let the generic application logic try

 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"







_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________



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_E194C2E18676714DACA9C3A2516265D20266A27DFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi MCruz, Steve


 <=
/p>

I also agree on the ̶=
0;would send ” instead of the “would have sent”  for=
 sure.  But I have  a small concern/ clarification  about th=
e Steve comment on   “for
 the period that the overload report is active” 
and the example to which it refers.


 


During the time the OLR i=
s active, which may be rather long,  the traffic the reacting node wou=
ld send may be 100 packet  when it has just received the OLR.
 A bit later, the traffic it would send could be 120 (or 80), and from the =
OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on&=
nbsp; which I agree. This is in line  with the every 10th packet dropp=
ing  on which I also agree.



  


As the text   w=
ould  be written with the Steve modification , we may understand it is=
  80 Packet during all the time  the OLR is active. Not yet think=
 to an
 alternative text, but first to see if you agree with my remark.=



 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de lionel.morand@orange.com

Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33

=C0 : Steve Donovan; dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


+1 (inclu=
ding Steve comment)


 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


Mar=
ia Cruz,



I support your suggested changes.  I have one further suggested change=
 below.



Steve




On 2/21/14 2:40 AM, Maria Cruz Bar=
tolome wrote:






#52: Throttling not needed to be based on previous h=
istory


 


Following agreement is reached:

 


 Now (chapter 4.7):


    The OC-Reduction-Percentage AVP (=
AVP code TBD8) is type of Unsigned32


    and describes the percentage of t=
he traffic that the sender is


    requested to reduce, compared to =
what it otherwise would have sent.


 


 Proposal:


   The OC-Reduction-Percentage AVP (AVP co=
de TBD8) is type of Unsigned32  


   and describes the percentage of th=
e traffic that the sender is  


   requested to reduce, compared to w=
hat it otherwise would send.        =
;          <----=



 


 


 Now (chapter 5.5.2):


      Indicates that the re=
porting node urges the reacting node to


      reduce its traffic by=
 a given percentage.  For example if the


      reacting node has bee=
n sending 100 packets per second to the


      reporting node, then =
a reception of OC-Reduction-Percentage value


      of 10 would mean that=
 from now on the reacting node MUST only send


      90 packets per second=
.  How the reacting node achieves the "true

      reduction" trans=
actions leading to the sent request messages is up


      to the implementation=
.  The reacting node MAY simply drop every


      10th packet from its =
output queue and let the generic application


      logic try to recover =
from it.0 < value < 100


 


  Proposal:


 Indicates that the reporting node urges the reactin=
g node to reduce 


 its traffic by a given percentage. For example=
 if the


 reacting node would send 100 packets to the &n=
bsp;            =
;            <---=



 reporting node, then a reception of OC-Reduction-Pe=
rcentage value of 


 10 would mean that from now on the reacting no=
de MUST only send


 90 packets instead of 100. How the reacting node ac=
hieves the "true       <---


 reduction" transactions leading to the sent re=
quest messages is up to 


 the implementation. The reacting node MAY simp=
ly drop every 10th 


 packet from its output queue and let the gener=
ic application logic try 


 to recover from it.




SRD> Replace "from now on&=
quot; in the above with "for the period that the overload report is ac=
tive"








 


 


_______________________________________________=



DiME mailing list


DiME@ietf.org


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


 


 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_E194C2E18676714DACA9C3A2516265D20266A27DFR712WXCHMBA12z_--


From nobody Fri Feb 21 10:14:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D449A1A0260; Fri, 21 Feb 2014 10:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Meoyfx6xqfMt; Fri, 21 Feb 2014 10:14:31 -0800 (PST)
Received: from mail210.messagelabs.com (mail210.messagelabs.com [216.82.250.179]) by ietfa.amsl.com (Postfix) with ESMTP id 300131A0565; Fri, 21 Feb 2014 10:14:29 -0800 (PST)
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-11.tower-210.messagelabs.com!1393006457!7735977!1
X-Originating-IP: [20.137.2.87]
X-StarScan-Received: 
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18898 invoked from network); 21 Feb 2014 18:14:19 -0000
Received: from amer-mta101.csc.com (HELO amer-mta111.csc.com) (20.137.2.87) by server-11.tower-210.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  21 Feb 2014 18:14:19 -0000
Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta111.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s1LIEGiv014179; Fri, 21 Feb 2014 13:14:16 -0500
In-Reply-To: 
References:  <5307791E.6060900@usdonovans.com> 
To: "DOLLY, MARTIN C" 
MIME-Version: 1.0
X-KeepSent: 73149D97:8BB1D0BC-85257C86:00641465; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012
From: Janet P Gunn 
Message-ID: 
Date: Fri, 21 Feb 2014 13:14:15 -0500
X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 02/21/2014 01:14:15 PM, Serialize complete at 02/21/2014 01:14:15 PM
Content-Type: multipart/alternative; boundary="=_alternative 00642E1485257C86_="
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dTy5jcMLYKwkwOHpi9AWA8qqNO4
Cc: DiME , "dime@ietf.org" 
Subject: Re: [Dime] Draft agenda for IETF#89 DIME meeting
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 18:14:35 -0000

This is a multipart message in MIME format.
--=_alternative 00642E1485257C86_=
Content-Type: text/plain; charset="US-ASCII"

I also support addressing rate-control, and including the rate-related 
parameters in the base solution.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.



From:   "DOLLY, MARTIN C" 
To:     Steve Donovan , "dime@ietf.org" 

Date:   02/21/2014 12:21 PM
Subject:        Re: [Dime] Draft agenda for IETF#89 DIME meeting
Sent by:        "DiME" 



AT&T supports the rate-control be on the agenda.
 
In addition, the base solution needs to take into account information 
needed to be conveyed for a rate based control versus the default.
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, February 21, 2014 11:05 AM
To: dime@ietf.org
Subject: Re: [Dime] Draft agenda for IETF#89 DIME meeting
 
Jouni,
Lionel,

I don't know if these items need to be agenda items for the meeting but I 
would like to get a sense from the working group for the direction we 
should take on agent overload (see previous email).  I also propose that 
draft-donovan-dime-doc-rate-control-00.txt be made a working group item.

Steve
On 2/19/14 3:28 AM, Jouni Korhonen wrote:
Folks,
 
Slightly late as always..
http://www.ietf.org/proceedings/89/agenda/agenda-89-dime
 
We have reserved as much time as possible for the overload
topic.
 
Agenda comments/change requests asap, please.
 
 
- Jouni & Lionel
 
**
 
 
DIME WG IETF 89 Agenda 
 
Chairs:
Jouni Korhonen 
Lionel Morand@ 
 
Jabber room: dime at jabber.ietf.org (Please join)
THURSDAY, March 6, 2014
0900-1130  Morning Session I (150 mins)
Richmond/Chelsea/Tower
 
09:00 - 09:10, Preliminaries (10 minutes)
------------------------------------------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status
 
 o draft-ietf-dime-app-design-guide-21   -> IESG
 o draft-ietf-dime-e2e-sec-req-01        -> About ready -> WGLC
 o draft-ietf-dime-group-signaling-03    -> in WG
 o draft-ietf-dime-ovli-01               -> in WG
 o draft-ietf-dime-pmip6-lr-18           -> AUTH48
 o draft-ietf-dime-rfc4005bis-14         -> AUTH48
 
Working group draft discussion (20 minutes)
-------------------------------------------
 
09:10 - 09:30 Diameter Group Signaling, Marco (20 minutes)
https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/
 
Chartered individual draft discussion (15 minutes)
--------------------------------------------------
 
09:30 - 09:45 Diameter Congestion and Filter Attributes, Brent (15 
minutes)
https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attributes/
 
Diamater Overload discussion (80 minutes)
-----------------------------------------
 
09:45 - 11:05 Diameter Overload Indication Conveyance, Jouni/Steve (80 
minutes)
https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/
 
 
+ 15 mins buffer / break..
 
Wrap-up (10 minutes)
--------------------
11:20 - 11:30 Next Steps: WG Chairs & ADs (10 minutes) 
WG Goals/Milestones status, next steps 
_______________________________________________
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


--=_alternative 00642E1485257C86_=
Content-Type: text/html; charset="US-ASCII"

I also support addressing rate-control,
and including the rate-related parameters in the base solution.



Janet



This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.







From:      
 "DOLLY, MARTIN
C" <md3135@att.com>

To:      
 Steve Donovan <srdonovan@usdonovans.com>,
"dime@ietf.org" <dime@ietf.org>

Date:      
 02/21/2014 12:21 PM

Subject:    
   Re: [Dime] Draft
agenda for IETF#89 DIME meeting

Sent by:    
   "DiME"
<dime-bounces@ietf.org>









AT&T supports the rate-control
be on the agenda.

 

In addition, the base solution
needs to take into account information needed to be conveyed for a rate
based control versus the default.

 

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

Sent: Friday, February 21, 2014 11:05 AM

To: dime@ietf.org

Subject: Re: [Dime] Draft agenda for IETF#89 DIME meeting

 

Jouni,

Lionel,



I don't know if these items need to be agenda items for the meeting but
I would like to get a sense from the working group for the direction we
should take on agent overload (see previous email).  I also propose
that draft-donovan-dime-doc-rate-control-00.txt be made a working group
item.



Steve

On 2/19/14 3:28 AM, Jouni Korhonen
wrote:

Folks,

 

Slightly late as always..

http://www.ietf.org/proceedings/89/agenda/agenda-89-dime

 

We have reserved as much time as possible
for the overload

topic.

 

Agenda comments/change requests asap,
please.

 

 

- Jouni & Lionel

 

**

 

 

DIME WG IETF 89 Agenda  

 

Chairs:

Jouni Korhonen <jouni.korhonen at
broadcom.com>

Lionel Morand@ <lionel.morand at
orange.com>

 

Jabber room: dime at jabber.ietf.org
(Please join)

THURSDAY, March 6, 2014

0900-1130  Morning Session I (150
mins)

Richmond/Chelsea/Tower

 

09:00 - 09:10, Preliminaries (10 minutes)

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

Audio/Video & Remote Presentation
Debugging

Note Well

Note Takers

Jabber scribe

Agenda bash

Document Status

 

 o draft-ietf-dime-app-design-guide-21
  -> IESG

 o draft-ietf-dime-e2e-sec-req-01
       -> About ready -> WGLC

 o draft-ietf-dime-group-signaling-03
   -> in WG

 o draft-ietf-dime-ovli-01  
            -> in WG

 o draft-ietf-dime-pmip6-lr-18
          -> AUTH48

 o draft-ietf-dime-rfc4005bis-14
        -> AUTH48

 

Working group draft discussion (20
minutes)

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

 

09:10 - 09:30 Diameter Group Signaling,
Marco (20 minutes)

https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/

 

Chartered individual draft discussion
(15 minutes)

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

 

09:30 - 09:45 Diameter Congestion and
Filter Attributes, Brent (15 minutes)

https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attributes/

 

Diamater Overload discussion (80 minutes)

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

 

09:45 - 11:05 Diameter Overload Indication
Conveyance, Jouni/Steve (80 minutes)

https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/

 

 

+ 15 mins buffer / break..

 

Wrap-up (10 minutes)

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

11:20 - 11:30 Next Steps: WG Chairs
& ADs (10 minutes) 

WG Goals/Milestones status, next steps


_______________________________________________

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




--=_alternative 00642E1485257C86_=--


From nobody Fri Feb 21 10:27:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D1C1A0533 for ; Fri, 21 Feb 2014 10:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FS0jFThwvf7 for ; Fri, 21 Feb 2014 10:27:51 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC231A0245 for ; Fri, 21 Feb 2014 10:27:51 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 21B66264215; Fri, 21 Feb 2014 19:27:47 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 06FBE2380D8; Fri, 21 Feb 2014 19:27:47 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 19:27:46 +0100
From: 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAAABKP8w
Date: Fri, 21 Feb 2014 18:27:45 +0000
Message-ID: <31567_1393007267_53079AA3_31567_6121_1_6B7134B31289DC4FAF731D844122B36E4B64E8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.21.151218
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/f8AUCKIHVzwkwf99_Bq0KdnM9AA
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 18:27:54 -0000

Hi JJ,

I think that the condition here is "if the reacting node would send 100 pac=
kets, 90 is sent" and this is true as long as the OLR is valid, right?

Or did I miss something in your question?

Lionel


De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 19:11
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] #52: Throttling not needed to be based on previous his=
tory - conclusion

Hi MCruz, Steve
=A0
I also agree on the "would send " instead of the "would have sent" =A0for s=
ure. =A0But I have =A0a small concern/ clarification =A0about the Steve com=
ment on =A0=A0"for the period that the overload report is active" and the e=
xample to which it refers.
=A0
During the time the OLR is active, which may be rather long, =A0the traffic=
 the reacting node would send may be 100 packet =A0when it has just receive=
d the OLR. A bit later, the traffic it would send could be 120 (or 80), and=
 from the OLR definition, =A0=A0it would send 120x0,9 (or 80* 0,9) packets,=
 on=A0 which I agree. This is in line =A0with the every 10th packet droppin=
g =A0on which I also agree.=20
=A0=A0
As the text =A0=A0would =A0be written with the Steve modification , we may =
understand it is =A080 Packet during all the time =A0the OLR is active. Not=
 yet think to an alternative text, but first to see if you agree with my re=
mark.
=A0
JJacques=20
=A0
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 18:33
=C0=A0: Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] #52: Throttling not needed to be based on previous his=
tory - conclusion
=A0
+1 (including Steve comment)
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 16:37
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] #52: Throttling not needed to be based on previous his=
tory - conclusion
=A0
Maria Cruz,

I support your suggested changes.=A0 I have one further suggested change be=
low.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history
=20
Following agreement is reached:
=A0
 Now (chapter 4.7):
=A0=A0=A0 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsign=
ed32
=A0=A0=A0 and describes the percentage of the traffic that the sender is
=A0=A0=A0 requested to reduce, compared to what it otherwise would have sen=
t.
=20
=A0Proposal:
=A0=A0 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned3=
2=A0=20
=A0=A0=A0and describes the percentage of the traffic that the sender is=A0=
=20
=A0=A0=A0requested to reduce, compared to what it otherwise would send.=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <----
=20
=A0
=A0Now (chapter 5.5.2):
=A0=A0=A0=A0=A0 Indicates that the reporting node urges the reacting node to
=A0=A0=A0=A0=A0 reduce its traffic by a given percentage.=A0 For example if=
 the
=A0=A0=A0=A0=A0 reacting node has been sending 100 packets per second to the
=A0=A0=A0=A0=A0 reporting node, then a reception of OC-Reduction-Percentage=
 value
 =A0=A0=A0=A0=A0of 10 would mean that from now on the reacting node MUST on=
ly send
=A0=A0=A0=A0=A0 90 packets per second.=A0 How the reacting node achieves th=
e "true
=A0=A0=A0=A0=A0 reduction" transactions leading to the sent request message=
s is up
=A0=A0=A0=A0=A0 to the implementation.=A0 The reacting node MAY simply drop=
 every
=A0=A0=A0=A0=A0 10th packet from its output queue and let the generic appli=
cation
=A0=A0=A0=A0=A0 logic try to recover from it.0 < value < 100
=A0
=A0 Proposal:
 Indicates that the reporting node urges the reacting node to reduce=20
=A0its traffic by a given percentage. For example if the
 reacting node would send 100 packets to the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <---
 reporting node, then a reception of OC-Reduction-Percentage value of=20
=A010 would mean that from now on the reacting node MUST only send
 90 packets instead of 100. How the reacting node achieves the "true=A0=A0=
=A0=A0=A0=A0 <---
 reduction" transactions leading to the sent request messages is up to=20
=A0the implementation. The reacting node MAY simply drop every 10th=20
=A0packet from its output queue and let the generic application logic try=
=20
=A0to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"



=A0
=A0
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
=A0
=A0
___________________________________________________________________________=
______________________________________________
=A0
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.
=A0
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.


From nobody Fri Feb 21 10:56:47 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBBC1A00CA for ; Fri, 21 Feb 2014 10:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSQcRt6zEk-6 for ; Fri, 21 Feb 2014 10:56:43 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 277911A022A for ; Fri, 21 Feb 2014 10:56:42 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1LIublm020961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Feb 2014 12:56:38 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1LIuaB2012821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 19:56:36 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 21 Feb 2014 19:56:36 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAAABKP8wAACF6rA=
Date: Fri, 21 Feb 2014 18:56:36 +0000
Message-ID: 
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <31567_1393007267_53079AA3_31567_6121_1_6B7134B31289DC4FAF731D844122B36E4B64E8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <31567_1393007267_53079AA3_31567_6121_1_6B7134B31289DC4FAF731D844122B36E4B64E8@PEXCVZYM13.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: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7VmvpuWsuKD788Gurt1eqELR-74
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 18:56:46 -0000

Hi Lionel

The proposed text would be now: =20
"For example if the  reacting node would send 100 packets to the reporting =
node, then a reception of OC-Reduction-Percentage value of 10 would mean th=
at, for the period that the overload report is active on, the reacting node=
 MUST only send  90 packets instead of 100"

I do not feel comfortable with this wording. The reacting node does not kno=
w the period for which  the overload report is active, as it may at any tim=
e receive  another OLR overriding the previous one. The new reading means 9=
0 packets for a period we don't k now.  The existing text was mentioning pa=
cket/seconds, that Mcruz wanted also to avoid as it could   have been under=
stood that 10 packet are removed for each period of one second, which is no=
t fully accurate,  if I remember well.

Best regards

JJacques=20


=20
-----Message d'origine-----
De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 19:28
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet=A0: RE: [Dime] #52: Throttling not needed to be based on previous his=
tory - conclusion

Hi JJ,

I think that the condition here is "if the reacting node would send 100 pac=
kets, 90 is sent" and this is true as long as the OLR is valid, right?

Or did I miss something in your question?

Lionel


De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9=A0: vendredi 21 f=E9vrier 2014 19:11 =C0=A0: di=
me@ietf.org Objet=A0: Re: [Dime] #52: Throttling not needed to be based on =
previous history - conclusion

Hi MCruz, Steve
=A0
I also agree on the "would send " instead of the "would have sent" =A0for s=
ure. =A0But I have =A0a small concern/ clarification =A0about the Steve com=
ment on =A0=A0"for the period that the overload report is active" and the e=
xample to which it refers.
=A0
During the time the OLR is active, which may be rather long, =A0the traffic=
 the reacting node would send may be 100 packet =A0when it has just receive=
d the OLR. A bit later, the traffic it would send could be 120 (or 80), and=
 from the OLR definition, =A0=A0it would send 120x0,9 (or 80* 0,9) packets,=
 on=A0 which I agree. This is in line =A0with the every 10th packet droppin=
g =A0on which I also agree.=20
=A0=A0
As the text =A0=A0would =A0be written with the Steve modification , we may =
understand it is =A080 Packet during all the time =A0the OLR is active. Not=
 yet think to an alternative text, but first to see if you agree with my re=
mark.
=A0
JJacques=20
=A0
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com Envoy=E9=A0: vendredi 21 f=E9vrier 2014 18:33 =C0=A0: Steve Donovan;=
 dime@ietf.org Objet=A0: Re: [Dime] #52: Throttling not needed to be based =
on previous history - conclusion
=A0
+1 (including Steve comment)
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo=
y=E9=A0: vendredi 21 f=E9vrier 2014 16:37 =C0=A0: dime@ietf.org Objet=A0: R=
e: [Dime] #52: Throttling not needed to be based on previous history - conc=
lusion
=A0
Maria Cruz,

I support your suggested changes.=A0 I have one further suggested change be=
low.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history
=20
Following agreement is reached:
=A0
 Now (chapter 4.7):
=A0=A0=A0 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsign=
ed32
=A0=A0=A0 and describes the percentage of the traffic that the sender is
=A0=A0=A0 requested to reduce, compared to what it otherwise would have sen=
t.
=20
=A0Proposal:
=A0=A0 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned3=
2
=A0=A0=A0and describes the percentage of the traffic that the sender is
=A0=A0=A0requested to reduce, compared to what it otherwise would send.=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <----
=20
=A0
=A0Now (chapter 5.5.2):
=A0=A0=A0=A0=A0 Indicates that the reporting node urges the reacting node t=
o
=A0=A0=A0=A0=A0 reduce its traffic by a given percentage.=A0 For example if=
 the
=A0=A0=A0=A0=A0 reacting node has been sending 100 packets per second to th=
e
=A0=A0=A0=A0=A0 reporting node, then a reception of OC-Reduction-Percentage=
 value
 =A0=A0=A0=A0=A0of 10 would mean that from now on the reacting node MUST on=
ly send
=A0=A0=A0=A0=A0 90 packets per second.=A0 How the reacting node achieves th=
e "true
=A0=A0=A0=A0=A0 reduction" transactions leading to the sent request message=
s is up
=A0=A0=A0=A0=A0 to the implementation.=A0 The reacting node MAY simply drop=
 every
=A0=A0=A0=A0=A0 10th packet from its output queue and let the generic appli=
cation
=A0=A0=A0=A0=A0 logic try to recover from it.0 < value < 100
=A0
=A0 Proposal:
 Indicates that the reporting node urges the reacting node to reduce
=A0its traffic by a given percentage. For example if the  reacting node wou=
ld send 100 packets to the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <---  reporting node, then a reception of OC-Re=
duction-Percentage value of
=A010 would mean that from now on the reacting node MUST only send  90 pack=
ets instead of 100. How the reacting node achieves the "true=A0=A0=A0=A0=A0=
=A0 <---  reduction" transactions leading to the sent request messages is u=
p to
=A0the implementation. The reacting node MAY simply drop every 10th
=A0packet from its output queue and let the generic application logic try
=A0to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"



=A0
=A0
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
=A0
=A0
___________________________________________________________________________=
______________________________________________
=A0
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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
=A0
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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 21 11:14:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0192B1A0477 for ; Fri, 21 Feb 2014 11:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-ed0uOtzNuP for ; Fri, 21 Feb 2014 11:14:04 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6A1A0545 for ; Fri, 21 Feb 2014 11:14:04 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 58F002AC4A3; Fri, 21 Feb 2014 20:13:59 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3D2113840DD; Fri, 21 Feb 2014 20:13:59 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 20:13:58 +0100
From: 
To: "dime@ietf.org" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAAABKP8wAACF6rAAATkwpg==
Date: Fri, 21 Feb 2014 19:13:58 +0000
Message-ID: <1789_1393010039_5307A577_1789_6240_1_dns3ssreic6i89k4lpnolngt.1393009910150@email.android.com>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <31567_1393007267_53079AA3_31567_6121_1_6B7134B31289DC4FAF731D844122B36E4B64E8@PEXCVZYM13.corporate.adroot.infra.ftgroup>, 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.21.30017
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pR6dYYtGtoRHC7xa-9aMg0IZiEw
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 19:14:08 -0000

Valid means till the validity duration expires or a fresh OLR is received. =
So the reacting node will behave according to the latest OLR received.

So no pb for me. But feel free to propose a new text if needed.

Lionel

Envoy=E9 depuis mon Sony Xperia SP d'Orange

"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  a =E9crit :


Hi Lionel

The proposed text would be now:
"For example if the  reacting node would send 100 packets to the reporting =
node, then a reception of OC-Reduction-Percentage value of 10 would mean th=
at, for the period that the overload report is active on, the reacting node=
 MUST only send  90 packets instead of 100"

I do not feel comfortable with this wording. The reacting node does not kno=
w the period for which  the overload report is active, as it may at any tim=
e receive  another OLR overriding the previous one. The new reading means 9=
0 packets for a period we don't k now.  The existing text was mentioning pa=
cket/seconds, that Mcruz wanted also to avoid as it could   have been under=
stood that 10 packet are removed for each period of one second, which is no=
t fully accurate,  if I remember well.

Best regards

JJacques



-----Message d'origine-----
De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Envoy=E9 : vendredi 21 f=E9vrier 2014 19:28
=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet : RE: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

Hi JJ,

I think that the condition here is "if the reacting node would send 100 pac=
kets, 90 is sent" and this is true as long as the OLR is valid, right?

Or did I miss something in your question?

Lionel


De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES) Envoy=E9 : vendredi 21 f=E9vrier 2014 19:11 =C0 : dime@iet=
f.org Objet : Re: [Dime] #52: Throttling not needed to be based on previous=
 history - conclusion

Hi MCruz, Steve

I also agree on the "would send " instead of the "would have sent"  for sur=
e.  But I have  a small concern/ clarification  about the Steve comment on =
  "for the period that the overload report is active" and the example to wh=
ich it refers.

During the time the OLR is active, which may be rather long,  the traffic t=
he reacting node would send may be 100 packet  when it has just received th=
e OLR. A bit later, the traffic it would send could be 120 (or 80), and fro=
m the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  whi=
ch I agree. This is in line  with the every 10th packet dropping  on which =
I also agree.

As the text   would  be written with the Steve modification , we may unders=
tand it is  80 Packet during all the time  the OLR is active. Not yet think=
 to an alternative text, but first to see if you agree with my remark.

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33 =C0 : Steve Donovan; dime@=
ietf.org Objet : Re: [Dime] #52: Throttling not needed to be based on previ=
ous history - conclusion

+1 (including Steve comment)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=
=E9 : vendredi 21 f=E9vrier 2014 16:37 =C0 : dime@ietf.org Objet : Re: [Dim=
e] #52: Throttling not needed to be based on previous history - conclusion

Maria Cruz,

I support your suggested changes.  I have one further suggested change belo=
w.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history

Following agreement is reached:

 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.

 Proposal:
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
   and describes the percentage of the traffic that the sender is
   requested to reduce, compared to what it otherwise would send.          =
        <----


 Now (chapter 5.5.2):
      Indicates that the reporting node urges the reacting node to
      reduce its traffic by a given percentage.  For example if the
      reacting node has been sending 100 packets per second to the
      reporting node, then a reception of OC-Reduction-Percentage value
      of 10 would mean that from now on the reacting node MUST only send
      90 packets per second.  How the reacting node achieves the "true
      reduction" transactions leading to the sent request messages is up
      to the implementation.  The reacting node MAY simply drop every
      10th packet from its output queue and let the generic application
      logic try to recover from it.0 < value < 100

  Proposal:
 Indicates that the reporting node urges the reacting node to reduce
 its traffic by a given percentage. For example if the  reacting node would=
 send 100 packets to the                          <---  reporting node, the=
n a reception of OC-Reduction-Percentage value of
 10 would mean that from now on the reacting node MUST only send  90 packet=
s instead of 100. How the reacting node achieves the "true       <---  redu=
ction" transactions leading to the sent request messages is up to
 the implementation. The reacting node MAY simply drop every 10th
 packet from its output queue and let the generic application logic try
 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"





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


___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 21 11:50:17 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA23A1A014C for ; Fri, 21 Feb 2014 11:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adh67c1gpM11 for ; Fri, 21 Feb 2014 11:50:12 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 36E871A01EE for ; Fri, 21 Feb 2014 11:50:12 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1LJo6cH019070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Feb 2014 13:50:07 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1LJo5S9024899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 20:50:05 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 21 Feb 2014 20:50:05 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #51: OC-Supported-Features in requests - conclusions
Thread-Index: AQHPLuYH/TcU1wuF0UmkZ3El3l6gWZq/XpYAgACFPYCAAALFAIAABVIAgAAvawA=
Date: Fri, 21 Feb 2014 19:50:04 +0000
Message-ID: 
References: <087A34937E64E74E848732CFF8354B9209783FFD@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4120@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978409B@ESESSMB101.ericsson.se> <602542051F40544EB188D494F506C2494792FB28@G9W0747.americas.hpqcorp.net> <21534_1393003816_53078D28_21534_757_1_6B7134B31289DC4FAF731D844122B36E4B6274@PEXCVZYM13.corporate.adroot.infra.ftgroup> <602542051F40544EB188D494F506C2494792FBAD@G9W0747.americas.hpqcorp.net>
In-Reply-To: <602542051F40544EB188D494F506C2494792FBAD@G9W0747.americas.hpqcorp.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0kC6z2yshy8P4jbs3raQ4yXwKs4
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 19:50:16 -0000

Hi Anders

My understanding is that a reacting node puts OC-Supported-feature AVP in r=
equests and reporting node put it in answers.

Then Overload control may also be used in the other way where the role of r=
eacting and reporting node is exchanged. For example HSS can be a reporting=
 node (as we want to address the HSS overload), MME being reacting. We can =
also have overload control in the other way, where MME is a reporting node =
(to address MME overload) towards HSS that is then the reacting node .
The two ways can be used simultaneously.
Furthermore, each way can use its own set of features/capabilities.

Best regards

JJacques=20

 =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Askerup, Anders
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 18:49
=C0=A0: lionel.morand@orange.com; Maria Cruz Bartolome; dime@ietf.org
Objet=A0: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

Lionel,

but issue #30 is about the Answer message isn't? My question is if a Server=
 sending a Request message must it include the OC-Supported-Features AVP or=
 not?

/Anders

-----Original Message-----
From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Friday, February 21, 2014 11:30 AM
To: Askerup, Anders; Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

Hi Anders,

The clarification on the expected behavior of reporting node is covered in =
issue #30 :)

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Askerup, Anders En=
voy=E9=A0: vendredi 21 f=E9vrier 2014 18:20 =C0=A0: Maria Cruz Bartolome; d=
ime@ietf.org Objet=A0: Re: [Dime] #51: OC-Supported-Features in requests - =
conclusions

Is the intent that it covers both the reporting nodes and reacting nodes, i=
.e. both Client and Server supporting DOIC must include the OC-Supported-Fe=
atures AVP if they support DOIC?

/Anders =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Friday, February 21, 2014 3:23 AM
To: dime@ietf.org
Subject: Re: [Dime] #51: OC-Supported-Features in requests - conclusions

Yes, sorry about this, this was my understanding as well but I provided a w=
rong rephrasing.
My understanding is the following conclusions is reached:

#51: OC-Supported-Features in requests

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.


-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: viernes, 21 de febrero de 2014 10:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] #51: OC-Supported-Features in requests - conclusions

I do not agree
I think the conclusion was to say:
The OC-Supported-Features AVP MUST be included into every Diameter request =
message a DOIC supporting node sends.

For OC-Supported-Features AVP in answer messages refer to issue #30.

Ulrich =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Friday, February 21, 2014 9:35 AM
To: dime@ietf.org
Subject: [Dime] #51: OC-Supported-Features in requests - conclusions

#51: OC-Supported-Features in requests
=20
My understanding is the following conclusions is reached:

 Now:
 The OC-Supported-Features AVP SHOULD be included into every Diameter  mess=
age a DOIC  supporting node sends (and intends to use for DOIC purposes).
=20
Proposal:
replace SHOULD by MUST

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

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


From nobody Fri Feb 21 12:18:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B181A026F for ; Fri, 21 Feb 2014 12:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTgO63mKOgi0 for ; Fri, 21 Feb 2014 12:18:08 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 74AD71A0242 for ; Fri, 21 Feb 2014 12:18:08 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1LKI2Pg062173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 14:18:04 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <53077659.1030909@usdonovans.com>
Date: Fri, 21 Feb 2014 14:18:02 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D78C2FB-F3A0-4BC5-BEC4-79D8920EE710@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-c1lalh1YsE3hivu25HkGqadoAo
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 20:18:09 -0000

On Feb 21, 2014, at 9:52 AM, Steve Donovan  =
wrote:

> My other concern is that this puts a lot of extra onus on the agent =
even for the case where the reporting node does not want to =
differentiate overload reports.  To this end I suggest we add an =
indication in the OLR marking the reports that are specific to just the =
Origin-Host in the request.  Absence of the "single-client-only" AVP =
would mean that the report applies to all clients.  Presence of the AVP =
would indicate that the OLR applies to the Origin-Host.

I support this approach. And of course, being me, I would like that AVP =
to contain the Diameter Identity of the client in question.

But I wonder--should this be limited to clients? Should it be possible =
for the server to bind an OLR to a particular _agent_? That is, some =
node on the message path that is not the Origin-Host? For adjacent =
agents, this is easy--the server only sends the OLR to that agent. But =
that won't work for non-adjacent agents.=


From nobody Fri Feb 21 15:56:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC19B1A02EC for ; Fri, 21 Feb 2014 15:56:01 -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
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 bBVBEJmzbbXj for ; Fri, 21 Feb 2014 15:55:58 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 904741A0296 for ; Fri, 21 Feb 2014 15:55:58 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56178 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGzwe-0005wU-Ab for dime@ietf.org; Fri, 21 Feb 2014 15:55:53 -0800
Message-ID: <5307E788.2090703@usdonovans.com>
Date: Fri, 21 Feb 2014 17:55:52 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <31567_1393007267_53079AA3_31567_6121_1_6B7134B31289DC4FAF731D844122B36E4B64E8@PEXCVZYM13.corporate.adroot.infra.ftgroup>,  <1789_1393010039_5307A577_1789_6240_1_dns3ssreic6i89k4lpnolngt.1393009910150@email.android.com>
In-Reply-To: <1789_1393010039_5307A577_1789_6240_1_dns3ssreic6i89k4lpnolngt.1393009910150@email.android.com>
Content-Type: multipart/alternative; boundary="------------040803090901000704070304"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NOYAXnURCFHeaFSYV3J5sy0wZ5g
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 23:56:01 -0000

This is a multi-part message in MIME format.
--------------040803090901000704070304
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

+1 on Lionel's point.

Steve

On 2/21/14 1:13 PM, lionel.morand@orange.com wrote:
> Valid means till the validity duration expires or a fresh OLR is received. So the reacting node will behave according to the latest OLR received.
>
> So no pb for me. But feel free to propose a new text if needed.
>
> Lionel
>
> Envoyé depuis mon Sony Xperia SP d'Orange
>
> "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  a écrit :
>
>
> Hi Lionel
>
> The proposed text would be now:
> "For example if the  reacting node would send 100 packets to the reporting node, then a reception of OC-Reduction-Percentage value of 10 would mean that, for the period that the overload report is active on, the reacting node MUST only send  90 packets instead of 100"
>
> I do not feel comfortable with this wording. The reacting node does not know the period for which  the overload report is active, as it may at any time receive  another OLR overriding the previous one. The new reading means 90 packets for a period we don't k now.  The existing text was mentioning packet/seconds, that Mcruz wanted also to avoid as it could   have been understood that 10 packet are removed for each period of one second, which is not fully accurate,  if I remember well.
>
> Best regards
>
> JJacques
>
>
>
> -----Message d'origine-----
> De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Envoyé : vendredi 21 février 2014 19:28
> À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
> Objet : RE: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>
> Hi JJ,
>
> I think that the condition here is "if the reacting node would send 100 packets, 90 is sent" and this is true as long as the OLR is valid, right?
>
> Or did I miss something in your question?
>
> Lionel
>
>
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : vendredi 21 février 2014 19:11 À : dime@ietf.org Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>
> Hi MCruz, Steve
>
> I also agree on the "would send " instead of the "would have sent"  for sure.  But I have  a small concern/ clarification  about the Steve comment on   "for the period that the overload report is active" and the example to which it refers.
>
> During the time the OLR is active, which may be rather long,  the traffic the reacting node would send may be 100 packet  when it has just received the OLR. A bit later, the traffic it would send could be 120 (or 80), and from the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  which I agree. This is in line  with the every 10th packet dropping  on which I also agree.
>
> As the text   would  be written with the Steve modification , we may understand it is  80 Packet during all the time  the OLR is active. Not yet think to an alternative text, but first to see if you agree with my remark.
>
> JJacques
>
>
> De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com Envoyé : vendredi 21 février 2014 18:33 À : Steve Donovan; dime@ietf.org Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>
> +1 (including Steve comment)
>
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : vendredi 21 février 2014 16:37 À : dime@ietf.org Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>
> Maria Cruz,
>
> I support your suggested changes.  I have one further suggested change below.
>
> Steve
> On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
> #52: Throttling not needed to be based on previous history
>
> Following agreement is reached:
>
>  Now (chapter 4.7):
>     The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
>     and describes the percentage of the traffic that the sender is
>     requested to reduce, compared to what it otherwise would have sent.
>
>  Proposal:
>    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
>    and describes the percentage of the traffic that the sender is
>    requested to reduce, compared to what it otherwise would send.                  <----
>
>
>  Now (chapter 5.5.2):
>       Indicates that the reporting node urges the reacting node to
>       reduce its traffic by a given percentage.  For example if the
>       reacting node has been sending 100 packets per second to the
>       reporting node, then a reception of OC-Reduction-Percentage value
>       of 10 would mean that from now on the reacting node MUST only send
>       90 packets per second.  How the reacting node achieves the "true
>       reduction" transactions leading to the sent request messages is up
>       to the implementation.  The reacting node MAY simply drop every
>       10th packet from its output queue and let the generic application
>       logic try to recover from it.0 < value < 100
>
>   Proposal:
>  Indicates that the reporting node urges the reacting node to reduce
>  its traffic by a given percentage. For example if the  reacting node would send 100 packets to the                          <---  reporting node, then a reception of OC-Reduction-Percentage value of
>  10 would mean that from now on the reacting node MUST only send  90 packets instead of 100. How the reacting node achieves the "true       <---  reduction" transactions leading to the sent request messages is up to
>  the implementation. The reacting node MAY simply drop every 10th
>  packet from its output queue and let the generic application logic try
>  to recover from it.
> SRD> Replace "from now on" in the above with "for the period that the overload report is active"
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------040803090901000704070304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1 on Lionel's point. 

      

      Steve

      

    
    
On 2/21/14 1:13 PM,
      lionel.morand@orange.com wrote:

    

    

      
Valid means till the validity duration expires or a fresh OLR is received. So the reacting node will behave according to the latest OLR received.

So no pb for me. But feel free to propose a new text if needed.

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> a écrit :


Hi Lionel

The proposed text would be now:
"For example if the  reacting node would send 100 packets to the reporting node, then a reception of OC-Reduction-Percentage value of 10 would mean that, for the period that the overload report is active on, the reacting node MUST only send  90 packets instead of 100"

I do not feel comfortable with this wording. The reacting node does not know the period for which  the overload report is active, as it may at any time receive  another OLR overriding the previous one. The new reading means 90 packets for a period we don't k now.  The existing text was mentioning packet/seconds, that Mcruz wanted also to avoid as it could   have been understood that 10 packet are removed for each period of one second, which is not fully accurate,  if I remember well.

Best regards

JJacques



-----Message d'origine-----
De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Envoyé : vendredi 21 février 2014 19:28
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet : RE: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Hi JJ,

I think that the condition here is "if the reacting node would send 100 packets, 90 is sent" and this is true as long as the OLR is valid, right?

Or did I miss something in your question?

Lionel


De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : vendredi 21 février 2014 19:11 À : dime@ietf.org Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Hi MCruz, Steve

I also agree on the "would send " instead of the "would have sent"  for sure.  But I have  a small concern/ clarification  about the Steve comment on   "for the period that the overload report is active" and the example to which it refers.

During the time the OLR is active, which may be rather long,  the traffic the reacting node would send may be 100 packet  when it has just received the OLR. A bit later, the traffic it would send could be 120 (or 80), and from the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  which I agree. This is in line  with the every 10th packet dropping  on which I also agree.

As the text   would  be written with the Steve modification , we may understand it is  80 Packet during all the time  the OLR is active. Not yet think to an alternative text, but first to see if you agree with my remark.

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com Envoyé : vendredi 21 février 2014 18:33 À : Steve Donovan; dime@ietf.org Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

+1 (including Steve comment)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : vendredi 21 février 2014 16:37 À : dime@ietf.org Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Maria Cruz,

I support your suggested changes.  I have one further suggested change below.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history

Following agreement is reached:

 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.

 Proposal:
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
   and describes the percentage of the traffic that the sender is
   requested to reduce, compared to what it otherwise would send.                  <----


 Now (chapter 5.5.2):
      Indicates that the reporting node urges the reacting node to
      reduce its traffic by a given percentage.  For example if the
      reacting node has been sending 100 packets per second to the
      reporting node, then a reception of OC-Reduction-Percentage value
      of 10 would mean that from now on the reacting node MUST only send
      90 packets per second.  How the reacting node achieves the "true
      reduction" transactions leading to the sent request messages is up
      to the implementation.  The reacting node MAY simply drop every
      10th packet from its output queue and let the generic application
      logic try to recover from it.0 < value < 100

  Proposal:
 Indicates that the reporting node urges the reacting node to reduce
 its traffic by a given percentage. For example if the  reacting node would send 100 packets to the                          <---  reporting node, then a reception of OC-Reduction-Percentage value of
 10 would mean that from now on the reacting node MUST only send  90 packets instead of 100. How the reacting node achieves the "true       <---  reduction" transactions leading to the sent request messages is up to
 the implementation. The reacting node MAY simply drop every 10th
 packet from its output queue and let the generic application logic try
 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overload report is active"





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


_________________________________________________________________________________________________________________________

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.

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

_________________________________________________________________________________________________________________________

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.

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



    

    

  


--------------040803090901000704070304--


From nobody Mon Feb 24 01:46:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40441A083F for ; Mon, 24 Feb 2014 01:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxH2MzlsBH8q for ; Mon, 24 Feb 2014 01:45:55 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 61D111A0426 for ; Mon, 24 Feb 2014 01:45:54 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1O9jnTS015661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 10:45:49 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1O9jmFG022377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 10:45:48 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 24 Feb 2014 10:45:48 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 10:45:48 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: AQHPLxrEfpfGmluZNE2HeNO7pKlzb5q/5wYAgAAKk4CABDnfIA==
Date: Mon, 24 Feb 2014 09:45:47 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4326DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 26885
X-purgate-ID: 151667::1393235149-00003660-A0364D42/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qIJU4rP518FTCbkVInw3g8o8DDI
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 09:45:59 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4326DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I share JJacques concern. Replacing "from now on" with "for the period that=
 the overload report is active"
is misleading. May be its better to simply remove "from now on".

Ulrich





From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Friday, February 21, 2014 7:11 PM
To: dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion

Hi MCruz, Steve

I also agree on the "would send " instead of the "would have sent"  for sur=
e.  But I have  a small concern/ clarification  about the Steve comment on =
  "for the period that the overload report is active" and the example to wh=
ich it refers.

During the time the OLR is active, which may be rather long,  the traffic t=
he reacting node would send may be 100 packet  when it has just received th=
e OLR. A bit later, the traffic it would send could be 120 (or 80), and fro=
m the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  whi=
ch I agree. This is in line  with the every 10th packet dropping  on which =
I also agree.

As the text   would  be written with the Steve modification , we may unders=
tand it is  80 Packet during all the time  the OLR is active. Not yet think=
 to an alternative text, but first to see if you agree with my remark.

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com
Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33
=C0 : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

+1 (including Steve comment)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

Maria Cruz,

I support your suggested changes.  I have one further suggested change belo=
w.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:

#52: Throttling not needed to be based on previous history



Following agreement is reached:



 Now (chapter 4.7):

    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

    and describes the percentage of the traffic that the sender is

    requested to reduce, compared to what it otherwise would have sent.



 Proposal:

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would send.          =
        <----





 Now (chapter 5.5.2):

      Indicates that the reporting node urges the reacting node to

      reduce its traffic by a given percentage.  For example if the

      reacting node has been sending 100 packets per second to the

      reporting node, then a reception of OC-Reduction-Percentage value

      of 10 would mean that from now on the reacting node MUST only send

      90 packets per second.  How the reacting node achieves the "true

      reduction" transactions leading to the sent request messages is up

      to the implementation.  The reacting node MAY simply drop every

      10th packet from its output queue and let the generic application

      logic try to recover from it.0 < value < 100



  Proposal:

 Indicates that the reporting node urges the reacting node to reduce

 its traffic by a given percentage. For example if the

 reacting node would send 100 packets to the                          <---

 reporting node, then a reception of OC-Reduction-Percentage value of

 10 would mean that from now on the reacting node MUST only send

 90 packets instead of 100. How the reacting node achieves the "true       =
<---

 reduction" transactions leading to the sent request messages is up to

 the implementation. The reacting node MAY simply drop every 10th

 packet from its output queue and let the generic application logic try

 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"








_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________



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_5BCBA1FC2B7F0B4C9D935572D9000668151B4326DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I share JJ=
acques concern. Replacing
"from now on" with "for the period =
that the overload report is active"


is mislead=
ing. May be its better to simply remove “from now on”.


 =
;


Ulrich


 =
;


 =
;


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Friday, February 21, 2014 7:11 PM

To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previo=
us history - conclusion






 


Hi MCruz, =
Steve


 


I also agr=
ee on the “would send ” instead of the “would have sent&#=
8221;  for sure.  But I have  a small concern/ clarification=
  about the Steve comment
 on   “for the period that the =
overload report is active”
and the example to which i=
t refers.


 


During the=
 time the OLR is active, which may be rather long,  the traffic the re=
acting node would send may be 100 packet  when it has just received
 the OLR. A bit later, the traffic it would send could be 120 (or 80), and =
from the OLR definition,   it would send 120x0,9 (or 80* 0,9) pac=
kets, on  which I agree. This is in line  with the every 10th pac=
ket dropping  on which I also agree.



 &nbs=
p;


As the tex=
t   would  be written with the Steve modification , we may u=
nderstand it is  80 Packet during all the time  the OLR is active=
. Not yet
 think to an alternative text, but first to see if you agree with my remark=
.


 


JJacques



 


 






De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de lionel.mor=
and@orange.com

Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33

=C0 : Steve Donovan; dime@ietf=
.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion





 


+1 (inclu=
ding Steve comment)


 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion





 =



Mar=
ia Cruz,



I support your suggested changes.  I have one further suggested change=
 below.



Steve




On 2/21/14 2:40 AM, Maria Cruz Bar=
tolome wrote:






#52: Throttling not needed to be based on previous h=
istory


 

Following agreement is reached:


 =



 Now (chapter 4.7):=



    The OC-Reduction-Percentage AVP (=
AVP code TBD8) is type of Unsigned32=



    and describes the percentage of t=
he traffic that the sender is=



    requested to reduce, compared to =
what it otherwise would have sent.


 

 Proposal:


   The OC-Reduction-Percentage AVP (AVP co=
de TBD8) is type of Unsigned32  


   and describes the percentage of th=
e traffic that the sender is  <=
/span>


   requested to reduce, compared to w=
hat it otherwise would send.        =
;          <----


 

 =



 Now (chapter 5.5.2):


      Indicates that the re=
porting node urges the reacting node to


      reduce its traffic by=
 a given percentage.  For example if the


      reacting node has bee=
n sending 100 packets per second to the


      reporting node, then =
a reception of OC-Reduction-Percentage value


      of 10 would mean that=
 from now on the reacting node MUST only send


      90 packets per second=
.  How the reacting node achieves the "true


      reduction" trans=
actions leading to the sent request messages is up


      to the implementation=
.  The reacting node MAY simply drop every=



      10th packet from its =
output queue and let the generic application


      logic try to recover =
from it.0 < value < 100=



 =



  Proposal:


 Indicates that the reporting node urges the reactin=
g node to reduce 


 its traffic by a given percentage. For example=
 if the


 reacting node would send 100 packets to the &n=
bsp;            =
;            <---=



 reporting node, then a reception of OC-Reduction-Pe=
rcentage value of 


 10 would mean that from now on the reacting no=
de MUST only send


 90 packets instead of 100. How the reacting node ac=
hieves the "true       <---


 reduction" transactions leading to the sent re=
quest messages is up to 

 the implementation. The reacting node MAY simp=
ly drop every 10th 


 packet from its output queue and let the gener=
ic application logic try 

 to recover from it.




SRD> Replace "from now on&=
quot; in the above with "for the period that the overload report is ac=
tive"










 =



 =



_______________________________________________


DiME mailing list


DiME@ietf.org


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


 =



 =



____________________________________________________=
_____________________________________________________________________


 =



Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
span lang=3D"EN-US">


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
span lang=3D"EN-US">


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 =



This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.


Thank you.






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4326DEMUMBX014nsnin_--


From nobody Mon Feb 24 02:14:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA951A036B for ; Mon, 24 Feb 2014 02:14:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD99lGU18D0P for ; Mon, 24 Feb 2014 02:14:45 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 841001A0192 for ; Mon, 24 Feb 2014 02:14:45 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1OAEhJ3016076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Feb 2014 04:14:44 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1OAEfR7001903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Feb 2014 11:14:42 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 11:14:41 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACMQxIw
Date: Mon, 24 Feb 2014 10:14:40 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com>
In-Reply-To: <53077659.1030909@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266A7BBFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bVB__qWqiHW0TcGRJBGT1Hb1sjY
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 10:14:49 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266A7BBFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

When a reporting node puts an OC-OLR an answer, this OLR is to be sent to t=
he origin Host of the corresponding request (eg  client 1). For eg a client=
 2, the reporting node  will put an OC-OLR in  an answer going to client 2 =
. I do not see why an OC-OLR that was put  in answer to client  1 will be p=
ut  later in the path  in an answer to client 2 or even  to answers to all =
clients and to distinguish these behaviors by extra indicators,  these are =
new things not needed in the baseline .

If a DA is acting on behalf of client 1, it will receive an OLR in  an answ=
er towards client 1 and will apply the traffic reduction to the traffic com=
ing from client 1 .  The same if it is acting on behalf of client 2. So no =
difference for the reporting node which is an objective.
Other approaches are new things that I do not yet  understand the need  and=
 that are  not part of the baseline.

So I remain in line with the  conclusions (and his hereafter mail) that  Ul=
rich  proposed and I think  supported  by several  of us.

Best regards

Jacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:53
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.  To this end I suggest we add an indication in the OLR marking th=
e reports that are specific to just the Origin-Host in the request.  Absenc=
e of the "single-client-only" AVP would mean that the report applies to all=
 clients.  Presence of the AVP would indicate that the OLR applies to the O=
rigin-Host.

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client

Here I disagree. We have the 3GPP requirement to allow requesting different=
 amount of reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35

3. introduce the binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention

 If there's an intervening DOIC agent, then the agent, not the client, is t=
he reacting node from the server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node

 But, short of adding an origin-host type, nothing binds the OLR to a parti=
cular client, regardless of DOIC support at the clients.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_E194C2E18676714DACA9C3A2516265D20266A7BBFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi



 <=
/p>

When a reporting node put=
s an OC-OLR an answer, this OLR is to be sent to the origin Host of the cor=
responding request (eg  client 1). For eg a client 2, the
 reporting node  will put an OC-OLR in  an answer going to client=
 2 . I do not see why an OC-OLR that was put  in answer to client &nbs=
p;1 will be put  later in the path  in an answer to client 2 or e=
ven  to answers to all clients and to distinguish these behaviors
 by extra indicators,  these are new things not needed in the baseline=
 .


 <=
/p>

If a DA is acting on beha=
lf of client 1, it will receive an OLR in  an answer towards client 1 =
and will apply the traffic reduction to the traffic coming from
 client 1 .  The same if it is acting on behalf of client 2. So no dif=
ference for the reporting node which is an objective.



Other approaches are new =
things that I do not yet  understand the need  and that are  =
;not part of the baseline.


 <=
/p>

So I remain in line with =
the  conclusions (and his hereafter mail) that  Ulrich  prop=
osed and I think  supported  by several  of us.


 <=
/p>

Best regards


 <=
/p>

Jacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:53

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Ulrich,



I have a couple of concerns with this approach, as currently outlined. =
; 



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This,=
 I guess, is a general question, not just applying to this proposal.  =
I suggest we capture in the agent behavior
 section that is currently missing wording indicating that the first suppor=
ting agent that receives the request must be the reacting node for that non=
-supporting client.  Subsequent DOIC supporting agents must not be the=
 reacting node for the non-supporting
 client.



We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't
 seem to be an issue for the loss algorithm, but this might not be the case=
 with other algorithms.



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.  To this end I suggest we add an indication in the OLR marki=
ng the reports that are specific to just
 the Origin-Host in the request.  Absence of the "single-client-o=
nly" AVP would mean that the report applies to all clients.  Pres=
ence of the AVP would indicate that the OLR applies to the Origin-Host.



Steve




On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Ben,


 


the proposed conclusion was based on comments received so far (from Li=
onel, Nirav, Steve, MCruz, JJ). 


Now you seem to address two points:


a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying te=
xt for 5.5. as follows:


 


When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR. 


 


This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server.


 


b) There is no binding of the OLR to the orig-host of the client<=
/o:p>


Here I disagree. We have the 3GPP requirement to allow requesting diff=
erent amount of reduction from different clients, and I think we have 3 opt=
ions:


1. ignore the 3GPP requirement


2. introduce new report types as originally proposed in #35=



3. introduce the binding between OLR and orig-host of the client.=



 


So far I understood that people favoured option 3.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [mailto:ben@=
nostrum.com] 


Sent: Thursday, February 20, 2014 11:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


 


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:


 




#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional report types. However=
, we agreed to add clarifying text to clause 5.5 as follows:

 


When an agent received an OLR in response to a request initiated by a =
client not supporting DOIC, this agent needs to bind the received OLR to th=
e origin-host of the client.




 


I do not agree.


 


You proposal implies that the server's OLR only applies to that client=
.


<Ulrich>exactly, that was the intention</Ulrich>


 If there's an intervening DOIC agent, then the agent, not the client,=
 is the reacting node from the server's perspective.


<Ulrich> the server's perspective is agnostic. The server does n=
ot know whether it's the client or an agent on the path that takes the role=
 of the reacting node</Ulrich>


 But, short of adding an origin-host type, nothing binds the OLR to a =
particular client, regardless of DOIC support at the clients.

<Ulrich> the binding is always there, regardless of DOIC support=
 at the client</Ulrich>


 


 Whether or not the client also supports DOIC doesn't change that. For=
 DOIC-supporting clients, the agent has the additional option of reducing t=
raffic by asking the clients to reduce traffic (making them reacting nodes =
from the perspective of the _agent_, but not the server.)  It doesn't =
have that option for non-DOIC clients.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_E194C2E18676714DACA9C3A2516265D20266A7BBFR712WXCHMBA12z_--


From nobody Mon Feb 24 02:41:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94551A07E5 for ; Mon, 24 Feb 2014 02:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI238wUlXLUU for ; Mon, 24 Feb 2014 02:41:36 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 405091A0644 for ; Mon, 24 Feb 2014 02:41:36 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id CCDA83B4449; Mon, 24 Feb 2014 11:41:34 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 7E044384085; Mon, 24 Feb 2014 11:41:34 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 11:41:34 +0100
From: 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1j2BaLawTok+U/ijMc7vV8AATUamAABiWF1AACvi8gACMQxIwAAGnMKA=
Date: Mon, 24 Feb 2014 10:41:32 +0000
Message-ID: <14146_1393238494_530B21DE_14146_941_1_6B7134B31289DC4FAF731D844122B36E4BB1CD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4BB1CDPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/baaliPeRqmDu0vsN9ML74H2I8os
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 10:41:41 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4BB1CDPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree.
Agent should not assume that the received OLR is valid for all the clients =
below it. It does not preclude an agent to do so when it is know that for a=
n application all the received are independent of the clients. But this is =
something not required as per the base solution for me and can be defined p=
er application use.

Regards,

Lionel
De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Envoy=E9 : lundi 24 f=E9vrier 2014 11:15
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Hi

When a reporting node puts an OC-OLR an answer, this OLR is to be sent to t=
he origin Host of the corresponding request (eg  client 1). For eg a client=
 2, the reporting node  will put an OC-OLR in  an answer going to client 2 =
. I do not see why an OC-OLR that was put  in answer to client  1 will be p=
ut  later in the path  in an answer to client 2 or even  to answers to all =
clients and to distinguish these behaviors by extra indicators,  these are =
new things not needed in the baseline .

If a DA is acting on behalf of client 1, it will receive an OLR in  an answ=
er towards client 1 and will apply the traffic reduction to the traffic com=
ing from client 1 .  The same if it is acting on behalf of client 2. So no =
difference for the reporting node which is an objective.
Other approaches are new things that I do not yet  understand the need  and=
 that are  not part of the baseline.

So I remain in line with the  conclusions (and his hereafter mail) that  Ul=
rich  proposed and I think  supported  by several  of us.

Best regards

Jacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:53
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.  To this end I suggest we add an indication in the OLR marking th=
e reports that are specific to just the Origin-Host in the request.  Absenc=
e of the "single-client-only" AVP would mean that the report applies to all=
 clients.  Presence of the AVP would indicate that the OLR applies to the O=
rigin-Host.

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client

Here I disagree. We have the 3GPP requirement to allow requesting different=
 amount of reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35

3. introduce the binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention

 If there's an intervening DOIC agent, then the agent, not the client, is t=
he reacting node from the server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node

 But, short of adding an origin-host type, nothing binds the OLR to a parti=
cular client, regardless of DOIC support at the clients.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4BB1CDPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I agree.


Agent shou=
ld not assume that the received OLR is valid for all the clients below it. =
It does not preclude an agent to do so when it is know that
 for an application all the received are independent of the clients. But th=
is is something not required as per the base solution for me and can be def=
ined per application use.


 =
;


Regards,


 =
;


Lionel








De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Envoy=E9 : lundi 24 f=E9vrier 2014 11:15

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Hi



 =
;


When a rep=
orting node puts an OC-OLR an answer, this OLR is to be sent to the origin =
Host of the corresponding request (eg  client 1). For eg a
 client 2, the reporting node  will put an OC-OLR in  an answer g=
oing to client 2 . I do not see why an OC-OLR that was put  in answer =
to client  1 will be put  later in the path  in an answer to=
 client 2 or even  to answers to all clients and to distinguish
 these behaviors by extra indicators,  these are new things not needed=
 in the baseline .


 =
;


If a DA is=
 acting on behalf of client 1, it will receive an OLR in  an answer to=
wards client 1 and will apply the traffic reduction to the traffic
 coming from client 1 .  The same if it is acting on behalf of client =
2. So no difference for the reporting node which is an objective.



Other appr=
oaches are new things that I do not yet  understand the need  and=
 that are  not part of the baseline.


 =
;


So I remai=
n in line with the  conclusions (and his hereafter mail) that  Ul=
rich  proposed and I think  supported  by several  of u=
s.


 =
;


Best regar=
ds


 =
;


Jacques



 =
;


 =
;


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:53

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


=
Ulrich,



I have a couple of concerns with this approach, as currently outlined. =
; 



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This,=
 I guess, is a general question, not just applying to this proposal.  =
I suggest we capture in the agent behavior
 section that is currently missing wording indicating that the first suppor=
ting agent that receives the request must be the reacting node for that non=
-supporting client.  Subsequent DOIC supporting agents must not be the=
 reacting node for the non-supporting
 client.



We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't
 seem to be an issue for the loss algorithm, but this might not be the case=
 with other algorithms.



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.  To this end I suggest we add an indication in the OLR marki=
ng the reports that are specific to just
 the Origin-Host in the request.  Absence of the "single-client-o=
nly" AVP would mean that the report applies to all clients.  Pres=
ence of the AVP would indicate that the OLR applies to the Origin-Host.



Steve




On 2/21/14 4:48 AM, Wiehe, Ulri=
ch (NSN - DE/Munich) wrote:






Ben,


 


the proposed conclusion was based on comments rec=
eived so far (from Lionel, Nirav, Steve, MCruz, JJ). 

Now you seem to address two points:


a) There is no dependency to DOIC support of the =
client.


To address this I would like to propose rewording=
 of the clarifying text for 5.5. as follows:


 


When an agent takes the role of a reacting node, =
the agent needs to bind a received OLR to the origin host of the client tha=
t initiated the request which corresponds to the answer containing the OLR.=
 


 


This would cover not only the case where an agent=
 takes the role of the reacting node on behalf of a (or several) non suppor=
ting client, but also the case where an agent is configured to take the rol=
e of a reporting node (for realm-type reports) towards the client and at th=
e same time the role of a reacting node towards the server.


 


b) There is no binding of the OLR to the orig-hos=
t of the client


Here I disagree. We have the 3GPP requirement to =
allow requesting different amount of reduction from different clients, and =
I think we have 3 options:


1. ignore the 3GPP requirement<=
/pre>

2. introduce new report types as originally propo=
sed in #35


3. introduce the binding between OLR and orig-hos=
t of the client.


 


So far I understood that people favoured option 3=
.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [mailto:ben@nostrum.com] 


Sent: Thursday, February 20, 2014 11:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.or=
g


Subject: Re: [Dime] Issue#35 conclusion


 


 


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN -=
 DE/Munich) <ulrich.wiehe@nsn.co=
m> wrote:


 




#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional =
report types. However, we agreed to add clarifying text to clause 5.5 as fo=
llows:


 


When an agent received an OLR in response to a re=
quest initiated by a client not supporting DOIC, this agent needs to bind t=
he received OLR to the origin-host of the client.




 


I do not agree.


 


You proposal implies that the server's OLR only a=
pplies to that client.


<Ulrich>exactly, that was the intention<=
/Ulrich>


 If there's an intervening DOIC agent, then the a=
gent, not the client, is the reacting node from the server's perspective.


<Ulrich> the server's perspective is agnost=
ic. The server does not know whether it's the client or an agent on the pat=
h that takes the role of the reacting node</Ulrich>=



 But, short of adding an origin-host type, nothin=
g binds the OLR to a particular client, regardless of DOIC support at the c=
lients.


<Ulrich> the binding is always there, regar=
dless of DOIC support at the client</Ulrich>


 


 Whether or not the client also supports DOIC doe=
sn't change that. For DOIC-supporting clients, the agent has the additional=
 option of reducing traffic by asking the clients to reduce traffic (making=
 them reacting nodes from the perspective of the _agent_, but not the serve=
r.)  It doesn't have that option for non-DOIC clients.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


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


 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4BB1CDPEXCVZYM13corpora_--


From nobody Mon Feb 24 03:28:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FA31A03E4 for ; Mon, 24 Feb 2014 03:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkL4NSSGHxNV for ; Mon, 24 Feb 2014 03:28:23 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 355411A03D8 for ; Mon, 24 Feb 2014 03:28:22 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1OBSKlA021386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 12:28:20 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1OBSJTn008187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 12:28:19 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 12:28:19 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbA
Date: Mon, 24 Feb 2014 11:28:18 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com>
In-Reply-To: <53077659.1030909@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 5529
X-purgate-ID: 151667::1393241300-00003660-F0696FCC/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nX1mf85BdWesBljhBnvGlb7V2pc
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 11:28:26 -0000

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client
Here I disagree. We have the 3GPP requirement to allow requesting different=
 amount of reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35
3. introduce the binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention
 If there's an intervening DOIC agent, then the agent, not the client, is t=
he reacting node from the server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node
 But, short of adding an origin-host type, nothing binds the OLR to a parti=
cular client, regardless of DOIC support at the clients.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

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



From nobody Mon Feb 24 03:44:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575E31A07F1 for ; Mon, 24 Feb 2014 03:44:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r9c3ZoLwBLg for ; Mon, 24 Feb 2014 03:44:15 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 80B431A07E7 for ; Mon, 24 Feb 2014 03:44:14 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1OBiDh1026160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 12:44:13 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1OBiDer017963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 12:44:13 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 24 Feb 2014 12:44:12 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 12:44:12 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [dime] #56: Bad Description of Overload Control State
Thread-Index: AQHPLKXn/K5opEUqEkqiVdwfHsd6G5rEUNjA
Date: Mon, 24 Feb 2014 11:44:11 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net>
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org>
In-Reply-To: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 7038
X-purgate-ID: 151667::1393242253-00003660-808B3BDE/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Bstu0OO_UdfS1JM_74ElyrBdDrQ
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 11:44:17 -0000

VGhlcmUgaGFzIGJlZW4gbm8gZGlzY3Vzc2lvbiBvZiB0aGlzIHRpY2tldC4NCg0KSSBwcm9wb3Nl
IHRvIHJlcGxhY2UgdGV4dCBpbiBjbGF1ZXMgNS41LjEgYXMgc3VnZ2VzdGVkIGluIHRoZSB0aWNr
ZXQuDQoNClJlZ2FyZHMNClVscmljaA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBleHQgZGltZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytkaW1lQGdyZW5hY2hlLnRv
b2xzLmlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE4LCAyMDE0IDE6MzUgUE0N
ClRvOiBkcmFmdC1kb2NkdC1kaW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7IFdpZWhlLCBVbHJpY2gg
KE5TTiAtIERFL011bmljaCkNCkNjOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBbZGltZV0gIzU2
OiBCYWQgRGVzY3JpcHRpb24gb2YgT3ZlcmxvYWQgQ29udHJvbCBTdGF0ZQ0KDQojNTY6IEJhZCBE
ZXNjcmlwdGlvbiBvZiBPdmVybG9hZCBDb250cm9sIFN0YXRlDQoNCiBUaGUgZGVzY3JpcHRpb24g
b2YgT3ZlcmxvYWQgQ29udHJvbCBTdGF0ZSBpbiBjbGF1c2UgNS41LjEgaXMgaW5hY2N1cmF0ZSwN
CiBpbmNvbXBsZXRlIGFuZCBjb3VsZCBiZSBtaXNsZWFkaW5nLiBJdCBkb2VzIG5vdCBkaWZmZXJl
bnRpYXRlIGJldHdlZW4NCiBPdmVybG9hZCBDb250cm9sIFN0YXRlIGluIGEgcmVhY3Rpbmcgbm9k
ZSB2ZXJzdXMgT3ZlcmxvYWQgQ29udHJvbCBTdGF0ZSBpbg0KIGEgcmVwb3J0aW5nIG5vZGUuIEl0
IGFsc28gZG9lcyBub3QgZGVzY3JpYmUgaG93IE92ZXJsb2FkIENvbnRyb2wgU3RhdGVzDQogYXJl
IG1haW50YWluZWQuDQoNCiBJdCBpcyBwcm9wb3NlZCB0byByZXBsYWNlIGN1cnJlbnQgdGV4dCB3
aXRoIHRoZSBmb2xsb3dpbmc6DQoNCg0KIDUuNS4xLiAgT3ZlcmxvYWQgQ29udHJvbCBTdGF0ZSAo
T0NTKQ0KDQogICAgNS41LjEuMSAgIE92ZXJsb2FkIENvbnRyb2wgU3RhdGVzIGZvciByZWFjdGlu
ZyBub2Rlcw0KDQogICAgQSByZWFjdGluZyBub2RlIChjbGllbnQpIG1haW50YWlucyBwZXIgc3Vw
cG9ydGVkIERpYW1ldGVyIGFwcGxpY2F0aW9uDQogICAgYSBob3N0LXR5cGUgT3ZlcmxvYWQgQ29u
dHJvbCBTdGF0ZSBmb3IgZWFjaCBEZXN0aW5hdGlvbi1Ib3N0IHRvd2FyZHMNCiAgICB3aGljaCBp
dCBzZW5kcyBob3N0LXR5cGUgcmVxdWVzdHMgYW5kIGEgcmVhbG0tdHlwZSBPdmVybG9hZCBDb250
cm9sDQogU3RhdGUNCiAgICBmb3IgZWFjaCBEZXN0aW5hdGlvbi1SZWFsbSB0b3dhcmQgd2hpY2gg
aXQgc2VuZHMgcmVhbG0tdHlwZSByZXF1ZXN0cy4NCiAgICBBIGhvc3QtdHlwZSBPdmVybG9hZCBD
b250cm9sIFN0YXRlIG1heSBiZSBpZGVudGlmaWVkIGJ5IHRoZSBwYWlyIG9mDQogICAgQXBwbGlj
YXRpb24tSWQgYW5kIERlc3RpbmF0aW9uLUhvc3Q7IGEgcmVhbG0tdHlwZSBPdmVybG9hZCBDb250
cm9sDQogU3RhdGUNCiAgICBtYXkgYmUgaWRlbnRpZmllZCBieSB0aGUgcGFpciBvZiBBcHBsaWNh
dGlvbi1JZCBhbmQgRGVzdGluYXRpb24tUmVhbG0uDQogICAgVGhlIGhvc3QtdHlwZS9yZWFsbS10
eXBlIE92ZXJsb2FkIENvbnRyb2wgU3RhdGUgZm9yIGEgZ2l2ZW4gcGFpciBvZg0KICAgIEFwcGxp
Y2F0aW9uIGFuZCBEZXN0aW5hdGlvbi1Ib3N0IC8gRGVzdGluYXRpb24tUmVhbG0gY291bGQgaW5j
bHVkZSB0aGUNCiAgICBpbmZvcm1hdGlvbiBhcyBzaG93biBpbiB0YWJsZSAxL3RhYmxlIDIuDQoN
CiAgICA8c2VlIGF0dGFjaG1lbnQ+DQoNCiAgICBBZ2VudHMgdGhhdCB0YWtlIHRoZSByb2xlIG9m
IGEgcmVhY3Rpbmcgbm9kZSBvbiBiZWhhbGYgb2YgY2xpZW50cyBNVVNUDQogICAgbWFpbnRhaW4g
T3ZlcmxvYWQgQ29udHJvbCBTdGF0ZXMgcGVyIGNsaWVudC4NCg0KICAgIDUuNS4xLjIgICBPdmVy
bG9hZCBDb250cm9sIFN0YXRlcyBmb3IgcmVwb3J0aW5nIG5vZGVzDQoNCiAgICBBIHJlcG9ydGlu
ZyBub2RlIChzZXJ2ZXIpIG1haW50YWlucyBwZXIgc3VwcG9ydGVkIERpYW1ldGVyIGFwcGxpY2F0
aW9uDQogICAgYW4gT3ZlcmxvYWQgQ29udHJvbCBTdGF0ZSBmb3IgZWFjaCBPcmlnaW4tSG9zdCBm
cm9tIHdoaWNoIGl0IHJlY2VpdmVzDQogICAgcmVxdWVzdHMgdGhhdCBjb250YWluIGFuIChleHBs
aWNpdCBvciBpbXBsaWNpdCkgaW5kaWNhdGlvbiBvZg0KICAgIE9MUl9ERUZBVUxUX0FMR08gc3Vw
cG9ydC4NCg0KICAgIEEgcmVwb3J0aW5nIG5vZGUgKGFnZW50IHRoYXQgaXMgY29uZmlndXJlZCB0
byB0YWtlIHRoZSByb2xlIG9mIGENCiAgICByZXBvcnRpbmcgbm9kZSBmb3IgYSBnaXZlbiByZWFs
bSkgbWFpbnRhaW5zIHBlciBzdXBwb3J0ZWQgRGlhbWV0ZXINCiAgICBhcHBsaWNhdGlvbiBhbiBP
dmVybG9hZCBDb250cm9sIFN0YXRlIGZvciBlYWNoIE9yaWdpbi1Ib3N0IGZyb20gd2hpY2gNCiBp
dA0KICAgIHJlY2VpdmVzIHJlYWxtLXR5cGUgcmVxdWVzdHMgKG9mIHRoYXQgZ2l2ZW4gcmVhbG0p
IHRoYXQgY29udGFpbiBhbg0KICAgIChleHBsaWNpdCBvciBpbXBsaWNpdCkgaW5kaWNhdGlvbiBv
ZiBPTFJfREVGQVVMVF9BTEdPIHN1cHBvcnQuDQoNCiAgICBBIE92ZXJsb2FkIENvbnRyb2wgU3Rh
dGUgbWF5IGJlIGlkZW50aWZpZWQgYnkgdGhlIHBhaXIgb2YgQXBwbGljYXRpb24tDQogSWQNCiAg
ICBhbmQgT3JpZ2luLUhvc3QuDQoNCiAgICBUaGUgT3ZlcmxvYWQgQ29udHJvbCBTdGF0ZSBmb3Ig
YSBnaXZlbiBwYWlyIG9mIEFwcGxpY2F0aW9uIGFuZCBPcmlnaW4tDQogICAgSG9zdCBjb3VsZCBp
bmNsdWRlIHRoZSBpbmZvcm1hdGlvbiBhcyBzaG93biBpbiB0YWJsZSAzLg0KICAgIDxzZWUgYXR0
YWNobWVudD4NCg0KICAgIE5vdGU6IEZvciBub2RlcyB0aGF0IHN1cHBvcnQgb3RoZXIgZmVhdHVy
ZXMgdGhhbiBqdXN0IE9MUl9ERUZBVUxUX0FMR08NCiAgICB0aGUgT3ZlcmxvYWQgQ29udHJvbCBT
dGF0ZSBkZWZpbml0aW9ucyBtYXkgbmVlZCB0byBiZSBleHRlbmRlZC4NCg0KICAgIDUuNS4xLjMg
IE1haW50YWluaW5nIE92ZXJsb2FkIENvbnRyb2wgU3RhdGVzDQoNCiAgICBSZWFjdGluZyBub2Rl
cyBjcmVhdGUgYSBob3N0LXR5cGUgT0NTIHdpdGggT0NTLUlkID0gKHgsQSkgd2hlbg0KIHJlY2Vp
dmluZw0KICAgIGFuIGFuc3dlciBtZXNzYWdlIG9mIGFwcGxpY2F0aW9uIHggY29udGFpbmluZyBh
biBPcmlnLUhvc3Qgb2YgQSBhbmQgYQ0KICAgIGhvc3QtdHlwZSBPQy1PTFIgQVZQIHVubGVzcyBz
dWNoIGhvc3QtdHlwZSBPQ1MgYWxyZWFkeSBleGlzdHMuDQoNCiAgICBSZWFjdGluZyBub2RlcyBj
cmVhdGUgYSByZWFsbS10eXBlIE9DUyB3aXRoIE9DUy1JZCA9ICh4LEEpIHdoZW4NCiByZWNlaXZp
bmcNCiAgICBhbiBhbnN3ZXIgbWVzc2FnZSBvZiBhcHBsaWNhdGlvbiB4IGNvbnRhaW5pbmcgYW4g
T3JpZy1SZWFsbSBvZiBBIGFuZCBhDQogICAgcmVhbG0tdHlwZSBPQy1PTFIgQVZQIHVubGVzcyBz
dWNoIHJlYWxtIHR5cGUgT0NTIGFscmVhZHkgZXhpc3RzLg0KDQogICAgUmVhY3Rpbmcgbm9kZXMg
ZGVsZXRlIGFuIE9DUyB3aGVuIGl0IGV4cGlyZXMgKGkuZS4gd2hlbiBjdXJyZW50IHRpbWUNCiAg
ICBtaW51cyByZWNlcHRpb24gdGltZSBpcyBncmVhdGVyIHRoYW4gdmFsaWRpdHkgZHVyYXRpb24p
Lg0KDQogICAgUmVhY3Rpbmcgbm9kZXMgdXBkYXRlIHRoZSBob3N0LXR5cGUgT0NTIHdpdGggT0NT
LUlkID0gKHgsQSkgd2hlbg0KICAgIHJlY2VpdmluZyBhbiBhbnN3ZXIgbWVzc2FnZSBvZiBhcHBs
aWNhdGlvbiB4IGNvbnRhaW5pbmcgYW4gT3JpZy1Ib3N0IG9mDQogICAgQSBhbmQgYSBob3N0LXR5
cGUgT0MtT0xSIEFWUCB3aXRoIGEgc2VxdWVuY2UgbnVtYmVyIGhpZ2hlciB0aGFuIHRoZQ0KICAg
IHN0b3JlZCBzZXF1ZW5jZSBudW1iZXIuDQoNCiAgICBSZWFjdGluZyBub2RlcyB1cGRhdGUgdGhl
IHJlYWxtLXR5cGUgT0NTIHdpdGggT0NTLUlkID0gKHgsQSkgd2hlbg0KICAgIHJlY2VpdmluZyBh
biBhbnN3ZXIgbWVzc2FnZSBvZiBhcHBsaWNhdGlvbiB4IGNvbnRhaW5pbmcgYW4gT3JpZy1SZWFs
bQ0KIG9mDQogICAgQSBhbmQgYSByZWFsbS10eXBlIE9DLU9MUiBBVlAgd2l0aCBhIHNlcXVlbmNl
IG51bWJlciBoaWdoZXIgdGhhbiB0aGUNCiAgICBzdG9yZWQgc2VxdWVuY2UgbnVtYmVyLg0KDQog
ICAgUmVwb3J0aW5nIG5vZGVzIGNyZWF0ZSBhbiBPQ1Mgd2l0aCBPQ1MtSWQgPSAoeCxBKSB3aGVu
IHJlY2VpdmluZyBhDQogICAgcmVxdWVzdCAoaW5kaWNhdGluZyBzdXBwb3J0IG9mIE9MUl9ERUZB
VUxUX0FMR08pIG9mIGFwcGxpY2F0aW9uIHgNCiAgICBjb250YWluaW5nIGFuIE9yaWctSG9zdCBv
ZiBBIHVubGVzcyBzdWNoIE9DUyBhbHJlYWR5IGV4aXN0cy4NCg0KICAgIFJlcG9ydGluZyBub2Rl
cyBkZWxldGUgYW4gT0NTIHdoZW4gaXQgZXhwaXJlcy4NCg0KICAgIFJlcG9ydGluZyBub2RlcyB1
cGRhdGUgdGhlIE9DUyB3aXRoIE9DUy1JZCA9ICh4LEEpIHdoZW4gdGhleSBkZXRlY3QgdGhlDQog
ICAgbmVlZCB0byBtb2RpZnkgdGhlIHJlcXVlc3RlZCBhbW91bnQgb2YgYXBwbGljYXRpb24geCB0
cmFmZmljIHJlZHVjdGlvbg0KICAgIGdlbmVyYXRlZCBieSBBLg0KDQotLSANCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KIFJlcG9ydGVyOiAgICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0LWRv
Y2R0LWRpbWUtDQogIHVscmljaC53aWVoZUBuc24uY29tICAgfCAgb3ZsaUB0b29scy5pZXRmLm9y
Zw0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5
OiAgbWFqb3IgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIGRyYWZ0LSAgICAgICB8
ICAgIFZlcnNpb246DQogIGRvY2R0LWRpbWUtb3ZsaSAgICAgICAgfCAgIEtleXdvcmRzOg0KIFNl
dmVyaXR5OiAgQWN0aXZlIFdHICAgIHwNCiAgRG9jdW1lbnQgICAgICAgICAgICAgICB8DQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn
L3dnL2RpbWUvdHJhYy90aWNrZXQvNTY+DQpkaW1lIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv
ZGltZS8+DQoNCg==


From nobody Mon Feb 24 04:21:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26481A0089 for ; Mon, 24 Feb 2014 04:21:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.659
X-Spam-Level: 
X-Spam-Status: No, score=0.659 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A2-y5RSiM2G for ; Mon, 24 Feb 2014 04:21:23 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 405A91A00A7 for ; Mon, 24 Feb 2014 04:21:22 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-81-530b39418e1c
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 5F.A8.04853.1493B035; Mon, 24 Feb 2014 13:21:22 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 13:21:21 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYA=
Date: Mon, 24 Feb 2014 12:21:20 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvja6TJXewwYs1XBZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8+PJ6wFRx0q+ve9Z25g7DLpYuTkkBAwkVg65z0bhC0mceHe eiCbi0NI4ASjxLE7E5ggnMWMEq9mT2cCqWITsJO4dPoFkM3BISKgLHH6lwNIWFhAXeLO9wus ILaIgIZE45tP7BC2n8S2NV3MIDaLgKrEjMYfYDavgK/EvD/zmSHmb2GS2LxwJtgVnAIBEoe+ zwezGYEu+n5qDdheZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/rCD3SAgoSizvl4Mo15O4MXUK G4StLbFs4WuovYISJ2c+YZnAKDoLydRZSFpmIWmZhaRlASPLKkbJ4tTi4tx0IwO93PTcEr3U oszk4uL8PL3i1E2MwNg4uOW30Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cAYMevFH2PTY0JVfD8/iifPS5ly3k/MOGOBo/+5ORw6pakdi69snP65PUM7YL3w 5902KYLcCocZk/8qdS8NmPH0poqtmULaHev30QGWbN8YC57eTmmXlZ18btOaJxtazr/wyp8k p5jHvTc2fk92TMaiZQrN3yeuuBtV5Mls3/ZlwTS+H5NWdr5QYinOSDTUYi4qTgQAMuSHEVsC AAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HoI7xYZOsZ_i5d68sh9aQpHlCo0
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 12:21:25 -0000

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else
Receiver of the answer (and OLR) is the client that sends the request, iden=
tified by "Origin-Host" in the request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention
 If there's an intervening DOIC agent, then the agent, not the client, is t=
he reacting node from the server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node
 But, short of adding an origin-host type, nothing binds the OLR to a parti=
cular client, regardless of DOIC support at the clients.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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 Mon Feb 24 04:43:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4581A0740 for ; Mon, 24 Feb 2014 04:43:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjGDPRS19Ffx for ; Mon, 24 Feb 2014 04:43:18 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4840E1A00AA for ; Mon, 24 Feb 2014 04:43:18 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1OChGux028887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Feb 2014 06:43:17 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1OChFi8028036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Feb 2014 13:43:15 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 13:43:15 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cA==
Date: Mon, 24 Feb 2014 12:43:14 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/epse2_zjRs-yJJqzFKMNuS0Aw_E
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 12:43:21 -0000

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

  =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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 Mon Feb 24 05:03:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950151A0865 for ; Mon, 24 Feb 2014 05:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyvpKXi7v1iG for ; Mon, 24 Feb 2014 05:03:13 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 23D131A0862 for ; Mon, 24 Feb 2014 05:03:12 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-b9-530b430f5b42
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E9.D2.10875.F034B035; Mon, 24 Feb 2014 14:03:12 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 14:02:11 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9w
Date: Mon, 24 Feb 2014 13:02:10 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvja6AM3ewwc6tbBZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49dqz4JfgRUPnuxgb2Cc5dTFyMkhIWAicej7HnYIW0ziwr31 bF2MXBxCAocYJZ68280O4SxmlGibO58ZpIpNwE7i0ukXTF2MHBwiAsoSp385gISFBdQl7ny/ wApiiwhoSDS++cQOURIl8eyQNUiYRUBV4uGOFawgYV4BX4nOWRkQ008zS6zZfBBsOqdArETP xHWMIDYj0D3fT61hArGZBcQlbj2ZzwRxp4DEkj3nmSFsUYmXj/+BzZQQUJRY3i8HUa4ncWPq FDYIW1ti2cLXYOW8AoISJ2c+YZnAKDoLydRZSFpmIWmZhaRlASPLKkb23MTMnPRyw02MwIA/ uOW37g7GU+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxrOm81hvd 7omOBq87HTSCeetqhHSYjVIsyw58NfsjvOlCsg9nooL8e6aKKw+Xx/qwGKgfP7EugyX14d9L 2056M4of99tkwc15TCXRm/3dnO2tMZY3mR5UsyceLL/q9YOJ1SJplSwPu5bFOmlTrzMLT89L fb/6seoiKY5LB41/2E8IrY4+46TEUpyRaKjFXFScCABsyX7TRgIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xRv2EOcY9lIKORMbpbWfKyJviKg
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 13:03:21 -0000

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."=20

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?=20
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

  =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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 Mon Feb 24 05:04:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594921A0862 for ; Mon, 24 Feb 2014 05:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPPnyNlG6ylk for ; Mon, 24 Feb 2014 05:04:09 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 73A991A0479 for ; Mon, 24 Feb 2014 05:04:09 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1OD46GK031230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 14:04:07 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1OD46Mo024919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 14:04:06 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 24 Feb 2014 14:04:05 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 14:04:05 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gAAJQgcAAImOXtA=
Date: Mon, 24 Feb 2014 13:04:04 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4422@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <6D78C2FB-F3A0-4BC5-BEC4-79D8920EE710@nostrum.com>
In-Reply-To: <6D78C2FB-F3A0-4BC5-BEC4-79D8920EE710@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1625
X-purgate-ID: 151667::1393247047-00005322-98E3D5C9/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YARJBuVumWEe2ZuKMgYOOfRDUUU
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 13:04:12 -0000

See inline

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Friday, February 21, 2014 9:18 PM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#35 conclusion


On Feb 21, 2014, at 9:52 AM, Steve Donovan  wrote=
:

> My other concern is that this puts a lot of extra onus on the agent even =
for the case where the reporting node does not want to differentiate overlo=
ad reports.  To this end I suggest we add an indication in the OLR marking =
the reports that are specific to just the Origin-Host in the request.  Abse=
nce of the "single-client-only" AVP would mean that the report applies to a=
ll clients.  Presence of the AVP would indicate that the OLR applies to the=
 Origin-Host.

I support this approach. And of course, being me, I would like that AVP to =
contain the Diameter Identity of the client in question.
why would there be the need to explicitly signal the the client's D=
iameter Identity? Isn't this information somehow available at the agent?

But I wonder--should this be limited to clients? Should it be possible for =
the server to bind an OLR to a particular _agent_? That is, some node on th=
e message path that is not the Origin-Host? For adjacent agents, this is ea=
sy--the server only sends the OLR to that agent. But that won't work for no=
n-adjacent agents.
this shall be limited to clients.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Feb 24 05:12:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDD41A0410 for ; Mon, 24 Feb 2014 05:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpql3L8nSwZV for ; Mon, 24 Feb 2014 05:12:43 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1D37F1A00B9 for ; Mon, 24 Feb 2014 05:12:41 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-0a-530b45482a14
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id A1.E1.04853.8454B035; Mon, 24 Feb 2014 14:12:40 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 14:12:39 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAACD12qAAAlPFjA=
Date: Mon, 24 Feb 2014 13:12:39 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097848DBESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja6HK3ewwdcbihZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8Hv3SwFP+4zVqz9dYC9gfH6EcYuRk4OCQETiUstl1khbDGJ C/fWs3UxcnEICZxglHjz9RILSEJIYDGjxL812SA2m4CdxKXTL5i6GDk4RASUJU7/cgAJCwvE Smy+1AE2R0QgTqLpdAuU7Sdx9vxPsDEsAqoSjzdcAdvLK+Ar8ffCNnaIXe3MEm0XljOBJDgF AiQaFp9gBrEZgQ76fmoNWJxZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8ryD0SAooSy/vlIMrz JZZ/+cIKsUtQ4uTMJywTGEVmIZk0C0nZLCRlEHE9iRtTp7BB2NoSyxa+ZoawdSVm/DvEgiy+ gJF9FaNkcWpxcW66kYFebnpuiV5qUWZycXF+nl5x6iZGYDQd3PLbaAfjyT32hxilOViUxHmv s9YECQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBcFrbGPfjyjvLIg/v3ZTq+K/Fwmr6GoYhB PHzRraetq27Ediaq99477/Z7w/V93VK8p4o2CRrtKxebOX1eQOLp8uqFv6cJ6z08VC0Tx5yu w3zectmczAbp6UzXTh7LmfrdZoLXzicvyvMKnzbfi0xbziotuEZA++Ev/W9Bk37Mufz59b4w E60OJZbijERDLeai4kQA8j8583QCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kPgXhUfe4o-i_8ybMmOA7wP3gak
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 13:12:47 -0000

--_000_087A34937E64E74E848732CFF8354B92097848DBESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I agree with Ulrich's proposal
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 10:46
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion

I share JJacques concern. Replacing "from now on" with "for the period that=
 the overload report is active"
is misleading. May be its better to simply remove "from now on".

Ulrich





From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Friday, February 21, 2014 7:11 PM
To: dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion

Hi MCruz, Steve

I also agree on the "would send " instead of the "would have sent"  for sur=
e.  But I have  a small concern/ clarification  about the Steve comment on =
  "for the period that the overload report is active" and the example to wh=
ich it refers.

During the time the OLR is active, which may be rather long,  the traffic t=
he reacting node would send may be 100 packet  when it has just received th=
e OLR. A bit later, the traffic it would send could be 120 (or 80), and fro=
m the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  whi=
ch I agree. This is in line  with the every 10th packet dropping  on which =
I also agree.

As the text   would  be written with the Steve modification , we may unders=
tand it is  80 Packet during all the time  the OLR is active. Not yet think=
 to an alternative text, but first to see if you agree with my remark.

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com
Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33
=C0 : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

+1 (including Steve comment)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

Maria Cruz,

I support your suggested changes.  I have one further suggested change belo=
w.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:

#52: Throttling not needed to be based on previous history



Following agreement is reached:



 Now (chapter 4.7):

    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

    and describes the percentage of the traffic that the sender is

    requested to reduce, compared to what it otherwise would have sent.



 Proposal:

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would send.          =
        <----





 Now (chapter 5.5.2):

      Indicates that the reporting node urges the reacting node to

      reduce its traffic by a given percentage.  For example if the

      reacting node has been sending 100 packets per second to the

      reporting node, then a reception of OC-Reduction-Percentage value

      of 10 would mean that from now on the reacting node MUST only send

      90 packets per second.  How the reacting node achieves the "true

      reduction" transactions leading to the sent request messages is up

      to the implementation.  The reacting node MAY simply drop every

      10th packet from its output queue and let the generic application

      logic try to recover from it.0 < value < 100



  Proposal:

 Indicates that the reporting node urges the reacting node to reduce

 its traffic by a given percentage. For example if the

 reacting node would send 100 packets to the                          <---

 reporting node, then a reception of OC-Reduction-Percentage value of

 10 would mean that from now on the reacting node MUST only send

 90 packets instead of 100. How the reacting node achieves the "true       =
<---

 reduction" transactions leading to the sent request messages is up to

 the implementation. The reacting node MAY simply drop every 10th

 packet from its output queue and let the generic application logic try

 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"









_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________



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_087A34937E64E74E848732CFF8354B92097848DBESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

 <=
/p>

I agree with Ulrich’=
;s proposal


Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: lunes, 24 de febrero de 2014 10:46

To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previo=
us history - conclusion






 


I share JJacques concern.=
 Replacing
"from now on" with "for the period =
that the overload report is active"


is misleading. May be its=
 better to simply remove “from now on”.


 


Ulrich


 


 


 


 


 






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Friday, February 21, 2014 7:11 PM

To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previo=
us history - conclusion






 


Hi MCruz, Steve


 


I also agree on the ̶=
0;would send ” instead of the “would have sent”  for=
 sure.  But I have  a small concern/ clarification  about th=
e Steve comment on   “for
 the period that the overload report is active” 
and the example to which it refers.


 


During the time the OLR i=
s active, which may be rather long,  the traffic the reacting node wou=
ld send may be 100 packet  when it has just received the OLR.
 A bit later, the traffic it would send could be 120 (or 80), and from the =
OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on&=
nbsp; which I agree. This is in line  with the every 10th packet dropp=
ing  on which I also agree.



  


As the text   w=
ould  be written with the Steve modification , we may understand it is=
  80 Packet during all the time  the OLR is active. Not yet think=
 to an
 alternative text, but first to see if you agree with my remark.


 


JJacques



 


 






De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de lionel.mor=
and@orange.com

Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33

=C0 : Steve Donovan; dime@ietf=
.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


+1 (inclu=
ding Steve comment)


 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


Mar=
ia Cruz,



I support your suggested changes.  I have one further suggested change=
 below.



Steve




On 2/21/14 2:40 AM, Maria Cruz Bar=
tolome wrote:






#52: Throttling not needed to be based on previous h=
istory


 


Following agreement is reached:


 

 Now (chapter 4.7):


    The OC-Reduction-Percentage AVP (=
AVP code TBD8) is type of Unsigned32


    and describes the percentage of t=
he traffic that the sender is

    requested to reduce, compared to =
what it otherwise would have sent.


 


 Proposal:<=
/span>


   The OC-Reduction-Percentage AVP (AVP co=
de TBD8) is type of Unsigned32  


   and describes the percentage of th=
e traffic that the sender is  


   requested to reduce, compared to w=
hat it otherwise would send.        =
;          <----


 


 

 Now (chapter 5.5.2):<=
o:p>


      Indicates that the re=
porting node urges the reacting node to=



      reduce its traffic by=
 a given percentage.  For example if the=



      reacting node has bee=
n sending 100 packets per second to the=



      reporting node, then =
a reception of OC-Reduction-Percentage value<=
/o:p>


      of 10 would mean that=
 from now on the reacting node MUST only send=



      90 packets per second=
.  How the reacting node achieves the "true


      reduction" trans=
actions leading to the sent request messages is up=



      to the implementation=
.  The reacting node MAY simply drop every


      10th packet from its =
output queue and let the generic application<=
/o:p>


      logic try to recover =
from it.0 < value < 100

 

  Proposal:=



 Indicates that the reporting node urges the reactin=
g node to reduce 


 its traffic by a given percentage. For example=
 if the


 reacting node would send 100 packets to the &n=
bsp;            =
;            <---=



 reporting node, then a reception of OC-Reduction-Pe=
rcentage value of 


 10 would mean that from now on the reacting no=
de MUST only send


 90 packets instead of 100. How the reacting node ac=
hieves the "true       <---


 reduction" transactions leading to the sent re=
quest messages is up to 


 the implementation. The reacting node MAY simp=
ly drop every 10th 


 packet from its output queue and let the gener=
ic application logic try 


 to recover from it.




SRD> Replace "from now on&=
quot; in the above with "for the period that the overload report is ac=
tive"












 

 

_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/dime<=
o:p>


 

 


____________________________________________________=
_____________________________________________________________________


 

Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
span lang=3D"DE">


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
span lang=3D"DE">


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.=



 

This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.


Thank you.






--_000_087A34937E64E74E848732CFF8354B92097848DBESESSMB101erics_--


From nobody Mon Feb 24 05:19:17 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D189E1A0852 for ; Mon, 24 Feb 2014 05:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtC7ouRK7M1y for ; Mon, 24 Feb 2014 05:19:13 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 88D731A0471 for ; Mon, 24 Feb 2014 05:19:09 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1ODJ7AW030198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 14:19:07 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1ODJ7k7030682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 14:19:07 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 14:19:06 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDA=
Date: Mon, 24 Feb 2014 13:19:06 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 11424
X-purgate-ID: 151667::1393247947-00005322-4DBD6259/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2vfm0uI1fMCwQVuGYyinP5Li9i8
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 13:19:16 -0000

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 24, 2014 2:02 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."=20

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?=20
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

  =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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

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


From nobody Mon Feb 24 05:26:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E481A0862 for ; Mon, 24 Feb 2014 05:26:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDtdQsKMKZOV for ; Mon, 24 Feb 2014 05:26:31 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E63271A0492 for ; Mon, 24 Feb 2014 05:26:30 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7E6B418C09F; Mon, 24 Feb 2014 14:26:29 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6150635C07B; Mon, 24 Feb 2014 14:26:29 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 14:26:29 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: AQHPLxrEZ6EisnBRQGeKN2pRy2ep65q/5wYAgAAKk4CABDnfIIAAKb6AgAARwXA=
Date: Mon, 24 Feb 2014 13:26:28 +0000
Message-ID: <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.24.83015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VEpcTyMpdzX6sDj33q6q-3rQ-L0
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 13:26:34 -0000

I don't see the issue, as explained in my mail but OK to remove it.=20

If "for now" is removed, the resulting text would be:

  For example if the reacting node has been sending
  100 packets per second to the reporting node, then
  a reception of OC-Reduction-Percentage value=A0of 10
  would mean that from now on the reacting node MUST
  only send 90 packets per second.

Maybe it would be even easier to reverse the sentence as follow:

 For example if an OC-Reduction-Percentage value of=20
=A010 has been received, the reacting node which=20
 would normally send 100 packets MUST only send 90=20
 packets to the reporting node.


But I'm fine if the initial proposed revised text is kept.

Lionel

De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: lundi 24 f=E9vrier 2014 14:13
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] #52: Throttling not needed to be based on previous his=
tory - conclusion

Hello,
=A0
I agree with Ulrich's proposal
Cheers
/MCruz
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 10:46
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion
=A0
I share JJacques concern. Replacing "from now on" with "for the period that=
 the overload report is active"
is misleading. May be its better to simply remove "from now on".
=A0
Ulrich
=A0
=A0
=A0
=A0
=A0
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Friday, February 21, 2014 7:11 PM
To: dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion
=A0
Hi MCruz, Steve
=A0
I also agree on the "would send " instead of the "would have sent" =A0for s=
ure. =A0But I have =A0a small concern/ clarification =A0about the Steve com=
ment on =A0=A0"for the period that the overload report is active" and the e=
xample to which it refers.
=A0
During the time the OLR is active, which may be rather long, =A0the traffic=
 the reacting node would send may be 100 packet =A0when it has just receive=
d the OLR. A bit later, the traffic it would send could be 120 (or 80), and=
 from the OLR definition, =A0=A0it would send 120x0,9 (or 80* 0,9) packets,=
 on=A0 which I agree. This is in line =A0with the every 10th packet droppin=
g =A0on which I also agree.=20
=A0=A0
As the text =A0=A0would =A0be written with the Steve modification , we may =
understand it is =A080 Packet during all the time =A0the OLR is active. Not=
 yet think to an alternative text, but first to see if you agree with my re=
mark.
=A0
JJacques=20
=A0
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 18:33
=C0=A0: Steve Donovan; dime@ietf.org
Objet=A0: Re: [Dime] #52: Throttling not needed to be based on previous his=
tory - conclusion
=A0
+1 (including Steve comment)
=A0
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: vendredi 21 f=E9vrier 2014 16:37
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] #52: Throttling not needed to be based on previous his=
tory - conclusion
=A0
Maria Cruz,

I support your suggested changes.=A0 I have one further suggested change be=
low.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history
=20
Following agreement is reached:
=A0
 Now (chapter 4.7):
=A0=A0=A0 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsign=
ed32
=A0=A0=A0 and describes the percentage of the traffic that the sender is
=A0=A0=A0 requested to reduce, compared to what it otherwise would have sen=
t.
=20
=A0Proposal:
=A0=A0 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned3=
2=A0=20
=A0=A0=A0and describes the percentage of the traffic that the sender is=A0=
=20
=A0=A0=A0requested to reduce, compared to what it otherwise would send.=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <----
=20
=A0
=A0Now (chapter 5.5.2):
=A0=A0=A0=A0=A0 Indicates that the reporting node urges the reacting node to
=A0=A0=A0=A0=A0 reduce its traffic by a given percentage.=A0 For example if=
 the
=A0=A0=A0=A0=A0 reacting node has been sending 100 packets per second to the
=A0=A0=A0=A0=A0 reporting node, then a reception of OC-Reduction-Percentage=
 value
 =A0=A0=A0=A0=A0of 10 would mean that from now on the reacting node MUST on=
ly send
=A0=A0=A0=A0=A0 90 packets per second.=A0 How the reacting node achieves th=
e "true
=A0=A0=A0=A0=A0 reduction" transactions leading to the sent request message=
s is up
=A0=A0=A0=A0=A0 to the implementation.=A0 The reacting node MAY simply drop=
 every
=A0=A0=A0=A0=A0 10th packet from its output queue and let the generic appli=
cation
=A0=A0=A0=A0=A0 logic try to recover from it.0 < value < 100
=A0
=A0 Proposal:
 Indicates that the reporting node urges the reacting node to reduce=20
=A0its traffic by a given percentage. For example if the
 reacting node would send 100 packets to the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <---
 reporting node, then a reception of OC-Reduction-Percentage value of=20
=A010 would mean that from now on the reacting node MUST only send
 90 packets instead of 100. How the reacting node achieves the "true=A0=A0=
=A0=A0=A0=A0 <---
 reduction" transactions leading to the sent request messages is up to=20
=A0the implementation. The reacting node MAY simply drop every 10th=20
=A0packet from its output queue and let the generic application logic try=
=20
=A0to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"





=A0
=A0
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
=A0
=A0
___________________________________________________________________________=
______________________________________________
=A0
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.
=A0
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.


From nobody Mon Feb 24 05:27:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91C91A085C for ; Mon, 24 Feb 2014 05:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U53sulfay8V8 for ; Mon, 24 Feb 2014 05:27:12 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDC41A0046 for ; Mon, 24 Feb 2014 05:27:07 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-8f-530b48aad416
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BF.DE.23809.AA84B035; Mon, 24 Feb 2014 14:27:06 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 14:27:05 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750A==
Date: Mon, 24 Feb 2014 13:27:04 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje4qD+5gg4OfVCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtPNTUwFs+MrerZcZm5gfOPTxcjJISFgIjG5tYkdwhaTuHBv PRuILSRwiFHi5AHBLkYuIHsxo8TP17eYQRJsAnYSl06/YOpi5OAQEVCWOP3LASQsLKAucef7 BVYQW0RAQ6LxzSd2CDtLoun9K7A4i4CqxPmWF4wgNq+Ar8S9ji+sEPOvskh8vz8LrIhTIEDi 6pcWJhCbEeig76fWgNnMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YQe6REFCUWN4vB1GuJ3Fj 6hQ2CFtbYtnC18wQewUlTs58wjKBUXQWkqmzkLTMQtIyC0nLAkaWVYzsuYmZOenlRpsYgUF/ cMtv1R2Md86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj9MYVl5Tc Cxq+vlhvGfpUZXpc2fGaXJEnyz/23r1wbsETpWOh3oudQ8SU3XecedWyJcup6zTX7V27g2f8 LLq8oq5kYR7ziSMi3/dW757ZxZv7sOFpa1yVw4WTG6eFSQqZXpJzneIRXcW28OSZ9v9nm+9N e3zI4Uvy9fvqG2X3c7/8aLzXMn6ughJLcUaioRZzUXEiACTqLKlIAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RzAoeISXVIGj946pE3Xgdg53PTU
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 13:27:17 -0000

Hello Ulrich,

I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.

I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.=20

I think having a new AVP simplifies agent behavior.

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 24, 2014 2:02 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."=20

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?=20
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

  =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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

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


From nobody Mon Feb 24 05:51:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E87B1A085C for ; Mon, 24 Feb 2014 05:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU0QabnZGW2O for ; Mon, 24 Feb 2014 05:51:47 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7407F1A037D for ; Mon, 24 Feb 2014 05:51:46 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1ODpgxo015098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Feb 2014 07:51:43 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1ODpfPx010331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Feb 2014 14:51:42 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 14:51:42 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750AAAjg2g
Date: Mon, 24 Feb 2014 13:51:40 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/X3Zh8zBQOx2G88iWhedwkZgOZTQ
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 13:51:50 -0000

Hi Mcruz

I have not said my proposal was limited to Host OLR. If a DA acting as reac=
ting node receives Realm OLRs in answers to a client of  which DA is acting=
 on behalf, DA will apply the realm OLR throttling to requests without dest=
ination host coming from the client.

Now I am not sure that adding an AVP will simplify the DA life. The princip=
le I have in mind is that each time we add an AVP, this multiply the combin=
ational possibilities and so we have to be careful. To come back to Host OL=
RS, if DA receives an OLR in an answer for Client 1 and an OLR in another  =
answer for client 2 and they are marked as not binded to client, which one =
prevails ? I think there may be some other questions that could 	arise. So =
my priority remains on the baseline, with OLR binded to a client.


Best regards
  =20
JJacques=20
 =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: lundi 24 f=E9vrier 2014 14:27
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] Issue#35 conclusion

Hello Ulrich,

I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.

I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.=20

I think having a new AVP simplifies agent behavior.

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 24, 2014 2:02 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."=20

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?=20
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

  =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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

_______________________________________________
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 Mon Feb 24 06:06:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6D1A088A for ; Mon, 24 Feb 2014 06:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOIEUEVPha7R for ; Mon, 24 Feb 2014 06:06:49 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2A11A0453 for ; Mon, 24 Feb 2014 06:06:49 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 11FEE190562; Mon, 24 Feb 2014 15:06:48 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D5E1B1800B8; Mon, 24 Feb 2014 15:06:47 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 15:06:47 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1j2BaLawTok+U/ijMc7vV8AATUamAABiWF1AACvi8gACOgNbAAAD6+QAAAMPNAAAAqUcAAACXZQAAAEc6AAACsxkQ
Date: Mon, 24 Feb 2014 14:06:46 +0000
Message-ID: <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.24.125115
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NQnWJVnNG3CECJGeT6lbHm0IJ_w
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 14:06:53 -0000

Is it implicit?=20

If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.

Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.

Regards,

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: lundi 24 f=E9vrier 2014 14:27
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] Issue#35 conclusion

Hello Ulrich,

I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.

I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.=20

I think having a new AVP simplifies agent behavior.

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 24, 2014 2:02 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."=20

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?=20
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

=20=20=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=
=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.=20=20=20=20=20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Mon Feb 24 06:10:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4209F1A088E for ; Mon, 24 Feb 2014 06:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3G_itDLwP3U for ; Mon, 24 Feb 2014 06:10:08 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6472E1A0109 for ; Mon, 24 Feb 2014 06:10:08 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1OEA5YJ028437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Feb 2014 08:10:07 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1OEA2b6015205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Feb 2014 15:10:04 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 15:10:04 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MA///ulWA=
Date: Mon, 24 Feb 2014 14:10:03 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.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: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ea3zrjl68q7_VzQ58-E4R7-tqeM
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 14:10:13 -0000

I am in line with Lionel.

JJacques=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran=
ge.com
Envoy=E9=A0: lundi 24 f=E9vrier 2014 15:07
=C0=A0: Maria Cruz Bartolome; dime@ietf.org
Objet=A0: Re: [Dime] Issue#35 conclusion

Is it implicit?=20

If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.

Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.

Regards,

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 14:27 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello Ulrich,

I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.

I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.=20

I think having a new AVP simplifies agent behavior.

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 24, 2014 2:02 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."=20

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?=20
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

  =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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

_______________________________________________
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

___________________________________________________________________________=
______________________________________________

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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.

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


From nobody Mon Feb 24 07:55:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F401A00EA for ; Mon, 24 Feb 2014 07:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LhkIc0ctvNw for ; Mon, 24 Feb 2014 07:55:53 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 990101A015E for ; Mon, 24 Feb 2014 07:55:52 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-f0-530b6b87f869
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A8.C6.23809.78B6B035; Mon, 24 Feb 2014 16:55:51 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 16:55:50 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750AAAjg2gAAR3AsA=
Date: Mon, 24 Feb 2014 15:55:50 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784A14@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW57NnewwcZr8hZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY3LLTdaCj/kVH6YUNzAujepi5OSQEDCR+NN9lAnCFpO4cG89 WxcjF4eQwCFGiXlTGpggnMWMEue2bmYBqWITsJO4dPoFUIKDQ0RAWeL0LweQsLCAusSd7xdY QWwRAQ2Jxjef2CHsMok5T7aygZSzCKhKbGjjBAnzCvhKLHr5kxli/BtWid/H14AdwSkQK7G7 9wYbiM0IdND3UxBxZgFxiVtP5kMdKiCxZM95ZghbVOLl43+sIPMlBBQllvfLQZTrSdyYOoUN wtaWWLbwNTPEXkGJkzOfsExgFJ2FZOosJC2zkLTMQtKygJFlFSN7bmJmTnq50SZGYMgf3PJb dQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDId/D4/R93z92I Kg1zv6f402L3w5b9vOLV5gsW+Oe91d76wHVenekW05OKzJmKf5hvaFj9L5rzx9XsarX66l8n lq9yLj+i+C1bRf6Nv8zVEqv5Sx06V9Y3uD+r3qpULxcc9PjYo691QueMTt9YXfXgyhHVL/oP X/15KC6VnMwR/mv71T+twSltSizFGYmGWsxFxYkAxPDhUkcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Qflg-c4kKMDZz0WMKrdEO74pjbM
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 15:55:56 -0000

Hello JJ,
To the specific case you mentioned:  "To come back to Host OLRS, if DA rece=
ives an OLR in an answer for Client 1 and an OLR in another  answer for cli=
ent 2 and they are marked as not binded to client, which one prevails ?"
If OLRs are not marked as bind to each client, then it means that they appl=
y to any/all clients (what by the way has been our assumption from the begi=
nning until Ulrich started this subject in order to cover 3GPP requirement)=
. Therefore, latest received will apply (if modified).=20

Best regards
/MCruz


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 14:52
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz

I have not said my proposal was limited to Host OLR. If a DA acting as reac=
ting node receives Realm OLRs in answers to a client of  which DA is acting=
 on behalf, DA will apply the realm OLR throttling to requests without dest=
ination host coming from the client.

Now I am not sure that adding an AVP will simplify the DA life. The princip=
le I have in mind is that each time we add an AVP, this multiply the combin=
ational possibilities and so we have to be careful. To come back to Host OL=
RS, if DA receives an OLR in an answer for Client 1 and an OLR in another  =
answer for client 2 and they are marked as not binded to client, which one =
prevails ? I think there may be some other questions that could 	arise. So =
my priority remains on the baseline, with OLR binded to a client.


Best regards
  =20
JJacques=20
 =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 14:27 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello Ulrich,

I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.

I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.=20

I think having a new AVP simplifies agent behavior.

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 24, 2014 2:02 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."=20

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?=20
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.=20
Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.

Best regards

Jacques=20

  =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me Envoy=E9=A0: lundi 24 f=E9vrier 2014 13:21 =C0=A0: dime@ietf.org Objet=
=A0: Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.
Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.
Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.=A0=20

First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.=A0 This, I =
guess, is a general question, not just applying to this proposal.=A0 I sugg=
est we capture in the agent behavior section that is currently missing word=
ing indicating that the first supporting agent that receives the request mu=
st be the reacting node for that non-supporting client.=A0 Subsequent DOIC =
supporting agents must not be the reacting node for the non-supporting clie=
nt.
I fully agree


We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.=A0 On the surface it doesn't seem to be an issue for the loss algorith=
m, but this might not be the case with other algorithms.
I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)

My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.
 I agree 
To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.=A0 Absence of the =
"single-client-only" AVP would mean that the report applies to all clients.=
=A0 Presence of the AVP would indicate that the OLR applies to the Origin-H=
ost.
I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.    =20

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).=20
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.=20

This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

#35: additional report types are proposed
=20
Dear all,
=20
I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:
=20
When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.
 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.
 the binding is always there, regardless of DOIC support at the cli=
ent

 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.

_______________________________________________
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

_______________________________________________
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 Mon Feb 24 07:56:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686811A013D for ; Mon, 24 Feb 2014 07:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.35
X-Spam-Level: 
X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDGxgF9BgUI4 for ; Mon, 24 Feb 2014 07:56:18 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id A4D651A00EA for ; Mon, 24 Feb 2014 07:56:18 -0800 (PST)
Received: from [137.254.4.54] (port=54869 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHxt5-0004Id-96 for dime@ietf.org; Mon, 24 Feb 2014 07:56:17 -0800
Message-ID: <530B6B9D.6010601@usdonovans.com>
Date: Mon, 24 Feb 2014 09:56:13 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------030306020100040800040701"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BJB7ExJXm2Tt14svrQm0Jr_uFG0
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 15:56:22 -0000

This is a multi-part message in MIME format.
--------------030306020100040800040701
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Adding an AVP to indicate that a report applies just to the Origin-Host
in the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a
reporting node (server) would be to report a single overload value to
all reacting nodes, be they clients or agents.  If this is the default
behavior then it would be best to have the default, implicit, meaning of
an overload report to be "applies to all reacting nodes".  The real
value of this new feature is to allow a server to further throttle a
specific, overly active, reacting node when then global reduction
percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single
global reduction percentage then requiring agents to bind an overload
report to each non supporting clients pushes a lot of extra work on
agents when it adds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to
overload reports that indicate when an overload report applies to a
specific reacting node.

- Absence of the AVP indicates that the report applies to all reacting
nodes (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the
overload report contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP
must do the following:
  - For transactions from DOIC-supporting clients the agent must not act
on the OLR.
  - For transactions from non-DOIC-supporting clients the agent must
apply the OLR to traffic from the set of non supporting clients.   This
implies that when making throttling decisions, the agent does not
differentiate which non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a
transaction originated by a non supporting client must bind that OLR to
that single client.

Note that the agent behavior is currently something that is missing from
the -01 version of the draft.  We will need something like this wording
independent of the resolution of this issue.

Steve

On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:
> Is it implicit? 
>
> If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.
>
> Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
> Envoyé : lundi 24 février 2014 14:27
> À : dime@ietf.org
> Objet : Re: [Dime] Issue#35 conclusion
>
> Hello Ulrich,
>
> I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.
>
> I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 
>
> I think having a new AVP simplifies agent behavior.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
> Sent: lunes, 24 de febrero de 2014 14:19
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] Issue#35 conclusion
>
> Hi MCruz,
> there is no reason to limit this to host type OLRs.
>
> If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.
>
> Best regards
> Ulrich
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
> Sent: Monday, February 24, 2014 2:02 PM
> To: dime@ietf.org
> Subject: Re: [Dime] Issue#35 conclusion
>
> Hello JJ and all,
>
> As per email thread, the latest proposal is:
> "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 
>
> An Ulrich comments on this:
> "This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."
>
> Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: lunes, 24 de febrero de 2014 13:43
> To: dime@ietf.org
> Subject: Re: [Dime] Issue#35 conclusion
>
> Hi Mcruz and all
>
> I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
> Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .
>
> For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.
>
> Best regards
>
> Jacques 
>
>    
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion
>
> Hello all,
>
> Not sure we all have the same understanding here.
> Let me try to explain my concerns.
>
> The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.
> Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:
>
> a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
> Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
> But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
> Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):
> "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."
> But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.
> How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:
> - C1 sends a Realm request via Agent, that finally reaches S1
> - S1 answers with OLR (Host:50%).
> - Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?
> In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.
>
> b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.
> With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.
>
> Let me know your opinions please
> Best regards
> /MCruz
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
> Sent: lunes, 24 de febrero de 2014 12:28
> To: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] Issue#35 conclusion
>
> Steve,
>
> please see inline.
>
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Friday, February 21, 2014 4:53 PM
> To: dime@ietf.org
> Subject: Re: [Dime] Issue#35 conclusion
>
> Ulrich,
>
> I have a couple of concerns with this approach, as currently outlined.  
>
> First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.
> I fully agree
>
>
> We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.
> I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)
>
> My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.
>  I agree 
> To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.
> I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.     
>
> Steve
> On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ben,
>
> the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
> Now you seem to address two points:
> a) There is no dependency to DOIC support of the client.
> To address this I would like to propose rewording of the clarifying text for 5.5. as follows:
>
> When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 
>
> This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.
>
> b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
> 1. ignore the 3GPP requirement
> 2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.
>
> So far I understood that people favoured option 3.
>
> See also inline.
>
> Ulrich
>
>
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, February 20, 2014 11:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] Issue#35 conclusion
>
>
> On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>
> #35: additional report types are proposed
>  
> Dear all,
>  
> I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>  
> When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.
>
> I do not agree.
>
> You proposal implies that the server's OLR only applies to that client.
> exactly, that was the intention  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
>  the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>  the binding is always there, regardless of DOIC support at the client
>
>  Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------030306020100040800040701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Adding an AVP to indicate
      that a report applies just to the Origin-Host in the request is
      not just an optimization for agents.

      

      It had been my assumption all along that the default behavior of a
      reporting node (server) would be to report a single overload value
      to all reacting nodes, be they clients or agents.  If this is the
      default behavior then it would be best to have the default,
      implicit, meaning of an overload report to be "applies to all
      reacting nodes".  The real value of this new feature is to allow a
      server to further throttle a specific, overly active, reacting
      node when then global reduction percentage doesn't do the job.

      

      In addition, if the normal case is that reporting nodes have a
      single global reduction percentage then requiring agents to bind
      an overload report to each non supporting clients pushes a lot of
      extra work on agents when it adds no value.

      

      My proposal is the following:

      

      - Add an optional AVP (call it something like Single-Node???) to
      overload reports that indicate when an overload report applies to
      a specific reacting node.

      

      - Absence of the AVP indicates that the report applies to all
      reacting nodes (clients and agents acting on behalf of non-DOIC
      clients).

      

      - Reporting nodes should only include the Single-Node AVP if the
      overload report contents are different from the global overload
      report.

      

      - DOIC-supporting agents receiving an OLR without the Single-Node
      AVP must do the following:

        - For transactions from DOIC-supporting clients the agent must
      not act on the OLR.

        - For transactions from non-DOIC-supporting clients the agent
      must apply the OLR to traffic from the set of non supporting
      clients.   This implies that when making throttling decisions, the
      agent does not differentiate which non supporting client
      originated the request.

      

      - DOIC-supporting agents receiving an OLR with the Single-Node AVP
      for a transaction originated by a non supporting client must bind
      that OLR to that single client.

      

      Note that the agent behavior is currently something that is
      missing from the -01 version of the draft.  We will need something
      like this wording independent of the resolution of this issue.

      

      Steve

      

    
    
On 2/24/14 8:06 AM,
      lionel.morand@orange.com wrote:

    

    

      
Is it implicit? 

If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.

Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : lundi 24 février 2014 14:27
À : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Hello Ulrich,

I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.

I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 

I think having a new AVP simplifies agent behavior.

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 2:02 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

Best regards

Jacques 

   

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.
Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:

a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

Let me know your opinions please
Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I have a couple of concerns with this approach, as currently outlined.  

First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.
<Ulrich>I fully agree</Ulrich>


We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.
<Ulrich>I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>

My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.
<Ulrich> I agree </Ulrich>
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.
<Ulrich>I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

Steve
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ben,

the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text for 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 

This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

#35: additional report types are proposed
 
Dear all,
 
I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
 
When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client.
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.

_______________________________________________
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

_______________________________________________
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

_________________________________________________________________________________________________________________________

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.

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



    

    

  


--------------030306020100040800040701--


From nobody Mon Feb 24 07:59:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740C01A0056 for ; Mon, 24 Feb 2014 07:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.35
X-Spam-Level: 
X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGzpgnf8ZPFB for ; Mon, 24 Feb 2014 07:59:34 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 97A301A015E for ; Mon, 24 Feb 2014 07:59:34 -0800 (PST)
Received: from [137.254.4.54] (port=59507 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHxwJ-00010t-5v for dime@ietf.org; Mon, 24 Feb 2014 07:59:33 -0800
Message-ID: <530B6C65.8080707@usdonovans.com>
Date: Mon, 24 Feb 2014 09:59:33 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------030103070304020000090506"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/awx-5-1cg9g5EpD6eK0sxqpzJVc
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 15:59:37 -0000

This is a multi-part message in MIME format.
--------------030103070304020000090506
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I'm with Lionel.  I don't understand why the proposed wording is
confusing.  Reacting nodes always only apply the reduction percentage
for the period of time that the specific overload report is active. 
That period either ends when a new overload report is received or when
the overload report expires.

That said, I'm happy with just removing the words "from no on" as
proposed by Lionel below.

Steve
 
On 2/24/14 7:26 AM, lionel.morand@orange.com wrote:
> I don't see the issue, as explained in my mail but OK to remove it. 
>
> If "for now" is removed, the resulting text would be:
>
>   For example if the reacting node has been sending
>   100 packets per second to the reporting node, then
>   a reception of OC-Reduction-Percentage value of 10
>   would mean that from now on the reacting node MUST
>   only send 90 packets per second.
>
> Maybe it would be even easier to reverse the sentence as follow:
>
>  For example if an OC-Reduction-Percentage value of 
>  10 has been received, the reacting node which 
>  would normally send 100 packets MUST only send 90 
>  packets to the reporting node.
>
>
> But I'm fine if the initial proposed revised text is kept.
>
> Lionel
>
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
> Envoyé : lundi 24 février 2014 14:13
> À : dime@ietf.org
> Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>
> Hello,
>  
> I agree with Ulrich's proposal
> Cheers
> /MCruz
>  
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
> Sent: lunes, 24 de febrero de 2014 10:46
> To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
> Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>  
> I share JJacques concern. Replacing "from now on" with "for the period that the overload report is active"
> is misleading. May be its better to simply remove "from now on".
>  
> Ulrich
>  
>  
>  
>  
>  
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: Friday, February 21, 2014 7:11 PM
> To: dime@ietf.org
> Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>  
> Hi MCruz, Steve
>  
> I also agree on the "would send " instead of the "would have sent"  for sure.  But I have  a small concern/ clarification  about the Steve comment on   "for the period that the overload report is active" and the example to which it refers.
>  
> During the time the OLR is active, which may be rather long,  the traffic the reacting node would send may be 100 packet  when it has just received the OLR. A bit later, the traffic it would send could be 120 (or 80), and from the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  which I agree. This is in line  with the every 10th packet dropping  on which I also agree. 
>   
> As the text   would  be written with the Steve modification , we may understand it is  80 Packet during all the time  the OLR is active. Not yet think to an alternative text, but first to see if you agree with my remark.
>  
> JJacques 
>  
>  
> De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
> Envoyé : vendredi 21 février 2014 18:33
> À : Steve Donovan; dime@ietf.org
> Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>  
> +1 (including Steve comment)
>  
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoyé : vendredi 21 février 2014 16:37
> À : dime@ietf.org
> Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
>  
> Maria Cruz,
>
> I support your suggested changes.  I have one further suggested change below.
>
> Steve
> On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
> #52: Throttling not needed to be based on previous history
>  
> Following agreement is reached:
>  
>  Now (chapter 4.7):
>     The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
>     and describes the percentage of the traffic that the sender is
>     requested to reduce, compared to what it otherwise would have sent.
>  
>  Proposal:
>    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  
>    and describes the percentage of the traffic that the sender is  
>    requested to reduce, compared to what it otherwise would send.                  <----
>  
>  
>  Now (chapter 5.5.2):
>       Indicates that the reporting node urges the reacting node to
>       reduce its traffic by a given percentage.  For example if the
>       reacting node has been sending 100 packets per second to the
>       reporting node, then a reception of OC-Reduction-Percentage value
>       of 10 would mean that from now on the reacting node MUST only send
>       90 packets per second.  How the reacting node achieves the "true
>       reduction" transactions leading to the sent request messages is up
>       to the implementation.  The reacting node MAY simply drop every
>       10th packet from its output queue and let the generic application
>       logic try to recover from it.0 < value < 100
>  
>   Proposal:
>  Indicates that the reporting node urges the reacting node to reduce 
>  its traffic by a given percentage. For example if the
>  reacting node would send 100 packets to the                          <---
>  reporting node, then a reception of OC-Reduction-Percentage value of 
>  10 would mean that from now on the reacting node MUST only send
>  90 packets instead of 100. How the reacting node achieves the "true       <---
>  reduction" transactions leading to the sent request messages is up to 
>  the implementation. The reacting node MAY simply drop every 10th 
>  packet from its output queue and let the generic application logic try 
>  to recover from it.
> SRD> Replace "from now on" in the above with "for the period that the overload report is active"
>
>
>
>
>
>  
>  
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>  
>  
> _________________________________________________________________________________________________________________________
>  
> 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.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------030103070304020000090506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I'm with Lionel.  I don't
      understand why the proposed wording is confusing.  Reacting nodes
      always only apply the reduction percentage for the period of time
      that the specific overload report is active.  That period either
      ends when a new overload report is received or when the overload
      report expires.

      

      That said, I'm happy with just removing the words "from no on" as
      proposed by Lionel below.

      

      Steve

       

    
On 2/24/14 7:26 AM,
      lionel.morand@orange.com wrote:

    

    

      
I don't see the issue, as explained in my mail but OK to remove it. 

If "for now" is removed, the resulting text would be:

  For example if the reacting node has been sending
  100 packets per second to the reporting node, then
  a reception of OC-Reduction-Percentage value of 10
  would mean that from now on the reacting node MUST
  only send 90 packets per second.

Maybe it would be even easier to reverse the sentence as follow:

 For example if an OC-Reduction-Percentage value of 
 10 has been received, the reacting node which 
 would normally send 100 packets MUST only send 90 
 packets to the reporting node.


But I'm fine if the initial proposed revised text is kept.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : lundi 24 février 2014 14:13
À : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

Hello,
 
I agree with Ulrich's proposal
Cheers
/MCruz
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 10:46
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
I share JJacques concern. Replacing "from now on" with "for the period that the overload report is active"
is misleading. May be its better to simply remove "from now on".
 
Ulrich
 
 
 
 
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Friday, February 21, 2014 7:11 PM
To: dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
Hi MCruz, Steve
 
I also agree on the "would send " instead of the "would have sent"  for sure.  But I have  a small concern/ clarification  about the Steve comment on   "for the period that the overload report is active" and the example to which it refers.
 
During the time the OLR is active, which may be rather long,  the traffic the reacting node would send may be 100 packet  when it has just received the OLR. A bit later, the traffic it would send could be 120 (or 80), and from the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  which I agree. This is in line  with the every 10th packet dropping  on which I also agree. 
  
As the text   would  be written with the Steve modification , we may understand it is  80 Packet during all the time  the OLR is active. Not yet think to an alternative text, but first to see if you agree with my remark.
 
JJacques 
 
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
Envoyé : vendredi 21 février 2014 18:33
À : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
+1 (including Steve comment)
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : vendredi 21 février 2014 16:37
À : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
Maria Cruz,

I support your suggested changes.  I have one further suggested change below.

Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history
 
Following agreement is reached:
 
 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.
 
 Proposal:
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  
   and describes the percentage of the traffic that the sender is  
   requested to reduce, compared to what it otherwise would send.                  <----
 
 
 Now (chapter 5.5.2):
      Indicates that the reporting node urges the reacting node to
      reduce its traffic by a given percentage.  For example if the
      reacting node has been sending 100 packets per second to the
      reporting node, then a reception of OC-Reduction-Percentage value
      of 10 would mean that from now on the reacting node MUST only send
      90 packets per second.  How the reacting node achieves the "true
      reduction" transactions leading to the sent request messages is up
      to the implementation.  The reacting node MAY simply drop every
      10th packet from its output queue and let the generic application
      logic try to recover from it.0 < value < 100
 
  Proposal:
 Indicates that the reporting node urges the reacting node to reduce 
 its traffic by a given percentage. For example if the
 reacting node would send 100 packets to the                          <---
 reporting node, then a reception of OC-Reduction-Percentage value of 
 10 would mean that from now on the reacting node MUST only send
 90 packets instead of 100. How the reacting node achieves the "true       <---
 reduction" transactions leading to the sent request messages is up to 
 the implementation. The reacting node MAY simply drop every 10th 
 packet from its output queue and let the generic application logic try 
 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overload report is active"





 
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
_________________________________________________________________________________________________________________________
 
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.

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



    

    

  


--------------030103070304020000090506--


From nobody Mon Feb 24 08:19:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0911A016E for ; Mon, 24 Feb 2014 08:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level: 
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrtrByj6jzTa for ; Mon, 24 Feb 2014 08:19:41 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 710571A0112 for ; Mon, 24 Feb 2014 08:19:41 -0800 (PST)
Received: from localhost ([127.0.0.1]:43987 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WHyFh-0000xJ-4z; Mon, 24 Feb 2014 17:19:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Feb 2014 16:19:33 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/57
Message-ID: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org>
X-Trac-Ticket-ID: 57
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5TQ4TghEmD4AwJtNttrh8b6GFpo
Cc: dime@ietf.org
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@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, 24 Feb 2014 16:19:43 -0000

#57: Handling of "Realm-Routed" Overload report type

 I'm assuming the name of the realm overload report in the -01 version will
 be changed to realm-routed.  This issue applies independent of the actual
 name of the report.

 The current behavior assumed for the realm-routed report is that the
 reacting node, generally the client, will reduce the percentage of realm
 routed requests sent to the reporting node.

 This is actually bad behavior and could result in the client throttling
 traffic that could have been handled by the full set of servers for that
 Diameter application.

 Consider the case where there are n servers for a Diameter application and
 all of those server are able to handle any transaction for that
 application.

 When one of those servers becomes overloaded and wishes to decrease the
 number of new sessions, the primary use of realm-routed requests.  The
 server will generate an OLR of type realm-routed.

 Assume in this case that the other servers are all healthy and able to
 handle new sessions.

 Clients will not have the knowledge that there are other servers in the
 network able to handle the new session and will have no choice but the
 throttle a percentage of the new session requests.  Even when these
 throttled requests could have been handled by any of the non overloaded
 servers.

 The proposal is to specify that realm-routed reports must be handled by
 DOIC-supporting agents.  Agents will understand if there are other servers
 able to handle the new session and, if so, can adjust the percentage of
 requests routed to the overloaded server.

 Agents that handle the realm-routed OLR must remove the request from the
 answer before relaying the answer to client.  This prevents the report
 from being acted on by either multiple agents (if multiple are in the
 path) or by an agent and a client.

 Clients that receive the realm-routed OLR must handle the OLR by
 throttling the requested percentage.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-docdt-dime-ovli    |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Mon Feb 24 08:23:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDB51A0180 for ; Mon, 24 Feb 2014 08:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16LHQ3epvFg8 for ; Mon, 24 Feb 2014 08:22:56 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E85DE1A0112 for ; Mon, 24 Feb 2014 08:22:55 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-c4-530b71de04be
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 02.A9.04249.ED17B035; Mon, 24 Feb 2014 17:22:54 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 17:22:53 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [dime] #56: Bad Description of Overload Control State
Thread-Index: AQHPLKXn/K5opEUqEkqiVdwfHsd6G5rEUNjAgABMwyA=
Date: Mon, 24 Feb 2014 16:22:53 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784A7E@ESESSMB101.ericsson.se>
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje69Qu5gg803NS3m9q5gs5iy4g+T A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxq62JqeCgYUXP7mVMDYxv1boYOTkkBEwk pq2ewwxhi0lcuLeeDcQWEjjCKHH3vk4XIxeQvZhRYu6PG4wgCTYBO4lLp18wdTFycIgIlEhM bdMFCQsLOEksvbyBHcQWEXCWmDZnGZRtJfH38h0wm0VAVWLuxNVMIDavgK/ExxeXmSDm9zBK vG+bA5bgFAiQeNX9CqyBEeig76fWgMWZBcQlbj2ZzwRxqIDEkj3noY4WlXj5+B8ryD0SAooS y/vlIMp1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnUWkpZZSFpmIWlZwMiyipGjOLU4 KTfdyGATIzAWDm75bbGD8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLg lGpgPPfhTkbfQ0lmfZFnSak3zUX6PNQW/prsw8n29u/e+mOHZzwo3Hfi6/UKhQlfZm4Rvxr0 ha92QWfyQm6hWPWHKdVLf2mdW/jTVepVot7jpEfX6hZPqambpPhz7pbPe4zbN5yewhkrtNVI 4Xfemv95rdzXGdj7K+fMuJ+4vHxxymENS7ufm3ZE8CixFGckGmoxFxUnAgDFeKq/UwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vIBZOA5BOG847mEGtEhzMqLjy0c
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 16:23:01 -0000

Ulrich,

In your proposal you newly define overload control states per client/origin=
-host.
This is very related to the ongoing discussion in Issue#35. Then, at least =
I think we need to first conclude on that thread.

A part from that,  we need to take into account that 3GPP requirement on ov=
erload mitigation differentiation per client is a server option:
TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".

Therefore, it could be better to keep this differentiation per client/origi=
n-host out of chapter 5.5.1.

Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:44
To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

There has been no discussion of this ticket.

I propose to replace text in claues 5.5.1 as suggested in the ticket.

Regards
Ulrich


-----Original Message-----
From: ext dime issue tracker [mailto:trac+dime@grenache.tools.ietf.org]
Sent: Tuesday, February 18, 2014 1:35 PM
To: draft-docdt-dime-ovli@tools.ietf.org; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: [dime] #56: Bad Description of Overload Control State

#56: Bad Description of Overload Control State

 The description of Overload Control State in clause 5.5.1 is inaccurate,  =
incomplete and could be misleading. It does not differentiate between  Over=
load Control State in a reacting node versus Overload Control State in  a r=
eporting node. It also does not describe how Overload Control States  are m=
aintained.

 It is proposed to replace current text with the following:


 5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node (client) maintains per supported Diameter application
    a host-type Overload Control State for each Destination-Host towards
    which it sends host-type requests and a realm-type Overload Control  St=
ate
    for each Destination-Realm toward which it sends realm-type requests.
    A host-type Overload Control State may be identified by the pair of
    Application-Id and Destination-Host; a realm-type Overload Control  Sta=
te
    may be identified by the pair of Application-Id and Destination-Realm.
    The host-type/realm-type Overload Control State for a given pair of
    Application and Destination-Host / Destination-Realm could include the
    information as shown in table 1/table 2.

    

    Agents that take the role of a reacting node on behalf of clients MUST
    maintain Overload Control States per client.

    5.5.1.2   Overload Control States for reporting nodes

    A reporting node (server) maintains per supported Diameter application
    an Overload Control State for each Origin-Host from which it receives
    requests that contain an (explicit or implicit) indication of
    OLR_DEFAULT_ALGO support.

    A reporting node (agent that is configured to take the role of a
    reporting node for a given realm) maintains per supported Diameter
    application an Overload Control State for each Origin-Host from which  =
it
    receives realm-type requests (of that given realm) that contain an
    (explicit or implicit) indication of OLR_DEFAULT_ALGO support.

    A Overload Control State may be identified by the pair of Application- =
 Id
    and Origin-Host.

    The Overload Control State for a given pair of Application and Origin-
    Host could include the information as shown in table 3.
    

    Note: For nodes that support other features than just OLR_DEFAULT_ALGO
    the Overload Control State definitions may need to be extended.

    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS with OCS-Id =3D (x,A) when  recei=
ving
    an answer message of application x containing an Orig-Host of A and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS with OCS-Id =3D (x,A) when  rece=
iving
    an answer message of application x containing an Orig-Realm of A and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS with OCS-Id =3D (x,A) when
    receiving an answer message of application x containing an Orig-Host of
    A and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS with OCS-Id =3D (x,A) when
    receiving an answer message of application x containing an Orig-Realm  =
of
    A and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS with OCS-Id =3D (x,A) when receiving a
    request (indicating support of OLR_DEFAULT_ALGO) of application x
    containing an Orig-Host of A unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS with OCS-Id =3D (x,A) when they detect t=
he
    need to modify the requested amount of application x traffic reduction
    generated by A.

--=20
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |      Owner:  draft-docdt-dime-
  ulrich.wiehe@nsn.com   |  ovli@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  draft-       |    Version:
  docdt-dime-ovli        |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: 
dime 

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


From nobody Mon Feb 24 08:45:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2231E1A00B7 for ; Mon, 24 Feb 2014 08:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.549
X-Spam-Level: *
X-Spam-Status: No, score=1.549 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j_8qTh0nXis for ; Mon, 24 Feb 2014 08:45:32 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3C1A0087 for ; Mon, 24 Feb 2014 08:45:32 -0800 (PST)
Received: from [137.254.4.54] (port=14263 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHyel-0005dN-3b for dime@ietf.org; Mon, 24 Feb 2014 08:45:31 -0800
Message-ID: <530B7729.3010005@usdonovans.com>
Date: Mon, 24 Feb 2014 10:45:29 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090408030701020707070806"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wH-_GxJ-XrgnGB7vOM4KG5fx8r8
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 16:45:34 -0000

This is a multi-part message in MIME format.
--------------090408030701020707070806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

See inline.

Steve

On 2/24/14 5:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> There has been no discussion of this ticket.
>
> I propose to replace text in claues 5.5.1 as suggested in the ticket.
>
> Regards
> Ulrich
>
>
> -----Original Message-----
> From: ext dime issue tracker [mailto:trac+dime@grenache.tools.ietf.org] 
> Sent: Tuesday, February 18, 2014 1:35 PM
> To: draft-docdt-dime-ovli@tools.ietf.org; Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: [dime] #56: Bad Description of Overload Control State
>
> #56: Bad Description of Overload Control State
>
>  The description of Overload Control State in clause 5.5.1 is inaccurate,
>  incomplete and could be misleading. It does not differentiate between
>  Overload Control State in a reacting node versus Overload Control State in
>  a reporting node. It also does not describe how Overload Control States
>  are maintained.
>
>  It is proposed to replace current text with the following:
>
>
>  5.5.1.  Overload Control State (OCS)
>
>     5.5.1.1   Overload Control States for reacting nodes
>
>     A reacting node (client) maintains per supported Diameter application
SRD> Why qualify with client.  It applies to all reacting nodes.
>     a host-type Overload Control State for each Destination-Host towards
>     which it sends host-type requests and a realm-type Overload Control
>  State
SRD> ...and... (add the word and here)
>     for each Destination-Realm toward which it sends realm-type requests.
>     A host-type Overload Control State may be identified by the pair of
>     Application-Id and Destination-Host; a realm-type Overload Control
>  State
>     may be identified by the pair of Application-Id and Destination-Realm.
>     The host-type/realm-type Overload Control State for a given pair of
>     Application and Destination-Host / Destination-Realm could include the
>     information as shown in table 1/table 2.
>
>     
SRD> Reception time and validity duration could be replaced with
"expiration time"
>
>     Agents that take the role of a reacting node on behalf of clients MUST
>     maintain Overload Control States per client.
SRD> This depends on the resolution of the current discussion of issue
35.  I propose it be modified to "Agents that take the reacting node on
behalf of non-supporting clients must maintain either the global
overload state or per client overload state if requested by the
reporting node.
>
>     5.5.1.2   Overload Control States for reporting nodes
>
>     A reporting node (server) maintains per supported Diameter application
SRD> There is no reason to qualify the reporting node as a server.  It
could also be an agent and all of this still applies.
>     an Overload Control State for each Origin-Host from which it receives
>     requests that contain an (explicit or implicit) indication of
>     OLR_DEFAULT_ALGO support.
SRD> It doesn't need to be per Origin-Host, per the discussion of issue
35.  We should support a global overload state if the reporting node
doesn't which to keep per reacting node state.
>
>     A reporting node (agent that is configured to take the role of a
>     reporting node for a given realm) maintains per supported Diameter
>     application an Overload Control State for each Origin-Host from which
>  it
>     receives realm-type requests (of that given realm) that contain an
>     (explicit or implicit) indication of OLR_DEFAULT_ALGO support.
>
>     A Overload Control State may be identified by the pair of Application-
>  Id
>     and Origin-Host.
SRD> I don't see this as a must.  It could be identified by just
Application-ID.
>
>     The Overload Control State for a given pair of Application and Origin-
>     Host could include the information as shown in table 3.
>     
SRD> Expiration time should be sufficient.
>
>     Note: For nodes that support other features than just OLR_DEFAULT_ALGO
>     the Overload Control State definitions may need to be extended.
>
>     5.5.1.3  Maintaining Overload Control States
>
>     Reacting nodes create a host-type OCS with OCS-Id = (x,A) when
>  receiving
>     an answer message of application x containing an Orig-Host of A and a
>     host-type OC-OLR AVP unless such host-type OCS already exists.
>
>     Reacting nodes create a realm-type OCS with OCS-Id = (x,A) when
>  receiving
>     an answer message of application x containing an Orig-Realm of A and a
>     realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>     Reacting nodes delete an OCS when it expires (i.e. when current time
>     minus reception time is greater than validity duration).
>
>     Reacting nodes update the host-type OCS with OCS-Id = (x,A) when
>     receiving an answer message of application x containing an Orig-Host of
>     A and a host-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reacting nodes update the realm-type OCS with OCS-Id = (x,A) when
>     receiving an answer message of application x containing an Orig-Realm
>  of
>     A and a realm-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reporting nodes create an OCS with OCS-Id = (x,A) when receiving a
>     request (indicating support of OLR_DEFAULT_ALGO) of application x
>     containing an Orig-Host of A unless such OCS already exists.
SRD> Why would the reporting node create an OCS when it is not
overloaded?  Shouldn't this be modified to say that the reporting nodes
creates an OCS when receiving a request and when in an overloaded state
for the application?  Also, we should not require that the reporting
node keep state for all reacting nodes, it should be able to keep a
single state for all reacting nodes.
>
>     Reporting nodes delete an OCS when it expires.
SRD> or when the reporting node exits the overload state.  This should
be after the reporting node sends an overload report with validity
duration of zero to reacting nodes.
>
>     Reporting nodes update the OCS with OCS-Id = (x,A) when they detect the
>     need to modify the requested amount of application x traffic reduction
>     generated by A.
>


--------------090408030701020707070806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      See inline.

      

      Steve

      

    
    
On 2/24/14 5:44 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
There has been no discussion of this ticket.

I propose to replace text in claues 5.5.1 as suggested in the ticket.

Regards
Ulrich


-----Original Message-----
From: ext dime issue tracker [mailto:trac+dime@grenache.tools.ietf.org] 
Sent: Tuesday, February 18, 2014 1:35 PM
To: draft-docdt-dime-ovli@tools.ietf.org; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: [dime] #56: Bad Description of Overload Control State

#56: Bad Description of Overload Control State

 The description of Overload Control State in clause 5.5.1 is inaccurate,
 incomplete and could be misleading. It does not differentiate between
 Overload Control State in a reacting node versus Overload Control State in
 a reporting node. It also does not describe how Overload Control States
 are maintained.

 It is proposed to replace current text with the following:


 5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node (client) maintains per supported Diameter application

    

    SRD> Why qualify with client.  It applies to all reacting nodes.

    

      
    a host-type Overload Control State for each Destination-Host towards
    which it sends host-type requests and a realm-type Overload Control
 State

    

    SRD> ...and... (add the word and here)

    

      
    for each Destination-Realm toward which it sends realm-type requests.
    A host-type Overload Control State may be identified by the pair of
    Application-Id and Destination-Host; a realm-type Overload Control
 State
    may be identified by the pair of Application-Id and Destination-Realm.
    The host-type/realm-type Overload Control State for a given pair of
    Application and Destination-Host / Destination-Realm could include the
    information as shown in table 1/table 2.

    <see attachment>

    

    SRD> Reception time and validity duration could be replaced with
    "expiration time"

    

      

    Agents that take the role of a reacting node on behalf of clients MUST
    maintain Overload Control States per client.

    

    SRD> This depends on the resolution of the current discussion of
    issue 35.  I propose it be modified to "Agents that take the
    reacting node on behalf of non-supporting clients must maintain
    either the global overload state or per client overload state if
    requested by the reporting node.

    

      

    5.5.1.2   Overload Control States for reporting nodes

    A reporting node (server) maintains per supported Diameter application

    

    SRD> There is no reason to qualify the reporting node as a
    server.  It could also be an agent and all of this still applies.

    

      
    an Overload Control State for each Origin-Host from which it receives
    requests that contain an (explicit or implicit) indication of
    OLR_DEFAULT_ALGO support.

    

    SRD> It doesn't need to be per Origin-Host, per the discussion of
    issue 35.  We should support a global overload state if the
    reporting node doesn't which to keep per reacting node state.

    

      

    A reporting node (agent that is configured to take the role of a
    reporting node for a given realm) maintains per supported Diameter
    application an Overload Control State for each Origin-Host from which
 it
    receives realm-type requests (of that given realm) that contain an
    (explicit or implicit) indication of OLR_DEFAULT_ALGO support.

    A Overload Control State may be identified by the pair of Application-
 Id
    and Origin-Host.

    

    SRD> I don't see this as a must.  It could be identified by just
    Application-ID.

    

      

    The Overload Control State for a given pair of Application and Origin-
    Host could include the information as shown in table 3.
    <see attachment>

    

    SRD> Expiration time should be sufficient.

    

      

    Note: For nodes that support other features than just OLR_DEFAULT_ALGO
    the Overload Control State definitions may need to be extended.

    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS with OCS-Id = (x,A) when
 receiving
    an answer message of application x containing an Orig-Host of A and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS with OCS-Id = (x,A) when
 receiving
    an answer message of application x containing an Orig-Realm of A and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS with OCS-Id = (x,A) when
    receiving an answer message of application x containing an Orig-Host of
    A and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS with OCS-Id = (x,A) when
    receiving an answer message of application x containing an Orig-Realm
 of
    A and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS with OCS-Id = (x,A) when receiving a
    request (indicating support of OLR_DEFAULT_ALGO) of application x
    containing an Orig-Host of A unless such OCS already exists.

    

    SRD> Why would the reporting node create an OCS when it is not
    overloaded?  Shouldn't this be modified to say that the reporting
    nodes creates an OCS when receiving a request and when in an
    overloaded state for the application?  Also, we should not require
    that the reporting node keep state for all reacting nodes, it should
    be able to keep a single state for all reacting nodes.

    

      

    Reporting nodes delete an OCS when it expires.

    

    SRD> or when the reporting node exits the overload state.  This
    should be after the reporting node sends an overload report with
    validity duration of zero to reacting nodes.

    

      

    Reporting nodes update the OCS with OCS-Id = (x,A) when they detect the
    need to modify the requested amount of application x traffic reduction
    generated by A.



    

    

  


--------------090408030701020707070806--


From nobody Mon Feb 24 08:55:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7771A01C6 for ; Mon, 24 Feb 2014 08:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zErs-aMWqe3v for ; Mon, 24 Feb 2014 08:55:02 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E2ECB1A00EF for ; Mon, 24 Feb 2014 08:55:02 -0800 (PST)
Received: from [137.254.4.54] (port=33334 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHyny-0003Mz-FD; Mon, 24 Feb 2014 08:55:01 -0800
Message-ID: <530B7965.8070202@usdonovans.com>
Date: Mon, 24 Feb 2014 10:55:01 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> <530519F7.1010207@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B40C7@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B40C7@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------000009070803090601020509"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OMJPWolnC7zi6Kax6bZPvqPcH_Y
Subject: Re: [Dime] [dime] #23: DOIC behavior for realm overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 16:55:05 -0000

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

Ulrich,

For the following:

---

We also have proposed wording on the interaction between these report types.  

 can you please remind me what that proposed wording is. My current understanding is that there is no interaction between these two report types

--- 

I agree with you that there is no interaction between the host reports
and "realm-routed" reports (or what ever we end up calling them).

Steve
 
On 2/21/14 1:07 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> see inline.
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Wednesday, February 19, 2014 9:54 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #23: DOIC behavior for realm overload
>
> We've had a lot of discussion of this topic.
>
> I believe that we reached agreement that we currently have two types of reports:
>
> - Host report that applies to requests sent to a destination-host
> - Realm report that applies requests routed to a realm that do not have a specified destination-host (realm-routed requests)
>
>  I agree
>
> We also have proposed wording on the interaction between these report types.  
>
>  can you please remind me what that proposed wording is. My current understanding is that there is no interaction between these two report types
>
> I propose that the second be renamed to realm-routed reports.
>
>  no strong view, but my preference is in favour of "absent-host reports"
>
> A separate ticket has been opened on the need for a third report type that would apply to all request routed to a realm, independent of whether a request contains a destination-host AVP.
>  I understand that this is #55
>
> Steve
> On 1/21/14 9:24 AM, dime issue tracker wrote:
> #23: DOIC behavior for realm overload
>
>  This applies to draft-ietf-dime-ovli-01, which does not show up in the
>  Component drop down menu.
>
>  The current assumption in the -01 draft is inconsistent in the definition
>  of behavior of behavior by a reacting node when it receives a realm
>  overload report.
>
>  Section 4.6 says overload treatment should apply to all request bound for
>  the overloaded realm.
>
>  Section 5.5.2 is not clear and there have been interpretations that a
>  realm overload report only applies to requests that contain the realm and
>  do not contain a destination-host AVP.
>
>  Section 5.5.2 should be updated to be consistent with section 4.6.
>
>


--------------000009070803090601020509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Ulrich,

      

      For the following:

    

    ---

    
We also have proposed wording on the interaction between these report types.  

<Ulrich> can you please remind me what that proposed wording is. My current understanding is that there is no interaction between these two report types</Ulrich>

--- 


    I agree with you that
      there is no interaction between the host reports and
      "realm-routed" reports (or what ever we end up calling them).

      

      Steve

     

    
On 2/21/14 1:07 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Steve,

see inline.
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, February 19, 2014 9:54 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #23: DOIC behavior for realm overload

We've had a lot of discussion of this topic.

I believe that we reached agreement that we currently have two types of reports:

- Host report that applies to requests sent to a destination-host
- Realm report that applies requests routed to a realm that do not have a specified destination-host (realm-routed requests)

<Ulrich> I agree</Ulrich>

We also have proposed wording on the interaction between these report types.  

<Ulrich> can you please remind me what that proposed wording is. My current understanding is that there is no interaction between these two report types</Ulrich>

I propose that the second be renamed to realm-routed reports.

<Ulrich> no strong view, but my preference is in favour of "absent-host reports"</Ulrich>

A separate ticket has been opened on the need for a third report type that would apply to all request routed to a realm, independent of whether a request contains a destination-host AVP.
<Ulrich> I understand that this is #55</Ulrich>

Steve
On 1/21/14 9:24 AM, dime issue tracker wrote:
#23: DOIC behavior for realm overload

 This applies to draft-ietf-dime-ovli-01, which does not show up in the
 Component drop down menu.

 The current assumption in the -01 draft is inconsistent in the definition
 of behavior of behavior by a reacting node when it receives a realm
 overload report.

 Section 4.6 says overload treatment should apply to all request bound for
 the overloaded realm.

 Section 5.5.2 is not clear and there have been interpretations that a
 realm overload report only applies to requests that contain the realm and
 do not contain a destination-host AVP.

 Section 5.5.2 should be updated to be consistent with section 4.6.




    

    

  


--------------000009070803090601020509--


From nobody Mon Feb 24 09:12:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D821A0213 for ; Mon, 24 Feb 2014 09:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWdiYbP6GyS1 for ; Mon, 24 Feb 2014 09:12:07 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id CBF951A01E6 for ; Mon, 24 Feb 2014 09:12:07 -0800 (PST)
Received: from [137.254.4.54] (port=9131 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHz4R-000667-VM; Mon, 24 Feb 2014 09:12:05 -0800
Message-ID: <530B7D62.1080700@usdonovans.com>
Date: Mon, 24 Feb 2014 11:12:02 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ben Campbell 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com>
In-Reply-To: <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com>
Content-Type: multipart/alternative; boundary="------------090702090106060009090605"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x9z73oERE200ctuvxEQcrz-Sylc
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 17:12:09 -0000

This is a multi-part message in MIME format.
--------------090702090106060009090605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ben,

One comment below.

Steve

On 2/20/14 5:16 PM, Ben Campbell wrote:
> On Feb 18, 2014, at 8:54 AM, Steve Donovan  wrote:
>
>> - Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.
> I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.
SRD> The reason for this requirement is to handle the likelihood that
each reporting node of the new realm report type will have independent
sequence numbers.  Thus, as long as all reporting nodes report all
updates to the realm overload status, it should be sufficient for a
reacting node to only listen to one of the reporting nodes when
determining if the OLR is new.
>
>


--------------090702090106060009090605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ben,

      

      One comment below.

      

      Steve

      

    
    
On 2/20/14 5:16 PM, Ben Campbell wrote:

    

    

      
On Feb 18, 2014, at 8:54 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
- Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.


      

      
I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.

    

    SRD> The reason for this requirement is to handle the likelihood
    that each reporting node of the new realm report type will have
    independent sequence numbers.  Thus, as long as all reporting nodes
    report all updates to the realm overload status, it should be
    sufficient for a reacting node to only listen to one of the
    reporting nodes when determining if the OLR is new.

    

      



      

    

    

  


--------------090702090106060009090605--


From nobody Mon Feb 24 09:44:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DFC1A0296 for ; Mon, 24 Feb 2014 09:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8l30kJw-TWZ for ; Mon, 24 Feb 2014 09:44:23 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 801A31A015B for ; Mon, 24 Feb 2014 09:44:23 -0800 (PST)
Received: from [137.254.4.54] (port=16225 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHzZm-0007Pw-0r for dime@ietf.org; Mon, 24 Feb 2014 09:44:22 -0800
Message-ID: <530B84F8.5030006@usdonovans.com>
Date: Mon, 24 Feb 2014 11:44:24 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070803080707000702060209"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gRwY6Da452IsQPFJ6G3ONUGBp3A
Subject: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 17:44:25 -0000

This is a multi-part message in MIME format.
--------------070803080707000702060209
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I propose the following resolution for issue 23:

Proposal -- Change the name of realm report. 


Proposed name - "Realm-Routed-Request" report.


Proposal -- Update all discussion on "Realm-Routed-Request" reports to
indicate that they apply only to requests targeted to a realm when there
is no destination-host AVP in the request.  Specifically, section 4.6
requires updating.

There is also a proposal to add a new report type to handle all
transactions to a realm.  This is addressed by ticket number 55.

Regards,

Steve

--------------070803080707000702060209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    I propose the following
      resolution for issue 23:

    

    
    
Proposal – Change the name of realm report.  

    


      Proposed name - “Realm-Routed-Request” report.

    

      Proposal – Update all discussion on
      “Realm-Routed-Request” reports to indicate that they apply only to
      requests
      targeted to a realm when there is no destination-host AVP in the
      request.  Specifically, section 4.6 requires updating.

      

      There is also a proposal to add a new report type to handle all
      transactions to a realm.  This is addressed by ticket number 55.

      

      Regards,

      

      Steve
    
    
    
    
    
    
    
    
    
    
  


--------------070803080707000702060209--


From nobody Mon Feb 24 09:56:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0105E1A02A6 for ; Mon, 24 Feb 2014 09:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bDzl7sYoznb for ; Mon, 24 Feb 2014 09:56:34 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5012E1A02A4 for ; Mon, 24 Feb 2014 09:56:34 -0800 (PST)
Received: from [137.254.4.54] (port=37782 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHzlV-0002TD-Hp for dime@ietf.org; Mon, 24 Feb 2014 09:56:30 -0800
Message-ID: <530B87D0.1040003@usdonovans.com>
Date: Mon, 24 Feb 2014 11:56:32 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------060702090604030507010209"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/skygxII9_8VpwnhaPPu44rmuxUc
Subject: [Dime] Issue #25 Proposed Resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 17:56:35 -0000

This is a multi-part message in MIME format.
--------------060702090604030507010209
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I propose that we close issue 25 as the resolution of issue 24 addressed
the concerns raised in issue 25.

Note that this requires a new section in the draft to define agent
behavior.  The actual wording of that section will need to be agreed to
before issue 24 can be closed.

Steve

--------------060702090604030507010209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    I propose that we close
      issue 25 as the resolution of issue 24 addressed the concerns raised
      in issue 25.

      

      Note that this requires a new section in the draft to define agent
      behavior.  The actual wording of that section will need to be
      agreed to before issue 24 can be closed.

      

      Steve

    
  


--------------060702090604030507010209--


From nobody Mon Feb 24 10:08:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB781A0175 for ; Mon, 24 Feb 2014 10:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.216
X-Spam-Level: 
X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ6LbgTQJXoC for ; Mon, 24 Feb 2014 10:08:53 -0800 (PST)
Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) by ietfa.amsl.com (Postfix) with ESMTP id E82BD1A00F2 for ; Mon, 24 Feb 2014 10:08:52 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1OI8nqv042855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 12:08:51 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530B7D62.1080700@usdonovans.com>
Date: Mon, 24 Feb 2014 12:08:48 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EE0179F-5A98-4471-9B53-A728C131AACC@nostrum.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum! .com> <530B7D62.1080700@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vpBRKIJzdvgIh2NCiOYYoJBa9gk
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 18:08:54 -0000

On Feb 24, 2014, at 11:12 AM, Steve Donovan  =
wrote:

>> I think this should be restated that realm reports should only be =
_sent_ by reporting nodes that have full knowledge of and authority for =
the realm's overload state. But there's no requirement that there be =
only one, just that if there are more than one they don't contradict =
each other.
> SRD> The reason for this requirement is to handle the likelihood that =
each reporting node of the new realm report type will have independent =
sequence numbers.  Thus, as long as all reporting nodes report all =
updates to the realm overload status, it should be sufficient for a =
reacting node to only listen to one of the reporting nodes when =
determining if the OLR is new.


Okay, does that imply an argument for actual timestamps? :-)=20

Or a way to make sure the timestamp is scoped to the reporting node?  Do =
we need to be unique across just time, or time and space?=


From nobody Mon Feb 24 10:19:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491311A00B1 for ; Mon, 24 Feb 2014 10:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RTrjldfIuQ5 for ; Mon, 24 Feb 2014 10:19:29 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 770001A00AB for ; Mon, 24 Feb 2014 10:19:27 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-1d-530b8d2d6667
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.83.04249.E2D8B035; Mon, 24 Feb 2014 19:19:26 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 19:19:25 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750AAFZYT7AASMSeA=
Date: Mon, 24 Feb 2014 18:19:25 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com>
In-Reply-To: <530B6B9D.6010601@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784B4EESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvja5eL3ewQdcsAYu5vSvYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXnJVaaClX+YKn6t3cPSwDjvAFMXIyeHhICJRMfS32wQtpjE hXvrwWwhgSOMEq8vuHcxcgHZixklzh6cygKSYBOwk7h0+gVQMweHiICyxOlfDiBhYQF1iTvf L7CC2CICGhKNbz6xQ9hlEpNu7AfbxSKgKjFz0RxmEJtXwFfizckVTBDzt7NJTFq2nBEkwSmg JzHrezNYAyPQQd9PrQGzmQXEJW49mQ91tIDEkj3nmSFsUYmXj/+xgtwjIaAosbxfDqI8X2LB 5tesELsEJU7OfMIygVFkFpJJs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZ VzFyFKcWJ+WmGxlsYgTGysEtvy12MF7+a3OIUZqDRUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjHln13l4cmp9XnzK6/ZLo9wFOswls5zlLme/OfWjX5/DZI/p6zuHLSwKg1vE F+5+Pr9MMmqL5Yx1M6+9mjz1ptDGWlMvH5kfsTP/3sm7LdvbZTlRc23bhXcntlp+1b7tfDhc /MAtjTXnSucs9fOoVm27PN3iW1RE0pzVNprHz6zUfH9568UylhIlluKMREMt5qLiRABoYd5M YwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QSYgafgPVOpLmN5ARX84WWcjyNw
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 18:19:37 -0000

--_000_087A34937E64E74E848732CFF8354B9209784B4EESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_087A34937E64E74E848732CFF8354B9209784B4EESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve, all,




I agree with Steve.


 <=
/p>

However, I would like to =
share one concern. We need to avoid that existing (if any) host OLR (“=
;all-client”) in the reacting node is replaced by new host OLR
 (per client).


Host OLR (per client) wit=
h the new AVP requires that the server uses a new sequence number, but exis=
ting host OLR (all) shall not be replaced, on the contrary
 both Host OLR (all) and new Host OLR (per client) should remain.


In order to achieve this,=
 it could be more convenient to use a dedicated OLR type (host per client),=
 instead of a new AVP.


 <=
/p>

Let me know your opinions=
.


Best regards


/MCruz


 <=
/p>

 <=
/p>





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

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Adding an AVP to indi=
cate that a report applies just to the Origin-Host in the request is not ju=
st an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






Is it implicit? 


 


If the agent detects that a client is not supporting DOIC, this agent =
will have to store the corresponding overload control state on behalf of th=
is client and only this client (saying that other clients may support DOIC)=
. I'm assuming then that any agent will have to store somewhere the origin-=
host of this client. And therefore, I don't see what would be the added-val=
ue of this AVP saying that this OLR is only for this client.

 


Even if this AVP is present, it would not preclude a reporting node to=
 always put this AVP in every answer, even if the OLR is the same for all t=
he clients.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27


=C0 : dime@ietf.org


Objet : Re: [Dime] Issue#35 conclusion


 


Hello Ulrich,


 


I haven't proposed to limit this to host type OLR, I just wanted to cl=
arify if this is what JJ got in mind.


 


I agree it could be done as you explained in the example below, but th=
e open question is whether it is better to add an AVP when OLR is just mean=
t for one single client, or on the contrary the agent _always_ need to bind=
 OLR to one specific client, even if the server simply requires same OLR fo=
r any client. 


 


I think having a new AVP simplifies agent behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: lunes, 24 de febrero de 2014 14:19


To: Maria Cruz Bartolome; dime@ietf.o=
rg


Subject: RE: [Dime] Issue#35 conclusion


 


Hi MCruz,


there is no reason to limit this to host type OLRs.


 


If we have an agent A that is configured to take the role of the repor=
ting node for realm-type reports for realm R, A could receive host type OLR=
s from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% =
reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin fro=
m C2); A then would aggregate these info and return realm type OLRs to C1 r=
equesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% r=
eduction of traffic from C2 to R.


 


Best regards


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Monday, February 24, 2014 2:02 PM


To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


Hello JJ and all,


 


As per email thread, the latest proposal is:


"When an agent takes the role of a reacting node, the agent needs=
 to bind a received OLR to the origin host of the client that initiated the=
 request which corresponds to the answer containing the OLR." 


 


An Ulrich comments on this:


"This would cover not only the case where an agent takes the role=
 of the reacting node on behalf of a (or several) non supporting client, bu=
t also the case where an agent is configured to take the role of a reportin=
g node (for realm-type reports) towards the client and at the same time the=
 role of a reacting node towards the server."


 


Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)


Sent: lunes, 24 de febrero de 2014 13:43


To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


Hi Mcruz and all


 


I think that you are  mixing the case of the DA that is the "=
;reporting" node which wants to indicate a realm OLR to clients, and f=
or which will use various (non standardized ) ways to determine among which=
 it can reuse the Host-OLR AVPs received from various servers. But in this =
case, clients receiving realm OLRs are supporting DOIC. 


Here I understand the on going  discussion is about the DA behavi=
or when  clients is not supporting DOIC and to reuse the Host-OLR rece=
ived for one client for other clients  .


 


For me I remain on  my previous mail, with a baseline solution. W=
e may always study new extensions, optimizations, but priority should be on=
 the baseline.


 


Best regards


 


Jacques 


 


   


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lun=
di 24 f=E9vrier 2014 13:21 =C0 : dime=
@ietf.org Objet : Re: [Dime] Issue#35 conclusion


 


Hello all,


 


Not sure we all have the same understanding here.


Let me try to explain my concerns.


 


The original 3GPP requirement we want to cover is the need for a serve=
r to reduce traffic for one specific client, i.e. traffic identified by &qu=
ot;Origin-Host" in the request.


Then, two options are under analysis about whether or not the OLR in t=
he server answer shall be marked:


 


a) OLR does not need to include anything else Receiver of the answer (=
and OLR) is the client that sends the request, identified by "Origin-H=
ost" in the request.


Then, as long as the reacting node=3D=3D"Origin-Host", the e=
xpected reduction is performed and requirement fulfilled.


But, when an agent is acting on behalf of a client as the reacting nod=
e, then the "Origin-Host" identifies final client, but not the re=
acting node.


Then, this is why the proposal is to add following clarification about=
 agent behavior (possible clause 5.5):


"When an agent takes the role of a reacting node, the agent needs=
 to bind a received OLR to the origin host of the client that initiated the=
 request which corresponds to the answer containing the OLR."


But this will imply that _always_ the reacting node applies this OLR t=
o one specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a=
 Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's cons=
ider following example:


- C1 sends a Realm request via Agent, that finally reaches S1


- S1 answers with OLR (Host:50%).


- Agent is acting as reacting node on behalf of C1, if it considers th=
is OLR only bind to C1... then... should it consider S1-OLR only as relevan=
t for requests coming from C1? Should agent do not use this S1-OLR to calcu=
late aggregated Realm overload?


In my opinion, in this case it does not make sense to consider OLR was=
 only meant to C1. And this problem could be solved adding explicit informa=
tion, as in b) below.


 


b) OLR needs to be extended (new AVP) that identifies the client (&quo=
t;Origin-Host" in the request) from which traffic reduction shall appl=
y.


With this new AVP, reacting node will easy be able to identify when OL=
R shall be applied to any client or just to the Origin-Host identified by n=
ew AVP.


 


Let me know your opinions please


Best regards


/MCruz


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28


To: ext Steve Donovan; dime@ietf.org<=
/a>


Subject: Re: [Dime] Issue#35 conclusion


 


Steve,


 


please see inline.


 


Ulrich


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Friday, February 21, 2014 4:53 PM


To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


Ulrich,


 


I have a couple of concerns with this approach, as currently outlined.=
  


 


First, how do we handle the case where there are multiple DOIC support=
ing agents between the non supporting client and the reporting node.  =
This, I guess, is a general question, not just applying to this proposal.&n=
bsp; I suggest we capture in the agent behavior section that is currently m=
issing wording indicating that the first supporting agent that receives the=
 request must be the reacting node for that non-supporting client.  Su=
bsequent DOIC supporting agents must not be the reacting node for the non-s=
upporting client.


<Ulrich>I fully agree</Ulrich>


 


 


We need to think through the ramifications of having multiple agents b=
eing the reacting node for the same non supporting clients, as this could e=
asily happen in networks where multiple agents are involved in a single tra=
nsaction.  On the surface it doesn't seem to be an issue for the loss =
algorithm, but this might not be the case with other algorithms.=



<Ulrich>I agree that this is not an issue for loss; it is an iss=
ue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich&=
gt;


 


My other concern is that this puts a lot of extra onus on the agent ev=
en for the case where the reporting node does not want to differentiate ove=
rload reports.


<Ulrich> I agree </Ulrich>


To this end I suggest we add an indication in the OLR marking the repo=
rts that are specific to just the Origin-Host in the request.  Absence=
 of the "single-client-only" AVP would mean that the report appli=
es to all clients.  Presence of the AVP would indicate that the OLR ap=
plies to the Origin-Host.


<Ulrich>I understand that the proposal is an optimization for ag=
ents. Therefore the semantics of the marking should be reverse: unmarked OL=
Rs are client specific, marked OLRs indicate that the reporting node does n=
ot want to differentiate, and therefore allow agents not to do the binding =
to the client.</Ulrich>     


 


Steve


On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:<=
/pre>

Ben,


 


the proposed conclusion was based on comments received so far (from Li=
onel, Nirav, Steve, MCruz, JJ). 


Now you seem to address two points:


a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying te=
xt for 5.5. as follows:


 


When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR. 


 


This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server.


 


b) There is no binding of the OLR to the orig-host of the client Here =
I disagree. We have the 3GPP requirement to allow requesting different amou=
nt of reduction from different clients, and I think we have 3 options:=



1. ignore the 3GPP requirement


2. introduce new report types as originally proposed in #35 3. introdu=
ce the binding between OLR and orig-host of the client.


 


So far I understood that people favoured option 3.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [mailto:ben@=
nostrum.com]


Sent: Thursday, February 20, 2014 11:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


 


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:


 


#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional report types. However=
, we agreed to add clarifying text to clause 5.5 as follows:

 


When an agent received an OLR in response to a request initiated by a =
client not supporting DOIC, this agent needs to bind the received OLR to th=
e origin-host of the client.


 


I do not agree.


 


You proposal implies that the server's OLR only applies to that client=
.


<Ulrich>exactly, that was the intention</Ulrich>  If =
there's an intervening DOIC agent, then the agent, not the client, is the r=
eacting node from the server's perspective.


<Ulrich> the server's perspective is agnostic. The server does n=
ot know whether it's the client or an agent on the path that takes the role=
 of the reacting node</Ulrich>  But, short of adding an origin-h=
ost type, nothing binds the OLR to a particular client, regardless of DOIC =
support at the clients.


<Ulrich> the binding is always there, regardless of DOIC support=
 at the client</Ulrich>


 


 Whether or not the client also supports DOIC doesn't change that. For=
 DOIC-supporting clients, the agent has the additional option of reducing t=
raffic by asking the clients to reduce traffic (making them reacting nodes =
from the perspective of the _agent_, but not the server.)  It doesn't =
have that option for non-DOIC clients.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_087A34937E64E74E848732CFF8354B9209784B4EESESSMB101erics_--


From nobody Mon Feb 24 10:40:05 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBF71A01EE for ; Mon, 24 Feb 2014 10:40:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMaxv-9R1Lze for ; Mon, 24 Feb 2014 10:40:03 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB001A01CA for ; Mon, 24 Feb 2014 10:40:03 -0800 (PST)
Received: from [137.254.4.54] (port=48702 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI0Rb-0007JV-Cn for dime@ietf.org; Mon, 24 Feb 2014 10:39:59 -0800
Message-ID: <530B9202.8040100@usdonovans.com>
Date: Mon, 24 Feb 2014 12:40:02 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------020201040802090300040609"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_gOIz5XgHQfJJJK2K_jorA1cCS0
Subject: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 18:40:04 -0000

This is a multi-part message in MIME format.
--------------020201040802090300040609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

There has been no discussion of ticket #27.  I can't even find it on the
DIME list, so I'm copying it here to initiate discussion.

The proposal is for an agent to send a TOO-BUSY response when it
throttles a request from a non supporting client.  The behavior of the
agent in this case would be in the new section to be added to capture
agent behavior as proposed in issue #24 (and various other places).

Steve

-----


The specification is currently missing a definition of the behavior of
agents that are the reacting node for overload reports in the case that
the client does not support the DOIC extension.

We need to add wording that the agent will throttle messages from the
client by the percentage indicated by the reporting node. We need to
determine the error response that will be sent by the agent. Given that
the client does not support the extension, the error will need to be an
existing error -- most likely TOO-BUSY.


--------------020201040802090300040609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    There has been no
      discussion of ticket #27.  I can't even find it on the DIME list,
      so I'm copying it here to initiate discussion.

      

      The proposal is for an agent to send a TOO-BUSY response when it
      throttles a request from a non supporting client.  The behavior of
      the agent in this case would be in the new section to be added to
      capture agent behavior as proposed in issue #24 (and various other
      places).

      

      Steve

      

      -----

      

    

    
    

      The specification is currently missing a definition of the
      behavior of agents that are the reacting node for overload reports
      in the case that the client does not support the DOIC extension.
    

    

      We need to add wording that the agent will throttle messages from
      the client by the percentage indicated by the reporting node. We
      need to determine the error response that will be sent by the
      agent. Given that the client does not support the extension, the
      error will need to be an existing error -- most likely TOO-BUSY.
    

  


--------------020201040802090300040609--


From nobody Mon Feb 24 10:40:19 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B801A019C for ; Mon, 24 Feb 2014 10:40:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOFlowYdUfp5 for ; Mon, 24 Feb 2014 10:40:07 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9048C1A022E for ; Mon, 24 Feb 2014 10:40:06 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-c9-530b920562f3
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 79.B4.04249.5029B035; Mon, 24 Feb 2014 19:40:05 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 19:40:04 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750AAFZYT7AASMSeAAAPq9AA==
Date: Mon, 24 Feb 2014 18:40:04 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784B72ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvjS7rJO5gg9tXpS3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoumd4wF/2cwV/Q8bWZsYNxxk6mLkZNDQsBEYu6LHjYIW0zi wr31YLaQwBFGieWNOl2MXED2YkaJSWcb2EESbAJ2EpdOvwBq5uAQEVCWOP3LASQsLKAucef7 BVYQW0RAQ6LxzSd2iJI6iWPnzEDCLAKqEsc/vwZbyyvgK7Hw60xmiPG/2SRWnusAG88p4Cfx 9+g2MJsR6J7vp9aANTALiEvcejIf6mYBiSV7zjND2KISLx//YwXZJSGgKLG8Xw6iPF/i75EP rBC7BCVOznzCMoFRZBaSSbOQlM1CUgYR15O4MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2Vcx chSnFiflphsZbGIERsrBLb8tdjBe/mtziFGag0VJnPfjW+cgIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYxT2Vf69i64rzZv/XOnpckq5m9L3hvGJN8vsG1/OOWMRUcS64PkqQ/5PV8ed+N4 ND35sNKrlVsn/Mx7s1KB48ykt+UKQQe09kYG112udRc+ZCF7vcxMt0v6bZDMKzb/RXv5U+eI VbCsvtJ0gP/jeuY7l1ljJYOVLrLdvpqhXvq3oGV5cPnfvmAlluKMREMt5qLiRAASWGi5YgIA AA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QsZVT3Ahb9p8h1Pn_-e18ZBDDHM
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 18:40:17 -0000

--_000_087A34937E64E74E848732CFF8354B9209784B72ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello again,

I forgot to mention something else in this thread, that I already mentioned=
 in related thread #56.

This is all in order to take into account 3GPP requirement on overload miti=
gation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".



Therefore, we can even consider this new OLR out of the base draft, and be =
considered by 3GPP applications when required.



Best regards

/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_087A34937E64E74E848732CFF8354B9209784B72ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello=
 again,


=
 


I for=
got to mention something else in this thread, that I already mentioned in r=
elated thread #56.


=
 


This =
is all in order to take into account 3GPP requirement on overload mitigatio=
n differentiation per client. But this is a server option:


TR 29809 ch. 6.4.7.1 states "It=
 may be up to the server/agent implementations to decide when and whether o=
verload mitigation differentiation per client is used".


 


Therefore, we can even consider this=
 new OLR out of the base draft, and be considered by 3GPP applications when=
 required.


 


Best regards


/MCruz


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: lunes, 24 de febrero de 2014 19:19

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Steve, all,




I agree with Steve.


 <=
/p>

However, I would like to =
share one concern. We need to avoid that existing (if any) host OLR (“=
;all-client”) in the reacting node is replaced by new host OLR
 (per client).


Host OLR (per client) wit=
h the new AVP requires that the server uses a new sequence number, but exis=
ting host OLR (all) shall not be replaced, on the contrary
 both Host OLR (all) and new Host OLR (per client) should remain.


In order to achieve this,=
 it could be more convenient to use a dedicated OLR type (host per client),=
 instead of a new AVP.


 <=
/p>

Let me know your opinions=
.


Best regards


/MCruz<=
/p>

 <=
/p>

 <=
/p>





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

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Adding an AVP to indi=
cate that a report applies just to the Origin-Host in the request is not ju=
st an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






Is it implicit? 


 


If the agent detects that a client is not supporting DOIC, this agent =
will have to store the corresponding overload control state on behalf of th=
is client and only this client (saying that other clients may support DOIC)=
. I'm assuming then that any agent will have to store somewhere the origin-=
host of this client. And therefore, I don't see what would be the added-val=
ue of this AVP saying that this OLR is only for this client.

 


Even if this AVP is present, it would not preclude a reporting node to=
 always put this AVP in every answer, even if the OLR is the same for all t=
he clients.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27


=C0 : dime@ietf.org


Objet : Re: [Dime] Issue#35 conclusion


 


Hello Ulrich,


 


I haven't proposed to limit this to host type OLR, I just wanted to cl=
arify if this is what JJ got in mind.


 


I agree it could be done as you explained in the example below, but th=
e open question is whether it is better to add an AVP when OLR is just mean=
t for one single client, or on the contrary the agent _always_ need to bind=
 OLR to one specific client, even if the server simply requires same OLR fo=
r any client. 


 


I think having a new AVP simplifies agent behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: lunes, 24 de febrero de 2014 14:19


To: Maria Cruz Bartolome; dime@ietf.o=
rg


Subject: RE: [Dime] Issue#35 conclusion


 


Hi MCruz,


there is no reason to limit this to host type OLRs.


 


If we have an agent A that is configured to take the role of the repor=
ting node for realm-type reports for realm R, A could receive host type OLR=
s from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% =
reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin fro=
m C2); A then would aggregate these info and return realm type OLRs to C1 r=
equesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% r=
eduction of traffic from C2 to R.


 


Best regards


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Monday, February 24, 2014 2:02 PM


To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


Hello JJ and all,


 


As per email thread, the latest proposal is:


"When an agent takes the role of a reacting node, the agent needs=
 to bind a received OLR to the origin host of the client that initiated the=
 request which corresponds to the answer containing the OLR." 


 


An Ulrich comments on this:


"This would cover not only the case where an agent takes the role=
 of the reacting node on behalf of a (or several) non supporting client, bu=
t also the case where an agent is configured to take the role of a reportin=
g node (for realm-type reports) towards the client and at the same time the=
 role of a reacting node towards the server."


 


Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)


Sent: lunes, 24 de febrero de 2014 13:43


To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


Hi Mcruz and all


 


I think that you are  mixing the case of the DA that is the "=
;reporting" node which wants to indicate a realm OLR to clients, and f=
or which will use various (non standardized ) ways to determine among which=
 it can reuse the Host-OLR AVPs received from various servers. But in this =
case, clients receiving realm OLRs are supporting DOIC. 


Here I understand the on going  discussion is about the DA behavi=
or when  clients is not supporting DOIC and to reuse the Host-OLR rece=
ived for one client for other clients  .


 


For me I remain on  my previous mail, with a baseline solution. W=
e may always study new extensions, optimizations, but priority should be on=
 the baseline.


 


Best regards


 


Jacques 


 


   


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lun=
di 24 f=E9vrier 2014 13:21 =C0 : dime=
@ietf.org Objet : Re: [Dime] Issue#35 conclusion


 


Hello all,


 


Not sure we all have the same understanding here.


Let me try to explain my concerns.


 


The original 3GPP requirement we want to cover is the need for a serve=
r to reduce traffic for one specific client, i.e. traffic identified by &qu=
ot;Origin-Host" in the request.


Then, two options are under analysis about whether or not the OLR in t=
he server answer shall be marked:


 


a) OLR does not need to include anything else Receiver of the answer (=
and OLR) is the client that sends the request, identified by "Origin-H=
ost" in the request.


Then, as long as the reacting node=3D=3D"Origin-Host", the e=
xpected reduction is performed and requirement fulfilled.


But, when an agent is acting on behalf of a client as the reacting nod=
e, then the "Origin-Host" identifies final client, but not the re=
acting node.


Then, this is why the proposal is to add following clarification about=
 agent behavior (possible clause 5.5):


"When an agent takes the role of a reacting node, the agent needs=
 to bind a received OLR to the origin host of the client that initiated the=
 request which corresponds to the answer containing the OLR."


But this will imply that _always_ the reacting node applies this OLR t=
o one specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a=
 Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's cons=
ider following example:


- C1 sends a Realm request via Agent, that finally reaches S1


- S1 answers with OLR (Host:50%).


- Agent is acting as reacting node on behalf of C1, if it considers th=
is OLR only bind to C1... then... should it consider S1-OLR only as relevan=
t for requests coming from C1? Should agent do not use this S1-OLR to calcu=
late aggregated Realm overload?


In my opinion, in this case it does not make sense to consider OLR was=
 only meant to C1. And this problem could be solved adding explicit informa=
tion, as in b) below.


 


b) OLR needs to be extended (new AVP) that identifies the client (&quo=
t;Origin-Host" in the request) from which traffic reduction shall appl=
y.


With this new AVP, reacting node will easy be able to identify when OL=
R shall be applied to any client or just to the Origin-Host identified by n=
ew AVP.


 


Let me know your opinions please


Best regards


/MCruz


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28


To: ext Steve Donovan; dime@ietf.org<=
/a>


Subject: Re: [Dime] Issue#35 conclusion


 


Steve,


 


please see inline.


 


Ulrich


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Friday, February 21, 2014 4:53 PM


To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


Ulrich,


 


I have a couple of concerns with this approach, as currently outlined.=
  


 


First, how do we handle the case where there are multiple DOIC support=
ing agents between the non supporting client and the reporting node.  =
This, I guess, is a general question, not just applying to this proposal.&n=
bsp; I suggest we capture in the agent behavior section that is currently m=
issing wording indicating that the first supporting agent that receives the=
 request must be the reacting node for that non-supporting client.  Su=
bsequent DOIC supporting agents must not be the reacting node for the non-s=
upporting client.


<Ulrich>I fully agree</Ulrich>


 


 


We need to think through the ramifications of having multiple agents b=
eing the reacting node for the same non supporting clients, as this could e=
asily happen in networks where multiple agents are involved in a single tra=
nsaction.  On the surface it doesn't seem to be an issue for the loss =
algorithm, but this might not be the case with other algorithms.=



<Ulrich>I agree that this is not an issue for loss; it is an iss=
ue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich&=
gt;


 


My other concern is that this puts a lot of extra onus on the agent ev=
en for the case where the reporting node does not want to differentiate ove=
rload reports.


<Ulrich> I agree </Ulrich>


To this end I suggest we add an indication in the OLR marking the repo=
rts that are specific to just the Origin-Host in the request.  Absence=
 of the "single-client-only" AVP would mean that the report appli=
es to all clients.  Presence of the AVP would indicate that the OLR ap=
plies to the Origin-Host.


<Ulrich>I understand that the proposal is an optimization for ag=
ents. Therefore the semantics of the marking should be reverse: unmarked OL=
Rs are client specific, marked OLRs indicate that the reporting node does n=
ot want to differentiate, and therefore allow agents not to do the binding =
to the client.</Ulrich>     


 


Steve


On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:<=
/pre>

Ben,


 


the proposed conclusion was based on comments received so far (from Li=
onel, Nirav, Steve, MCruz, JJ). 


Now you seem to address two points:


a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying te=
xt for 5.5. as follows:


 


When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR. 


 


This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server.


 


b) There is no binding of the OLR to the orig-host of the client Here =
I disagree. We have the 3GPP requirement to allow requesting different amou=
nt of reduction from different clients, and I think we have 3 options:=



1. ignore the 3GPP requirement


2. introduce new report types as originally proposed in #35 3. introdu=
ce the binding between OLR and orig-host of the client.


 


So far I understood that people favoured option 3.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [mailto:ben@=
nostrum.com]


Sent: Thursday, February 20, 2014 11:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion


 


 


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:


 


#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional report types. However=
, we agreed to add clarifying text to clause 5.5 as follows:

 


When an agent received an OLR in response to a request initiated by a =
client not supporting DOIC, this agent needs to bind the received OLR to th=
e origin-host of the client.


 


I do not agree.


 


You proposal implies that the server's OLR only applies to that client=
.


<Ulrich>exactly, that was the intention</Ulrich>  If =
there's an intervening DOIC agent, then the agent, not the client, is the r=
eacting node from the server's perspective.


<Ulrich> the server's perspective is agnostic. The server does n=
ot know whether it's the client or an agent on the path that takes the role=
 of the reacting node</Ulrich>  But, short of adding an origin-h=
ost type, nothing binds the OLR to a particular client, regardless of DOIC =
support at the clients.


<Ulrich> the binding is always there, regardless of DOIC support=
 at the client</Ulrich>


 


 Whether or not the client also supports DOIC doesn't change that. For=
 DOIC-supporting clients, the agent has the additional option of reducing t=
raffic by asking the clients to reduce traffic (making them reacting nodes =
from the perspective of the _agent_, but not the server.)  It doesn't =
have that option for non-DOIC clients.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_087A34937E64E74E848732CFF8354B9209784B72ESESSMB101erics_--


From nobody Mon Feb 24 10:50:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A063A1A02BF for ; Mon, 24 Feb 2014 10:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.35
X-Spam-Level: 
X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnOZKJTUhs12 for ; Mon, 24 Feb 2014 10:50:32 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id DE5851A02C2 for ; Mon, 24 Feb 2014 10:50:21 -0800 (PST)
Received: from [137.254.4.54] (port=1272 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI0bW-0007T9-97 for dime@ietf.org; Mon, 24 Feb 2014 10:50:20 -0800
Message-ID: <530B9469.4070403@usdonovans.com>
Date: Mon, 24 Feb 2014 12:50:17 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------000305020504060007060904"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YDm4QnbUnQiQE7pU7L9eaJ6NtRw
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 18:50:39 -0000

This is a multi-part message in MIME format.
--------------000305020504060007060904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Maria Cruz,

To the degree possible we should minimize the per application overload
logic required.  To this end, it would be better to have this as part of
the base specification, as it is likely that most/all applications will
want the same behavior.

Whether a reporting node uses per Origin-Host reports is an
implementation detail of the reporting node.  How reacting nodes respond
to per Origin-Host reports should be specified in a common way.

Steve

On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
>
> Hello again,
>
>  
>
> I forgot to mention something else in this thread, that I already
> mentioned in related thread #56.
>
>  
>
> This is all in order to take into account 3GPP requirement on overload
> mitigation differentiation per client. But this is a server option:
>
> TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent
> implementations to decide when and whether overload mitigation
> differentiation per client is used".
>
>  
>
> Therefore, we can even consider this new OLR out of the base draft,
> and be considered by 3GPP applications when required.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* lunes, 24 de febrero de 2014 19:19
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Steve, all,
>
>
> I agree with Steve.
>
>  
>
> However, I would like to share one concern. We need to avoid that
> existing (if any) host OLR ("all-client") in the reacting node is
> replaced by new host OLR (per client).
>
> Host OLR (per client) with the new AVP requires that the server uses a
> new sequence number, but existing host OLR (all) shall not be
> replaced, on the contrary both Host OLR (all) and new Host OLR (per
> client) should remain.
>
> In order to achieve this, it could be more convenient to use a
> dedicated OLR type (host per client), instead of a new AVP.
>
>  
>
> Let me know your opinions.
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 16:56
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Adding an AVP to indicate that a report applies just to the
> Origin-Host in the request is not just an optimization for agents.
>
> It had been my assumption all along that the default behavior of a
> reporting node (server) would be to report a single overload value to
> all reacting nodes, be they clients or agents.  If this is the default
> behavior then it would be best to have the default, implicit, meaning
> of an overload report to be "applies to all reacting nodes".  The real
> value of this new feature is to allow a server to further throttle a
> specific, overly active, reacting node when then global reduction
> percentage doesn't do the job.
>
> In addition, if the normal case is that reporting nodes have a single
> global reduction percentage then requiring agents to bind an overload
> report to each non supporting clients pushes a lot of extra work on
> agents when it adds no value.
>
> My proposal is the following:
>
> - Add an optional AVP (call it something like Single-Node???) to
> overload reports that indicate when an overload report applies to a
> specific reacting node.
>
> - Absence of the AVP indicates that the report applies to all reacting
> nodes (clients and agents acting on behalf of non-DOIC clients).
>
> - Reporting nodes should only include the Single-Node AVP if the
> overload report contents are different from the global overload report.
>
> - DOIC-supporting agents receiving an OLR without the Single-Node AVP
> must do the following:
>   - For transactions from DOIC-supporting clients the agent must not
> act on the OLR.
>   - For transactions from non-DOIC-supporting clients the agent must
> apply the OLR to traffic from the set of non supporting clients.  
> This implies that when making throttling decisions, the agent does not
> differentiate which non supporting client originated the request.
>
> - DOIC-supporting agents receiving an OLR with the Single-Node AVP for
> a transaction originated by a non supporting client must bind that OLR
> to that single client.
>
> Note that the agent behavior is currently something that is missing
> from the -01 version of the draft.  We will need something like this
> wording independent of the resolution of this issue.
>
> Steve
>
> On 2/24/14 8:06 AM, lionel.morand@orange.com
>  wrote:
>
>     Is it implicit? 
>
>      
>
>     If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.
>
>      
>
>     Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.
>
>      
>
>     Regards,
>
>      
>
>     Lionel
>
>      
>
>     -----Message d'origine-----
>
>     De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
>
>     Envoyé : lundi 24 février 2014 14:27
>
>     À : dime@ietf.org 
>
>     Objet : Re: [Dime] Issue#35 conclusion
>
>      
>
>     Hello Ulrich,
>
>      
>
>     I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.
>
>      
>
>     I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 
>
>      
>
>     I think having a new AVP simplifies agent behavior.
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>
>     Sent: lunes, 24 de febrero de 2014 14:19
>
>     To: Maria Cruz Bartolome; dime@ietf.org 
>
>     Subject: RE: [Dime] Issue#35 conclusion
>
>      
>
>     Hi MCruz,
>
>     there is no reason to limit this to host type OLRs.
>
>      
>
>     If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
>
>     Sent: Monday, February 24, 2014 2:02 PM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>     Hello JJ and all,
>
>      
>
>     As per email thread, the latest proposal is:
>
>     "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 
>
>      
>
>     An Ulrich comments on this:
>
>     "This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."
>
>      
>
>     Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
>
>     Best regards
>
>     /MCruz
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>     Sent: lunes, 24 de febrero de 2014 13:43
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>     Hi Mcruz and all
>
>      
>
>     I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
>
>     Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .
>
>      
>
>     For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.
>
>      
>
>     Best regards
>
>      
>
>     Jacques 
>
>      
>
>        
>
>      
>
>     -----Message d'origine-----
>
>     De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org  Objet : Re: [Dime] Issue#35 conclusion
>
>      
>
>     Hello all,
>
>      
>
>     Not sure we all have the same understanding here.
>
>     Let me try to explain my concerns.
>
>      
>
>     The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.
>
>     Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:
>
>      
>
>     a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
>
>     Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
>
>     But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
>
>     Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):
>
>     "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."
>
>     But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.
>
>     How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:
>
>     - C1 sends a Realm request via Agent, that finally reaches S1
>
>     - S1 answers with OLR (Host:50%).
>
>     - Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?
>
>     In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.
>
>      
>
>     b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.
>
>     With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.
>
>      
>
>     Let me know your opinions please
>
>     Best regards
>
>     /MCruz
>
>      
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
>
>     Sent: lunes, 24 de febrero de 2014 12:28
>
>     To: ext Steve Donovan; dime@ietf.org 
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>     Steve,
>
>      
>
>     please see inline.
>
>      
>
>     Ulrich
>
>      
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>
>     Sent: Friday, February 21, 2014 4:53 PM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>     Ulrich,
>
>      
>
>     I have a couple of concerns with this approach, as currently outlined.  
>
>      
>
>     First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.
>
>     I fully agree
>
>      
>
>      
>
>     We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.
>
>     I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)
>
>      
>
>     My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.
>
>      I agree 
>
>     To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.
>
>     I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.     
>
>      
>
>     Steve
>
>     On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Ben,
>
>      
>
>     the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
>
>     Now you seem to address two points:
>
>     a) There is no dependency to DOIC support of the client.
>
>     To address this I would like to propose rewording of the clarifying text for 5.5. as follows:
>
>      
>
>     When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 
>
>      
>
>     This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.
>
>      
>
>     b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
>
>     1. ignore the 3GPP requirement
>
>     2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.
>
>      
>
>     So far I understood that people favoured option 3.
>
>      
>
>     See also inline.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: ext Ben Campbell [mailto:ben@nostrum.com]
>
>     Sent: Thursday, February 20, 2014 11:55 PM
>
>     To: Wiehe, Ulrich (NSN - DE/Munich)
>
>     Cc: dime@ietf.org 
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>      
>
>     On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)   wrote:
>
>      
>
>     #35: additional report types are proposed
>
>      
>
>     Dear all,
>
>      
>
>     I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>
>      
>
>     When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.
>
>      
>
>     I do not agree.
>
>      
>
>     You proposal implies that the server's OLR only applies to that client.
>
>     exactly, that was the intention  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
>
>      the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>
>      the binding is always there, regardless of DOIC support at the client
>
>      
>
>      Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.
>
>      
>
>     _______________________________________________
>
>     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
>
>      
>
>     _______________________________________________
>
>     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
>
>      
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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.
>
>      
>
>     _______________________________________________
>
>     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


--------------000305020504060007060904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      To the degree possible we should minimize the per application
      overload logic required.  To this end, it would be better to have
      this as part of the base specification, as it is likely that
      most/all applications will want the same behavior.

      

      Whether a reporting node uses per Origin-Host reports is an
      implementation detail of the reporting node.  How reacting nodes
      respond to per Origin-Host reports should be specified in a common
      way.

      

      Steve

      

    
    
On 2/24/14 12:40 PM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello again,

        
 

        
I forgot to mention
            something else in this thread, that I already mentioned in
            related thread #56.

        
 

        
This is all in order
            to take into account 3GPP requirement on overload mitigation
            differentiation per client. But this is a server option:

        
TR 29809 ch.
            6.4.7.1 states "It may be up to the server/agent
            implementations to decide when and whether overload
            mitigation differentiation per client is used".

        
 

        
Therefore, we
            can even consider this new OLR out of the base draft, and be
            considered by 3GPP applications when required.

        
 

        
Best regards

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Maria Cruz Bartolome

                Sent: lunes, 24 de febrero de 2014 19:19

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Steve,
            all,

        


            I agree with Steve.

        
 

        
However,
            I would like to share one concern. We need to avoid that
            existing (if any) host OLR (“all-client”) in the reacting
            node is replaced by new host OLR (per client).

        
Host
            OLR (per client) with the new AVP requires that the server
            uses a new sequence number, but existing host OLR (all)
            shall not be replaced, on the contrary both Host OLR (all)
            and new Host OLR (per client) should remain.

        
In
            order to achieve this, it could be more convenient to use a
            dedicated OLR type (host per client), instead of a new AVP.

        
 

        
Let
            me know your opinions.

        
Best
            regards

        
/MCruz

        
 

        
 

        

          

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

                Sent: lunes, 24 de febrero de 2014 16:56

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Adding an AVP
          to indicate that a report applies just to the Origin-Host in
          the request is not just an optimization for agents.

          

          It had been my assumption all along that the default behavior
          of a reporting node (server) would be to report a single
          overload value to all reacting nodes, be they clients or
          agents.  If this is the default behavior then it would be best
          to have the default, implicit, meaning of an overload report
          to be "applies to all reacting nodes".  The real value of this
          new feature is to allow a server to further throttle a
          specific, overly active, reacting node when then global
          reduction percentage doesn't do the job.

          

          In addition, if the normal case is that reporting nodes have a
          single global reduction percentage then requiring agents to
          bind an overload report to each non supporting clients pushes
          a lot of extra work on agents when it adds no value.

          

          My proposal is the following:

          

          - Add an optional AVP (call it something like Single-Node???)
          to overload reports that indicate when an overload report
          applies to a specific reacting node.

          

          - Absence of the AVP indicates that the report applies to all
          reacting nodes (clients and agents acting on behalf of
          non-DOIC clients).

          

          - Reporting nodes should only include the Single-Node AVP if
          the overload report contents are different from the global
          overload report.

          

          - DOIC-supporting agents receiving an OLR without the
          Single-Node AVP must do the following:

            - For transactions from DOIC-supporting clients the agent
          must not act on the OLR.

            - For transactions from non-DOIC-supporting clients the
          agent must apply the OLR to traffic from the set of non
          supporting clients.   This implies that when making throttling
          decisions, the agent does not differentiate which non
          supporting client originated the request.

          

          - DOIC-supporting agents receiving an OLR with the Single-Node
          AVP for a transaction originated by a non supporting client
          must bind that OLR to that single client.

          

          Note that the agent behavior is currently something that is
          missing from the -01 version of the draft.  We will need
          something like this wording independent of the resolution of
          this issue.

          

          Steve

        

          
On 2/24/14 8:06 AM, 
              lionel.morand@orange.com wrote:

        

        

          
Is it implicit? 

          
 

          
If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.

          
 

          
Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.

          
 

          
Regards,

          
 

          
Lionel

          
 

          
-----Message d'origine-----

          
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

          
Envoyé : lundi 24 février 2014 14:27

          
À : dime@ietf.org

          
Objet : Re: [Dime] Issue#35 conclusion

          
 

          
Hello Ulrich,

          
 

          
I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.

          
 

          
I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 

          
 

          
I think having a new AVP simplifies agent behavior.

          
 

          
Best regards

          
/MCruz

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

          
Sent: lunes, 24 de febrero de 2014 14:19

          
To: Maria Cruz Bartolome; dime@ietf.org

          
Subject: RE: [Dime] Issue#35 conclusion

          
 

          
Hi MCruz,

          
there is no reason to limit this to host type OLRs.

          
 

          
If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

          
 

          
Best regards

          
Ulrich

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome

          
Sent: Monday, February 24, 2014 2:02 PM

          
To: dime@ietf.org

          
Subject: Re: [Dime] Issue#35 conclusion

          
 

          
Hello JJ and all,

          
 

          
As per email thread, the latest proposal is:

          
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 

          
 

          
An Ulrich comments on this:

          
"This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."

          
 

          
Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 

          
Best regards

          
/MCruz

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

          
Sent: lunes, 24 de febrero de 2014 13:43

          
To: dime@ietf.org

          
Subject: Re: [Dime] Issue#35 conclusion

          
 

          
Hi Mcruz and all

          
 

          
I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 

          
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

          
 

          
For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

          
 

          
Best regards

          
 

          
Jacques 

          
 

          
   

          
 

          
-----Message d'origine-----

          
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion

          
 

          
Hello all,

          
 

          
Not sure we all have the same understanding here.

          
Let me try to explain my concerns.

          
 

          
The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.

          
Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:

          
 

          
a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.

          
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.

          
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.

          
Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):

          
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."

          
But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.

          
How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:

          
- C1 sends a Realm request via Agent, that finally reaches S1

          
- S1 answers with OLR (Host:50%).

          
- Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?

          
In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.

          
 

          
b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.

          
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

          
 

          
Let me know your opinions please

          
Best regards

          
/MCruz

          
 

          
 

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

          
Sent: lunes, 24 de febrero de 2014 12:28

          
To: ext Steve Donovan; dime@ietf.org

          
Subject: Re: [Dime] Issue#35 conclusion

          
 

          
Steve,

          
 

          
please see inline.

          
 

          
Ulrich

          
 

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

          
Sent: Friday, February 21, 2014 4:53 PM

          
To: dime@ietf.org

          
Subject: Re: [Dime] Issue#35 conclusion

          
 

          
Ulrich,

          
 

          
I have a couple of concerns with this approach, as currently outlined.  

          
 

          
First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.

          
<Ulrich>I fully agree</Ulrich>

          
 

          
 

          
We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.

          
<Ulrich>I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>

          
 

          
My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.

          
<Ulrich> I agree </Ulrich>

          
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.

          
<Ulrich>I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

          
 

          
Steve

          
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

          
Ben,

          
 

          
the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 

          
Now you seem to address two points:

          
a) There is no dependency to DOIC support of the client.

          
To address this I would like to propose rewording of the clarifying text for 5.5. as follows:

          
 

          
When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 

          
 

          
This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.

          
 

          
b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:

          
1. ignore the 3GPP requirement

          
2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.

          
 

          
So far I understood that people favoured option 3.

          
 

          
See also inline.

          
 

          
Ulrich

          
 

          
 

          
 

          
-----Original Message-----

          
From: ext Ben Campbell [mailto:ben@nostrum.com]

          
Sent: Thursday, February 20, 2014 11:55 PM

          
To: Wiehe, Ulrich (NSN - DE/Munich)

          
Cc: dime@ietf.org

          
Subject: Re: [Dime] Issue#35 conclusion

          
 

          
 

          
On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

          
 

          
#35: additional report types are proposed

          
 

          
Dear all,

          
 

          
I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:

          
 

          
When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

          
 

          
I do not agree.

          
 

          
You proposal implies that the server's OLR only applies to that client.

          
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.

          
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

          
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

          
 

          
 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.

          
 

          
_______________________________________________

          
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

          
 

          
_______________________________________________

          
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

          
 

          
_________________________________________________________________________________________________________________________

          
 

          
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.

          
 

          
_______________________________________________

          
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


    

    

  


--------------000305020504060007060904--


From nobody Mon Feb 24 10:51:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C261A02B4 for ; Mon, 24 Feb 2014 10:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 85CnYXpqa0Ax for ; Mon, 24 Feb 2014 10:51:40 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC131A02B8 for ; Mon, 24 Feb 2014 10:51:40 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-4a-530b94baf28e
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6E.55.04249.AB49B035; Mon, 24 Feb 2014 19:51:39 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 19:51:38 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
Thread-Index: AQHPMXw7Go/E8EkQY06I9J5ntJSCrprEvtUg
Date: Mon, 24 Feb 2014 18:51:38 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org>
In-Reply-To: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje7uKdzBBqfOclvM7V3BZjFlxR8m ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvjfd9DloJdkhVfLvE0MM4T6WLk5JAQMJFY cOw3K4QtJnHh3nq2LkYuDiGBI4wSm7b8YwNJCAksZpQ4sDEOxGYTsJO4dPoFUxcjB4eIQInE 1DZdkLCwQKDEoVuXWUBsEYEgiUnzVjJDlBhJPDmmBRJmEVCVeL/pDSOIzSvgK9F9dgkrxHQ3 iUMH5zCB2JwC7hJPN+8H28oIdM73U2vA4swC4hK3nsxngjhTQGLJnvPMELaoxMvH/6DOV5S4 On05VL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMXIUpxYn 5aYbGWxiBMbBwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MbTNVt7gGVFh4/7gSLj834Xy2Sen1I/fePpnBeY1tnd4Ge09JW09X96h1/itiairrIk6d zhSdcOr9GcPgFVqv2Pmf3btZEPmwKLHtSfwnpqq2hwXzZC3WX/dlXH+gZemFf5FTfiVrr5Hq mTv346pVs2/UT3mTUvXd8/D9PFOfhW/ZVzHcZLj6V4mlOCPRUIu5qDgRAFEDMY5RAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/R2eiYvLGbS0TlFYiPykww4XJdhk
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 18:51:43 -0000

Steve,

See some comments below please.
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
Sent: lunes, 24 de febrero de 2014 17:20
To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

#57: Handling of "Realm-Routed" Overload report type

 I'm assuming the name of the realm overload report in the -01 version will
 be changed to realm-routed.  This issue applies independent of the actual
 name of the report.

 The current behavior assumed for the realm-routed report is that the
 reacting node, generally the client, will reduce the percentage of realm
 routed requests sent to the reporting node.

 This is actually bad behavior and could result in the client throttling
 traffic that could have been handled by the full set of servers for that
 Diameter application.
[MCruz] This can only happen if the agent has miscalculated the realm overl=
oad.

 Consider the case where there are n servers for a Diameter application and
 all of those server are able to handle any transaction for that
 application.

 When one of those servers becomes overloaded and wishes to decrease the
 number of new sessions, the primary use of realm-routed requests.  The
 server will generate an OLR of type realm-routed.
[MCruz] I do not agree. Servers do not generate Realm-routed reports.

 Assume in this case that the other servers are all healthy and able to
 handle new sessions.

 Clients will not have the knowledge that there are other servers in the
 network able to handle the new session and will have no choice but the
 throttle a percentage of the new session requests.  Even when these
 throttled requests could have been handled by any of the non overloaded
 servers.

 The proposal is to specify that realm-routed reports must be handled by
 DOIC-supporting agents.  Agents will understand if there are other servers
 able to handle the new session and, if so, can adjust the percentage of
 requests routed to the overloaded server.

 Agents that handle the realm-routed OLR must remove the request from the
 answer before relaying the answer to client.  This prevents the report
 from being acted on by either multiple agents (if multiple are in the
 path) or by an agent and a client.

 Clients that receive the realm-routed OLR must handle the OLR by
 throttling the requested percentage.

--=20
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-docdt-dime-ovli    |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
dime 

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


From nobody Mon Feb 24 10:57:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CD01A02B8 for ; Mon, 24 Feb 2014 10:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8guj1A4Gjsn for ; Mon, 24 Feb 2014 10:57:18 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 935C31A0154 for ; Mon, 24 Feb 2014 10:57:17 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id DA26E324413; Mon, 24 Feb 2014 19:57:15 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C1F6435C092; Mon, 24 Feb 2014 19:57:15 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 19:57:15 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750AAFZYT7AASMSeAAAPq9AP//85aA///u9UA=
Date: Mon, 24 Feb 2014 18:57:14 +0000
Message-ID: <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4177@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com>
In-Reply-To: <530B9469.4070403@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4BC596PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.24.133018
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OetUy3Z5ybA0zkZ_YGDYMdxe4tk
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 18:57:27 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4BC596PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I really don't understand but it is not the first time :)

What about the DOIC association? What about my assumption about agent maint=
aining overload control state for non-DOIC enabled client?
So for me, the proposal from Ulrich is a clarification on the agent behavio=
r that was implicit if you consider the comments above.

For me, the option for the server is only to send a specific OLR for a spec=
ific client. So over two different DOIC association with the same server/re=
porting node, you can have two different OLRs.
But it does not change the way the OLR is handled by reacting nodes.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Maria Cruz,

To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of the ba=
se specification, as it is likely that most/all applications will want the =
same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origin-Hos=
t reports should be specified in a common way.

Steve
On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
Hello again,

I forgot to mention something else in this thread, that I already mentioned=
 in related thread #56.

This is all in order to take into account 3GPP requirement on overload miti=
gation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".



Therefore, we can even consider this new OLR out of the base draft, and be =
considered by 3GPP applications when required.



Best regards

/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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


___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4BC596PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I really d=
on't understand but it is not the first time
J


 <=
/p>

What about=
 the DOIC association? What about my assumption about agent maintaining ove=
rload control state for non-DOIC enabled client?


So for me,=
 the proposal from Ulrich is a clarification on the agent behavior that was=
 implicit if you consider the comments above.


 =
;


For me, th=
e option for the server is only to send a specific OLR for a specific clien=
t. So over two different DOIC association with the same server/reporting
 node, you can have two different OLRs.


But it doe=
s not change the way the OLR is handled by reacting nodes.


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 19:50

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Maria Cruz,



To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of t=
he base specification, as it is likely that most/all applications will want=
 the same behavior.



Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origi=
n-Host reports should be specified in a common way.



Steve




On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:






Hello=
 again,


 =
;


I for=
got to mention something else in this thread, that I already mentioned in r=
elated thread #56.


 =
;


This =
is all in order to take into account 3GPP requirement on overload mitigatio=
n differentiation per client. But this is a server option:


TR 29809 ch. 6.4.7.1 states "It may be up to=
 the server/agent implementations to decide when and whether overload mitig=
ation differentiation per client is used".


 


Therefore, we can even consider this new OLR out =
of the base draft, and be considered by 3GPP applications when required.


 


Best regards


/MCruz


 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: lunes, 24 de febrero de 2014 19:19

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Steve, all,




I agree with Steve.


 <=
/p>

However, I would like to =
share one concern. We need to avoid that existing (if any) host OLR (“=
;all-client”) in the reacting node is replaced by new host OLR
 (per client).


Host OLR (per client) wit=
h the new AVP requires that the server uses a new sequence number, but exis=
ting host OLR (all) shall not be replaced, on the contrary
 both Host OLR (all) and new Host OLR (per client) should remain.


In order to achieve this,=
 it could be more convenient to use a dedicated OLR type (host per client),=
 instead of a new AVP.


 <=
/p>

Let me know your opinions=
.


Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Adding an AVP to indi=
cate that a report applies just to the Origin-Host in the request is not ju=
st an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






Is it implicit? 


 


If the agent detects that a client is not supporting DOIC, this agent =
will have to store the corresponding overload control state on behalf of th=
is client and only this client (saying that other clients may support DOIC)=
. I'm assuming then that any agent will have to store somewhere the origin-=
host of this client. And therefore, I don't see what would be the added-val=
ue of this AVP saying that this OLR is only for this client.

 


Even if this AVP is present, it would not preclude a reporting node to=
 always put this AVP in every answer, even if the OLR is the same for all t=
he clients.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27


=C0 : dime@ietf.org


Objet : Re: [Dime] Issue#35 conclusion


 


Hello Ulrich,


 


I haven't proposed to limit this to host type OLR, I just wanted to cl=
arify if this is what JJ got in mind.


 


I agree it could be done as you explained in the example below, but th=
e open question is whether it is better to add an AVP when OLR is just mean=
t for one single client, or on the contrary the agent _always_ need to bind=
 OLR to one specific client, even if the server simply requires same OLR fo=
r any client. 


 


I think having a new AVP simplifies agent behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: lunes, 24 de febrero de 2014 14:19


To: Maria Cruz Bartolome; dime@ietf.o=
rg


Subject: RE: [Dime] Issue#35 conclusion


 


Hi MCruz,


there is no reason to limit this to host type OLRs.


 


If we have an agent A that is configured to take the role of the repor=
ting node for realm-type reports for realm R, A could receive host type OLR=
s from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% =
reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin fro=
m C2); A then would aggregate these info and return realm type OLRs to C1 r=
equesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% r=
eduction of traffic from C2 to R.


 


Best regards


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Monday, February 24, 2014 2:02 PM


To: dime@ietf.org


Subject: Re: [Dime] Issue#35 conclusion


 


Hello JJ and all,


 


As per email thread, the latest proposal is:


"When an agent takes the role of a reacting node, the agent needs=
 to bind a received OLR to the origin host of the client that initiated the=
 request which corresponds to the answer containing the OLR." 


 


An Ulrich comments on this:


"This would cover not only the case where an agent takes the role=
 of the reacting node on behalf of a (or several) non supporting client, bu=
t also the case where an agent is configured to take the role of a reportin=
g node (for realm-type reports) towards the client and at the same time the=
 role of a reacting node towards the server."


 


Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)


Sent: lunes, 24 de febrero de 2014 13:43


To: dime@ietf.org


Subject: Re: [Dime] Issue#35 conclusion


 


Hi Mcruz and all


 


I think that you are  mixing the case of the DA that is the "=
;reporting" node which wants to indicate a realm OLR to clients, and f=
or which will use various (non standardized ) ways to determine among which=
 it can reuse the Host-OLR AVPs received from various servers. But in this =
case, clients receiving realm OLRs are supporting DOIC. 


Here I understand the on going  discussion is about the DA behavi=
or when  clients is not supporting DOIC and to reuse the Host-OLR rece=
ived for one client for other clients  .


 


For me I remain on  my previous mail, with a baseline solution. W=
e may always study new extensions, optimizations, but priority should be on=
 the baseline.


 


Best regards


 


Jacques 


 


   


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lun=
di 24 f=E9vrier 2014 13:21 =C0 : dime=
@ietf.org Objet : Re: [Dime] Issue#35 conclusion


 


Hello all,


 


Not sure we all have the same understanding here.


Let me try to explain my concerns.


 


The original 3GPP requirement we want to cover is the need for a serve=
r to reduce traffic for one specific client, i.e. traffic identified by &qu=
ot;Origin-Host" in the request.


Then, two options are under analysis about whether or not the OLR in t=
he server answer shall be marked:


 


a) OLR does not need to include anything else Receiver of the answer (=
and OLR) is the client that sends the request, identified by "Origin-H=
ost" in the request.


Then, as long as the reacting node=3D=3D"Origin-Host", the e=
xpected reduction is performed and requirement fulfilled.


But, when an agent is acting on behalf of a client as the reacting nod=
e, then the "Origin-Host" identifies final client, but not the re=
acting node.


Then, this is why the proposal is to add following clarification about=
 agent behavior (possible clause 5.5):


"When an agent takes the role of a reacting node, the agent needs=
 to bind a received OLR to the origin host of the client that initiated the=
 request which corresponds to the answer containing the OLR."


But this will imply that _always_ the reacting node applies this OLR t=
o one specific client, what is not what we need to achieve.


How will this impact the case where the agent is providing access to a=
 Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's cons=
ider following example:


- C1 sends a Realm request via Agent, that finally reaches S1


- S1 answers with OLR (Host:50%).


- Agent is acting as reacting node on behalf of C1, if it considers th=
is OLR only bind to C1... then... should it consider S1-OLR only as relevan=
t for requests coming from C1? Should agent do not use this S1-OLR to calcu=
late aggregated Realm overload?


In my opinion, in this case it does not make sense to consider OLR was=
 only meant to C1. And this problem could be solved adding explicit informa=
tion, as in b) below.


 


b) OLR needs to be extended (new AVP) that identifies the client (&quo=
t;Origin-Host" in the request) from which traffic reduction shall appl=
y.


With this new AVP, reacting node will easy be able to identify when OL=
R shall be applied to any client or just to the Origin-Host identified by n=
ew AVP.


 


Let me know your opinions please


Best regards


/MCruz


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28


To: ext Steve Donovan; dime@ietf.org<=
/a>


Subject: Re: [Dime] Issue#35 conclusion


 


Steve,


 


please see inline.


 


Ulrich


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Friday, February 21, 2014 4:53 PM


To: dime@ietf.org


Subject: Re: [Dime] Issue#35 conclusion


 


Ulrich,


 


I have a couple of concerns with this approach, as currently outlined.=
  


 


First, how do we handle the case where there are multiple DOIC support=
ing agents between the non supporting client and the reporting node.  =
This, I guess, is a general question, not just applying to this proposal.&n=
bsp; I suggest we capture in the agent behavior section that is currently m=
issing wording indicating that the first supporting agent that receives the=
 request must be the reacting node for that non-supporting client.  Su=
bsequent DOIC supporting agents must not be the reacting node for the non-s=
upporting client.


<Ulrich>I fully agree</Ulrich>


 


 


We need to think through the ramifications of having multiple agents b=
eing the reacting node for the same non supporting clients, as this could e=
asily happen in networks where multiple agents are involved in a single tra=
nsaction.  On the surface it doesn't seem to be an issue for the loss =
algorithm, but this might not be the case with other algorithms.=



<Ulrich>I agree that this is not an issue for loss; it is an iss=
ue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich&=
gt;


 


My other concern is that this puts a lot of extra onus on the agent ev=
en for the case where the reporting node does not want to differentiate ove=
rload reports.


<Ulrich> I agree </Ulrich>


To this end I suggest we add an indication in the OLR marking the repo=
rts that are specific to just the Origin-Host in the request.  Absence=
 of the "single-client-only" AVP would mean that the report appli=
es to all clients.  Presence of the AVP would indicate that the OLR ap=
plies to the Origin-Host.


<Ulrich>I understand that the proposal is an optimization for ag=
ents. Therefore the semantics of the marking should be reverse: unmarked OL=
Rs are client specific, marked OLRs indicate that the reporting node does n=
ot want to differentiate, and therefore allow agents not to do the binding =
to the client.</Ulrich>     


 


Steve


On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:<=
/pre>

Ben,


 


the proposed conclusion was based on comments received so far (from Li=
onel, Nirav, Steve, MCruz, JJ). 


Now you seem to address two points:


a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying te=
xt for 5.5. as follows:


 


When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR. 


 


This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server.


 


b) There is no binding of the OLR to the orig-host of the client Here =
I disagree. We have the 3GPP requirement to allow requesting different amou=
nt of reduction from different clients, and I think we have 3 options:=



1. ignore the 3GPP requirement


2. introduce new report types as originally proposed in #35 3. introdu=
ce the binding between OLR and orig-host of the client.


 


So far I understood that people favoured option 3.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [mailto:ben@=
nostrum.com]


Sent: Thursday, February 20, 2014 11:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org


Subject: Re: [Dime] Issue#35 conclusion


 


 


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:


 


#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional report types. However=
, we agreed to add clarifying text to clause 5.5 as follows:

 


When an agent received an OLR in response to a request initiated by a =
client not supporting DOIC, this agent needs to bind the received OLR to th=
e origin-host of the client.


 


I do not agree.


 


You proposal implies that the server's OLR only applies to that client=
.


<Ulrich>exactly, that was the intention</Ulrich>  If =
there's an intervening DOIC agent, then the agent, not the client, is the r=
eacting node from the server's perspective.


<Ulrich> the server's perspective is agnostic. The server does n=
ot know whether it's the client or an agent on the path that takes the role=
 of the reacting node</Ulrich>  But, short of adding an origin-h=
ost type, nothing binds the OLR to a particular client, regardless of DOIC =
support at the clients.


<Ulrich> the binding is always there, regardless of DOIC support=
 at the client</Ulrich>


 


 Whether or not the client also supports DOIC doesn't change that. For=
 DOIC-supporting clients, the agent has the additional option of reducing t=
raffic by asking the clients to reduce traffic (making them reacting nodes =
from the perspective of the _agent_, but not the server.)  It doesn't =
have that option for non-DOIC clients.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4BC596PEXCVZYM13corpora_--


From nobody Mon Feb 24 11:12:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2401A0283 for ; Mon, 24 Feb 2014 11:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk2nkVUbnet9 for ; Mon, 24 Feb 2014 11:12:47 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C21851A0272 for ; Mon, 24 Feb 2014 11:12:46 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-a9-530b99adbac9
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id FD.5D.04853.DA99B035; Mon, 24 Feb 2014 20:12:45 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 20:12:44 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue #23 Proposed resolution
Thread-Index: AQHPMYgSECydxGIpskK7qjdEofxvM5rExTAw
Date: Mon, 24 Feb 2014 19:12:44 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se>
References: <530B84F8.5030006@usdonovans.com>
In-Reply-To: <530B84F8.5030006@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784BEDESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7amdzBBksnSlrM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPvd7SwFH7Uqjt9rY21gPK/axcjJISFgItG5ZDsbhC0mceHe eiCbi0NI4ASjxIl3d6GcxYwS/182MYJUsQnYSVw6/YKpi5GDQ0RAWeL0LwcQU1jAUOL7B0GQ ChEBI4mGL7OZYOxzFyaDdbIIqEp8eL6EBcTmFfCVuPhqBzuILSSgK7F38g+wek4BPYmFO6+D xRmB7vl+ag1YnFlAXOLWk/lMEHcKSCzZc54ZwhaVePn4HyuErSjx8dU+Roj6fIlVb7cwQ+wS lDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFmcWlyc m25koJebnluil1qUmVxcnJ+nV5y6iREYSQe3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGGXM9R+X2IltmifZKr3HqnPT6nelFUpVtYHxM5j2scRtucJt NmVD0IGfPwJCjGoWRHjNVr2sd1Hj5HeGdat2WR1bsaGpsKtBWsMr12nZ4qvNBgFrlwYxJsdM vimnuW52eNZtruruUtWnMd/mfJkaVXL/0rn+O7FrD3O03zmpeyQ7O3BmZp7lPiWW4oxEQy3m ouJEAHWYhX9yAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iUhPIlhsm6cvyHB0yl3HWKK-BwE
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 19:12:49 -0000

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

Hello,

I do not think we have agreed so far on the need to have two different repo=
rts (so called realm-routed and just realm).
Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: dime@ietf.org
Subject: [Dime] Issue #23 Proposed resolution

I propose the following resolution for issue 23:


Proposal - Change the name of realm report.

Proposed name - "Realm-Routed-Request" report.

Proposal - Update all discussion on "Realm-Routed-Request" reports to indic=
ate that they apply only to requests targeted to a realm when there is no d=
estination-host AVP in the request.  Specifically, section 4.6 requires upd=
ating.

There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.

Regards,

Steve

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











Hello=
,


=
 


I do =
not think we have agreed so far on the need to have two different reports (=
so called realm-routed and just realm).


Regar=
ds


/MCru=
z


=
 






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

Sent: lunes, 24 de febrero de 2014 18:44

To: dime@ietf.org

Subject: [Dime] Issue #23 Proposed resolution






 


I propose the following resolution for issue 23:








Proposal – Change the name of realm report.  




Proposed name - “Realm-Routed-Request” report.




Proposal – Update all discussion on “Realm-Routed-Request”=
; reports to indicate that they apply only to requests targeted to a realm =
when there is no destination-host AVP in the request.  Specifically, s=
ection 4.6 requires updating.



There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.



Regards,



Steve 






--_000_087A34937E64E74E848732CFF8354B9209784BEDESESSMB101erics_--


From nobody Mon Feb 24 11:24:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E201A018C for ; Mon, 24 Feb 2014 11:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.35
X-Spam-Level: 
X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNfYVazcOGAW for ; Mon, 24 Feb 2014 11:24:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id C434E1A0160 for ; Mon, 24 Feb 2014 11:24:16 -0800 (PST)
Received: from [137.254.4.54] (port=61233 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI18N-0005u5-S4; Mon, 24 Feb 2014 11:24:15 -0800
Message-ID: <530B9C5E.90800@usdonovans.com>
Date: Mon, 24 Feb 2014 13:24:14 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: lionel.morand@orange.com, "dime@ietf.org" 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------040409040101070104070900"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eLwYjtF8NU_T0wVML8-mLSrvhSc
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 19:24:24 -0000

This is a multi-part message in MIME format.
--------------040409040101070104070900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Lionel,

The question is whether the reporting node is sending the overload
report per client or it is sending a global overload report that applies
to all clients. 

I still believe that the default behavior of a reporting node will be to
have a single overload reduction value for the application and that that
overload reduction value will apply to all clients.  If this is the case
then there is little benefit (and significant overhead) to requiring an
agent to maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to
have a different reduction value for specific reacting nodes.  If this
is the case then the reporting node should indicate that it only applies
to the origin-host in the request and only then should agents be
required to maintain state for the non-supporting client.

Steve

On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:
>
> I really don't understand but it is not the first time J
>
>  
>
> What about the DOIC association? What about my assumption about agent
> maintaining overload control state for non-DOIC enabled client?
>
> So for me, the proposal from Ulrich is a clarification on the agent
> behavior that was implicit if you consider the comments above.
>
>  
>
> For me, the option for the server is only to send a specific OLR for a
> specific client. So over two different DOIC association with the same
> server/reporting node, you can have two different OLRs.
>
> But it does not change the way the OLR is handled by reacting nodes.
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* lundi 24 février 2014 19:50
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] Issue#35 conclusion
>
>  
>
> Maria Cruz,
>
> To the degree possible we should minimize the per application overload
> logic required.  To this end, it would be better to have this as part
> of the base specification, as it is likely that most/all applications
> will want the same behavior.
>
> Whether a reporting node uses per Origin-Host reports is an
> implementation detail of the reporting node.  How reacting nodes
> respond to per Origin-Host reports should be specified in a common way.
>
> Steve
>
> On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
>
>     Hello again,
>
>      
>
>     I forgot to mention something else in this thread, that I already
>     mentioned in related thread #56.
>
>      
>
>     This is all in order to take into account 3GPP requirement on
>     overload mitigation differentiation per client. But this is a
>     server option:
>
>     TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent
>     implementations to decide when and whether overload mitigation
>     differentiation per client is used".
>
>      
>
>     Therefore, we can even consider this new OLR out of the base
>     draft, and be considered by 3GPP applications when required.
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria
>     Cruz Bartolome
>     *Sent:* lunes, 24 de febrero de 2014 19:19
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>     Steve, all,
>
>
>     I agree with Steve.
>
>      
>
>     However, I would like to share one concern. We need to avoid that
>     existing (if any) host OLR ("all-client") in the reacting node is
>     replaced by new host OLR (per client).
>
>     Host OLR (per client) with the new AVP requires that the server
>     uses a new sequence number, but existing host OLR (all) shall not
>     be replaced, on the contrary both Host OLR (all) and new Host OLR
>     (per client) should remain.
>
>     In order to achieve this, it could be more convenient to use a
>     dedicated OLR type (host per client), instead of a new AVP.
>
>      
>
>     Let me know your opinions.
>
>     Best regards
>
>     /MCruz
>
>      
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve
>     Donovan
>     *Sent:* lunes, 24 de febrero de 2014 16:56
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>     Adding an AVP to indicate that a report applies just to the
>     Origin-Host in the request is not just an optimization for agents.
>
>     It had been my assumption all along that the default behavior of a
>     reporting node (server) would be to report a single overload value
>     to all reacting nodes, be they clients or agents.  If this is the
>     default behavior then it would be best to have the default,
>     implicit, meaning of an overload report to be "applies to all
>     reacting nodes".  The real value of this new feature is to allow a
>     server to further throttle a specific, overly active, reacting
>     node when then global reduction percentage doesn't do the job.
>
>     In addition, if the normal case is that reporting nodes have a
>     single global reduction percentage then requiring agents to bind
>     an overload report to each non supporting clients pushes a lot of
>     extra work on agents when it adds no value.
>
>     My proposal is the following:
>
>     - Add an optional AVP (call it something like Single-Node???) to
>     overload reports that indicate when an overload report applies to
>     a specific reacting node.
>
>     - Absence of the AVP indicates that the report applies to all
>     reacting nodes (clients and agents acting on behalf of non-DOIC
>     clients).
>
>     - Reporting nodes should only include the Single-Node AVP if the
>     overload report contents are different from the global overload
>     report.
>
>     - DOIC-supporting agents receiving an OLR without the Single-Node
>     AVP must do the following:
>       - For transactions from DOIC-supporting clients the agent must
>     not act on the OLR.
>       - For transactions from non-DOIC-supporting clients the agent
>     must apply the OLR to traffic from the set of non supporting
>     clients.   This implies that when making throttling decisions, the
>     agent does not differentiate which non supporting client
>     originated the request.
>
>     - DOIC-supporting agents receiving an OLR with the Single-Node AVP
>     for a transaction originated by a non supporting client must bind
>     that OLR to that single client.
>
>     Note that the agent behavior is currently something that is
>     missing from the -01 version of the draft.  We will need something
>     like this wording independent of the resolution of this issue.
>
>     Steve
>
>     On 2/24/14 8:06 AM, lionel.morand@orange.com
>      wrote:
>
>         Is it implicit? 
>
>          
>
>         If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.
>
>          
>
>         Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.
>
>          
>
>         Regards,
>
>          
>
>         Lionel
>
>          
>
>         -----Message d'origine-----
>
>         De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
>
>         Envoyé : lundi 24 février 2014 14:27
>
>         À : dime@ietf.org 
>
>         Objet : Re: [Dime] Issue#35 conclusion
>
>          
>
>         Hello Ulrich,
>
>          
>
>         I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.
>
>          
>
>         I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 
>
>          
>
>         I think having a new AVP simplifies agent behavior.
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         -----Original Message-----
>
>         From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>
>         Sent: lunes, 24 de febrero de 2014 14:19
>
>         To: Maria Cruz Bartolome; dime@ietf.org 
>
>         Subject: RE: [Dime] Issue#35 conclusion
>
>          
>
>         Hi MCruz,
>
>         there is no reason to limit this to host type OLRs.
>
>          
>
>         If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.
>
>          
>
>         Best regards
>
>         Ulrich
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
>
>         Sent: Monday, February 24, 2014 2:02 PM
>
>         To: dime@ietf.org 
>
>         Subject: Re: [Dime] Issue#35 conclusion
>
>          
>
>         Hello JJ and all,
>
>          
>
>         As per email thread, the latest proposal is:
>
>         "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 
>
>          
>
>         An Ulrich comments on this:
>
>         "This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."
>
>          
>
>         Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
>
>         Best regards
>
>         /MCruz
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>         Sent: lunes, 24 de febrero de 2014 13:43
>
>         To: dime@ietf.org 
>
>         Subject: Re: [Dime] Issue#35 conclusion
>
>          
>
>         Hi Mcruz and all
>
>          
>
>         I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
>
>         Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .
>
>          
>
>         For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.
>
>          
>
>         Best regards
>
>          
>
>         Jacques 
>
>          
>
>            
>
>          
>
>         -----Message d'origine-----
>
>         De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org  Objet : Re: [Dime] Issue#35 conclusion
>
>          
>
>         Hello all,
>
>          
>
>         Not sure we all have the same understanding here.
>
>         Let me try to explain my concerns.
>
>          
>
>         The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.
>
>         Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:
>
>          
>
>         a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
>
>         Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
>
>         But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
>
>         Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):
>
>         "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."
>
>         But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.
>
>         How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:
>
>         - C1 sends a Realm request via Agent, that finally reaches S1
>
>         - S1 answers with OLR (Host:50%).
>
>         - Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?
>
>         In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.
>
>          
>
>         b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.
>
>         With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.
>
>          
>
>         Let me know your opinions please
>
>         Best regards
>
>         /MCruz
>
>          
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
>
>         Sent: lunes, 24 de febrero de 2014 12:28
>
>         To: ext Steve Donovan; dime@ietf.org 
>
>         Subject: Re: [Dime] Issue#35 conclusion
>
>          
>
>         Steve,
>
>          
>
>         please see inline.
>
>          
>
>         Ulrich
>
>          
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>
>         Sent: Friday, February 21, 2014 4:53 PM
>
>         To: dime@ietf.org 
>
>         Subject: Re: [Dime] Issue#35 conclusion
>
>          
>
>         Ulrich,
>
>          
>
>         I have a couple of concerns with this approach, as currently outlined.  
>
>          
>
>         First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.
>
>         I fully agree
>
>          
>
>          
>
>         We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.
>
>         I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)
>
>          
>
>         My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.
>
>          I agree 
>
>         To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.
>
>         I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.     
>
>          
>
>         Steve
>
>         On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Ben,
>
>          
>
>         the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
>
>         Now you seem to address two points:
>
>         a) There is no dependency to DOIC support of the client.
>
>         To address this I would like to propose rewording of the clarifying text for 5.5. as follows:
>
>          
>
>         When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 
>
>          
>
>         This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.
>
>          
>
>         b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
>
>         1. ignore the 3GPP requirement
>
>         2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.
>
>          
>
>         So far I understood that people favoured option 3.
>
>          
>
>         See also inline.
>
>          
>
>         Ulrich
>
>          
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: ext Ben Campbell [mailto:ben@nostrum.com]
>
>         Sent: Thursday, February 20, 2014 11:55 PM
>
>         To: Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc: dime@ietf.org 
>
>         Subject: Re: [Dime] Issue#35 conclusion
>
>          
>
>          
>
>         On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)   wrote:
>
>          
>
>         #35: additional report types are proposed
>
>          
>
>         Dear all,
>
>          
>
>         I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>
>          
>
>         When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.
>
>          
>
>         I do not agree.
>
>          
>
>         You proposal implies that the server's OLR only applies to that client.
>
>         exactly, that was the intention  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
>
>          the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>
>          the binding is always there, regardless of DOIC support at the client
>
>          
>
>          Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.
>
>          
>
>         _______________________________________________
>
>         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
>
>          
>
>         _______________________________________________
>
>         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
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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.
>
>          
>
>         _______________________________________________
>
>         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
>
>  
>
> _________________________________________________________________________________________________________________________
>
> 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.


--------------040409040101070104070900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Lionel,

      

      The question is whether the reporting node is sending the overload
      report per client or it is sending a global overload report that
      applies to all clients.  

      

      I still believe that the default behavior of a reporting node will
      be to have a single overload reduction value for the application
      and that that overload reduction value will apply to all clients. 
      If this is the case then there is little benefit (and significant
      overhead) to requiring an agent to maintain state per
      non-supporting client.

      

      I also agree that there is value to the reporting node being able
      to have a different reduction value for specific reacting nodes. 
      If this is the case then the reporting node should indicate that
      it only applies to the origin-host in the request and only then
      should agents be required to maintain state for the non-supporting
      client.

      

      Steve

      

    
    
On 2/24/14 12:57 PM,
      lionel.morand@orange.com wrote:

    

    

      
      
      
      

        
I really don't understand but it is not the
            first time
          J

        
 

        
What about the DOIC association? What about my
            assumption about agent maintaining overload control state
            for non-DOIC enabled client?

        
So for me, the proposal from Ulrich is a
            clarification on the agent behavior that was implicit if you
            consider the comments above.

        
 

        
For me, the option for the server is only to
            send a specific OLR for a specific client. So over two
            different DOIC association with the same server/reporting
            node, you can have two different OLRs.

        
But it does not change the way the OLR is
            handled by reacting nodes.

        
 

        
Lionel

        
 

        

          

            
De :
                DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : lundi 24 février 2014 19:50

                À : dime@ietf.org

                Objet : Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Maria Cruz,

          

          To the degree possible we should minimize the per application
          overload logic required.  To this end, it would be better to
          have this as part of the base specification, as it is likely
          that most/all applications will want the same behavior.

          

          Whether a reporting node uses per Origin-Host reports is an
          implementation detail of the reporting node.  How reacting
          nodes respond to per Origin-Host reports should be specified
          in a common way.

          

          Steve

        

          
On 2/24/14 12:40 PM, Maria Cruz Bartolome
            wrote:

        

        

          
Hello again,

          
 

          
I forgot to mention
              something else in this thread, that I already mentioned in
              related thread #56.

          
 

          
This is all in
              order to take into account 3GPP requirement on overload
              mitigation differentiation per client. But this is a
              server option:

          
TR 29809 ch. 6.4.7.1 states "It may be
            up to the server/agent implementations to decide when and
            whether overload mitigation differentiation per client is
            used".

          
 

          
Therefore, we can even consider this
            new OLR out of the base draft, and be considered by 3GPP
            applications when required.

          
 

          
Best regards

          
/MCruz

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of Maria Cruz Bartolome

                  Sent: lunes, 24 de febrero de 2014 19:19

                  To: dime@ietf.org

                  Subject: Re: [Dime] Issue#35 conclusion

            

          

          
 

          
Steve,
              all,

          


              I agree with Steve.

          
 

          
However,
              I would like to share one concern. We need to avoid that
              existing (if any) host OLR (“all-client”) in the reacting
              node is replaced by new host OLR (per client).

          
Host
              OLR (per client) with the new AVP requires that the server
              uses a new sequence number, but existing host OLR (all)
              shall not be replaced, on the contrary both Host OLR (all)
              and new Host OLR (per client) should remain.

          
In
              order to achieve this, it could be more convenient to use
              a dedicated OLR type (host per client), instead of a new
              AVP.

          
 

          
Let
              me know your opinions.

          
Best
              regards

          
/MCruz

          
 

          
 

          

            

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

                  Sent: lunes, 24 de febrero de 2014 16:56

                  To: dime@ietf.org

                  Subject: Re: [Dime] Issue#35 conclusion

            

          

          
 

          
Adding an
            AVP to indicate that a report applies just to the
            Origin-Host in the request is not just an optimization for
            agents.

            

            It had been my assumption all along that the default
            behavior of a reporting node (server) would be to report a
            single overload value to all reacting nodes, be they clients
            or agents.  If this is the default behavior then it would be
            best to have the default, implicit, meaning of an overload
            report to be "applies to all reacting nodes".  The real
            value of this new feature is to allow a server to further
            throttle a specific, overly active, reacting node when then
            global reduction percentage doesn't do the job.

            

            In addition, if the normal case is that reporting nodes have
            a single global reduction percentage then requiring agents
            to bind an overload report to each non supporting clients
            pushes a lot of extra work on agents when it adds no value.

            

            My proposal is the following:

            

            - Add an optional AVP (call it something like
            Single-Node???) to overload reports that indicate when an
            overload report applies to a specific reacting node.

            

            - Absence of the AVP indicates that the report applies to
            all reacting nodes (clients and agents acting on behalf of
            non-DOIC clients).

            

            - Reporting nodes should only include the Single-Node AVP if
            the overload report contents are different from the global
            overload report.

            

            - DOIC-supporting agents receiving an OLR without the
            Single-Node AVP must do the following:

              - For transactions from DOIC-supporting clients the agent
            must not act on the OLR.

              - For transactions from non-DOIC-supporting clients the
            agent must apply the OLR to traffic from the set of non
            supporting clients.   This implies that when making
            throttling decisions, the agent does not differentiate which
            non supporting client originated the request.

            

            - DOIC-supporting agents receiving an OLR with the
            Single-Node AVP for a transaction originated by a non
            supporting client must bind that OLR to that single client.

            

            Note that the agent behavior is currently something that is
            missing from the -01 version of the draft.  We will need
            something like this wording independent of the resolution of
            this issue.

            

            Steve

          

            
On 2/24/14 8:06 AM, 
                lionel.morand@orange.com wrote:

          

          

            
Is it implicit? 

            
 

            
If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.

            
 

            
Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.

            
 

            
Regards,

            
 

            
Lionel

            
 

            
-----Message d'origine-----

            
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

            
Envoyé : lundi 24 février 2014 14:27

            
À : dime@ietf.org

            
Objet : Re: [Dime] Issue#35 conclusion

            
 

            
Hello Ulrich,

            
 

            
I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.

            
 

            
I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 

            
 

            
I think having a new AVP simplifies agent behavior.

            
 

            
Best regards

            
/MCruz

            
 

            
-----Original Message-----

            
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

            
Sent: lunes, 24 de febrero de 2014 14:19

            
To: Maria Cruz Bartolome; dime@ietf.org

            
Subject: RE: [Dime] Issue#35 conclusion

            
 

            
Hi MCruz,

            
there is no reason to limit this to host type OLRs.

            
 

            
If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

            
 

            
Best regards

            
Ulrich

            
 

            
-----Original Message-----

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome

            
Sent: Monday, February 24, 2014 2:02 PM

            
To: dime@ietf.org

            
Subject: Re: [Dime] Issue#35 conclusion

            
 

            
Hello JJ and all,

            
 

            
As per email thread, the latest proposal is:

            
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 

            
 

            
An Ulrich comments on this:

            
"This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."

            
 

            
Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 

            
Best regards

            
/MCruz

            
 

            
-----Original Message-----

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

            
Sent: lunes, 24 de febrero de 2014 13:43

            
To: dime@ietf.org

            
Subject: Re: [Dime] Issue#35 conclusion

            
 

            
Hi Mcruz and all

            
 

            
I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 

            
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

            
 

            
For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

            
 

            
Best regards

            
 

            
Jacques 

            
 

            
   

            
 

            
-----Message d'origine-----

            
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion

            
 

            
Hello all,

            
 

            
Not sure we all have the same understanding here.

            
Let me try to explain my concerns.

            
 

            
The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.

            
Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:

            
 

            
a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.

            
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.

            
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.

            
Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):

            
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."

            
But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.

            
How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:

            
- C1 sends a Realm request via Agent, that finally reaches S1

            
- S1 answers with OLR (Host:50%).

            
- Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?

            
In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.

            
 

            
b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.

            
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

            
 

            
Let me know your opinions please

            
Best regards

            
/MCruz

            
 

            
 

            
 

            
-----Original Message-----

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

            
Sent: lunes, 24 de febrero de 2014 12:28

            
To: ext Steve Donovan; dime@ietf.org

            
Subject: Re: [Dime] Issue#35 conclusion

            
 

            
Steve,

            
 

            
please see inline.

            
 

            
Ulrich

            
 

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

            
Sent: Friday, February 21, 2014 4:53 PM

            
To: dime@ietf.org

            
Subject: Re: [Dime] Issue#35 conclusion

            
 

            
Ulrich,

            
 

            
I have a couple of concerns with this approach, as currently outlined.  

            
 

            
First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.

            
<Ulrich>I fully agree</Ulrich>

            
 

            
 

            
We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.

            
<Ulrich>I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>

            
 

            
My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.

            
<Ulrich> I agree </Ulrich>

            
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.

            
<Ulrich>I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

            
 

            
Steve

            
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

            
Ben,

            
 

            
the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 

            
Now you seem to address two points:

            
a) There is no dependency to DOIC support of the client.

            
To address this I would like to propose rewording of the clarifying text for 5.5. as follows:

            
 

            
When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 

            
 

            
This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.

            
 

            
b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:

            
1. ignore the 3GPP requirement

            
2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.

            
 

            
So far I understood that people favoured option 3.

            
 

            
See also inline.

            
 

            
Ulrich

            
 

            
 

            
 

            
-----Original Message-----

            
From: ext Ben Campbell [mailto:ben@nostrum.com]

            
Sent: Thursday, February 20, 2014 11:55 PM

            
To: Wiehe, Ulrich (NSN - DE/Munich)

            
Cc: dime@ietf.org

            
Subject: Re: [Dime] Issue#35 conclusion

            
 

            
 

            
On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

            
 

            
#35: additional report types are proposed

            
 

            
Dear all,

            
 

            
I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:

            
 

            
When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

            
 

            
I do not agree.

            
 

            
You proposal implies that the server's OLR only applies to that client.

            
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.

            
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

            
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

            
 

            
 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.

            
 

            
_______________________________________________

            
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

            
 

            
_______________________________________________

            
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

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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.

            
 

            
_______________________________________________

            
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

        

        
 

      

      
_________________________________________________________________________________________________________________________

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.


    

    

  


--------------040409040101070104070900--


From nobody Mon Feb 24 11:31:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD611A0198 for ; Mon, 24 Feb 2014 11:31:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm2WPsS7CYwx for ; Mon, 24 Feb 2014 11:31:23 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E4A5B1A0171 for ; Mon, 24 Feb 2014 11:31:23 -0800 (PST)
Received: from [137.254.4.54] (port=11040 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI1F8-0007zu-V1; Mon, 24 Feb 2014 11:31:16 -0800
Message-ID: <530B9E01.3050506@usdonovans.com>
Date: Mon, 24 Feb 2014 13:31:13 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Maria Cruz Bartolome ,  "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------010704000006070100020004"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SGFobr9HHe9Wm-OGDkBbA0SfweU
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 19:31:25 -0000

This is a multi-part message in MIME format.
--------------010704000006070100020004
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of
the meaning of realm-routed-request report (new attempt at a name to try
to make Ulrich happy :-) ).

My definition is that it is a report generated by the server when the
server does not want to receive new sessions. 

Your definition appears to be that it is a report generated by an agent
(or a server is there are no agents in the network?) to indicate that
the network need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can
generate a realm-routed-request report without knowing the status of
servers and their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based
applications.  This could also be applied to pseudo session based
applications and applications that always rely on realm routed requests.

Everyone, which definition applies?

Steve

On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
> Steve,
>
> See some comments below please.
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
> Sent: lunes, 24 de febrero de 2014 17:20
> To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
> Cc: dime@ietf.org
> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>
> #57: Handling of "Realm-Routed" Overload report type
>
>  I'm assuming the name of the realm overload report in the -01 version will
>  be changed to realm-routed.  This issue applies independent of the actual
>  name of the report.
>
>  The current behavior assumed for the realm-routed report is that the
>  reacting node, generally the client, will reduce the percentage of realm
>  routed requests sent to the reporting node.
>
>  This is actually bad behavior and could result in the client throttling
>  traffic that could have been handled by the full set of servers for that
>  Diameter application.
> [MCruz] This can only happen if the agent has miscalculated the realm overload.
>
>  Consider the case where there are n servers for a Diameter application and
>  all of those server are able to handle any transaction for that
>  application.
>
>  When one of those servers becomes overloaded and wishes to decrease the
>  number of new sessions, the primary use of realm-routed requests.  The
>  server will generate an OLR of type realm-routed.
> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>
>  Assume in this case that the other servers are all healthy and able to
>  handle new sessions.
>
>  Clients will not have the knowledge that there are other servers in the
>  network able to handle the new session and will have no choice but the
>  throttle a percentage of the new session requests.  Even when these
>  throttled requests could have been handled by any of the non overloaded
>  servers.
>
>  The proposal is to specify that realm-routed reports must be handled by
>  DOIC-supporting agents.  Agents will understand if there are other servers
>  able to handle the new session and, if so, can adjust the percentage of
>  requests routed to the overloaded server.
>
>  Agents that handle the realm-routed OLR must remove the request from the
>  answer before relaying the answer to client.  This prevents the report
>  from being acted on by either multiple agents (if multiple are in the
>  path) or by an agent and a client.
>
>  Clients that receive the realm-routed OLR must handle the OLR by
>  throttling the requested percentage.
>


--------------010704000006070100020004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      Thanks for the comments.  We obviously have a different
      understanding of the meaning of realm-routed-request report (new
      attempt at a name to try to make Ulrich happy :-) ).

      

      My definition is that it is a report generated by the server when
      the server does not want to receive new sessions.  

      

      Your definition appears to be that it is a report generated by an
      agent (or a server is there are no agents in the network?) to
      indicate that the network need to handle fewer new sessions.

      

      I actually think both cases apply but I don't think that an agent
      can generate a realm-routed-request report without knowing the
      status of servers and their ability to handle new Diameter
      sessions.

      

      Note that I'm discussing this in the context of session-based
      applications.  This could also be applied to pseudo session based
      applications and applications that always rely on realm routed
      requests.

      

      Everyone, which definition applies?

      

      Steve

      

    
    
On 2/24/14 12:51 PM, Maria Cruz
      Bartolome wrote:

    

    

      
Steve,

See some comments below please.
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
Sent: lunes, 24 de febrero de 2014 17:20
To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

#57: Handling of "Realm-Routed" Overload report type

 I'm assuming the name of the realm overload report in the -01 version will
 be changed to realm-routed.  This issue applies independent of the actual
 name of the report.

 The current behavior assumed for the realm-routed report is that the
 reacting node, generally the client, will reduce the percentage of realm
 routed requests sent to the reporting node.

 This is actually bad behavior and could result in the client throttling
 traffic that could have been handled by the full set of servers for that
 Diameter application.
[MCruz] This can only happen if the agent has miscalculated the realm overload.

 Consider the case where there are n servers for a Diameter application and
 all of those server are able to handle any transaction for that
 application.

 When one of those servers becomes overloaded and wishes to decrease the
 number of new sessions, the primary use of realm-routed requests.  The
 server will generate an OLR of type realm-routed.
[MCruz] I do not agree. Servers do not generate Realm-routed reports.

 Assume in this case that the other servers are all healthy and able to
 handle new sessions.

 Clients will not have the knowledge that there are other servers in the
 network able to handle the new session and will have no choice but the
 throttle a percentage of the new session requests.  Even when these
 throttled requests could have been handled by any of the non overloaded
 servers.

 The proposal is to specify that realm-routed reports must be handled by
 DOIC-supporting agents.  Agents will understand if there are other servers
 able to handle the new session and, if so, can adjust the percentage of
 requests routed to the overloaded server.

 Agents that handle the realm-routed OLR must remove the request from the
 answer before relaying the answer to client.  This prevents the report
 from being acted on by either multiple agents (if multiple are in the
 path) or by an agent and a client.

 Clients that receive the realm-routed OLR must handle the OLR by
 throttling the requested percentage.



    

    

  


--------------010704000006070100020004--


From nobody Mon Feb 24 11:39:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80F41A00D7 for ; Mon, 24 Feb 2014 11:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umBi3eK5RQnw for ; Mon, 24 Feb 2014 11:39:33 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1401A018C for ; Mon, 24 Feb 2014 11:39:33 -0800 (PST)
Received: from [137.254.4.54] (port=23828 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI1NB-0002gE-PQ for dime@ietf.org; Mon, 24 Feb 2014 11:39:31 -0800
Message-ID: <530B9FF4.4070108@usdonovans.com>
Date: Mon, 24 Feb 2014 13:39:32 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------020605070600010705030103"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hOAS41fPGIu5ArxqXEP09ftTqkY
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 19:39:35 -0000

This is a multi-part message in MIME format.
--------------020605070600010705030103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the
ability to have a realm report that control the total amount of traffic
sent to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the
resolution of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is
indicated by the origin-host AVP in the answer message carrying the
report.  Can be generated by a server or by an agent acting as a
front-end to a group of servers.

- Realm-routed-request report - Applies to all requests sent to a realm
without a destination-host AVP in the request message.  Can be generated
by a server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent
of the presence or absence of a destination-host AVP in the request
message.  Can be generated by a server or an agent.  The method for
determining the realm state is out of scope for the DOIC document.

Steve

On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
>
> Hello,
>
>  
>
> I do not think we have agreed so far on the need to have two different
> reports (so called realm-routed and just realm).
>
> Regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 18:44
> *To:* dime@ietf.org
> *Subject:* [Dime] Issue #23 Proposed resolution
>
>  
>
> I propose the following resolution for issue 23:
>
>
> Proposal -- Change the name of realm report.  
>
>
> Proposed name - "Realm-Routed-Request" report.
>
>
> Proposal -- Update all discussion on "Realm-Routed-Request" reports to
> indicate that they apply only to requests targeted to a realm when
> there is no destination-host AVP in the request.  Specifically,
> section 4.6 requires updating.
>
> There is also a proposal to add a new report type to handle all
> transactions to a realm.  This is addressed by ticket number 55.
>
> Regards,
>
> Steve
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------020605070600010705030103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      I thought you had asserted that there was a 3GPP requirement to
      have the ability to have a realm report that control the total
      amount of traffic sent to a realm.  There is certainly an IETF DOC
      requirement to this effect.

      

      The proposal is to have three report types (or four depending on
      the resolution of the per client host report discussion).

      

      - Host report - Apply to all requests sent to a host.  The host is
      indicated by the origin-host AVP in the answer message carrying
      the report.  Can be generated by a server or by an agent acting as
      a front-end to a group of servers.

      

      - Realm-routed-request report - Applies to all requests sent to a
      realm without a destination-host AVP in the request message.  Can
      be generated by a server or by an agent acting as a front-end to a
      group of servers.

      

      - Realm report - Applies to all requests sent to the realm,
      independent of the presence or absence of a destination-host AVP
      in the request message.  Can be generated by a server or an
      agent.  The method for determining the realm state is out of scope
      for the DOIC document.

      

      Steve

      

    
    
On 2/24/14 1:12 PM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello,

        
 

        
I do not think we
            have agreed so far on the need to have two different reports
            (so called realm-routed and just realm).

        
Regards

        
/MCruz

        
 

        

          

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

                Sent: lunes, 24 de febrero de 2014 18:44

                To: dime@ietf.org

                Subject: [Dime] Issue #23 Proposed resolution

          

        

        
 

        
I propose the following resolution for
          issue 23:

          

          

          

        
Proposal
          – Change the name of realm report.  

        


          Proposed name - “Realm-Routed-Request” report.

        


            Proposal – Update all discussion on “Realm-Routed-Request”
            reports to indicate that they apply only to requests
            targeted to a realm when there is no destination-host AVP in
            the request.  Specifically, section 4.6 requires updating.

            

            There is also a proposal to add a new report type to handle
            all transactions to a realm.  This is addressed by ticket
            number 55.

            

            Regards,

            

            Steve 

      

      

      

      

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


    

    

  


--------------020605070600010705030103--


From nobody Mon Feb 24 11:52:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB4B1A0198 for ; Mon, 24 Feb 2014 11:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8iWJC_gSpmH for ; Mon, 24 Feb 2014 11:52:54 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9BE1A0184 for ; Mon, 24 Feb 2014 11:52:54 -0800 (PST)
Received: from [137.254.4.54] (port=43768 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI1a1-0002fl-2t for dime@ietf.org; Mon, 24 Feb 2014 11:52:53 -0800
Message-ID: <530BA310.4090100@usdonovans.com>
Date: Mon, 24 Feb 2014 13:52:48 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net> <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com>
In-Reply-To: <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com>
Content-Type: multipart/alternative; boundary="------------000603090607090706070500"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1hb2xf7veSdoRkIwnXCfS4VerVE
Subject: Re: [Dime] Issue#29 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 19:52:55 -0000

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

I agree.

I also think that we agreed that the lifetime of the
OC-Supported-Features AVP is a single transaction and that the
OC-Supported-Features AVP must be included in all requests originated by
a Diameter node supporting DOIC.

Steve

On 2/20/14 4:31 PM, Ben Campbell wrote:
> I concur with removing the sequence number from OC-Supported-Features.
>
> On Feb 19, 2014, at 2:44 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>
>> #29: OC-Sequence-Number in OC-Supported-Features
>>  
>> Dear all,
>>  
>> I have received comments from Lionel, Jouni and Steve;
>> I understand that Lionel and myself support removal of OC-Sequence-Number AVP from OC-Supported-Features AVP while Jouni has no strong view.  I’m not sure whether Steve is convinced by the response given to his comments.
>>  
>> In summary I dare to propose that we conclude in favour of removing OC-Sequence-Number from OC-Supported-Features.
>>  
>> Ulrich
>>  
>> _______________________________________________
>> 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
>


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


  
    
  
  
    I agree.

      

      I also think that we agreed that the lifetime of the
      OC-Supported-Features AVP is a single transaction and that the
      OC-Supported-Features AVP must be included in all requests
      originated by a Diameter node supporting DOIC.

      

      Steve

      

    
    
On 2/20/14 4:31 PM, Ben Campbell wrote:

    

    

      
I concur with removing the sequence number from OC-Supported-Features.

On Feb 19, 2014, at 2:44 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:



      

        
#29: OC-Sequence-Number in OC-Supported-Features
 
Dear all,
 
I have received comments from Lionel, Jouni and Steve;
I understand that Lionel and myself support removal of OC-Sequence-Number AVP from OC-Supported-Features AVP while Jouni has no strong view.  I’m not sure whether Steve is convinced by the response given to his comments.
 
In summary I dare to propose that we conclude in favour of removing OC-Sequence-Number from OC-Supported-Features.
 
Ulrich
 
_______________________________________________
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



    

    

  


--------------000603090607090706070500--


From nobody Mon Feb 24 12:12:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2A61A02BF for ; Mon, 24 Feb 2014 12:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGnZdbwGjTvi for ; Mon, 24 Feb 2014 12:12:39 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E0AC31A020C for ; Mon, 24 Feb 2014 12:12:39 -0800 (PST)
Received: from [137.254.4.54] (port=11134 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI1tD-0003x9-OG for dime@ietf.org; Mon, 24 Feb 2014 12:12:38 -0800
Message-ID: <530BA7B6.9020405@usdonovans.com>
Date: Mon, 24 Feb 2014 14:12:38 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------020304000608050906080607"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gVS1zDLJyTp0FyNU08Gp9cnWmO8
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 20:12:41 -0000

This is a multi-part message in MIME format.
--------------020304000608050906080607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I can see two additional reasons for requiring OC-Supported-Features:

1) If the reacting node needs to know in advance whether the type of
overload abatement the reporting node will ask for.

this is not needed in the case of the loss abatement algorithm as the
reacting node can just immediately start throttling the appropriate
number of requests.  It does not require prior knowledge of the traffic
sent.

There are abatement algorithms that do require the client to keep state
about traffic sent to specific destinations.  We can, if we choose,
leave it up to the drafts associated with the new abatement algorithms
to specify the requirement to include OC-Supported-Features, as proposed
by Ulrich.

2) If the reacting node can use the absence of the OC-Supported-Features
AVP in answer messages to know that there is no Diameter overload
supported in the network and thus take other measures to protect the
Diameter network.  For example, I can envision a client implementation
that adapts to the knowledge of whether servers support overload.  In
the case that the server does support overload the client can send
unlimited traffic to the server, up to the point that the server sends
an OLR.  If the client determines that the server does not support
overload then it might have a configured maximum rate that it will send
to the server.

My inclination is to include the OC-Supported-Features AVP in answers
because most abatement algorithms will need it and because it can lead
to better implementation client implementations.

Steve

On 2/19/14 6:37 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Hi Jouni,
>
> thank you for your reply, and sorry for not having correctly summarized the status with regard to dependencies between OC-OLR AVP and OC-Supported-Features AVP in an answer message.
>
> I would like to further discuss this aspect.
> My understanding is: as long as only OLR_DEFAULT_ALGO (0x0000000000000001) is supported, there is no such dependency.
> Furthermore: even with the introduction of Rate-control in draft-donovan-dime-doc-rate-control-00, no such dependency is introduced. 
> An OLR is a loss-type OLR when it contains a Reduction-Percentage and it's a rate-type OLR when it contains an OC-Maximum-Rate AVP (see draft-donovan-dime-doc-rate-control-00 clause 4.1).
>
> A future extension may introduce such dependency (although I don't think it's a good idea) e.g. by saying that an OLR is a new-feature-type OLR when the OC-Supported-Features AVP in the same answer message indicates support of new-feature, and a loss-type OLR otherwise; however this is subject to be specified in the extension spec, not in draft-ietf-dime-ovli.
>
> Summary: currently no dependency; currently dependency is no reason to have OC-Supported-Feature in anwers; new feature may introduce the dependency and consequently introduce OC-Supported-Feature in answer.
>
> Ulrich
>
>
>
>
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: Wednesday, February 19, 2014 11:25 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>
>
> On Feb 19, 2014, at 11:57 AM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> #30: OC-Supported-Features AVP in answer messages
>>  
>> Dear all,
>>  
>> It may be too early to finaly conclude on this one.
>>  
>> It seems we have consensus in the following: Absence of Supported-Features-AVP from an answer message MUST not result in reacting nodes to cease sending of any DOIC related AVPs in subsequent requests.
> This is OK.
>
>>  
>> It is still open whether we can remove OC-Supported-Features from answer messages. However we seem to agree that the meaning of OC-OLR AVP is not dependent from any OC-Supported-Features AVP within the same answer.
> I do not agree that the OC-OLR meaning is not dependant on the OC-Supported-Features in the answer.
>
>> The open question seems to be whether it is required for reacting nodes to do different throttlings based on implicit signals towards a) non-supporting destinations  and b) supporting but not traffic-reduction-requesting destinations. If required it seems also be clear that an additional indication is needed to indicate whether the OC-Supported-Feature AVP was inserted by the server (host) or by an agent (realm).
> Right.
>
>
> - Jouni
>
>>  
>> Ulrich
>>  
>> _______________________________________________
>> 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
>


--------------020304000608050906080607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I can see two additional
      reasons for requiring OC-Supported-Features:

      

      1) If the reacting node needs to know in advance whether the type
      of overload abatement the reporting node will ask for.

      

      this is not needed in the case of the loss abatement algorithm as
      the reacting node can just immediately start throttling the appropriate
      number of requests.  It does not require prior knowledge of the
      traffic sent.

      

      There are abatement algorithms that do require the client to keep
      state about traffic sent to specific destinations.  We can, if we
      choose, leave it up to the drafts associated with the new
      abatement algorithms to specify the requirement to include
      OC-Supported-Features, as proposed by Ulrich.

      

      2) If the reacting node can use the absence of the
      OC-Supported-Features AVP in answer messages to know that there is
      no Diameter overload supported in the network and thus take other
      measures to protect the Diameter network.  For example, I can
      envision a client implementation that adapts to the knowledge of
      whether servers support overload.  In the case that the server
      does support overload the client can send unlimited traffic to the
      server, up to the point that the server sends an OLR.  If the
      client determines that the server does not support overload then
      it might have a configured maximum rate that it will send to the
      server.

      

      My inclination is to include the OC-Supported-Features AVP in
      answers because most abatement algorithms will need it and because
      it can lead to better implementation client implementations.

      

      Steve

      

    
    
On 2/19/14 6:37 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Hi Jouni,

thank you for your reply, and sorry for not having correctly summarized the status with regard to dependencies between OC-OLR AVP and OC-Supported-Features AVP in an answer message.

I would like to further discuss this aspect.
My understanding is: as long as only OLR_DEFAULT_ALGO (0x0000000000000001) is supported, there is no such dependency.
Furthermore: even with the introduction of Rate-control in draft-donovan-dime-doc-rate-control-00, no such dependency is introduced. 
An OLR is a loss-type OLR when it contains a Reduction-Percentage and it's a rate-type OLR when it contains an OC-Maximum-Rate AVP (see draft-donovan-dime-doc-rate-control-00 clause 4.1).

A future extension may introduce such dependency (although I don't think it's a good idea) e.g. by saying that an OLR is a new-feature-type OLR when the OC-Supported-Features AVP in the same answer message indicates support of new-feature, and a loss-type OLR otherwise; however this is subject to be specified in the extension spec, not in draft-ietf-dime-ovli.

Summary: currently no dependency; currently dependency is no reason to have OC-Supported-Feature in anwers; new feature may introduce the dependency and consequently introduce OC-Supported-Feature in answer.

Ulrich





-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Wednesday, February 19, 2014 11:25 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Feb 19, 2014, at 11:57 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



      

        
#30: OC-Supported-Features AVP in answer messages
 
Dear all,
 
It may be too early to finaly conclude on this one.
 
It seems we have consensus in the following: Absence of Supported-Features-AVP from an answer message MUST not result in reacting nodes to cease sending of any DOIC related AVPs in subsequent requests.


      

      
This is OK.



      

        
 
It is still open whether we can remove OC-Supported-Features from answer messages. However we seem to agree that the meaning of OC-OLR AVP is not dependent from any OC-Supported-Features AVP within the same answer.


      

      
I do not agree that the OC-OLR meaning is not dependant on the OC-Supported-Features in the answer.



      

        
The open question seems to be whether it is required for reacting nodes to do different throttlings based on implicit signals towards a) non-supporting destinations  and b) supporting but not traffic-reduction-requesting destinations. If required it seems also be clear that an additional indication is needed to indicate whether the OC-Supported-Feature AVP was inserted by the server (host) or by an agent (realm).


      

      
Right.


- Jouni



      

        
 
Ulrich
 
_______________________________________________
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



    

    

  


--------------020304000608050906080607--


From nobody Mon Feb 24 12:29:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDA21A02CA for ; Mon, 24 Feb 2014 12:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.115
X-Spam-Level: 
X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EyaaQYLKMN9 for ; Mon, 24 Feb 2014 12:29:05 -0800 (PST)
Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) by ietfa.amsl.com (Postfix) with ESMTP id 407171A0262 for ; Mon, 24 Feb 2014 12:29:05 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1OKSwPx048058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 14:29:00 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530B9E01.3050506@usdonovans.com>
Date: Mon, 24 Feb 2014 14:28:57 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3VsBhuPoRsSOMT4rj7-i-N1ND5U
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 20:29:08 -0000

On Feb 24, 2014, at 1:31 PM, Steve Donovan  =
wrote:

> Maria Cruz,
>=20
> Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to =
try to make Ulrich happy :-) ).
>=20
> My definition is that it is a report generated by the server when the =
server does not want to receive new sessions. =20
>=20
> Your definition appears to be that it is a report generated by an =
agent (or a server is there are no agents in the network?) to indicate =
that the network need to handle fewer new sessions.
>=20
> I actually think both cases apply but I don't think that an agent can =
generate a realm-routed-request report without knowing the status of =
servers and their ability to handle new Diameter sessions.
>=20

The version I had in mind from way back could be sent by either, but =
would apply to all realm-routed requests for the _realm_, regardless of =
which server would finally get it. This is easy enough if the agent =
generates it. It's harder if a server generates it, since that server =
would need full knowledge of the realm. But we should not forbid that =
possibility.

To my knowledge, we have not defined a way for a server to say "reduce =
new session requests to _me_, but let other servers speak for =
themselves." That would require either a new report type, or an AVP to =
indicate the special treatment (which, btw, would start to approach the =
idea of "scopes" ;-) )



> Note that I'm discussing this in the context of session-based =
applications.  This could also be applied to pseudo session based =
applications and applications that always rely on realm routed requests.
>=20

I agree, but will go further to say it applies to any realm-routed =
requests (that is, requests with no Destination-Host AVP present) for =
the associated application, but in an application-independent way.  Or =
more to the point, the set of [session-oriented applications, =
pseudo-session oriented applications, non-session oriented applications] =
is the same as the set of [applications].

> Everyone, which definition applies?
>=20
> Steve
>=20
> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>> Steve,
>>=20
>> See some comments below please.
>> /MCruz
>>=20
>> -----Original Message-----
>> From: DiME [
>> mailto:dime-bounces@ietf.org
>> ] On Behalf Of dime issue tracker
>> Sent: lunes, 24 de febrero de 2014 17:20
>> To:=20
>> draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
>>=20
>> Cc:=20
>> dime@ietf.org
>>=20
>> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>>=20
>> #57: Handling of "Realm-Routed" Overload report type
>>=20
>>  I'm assuming the name of the realm overload report in the -01 =
version will
>>  be changed to realm-routed.  This issue applies independent of the =
actual
>>  name of the report.
>>=20
>>  The current behavior assumed for the realm-routed report is that the
>>  reacting node, generally the client, will reduce the percentage of =
realm
>>  routed requests sent to the reporting node.
>>=20
>>  This is actually bad behavior and could result in the client =
throttling
>>  traffic that could have been handled by the full set of servers for =
that
>>  Diameter application.
>> [MCruz] This can only happen if the agent has miscalculated the realm =
overload.
>>=20
>>  Consider the case where there are n servers for a Diameter =
application and
>>  all of those server are able to handle any transaction for that
>>  application.
>>=20
>>  When one of those servers becomes overloaded and wishes to decrease =
the
>>  number of new sessions, the primary use of realm-routed requests.  =
The
>>  server will generate an OLR of type realm-routed.
>> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>>=20
>>  Assume in this case that the other servers are all healthy and able =
to
>>  handle new sessions.
>>=20
>>  Clients will not have the knowledge that there are other servers in =
the
>>  network able to handle the new session and will have no choice but =
the
>>  throttle a percentage of the new session requests.  Even when these
>>  throttled requests could have been handled by any of the non =
overloaded
>>  servers.
>>=20
>>  The proposal is to specify that realm-routed reports must be handled =
by
>>  DOIC-supporting agents.  Agents will understand if there are other =
servers
>>  able to handle the new session and, if so, can adjust the percentage =
of
>>  requests routed to the overloaded server.
>>=20
>>  Agents that handle the realm-routed OLR must remove the request from =
the
>>  answer before relaying the answer to client.  This prevents the =
report
>>  from being acted on by either multiple agents (if multiple are in =
the
>>  path) or by an agent and a client.
>>=20
>>  Clients that receive the realm-routed OLR must handle the OLR by
>>  throttling the requested percentage.
>>=20
>>=20
>=20


From nobody Mon Feb 24 12:33:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9D1A02D7 for ; Mon, 24 Feb 2014 12:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8weDjLqRxCzM for ; Mon, 24 Feb 2014 12:32:59 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id B88C61A0202 for ; Mon, 24 Feb 2014 12:32:59 -0800 (PST)
Received: from [137.254.4.54] (port=43720 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI2Cv-0002m8-L7 for dime@ietf.org; Mon, 24 Feb 2014 12:32:58 -0800
Message-ID: <530BAC7C.7080106@usdonovans.com>
Date: Mon, 24 Feb 2014 14:33:00 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060004020006010905050109"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vbtiPH_srCkJCTuyKy2XuKoPS9A
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 20:33:01 -0000

This is a multi-part message in MIME format.
--------------060004020006010905050109
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Would you agree to the following to replace the first two statements:

Sequence number is of type Unsigned64.

When generated, a new sequence number must be greater than the sequence
number contained in the active overload report to which it applies
(including over reboot of that node).  Note: this allows sequence
numbers to start at 1 for any occurrence of overload at a reporting
node.  This, I think, allows us to ignore wraparound issues as
wraparound will never happen.  Unless we are worried about a server
staying in overload for billions of years (assuming reports with a ten
minute validity period refreshed every five minutes).

The other two statements are good.

Steve

On 2/19/14 9:33 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> #32: Sequence-Number Time-Stamp values within OC-OLR
>  
> I understand that we agreed the following principles:
>  
> Sequence-Number is of type Time, however the value need not correspond
> to the point in time of generation.
>  
> When generated, a new sequence number must be  greater than any
> sequence number previously generated by the same node (including over
> a reboot of that node)
>  
> When received, a sequence number is used to detect
> outdates/replays/freshness.
>  
> Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.
>  
>  
> I did not understand the requirement for globally uniqueness as
> introduced by Jouni.
> Can Jouni please explain.
>  
> Ulrich
>  
>  
>  
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------060004020006010905050109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Would you agree to the following to replace the first two
      statements:

      

      Sequence number is of type Unsigned64.

      

      When generated, a new sequence number must be greater than the
      sequence number contained in the active overload report to which
      it applies (including over reboot of that node).  Note: this
      allows sequence numbers to start at 1 for any occurrence of
      overload at a reporting node.  This, I think, allows us to ignore
      wraparound issues as wraparound will never happen.  Unless we are
      worried about a server staying in overload for billions of years
      (assuming reports with a ten minute validity period refreshed
      every five minutes).

      

      The other two statements are good.

      

      Steve

      

    
    
On 2/19/14 9:33 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      
      
          
#32: Sequence-Number Time-Stamp values within OC-OLR

          
 

          
I understand that we agreed the following principles:

          
 

          
Sequence-Number is of type Time, however the value need
            not correspond to the point in time of generation.

          
 

          
When generated, a new sequence number must be  greater
            than any sequence number previously generated by the same
            node (including over a reboot of that node)

          
 

          
When received, a sequence number is used to detect
            outdates/replays/freshness.

          
 

          
Sequence numbers of expired OLRs MUST NOT be remembered
            by reacting nodes.

          
 

          
 

          
I did not understand the requirement for globally
            uniqueness as introduced by Jouni.

          
Can Jouni please explain.

          
 

          
Ulrich

          
 

          
 

          
 

        
      

      

      

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


    

    

  


--------------060004020006010905050109--


From nobody Mon Feb 24 12:47:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80FA1A0233 for ; Mon, 24 Feb 2014 12:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzvwwY8gbjNY for ; Mon, 24 Feb 2014 12:46:55 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9534F1A01BE for ; Mon, 24 Feb 2014 12:46:55 -0800 (PST)
Received: from [137.254.4.54] (port=62862 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI2QL-0002h5-Rv for dime@ietf.org; Mon, 24 Feb 2014 12:46:54 -0800
Message-ID: <530BAFBC.80101@usdonovans.com>
Date: Mon, 24 Feb 2014 14:46:52 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F31@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F31@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------000309090004050306090603"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Z_cA34PphvDcd8Diq_74oAxE13U
Subject: Re: [Dime] Issue#34 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 20:46:57 -0000

This is a multi-part message in MIME format.
--------------000309090004050306090603
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

+1
On 2/20/14 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> #34: Semantics of OC-Report-Type AVP
>  
> Dear all,
>  
> Apart from potentially renaming "realm report" to something else (I
> don't like "realm routed report" as its not the report that is
> realm-routed) I believe we finally agreed to accept the text as
> proposed in ticket#34 and replace the corresponding text from clause 4.6.
>  
> Ulrich
>  
>  
>  
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------000309090004050306090603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    
On 2/20/14 6:21 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      
      
          
#34: Semantics of OC-Report-Type AVP

          
 

          
Dear all,

          
 

          
Apart from potentially renaming “realm report” to
            something else (I don’t like “realm routed report” as its
            not the report that is realm-routed) I believe we finally
            agreed to accept the text as proposed in ticket#34 and
            replace the corresponding text
            from clause 4.6.

          
 

          
Ulrich

          
 

          
 

          
 

        
      

      

      

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


    

    

  


--------------000309090004050306090603--


From nobody Mon Feb 24 13:08:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98F31A01C9 for ; Mon, 24 Feb 2014 13:08:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ9OMG-VJqO7 for ; Mon, 24 Feb 2014 13:08:54 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD9F1A0193 for ; Mon, 24 Feb 2014 13:08:53 -0800 (PST)
Received: from [137.254.4.54] (port=31247 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI2le-0004ui-UM; Mon, 24 Feb 2014 13:08:51 -0800
Message-ID: <530BB4E5.7010301@usdonovans.com>
Date: Mon, 24 Feb 2014 15:08:53 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Jouni Korhonen , dime@ietf.org
References: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> <213D2B01-4A4F-4C06-9272-B93D98F629BC@gmail.com>
In-Reply-To: <213D2B01-4A4F-4C06-9272-B93D98F629BC@gmail.com>
Content-Type: multipart/alternative; boundary="------------010107060201070401060203"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xAezrKl2EKBcHBgx1lvx-y0PJ88
Cc: ben@nostrum.com
Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 21:08:55 -0000

This is a multi-part message in MIME format.
--------------010107060201070401060203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I believe that we agreed to remove the discussion and definition of
server farms when discussion issue #24.  If we still agree on that then
this issue goes away.

Steve

On 2/10/14 4:53 AM, Jouni Korhonen wrote:
> Good point. I would clarify that a server farm could mean both: one with
> a single identity and one with multiple identities. The selection is 
> implementation and deployment specific.
>
> - Jouni
>
>
> On Feb 7, 2014, at 10:37 PM, dime issue tracker  wrote:
>
>> #38: Server Farm Definition Issue
>>
>> A "server farm" is defined as "A set of Diameter servers that can handle
>> any request for a given set of Diameter applications.". This is not
>> strictly true. For example, if a request includes a Destination-Server
>> AVP, then then in general only that particular server in the farm can
>> handle the request.
>>
>> I assume that we don't mean to limit the server farm concept to situations
>> where the entire farm is known by a single Diameter-Identity, do we?
>>
>> -- 
>> -------------------------+-------------------------------------------------
>> Reporter:               |      Owner:  draft-docdt-dime-
>>  ben@nostrum.com        |  ovli@tools.ietf.org
>>     Type:  defect       |     Status:  new
>> Priority:  minor        |  Milestone:
>> Component:  draft-       |    Version:  1.0
>>  docdt-dime-ovli        |   Keywords:
>> Severity:  Active WG    |
>>  Document               |
>> -------------------------+-------------------------------------------------
>>
>> Ticket URL: 
>> dime 
>>
>


--------------010107060201070401060203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I believe that we agreed
      to remove the discussion and definition of server farms when
      discussion issue #24.  If we still agree on that then this issue
      goes away.

      

      Steve

      

    
    
On 2/10/14 4:53 AM, Jouni Korhonen
      wrote:

    

    

      
Good point. I would clarify that a server farm could mean both: one with
a single identity and one with multiple identities. The selection is 
implementation and deployment specific.

- Jouni


On Feb 7, 2014, at 10:37 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wrote:



      

        
#38: Server Farm Definition Issue

A "server farm" is defined as "A set of Diameter servers that can handle
any request for a given set of Diameter applications.". This is not
strictly true. For example, if a request includes a Destination-Server
AVP, then then in general only that particular server in the farm can
handle the request.

I assume that we don't mean to limit the server farm concept to situations
where the entire farm is known by a single Diameter-Identity, do we?

-- 
-------------------------+-------------------------------------------------
Reporter:               |      Owner:  draft-docdt-dime-
 ben@nostrum.com        |  ovli@tools.ietf.org
    Type:  defect       |     Status:  new
Priority:  minor        |  Milestone:
Component:  draft-       |    Version:  1.0
 docdt-dime-ovli        |   Keywords:
Severity:  Active WG    |
 Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/38>
dime <http://tools.ietf.org/wg/dime/>



      

      



    

    

  


--------------010107060201070401060203--


From nobody Mon Feb 24 13:24:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315051A02CD for ; Mon, 24 Feb 2014 13:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xylstIxkH403 for ; Mon, 24 Feb 2014 13:24:21 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 622711A0193 for ; Mon, 24 Feb 2014 13:24:21 -0800 (PST)
Received: from [137.254.4.54] (port=49225 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI30S-0008J9-25; Mon, 24 Feb 2014 13:24:17 -0800
Message-ID: <530BB87A.2000807@usdonovans.com>
Date: Mon, 24 Feb 2014 15:24:10 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: lionel.morand@orange.com, "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" ,  "ben@nostrum.com" 
References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> <10919_1391878439_52F66127_10919_17464_1_6B7134B31289DC4FAF731D844122B36E4938F4@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <10919_1391878439_52F66127_10919_17464_1_6B7134B31289DC4FAF731D844122B36E4938F4@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------040900010907050402080101"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/z3w4qU8lYQTeW-icHBbt07V9w9Q
Subject: Re: [Dime] [dime] #44: Incorrect sequence number behavior
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 21:24:23 -0000

This is a multi-part message in MIME format.
--------------040900010907050402080101
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Lionel,

I believe that Ben's issue was with the following wording in section 4.3

   The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.
   It is possible to replay the same OC-OLR AVP multiple times between
   the overload control endpoints, however, when the OC-OLR AVP content
   changes or sending endpoint otherwise wants the receiving endpoint to
   update its overload control information, then the OC-Sequence-Number
   AVP MUST contain a new greater value than the previously received.
   The receiver SHOULD discard an OC-OLR AVP with a sequence number that
   is less than previously received one.


The wording you reference is in section 5.5.2.

The above wording can be improved by changing the last sentence to "The
reacting node SHOULD discard an OC-OLR AVP with a sequence number that
is less than or equal to the previously received sequence number."

Steve

On 2/8/14 10:53 AM, lionel.morand@orange.com wrote:
> Hi Ben,
>
> The case "equal" is discussed in the previous sentence.
>
> Check the following:
>
>    The received OC-Supported-Features AVP does not change the existing
>    overload condition and/or traffic abatement algorithm settings if the
>    OC-Sequence-Number AVP contains a value that is equal to the
>    previously received/recorded one.  If the OC-Supported-Features AVP
>    is received for the first time for the reporting node or the OC-
>    Sequence-Number AVP value is less than the previously received/
>    recorded one (and is outside the valid overflow window), then either
>    the sequence number is stale (e.g. an intentional or unintentional
>    replay) and SHOULD be silently discarded.
>
> The first sentence implies that the received OLR is ignored. 
>
> And actually, there is something wrong in the last sentence. At the end, 
>
>    recorded one (and is outside the valid overflow window), then either
>    the sequence number is stale or replay (e.g. an intentional or unintentional
>    replay) and SHOULD be silently discarded.
>
> The "either" in the first line should be removed.
>
> Regards,
>
> Lionel
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
> Envoyé : vendredi 7 février 2014 22:49
> À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
> Cc : dime@ietf.org
> Objet : [Dime] [dime] #44: Incorrect sequence number behavior
>
> #44: Incorrect sequence number behavior
>
>  section 4.3 says that the receiver should discard an OLR with a sequence
>  number less than the most recent. That should be less than or equal.
>  Technically, re-applying the same OLR should make no difference, but it's
>  never needed, and could be error prone if the sender screwed something up.
>


--------------040900010907050402080101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Lionel,

      

      I believe that Ben's issue was with the following wording in
      section 4.3 

    

    
      
    
    
   The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.
   It is possible to replay the same OC-OLR AVP multiple times between
   the overload control endpoints, however, when the OC-OLR AVP content
   changes or sending endpoint otherwise wants the receiving endpoint to
   update its overload control information, then the OC-Sequence-Number
   AVP MUST contain a new greater value than the previously received.
   The receiver SHOULD discard an OC-OLR AVP with a sequence number that
   is less than previously received one.

    

      The wording you reference is in section 5.5.2.

      

      The above wording can be improved by changing the last sentence to
      "The reacting node SHOULD discard an OC-OLR AVP with a sequence
      number that is less than or equal to the previously received
      sequence number."

      

      Steve

    

    
      
    On 2/8/14 10:53 AM, lionel.morand@orange.com wrote:

    

      
Hi Ben,

The case "equal" is discussed in the previous sentence.

Check the following:

   The received OC-Supported-Features AVP does not change the existing
   overload condition and/or traffic abatement algorithm settings if the
   OC-Sequence-Number AVP contains a value that is equal to the
   previously received/recorded one.  If the OC-Supported-Features AVP
   is received for the first time for the reporting node or the OC-
   Sequence-Number AVP value is less than the previously received/
   recorded one (and is outside the valid overflow window), then either
   the sequence number is stale (e.g. an intentional or unintentional
   replay) and SHOULD be silently discarded.

The first sentence implies that the received OLR is ignored. 

And actually, there is something wrong in the last sentence. At the end, 

   recorded one (and is outside the valid overflow window), then either
   the sequence number is stale or replay (e.g. an intentional or unintentional
   replay) and SHOULD be silently discarded.

The "either" in the first line should be removed.

Regards,

Lionel


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : vendredi 7 février 2014 22:49
À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Cc : dime@ietf.org
Objet : [Dime] [dime] #44: Incorrect sequence number behavior

#44: Incorrect sequence number behavior

 section 4.3 says that the receiver should discard an OLR with a sequence
 number less than the most recent. That should be less than or equal.
 Technically, re-applying the same OLR should make no difference, but it's
 never needed, and could be error prone if the sender screwed something up.



    

    

  


--------------040900010907050402080101--


From nobody Mon Feb 24 13:31:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F321A026A for ; Mon, 24 Feb 2014 13:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.115
X-Spam-Level: 
X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb2XJnWQhMrt for ; Mon, 24 Feb 2014 13:31:43 -0800 (PST)
Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2828D1A0193 for ; Mon, 24 Feb 2014 13:31:42 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1OLVRuJ059787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 15:31:29 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530BB4E5.7010301@usdonovans.com>
Date: Mon, 24 Feb 2014 15:31:26 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> <213D2B01-4A4F-4C06-9272-B93D98F629BC@gmail.com> <530BB4E5.7010301@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/y6UJXOttTgQV2l8hIKIe9PETYcI
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 21:31:45 -0000

On Feb 24, 2014, at 3:08 PM, Steve Donovan  =
wrote:

> I believe that we agreed to remove the discussion and definition of =
server farms when discussion issue #24.  If we still agree on that then =
this issue goes away.
>=20

+1


From nobody Mon Feb 24 13:33:16 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F911A0298 for ; Mon, 24 Feb 2014 13:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSr52eyfCso9 for ; Mon, 24 Feb 2014 13:33:11 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id A07D51A026D for ; Mon, 24 Feb 2014 13:33:11 -0800 (PST)
Received: from [137.254.4.54] (port=59052 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI39B-0002fq-KV for dime@ietf.org; Mon, 24 Feb 2014 13:33:10 -0800
Message-ID: <530BBA98.9080903@usdonovans.com>
Date: Mon, 24 Feb 2014 15:33:12 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com>  <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <579DC2BE-CC3C-43E6-819C-ADB7B1182CED@nostrum.com>
In-Reply-To: <579DC2BE-CC3C-43E6-819C-ADB7B1182CED@nostrum.com>
Content-Type: multipart/alternative; boundary="------------090508020701010204040803"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VE8a3WmhQQlTrhU7CML6jCCDE84
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 21:33:13 -0000

This is a multi-part message in MIME format.
--------------090508020701010204040803
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I think the proposal here is the following:

A reporting node communicates that an overload report is no longer valid
by sending an OLR with a Validity-Period AVP with a value of zero.  This
is the only way for a reporting node to indicate that an overload report
is no longer valid.  For instance, setting the reduction-percentage to
zero does not make the overload report invalid. 

Do we have agreement on this?

Steve

On 2/17/14 12:44 PM, Ben Campbell wrote:
> On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com wrote:
>
>> I would like to highlight that my proposal is not related to the default Reduction-percentage algo.
>>
>> Whatever the ago used, I think that an OLR can only be sent for two purposes:
>> - Send an indication of overload situation
>> - Send an indication of end of the overload situation
>>
>> For me, providing both indications in the same message would be a non-sense. And I don't understand why the validity period would prevail in that case.
> So here's the question: Let's assume a reporting node sends you an OLR using the "loss" algorithm, a reduction-percentage of 50%, and a Validity-Duration of 10 minutes. 5 minutes later, it sends you a new OLR with an invalid reduction percentage and a Validity-Duration of 0.
>
> What's the current overload state?
>
> What if the second OLR used the "rate" algorithm, with a valid value, but still had a validity duration of 0. Does that change anything?
>
> I am arguing that, in both cases, the second OLR ends the overload period.
>
> I'm actually okay if we have a normative statement to the effect that the reporting node MUST NOT send an invalid reduction percentage, and that a reacting node MUST ignore an OLR with an invalid value _except_ for the case of a validity-duration set to zero.
>
> This all comes down to how much guessing we are willing to do about the intent of the sender when one receives an invalid OLR. I think it's reasonable to guess that a zero validity duration means to end an overload condition, without regard to the rest of the message. I _don't_ think it's reasonable to try to guess what the sender meant with an invalid reduction percentage, when the validity period is non-zero.
>
> Another, perhaps simpler, approach would be to assert that the reception of _any_ invalid OLR automatically ends any existing overload condition. (I'm not necessarily arguing for that--it's just something to think about.)
>
>> Now, if what is argued by Ben and supported by JJ and Steve is clear for the rest of the group, I will not fight.
> ... but the fighting is the fun part :-)
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------090508020701010204040803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I think the proposal here
      is the following:

      

      A reporting node communicates that an overload report is no longer
      valid by sending an OLR with a Validity-Period AVP with a value of
      zero.  This is the only way for a reporting node to indicate that
      an overload report is no longer valid.  For instance, setting the
      reduction-percentage to zero does not make the overload report
      invalid.  

      

      Do we have agreement on this?

      

      Steve

      

    
    
On 2/17/14 12:44 PM, Ben Campbell
      wrote:

    

    

      
On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com wrote:



      

        
I would like to highlight that my proposal is not related to the default Reduction-percentage algo.

Whatever the ago used, I think that an OLR can only be sent for two purposes:
- Send an indication of overload situation
- Send an indication of end of the overload situation

For me, providing both indications in the same message would be a non-sense. And I don't understand why the validity period would prevail in that case.


      

      
So here's the question: Let's assume a reporting node sends you an OLR using the "loss" algorithm, a reduction-percentage of 50%, and a Validity-Duration of 10 minutes. 5 minutes later, it sends you a new OLR with an invalid reduction percentage and a Validity-Duration of 0.

What's the current overload state?

What if the second OLR used the "rate" algorithm, with a valid value, but still had a validity duration of 0. Does that change anything?

I am arguing that, in both cases, the second OLR ends the overload period.

I'm actually okay if we have a normative statement to the effect that the reporting node MUST NOT send an invalid reduction percentage, and that a reacting node MUST ignore an OLR with an invalid value _except_ for the case of a validity-duration set to zero.

This all comes down to how much guessing we are willing to do about the intent of the sender when one receives an invalid OLR. I think it's reasonable to guess that a zero validity duration means to end an overload condition, without regard to the rest of the message. I _don't_ think it's reasonable to try to guess what the sender meant with an invalid reduction percentage, when the validity period is non-zero.

Another, perhaps simpler, approach would be to assert that the reception of _any_ invalid OLR automatically ends any existing overload condition. (I'm not necessarily arguing for that--it's just something to think about.)



      

        
Now, if what is argued by Ben and supported by JJ and Steve is clear for the rest of the group, I will not fight.


      

      
... but the fighting is the fun part :-)
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



    

    

  


--------------090508020701010204040803--


From nobody Mon Feb 24 14:06:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE48A1A02C7 for ; Mon, 24 Feb 2014 14:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.35
X-Spam-Level: **
X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGi2AikOaKod for ; Mon, 24 Feb 2014 14:06:41 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id A94201A02C6 for ; Mon, 24 Feb 2014 14:06:41 -0800 (PST)
Received: from [137.254.4.54] (port=32335 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI3fb-0006bK-9B for dime@ietf.org; Mon, 24 Feb 2014 14:06:40 -0800
Message-ID: <530BC272.509@usdonovans.com>
Date: Mon, 24 Feb 2014 16:06:42 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <087A34937E64E74E848732CFF8354B9209784033@ESESSMB101.ericsson.se> <530771A6.4030002@usdonovans.com> <087A34937E64E74E848732CFF8354B920978435A@ESESSMB101.ericsson.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060107050101040201050008"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PP7pjp8pHMjzEZBpTDJjiZZlLlI
Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 22:06:43 -0000

This is a multi-part message in MIME format.
--------------060107050101040201050008
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

There is still an issue with the text Maria Cruz points out.  This part
-- If the OC-Supported-Features AVP is received for the first time for
the reporting node -- is erroneous and should be removed from the sentence.

Steve

On 2/21/14 11:24 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi MCruz
>
>  
>
> The text  you propose to remove deals with the Seq number within
>  OC-Supported features, because of duplication with another text, but
> this other text text relates to the seq number handling within the
> OC-OLR AVP.
>
> I think we can keep two texts, one for the seq number  within
> OC-Supported features  and another one for  the seq number  within
> OC-OLR AVP,. We will then see how the text  for seq number  within
> OC-Supported features evolves with the #29  outputs.
>
>  
>
> Best regards
>
>  
>
> JJacques  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* vendredi 21 février 2014 16:42
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
>
>  
>
> Steve,
>
>  
>
> Extracted text is duplicated now, this paragraph I referred is simply
> wrong.
>
> But I agree duplicated text should be revised due to issue#29, but
> this is up to this ticket to provide the alternative text.
>
>  
>
> Cheers
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* viernes, 21 de febrero de 2014 16:33
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
>
>  
>
> Maria Cruz,
>
> I think we need to see the replacement text before concluding this ticket.
>
> Steve
>
> On 2/21/14 2:51 AM, Maria Cruz Bartolome wrote:
>
>      
>
>     #53: 5.5.2 chapter typo?
>
>      
>
>     Following text will be deleted:
>
>      
>
>         .........  If the OC-Supported-Features AVP
>
>         is received for the first time for the reporting node or the OC-
>
>         Sequence-Number AVP value is less than the previously received/
>
>         recorded one (and is outside the valid overflow window), then either
>
>         the sequence number is stale (e.g. an intentional or unintentional
>
>         replay) and SHOULD be silently discarded.
>
>      
>
>      As long as, the situations that it refers are covered later in the same chapter.
>
>      
>
>      
>
>     _______________________________________________
>
>     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


--------------060107050101040201050008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    There is still an issue
      with the text Maria Cruz points out.  This part -- If the OC-Supported-Features
      AVP
      is received for the first time for the reporting node -- is
      erroneous and should be removed from the sentence.

      

      Steve

      

    
    
On 2/21/14 11:24 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi
            MCruz

        
 

        
The
            text  you propose to remove deals with the Seq number within
             OC-Supported features, because of duplication with another
            text, but this other text text relates to the seq number
            handling within the OC-OLR AVP.

        
I
            think we can keep two texts, one for the seq number  within
            OC-Supported features  and another one for  the seq number
             within OC-OLR AVP,. We will then see how the text  for seq
            number  within OC-Supported features evolves with the #29
             outputs.

        
 

        
Best
            regards

        
 

        
JJacques
             

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : vendredi 21 février 2014 16:42

                À : dime@ietf.org

                Objet : Re: [Dime] [dime] #53: 5.5.2 chapter
                typo? - conclusion

          

        

        
 

        
Steve,
            

        
 

        
Extracted
            text is duplicated now, this paragraph I referred is simply
            wrong.

        
But
            I agree duplicated text should be revised due to issue#29,
            but this is up to this ticket to provide the alternative
            text.

        
 

        
Cheers

        
/MCruz

        
 

        

          

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

                Sent: viernes, 21 de febrero de 2014 16:33

                To: dime@ietf.org

                Subject: Re: [Dime] [dime] #53: 5.5.2 chapter
                typo? - conclusion

          

        

        
 

        
Maria Cruz,

          

          I think we need to see the replacement text before concluding
          this ticket.

          

          Steve

        

          
On 2/21/14 2:51 AM, Maria Cruz Bartolome
            wrote:

        

        

          
 

          
#53: 5.5.2 chapter typo?

          
 

          
Following text will be deleted:

          
 

          
    .........  If the OC-Supported-Features AVP

          
    is received for the first time for the reporting node or the OC-

          
    Sequence-Number AVP value is less than the previously received/

          
    recorded one (and is outside the valid overflow window), then either

          
    the sequence number is stale (e.g. an intentional or unintentional

          
    replay) and SHOULD be silently discarded.

          
 

          
 As long as, the situations that it refers are covered later in the same chapter.

          
 

          
 

          
_______________________________________________

          
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


    

    

  


--------------060107050101040201050008--


From nobody Mon Feb 24 14:43:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610DC1A0311 for ; Mon, 24 Feb 2014 14:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRhObfhrH8tT for ; Mon, 24 Feb 2014 14:43:06 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E911A030A for ; Mon, 24 Feb 2014 14:43:06 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1OMh3Es088048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 16:43:05 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530BBA98.9080903@usdonovans.com>
Date: Mon, 24 Feb 2014 16:43:03 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EDA7999-937A-434C-B94A-A41C1C6EF0EE@nostrum.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com>  <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <579DC2BE-CC3C-43E6-819C-ADB7B1182CED@nostrum.com> <530BBA98.9080903@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/APt5MZAba7qdR0cUE3FlfimFErw
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 22:43:07 -0000

On Feb 24, 2014, at 3:33 PM, Steve Donovan  =
wrote:

> I think the proposal here is the following:
>=20
> A reporting node communicates that an overload report is no longer =
valid by sending an OLR with a Validity-Period AVP with a value of zero. =
 This is the only way for a reporting node to indicate that an overload =
report is no longer valid.  For instance, setting the =
reduction-percentage to zero does not make the overload report invalid. =20=

>=20
> Do we have agreement on this?

Agreed.=


From nobody Mon Feb 24 14:57:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3C31A0313 for ; Mon, 24 Feb 2014 14:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW1LOEfZx1jz for ; Mon, 24 Feb 2014 14:57:33 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7109B1A030A for ; Mon, 24 Feb 2014 14:57:33 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1OMvUve088639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 16:57:32 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530BAFBC.80101@usdonovans.com>
Date: Mon, 24 Feb 2014 16:57:30 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <987072EC-AD3E-4D7F-99AA-81F83B5E19F7@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F31@DEMUMBX014.nsn-intra.net> <530BAFBC.80101@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/q49ZTSaEebA0A_qtJOwmUW-4GTA
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#34 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 22:57:36 -0000

I think I agree, but there's a use case that I'm not sure we've covered:

Our definition of a host report requires the Destination-Host avp to be =
present. I think that makes sense for non-adjacent cases ( e.g. =
client-->agent --> server. ) The only way a client knows that a request =
will go to the specific server is the DH avp. But for adjacent cases, =
(e.g. client or agent --> server), the reacting node has complete =
control over the next hop destination, based on whatever sever selection =
function it might implement.

More concretely, if a reacting node receives a host OLR from a reporting =
node, and needs to send a request that it knows will go to that =
reporting node based on it's local next-hop selection, but no DH AVP is =
present, does the OLR apply? If not, do we have any way for a reporting =
node to indicate that it wants a reduction of all messages for an =
application, regardless of whether they are realm or DH routed?

On Feb 24, 2014, at 2:46 PM, Steve Donovan  =
wrote:

> +1
> On 2/20/14 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> #34: Semantics of OC-Report-Type AVP
>> =20
>> Dear all,
>> =20
>> Apart from potentially renaming =93realm report=94 to something else =
(I don=92t like =93realm routed report=94 as its not the report that is =
realm-routed) I believe we finally agreed to accept the text as proposed =
in ticket#34 and replace the corresponding text from clause 4.6.
>> =20
>> Ulrich
>> =20
>> =20
>> =20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Feb 24 15:00:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6931A01B7 for ; Mon, 24 Feb 2014 15:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwVW_J-pnxD9 for ; Mon, 24 Feb 2014 15:00:21 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 985871A01BB for ; Mon, 24 Feb 2014 15:00:20 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1ON0Iln088831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 17:00:19 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530BAC7C.7080106@usdonovans.com>
Date: Mon, 24 Feb 2014 17:00:17 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ot4EhPRPeEQua00QPImC6YNnc8E
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 23:00:22 -0000

+ 1, except as noted:

On Feb 24, 2014, at 2:33 PM, Steve Donovan  =
wrote:

> Ulrich,
>=20
> Would you agree to the following to replace the first two statements:
>=20
> Sequence number is of type Unsigned64.
>=20
> When generated, a new sequence number must be greater than the =
sequence number contained in the active overload report to which it =
applies (including over reboot of that node).  Note: this allows =
sequence numbers to start at 1 for any occurrence of overload at a =
reporting node.  This, I think, allows us to ignore wraparound issues as =
wraparound will never happen.  Unless we are worried about a server =
staying in overload for billions of years (assuming reports with a ten =
minute validity period refreshed every five minutes).

s/ any occurrence of overload / the initial occurrence of an overload =
condition

>=20
> The other two statements are good.
>=20
> Steve


From nobody Mon Feb 24 15:01:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A507A1A01CB for ; Mon, 24 Feb 2014 15:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nHr0dWzhNtM for ; Mon, 24 Feb 2014 15:01:42 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BC51A01B7 for ; Mon, 24 Feb 2014 15:01:41 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1ON1dKm088885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 17:01:41 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530BA7B6.9020405@usdonovans.com>
Date: Mon, 24 Feb 2014 17:01:39 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1HE7jK3g_xeNo6MQyhwo1cI0FsY
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 23:01:43 -0000

On Feb 24, 2014, at 2:12 PM, Steve Donovan  =
wrote:

> I can see two additional reasons for requiring OC-Supported-Features:
>=20
> 1) If the reacting node needs to know in advance whether the type of =
overload abatement the reporting node will ask for.
>=20
> this is not needed in the case of the loss abatement algorithm as the =
reacting node can just immediately start throttling the appropriate =
number of requests.  It does not require prior knowledge of the traffic =
sent.
>=20
> There are abatement algorithms that do require the client to keep =
state about traffic sent to specific destinations.  We can, if we =
choose, leave it up to the drafts associated with the new abatement =
algorithms to specify the requirement to include OC-Supported-Features, =
as proposed by Ulrich.
>=20
> 2) If the reacting node can use the absence of the =
OC-Supported-Features AVP in answer messages to know that there is no =
Diameter overload supported in the network and thus take other measures =
to protect the Diameter network.  For example, I can envision a client =
implementation that adapts to the knowledge of whether servers support =
overload.  In the case that the server does support overload the client =
can send unlimited traffic to the server, up to the point that the =
server sends an OLR.  If the client determines that the server does not =
support overload then it might have a configured maximum rate that it =
will send to the server.
>=20
> My inclination is to include the OC-Supported-Features AVP in answers =
because most abatement algorithms will need it and because it can lead =
to better implementation client implementations.

+1 on both points=


From nobody Mon Feb 24 15:02:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6E1A0320 for ; Mon, 24 Feb 2014 15:02:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58d6amCmAFeM for ; Mon, 24 Feb 2014 15:02:33 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 381321A030A for ; Mon, 24 Feb 2014 15:02:33 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1ON1dKn088885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 17:02:32 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530BA310.4090100@usdonovans.com>
Date: Mon, 24 Feb 2014 17:02:31 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BE5229D-E276-4084-B6EB-DBF89817E02F@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net> <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com> <530BA310.4090100@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K5yVVqiAF89f-CvYQs6FqmRuyzM
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#29 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 23:02:37 -0000

On Feb 24, 2014, at 1:52 PM, Steve Donovan  =
wrote:

> I agree.
>=20
> I also think that we agreed that the lifetime of the =
OC-Supported-Features AVP is a single transaction and that the =
OC-Supported-Features AVP must be included in all requests originated by =
a Diameter node supporting DOIC.

+1, and my previous agreement was based on that assumption.


>=20
> Steve
>=20
> On 2/20/14 4:31 PM, Ben Campbell wrote:
>> I concur with removing the sequence number from =
OC-Supported-Features.
>>=20
>>=20
>=20


From nobody Mon Feb 24 15:11:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9163F1A031D for ; Mon, 24 Feb 2014 15:11:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADd5mS99ziye for ; Mon, 24 Feb 2014 15:11:50 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D21A0307 for ; Mon, 24 Feb 2014 15:11:50 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1ONBlS5089336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 17:11:49 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530B9202.8040100@usdonovans.com>
Date: Mon, 24 Feb 2014 17:11:47 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com>
References: <530B9202.8040100@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kyb6eGr38jOfh7seF37HSEDic_U
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 23:11:51 -0000

On Feb 24, 2014, at 12:40 PM, Steve Donovan  =
wrote:

> There has been no discussion of ticket #27.  I can't even find it on =
the DIME list, so I'm copying it here to initiate discussion.
>=20
> The proposal is for an agent to send a TOO-BUSY response when it =
throttles a request from a non supporting client.  The behavior of the =
agent in this case would be in the new section to be added to capture =
agent behavior as proposed in issue #24 (and various other places).
>=20

RFC6733 has the following to say about TOO_BUSY

"When returned, a Diameter node SHOULD attempt to send the message to an =
alternate peer.  This error MUST only be used when a specific server is =
requested, and it cannot provide the requested saervice."

Do those semantics and limitations apply to this usage? Is there a =
chance if incorrect behavior from a client that doesn't support DOIC, =
and therefore is not aware of this new usage of TOO_BUSY? For example, =
if an agent sends TOO_BUSY due due to a host OLR received from the an =
upstream server, the client might (actually SHOULD) try to reach that =
same server via an alternate agent. Is that okay?

I'm not sure I understand the original intent of the MUST only sentence. =
But the only way I know of to request a specific server is to use D-H. =
So would we allow the sending of a TOO_BUSY in response to a =
realm-routed request?



From nobody Mon Feb 24 15:13:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E36A1A0307 for ; Mon, 24 Feb 2014 15:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzYjae34mi-O for ; Mon, 24 Feb 2014 15:13:34 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DD91A02E4 for ; Mon, 24 Feb 2014 15:13:34 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1ONDQD9089395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 17:13:33 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530B87D0.1040003@usdonovans.com>
Date: Mon, 24 Feb 2014 17:13:26 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <214266C0-601C-4BDC-B2F9-910BF3BD9557@nostrum.com>
References: <530B87D0.1040003@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ukx_WM9AQv2M8apbiAF7LPoQMw8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue #25 Proposed Resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 23:13:36 -0000

On Feb 24, 2014, at 11:56 AM, Steve Donovan  =
wrote:

> I propose that we close issue 25 as the resolution of issue 24 =
addressed the concerns raised in issue 25.
>=20
> Note that this requires a new section in the draft to define agent =
behavior.  The actual wording of that section will need to be agreed to =
before issue 24 can be closed.
>=20


Agreed.


From nobody Mon Feb 24 18:22:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2E01A0341 for ; Mon, 24 Feb 2014 18:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeQnYyTdgBmV for ; Mon, 24 Feb 2014 18:22:51 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5811A1A0320 for ; Mon, 24 Feb 2014 18:22:51 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64649 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI7fU-0007Oz-Tc; Mon, 24 Feb 2014 18:22:49 -0800
Message-ID: <530BFE79.5020209@usdonovans.com>
Date: Mon, 24 Feb 2014 20:22:49 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ben Campbell 
References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com>
In-Reply-To: <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com>
Content-Type: multipart/alternative; boundary="------------040306040305000508090004"
X-OutGoing-Spam-Status: No, score=-2.9
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: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ced8_xmdyY2tnmICG0_05y8rSjE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 02:22:53 -0000

This is a multi-part message in MIME format.
--------------040306040305000508090004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It looks like DIAMETER-TOO-BUSY fits best for requests throttled because 
of a Realm-Routed-Request (RRR) overload report handled by an agent.

The only other option I see for agent handling of host overload reports 
is DIAMETER_UNABLE_TO_COMPLY.

    DIAMETER_UNABLE_TO_COMPLY 5012

       This error is returned when a request is rejected for unspecified
       reasons.

This is the behavior definition:

If the service cannot be
    provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
    message MUST be sent within the accounting request; a Diameter client
    receiving an authorization response for a service that it cannot
    perform MUST NOT substitute an alternate service and then send
    accounting requests for the alternate service instead.

Or we could use DIAMETER_UNABLE_TO_DELIVER

  DIAMETER_UNABLE_TO_DELIVER 3002

       This error is given when Diameter cannot deliver the message to
       the destination, either because no host within the realm
       supporting the required application was available to process the
       request or because the Destination-Host AVP was given without the
       associated Destination-Realm AVP.



Steve

On 2/24/14, 5:11 PM, Ben Campbell wrote:
> On Feb 24, 2014, at 12:40 PM, Steve Donovan  wrote:
>
>> There has been no discussion of ticket #27.  I can't even find it on the DIME list, so I'm copying it here to initiate discussion.
>>
>> The proposal is for an agent to send a TOO-BUSY response when it throttles a request from a non supporting client.  The behavior of the agent in this case would be in the new section to be added to capture agent behavior as proposed in issue #24 (and various other places).
>>
> RFC6733 has the following to say about TOO_BUSY
>
> "When returned, a Diameter node SHOULD attempt to send the message to an alternate peer.  This error MUST only be used when a specific server is requested, and it cannot provide the requested saervice."
>
> Do those semantics and limitations apply to this usage? Is there a chance if incorrect behavior from a client that doesn't support DOIC, and therefore is not aware of this new usage of TOO_BUSY? For example, if an agent sends TOO_BUSY due due to a host OLR received from the an upstream server, the client might (actually SHOULD) try to reach that same server via an alternate agent. Is that okay?
>
> I'm not sure I understand the original intent of the MUST only sentence. But the only way I know of to request a specific server is to use D-H. So would we allow the sending of a TOO_BUSY in response to a realm-routed request?
>
>
>


--------------040306040305000508090004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    It looks like DIAMETER-TOO-BUSY fits best for requests throttled
    because of a Realm-Routed-Request (RRR) overload report handled by
    an agent.

    

    The only other option I see for agent handling of host overload
    reports is DIAMETER_UNABLE_TO_COMPLY.  

    
    
   DIAMETER_UNABLE_TO_COMPLY 5012

    
    
      This error is returned when a request is rejected for unspecified
      reasons.

    This is the behavior definition:

    
    
If the service cannot be
   provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
   message MUST be sent within the accounting request; a Diameter client
   receiving an authorization response for a service that it cannot
   perform MUST NOT substitute an alternate service and then send
   accounting requests for the alternate service instead.

    Or we could use DIAMETER_UNABLE_TO_DELIVER

    
    
 DIAMETER_UNABLE_TO_DELIVER 3002

      This error is given when Diameter cannot deliver the message to
      the destination, either because no host within the realm
      supporting the required application was available to process the
      request or because the Destination-Host AVP was given without the
      associated Destination-Realm AVP.

    

    

    Steve

    

    
    
On 2/24/14, 5:11 PM, Ben Campbell
      wrote:

    

    

      
On Feb 24, 2014, at 12:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
There has been no discussion of ticket #27.  I can't even find it on the DIME list, so I'm copying it here to initiate discussion.

The proposal is for an agent to send a TOO-BUSY response when it throttles a request from a non supporting client.  The behavior of the agent in this case would be in the new section to be added to capture agent behavior as proposed in issue #24 (and various other places).



      

      
RFC6733 has the following to say about TOO_BUSY

"When returned, a Diameter node SHOULD attempt to send the message to an alternate peer.  This error MUST only be used when a specific server is requested, and it cannot provide the requested saervice."

Do those semantics and limitations apply to this usage? Is there a chance if incorrect behavior from a client that doesn't support DOIC, and therefore is not aware of this new usage of TOO_BUSY? For example, if an agent sends TOO_BUSY due due to a host OLR received from the an upstream server, the client might (actually SHOULD) try to reach that same server via an alternate agent. Is that okay?

I'm not sure I understand the original intent of the MUST only sentence. But the only way I know of to request a specific server is to use D-H. So would we allow the sending of a TOO_BUSY in response to a realm-routed request?





    

    

  


--------------040306040305000508090004--


From nobody Mon Feb 24 18:41:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86501A03A6 for ; Mon, 24 Feb 2014 18:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xex9mlskh8TP for ; Mon, 24 Feb 2014 18:41:20 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8081A039B for ; Mon, 24 Feb 2014 18:41:19 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1P2fG8h095830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 20:41:18 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530BFE79.5020209@usdonovans.com>
Date: Mon, 24 Feb 2014 20:41:16 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com> <530BFE79.5020209@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XFdhY9p45SFawUO52iWjaPa1SbI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 02:41:21 -0000

On Feb 24, 2014, at 8:22 PM, Steve Donovan  =
wrote:

> It looks like DIAMETER-TOO-BUSY fits best for requests throttled =
because of a Realm-Routed-Request (RRR) overload report handled by an =
agent.

I'm confused. I interpreted 6733 to explicitly forbid DIAMETER_TO_BUSY =
for realm routed requests:=20

"This error MUST only be used when a specific server is requested..."

What am I missing? (Yes, I recognize "... when a specific server is =
requested..." is vague.)


>=20
> The only other option I see for agent handling of host overload =
reports is DIAMETER_UNABLE_TO_COMPLY. =20
>    DIAMETER_UNABLE_TO_COMPLY 5012
>       This error is returned when a request is rejected for =
unspecified
>       reasons.
>=20
> This is the behavior definition:
> If the service cannot be
>    provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
>    message MUST be sent within the accounting request; a Diameter =
client
>    receiving an authorization response for a service that it cannot
>    perform MUST NOT substitute an alternate service and then send
>    accounting requests for the alternate service instead.
>=20
> Or we could use DIAMETER_UNABLE_TO_DELIVER
>  DIAMETER_UNABLE_TO_DELIVER 3002
>=20
>       This error is given when Diameter cannot deliver the message to
>       the destination, either because no host within the realm
>       supporting the required application was available to process the
>       request or because the Destination-Host AVP was given without =
the
>       associated Destination-Realm AVP.

This seems closer to the right semantics for RRRs.


From nobody Mon Feb 24 23:52:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C731A044B for ; Mon, 24 Feb 2014 23:51:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1RJoWRXIw55 for ; Mon, 24 Feb 2014 23:51:52 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD261A042C for ; Mon, 24 Feb 2014 23:51:51 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1P7ot2r013412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 08:51:48 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1P7orna004908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 08:50:54 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 08:50:53 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 08:50:53 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Maria Cruz Bartolome , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
Thread-Index: AQHPMZF4/G9fUnj1okql3Ng2TYdVeZrEug2AgADbzjA=
Date: Tue, 25 Feb 2014 07:50:52 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com>
In-Reply-To: <530B9E01.3050506@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B45D9DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 16504
X-purgate-ID: 151667::1393314708-00005322-B30009E5/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6hr9NJmQpmujMOYC2-XQMC3Ks0M
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 07:51:56 -0000

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

Hi,
I agree with MCruz.

Principle is that the server never sends OLRs with a report type of realm-r=
outed-request (exept the case where the server knows (i.e.is configured) th=
at there is no other server in that realm).

Only agents that are configured to take the role of a reporting node for a =
realm will insert OLRs with report type of realm-routed-requests into answe=
r messages and the content should be the aggregation of percentages as rece=
ived in host type OLRs from all the servers in the realm.

Ulrich




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.o=
rg
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of th=
e meaning of realm-routed-request report (new attempt at a name to try to m=
ake Ulrich happy :-) ).

My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions.

Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and appli=
cations that always rely on realm routed requests.

Everyone, which definition applies?

Steve
On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:

Steve,



See some comments below please.

/MCruz



-----Original Message-----

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

Sent: lunes, 24 de febrero de 2014 17:20

To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

Cc: dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type



#57: Handling of "Realm-Routed" Overload report type



 I'm assuming the name of the realm overload report in the -01 version will

 be changed to realm-routed.  This issue applies independent of the actual

 name of the report.



 The current behavior assumed for the realm-routed report is that the

 reacting node, generally the client, will reduce the percentage of realm

 routed requests sent to the reporting node.



 This is actually bad behavior and could result in the client throttling

 traffic that could have been handled by the full set of servers for that

 Diameter application.

[MCruz] This can only happen if the agent has miscalculated the realm overl=
oad.



 Consider the case where there are n servers for a Diameter application and

 all of those server are able to handle any transaction for that

 application.



 When one of those servers becomes overloaded and wishes to decrease the

 number of new sessions, the primary use of realm-routed requests.  The

 server will generate an OLR of type realm-routed.

[MCruz] I do not agree. Servers do not generate Realm-routed reports.



 Assume in this case that the other servers are all healthy and able to

 handle new sessions.



 Clients will not have the knowledge that there are other servers in the

 network able to handle the new session and will have no choice but the

 throttle a percentage of the new session requests.  Even when these

 throttled requests could have been handled by any of the non overloaded

 servers.



 The proposal is to specify that realm-routed reports must be handled by

 DOIC-supporting agents.  Agents will understand if there are other servers

 able to handle the new session and, if so, can adjust the percentage of

 requests routed to the overloaded server.



 Agents that handle the realm-routed OLR must remove the request from the

 answer before relaying the answer to client.  This prevents the report

 from being acted on by either multiple agents (if multiple are in the

 path) or by an agent and a client.



 Clients that receive the realm-routed OLR must handle the OLR by

 throttling the requested percentage.




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











Hi,


I agree wi=
th MCruz.


 =
;


Principle =
is that the server never sends OLRs with a report type of realm-routed-requ=
est (exept the case where the server knows (i.e.is configured)
 that there is no other server in that realm).


 =
;


Only agent=
s that are configured to take the role of a reporting node for a realm will=
 insert OLRs with report type of realm-routed-requests into
 answer messages and the content should be the aggregation of percentages a=
s received in host type OLRs from all the servers in the realm.<=
/span>


 =
;


Ulrich


 =
;


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, February 24, 2014 8:31 PM

To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools=
.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


Maria Cruz,



Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to try=
 to make Ulrich happy :-) ).



My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions. 




Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.



I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.



Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and =
applications that always rely on realm routed requests.



Everyone, which definition applies?



Steve




On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:






Steve,


 


See some comments below please.


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of dime issue tracker


Sent: lunes, 24 de febrero de 2014 17:20


To: draft-docd=
t-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com


Cc: dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overl=
oad report type


 


#57: Handling of "Realm-Routed" Overload report type


 


 I'm assuming the name of the realm overload report in the -01 version=
 will


 be changed to realm-routed.  This issue applies independent of t=
he actual


 name of the report.


 


 The current behavior assumed for the realm-routed report is that the<=
o:p>


 reacting node, generally the client, will reduce the percentage of re=
alm


 routed requests sent to the reporting node.


 


 This is actually bad behavior and could result in the client throttli=
ng


 traffic that could have been handled by the full set of servers for t=
hat


 Diameter application.


[MCruz] This can only happen if the agent has miscalculated the realm =
overload.


 


 Consider the case where there are n servers for a Diameter applicatio=
n and


 all of those server are able to handle any transaction for that<=
/o:p>


 application.


 


 When one of those servers becomes overloaded and wishes to decrease t=
he


 number of new sessions, the primary use of realm-routed requests.&nbs=
p; The


 server will generate an OLR of type realm-routed.


[MCruz] I do not agree. Servers do not generate Realm-routed reports.<=
o:p>


 


 Assume in this case that the other servers are all healthy and able t=
o


 handle new sessions.


 


 Clients will not have the knowledge that there are other servers in t=
he


 network able to handle the new session and will have no choice but th=
e


 throttle a percentage of the new session requests.  Even when th=
ese


 throttled requests could have been handled by any of the non overload=
ed


 servers.


 


 The proposal is to specify that realm-routed reports must be handled =
by


 DOIC-supporting agents.  Agents will understand if there are oth=
er servers


 able to handle the new session and, if so, can adjust the percentage =
of


 requests routed to the overloaded server.


 


 Agents that handle the realm-routed OLR must remove the request from =
the


 answer before relaying the answer to client.  This prevents the =
report


 from being acted on by either multiple agents (if multiple are in the=



 path) or by an agent and a client.


 


 Clients that receive the realm-routed OLR must handle the OLR by=



 throttling the requested percentage.


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B45D9DEMUMBX014nsnin_--


From nobody Tue Feb 25 00:34:43 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9191A03F3 for ; Mon, 24 Feb 2014 19:37:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAshk8FJiDyW for ; Mon, 24 Feb 2014 19:37:53 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 126161A03F4 for ; Mon, 24 Feb 2014 19:37:53 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54138 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WI8q6-00067X-5C for dime@ietf.org; Mon, 24 Feb 2014 19:37:51 -0800
Message-ID: <530C100E.4070607@usdonovans.com>
Date: Mon, 24 Feb 2014 21:37:50 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/mixed; boundary="------------090300010300040604040808"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Bz3eS4RgpM4n7OFPFLtHyMI17qs
X-Mailman-Approved-At: Tue, 25 Feb 2014 00:34:39 -0800
Subject: [Dime] DOIC Issue Status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 03:37:55 -0000

This is a multi-part message in MIME format.
--------------090300010300040604040808
Content-Type: multipart/alternative;
 boundary="------------050504000204000503040308"


--------------050504000204000503040308
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

My apologies for the flood of messages to the DIME list today.  I was in
the process of compiling the attached document.

The document attempts to capture the status of all of the open trouble
tickets for the DIOC specification.  It is the first draft so be nice if
there are obvious errors.

I am compiling this in advance of next weeks DIME working group meeting
in London.  I hope to have resolved issues updated in a preliminary
version of a -02 version of the DOIC draft prior to the DIME meeting.

Please let me know if there is disagreement on the items I have marked
as resolved, as I will be making those updates to the DOIC draft first.

It is also possible that some of those I have marked as open can be
moved pretty quickly to resolved.

Regards,

Steve

--------------050504000204000503040308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      My apologies for the flood of messages to the DIME list today.  I
      was in the process of compiling the attached document.

      

      The document attempts to capture the status of all of the open
      trouble tickets for the DIOC specification.  It is the first draft
      so be nice if there are obvious errors.

      

      I am compiling this in advance of next weeks DIME working group
      meeting in London.  I hope to have resolved issues updated in a
      preliminary version of a -02 version of the DOIC draft prior to
      the DIME meeting.

      

      Please let me know if there is disagreement on the items I have
      marked as resolved, as I will be making those updates to the DOIC
      draft first.

      

      It is also possible that some of those I have marked as open can
      be moved pretty quickly to resolved.

      

      Regards,

      

      Steve

    
  


--------------050504000204000503040308--

--------------090300010300040604040808
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
 name="DOIC issue status - 140224.docx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="DOIC issue status - 140224.docx"

UEsDBBQABgAIAAAAIQDpURCwjQEAAMIFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo
oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lE1PwkAQhu8m/odmr6Zd8GCMoXBQPCqJ
GM/rdgqr3Y/sLF//3mmBBkmhKHpp0k7f931m2p3eYKmLaA4elTUp6yYdFoGRNlNmkrLX8WN8
yyIMwmSisAZStgJkg/7lRW+8coARqQ2mbBqCu+Mc5RS0wMQ6MFTJrdci0K2fcCfkp5gAv+50
bri0JoAJcSg9WL/3ALmYFSEaLunxmoTkLLpfv1dGpUw4VygpAoHyssobdR4KPCKcm2yPLt6Q
JaSszHGqHF4dTvhwMNlLULpsrSoQ1TON06sMopHw4UloYucL6zOeWTnT1HdyvLkGRpvnSkKt
L92ctxIQ6TvpIqkrWiizZT/IgWFVAP49xdr3xPg3FabDPAdJP0j7PDTGZdPJOmJH254GIdCQ
Tgn5/tvGbUPHjXMrwgLeX/6NYse8FSSn8zQW7wWcMPEfDqO2boUItCOAV9fu2RyVzbFIOhkj
bx3SzvG/aHu7HEp1TEfOgQ8K6vXQdMTqRFpYZ/cH5UbMIGvI5tUG7n8BAAD//wMAUEsDBBQA
BgAIAAAAIQDHwie8DAEAAN8CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAArJLBTsMwDIbvSLxD5PuabiCE0NJdENJuCJUHMInXBtokSjzY3p6w
w0qlUU1ix8TOn+/37+Vq13fik2Ky3imYFyUIctob6xoFr/XT7B5EYnQGO+9IwZ4SrKrrq+UL
dcj5UWptSCKruKSgZQ4PUibdUo+p8IFcrmx87JHzMTYyoP7AhuSiLO9k/K0B1UhTrI2CuDY3
IOp9yD//R1v2xGiQUWofaRZiJotssxdRY2yIFRivn/N1OnQUmRrkaaDb84H8ZmM1PXq97cnx
Cc+SdkzOkJlGwhCmiOaXJBozD/P58tHIPKSDlSmaxfk0fy/DEBi32/7Noe0GlGNUx1rxHqj5
CUyO1rL6BgAA//8DAFBLAwQUAAYACAAAACEAAGh14SABAAC5AwAAHAAIAXdvcmQvX3JlbHMv
ZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAACsk81OwzAQhO9IvIPlO3FSoCBUpxdA6hWCOLvOOrGI7chefvL2mFSliVrC
JRdLuyvPfGuNV+sv05AP8EE7y2mWpJSAla7UtuL0pXi8uKUkoLClaJwFTjsIdJ2fn62eoBEY
L4Vat4FEFRs4rRHbO8aCrMGIkLgWbJwo543AWPqKtUK+iQrYIk2XzA81aD7SJJuSU78pLykp
ujY6/6/tlNIS7p18N2DxhAULgBg3C1FT+AqQ030niZyUnUa4mhPhE7bPRxSD5hTI9Zwgylks
xLaBw2P8tqYglnNCYAzKAKAvWX9mUwzZnAwBuyam+hCJvp6yX/xhb7T0LjiFiXSG7eL4E8Ob
cdLZzvFVY/2gFEg8Mh+M9hxs9OHybwAAAP//AwBQSwMEFAAGAAgAAAAhAOqQEIP/NwAA82AB
ABEAAAB3b3JkL2RvY3VtZW50LnhtbOR9647bSJbm/wX2HYg0sKgCKtO8XzztbPDaZcBlF2xX
FxaDRYMpMTMJS6JGF2fl/Jp32F8L7ALzLPMo9ST7nQhSiqAoKXTNdHaj4bIlimScOHHOd+5/
+esfw4H2rZhMy2r09sK40i+0YtSr+uXo7u3Fb1+yS/9Cm87yUT8fVKPi7cVjMb346/V//29/
eXjTr3rzYTGaabjFaPrmYdx7e3E/m43fvH497d0Xw3x6NSx7k2pa3c6uetXwdXV7W/aK1w/V
pP/a1A2d/W08qXrFdIrnxfnoWz69qG83rNTuNsx7zY1NXfdfD/NytLjH6htV42KE972tJsN8
Nr2qJnf4xeTrfHyJNxzns/KmHJSzR7yf7i5u8+3txXwyelOv6nKxKvrNG7zAm2/DQXMxXnv9
tZwCb/h/ml9MVhba8ZL8J0lNcvZ6ryfFAC9cjab35XhJt33vBnrcN6+0ccHCYh/Ghr3yvAV5
VDY9meQP2PvmwQ/jldt1EKPPfzQccDoQQy3ZqH1HQ1fYEbrF4h1UXkF+ZvMmIvM97EeaJSc9
jHEEDzlQf5tU8/FiVePysLu9G31d3IskwQ5vprvsqItLm+50gxVZ8fk+HxcX2rD35t3dqJrk
NwO8ESiuEUdeXEM63VT9R/rvWMPHb8b5JH/Xf3vhuJath4l5wT6dFX/M6FPXSX07MwJ8+gaS
sP/p7YWu67Zhe5B+9UdJcZvPBzPhG7r7hP6YXX+e5bP5VPtaPL75y2v6gP7Ed/hz3PESoe1G
HskXerXmJWwrTaM4ihdPFB6l9BIfIdq0P//jf2uzsve1mGl0cIq+Btmt3RQ4Y1q/nPbm02nR
v9K0z9Ww0HBoxtU0H0y1YXl3P9OKP8rpTLuZz7RRpfUgWIrRFMu6z6e4A24+KXII9v6Vwhot
J3UCz43kNeqZ5Ud+QCvfj9Cfimk1+IZV0TqXb1i/mFbRO+KKOYlFrbrVZveFNsMxAH/UZMHa
oWiwHq03qEAL7eEeK5uP+/msmGr5pNCGeR8XV+y3ycd3sQZxcztjdKTbNZdCaZa3pRo1PN10
vdDPWtSIvdj3wnRvasR8BUSLcIb3Laekq+8WSytnxZCvaXaPteKKfIbd/Fbw7byt5uANrHRU
zUC3f5uXWH2zvBUCqOy6F3tJYHu2vE6v/t9u63y9enA8P3IMlxFMODgH3H52M2AH+GbwKz/J
N4PPs0fwysObb/ng7cUXEix/m5T9C/Y2uPx3fPWAk0lrmT2OIXXy+axafP0+f6xwfJrvbss/
iuVv31fV1+bOkC/sHrflZDr7VDW3HOTiv9iXMdh5CGzGLqfvpQ9G1c8RTnj99aj6e/MvvDBJ
ImFltA5a7R3+i3vwhRh64PO3lz62dUfv+NgwvK6PXd9hN+EPbJ4zm+ARC3Fqp1YQeAsW+BWo
R9cNR08cBx8KIloPcbvIaUnH9iZ/Yb93TVPPXCbv2UrTP+rtjIvB4Jec72kFFdDas/4fOV/d
TTWbVcN13/P1LO7V0LN+So89q1dzTq/mDEZQ3JAzR/0g+mV9oayPwAWm7zktMdleLNNHmwnI
CS0oKfnyXwVq02tzylx/4Zriw3x4U0w6pDp7b77MzsUyNlFerBfrmR0nId/vRu+dbbGf50NA
/cc9lsnYXn2Zpm5bodnCGCrL3HX7OOzYY0HswCovyPQszwx90lPbxK7MdZ92XdCHCkp4/XqI
HTnnTvDyu4sWNzawN+E/h2hxdd8OY4vw5I671pLNu4qWZmuk2zDxQab9m+k470FtjgHUism3
4uL6lWlp6/ecJOcRZI8TJ7ob2tYzosY1A5c3BQBZWU00uCQIYA+GWgVoOajy/h5E2U1S2aYf
eGlSK+BdBPKuB5tskz2Ws6OcyhLLC5Itx7tLme64nG4+/rW2pphtEt/nIwBxMhhGOUwt2CJ8
cyfFuJrMYIV0kGPFWk0zJ7H0M+wPf3dYQ+xlL7GE//uJePHyE+Bs0b/8BOugmM7+/I//h2Ww
BSi8vuGFiZVYe+yHJDoaebLjJl1L+/EbM/C0fDBozGBmIZLBvGWlU7KQylG/7MFC5CYUdvVR
y8fjwSMsTvyBC8h8AoFwcT65K0Ay+jCv95yZmPgRzCuYaLCt+7i0HDHn3SUss5kW/v1XPIOx
S32nLnOrhmOHqkF4QKw03nZOXgrCDu3AMRKynp67GrS7ZMJxIbgVJLbjhMYzosb1l2IyLEfV
oLrDoYJDIry5mRTfSu7a7hAz2yiymw40jdRJ4rhNkSzzU9ukT1Vx5gpMqo3T+g5rLLDGobXH
OndTjnromIHN3IvbzoGeOq7b7fmUvlmzpPBuUtQeuk/FEGAG4u62HJWNTy4poRBnxUQb5I/0
J5COdpMP8lEPTsousddWi0Zi6qGxsmW1hbVpywQVIi9y41KkvQE/dPDEBnjL4EAnIb7A+8q4
/ueS4m0qS9e9NDR85qk+/y5y93HtWYWbcQR1l/egyO40eIhnzWruyz7iiRrgLAP4QLaTClHC
YtSfqizRCsPIdO09vAT77S7bn7APRzBiQLQW6GG2ODhJa2g+LbBKOJSh0nsEzpme7uXwqDLN
Dncy/wGU+5IepPwJKdEtRxVcygTwmbJvgP4lHNMErmqNX18/BTbUvpAv96EEWoGjelQ8iC9H
mJK7pJk/l101ohOH18PVJDuLB/zzpsATGeIoZxoOYD4o/13NXe2YqQ9vtYrBLx8j0eCXvxEP
WIdn1zZDL3NdFZ+JfN9P26CifLn4GnRmGz8YkbucTudwnecjcoeDkHV8YD6alQO24w2D1HGF
NUyCOy22gNRZzsXhrOpi/iMhOidJQzsLt/jdXwiic6PYCE2XonXbZGDLHbWNV+TLV3ilkfvS
bTZI/lemc3pE56W+7gXRc6LG9edaXlpXxpWjLfR9SCpDi2qpKmlVnAMESo+N7OIw8LwTOMCU
ZAoPzu2xyt1wnWebphl5JzCylVbJ8Osi3PrKtLW834drb4pgKgtIMql6QtHn2ZltxskW/n8h
ok/Xs9Ty/O/BmHVPL/osK7QSMzoB6++tCK4/1r5bLQbmnSDKmo7646okqIxgO6DjdFz0WN7A
HpJhR8s2TTzXPYX7TUkynMXl6/mh66XuFuDDXL6mZUVCAFowFhLD8sKssRtX1D7T8NcITWnD
ee9edB9SpgwTcsxjn48Jss/EKwAqkYZCnj9cB/+vmgVkm25oBXqiAHDkVxfht/yNuKgO+G34
np9lYcvRbIWBlWQemQFLJ4h8363wW75cfI0F/GY5D7AO4R7t/wpQHYFQX3m+xfU7wuRvNGyW
4EDYcMYIcN9XDwTX4UyC9TOndKf1R40QxyERRc80rci3W4Rrx3pfiPaBVyhAwKglb2GrR1HE
bI8ll8gCdCuXyJevcEnDfyvAewPrdMdoXpne6fWSGcSRG7gq5rO88JPRaXbdoG4KRHHDtfZU
wK1Bfo7BLX0TD0qC6Myv0K8A4cgUns7H5MfQKFy5/iStjdPuprS8KEBKXKDiCNiRdrHtJQw5
MS5d4TEu5c+itEzgFiv2t0DWLUpLVmdsOfVHC8E6k0Ng3PxCTmefhbRu5tNHeCqmY8rzJN8R
NBSyoQbwHDXBrC7B2XbG2r7jGliOgrJqbZiggfddzMJDB6dLLx/P5lAhpHLJY9Y47eBjG5SU
CIvPbx5rLw8MFZXFmYEZR36icpJl9hI1sfyNuFMdmhggJU7TbeYM4w35vltlh3y5+BoCwzC/
43fsCHMdsGOYtlTUS9XHmWuYMIB2P3qSIm20q3Ae5ZO6IiubX0i3YQJ0ndb1z6B1Uz2NMuSn
Ph+34PUnFgHQKBd0oUYhhiCqclZnVBbTv55cpepuYqZOtoeElva32XSBTTrEdp3RK4iUM/nB
XCtOIttUUaoyd28VnEqr/IDQEE/5IeWJRPqTWh1BGKfBtkTaF2J1IF/TxGLJPn/u7v7g9FLO
ziIzs4N2uoJC7HvbYZZPxQ4y//pjfPmZ0p9GveKSp5IT1qJPueWAEGdWoEAKYPP0wi4LAj1t
ezLaAGBLDuChmRttjOwliRW4FqVUbGPh2LKSkITYSjqJ/I24P10wMrDczDC2+CU4jDzOE3XU
rvmJf8YnGkiONDO3pfCNSNdTz6P3WLojZNptlfjy5SKpBb12HlMxM21Xz/YwhwU1rcTOK1k7
fXaCW+caqRzD7pNNKYxKJpUReqltqXhsA92MmO21chbkb8QN6jgLNuSBZ6Yqqd/yfUUjTv5G
fKLAEp+oILvoq9SAGjoKTh2nJcd1E8VzoUNQbcm88qN3fqlFau+fKBP8gtyRaa8CHCU/0Boh
zbNRkcuiUVk+VU5O8tGU/EXVSGWLHTvNbMOlYi9B3OlWFjuZL6fUtda2TUfJl6/ZBWnBi+Az
peBQSBIVkKJDCz59pN+Wo95gTlWfIE+n3moSdCl/eJN35Ej5HLYLzJ6kW8DsCwF4XhDYVtI2
3GycD9+NKAiyPAoyRtkqx+XLV9ilubPEdZvMWEs/A8DzdCeNgi1b3wVgpGU0axPUwN7UYABv
BcotjsRo+oD41hAxfziWT4/wbPjkUJnfUvu6bXr4ghTl3uwSe57P0kXYHVbYhXHG9VnUvmHp
iesEe5jswn6rLKfbX1NjgUuZ20HYhric1eoHcLqEN/As95heWYX9l1TfwLAD5UpKDKP98tvn
L3UF+hQNFsh0QACQp5XWQhu2dUHZluS7pnRKprseWUAC1zKdS9zIoq3TOV6EjBFe0l6gJkNF
Z0E7ZUlgqfjSZLqK+lj+RmSgDljiuHHmxmbLrnWcLMnCdJl9TYW78n3VnijAEmJZjUVSWa7r
O1KDm/QcxUwpICAUvUA1kg8LhGehbkrZ5tmt8GVNJuiCQNtGGa88nNDl1GobRbbnGb4dK/nW
pYOptv4OiluR4adJG0wboWMDiS1trg6KbxOt8gaJG3/ANlBOLwiLmEWOXFQemEPpUEW5wF8Z
vZGZ2iupaRFvdjEpekX5jQ4ITllrn7p25EhgxUgi3w+3ZSC+ELCCAINnRnpLTrip51omM/D3
1j57q+duGf7KMmTxjd1WSLHcraJfT/zI8tEqQkL6Kt6WbSdqb2og+ZQrCeD4j6M7pF7dXX7h
kU3667vRbdUglybvvoEujXUw+VZSi5kc/2YRUfzu5H4rS89iI/Fahj4aE6HjiS3bTDJptoJg
JWfGp7qvzh7r3C1d1cms1N9ae9gFb0VkI7ms1ohbwaFBzvlFNyMoNqSokpm3yh5rOWM6J6Yg
0brkCRVYYaDNnWs6rW3tPCDyPklKbu1yO5ScE7hBmrWjPbqPVC6D5SktBVTriTWokx625TXq
OyyVXLcsUsWT/NEcT/6CKDTR++P7T1zX1VYG0CPV7FKDKhZvQUnyv2gocFmkqwwLaD9+RaMD
X+Pq5b4BpbBa3aKP33YwfBuoONSiJd1nDw+kaAtti9T5r/9UeHHkmJhZFrRcsmaQ6Hpkk8z+
Plihm6d4aJU4hBsJn3/++Nv7BKzCPTk12xRIx6WqUsY8zPkDVuEpMMzOWGa/EHhlbNFYsqjt
KpHu2YBgSIz3n/6RpFn42/sv/wjf/+3jwo80Hw1g/ILDqPhKKvmizmnsDe6qihBzPoUYYsYO
pBCQ3LS60tI/YOws67v414/o35azwqGrLi2+wqIWGowhvVXWwzpSIdzMCbfv9KIPE+cIJVEL
2XMkAOmY8BjG/yRJlHYUpkG6klKUhEmMmmNpq3ZU9PLlK1qxOe4S8mKytvuAvbLMLtar93xt
ut+OANIxDH/FDd6pH+XlbYU98uU7UAMAUo5lfimHxSVaLQ3HGprCocsDy/LmEU7IhA5BvI1G
u6VE6rFlG1lIx1hwp5tI64hd+yD/qNzicoVGXBGvOLyot2b1lbrmgijIC314Uy76z6Gy++3F
P/5WRXnva9NhjV+bIjO7uZKLDgVrZDds6flJiChrSwp6OuoDEAyVjtazhj5tBkRyIxwvzAHz
22ha3iGZ0VVKX0QQIXATu02Q+nidkCCyrBFQ4uxaCbm4gWPC+d96cXTxSELdpuS+54hcyG8U
oM2nvpTiXNbWH/Lj9Du1G0UhZDGhUOFPsDJ5siqXOdqIteLjUSnUIAMC4DKqHgGoJYDBfZvw
s9YXwq6ZoeM1d8DRBeQ5RcuFBvrWiITceTWeAbBA5xpknmk/cLBEGIoux6U42OgbS21TESYj
XPWjkpGT6p7jsGYZgoDqFOLHPXcNH0g4m5NZic3g+gsCv51B8LQvzviDe/I4e7R3HNKgcdD2
0UYD2BEZzqx7LRqCj9FTY/r6Fn7Y+xEwqcrueaGF3ctUqo2e1+5Z6IUBj8lzevFuJNXI8/rM
Mmle/DGmJEEyKqY8BPLh4xcZbwHkT6rqNp1MwOe8nejdJB8ypct1K33BuiB2HICbQgIma24G
rbz1Vt2LgrQYFtQ2lLuo5ZCNCt/Zbpi5fkJ6eZvUkLHcAdDveDaLaduRm257+xfi9DbSLNDt
uBWq6pSTR9sqEuMt/hZyi9nQiY5WktYZemg5qN+x4fc+J+NuoQZslmFO0SAmW+Da5N6Ryy8U
tENkVBIFaoGA3WwU09CtODRbKT9k3KHHM4X4loBtRw7BXR13kc23xkY5m/saeDrT4/axhyYK
Qt+X07ZOsU7Bp40dHqCRqkZdO8lB2pQ72Vcur0JmX0CDoMP/Eh2CRTAaoEs8H8mXYyMl00+C
LUr5hchFL04xxiF7TuGvbmX9yjpDJxokqppGbO6RtCK5pBpZITgh5aPUlgE7oiRRi1wjEsT6
0uUDSUTuiJbEW3ZvwMIMg0DmExmakyk99xSi2QlQ2Z+yjBIBZxlBZiVcYJ9WNK+4j9TWuJvn
B2AsTJE5u7tKFrhMSdO8r+DpZ555NvrqT55Ty9us3cCqv0V8gSKMg0FFc41YTowUEsCXvAXI
ozaGzf1xUt6Vo8ufqQks2QJdornt7TcSN7ORYKuwWse3Ip2QCt9kYbXyN+KZ6goq6kiNCuIW
5HGT1IldoVqBPCDyfcX4ofyN+ESGbrjdznKVeAEq0fbzfTUfIBmJeT7QLXxCjdloKAcRmeI4
CwJzn0Xj2uBbIFK3s9CuTVk7tkxqp6VAWZlbxHXK34jr7KAsktOdJEpawAnvEWZRSmHj5emU
77vVCpIvF19jLbklWSTAb2Ff2S6tkXH1ZuUrjM2jYu27b7oVdhmerW/FI4cu3EnGb1NnooET
HrV/m6Op4e0jHTRiETa/iP7Br/xh+qOUxoajCedJrt0NKvQbbUQy3F10ECt+EFmDRv7zrqN4
JJSEDFbTytq5f22D6oWgJMt2MPIps+VDhbQWL0HrHonFZUW/lcXly1dYvDk8ErzYwHWvrDM0
rbIdNK1KjNaBb299VwKMtIxmbYJE35salN/9dxwkQKHHy2QOxzQlFJ7DbLRCynJmCkrAJnqm
w6EcE4mW0k9e3VbWIBIv2zevsAbjApRnY1YYUr0kyXQKfOJ6RqbDGpaPAFr3WXa0fMt9Nr1j
nfVHtETe2qhbXAu2ZD2s4AY51n2aofYe+18M/vyP/4NQ57IpLlwMaIRKnua+lhU3mveThime
LYdLB3IG3BlgrBZChbWrkRN/hrDqlKKqLfqvu8PSVbnhCGuIW9hvjCAfar99RtY4erBB0uMx
GGA6AY7AMxFywZg0NIkakdlMaqOB4ovFNrY0dewloXBTAM11JmIcSR/YbupYutvmj1oqNOfg
hegDrDSNgLJah6G12H0OgywjVg59I04kQbqBmV5ZZ2gWhRmJbhwYKrXB8vK2ikD58h2ocf0O
E4ARaJ7OqIpiRONLWCNjoS//HhJzN4eik9iYJMh0gKAZ0OgTNQOsO87emiGK0DF04ZJcIQsX
TmfTDLrtGL7fnktkOXaE/tsEmU67TkEJ1BNSSCAuJjvDjEKskQlJNqyokxdOiJPdOESKi73F
pfRC5KJreElqsuJfgeWfFBl2I4dX1hna+VhoK5Yk+wydk8R7c4COgpM/08CyiZblk6HYkpKV
Vp1cIuqulyCZp6U2Td9InMwlz9fekgJ9c1yWXsbu8NQS0bATJ7Xbx0APUtNyWx4RWcNtVYhK
68QkCGRPEBCGfwF/E4YJc7fUmtZxR0KCLibo0jZvBkcvROLZJqyizP0e4spnaO1jhD6y25It
yu6suPgaYlNovLtopkBT4eBnO7nMs6IUjWyMll/fdeAaBeO8HJnnxXHiuH5rnZDsvhGxWOpp
ZfsTyzzDD0ILs1n/KWSehUk3Hmazbl7sWU/5GpRnn6HbhZOgfTsCkc+eGh9owJIk79b5qURP
VwPKJEjKLcw+SVZytModM9bdden9Wn/P7n1kc6c+AreyQWufeEdKsufDG7jyWBQzHNwh/DG7
H0oLVHOE7mbWe3D3ZugOJO83Hf4Amer49LSC7izBaNNM4YJt96C1YtOL7cP62SgBWMapbZfm
+o0l3HpIB3w9Mb3QaTdVaFutLwSwupll2Sgzkdm3vdhnIbzPUP1vwDODVoutw/yk1Lhm3H9T
zKhogooaaBbeeuZfW8W2m1Qzw9h1XVa9J3hu3BQZzgZz7e0t1RAKQ0JdIxfXmOZnkWpoxuVn
mPUgs77hRW6AhMjmDfdhfZU1dqu2TlGH8YkRSmyo9HZZuwunJpuTKLFCh65tJ9hzXQ1p+g1D
LeU44ZpfLxX1hshCE2k6oesUGcp+5LH6QIEn24fzhchlONGdTPe/A0eCfYaiWs+JaCpSy1PY
3vp9jqrscFsRRw1864C779IvGZ8DDBxd/IGwL3K4kHqDHpMzwFBWQM+StzBlHaB4w8E4kszW
I4QhE69leWBSOIZBH+ZmVJFnZ0w9yNBMLmISWpADTmakZnhYIE1lnd1yW4g6wfUAL+styoio
eRziTS0JPZF5qn5mHaTLMNPC1tu/2CR3oRRQSCkx4678dyhgNnA4bbQUkRVp+3S+EMHsGU6c
hM+qQVQ3S76yLZn11Kzf3bodIOlPN8PsOakpNrCQHYG+djcv+znr4UjlJGi/U40ukWLLEypZ
b5TO9GQ6ED126Oo/f+X2ZO93nN2Htxe7YWkH42+sOG03rbHQCQuDTk+NM88nlzHm3EJWdcuU
ND0jjSPm8D6tzSCI4MXoChpcffLZFU5op2gbt+UMvBDx51gYn5gE7mZZf1Yktk78tfL4TiH+
MBPP9JDa+YyowVKdJii3p65QcguGZraYBC/UyLKbxANF9NBs+wv10PHcMFokKu3DJC4Kk7am
Op3Fe+DFpqtjao289bZhwyuqy63IZBtja1BfaY2/NmWQf6KmpM52pUQnmh9JZSRIdAP6hDnS
ZH7aV9ZP2jif5HAIjO81i5ApespJvABftQxO61fh4PQLbi8VxWt1h7J+OUXPXBSusO77qPlh
TQfZ4FgYQy0m5C3LplrdYAy/QUoqrkFSK96IJ68W38pqPh1QtgL1f4V91bqLbEzhtfkbdne/
q7U5/ecQt7DnBzp84C319lJRbuZSa2GVsqEduVu+fAeDe52YP0cdaBh6YeI+f2r8fk/jIGXY
v8arpxjUy6lDGKujaEkKeBBXO3ksXYWyHFEoJ+03VRqQWTqNpGYFh0V/Q5vnJUo/CJ+j27ON
AS5tfG74hh6yrqN741YlSX4WbWXpTgzHewu2GV6KdppswtFyjfJLH0VbdR9dSYW1uGuhh6hQ
D1NWYHJD0fKX5L64+kMu+ENoCqkmtVcNh/NRCddbMyKFFE0TMuYX00lBG9VBNbpDaIWxOWXI
UQ0mGYikzaDKajW2qCb6tZiU6HxJ7f/rr/DLOVO1/15Mqqv/+k+MpMGd8X9SZtUIauwhf2Qx
a+rIKb0mNF7j0cfVqPRQekt6RgatWY5g5kLN/4R3nlH2Ensi2tfM2WCbSxQBUr0IZliQaqW3
E3rK5l95FvQKUUaMEniGwpYQ9Sf88E0y9O1Cdc2bfNory7cX1GNwqn3A2NpPFTp50O6hWegs
nJZ555f3IfLzO7/pTVc/5m1v6kevaZ0ii0EJ5x6KBUxEiBNMmMeqBBfkC8UCdpRiqEN72pRj
ZJidHkeLY0knVVbuW2WHfPkRsMAZqh2tNHPSJGppi/bW72Pb7E2N6wjDK0bVZIhAAxrl5f1v
JWF/DI1G77tBLRpa53yKkAX165IOuXRGjqRdvShMDMdqaR4v9JAVnR5kC8pqYYV7uGY4W9mL
FRrI7XRa5oFh22kQJHI0WX7xradEvnzNOgXvl1D2MshHd/Na/suKpq4c7/WK8azpPgBWaetI
KDHIcerHp5XURBFF7HwmLAoNFxzFnK1Up0jftzQc5zLMMh+gaU9j4bF7Mn23/AUCyNQX4T4H
Bzet5PLRI1SnbOxJPHqoHDc8D2OWki2H+aW47tCPGa2MWlYMPDt+5rsH+aH3llzdwPCVfY4q
RaRb+3qwRYUfX4532k2KxtgC2klSe42Bd4AttgSOU7lfq6HrVGhMBxX9LNC3t8IrSS8jHc8j
qRAjTDDQKGx5WU2UoLu2RznWS+NF5sTjiNazqRDMyrSRSN2SRpgWHTj809OuU1Ah70baZ3iQ
ES7T7CtUxddCf6u/UDLKZnAWUmU9pS1xY2hdVwYYSHxIwBjlSbBYJI4SvXtKTkvpJd5xc2bh
xdAWfgZmtvHOVXeATbxwHjnMOY1sY1+ufY0TaiQLGkn3o3+OYJLtx3pkp3SEN5hRx5fBk0Zk
rKb1rNNIZ6gPNTFHSDdW5ijUpsUhYk6WiisIcj010IWTOxZ+uYyAGOmcwMSfwGMCl0Pdn1M6
JScR/24Qu9HKIEP4Y8PQOAi3+LYNBmwou0IXbkGcxT/nBOj25jttK0lh74UyYKXlsAzTIfQ2
+Vh7c5YT0bGFABXsUFLE6B0NQ/Azz3JDMti2HVX5NcQ+YvI3Ir07+ojpQRx6vtkiiY7GvUhM
lgNs8n23an35cvE1mD+LbzsrgX7TtGsTEvlgOcOPSC43Zu/wkwFFydoJ0MzODR7rQ+0V06Rm
EWyy44ZdeCH2iosxoQ588DLLGWgk4frBQbBvb3m4TjucoZbWsfwkgS9Fpsbp/U6H2Cu9fJzf
lAP0I21NUT6+yZKPRtUcvnBW/TUsCLCW0yEmURR9YM+KzJVJMYPpcncvw8tTaCzdtgwn0VuW
tutSCxTPbvTNPrhGSXSdRWN5URzZFstf2yCKuta4o8bqPnM8eJQP3myYbj+cIxeC7FQ+Qa2P
v1AbUzACT/2jUA8uwNjlEh2BqL6GD16b8sngFFAhoY7yCwUFiQ4PqW4pDbiWN3FvBenZcRg7
adtUMNLEtVOSmktzsfVECfY21+24Ldc8yoWsdxq8snDmoXllwV2GtbtQEAGIbgmHFDYhskNA
ZGp9OsFAO5rzsjFP/lDtibp7w8Wszs0i9IVoTyNwYiNqD0GxsiRyTda2b8kdsjrcCp/ky1fg
U8NPEpMxTNV9kl85Z6jK9pIQjRlZU5kdpZW0jGZtwlnZmxrUo7LJlSrpGPXIJ49hvh3Chjj/
eAnJeqIbfhaS4SMQw4psx8HQQklwyKvbyhqynFlhDY6sz+dPy1Cs6LRL8V3b8azssIIYpXUK
/jQhQU9oPymk5pGTDGhpNoc/tW7OuJ4NDpWDGB8XR1HY8jO2oeQLkYOOAy2JHnsys7cX24VT
Tnby18nBMxQ4Y6BBhEqdNmZQ8DOcjBokBz9zxFX0LzP4jHEIqNJ1gdPWn4SlWDwoA8xN9BTI
oGVpmpZv6ikrjd9bVwbIo2QxYXaHNQLxLHhdjwI/9CKymwWhr3IOBGWntBxB7nVtLUud+uW3
z182QPNmYjHa2tYQPef+FQGaE1bvcsS3PVeW4SFjg7n5ti1cXp4IzOVvxH3s8Fw5emDqcFPJ
pLZ1Xw/jQNav8n236lf5cvE1BM8VsRMiLlMkpf0pDnOYzkoYPxV9u3T9UZrIAw1wpHwyDtm7
Nm3Kdo3S2kRbig+hRp7XFDkGmyqpDtVYXmSmqNXf4n18IRrLi13PTdqjQj3g19RoDTnfEZ7J
l6+wT4NuJVG/EbmfofTbdNPA9tt1FipyS1pGszZBmO1NDZi+k2o2G5CDgFKsyMkE2Ma9TIuW
4+MJL2PQkA06qyaPJ9diTho4oR+RgBEEHXpMBp4VHBQnURI7Z4P1ZupBnrutdAArSnxkW9Gn
p9XWgnqrYX0D6c+J4bHUOI4NS97s9rF4IRLRti0vRsrg5sU+Cwx/hppr1FtbVtCuJ25v/Vmp
ce1cOVcmpYmM2Wznx3G1IQp2JNTu6LqeWO0RFG5gZ7HnL6K6+9AhMuzUJhvpyVG7HYapgf2W
OV8PIsi/w1okK62x8bIzIPmpGCLls6tokIHPVhnAxmT/7Sn91+8UwOiiPJDGWlAq6W05gcuf
+Z+bj1r5qPWFwLjIcOLlsZcf2IRyFA9qt5NqCJODZz4xnhZrJk0qtKgrK80u06N20x2Kdm3D
T8yQDRkVFHn7gL8Q2e4aVoI2wYnM4e3F7nOK98Z36/wzZygoNxxM4DTZdNgNW39WapB/5hMr
W+LDd4FykPmDoTnAtGQVnhzXepgjozsrmbq+7cGvR07MvfGekgw8i3fGDjBYGBFE+RRYceZl
mSsnu8hsvdVloLRGSc7/QqVhrU1f7ngdQ8X3FLzg0vWkpj+GrQVG1HKmtOXDCxGGThagjZXb
YoP2Ys96/NcJwzOUXXuuk9mhQ0f82QjD93nvK7VVWBS/YK7QbFINWH0nEp4HQ+krPov35CLS
Ru+3UNdPwDemhTGpC6N6xWXEI3rnEZGugbBlsEfoQvD5KC1HkobUzm2EKlYu6fioTuo1PZ3f
8KYUlGKCqqUSyLK/nC2QT6dVr2T576xMmCVICPdAUskvc2DVOugHvyoMJ54BgfvNHoo6IZ2z
lPBDJFFgoh3A7kR8pU4J3PaEe6afOOgqqXCeZDqJnnD5G5EhOjzhnpm4pu5uybhg8ky+r9oT
Bad3jPoyXgFNTmrm/K5bP1EPKOqZS6eWNpJNkV/dHtbbBKdXIHUXxG/TlHrfxZ7SCmVNLK5Q
/mYLTS3LdBMjbClE17cSK7JkN5983+NAhTovNqm0Byo1FccVYxI4OUEbibiaaoUvqQQeQnKD
d+BQ6wlI0UpQsbyZy18IYLDTzErBDZsX+ywAwxlqs9GZDH1BrT1inKeLFVBtdlJMe5NyzOqp
IIU+Nn0o4ho7oPxvdvpKbHQUBnVW4JSv+15okzh5AXaUhZS3yN7HUyyABFlsiuJYUDjU2YLr
GVhERT5Bmw/UQSMMSnpmGV9V0SGm6Ztobq2CcxEADFlXJr5XwkvL34gv3aGX7SA19Mhv6RBE
WaMsYMRbsoJ83606RL5cfA2Bdu9qsINaIszoqMvGO+aSWU4X+RS9bDAZmuIVIwlRW+VtAT4v
RCVY6PUTmN73ECw5R5m3l+gRMqJ3V5DC2ZJdLitM3UhOSYlwy+hnoHUWJ4ZQuPhEyOeSJo0V
/YulFhAQ58kNRSO1XD2zT6Ah0bg68ReeqhUacXKcxVBElreD9jxbAGAXJhK2XGk5Sx3A5BgK
XWZIZt9N+MOoddC2vBXh6XT5yLJVNCDkb0Tidwh/iidlGRuPKbhVzDACEGBBh5MK/25/Um1V
iMeF2QmXE3ZaLuuSjdo6m8J6hgEyZcNLWY4Ysi/ui+FfOys1ZH1B/7oZEDvKBY4WRV2cSGkf
HJ3DqFUlLH2zZR/0QHeh91UyUzF9yTPp0K48Uf5myxOd0Igsg9XOCTvvxLZuGBatfLnz8n1F
XpO/YU+s06EZUXkYcPx59oij8PAGhfRvL34ucmqpZl6AG0H/cR0qZDKhmx+4CwZJNU1uhSQZ
8Z7iu9bpKRtuNyt7X1Gv2b4J+8X1K8t9I31Dr8jWwvyODYhA+Zadpe0k0c6DKpNoC/Hq3ogd
B1VP4zQOky2whQmynZ5YX0xLrBunojnsFbn863oEBWqYqe2hEjNT0Kv7vFsXNQw/zDBW8kRP
FKjxr9L6wQxdrS7Fli2cj6Zfy7HKL5eNWfjv/pf0o27msyNUwjqGioP3SOTGEMMUoRcV4LTP
E5fk7hYAmoY2ikU7Rs+zUNGfsWnsWGgXt8gWvx8hB/WCLC/KAlgycpf5sCL4UdaemO22SIef
65VTtnah71D3M9XGFWrxb6gYriI1N0DPSFrMFKWJwoq0IdqTlDRqhrIcpo2vWIGFTBuTVzP9
CTdUeknlYwUiqPywdarWEHslbINmn+MKzvfpT9p99UCV/T/xfGiZkZhTs92ZpvuoOqiwQGsi
Ffh5ooOjQq5V8UUl03BfqPxYkdbUJIH3Um2ozAMXDyVawT3k1C6UqMyzeMh5v7hs1lUE1z64
ju2mmR+p+D6fFaHnYyRPHJGnS9Bxha+pkJA1hKxGPxGVeXsjSMZW1pO03d0Mbeu2n1iBinvq
RHSmZrusYkR6W2UJQgGJvByp/FiNs3MWSLqDhULZjqxXFGiM3r3EzuM671toX6+ihqhRZOK1
sxnPqYa+LM4iFrVva3+JyN385ARpjOkJT8hP0ksqs1F5RNm4nH7QwS6oyVGqbHJ11/L04xuQ
9SnuwOCukeppaJwK9S9B4fW/wreiAoz12Dd9izmeBJP2aMemgwboG4k2HqwxvPjE2I8SDG3c
34iuqb6kwRoIw4ExJPnf68b8l0nTOp/kZNPmletWyCbWvH/Z9q7GyI3CkI5C93nF/KbM4Z2e
xQXXND7HgqWXVD6v3K+q8ltFqd9K6UD3inHRK2/LHnCONGnnJ9Qv5lNWy53fkoogiMPCf9Lb
rCG35aeGF7Sbx+iOmbnMqbmnk0adv6SXVCZ3davyOzVSkx4VrDhmCq6yMoMEHz6yQlIOqpCN
INNbdvl0E9xOzNhwo+jkjoW1B1qFcKuA/ZgEF7KZlnQXwnPMCm1x+RXblv7ajpnd1DYzDz3c
WN7udyVNAKdVtmkn/u6W4GB0lO7CI+BoP5RXxdVP+AtqEqpRf/ojHN+/N2Beep1uYhshRln7
T8na6/WU1PGVyv3lQ8+sFsqoW9OPtXvBmE5nuKgD/N7OMusvuJfxfa1iXHhxZAZZO738lCjJ
jQLXSc5gNF7/62f4XZWgohkYGOx+Kn9BB1Q0kKYX2WeQddc26u9IY3ZKFAVBYVtoiuP4Z6SN
boVJHLLuGqfVA9cf3ycq8R0rwQxjXlR32hdaCwPIAF+3h9oPBO576HmhfYGh8SPphxklXALP
/4bJOXejom+ZCjuNeisbUPD7k5AjudH8Glyqpn/7LCHvhjWuK7QRq/8jStZqlqmiC0oWpmRr
FmBAvsYu4THbNtDMfaWHw7O3mbBeiYcOojI5Jsn3Ri1cwK4MwFPHPwynIV2/MIqauA0RfEll
Fb2G1B7UJ0SnjwluPLMSSGGFIDWU6ZTGtb9QwHcSxbtxDfK5PCcOTh8KXrtQ6SXXsMWqjSIg
V5UbqJ3eJQReKy1BXerMAecaayDE0aX0BmvoHJiwBOPTO7jW0nl5ADoQsFbjRJgBDW8tPTs4
X3NINF1hmXaSZZFuqeQI1m6DJt9CSJGSv2GJIOo+hh+kt1Tmp1LlZy0uumY2FAaX1DYUE+r5
DTxgmu/amGhSW1mmjRDgfDL9kccaGsfCtOiriCLXwcDIMH7C8KrSqAtxKMciWt7w0qVE3e4T
4vox7Kv2lPejmRIK7k/J3flQoJO9cNRVtspJowRJgkdPvKq5v8MQME3bjFydvMOnwJYdT/Rs
O9E97/SC7PpD+rsKvLZD0/GDkyUMKfDNWeC1kZimY64MTk7QKhsGz/N1lh8X+C0ydKB4RUwN
FbU5HAFQSANSVU4xBaVdR39i7LdqOwB6rPP+N0CXtylRELaenkBFWU+4xiUcacbd8mFJDGzQ
enBBK6WAkrSuVBzvlu+HVhg9YaYMiYQd0fuOuD1AorWl1KtJhlNbkkbVgZbEZco463vD7Xrm
pnbImjqfQsEqaJflQdmI23HZAm1JQIYdKDX0jnGqkeuyFldPtNgnQ+8/nga8m2YSBHF2Knym
wD4sqlMuh9WRJZcD2s5hfnQxVNPeqoufpCPfjeId1ID4WLMMSDEeAc0iDYqEnjzITO7MxppV
eWHXNrJYaVSc3JxdFKTyN6LF2oGgrdjPLDtsWQkmgsUebz65JJF83y1PPKRY4nqlLuILr2zA
EAUVEO7EyOpG9zh52zuNt53WtN7ycRxHjwDVFJ6YYaS4Q2CAE1bwNMjfsH2rP1qerOsP1YP2
Q9OBEAUNP6oQxIBd5oXtGVOdBJFfQtxk+Rvx9TrYyjWRTIOKxJMTZK2HiYXtl+pK61eQNWRC
13mSNH55OY2iTiKlrPSH+7J3r3BWdZQqpIFSiEEmnRpRl3u+fonSWyqjHmHKm8oNWn6mNW+D
qR61nCMaUkDh4b5CvBvVazQdlVzFJAvRPgafD+nf0rPXye84crK0JZyOxrenI3GTMiWtcc0G
qdFX4GQwcK+YjBAZq660CE1yiJrINReSoRGIkB7dTV7bMyPLC1TCoc+Lg5tBMgO53fRBBB6g
uwGii4iDcfZEmj66Fk3ng3xGSfuL4Vl1H/jXvWpI7eJUbHiM+IOF24YhZ2VjMgGFc8/Oo8BS
wtGF5UeHlaVCoQmi2kE1It907FAFWZ6Kk8IxiXNsVjW6fIdtxJw8NgqNFtPePO0epZrFBPEF
okvZR+iunMm81H1iPOhudGtTKVA71Tqlc72G41cjVO1tXPPD/WUR2KZPw+WGpXSIPk7Ku3J0
+XOFJmAk/9m2SEvoJrSbOK5pKVW9PC9Ck/iQ1ncQpYl518ihHeSPEYeOj5mqJwJjHfDPQNdS
1CurBHIP277r32naBxt7iVrCHuT3zaMKItajDOWQrnU+kqC9qxNnSj1vDyNJN0AjQScI/LVo
GPU81NFMxBL14AdMkJQYu/vg2jFCA6lSl599l6lYqHxUkYciKLTLZpMwkJsEf381gQIhqNtH
cjw+wnQZPHBCwx6XLRObfg5sRKcC8eDpdzEN+pTHRpF4UJ7F5E6uTzxIkuVAEotxIniJHkqZ
xb5IvQJT1/sIjPTnvC/5uJj0oJfRa0oFYlkOxs4GiUoIYV+2400E1p+uRayAhDaO2iehmzSp
PmqespL/C1ZqyrwV+MOIUZiUZO1Qgm2hZQAreVZx1sjrF+14socU+WPVSF7zUzVE0QB6Se4A
UkyKQfENJbR1uhEDGb1yCoyn/TAtCq03yOE61Owr90cVLjEc0wospSk7MpXUTPYuRahjxILT
drmi46/v+w6FrZc7tv6JHYNphGYgdZ8R9V4kG9xrKqmVmBanh5BSCqpTfnGRiPI3IhN2ENGL
DcCJlRHAtQElEVG+75YnCkSsO4R8kL1rnpJ3zfLCMIbL8dgEWXm9btmDHhKNr+tTIz0vf11I
Twa7pbRaf/+0WswnM9NYqer/sJ1Yv1RJTK4ROqv2z1ED/3Je7VJRNYFvzHm+pXq5xbhoahAA
bKDklHGz0DP5AL1tYa/nReIa7BRHTK1lPUIACIqf4LUdokUReRLJQ5sj1XYmtlmo5oO+hv7U
cFwANKjoAg/BRcN8ulMr8XE3ljYw9hzJAypO9JOwwq+TCu1aMH1e4V1NtF01TKVcy5O865Fk
YGdrNUgZqUeWlSRu4Mcq3q4TrVXakO9NCCrR2I3DNHOVYnjPisZPLwVJ2cCz2f7f/xjM/uUS
/5NYp1vu6BmiAl72ZHJH4RVdM0792FQJXZyEPRRe0cSkGyNRyk09ySt+ELEsm/KlhGYd046d
OHqyzWd8+25hFS8wFE+ZXLhg5hNqQk2mtuyaUeup5PppaBkqfpaTbA1bo8RCyjKcOUjk2Oma
3ypa3tSeqsar8PDlGk98XIJaiJIMUdvij3xI/dj49GTp3buFiBUYJkzc75PG3NknrfIgKtMU
b8BTamSHHlUkoYmRDVRljDFpp8AegOB1DjEh3LbvspvEhhtiZlSmUozx/NiYEqBBhOPSmOWQ
jdj4jboVSZ2822kZM4+d9ALddPb00HTR7+4JDfwWZlrDjKt27zG7Zxg6+tSSnYXEb+pjACOM
BctHUDRwyK3KYta5pBrRzABwvAKhTT3S09R6Mq1+gFwOuo6ybIeu2TQ1Oa39DCqvkjjv3Zdo
58g14cVsMpdVQzc/W2mYZYnzPfIzU38U45e4SY2y1xek6UZTPn9qqiHjg4lhLm+Z4wBgAi2O
EKuuszxoyJI2H0sP66aprgdObPoqtYbPTRa3IJMaMdc46IhDyZlfDCl2QxtVJ1nIKO2X8H+i
RBrXPWp9OBk06kiqkn+hx9QOU6l94OmobOhIueJ6mwtA1ppyPhvPZxq4B11tKP1tgE7cRI27
YlRM4AwUsm8U2Akd6DDySGng1ukWKr3nGrZYVTmD6q7sqfxUTfDNMH+V+QF71MytIfiVrpFB
W1eZs78CTUlP7T6ndpCEnrNt0CbrNr4PYTuiF8hGNoPAaSWhd2Z/7fPE7UmMu7jx0LHSSJ34
yWIZhxh+PHhcqGQpWNH/Z+7adhOGYeivTP2ClkthSEWCAXuahMR+gEuBakxBEDRtX79jp4Wm
BGQ6pvJWmpgmTuL4OHbcaoe1sDLN2Zqo4pUFOSMhlK4rc0hxAfSVwnxBI6y/hNVhPgl3zgVW
tjVJqGW8ZbhndGXSfC2g50B3WYKC6QziA2KLDyPNieQNr5Dxo5sa+ayeuOVgs4bLjgeiW1X/
RSpZTRSvgKMRSEIuH6sSsJFwpdUIN5uDPo7/+35laqEDs1mtxmTLfBBMXqd0sHlXMQlM9nqX
fMTpzDSvdDcH/Ir/R6T6inqYLTcEY8AocjNGbAwhY6AbVQXGC90V+svk4CFiIjSQB00gqCx3
hIhShJieDMhlBR2UIjCtMg2mHMv/AhXd07c0fiQF1uqEW1jAnEdBd3f3rMmv6Wur02qiWCYD
5EgIZdK4iB3fzwz8TuiIlQRMZjXDzeL6cOgHMgf+B9r2DNi0undheGRcZul9K2p9YmAHE4rI
D9jvPSPp16hwM0u9FQwGPXa6ODm+PRCj72kKwcVvFmK1hi+bnbg2RI+PW3DkwYw0CvtNOn1j
Bk1QTm/T9Fm0ereryQ9KvyIvaLYbZMTrrPGMy3f4We0SmF4ibwMjxB4RTDGlIyOqtyl9R6st
Krd9rovgjDWqBg1DOlNaq89T8SZe5kpNzEzktWpMu1QK4R7Hn6uD5p+++dxcbeDe29lj5sam
DrdioeavuwSxgR2ki4zHiZ6j6cjVmKZMM9xgHXimFt/8AJIDGZO6vwAAAP//AwBQSwMEFAAG
AAgAAAAhACFaooQhBwAA2x0AABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9vG0UUvyPx
HUZ7L7ETJ02iOlXs2A20aaPYLepxvDv2TjO7s5oZJ/ENtUckJERBHKjEjQMCKrUSl/JpAkVQ
pH4F3szsrnficZOUABU0h9Y7+3tv3vu9P/Nnr1w9Shg6IEJSnjaD+nu1AJE05BFNR83gdr97
aTVAUuE0woynpBlMiAyubrz7zhW8rmKSEATyqVzHzSBWKltfWJAhDGP5Hs9ICu+GXCRYwaMY
LUQCH4LehC0s1morCwmmaYBSnIDaW8MhDQnqa5XBRqG8w+AxVVIPhEz0tGriSBhstF/XCDmR
bSbQAWbNAOaJ+GGfHKkAMSwVvGgGNfMXLGxcWcDruRBTc2Qrcl3zl8vlAtH+oplTjAblpPVu
Y+3yVqnfAJiaxXU6nXanXuozAByG4Km1paqz0V2ttwqdFZD9Oau7XVuuNVx8Rf/SjM1rrVZr
eS23xSo1IPuzMYNfra00NhcdvAFZ/PIMvtHabLdXHLwBWfzKDL57eW2l4eINKGY03Z9B64B2
u7n2EjLkbNsLXwX4ai2HT1GQDWV26SmGPFXzci3B97joAkADGVY0RWqSkSEOIYvbmNGBoHoC
vE5w5Y0dCuXMkJ4LyVDQTDWDDzIMFTHV9/LZdy+fPUHH958e3//x+MGD4/s/WEWO1DZOR1Wp
F998+sejj9DvT75+8fBzP15W8b98//HPP33mB0L5TM15/sXjX58+fv7lJ799+9AD3xR4UIX3
aUIkukkO0R5PwDHDims5GYjzSfRjTKsSm+lI4hTrWTz6Oyp20DcnmGEPrkVcBu8IaB8+4LXx
PcfgXizGKo+349n1OHGAO5yzFhdeFq7ruSo098fpyD+5GFdxexgf+OZu49SJb2ecQd+kPpXt
mDhm7jKcKjwiKVFIv+P7hHj4ukupw+sODQWXfKjQXYpamHop6dOBk01ToW2aQFwmPgMh3g43
O3dQizOf11vkwEVCVWDmMb5PmEPjNTxWOPGp7OOEVQm/gVXsM7I3EWEV15EKIj0ijKNORKT0
ydwS4G8l6NehdfjDvsMmiYsUiu77dN7AnFeRW3y/HeMk82F7NI2r2PflPqQoRrtc+eA73K0Q
/QxxwOnccN+hxAn36d3gNh05Jk0TRL8ZC08srxHu5G9vwoaYmFYDTd3p1QlNX9W4E+jbueMX
17ihVT7/6pHH7je1ZW8CCb6a2T7RqOfhTrbnNhcRffO78xYep7sECmJ2iXrbnN825+A/35zn
1fPFt+RpF4YGrbdMdqNttt3J3F33kDLWUxNGbkiz8Zaw9kRdGNRy5sRJylNYFsNPXckwgYMb
CWxkkODqQ6riXowz2LTXA61kJHPVI4kyLuGwaIa9ujUeNv7KHjWX9SHEdg6J1Q6P7PCSHi7O
GqUaY9XIHGiLiZa0grNOtnQ5Vwq+vc5kdW3UmWerG9NMU3RmK13WFJtDOVBeugaDJZuwqUGw
FQKWV+DMr6eGww5mJNK82xgVYTFR+HtClHttHYlxRGyInOEKm3UTuyKFZvzT7tkcOR+bJWtA
2ulGmLSYnz9nJLlQMCUZBE9WE0urtcVSdNgM1pYXlwMU4qwZDOGYCz+TDIIm9TYQsxHcFYVK
2Kw9tRZNkU49XvNnVR1uLuYUjFPGmZBqC8vYxtC8ykPFUj2TtX9xuaGT7WIc8DSTs1mxtAop
8q9ZAaF2Q0uGQxKqarArI5o7+5h3Qj5WRPTi6BAN2FjsYQg/cKr9iaiE2wpT0PoBrtY02+aV
21vzTlO90DI4O45ZFuO8W+qrmaLiLNz0k9IG81QxD3zz2m6cO78ruuIvypVqGv/PXNHLAVwe
LEU6AiHc7AqMdKU0Ay5UzKELZTENuwLWfdM7IFvgehZeA/lwv2z+F+RA/29rzuowZQ1nQLVH
R0hQWE5ULAjZhbZksu8UZfV86bEqWa7IZFTFXJlZswfkgLC+7oErugcHKIZUN90kbwMGdzL/
3Oe8ggYjvUep1pvTycql09bAP71xscUMTp3YS+j8LfgvTSxX9+nqZ+WNeLFGVh3RL6a7pEZR
Fc7it7aWT/WaJpxlAa6stbZjzXi8uFwYB1Gc9RgGy/1MBldASP8D6x8VIbMfK/SC2ud70FsR
fHuw/CHI6ku6q0EG6QZpfw1g32MHbTJpVZbafOejWSsW6wveqJbzniBbW3aWeJ+T7HIT5U7n
1OJFkp0z7HBtx+ZSDZE9WaIwNCzOISYw5itX9UMUH9yDQG/Blf+Y2U9TMoMnUwfZrjDZNeDR
JP/JpF1wbdbpM4xGsnSPDBGNjorzR8mELSH7eaTYIhu0FtOJVgou+Q4NrmCO16J2tSyFF08X
LiXMzNCyS2Fzl+ZTAB/H8satj3aAt03Weq2Lq2CKpX+FsjMY76fMe/I5K2X2oPjKQL0GZero
1ZTlTAF5s4kHnzcFhqNXz/RfWHRsppuU3fgTAAD//wMAUEsDBAoAAAAAAAAAIQC3Ct/LlEkB
AJRJAQAXAAAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWf/2P/gABBKRklGAAEBAQBIAEgAAP/i
B7hJQ0NfUFJPRklMRQABAQAAB6hhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQALABoAC2Fj
c3BBUFBMAAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2Rlc2MAAAEIAAAAb2Rz
Y20AAAF4AAAFbGNwcnQAAAbkAAAAOHd0cHQAAAccAAAAFHJYWVoAAAcwAAAAFGdYWVoAAAdE
AAAAFGJYWVoAAAdYAAAAFHJUUkMAAAdsAAAADmNoYWQAAAd8AAAALGJUUkMAAAdsAAAADmdU
UkMAAAdsAAAADmRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAABRH
ZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABtbHVjAAAAAAAAAB4AAAAMc2tTSwAAACgAAAF4aHJIUgAAACgAAAGg
Y2FFUwAAACQAAAHIcHRCUgAAACYAAAHsdWtVQQAAACoAAAISZnJGVQAAACgAAAI8emhUVwAA
ABYAAAJkaXRJVAAAACgAAAJ6bmJOTwAAACYAAAKia29LUgAAABYAAALIY3NDWgAAACIAAALe
aGVJTAAAAB4AAAMAZGVERQAAACwAAAMeaHVIVQAAACgAAANKc3ZTRQAAACYAAAKiemhDTgAA
ABYAAANyamFKUAAAABoAAAOIcm9STwAAACQAAAOiZWxHUgAAACIAAAPGcHRQTwAAACYAAAPo
bmxOTAAAACgAAAQOZXNFUwAAACYAAAPodGhUSAAAACQAAAQ2dHJUUgAAACIAAARaZmlGSQAA
ACgAAAR8cGxQTAAAACwAAASkcnVSVQAAACIAAATQYXJFRwAAACYAAATyZW5VUwAAACYAAAUY
ZGFESwAAAC4AAAU+AFYBYQBlAG8AYgBlAGMAbgD9ACAAUgBHAEIAIABwAHIAbwBmAGkAbABH
AGUAbgBlAHIAaQENAGsAaQAgAFIARwBCACAAcAByAG8AZgBpAGwAUABlAHIAZgBpAGwAIABS
AEcAQgAgAGcAZQBuAOgAcgBpAGMAUABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkAcgBp
AGMAbwQXBDAEMwQwBDsETAQ9BDgEOQAgBD8EQAQ+BEQEMAQ5BDsAIABSAEcAQgBQAHIAbwBm
AGkAbAAgAGcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEKQGnUoACAAUgBHAEIAIIJyX2ljz4/w
AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAGcAZQBuAGUAcgBpAGMAbwBHAGUAbgBlAHIAaQBz
AGsAIABSAEcAQgAtAHAAcgBvAGYAaQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABPAGIAZQBj
AG4A/QAgAFIARwBCACAAcAByAG8AZgBpAGwF5AXoBdUF5AXZBdwAIABSAEcAQgAgBdsF3AXc
BdkAQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBHAEIALQBQAHIAbwBmAGkAbADBAGwAdABh
AGwA4QBuAG8AcwAgAFIARwBCACAAcAByAG8AZgBpAGxmbpAaACAAUgBHAEIAIGPPj/Blh072
TgCCLAAgAFIARwBCACAw1zDtMNUwoTCkMOsAUAByAG8AZgBpAGwAIABSAEcAQgAgAGcAZQBu
AGUAcgBpAGMDkwO1A70DuQO6A8wAIAPAA8EDvwPGA68DuwAgAFIARwBCAFAAZQByAGYAaQBs
ACAAUgBHAEIAIABnAGUAbgDpAHIAaQBjAG8AQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBw
AHIAbwBmAGkAZQBsDkIOGw4jDkQOHw4lDkwAIABSAEcAQgAgDhcOMQ5IDicORA4bAEcAZQBu
AGUAbAAgAFIARwBCACAAUAByAG8AZgBpAGwAaQBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBw
AHIAbwBmAGkAaQBsAGkAVQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAAcAByAG8AZgBpAGwAIABS
AEcAQgQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAAUgBHAEIGRQZEBkEAIAYqBjkGMQZK
BkEAIABSAEcAQgAgBicGRAY5BicGRQBHAGUAbgBlAHIAaQBjACAAUgBHAEIAIABQAHIAbwBm
AGkAbABlAEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBpAHYAZQBsAHMAZXRl
eHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUgSW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4A
WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAAAAAAAABadQAA
rHMAABc0WFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAc2YzMgAAAAAAAQxC
AAAF3v//8yYAAAeSAAD9kf//+6L///2jAAAD3AAAwGz/4QB0RXhpZgAATU0AKgAAAAgABAEa
AAUAAAABAAAAPgEbAAUAAAABAAAARgEoAAMAAAABAAIAAIdpAAQAAAABAAAATgAAAAAAAABI
AAAAAQAAAEgAAAABAAKgAgAEAAAAAQAAAgCgAwAEAAAAAQAAAYsAAAAA/9sAQwABAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEB/9sAQwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEB/8AAEQgBiwIAAwERAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAA
AAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci
cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldY
WVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC
w8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEA
AAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXET
IjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZX
WFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5
usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A/v4o
AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK
ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC
gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA
oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA
KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA
CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg
AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK
ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC
gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA
oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA
KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA
CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg
AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgDl/HGu6p4X8FeMPE2h+HpfFut
+HfC/iDXdH8KQanY6LN4m1TSNJu9Q0/w9DrGpldN0mXWru3h02PU9QZbGxe5F1dkQRSGgD82
fht/wU68KaxofjrUfiF8P9d0yT4ceBNA8beL7rwxLYWaaFqviT4i/Er4dx/CfXPDXxL1LwH4
r0b4teHdU+GWvLr+gS2N3pV2Yhc+Hta1Wxu9Kn1EA7Dwp/wU4+B/iNdSvL3wp8SdC0T/AISD
UdM8Ka/c6b4eu9P8Y6NYa7+zt4dPiOyhtvEf9p6XA9/+078Np20/WNPtL6PTZNVuFWW7sTYM
AJ8Tf+Cjvw38HfB23+Omj6Pq6eBfDv7Rmj/A34nReMbFdF8TeHIJNPnvPEGoW/hu01G81XS9
ZsTLph0/R/GVt4eu7q3uBf3dpZaLfabrVwAbGo/8FK/2ftIk8QHVND+LVhYeEfFEHgnxZ4gu
fBFuvhbw54vP9pWOo+HNT8VLrreH/wC1dG8XafB4Bvbe01K7+2+L9a0SDQG1rRr461EAfang
LxpH498Ow+IY/Dfivwn5tzc2r6L400qHR9etpbVwkhns7e91CDymYnyZobuaKYKXjdkKswB2
dABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA
BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAHnPxh8S+B
fBvwj+KfjD4oWdvqHw08KfDnxv4l+Ilhd6ZFrVpfeBdC8M6nqni2zutHnV4NWt7nQLXUIZtM
mVor+N2tZFZJWBAPy60747/8E8PtOreEPjp+zt4H+EPiXwhoHhvV10DxJ8I9P+IVp/wr3xPo
Gn/Hi08TT6/4F8L+JbDS9I0FtT1XxB43m8QyafZeGvEOj+K9Xk1G/wBKz4h1AA7DXPjD/wAE
lbe4ksdS0X4E6kfDfiWa3aTS/gjf+IrHR9Y8B6Lb+HJtcF/ofgTUbKx0jwv4f+GMdgvi4XEW
gWek/DYPBq32XwnDJaAH2X/wr/8AZPjubj4Mp4U+B02p2esw/Em5+FMWm+DbrXE1+y0WCys/
GMvgeNJdVl1O18Oiz0+w1ZtMeeHRFsrC1lWwS2hUA+EPB3xE/wCCfXxg03wbp3hbwDe/DrQP
F8X7OPxa0zwHonwe1Xw94h+MGnJo3iXxh8LdK8X/AA90PwPqfiPVvB/gG2+F9h4xuL6zDaDa
r4U0Q3OsyaPAbLUwD2b4L/8ABQj9kLVvh54R8UTa1onwj1H4m+Jr59Q8JppOq39ufiXr+p6B
P4utj4j0Dw6uheJ9Xste8deE4fHOu2Ek0WheIPGGjab4tm0nW782agHsml/tu/s8Xnwq+Enx
i1nxRrXgrwl8avCj+OPBcHjPwb4q0bX18JW0egyar4m8RaKmlXdz4b8MaD/wlHhwa54s1Y2/
hXTl13SLiXWzZ6lZXM4Bzlz/AMFFv2NbH7WuqfGix0Sa0v3sGtdf8J+PdAvLoQal4/0bUNU0
u01nwtY3Gs+HdH1f4VfEjTNb8TaVHe+H9IvvBmtWuoalbzRQLOATXn/BQ39jzTY9Wk1X4yWe
jHRdbuNAvYdb8J+PNFuZL2x1H4laTqtzplvqnhe0m1vRdG1L4OfFOy1nxDoqahoWmXPgTX4r
zUYnghFwAdB4F/bE+F/xC8b/ABq8PeHRquo+Evgx4E8AeOb74h6do/iTUtI8U2/jLxn8a/Ae
pWvhTTYPDw1HxFb+F/EXwR8QWU+ueGf+Eg0bV5boJp10fsFwXAOesf8Agod+x3qJDQfGS0S3
bwn/AMJoNRuvCPj+z0g6IfDN/wCMEiXWbrwrFpUniCbw/pOs3lt4SivH8VXM2i6vp9vo0mo6
fc2iAHEXv/BRH4b+HfB3wx+Ivjnwl4p8H+BfH3xa/ah+Fuua1dab4k1LUPACfsv3nxji8ReL
/EXhXTvCkvilNB1PT/gzr+saiLjSNPuPB1hdJca6DbWN7cxgHW+If+Ch/wCyjoWq6lp0fxR0
rWYPC2peNrXx7qWj2PiDUrXwjp3w/wDA/wAZfG3ijWs6dol7/wAJHZ6ZD8B/iVpVwnh1tQlG
oeGNXiiE0tmIbgA7TQ/21v2a/Evi3wV4E0T4g3V74v8AH/iHU/Cfh/w+3gj4gWepxeJdI1f4
n6Ff6L4jtr/wtayeD7+PVPgt8V7aKPxYNGW6XwHr9xbPNbQwTXAB5df/APBRL4HWHxa174dt
cXUnhbw/YaRc3nxU8jWofCUt4R+1K3jSy09p/D6DWYfAh/ZR8ew6jquhXeq6ZqV48lhp9wb3
TXgvAD0/R/21/wBm7xBJoq6P461LUI9e1DwFpNrfWvgH4iXGlWmrfFPxPpfhD4a6bresw+FZ
NJ8P3nj3Wtb0dvCUetXtgNd0bVNN8S6e0/hzULLVZwDnT/wUF/ZHNpFfQfFlL22n074f6lA9
h4O8e3sko+KumaZrXw600W9v4XkuF17xlper2N34e8PSRJreqbrq2s7Ca903Ura0AOO+LH/B
Sf8AZh+Hngr4t694a8aQfE7xl8J9F8bapd/DbwrZeJJPEGvT/D+18bXHii3024g8Oajbppmj
T/DjxtputeKmjl8M6Fqfh+6tNZ1OyeW0NwAfS37Qfxn079n34T+I/ixrHh/WvEeleG7rw5b6
lbaNBPKNLsvEHibSPDlz4p8QXNta6hPo/grwfFqzeKPHXiJNP1D/AIRvwhpOta69jdR6e8LA
HjFj+3v+zcmmaQ/iXxxb6P4lvrDwf9t8OaBYa78SoY/Evi+f4S6db+EfDXij4d6N4i8N/ELV
rHWfjp8JdOuz4H1DW4408e+HNRmEFheyTW4AzSv+Ch/7G+s6f4d1Sy+NukR2nivWND0Xw+NU
8OeNtCvNSn8S6L4H8Q6LqEema54a07U4/Dt7pXxK8CTjxRNZx+HYJPEun2t1qkN0LmGAA6Lx
n+3B+zF8PfFHjLwZ4y+It1oniTwFqB0jxJYS+A/iPdJFq6/8KseXSNIv7Dwjd6b4n1e3tfjb
8K9SudK8MXmsajb6V4y0/VJbZbG31OexAMu6/b3/AGWLOa3tJviFrB1O91O30PT9Eg+GfxUu
vEOqa/Nqtv4duvD+leHrbwVNrep69oXim8sfB/izR7GwuNQ8H+ML+y8LeKbfR9cuY7FgCrJ/
wUJ/Y7TT4NXj+NejXWlX2naNqWkanZaH4uvNP8QLryfDR9P0/wAO3tv4fkttd1tR8ZPhWupa
Fpct1q+iy+PPD8GsWdjPPPHbgFb4h/t5/AzwB4l07w5cape3Mlh4vtNC+J8up6N4p8K3Hww8
Mah8K/jv8UbDx/qGneIPDVpc+IvD89t+z3470Zk0Iz3Md3ZzzjzFt44LwA67xd+2t+zb4D8L
fDzxp4t8e3+j+G/irp2tav4F1E+AviLqP9saR4f1nw9oOravJb6R4T1C60vSLfUfFfh7ydW1
aGx03ULHVbTVtNu7zSpPttAHBXn/AAUW/ZW0oanqGs+P5tN8O2mieF9b0/Vn8K+OLnUdVTX5
PidHqVuPCdr4Wl8UadL4Sf4S+MYfE51DTITo95pV9p+pJZX1obeUAofCj/goZ8F/iZqXgXwj
LpnjfQ/iT42+K3ir4R/8ITb+D/Fmuf2DrXh6/wDjtbWHiDVNfj8Pafps3gvxDbfs7/EiSz8U
6Yt9pen6jo9/pOsT2Muk6vPZAHc6t+3j+yjo3iPW/CV38WbObxB4e8ZD4e6rYaV4Z8aa6YvG
0l/430W18MQ3OieHNQtLzWdR8T/Djxr4L0mxtJ5p9X8daG/gnTEu/FOoaRpWoAHI6r/wUS/Z
x0DRfEGoatq3ii61zwvqd1Z654N8K+C/Fni3xNp9l/w0Drn7N2k6rdWum6KsFvDq/wAQ/D+q
WsNpPcR3qrp+owRQ3V1axxXQBf179vX4IeA/it8W/hf8U7zVPh3/AMKw03w/rVt4p1TQvFep
aJ4o03VPhNqnxi1mKKfSvDNxb6L4i8N+EfDnivVbjwjf3kniPU9G8M6xrWm6fNbWF9FaAHda
N+2H8Ddf8XfFXwjpmseJbiT4L+AdZ+IvxD8Rf8IN4uXwpo2jeGfiD8W/hh4p05dZOkYu/EXh
7xh8EfiFYXei28D3Oow6Ut54eOtW8krwAGX4c/bo/ZY8WP4ci0L4pRXE3ijXLHw/p1vdeEvH
Wk3VnqGr+IfBXhPQX8RWur+GbC58J6d4m8SfEjwBovhfVvFEWkaZ4kvvGGhR6Ld3y3e9AC/4
v/bT/Zs8CXfiO08T/EOWxHhTWPEfh/Wr+38HeOtV0aPWvBOha/4o8fabY65pPhq+0fV7v4ee
G/C/iHXPiBFpF7fN4M0/SbyXxENPePyyAYNz+3z+yfa6vq2gS/FMnWtH8VjwQ+mp4K+IL3Gr
eKT4m8Z+DjpPhTb4UMXjOUeJvh/4t0cS+EpNatpL7TYbeKaSbVtGTUADMvv+Cin7Gthd3dm/
xq068ksNY1bRL2bR/C3jvXrK0uNCbUF1m/ub/RPC+oWVv4f00aNrst14onnTw4lvoGuXI1Vr
fS7uWMA6lf23v2YXku1HxNTy7TXPFfhx7z/hFPGx06fWPA3jnwJ8NPGFpZ6ivhtrG9Phvx38
SvBvhvV3tbiWO0vdUkkkYWmm6pc2YByXjf8Ab1+CXhn4a+BfjH4cudY8ffDDxd8ZrL4PX/in
w94f8WOdInm8PeItdv8AxJpWip4Zutb8aadpDaELC+t/DNhdut1NqFv9oGoaFqmnRAHRa3+3
Z+yv4e1CPStU+KUUWpXem+B9X0eyi8KeN7qfxNpvxJjuJfBN54RW38Ny/wDCWxeIBbSR2X/C
OnU2e7e2sCo1C9s7WcAw/Fv7eHwN+GPxj+KPwk+L+sH4Yp8O9I8HazZeN9ettbuPCXieLxT4
B8bfEW40waxZaDJpOg+JNM8PfDzxde2fhnU9VbW/E1no93c+H7O8lgntIwBr/wDBRX9jJUum
X44aLcSWGlTaxqFpY6B4x1LUbCG11m30G9sbzTNO8O3WoQ67Y6hdRfbfDjW39vW9iX1WTThp
cb3igHban+2Z+zho/h34ceLNR8f3FvoHxXXxk/gy+/4Qrx9N5sXw5vUsPiFceI7aDwvLd+B7
XwJcG4bxjeeNoPD9p4bt9N1e71ee1ttI1Ga2AObsv2/f2Rb/AEzStbi+MmlxaDrK+MjZa/e+
H/GOn6Cs3gDwf4h+IPiuyvdZvfD0Gm6bqOm+BfCniDxaum6hc219eaFYLf2VvcR3+mfbQDj4
v+Civ7Pum/En4keAfiBqGu/C6x8CaDofiHT/ABX488JeO/Dlh4itL7w3418S65YT2WteD9Nu
fDGv6JZfD/xPc2Hh/WpF1bxlpVida8JW2q2TAkA6bSf26fgn4y+JvwS+G3ww1Sb4jTfGDxP4
j8MX2uaLZa7aaZ8PbzQ/ht8U/iLbQeKri/0GOwttb1VPhJ4m0dPCl1qeneJrVhFrEmmSaVtn
kAPs+gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgDk/Ho8It4G8aL8QLWwvvAbeE
/EY8bWWq2D6rpl54ROj3g8SWuo6ZHBdSalYXGjfbYrywjtrl7y3eS3WCZpBGwB+L/gL9hf8A
ZG+Pdl8Ebv4NftB/E7xD8LPh78QfF8/xah8WeN/G8PxZ+M+n/EX4LeAJvh18DvGuueM7DQvE
138Grf4D33g2y0/wLfaGB4k+D+p6HqOm6w15qWqeJtYAPW/iv/wTz/Y7PgD4garrPxm+OPhP
4f29z+0/8TdQ03wR8XTqWneE/D3xL8Gz2Hxi8NfDzwx/wj/iiXSPB3hO2PiTxDoPg/wnpkk2
geJvFOuSeVffatJ02wAP0o0HxH8LNct9M8e6Pq/hC9k1jRLG/tPFLyaVbatd6ReLYWttLc3U
6W2oW6SyXunWcttcpbtBeXNvYTW8Nw6W9AH5s+Af2BP2PfB3xu0n4deE/jH+0Qfi98K9L+Dv
xY8P6D/wuTxTLqPgf4afD7xD8XvD3hjwLp/iS30qG5tPhf4l074neJvh94v+GM/iKZNW8AaX
4JsP7PsLLSdN1G5AOo+Hv/BLL9mT4Ha18PfFej/Ez49aZeeAvGPhDXdCm1T4xR6LYazqum6a
dC1XQPEEGiaL4dtvEOlfFtLDwJ/wtLQ7jP8AwsG8+FXwyF98nhtoL8A7u6/YR/ZbvPhp8CPh
Hf8AjLx3feF/gZ4s8Q2vgf8AtH4vXV/rPiLwprPia2u/EX7PHi/Ub6SeXxV8Fri7t/Bfha9+
FjRw20Wj+CfAfh8yRrpYW8APGfhH/wAEyvgZ4XsLXVfiL8Y/HnjD4vad+0P4k+K1r4/8N/FT
U/C154Zs7fx18VviEf2e/CQtLttU8P8Awak0H4u+OIfiH8OhqE0+uN4q8R6vNqGnW3/CPx6A
AdDYf8E2v2VbDV9G8YyfGv41XWrWHjLTfE3hvX/+F46dpF5p994b+Jvx/wDi74n8N6NrHhvS
dDvl8O+Lpv2kfiz4X+I2gR3siap4Av8ATdLZtPu9AsNYhAOw0v8A4J2/sy6Pp/7QXhPS/iF8
WrPSP2p9HvPB2reGoPjFKLbwTBonxE+I/wAXNPsPgXbG3N38Pz4E8Y/FLxhq+iaHostzo2iR
Xapc6NKn2t7oA8p0T/gk7+x5FbXGgW3xX+NeuaBfReJPDsXhO8+Mui6lp1u+sfCn4l/DpLSw
eLw6uuR6x4V8KfE7XvEnhm+/tWTXNI8RaR4c8VS3dzNo5a4ANr4s/safsfeFf2Y9C0L4o/G7
42P8I/hP45+Nfx7uvGrfF3VNf8ceKbL4hxeP739oHw94m13QtH1DxN8RPA3jDQvH/wARrDx7
ocFnqOuz6VrurXK6pb6ta2mp2YBv+OP+CaX7L/xG07xho9r8UfjR4W8O/Evxf8WviZD4a8C/
GO2tvDGhH4r/AAn+JHwf+J9j8ONC1PSde0vwv4P1O1+M/wAR/GWo2WhWyRw/ETxhPrlzeNaW
mjaPp4B4f8MP2HfA2p/tMfDz9sb4G/tffExvA/gH4p/GHQ/E+jeJNdF5pfjbxrq3xq+Ox+N3
gbWrTUdG0XRte0fUfiR461LSvA+paVDpc3hf+xLi90jUPHtjrmiy6KAeuXP/AATE/ZfvPHnj
D4kaD8Zvj94XupfF+veNNU0bwj8dksfC3gXUdaHx5knsPDNpLpV9d/DzQtK1X9oj4zeINH0r
Q9T0iDSfEXiS71WAi5tFKAE+kf8ABNb9kvQPCWt6HoPxW+MmhaVqXw38G6N4q1bw/wDHq48P
Saj4j8BfGEfFvwx+0XqraDHpujWnx00z4g6XLbWPxPs9P0+PStJtZPCei6dpmlWMNjbAHkvj
T/gm7+xB4H0jw94S8Z/HT9oqHSfF9r8Lf2bPC9g/xjvtUg0zwvFplzrFl8K3Ok+GLqPQ/BPx
U8O+D7OPxf8A8JOU0e8bw9puveHtS8MeMb+78QasAdd8Zv2Cf2FL7R/GPgnxh8X/AIoeDD4/
8Z/FP4tab4e8G/HPVrHxH4c0X4iaHd/D/wCMPgn4W+FtNi1TUdP+DfiXxB8Wv+Eo8eeCNM0T
U9Fv/HfijR77xAZtLt9E0i0APsDxx8B/h94s+AupfAa/+Pnxj8MWtx4wvtSi+K/hr41voHxt
0Txc/wAQ5PiTJZab4/8ALkaB7DUtTXQIfDN5pd3p0Hgqa18LTaU+miBKAPmPxv8A8E/P2J/g
/YeIviHf+NfHHwX8NfD7wt8KvHEcOkfEkWXh/wCGGifs4+IfhD4vn8b+FtA1fTNdbTL7xrJ+
z98FdI+L2uR2uoX/AI2034faFpyyWepaprdxrgB5R4U/ZJ/YK+Bmr/BPV7r9oH46aZ4v0fxT
+zvqHgmy8WfE7VdF8dWmjy/D8/Cr4e+CviL4d0jwp4d8SaL8Jfixp/wv0iPx1pnjvTtK8PeK
PF3w10U3+pWE2mXNjdAHqXjz/gn98GfFPxI/a7+OHxs+OPjDTbL4heIfB/xIs4/D/wARbLwl
4Y/Z98H+B/C/7O97q/iizttbtNV0rw74l8bX/wCzHoVx8QPHd2Y9P1X4eWaeHbOx0nyNe1nW
gDL+N3/BPj4GfGTVtd8c/C/4+eKPhpr3j74z/Cr4ta14o8G/FGNpfAWj2Hi638X+M4v2e7iz
mltPhhrnx08cQ6L4q8Za2qa3p/i3xZbW99Pp8zNDbqAZvxi/YE/YL8N215ouuePfiT8INE+M
48E/ATw7ongH4k6lpvhjwpNYaBpOn+IdF8O6euk6/pHg9fjP4O+AXhjwZ8Zda8UpJpfi61+H
OkWUt5pPimS4vtTAK/hz/gnN+xv4w+IXxW1n4efGb9o7wn4l0741atpPirQ/Dvxc1jw5D4X+
I9n4A+KOtw+GfBA8R+G5dWstJ8PeEv2sfGvi3w8vhHVLjTbW48UWupRahcS6VNFEAdXrf7Fn
7G/xB8E/Cf4FaR8dPiNaaf8As7eE/jV4S+0+AviloJ1OSW68efDHxF8ZNQ+LmvQeGdU0TT/G
Vp4+0jw3qF7p1wnhQabd634ittJ8PwaXHLa6OAfKfjT/AIJqfBf4zWT6l+zr+2r8Z/A2sfDP
4rasPE3iXX/Gkban4d8cfDTxV8bNQsL/AEhbrw34fstU8OaD47/aN8ZXetafeabqfhz4jaXc
eFNI0rxj4et7A6jqoB9n/CL9gH9mey8XWXjnwH8cfjJ458SfCv4s6Nq8l5ZfGjStQbwx49+H
Pjz9pLxVrngvXT4Q0bS7i3s9W1P9qf4weFviN4J1efZq/hi/0rw5qVrDHpQecA841/8AZC/Y
s+Ofij40eGdF+Ov7Qegwa98VfGHxL8SaR4U+IninQPhV4T+Kcur634K8TX/wn1nxP4Rvfh5p
fivwr8aL3xV44nTwJrd94k8I/HzUNQ127lstT0/SdN0sAn8bf8E9P2P/AAd4R+N/xH+Ivxq/
aC1/w54a+GPxuvfGGqXHxYuNd1D4PWvjj4r69+0V8Rfih4D0/wAGeGF17wn8QtK8ZWE+oaTf
aTaXf2W28J6bDFoF/rGmzXs4B7l42/YR/Zj+NHxC8YfE7xH4u+IHiSb4zfCTWfhndeFofitd
XXgi9Q/DfXfg3d/FPw1obi5nX4vaH8NPGHivwXH4+iv7u7sNO8Uasb21fUZba7tgDzrwf+yB
+yf8HvFXiL4T2vxv+Od144+MnwD/AGjfAPiI+Jfi7rPiK91fwTrXxBn+JvxM8XeKdZk0mTw/
/wALH8B+Lv2gdf1zwf4n8cvN4i02z+J3iqS0h1ixlvnsADX8G/8ABOb9lXwB4l8GeKZPiL8T
df1XwL4os/iy6eLvixp01l4q0rS9E+Eel+EtN8f2OnaVo0Hif4beDPF3wT+GvxQ8H2V8iWuk
/FHSJNfTUZ7bVb/SLkAyvid+xp+xp8Qvi98SPht4n+IXxV0nxx8Ur+4/aj1jwFoHxR8T6J4W
8LaJo+lw/Cn40XnhS2gtn8N+BfDPx30L4m3Hh/4/aLHeW2q/Eix8Y3msxyWk1rb6tpQB5v8A
GT9gL9i3QdfsvEXxM+Pfx58O6V8X/ife6MnhXTvilbWngTxBe/E74u+LvjZefD/U9L0DwZIN
P+G+q+JfGGr6PE2p31lp3h/Rbnw7BY+ItH8Q2Xh7XYQD0Lx1/wAEyv2V9a0vxLoV78XfjZ4L
0K+8SfGnxY2haP8AGuysdF8G2P7Reg/2X4o8K+FNK8QaRq9j4P8AAVt9j8R6/wCCfD+mwWtp
pWs694ovUlv7U2trpgAvin/glr+y5r9lc2/iL4pfHseIdX+Knin4x3vjV/jc9l411q68Z2/g
jTbXwnrGqrpkUXiP4ceHrv4a/DS98J+HtcsdTEWueBPDF7qWoazd2s32oAqeOv2SP2QvhV+z
a2keMPjt8YNO+H+l/tFxfGrXviovxLj8UfEPxN8VvF+jS/CfS9M8Ra9ZeGNbuNesLfw/4l0b
Rl0+30T+1Ps2haT4k8RanfX1vr+t6iAecXP/AASq/Yas9dtPDNx8e/jZZ6v4+0Sw8E3Pg6b9
ozT42+JPhn4T6H4A03xd4PuPDs+ml9U0u4ttBtNY+JGnaHbWc1nrPjbWPEEDeH9RbwndeHQD
6j+Kv7CH7MP7QHxb8V/Ezx3r3i/xHqXxK+FA8Mah8P7D4ktF8Pp7OHwv4r8AaB8YdB8I2al7
P4j+FvCXxC8aeG/CvxEsLzGlW/iq8ljil1O30a800A4TUf8Agnp+zFrdlqdr/wALq+Nou/HH
wl8CfC/xTq8Px9kv9T+IVz8JvFuneKbT4u+Jv7Ug1Ow8S/Gm4HgiTwn4n+INxYSz/wDCE2Wq
+GLSx0mzs0+wgHpGi/sYfs+eG7H4G2WqePvGniXQ/hmv7SbeG9J8aeOvD+o6N8T9M/a01HUr
/wCJGm+ObcaJYp4y0iKfxVLbeDoNNfThpNrd2VrPLqiunmgHiEP/AASx/Y8uJfhrPrvxH+NH
jeD4b/CzXPC9tZ+Nvj3qHiqx8ZfDDWtO+Kvh+a68cxaksx1zS9L8FfGzxz4D0PxFayaY2ieD
7/T9OsL+Gewt70gHNeBP+Cf37Hn7QXhzRPH1h8ef2jfjJ4d8W+E30trrx78X7/V9V8ZweCfh
v8Wv2bL/AMXa7N4m8MWnjifxDp5+JPjPVj4jW8sU0/4hWnhzX9C+wWOj6RYUAdppn/BPv9lP
4n6t8K/in4E/aE+OuratpHgbwtBonjb4f/tK3WqP8Um8HeEfH3w3b4teKtUs/wC1IfGPxE1j
wx8TNb8N+JfiLYva6g9hBouhWc2l6ZZHTbgA+7vCH7QXwW8f+M7vwB4I+JPhbxZ4os/Dll4s
a18P6lFq1hdaJfeIvGfhMTabrtl52hare2PiL4feL9M1nSNO1K61fQ5tHkfWLGxgubOW4AJv
iP8AHX4V/CjRvC3iDxt4oa20rxv4p/4QrwlNoGg+JfG9x4g8U/2J4j8Rto+maf4H0fxHqNxc
JonhHxLfyuLX7PDHo92ksyTBI3APNrz9tf8AZYso7e5b4zeGbzTrzwxB4utNc0e31zXvDl1p
F38MdX+NOnwW/iXRNJ1DQJvEWrfCTQdX+I+i+D49SbxdrXg6yfXtK0O80+SGaUA7bwX+0b8G
/iL4otfB/gnxdN4j1u70q21dTp/hjxg2jW0d54V8LeOLfTNT8UTaBF4Y0fxO/g/xt4T8TN4O
1bWLLxZHouvaffy6KlvKXUA3/C3xp+FvjPU/Gej+HfG2iX2o+APGzfDrxTbyXBsfsXjJfDPh
Dxg2jWc1+ttBrLjw/wCPPCV611osuoWSzaxFpz3K6nb3lnbgHPa3+0r8CvDnj7w78Mtb+J3h
bT/GPirStH1rQ7Ge+A0+6sfEmqa7onhXfr4U6Ba3ni7V/C3ijTfCenXWpw6h4lvfDeu22i21
7Lpd2sYB6rd+J/DWntepf+IdDsn0wwLqSXerWFs2ntdwT3Nqt6s1whtTc21rc3EAnEZmgt55
Y90cUjKAc5dfFHwHZ/Ejw78JJ/EVoPiH4r8IeKfHmg+HIo7q4nvPCngvUfCOk+I9XkureCWw
so7K+8d+FooIL+6tbrU11J5tLhvYdP1KSzAO/oAKACgAoAKACgAoAKACgAoAKAOS8feHofF/
gXxr4TudSOjW/ifwl4j8PT6wI4pjpUOtaPeabLqQhuHjglNily115c0kcUnlbZHVCzAA/Jf4
Vf8ABMP4KaXq/hWw8J/HW+8c6P8AADXtK0nVvBOrWdvr1loXjtvh5+zFruo3upTWXiaz1a08
SX178F/hT8TvC9r4ou/Emm+FPDnjTV/CWj6ZP4E1DwbY+FwDV03/AIJGeCNO0W10RfjZ4u+z
W/hp/D1osfhrRi3h6DTdN+OeleD9O8GahqGoal4l0jwrplr8eNdsPE+h634i8Val460Pwv4K
8N6p4ktNE0X7FOAQ/Ev/AIJlfs96F4P8R694z+LsnhjRLnxt8ONcm1DxNYaNY+AdLkuPBDfC
Lxx4Tu7DTtS8OahNoPx48W+Lbz4heKLB/FltIfixd+F9atZpoPD9rpt2AfQ/wT/YW8IfBT4s
/Ebxxa/EvW9asfiT4P8AiJ4MtfDS20PhbxZpmheN/i54j+MOosfif4b1Ww8ea3qPhfWfHOse
HPDGtPe2mreHPCKeF9PtL6LUdHfVtUAO9+Jv7IHhLx9J8FRZeMPE1pY/B3xJ4s1qPSfH2qaz
8b7LxZpPjjSZtJ8QWus3XxX1/wARa5/b+mq8V34E8XvrN3deBpxdQabYT6dfT2FAHxwP+CQf
w9XQvD+kj4wa1PeeGtNXS9J1a98DeFbuaxk0nwP8A/AfhnxRYW7TpFp/xBtdG+Aeiav4o8a2
bQ6l4t8UeINU1qSPSbez0jTbIAxdU/YF/Zw+EvjnTvHfxB/aP0TSY9A8W6/rQ8GeKW03SPB/
h7UPiTqXhbxj4an8O6TL4yi1bRNTt/FnwZ1fxba3Ov6r4l8PTaJH4y8PaJ4c8N+B/Duk6b4X
AIV/4JVfBT4e+ATqmufHJfDvwy8G/DTXrbxLr+l+D/Cnheyh8CXP7KPwy+AHjfUdSvm1HUPC
EWh67pPwi0f4wa/qWpeGdR1Cx8ZrJrPh/XNAUahc6kAe7fBH/gnppnw7+JHw2+M8vxqvPGut
+FfE/jjxy+o2PgnRNAg8Xw/EvwyumaholwlprGp6GnhYah9h8WaZPHo914rsNUsIP7G8XaZZ
ax4uh8UAHON/wSn+GMdx4K1LT/G1xpmt+Fr744arqOp2XgjQYYdd8QfFv4xRfGrQPGkujRXc
Wi3Hjj4Y+JNO0HR9C1fxZY+MtF13wlpC+H/EPhm7tJohaAHKWH/BJLw9aeDPHfg66+Nt/rkH
xH+Hvxg8A6/ceIvhd4R1yPQT8WdW8Y+IJ/Enw2tdSv7h/AOuabq3xB8WQ6lcadd3Z8U+H5NB
0TU3iOgrfXoBe1n/AIJHfDbWr74gXMvxP8RWFv440H4w6Pplno2gwaRbfDOf4oeN/wBonxhY
3Xw10+x1yHQdEsNDtf2lPGvhXW9C1TRNc03xh4f03RIZV0Wb+1ZNTAO/8T/8E1/DvjD4Jab8
HNa+KuqRR2fxQ/aU+JFzquieCPDmkaNN/wANS2PxX07x3pen+CluLnRtJvfCsPxe1+8+GPiK
GafUPCesado+pXUOuAatbaqAW/Dv/BN3wh4Z8OftSeGtO+IV3Ha/tSfCH4s/CfxRdL4L0KO+
sP8AhafxZ/aK+KTeLtQuFu8+L/EHh1f2iNV8K2U2ugteaR4V0WW5nSW4vY2AOU8Xf8EqPhX4
h1L4r6ho/iaHwp/wsuy8MLpcej+EpdP/AOFZ6rotn8HodUvPh/D4d8W+HNM0XTtT1n4I+DfH
On6XFpiz6V4+fWtZvtU1/SNXu/DrgFa8/wCCU3gS/wDEH9sXfxe8YT248Sazq81ufC3g21v9
Y0zxdrniTxN4v0rxNqGl2OnWmuXCat4jnsPh3fNpFrZfDHwdE3g3QtGudKuZGUA5+1/4JNaQ
mhJY6j8cbzV9fl0zxTol/wCJrv4T+DVuH0vxJpH7LFhGNKtUvs6LqWm3n7Kvhy+TU4Lyd72L
xj4rtLuFpZLO9hAG+JP+CQvw68SeHdX8O3nxV1q6iv8AT/FWi2d3q/gXwpq89vYav8Jf2kPh
boHiHUxI9umvfFLQm/aV8ReKdV+J155WteKtU8GeAYb22sk0SWe7APVP2j/+CbfhP9o7xZ48
8V678UPEWi3Hj7wVB4cvoE8OaHrb6bq1r8H/AIp/BSK602+1KQXkfgy68NfFrXvEOsfDqV5N
I1Tx/pXh7xU9/C9rqNjqgB1Hx8/4J/8Agz47/FH/AIWNqPiPStItL7R/gRpHiDwndfDbwr4l
03V4P2f/ABb8TfFXha2S71KSKa00fVj8UdU0/XtElhvrOeLQ/DVxaG0l06VboA4T4T/8EwPh
38NPBnxr8F6j8QvEfjdPjX8Brz4C6r4o1vTU/wCEs0bw9r/wy8H/AA58UvZXFzq+p+H7rTbt
vBWk+IfDmh3Hhtf+EZuHudK/tPV9KMEEABh69/wSr8AeJvC3irTdV8dWNt4u8Y+M77xNrXjH
w/8ACfwXoazaRrX7KNl+ydq3hQaDFLc2506w8PxX/wARfBEkl7JH4N+JN3BrMNlqdna3Gn6i
AZmu/wDBKPw3q/izVPEP/C476/0o+MLzxd4d8KeM/hj4P8b6PZPqfxC+JHxM1TTfFf8Aal1B
J49t7rxL8WfGciT6utrcQwtojM097Yalea0AdH8Pv+CWvw9+H/xE+GnjmP4meLfFdl8MNb0L
UdF8N+L7V7+3ktvCPg39m7wx4SvXvdL1vR93jbS9R/Zo8La5feL7yy1C31qPXtb0e78OJbw6
Vc2IBJ4t/wCCZHh3xB4y8R+L9L+K114fbU/iT8SvippWmR/Dnwre2o8SfEv42fs9fHzVNL8c
ut1Yn4j+D4PG3wBtrB/D+sR2Ut94U8XalpM2ppf6XpusAA4fVP8Agkb4L1DU/iHqMPxg1q1t
/iH410TxzfeGl8E6TB4S0668NeJb/V9E8J6bpWj61o17pfw1Oka/4h0nWvh/4e1bQfD+q6uv
hLxnFDp3iPws9zrQB9mfs1fstW37MVz410nwb4yS6+G/izxV4t8aWvgh/BmhabfaVr3i290a
/mmu/GVpM2teIoNJls9Zs9JTVIzcrpesW1rqF3qF1pEV/dAHzd8Sv+CbuoeP/g74r/Z5sv2i
/Efhj4K674r+L/irR/CsPw28Gaxreh3Hxu1j4ueIvFsM3jPUZf7cvZNF1v4u6lP4JvdNbw9P
pthoel6T4nHjK0u9cGqAG5pf/BODwpp5/ajJ+It4j/tVfCr4+/DHxtPpPgjw9o91at8ePiR8
TfiJd+KJJ47i5bxBqvg9vijq/h/QItdFzG+lWdt9ol3z3aygEHwn/wCCaPw++Fnxv8P/AByi
8Z3et6xput+IPFV34UHhuLw74H0fxXqus/EHVLLVfhb4Z8P65ZaX8N7SOD4leItO8Q6TJa+L
LfxShtr+5ksdUN5eXgBgXH/BMHw7O+iY+LeobfC3iH4ia9ot3N8PPCs+u6+vjH46fC39oDRd
L+LWtm4S4+K+neH/ABX8MYvDmqxa7FaHxb4D8R6zoN4dOv5ZNbuADkZf+CRvgdbE2dh8ZfF9
kseh/D+xEX9h276frmqeAPHfgrx9p8/jDT7bXLJb7w4l14Tu/DGn+F/B8/gP7P4I1bS/Dusa
v4iXwB8PLvwyAev/AAW/4JwfDr4O+P8AxP4hTxTL4v8AAfiT4ZfFb4TSfDfX/CWjNjwZ8X7r
4UXfiHQNW8bfaZ/E3iXQNEX4XR6F4N0fW5blPD/hDWv+EcW5uk0m2vZwDyPw5/wSF+F3h7w/
Fod18UvFfjZ38RfCbxPqF38RPC3hHxZHf6p8PNGttH8VSHTpbSztIU+LS+GvhpdeM7bbLYpP
8MfDDadZwv8AapJAB+i/8Ejfhvpv9mtq/wAR9Q8az6fqvwL1U3vjfwhZ+Jrm9j+D2gfCLRdV
8N3tpqevz+H5fB/ja4+C3hTVRo39hC98Mz3Ws2dnrGo6dd21tZgHqXif/gnnZavov7L9lp/x
X1aG7/Zr+FXwi+Fdw974Q0C/X4oaP8Fvih8Cvi54Zm1WW5nNx4VvdT8TfArTbLV7nS5r9P7I
8U63DbQxTRwTOAfL3w2/4I7W9h8I/hxo3i34r2/hv4h2Xw9+H/hb4haZ4P8AAfhrVfhkNR8I
+Cf2c9Ak1LwboeqpaPYeNRq/7OPhya4+LOLTxPr+k6/4qsptK0ZNR0yLQQDv7j/gkX4b1Sz8
YR678evFeo6v42l+KsereIbXwD4L0bU7Sy+LXwZ8AfB/X38PLpoitPC+tCH4WeCPEbah4ct9
L02aceKNBh0Kz0DX7Ky0EA98+EP/AAT/APDfwe8da/488M+OpNIv/Enwj8V/DTVNP8OeEra3
0qfV/F+r2/iG88dPY+NNc+INr/amj66+u3mh2McEUdzZeI7rQ/Gt5400TRfCdh4fAPn7Qf8A
gj58PrXQfHGleKPi5rnijVPF3gL4g+FNM8Tp4F8MaJrngnXviF4i8HeJtU8VeE7u3ububSI2
vPC19p99oGnS2Vrqnh7xb4l0OW9gtL+TcAevfFH/AIJp/Dr4n+Avgr4Du/EWnaNp3wa8PfED
SrCODwHp+uadfat8R/iT8M/ifruvabY+Ktb1y+8PSx678O5reyto9Z1KSHT/ABLfwG+f7JbF
gDyW4/4JIaRNqPhi8i/aC8TWlp4H07VLLwfodr8N/BNvoenRXvxJ0v4oWug6tp1u8EPifwFB
rvhzw7pl74L1v7TDqHhaHWfDEep2GiajpVl4dAPYv2c/+Cb/AIJ/Z8+J/hj4oR+PNS8c6l4Y
8L6loWnWOs+H4dItNHv7/V/iZcNe+E7PRNZttB8N6Nc6D8T9W0bVvDH9galZ3t9ZW2v2N3pF
zPeWswBQ+BP/AATR8G/Azx18JPGWnfEvWtZh+D1p4ZtfD+kx+EfDXhx7iPwP4G+NPwz8KWk2
p6NsltdHufB/xr1i98eaNZW0Np45+IGgaJ45m/smWTVtI1EA89X/AIJIfD8ajazp8VNX0200
ufULPQrnw54D8KeHfGGg+GdV8X/tJ+JtS0zSPGWnOt5Ya3fWX7SesaFeeJrOyt5ruDwd4Yu7
vTp3W6hkAPaNA/YHtPBvwi+CHw58EfEweFdf+CvxtHx1tvGVr4IXUrbxP4u/4V941+HUsmpe
F9a8WajDZvd6Z4xbVrx7PWDZy69psdzHpsNjeXOnUAeYWv8AwSe+F+ieCLj4VeF/id420z4X
t/Yvia18O6npmhazq8Hxb8OfsuXv7J2k/EKfxKsWmy3NlJ4Hk0nxXq3g1dOttPvfH+iQajZa
jpXh2+1LwxdAHvPwk/Yyu/hDp/j/AMHaF8aPE7fDH4oaZqdx4y8LW/hzRdO8RS+Oda+Enw9+
Emo+LdA8eRz3GqeHrWOy8ADxVpOg2djJLpvinxBqbtrl3olpo+i6eAfP/gj/AIJV+FPCcaSa
h8T7DxDqdj4S+Jeg+HtSuPgn8NETwx4j8efA39mT4IaT8QNH0XUYNa8PL4q8H2n7L3hXxhaz
3Wk3MGs+JPEniQajGNPktLWEAb4M/wCCVHhLwjfaVrMnxUfX9c0Dxz4A8e6Ff6x8MfC1/Hp+
o+DPj/8AtCfHi90ry9Rv9RvJtC1y5/aP8YeForQajFc6Ra6H4U1lb2/1PT73+0QDoPH/APwT
J0D4k/GPx38WfFfxavdch8ceM/AXiifwVrPw18F6h4dt9P8Ah549vvH2heHb22j+x2euRx3W
rarob6xf6d/a9zodxENUuNS1j+0dX1QA6j9mj/gnjpX7N3xT8I/Euw+Let+NX8J/DXVfh5HY
a/4R0KDVtQGv/Dr9mnwBq9/deLba6fWDpkX/AAzJ4Z1rw94adZtP0CXxP4k0+Ka7tV0htOAP
0doAKACgAoAKACgAoAKACgAoAKAPO/i/4At/ix8Jvih8Lbu+/sy2+JPw88aeArjU/IN1/Z0P
jDw3qXh+W/8Aswntjc/Y01E3HkC5t/O8vy/Pi3b1APx50b/gnL8RY7rVI/Av7RngfwZ4i1jR
tBtfEuifDy/8axaV4k0PwD4R/Yo8HW/hTVNKn8R3qw+GdQvP2Z/G2j6/qv2C71ey0L433+mr
9ujtbzT9cAPq/wAa/sb/ABVvNV/Zuu/Bnxmu7TRfhB4O+FXg/wCIGl+JtU8c69q3jaz+F/xt
+DvxZ+22etr4jtH1DW/Euh/D7xd8OtW1Lxbb6lNeaH42ujfPcwTajZ3IB8JfD3/gml+0N4o+
FPw+8PePvjbpPh/xU/w++El58RfgT4q17xr8QdF8I+NPC9l8DXPxUi1GHx9qa6j8TNd134I+
KtF1O/33/geS28a+IL3RUvL201CXxAAesX//AATS+OV/4i8WeOfEn7TPh+x8V63F8c9L8JeK
NL0bxjY3Pwtvfjp8KfBvw2/4Sn4fi88YyPpXiW08UeAfDXiJbOa+ujet4h163bWbjX7TT9fv
wD6P+Cn7E3jL4e/Ek+KfFnxSu/EPgbUvg54u+GfiTwJP4n8beIkOoeMPE83iBpfCWs61f2V7
4J03Q11fxBodpb6G1vYX2iS+FrO18OeHr/wla6tfgHh/hr/gnf8AEgWPwx1CP9rPXPGqWHw4
8V+GtV1GLXfFui6b4k8URaNH4T8AePdMt9H8S6gmpSH4baF4S8FfEfSZr2K08SnQ9S8WJcLq
niHWLW4AKfiH/gl14x1C20C0074raNbQaD8L9A0KO61a6+Ius6jb/FS3/Zl/at+Cviz4m2Op
al4our+1vPEvjT9orRPHU7reJfCy8Df2dJcG4u7K504Az/Hf/BMT46eNfCvxN0HUP2nLnXpv
iHfeNLPUrPxbd+PdR8Ha74Q8b/Df4yeEdM0bxD4UsPEWnwrffCDXPiro+p+Ab61vJ01vTPhr
4Tsdch02e306fRAD9b/hlonizw14K0Xw/wCM77w/qWr6JA2lQXfhqz1Cx0+TRbBza6Cs0Op3
V3cPqcekxWiarcI8Nrc6gtxPaWlpbyR28YB2VtqOn3lxf2lpfWlzdaVPFa6nbQXEU0+n3M9r
BfQ297Ejs9tNLZXVvdxxzKjvbzxTKDHIrEAuUAZ8GraXdNdrb6jYztYagNJvliuoZGtNUMVv
MNOuQrkw3phu7WUWsm2Yx3MDhNsqFgC+CGAIIIIBBByCDyCD3B6g96AFoAKAEJA5JA5AyTjl
iABz3JIAHckDqaAKenalp+r2cWoaVfWmpWE5lEF7Y3EV1azGGaS3mEc8LvE5inilhk2sdksb
xthlYAAu0AUZtT063vbPTZ7+zh1HUVunsLGW5iS7vVsUilvWtbdnEs4tI7iCS5MSt5KTRNJt
WRSQC6SAQCQCc4BPJxycDvjqaAKlhqNhqtsL3TL211C0aa6txdWVxFc25uLG6msb2ETQs8Zl
tL22uLS5j3bobmCWGQLJG6gAuUAUrbUdPvLi/tLS+tLm70qeK11O2guIpp9PuZ7WC+hgvYo3
aS1mms7m3u445lR3t54plBjkViAXaAKF7qumabLYQ6hqFnZTapeLp+mxXVzDBJqF88cky2dm
krq1zctFFLIIYg8hSN224UmgC/QBSvNS0/T2s1v721s21G9j06wW6uIoGvdQmjmmisrUSspn
u5YbeeVLeLdK8cMrqpVGIALgIPQg8kHBzyDgj6g5BHY9aAFoAQEHOCCQcHBzg4BwfQ4IOD2I
PegBaAGSSxxANLIkas8cYZ2CAyTSLFFGCxALyyukca/ed2VVBYgEAfQAUAUv7S086idI+3Wn
9qiyGpHTftEX24ae07Wy3xtd/n/ZDcq0AuNnlecDHv38UAXAQc4IOCQcHOCOoPuO460ABIGM
kAscDJ6nBOB6nAJx6AnsaAGTTRW8bzTyxwxRo8kksrqiIiKzu7MxACois7EnAVSx4BNAEVne
Wmo2drqFhcwXtjfW0F5ZXlrKlxa3dpdRLPbXNtPEzRzQTwuksMsbMkkbq6MVYEgFdNY0mW6u
7GPVNPkvbEbr20S8t2ubRdgkLXMAkMsAEbLITKqgIyuflYEgEUWv6HPHDNBrOlzRXMFzdW8s
V/ayJPbWZRbu4idZSskNq0ka3EikpC0iCQqWGQBJNf0OLSf7el1jTI9E2o/9sPfWy6ZsknW2
R/txl+zbXuHWBT5mDMwjzvOKANegChpuq6ZrNr9u0jULLU7Mz3NsLuwuYbu3NxZ3Elpdw+dA
8kfm211DLBOm7dHNG8bgMpFAF+gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgDyL
9oHwn4z8e/Ab42+BvhzrJ8O/ELxn8IviT4T8CeIBeTacdC8Z+IvButaP4X1kahbBrixOma3e
WN79sgVprbyPPiBdFFAH5N3XwE+Pdh40+CPjD4O/s1618FNJ8FfDHRfAXxn03w94j+F/h/xN
4/0Y/Ez9kbUfiHp2hap4Y8XG8l1jWvBHw78Y6LZeIH1fQ9b1Kz8DSm11m1k1vQBq4Bxlv8Jv
+Cqf/CDzeG9f8TePLzxVqeofCGXxV8SNH8ceCI9Y0nTx+zt4p8EeKvC3g7wZFrul+GNXsPCf
x+TwN8YdR8ZQ6t4c17xlb3PiDwpqVvJ4d0xrHWwD6K/Zg+DP7XuhfFf48+NfitHqdp8SvEXw
Qt/hrovxi8R654W1nw74q8TeFP2jP2mPFPgnVNF8MaLqGvQ+GPD1l8KviJ8M3Gkr4P0az/tB
dYtrvS7rV7TULm7ANH9uT4H/ALWnxr/Zg8LfBTw7LaeLviTPP4+8e+KPHmk6vo3hjw/D4p+H
HhDxf4l+A2mJC1p4fvDq8nxkm+F3iPQbi00WHR7PWPh+ZfE93Bptw0l6AZUXwa/aK1b4U/E8
6r4M+K+m+LNd/by+E37QEPhyH40MNUvvgvL8U/hd478WeD/C2r6f8SIbDRbXwr4VTxb4c1jw
lBf+HdG1S+0m7ttItdUtZ9LuLgA+SfAv7L/7evgvwX4b8FeGNM8eeAbTw94L8Up4Y1Wx8RfD
/wAVT/Djxn4v+DPxv8O6rqfhbSdX8ZSxwRxeM7/4VyxaTpV3aaXbH7bc6NbRC68QLfAH09+0
R8Mf21PiR8NvhroXgvwr4z0K68Q/sjfHb4d/EH4e6d8cpLCy8E/Gbxp8PLq28A+OW+LMevad
4s8c6/4X8R6eugWWm6nFp+iT2njaXxRPqsOp+F0slAPnD9rnxR+294I1O98QeFvBXxm+Ffwg
1Xw54c+HFnaN8XtN8Xaz4j8SQeG9ZvtP8WX+p/8ACYa5q3w7vtJs55tT1A6driQeLfEPgu08
Karquqah4qtEuAD3D4U+Bf8AgoRffCX9prxHD8QvH954o8VfCvUbb9nnTvGEfhTR31l77XNU
8RfDbxLZf21qM+p+A/G0fwt1DRvA3inw94u0TQX0/wAY28uo+IdZ1HWILjxAoBz/AIs+CP7a
Nh8UfjF4s+BPhH4gfD/wz8S7nSdW8Kxa18R/DN94jsPiLZfCv9m3w34C8X/EPVNS8Z+JNU8Q
eG/BDeE/jVoPiTR9W1XxVZ3P9qaKj+FvElrBoculAGTY/Cf/AIKi3beC9O0/xj428LS6Lb/E
lx461TxX4J16fxb43i8T+C/EfhTxP8Q/Bl/q97pfhDQfEvglfEvwpbwx4cfxv4Z8Lalot142
0rSb3UfEGm6rqQB23gb9nz9pZvgh410268AeMfDPj/4gftofs4/FfWY/EPjvw5q/iCbwrpXw
V/Zl8E/F/wAZX3iK08Z6+kP2fxT4D+Ic9pa2GrtrdlFa6beeFtPtWXRhAAeafD74F/8ABRfS
9A0TR9Q1j4vaBofhfwF+zH4cs/CEvxF8La5caxp2lr+yxpnxos73xsfiBc+IbTxRpHifwf8A
tG+Lv7VF5qN94m8H+N7PRrbxHFbR6H4ZsQDrPhR8NP8AgopoHir4STeME+Juv+FNE8efCfVP
HPhXWvijoENp4j02TTPEXhXx1faj4ysPFmqeJ7KLwRCPB3j+38L2kM/h34iahoGoaFqclrd+
ItQuNYAPU/iJ4L/bS8dftWXT6f4Q+Ivgr9nO5+Ifww0rXTovxstPs3ifwr4f174g23jDxpp8
eneLdM8U+CrHxD4R8Q+FnuvD3hlrK6W5sEcW765pPmQAHP8Agz4Kftwah+zv8TbD40+I/iN4
y+I118b/ANm7xTaeE9G8Y+H/AAvqM2g/C39oTwn4u+MGpfD3xz4X8ZaBKui/Eb4aaXKmn+GN
RuvBVnbtYPo9vpNlcaxfqwB4h4d/Z9/4KBfD/wAE694S+GujeOfDHhu7PxA12z8MWfxI8J28
1n8QPGmpft+XnhXWdGuJ/Fk/9k6FovjDxd+x/wCLPFuh6dqVhoN7aWF3NdaHrph8d2VyAd5B
8Kf+CmF9r3hrRrzxf470bS4vjV8Q9T8T/FCy8T+CtU1LWNL1jxV4J8S/De+n+G11rthoej+A
fh5oVl8RfhxJpmgajPF4x0rXfD3i/wAQ+FbnXYzpvhwAg/aQ/Zp/au1j45fFP4hfC3wv8Qrr
WrD4mfFX4ifCDxvZ/FLT003S4PEP7JHwT8B+C9K8PaPrnjyAaBbp8X/BnjRfEnhuXQbHw5rM
N1a3eu2ur6PdRiMA9K8HfDz9sTxH+2P4e+J3j/wB8R/CnwP0D4vare6N4Qh+OVrr+n6Zp2s/
Db4meFdQ8W6hY2XjO1l1fwre+JNI8Aa4/g69ttVstAk163/4R/QHjHiCVQDxfWvhB+3r8PPB
v7QXhf4OfDPx1LP8Q9Q+L3ij4bXNh8ZvDnhjT/h58TfE/wC1D+3B8T9F8d6Zpc/iyW2uLTX/
AAN4p/Z5sNX8ISW9n4Uup9bGpeINNk1fRPEigA7f4jfA7/gozd6t4gi8H/EPxtoXh6f45fEn
w9oGqaJ4z0DxBrVp8J/EcXxo+IXwn+JQ0LxNr2mWktr4B8YfFf4f/DnXPCF/rC61qenfBWG5
1OLWPBmpwW6gB+0d8CP23ofj5+0D49/ZjtPEXhn/AIT/AMZ+CPE17r9j4z8Mafofj34a6D+z
74O8C+IvB9jomra3NDp/xIuPGvh9I/D/AIhvNA0PVbGxsC1n430jTbpkuADnbP4If8FKE8QG
LX/id8VPEXhjTLr4IvpkdrrHgTw7N4l+Hd547+CVz8QvCuuXOkeNLbU9A8b+BdM0v4rXGoa1
aTaxq3jTQb1LVfFs897baPbgHV+N/gR+2L4r8B/sieIbnQ/E2qfGP4RfBj4x6P4v1S98aeHB
qln4i1r4y/s2PbWhun8QHStV8a+KPgT4L+LOieGfF++6vdD1vUINRk8T+HPEl9aa7EAcHrfw
5/4KdQ2HjvSrJfiXejXfCfxp1LwFqNn8S/BMb+GE1j4PftVeH/gx4M1aW48V22oP4x8PeLb/
APZsl1TVz/atidX0x9c1TxVqc/8Awk+oXYB1snwP/bI8Q/Gf4YDxz4V8d+KPhf8ADz9qbw78
Qfhzfan8Q/DV7beBPAfh39oX9qa41fVPFVvceMh4g8VXupfBbxz+z3beFzrMHjHWdO07w3rt
tE+h6xbavDqwBvWPwd/bl8OfFbVY/Cv/AAn1j4N1H9o7x94wttW1D4paXrHh+LRfE/7ZPw5+
JVxrc2l6v4r1S/XwXf8A7JM3xB+G+leDxpL2eg+L0uotO8J6VrcuieJpwDS8c/Dv9uwfG7x9
rnhj/hY118LdV+L+sahqOkW3xF0O3XXPgrp/xK/Yy1G28P8Age2vPFUVz4W1rVPBVh+1hDp0
+kv4T1t4r17G61i3up/BMaAGP4A+DH7c3h34EftIWXi6T4har+0H49t/2U9a8O+K9O+KWmS6
beS+H/APwS8K/FbR/DcA8XWmh+E9d03VfB/xAufFNxp2kaBZeKY9Si1Cx1bxBPqe5QDl/Hnw
1/4KAeC/FPxc8Sp4o+KOu/Brw18Rtfjt/BGi+NvDbX3iT4BW/h/xTc/DjWPCnjPVfGGneNbH
xJ8P7xPCVr46trq80PxP4st7PWNT1fXvGt1tt9cAOZ+Evhv9vX4gaf8ABHX/ABJpnxB8U+Bt
SuP2evifd67qni3wc2m6tpV94+/4J2fEXU5n0DUfENrrtlq3hrw54T/aylvbe+0KxubTUdSl
s9EFxd3/AIc8oA9p+CPwe/bq0j4h/so3fjPxj8R9F8H6V8JfhxrXxwi1LxdoPjqHUPjDpg+K
Gm/GTw/4sh1Txbd3MOneNdH1D4Qy+HL7woNe0PRtR8K6td6DpWgX+ra/qGqAHhPxRtv26vDv
inTfC/iC1+M/2Hxr8TfHPw4+H03hr4jaHF/wlOp3ek/8FRfG3gnWLa+0nxvYX2heG9K8P6x+
x295eeKrjQi03g6x0e5tLy5029tL8AztY+Cv/BRK11jx/wCMdW+HHjH4gfHLVfgP8Xvg1a/F
bQ/jJ4R8GaSut658U7fxj8IfFXg6103xRpH9naP4W8O23h/T9Y0U+FfC9tqurxatdeIrfUha
3Op3wB2dp8C/+Ch1t4sA0TxJ8VvBGk638Tvih498UeIrHxl4M8befquva38APGPg42PhbxT4
+trCy8MyeDtI+OPwxu/D1m2meHdA8S67HqcHh64WDw1rcYB6p4i+E37aes/sxfsw21lZeNrX
9oT4Y+Mvi3/wkusr8Ww13retaj8APj98Pfhf8YfGMd7r9rod5oWpfFfxF8MfiF4h+FtxD4m0
bwZbXN1otloGuaPoUsVwAa//AAqT9qvXvhx8PpfGGkfEnVIvDH7Zvhn4gW/gUfE+ytPHNj8B
B8CW8E67o/iPXbHxva23izTR8atY8S+M7jwzrHi/xAbjwtd2iRWsttp2neHbEA+fPgt+z3/w
UO8D6R+zr8N7LWPHvw5+GfgW2+EOl6tBa+J/BPiyXw3e+Gfgn+w9FrsE9lqPiyS61D4fHxj4
G/a38G3Gi2+q3+l6TP40sdW0LwteabH4RlsQA/ao/Yq/aU+LfjX9pK7+EXgJPBviDxR8e/iB
8TdK+KD+KfDHht/iV8I9b/YQ+GvwJn+Csd7pmst4jWL4g/FnQby4ubfxPZ6b4d0JPDEHiq7v
LW8udJluADJ+JX7Fv7RHiTxl4n8XeB/hE/h/wX4l8dfGTxtonw2HiHwZo8mhfDrxB4//AOCZ
+sa/8I5LW0186Loc3xz0f9mn9o/UJ9H0i7bwwsvjs2Pi+/0mbxVqa0AfRf7ZXwc+OfxV+B/h
PwB8EvgTrvhP4d+IfCf7QVj4n+CuheIPh14Ml0n4h6v428I+IfhJ4x8RQaV4s0zRrjw9qMOn
fEvX9V0HTNc1S3TWvHGjJ4o8M3epwGXQgCt4m8BftoQwfDbT/DXgn4nXWqap+0b8XfF3xO8c
XPx0ieCw+CVz+0L450vwd4Ej8D6j4zuNEkttT/Z61vwteWFxotva6lo8mkKSIfGcdzdRAHoH
/BOb4L/FX9m3w1qPw88dfDLx7pcHiTS/gVqEeu33xF0vxb4S8Mz+Gv2Q/gR4P8caUNLvPH+s
3+n6xc/G/wAJfE/+1p/D+gyW2s3uqWevT6je6be291bgH6i0AFABQAUAFABQAUAFABQAUAFA
BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ
AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU
AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAF
ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB
QAUAFABQAUAFABQAUAFABQAUAFABQB+YHxK+E0Pxs/av/aistUXxJ4l1H4bfs0/s3al8MPB0
HxC8ReB/DTeKvFev/tSPfJf3Ghs/2VPEF54Y8N2mp6obO8uLezsIWjhk8lYyAfFfws1j4Faj
Z+EL/wCM3w+8b+Ebb4lXfxP034aQ+CvjT4/8Tap4u1v4dftCfDr9mdPDsNjqF5pVvZazr/xI
+IOmrp63mpQ2I0q7srme8g8q+8kAseEPiJ+xRJ/wtqy+Inh745+H9f8Ahp8Wrn4cf2BofjPx
vq2r3E+u61rlt8OfD15po8UyXKeP9f0Pwz4l1jUdKtPP0a2h8N6v5OrfafsthMAfXH7O3wO/
Ze/aR8N+L/Ffhbwv8dPD2jeFfiP4x+HUU/iv4ieLNOl1+48HapJplzrWnWSeIJtQtLG6kTcL
PWbTTdVs5C9td2cc0bgAHNftn/sh/Cn4a/s9+I/GHgvU/idoviGy8bfBLTLbUYPij4zaWOy8
TfHL4ceF9bgAfVCu2+0PWdSsJDjIjuXKkMAQAebfHfw9+zj+z58abTwT8QfCfxM0T4ZL4Kt/
FT/EG6+KPxGuJfFt9La+MrnWPDPgSKzupNGufFHgmDw5o+t+I/DOv6rpGran4P8AEV74m8Mp
qUPhLWLWUAx/F/jT/gn34Mu7u0v9G/ac1A2EPieS9n0XxB4qv7a1m8Ja5+0n4f1aymkbxnAV
u/tv7JnxtktlCmGa08OWs7TxnVLRGAL1v4o/4J8XPj4fD9LX9o1LtvFlp4PTxHN4k8XxeEn1
C98Y+E/AMF9/a7+LRMmknxb4+8CaO95LZRvHL4u0uZ4BbW+szaWAYp+IP/BPiWw1vUdK0H9q
DxDb+FtB+IvinxcfD3iPxDqo8LeG/hW/hs+Mtb1a4g8efY5NPsLTxj4W1KGXSrnUzdWGuWss
SGSG/itAD7X+Gv7Jv7L/AMVvCdv428KR/FZ/Dt/q3iXTNKvb74l+L4V1iDw14k1bwy+vaU9v
r13De+Hdcn0ibVPDeqxzeXrGhXWn6pEiQ3kYoA7z/hgj4Af3fiR/4dLxr/8ALWgA/wCGCPgB
/d+JH/h0vGv/AMtaAD/hgj4Af3fiR/4dLxr/APLWgA/4YI+AH934kf8Ah0vGv/y1oAP+GCPg
B/d+JH/h0vGv/wAtaAD/AIYI+AH934kf+HS8a/8Ay1oAP+GCPgB/d+JH/h0vGv8A8taAD/hg
j4Af3fiR/wCHS8a//LWgA/4YI+AH934kf+HS8a//AC1oAP8Ahgj4Af3fiR/4dLxr/wDLWgA/
4YI+AH934kf+HS8a/wDy1oA/LzS/APgH4bfsX6D8c9e0T4l+P9WuPjP8cfCXijxLqnxU+Iqa
D4A8GeF/jH8bNJ03xt4yi0CbUtfbwb4b0rwZ4d8M6xfaLpl/daDZ6nF4n1G3k0bRdXcAHUXv
jf8AYc0LwJbeMvFHhL9oHSZ9U8WfHDwX4e0m3+J9/qn/AAk2sfA/xD8QfDGpXWjXVp428+XQ
vFutfDjXNP8AC2sy6fHayXjQR6kbGFhdOAdHb+IP2CI/D761r2kftH+Hb2z8O3fiPWNAuvFP
i7UdV0m30/wX+zt4/wBRjn/sfxVfWzpZ+GP2oPhbqk9+Jk0+1sp9evNSudPttEupCAfa/hH9
i79m3xr4U8MeMtGHxLOj+LfD2i+JtKMvxW8UzSHTde0221SxMkuneIL/AE+Vza3URaSxvryz
kJL213cQlJnAPAv21P2QPhP8M/2S/wBon4g+CtS+J2ieLfB3wl8ZeIPDurwfFHxm02m6vp2k
XFxZXkQfVChkgmVZFDgqSPmBGQQDxD9rDT/gT+zD8VvCnw8vPhz8SNc0Txt4J0y+0bxxJ8aP
HNppOl/EnxB8RdO8G+EPAniSCO6mfT7TxxZtryeHPEHnfZ28XaZpPhW4g+0eJ9OnjAKmrfEX
/gnrp17oP2e0/aB1DQNTs/EHibVvFEfjXxZb6XoHw00T4bfFf4nwfFWaKfxMt7qHgzWdB+C/
xA/s37Fbtr5bQbt7jRIS1lFegHsXws8M/sQfF74gaL8MvDVj+0Hpvi3XPD2veJrWy8XeKPHH
hVP7N8Oa/rvhzUzbyat4ihfXHh1DQJ5Xl8Lxa9Z22n6joWoX93aW2t6dJOAfW3/DBHwA/u/E
j/w6XjX/AOWtAB/wwR8AP7vxI/8ADpeNf/lrQAf8MEfAD+78SP8Aw6XjX/5a0AH/AAwR8AP7
vxI/8Ol41/8AlrQAf8MEfAD+78SP/DpeNf8A5a0AH/DBHwA/u/Ej/wAOl41/+WtAB/wwR8AP
7vxI/wDDpeNf/lrQAf8ADBHwA/u/Ej/w6XjX/wCWtAB/wwR8AP7vxI/8Ol41/wDlrQAf8MEf
AD+78SP/AA6XjX/5a0AH/DBHwA/u/Ej/AMOl41/+WtAB/wAMEfAD+78SP/DpeNf/AJa0AH/D
BHwA/u/Ej/w6XjX/AOWtAB/wwR8AP7vxI/8ADpeNf/lrQAf8MEfAD+78SP8Aw6XjX/5a0AH/
AAwR8AP7vxI/8Ol41/8AlrQAf8MEfAD+78SP/DpeNf8A5a0AH/DBHwA/u/Ej/wAOl41/+WtA
B/wwR8AP7vxI/wDDpeNf/lrQAf8ADBHwA/u/Ej/w6XjX/wCWtAB/wwR8AP7vxI/8Ol41/wDl
rQAf8MEfAD+78SP/AA6XjX/5a0AH/DBHwA/u/Ej/AMOl41/+WtAB/wAMEfAD+78SP/DpeNf/
AJa0AeafCT4aaJ8Ev269W+H/AIH1XxcPB+v/ALJcfjHUdC1/xZrXiSybxLY/GJdFt9Wt49Xu
rn7LdLpdxLZs8BTzImw4bC4AP0doAKACgAoAKACgAoAKACgAoA+FdH8RxeD/ANrv9tvxbcWs
19B4W/Zb/ZQ8RzWVvJFFcXkWiax+2JqclrBLOyQRzXCWzQxyTOsSO4aRggY0AfKnwv8A2iv+
CcXxe+HtjP4j+Feh/Drwh4U8F+INTsdE8c+EBLqXhC+8S6nD8ePjp4NvtJ8O2+ty+GvFngHx
74D0/wAXeNo3lCajrmhab4r8NXmsWEdpqTAHSfEH4kf8EyNBT4sLD4H8DeJfiB4ag+JGraz4
VHw38V6FfeKPGPw31X4r+J9X0WDxZrHhK18OLrT+Of2evijpuk6xJqz2b+J/BuvWmn3dxc5h
ugD2D4e/tn/sD+CNJ1DWvD3jfwl8NNT+IF7qnjnxp4Xk8M+JdF8TQ+JrLwppesa1deKfD3/C
PxalZ6tc6ENOm027u7KFPGaSWtx4Yl1v7bA8wBb/AGyvH3hf4n/sTar478F3l7qPhfxB8QP2
fLjR7/UND17w5cXttb/tO/CyyN2uk+JtM0fWYrS4ltpJrC6uLCKDUrF7bUrCS50+7tbqYA+n
/HP7O/wR+Jms6nr/AI/+GfhLxdq2s+H7rwvqV5r2lW+ovd6JeaTrGg3NnItwrp+80PxDrmkG
ZVE403Vr+zEghuZUYA5Ifsd/sxLafYB8EvAIs/Ju7f7P/YVsYjDfS/FGa8QqVO4XMvxt+Lck
+7PmP8Q/FjNk6zeGUAmH7In7NAm88/BbwC0pu4r8s2hWrbruHxD4Y8WRzuCpDyL4k8F+FNaB
bP8AxMNA0u5/1lpEVAMFv2MfgDpHhTxT4a+G/gXQvhNc+LfCOs+BNQ8SeA9H0rT9di8K+Jm8
MR+KNIglubO6t/s/iGw8H6BpupebbyNJbadaOjJPa28sYB9E+D/CXh7wF4T8MeBvCOl22ieF
fBvh/R/C3hrRrNNlppWg6Bp9vpWk6dbJyRDZ2FrBbx5JO2MFiTkkA6OgAoAKACgAoAKACgAo
AKACgAoA/O/9kD4W/D74t/sh+GPDnxJ8J6P4x0K2+Mf7UGoRaXrdql5ZC6m/aM+OuiXLPBJ8
kiXejazq2lXcMgaK60/Uby1mR4Z3UgHv9z+x9+zDea3B4iuvgd8OZ9Ztda1fxFbX0nhuwaW3
1rX9UfW9Z1GEGLZHcalq813qV2yqPOvL/ULh8yXty0gBVi/Yz/Zct7mO8tvgh4Atr2Lw9ZeF
Y7yDQ7aK5XQNO0/wvpNnpgmUBzbRaZ4I8G2G0k77PwtoNu+6LS7RYgD6F0HQtG8LaHo3hnw5
pllonh7w7pOnaFoWjabbx2mnaTo2kWcOn6ZplhaxBYraysLK3gtbWCNVjhgiSNAFUCgD5K/4
KIf8mMftX/8AZDPiB/6Y7mgD6A8YfBv4V/EDUp9X8b+AvDHirUbnS9C0We613SrXUZJNM8Me
LbPx54dtW+0o42aJ4y0+x8S6Ycb7PWLSC9gZJo1agDhH/ZN/ZtktprOT4LfD2S0n1248Ry20
nhywaF9Wu9E8TeG7mYxtEV8qbQPGfi3SHtQPspsPEms23leXqFysgBv+Ef2ePgp4E13w/wCJ
/CXw38L6H4g8K6Dc+GfDur2emxJf6Pol5JPJeWNhcMGkt47s3M63JRg08chjkLKAAAez0AFA
BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQB8St/ykdi/wCzJZ//AFe1
vQB9tUAFABQAUAFABQAUAFABQAUAflX4/wBP+Outftmfta6B8KdP+DV94T139lr9lvSfiJ/w
tbVvG+jTpYal4h/a5siuj3/g6W3eztn0ufUvtt7LcW91aS+TNazRFDIoB8A6n4V+GPxD8NXG
vQad+xbrXhjx94s8HeE9c8Y+B/Fv7XK6bqPijV/hX8NPgH4Z07xx4x8HMsGknxN8OPin8MPB
lzceMNU0+w8RXGs6NJqs95rej3M+mgHtHhT4B+Jfjl4g+Ilh4f8AAn7L3iDxF4e1eS++IWka
z4q/bA8NX9nefEzVvj18Qor650nxTcaJLd6T4sv/ANoz43a1pt/Y21zot9B4su4rGdrbSNKi
08A9Jg/YP+M1tPqd5B8Iv2VU1DXfCviLwT4k1b/hZ/7TTax4r8MeJtAsvC99pfi3Vm8RnUPE
8dhoOm2OneHJdcuL+fwtDawnw7LpkiB6AIP2yNO/bb8MfsmXfhe88P8A7K9l4N8O+J/2cdCs
INN1n4u3uo29rpHx1+FFj4egNzqbTTXMaXVvpsWoXN1NNeS2n2mYyyXTByAew+Mf2oP2o/h9
8QLb4YeNNb/Y98O+Mbm18A3v2XULb9oJNFtLf4p+J/Efgr4cnVfGEehyeDtGl8a+L/CeveGP
Dtvq+vWVxqevWcelW8TXt/p0N2AcZY/txfG7UV0l7fx7+xekWu3vg210e4vrb9ojTLXUbT4h
+F/G3jXwP4ltrrUvD1pbyeBPFfhb4bePdb0L4ieaPAmoWfhPXGg8RNJZSxgA3Iv2uv2lZPCO
iePp9Z/ZM0vwZ4j8Z+E/AWjeJfEOh/tI+F9KvvEHjrRrDxB4QkhuPEnhvSQ3hzX9J1XTrqx8
ZAHwkftaQy61HPFcRQgHY+O/2gP2s/hpHo03jfxB+xJocGu+JPC/hOznk134t3UNvrPjVLx/
Co1iSxS5XQtL1v7BcrZ67rJsdFLKvmX8ayKxAOvl+Iv7bUF6+mz6n+w3DqMbaeklhL4y+I0d
7G+rQXN1pSPavcidW1O2s7u509WQG9gtbma28yOCVlAMrR/jB+2Tr/n/ANk6v+xHcrDrF7oM
creI/itbQX+qado9h4gv4NGuLsQQ67FaaNqdlqE97osl/YxwSuWud9vcrCAYPiT9oX9rHwqv
gg6pr/7E9w3xI8Yt4B8Dx6HrXxd8SS+I/FcGlanr2o6ZYJoMeoE/2LoGi6zr2vXUvl2mjaRp
d7e6hNAkahwDsrb4jfts3tzpdnZ6p+w1d3muWjahotpbeMviNcXOsWCpfyte6XBFcvLqFose
lapI1zaLLCE02/cvts7gxgEVn8Tv20dRSOTT9a/YVv45l1B4ZLPxv8Q7pJU0m1t77VXjaC7d
ZF0yyu7W81BlJFna3VvcXJjimjdgDlLb9oT9q668Sa14UTxN+w9Fq+geHvBXiq/e88R/Fax0
iXQPiJN4zg8H6jpPiC88nQtcj1iX4feMAsejahfTWo0S4e9jt0kt2lAO4Pjz9uNdJi15rv8A
YiGhz3h0+HWj4s+JQ0ma/F7JppsYtRM/2OS8GpRS6ebZJmm+2xyWuzz0aMAFZ/iR+2ujSq+q
/sMo0ErQTK/jP4iq0M66vJoDQyg3QMcq69FLorRvhxq8cmmkfbEaEAHKXPx+/aztPGlr8Ppv
EX7EH/CV3Phjxr4xexi8RfFae10/w78PNV8J6J4xvdb1eESaToMmjan438N20llrF7ZXtx9s
uJLWCaLTtRe2AOvl+If7bcLXSTaj+w7E9lo8PiG9SXxj8R42tNAuSgt9cule5Bt9HuDJGIdT
lCWUpdNk7bhkAzvht8VP22/i94B8I/E/4eJ+yD4h8DeO9B0/xN4V1xLj402K6pouqQLcWV4L
PUbW1vrfzYmB8q6t4ZVPDIO4B2/27/god/0A/wBkP/wZ/Fz/AOJoA+DP2W/ix+1x8LP2YfB2
p6k37KmmaB4g+N3x68J+GLe9/wCF1614m8R+M9X/AGifjHdTeHvD3h3wxp2qa1r1/Nd2Gv3t
hYaTp15fJ4e0y41O+jjt7DULiEA+pfBPx3/az+JHh/RvFHgfxX+wj4k0PX/C8PjTS7zT/GXx
LMk3hWeys9RGuT2U0sWoWNjDZ6jYzXr6ha2raf8AaoY79LeVwlAHVaf8QP239X1CPSdKvv2H
9T1WawTVYtM0/wAX/Ei91CXS5YLK6j1KOytriW5ewkttS064S8WI27wahZSrIY7qBpADpPt3
/BQ7/oB/sh/+DP4uf/E0AfJv7d95+3g37Gf7Tg8T6N+ymnh8/Bfx4NYfSdR+Kzaoth/Yd157
aetwv2drwLzbif8AcmXaJf3e6gD0D4gftQftRfCvxvoXw6+IOufseeGPFfiOx0HU9Mtb23/a
Bl0tbDxT450j4Z+HbvVfE1nolz4X0CDWfiB4g0Hwhp76/rOmC413WtJsUzLqNoJgD0GH4pft
nXEIubfXv2Ep7drXUr5biHxz8QZYWstGcR6xeCVLtkNrpUjBNSuAxhsXIW6eJiBQBctviD+2
7eLpjWeofsPXa63Hqc2jNbeMPiROurw6IZF1mXTDFcOL+PSGilGpyWplWwMUguzEUbABxPjH
9of9q3wH4Wu/GniTxN+xBH4csbWw1C5vdJ8QfFnxHONM1HxNp3g6DVYdN8PJqep3elReJNVs
tLvtRtLOe0sJ5HN5LCsMxQA9Xm1T/goRbQy3FxpH7H8FvBHJNPPNq3xZihhhiUvLLLK4VI44
0VnkkdgqKCzEAE0AfO3hP9sP9ozxv4g8G+GfD3iL9kOTU/iLpF7r3gCbV9L/AGi/C+jeONGs
oPBd0NS8H+IPFHh7RtE8UWOp23xD8I3GgXeg3+oW3iGLVS2izXxs71YAD1//AIWd+2j5sUB1
r9hXz7jVptBgh/4Tf4h+bNrtvPYWs+ixR/a98mrQXWq6XbTacga8jn1KwheESXlusgBLF8R/
22J7u4sIdV/YamvrTWLbw9d2UXjP4iyXdrr94ZxaaHcW6XJmh1i6NrdC20yRFvZzbTiKBjDJ
tAPO9U/ae/aY0b4g6b8LNR8a/sKw+PdU8Q6j4Rj8PR+J/irc3Gn+KtM8MaR40m8N+IJ7YS2v
hrXLrwtr2k61pGm+IJ9NutatL2EaTHeTOsTAHp03jj9ua3g1a6nuP2JIbbQbuLT9duJvFfxL
jg0W/naBYbLVpnmEenXczXVqsVteNDNI1zAEQmaPcAUD8Tf20hGkp1r9hURS6PbeIY5D42+I
flyaBe3NvZWeuI/2va+j3d5d2tpbampNlcXNzbwRTvLNGrADrb4l/tqXtqb+z1j9he7sRdaZ
Ym8tvGvxEuLUX2tQw3GjWZuIrp4Rdatb3NvPpluX86/huIZbVJUlRmAMP4jfG39r/wCEnh/x
H4p+I+ufsReE9G8J6JH4k8Qzal4i+K/2vTtDm1GDSLbUn0uATanLb3er3VtpVk0FpL9r1O5g
sLfzLqVIiAaMXxX/AG0XgjmudQ/Ym0iY6JaeIrnTNf8AEvxQ0HW9L0i9h02aK71vRNWktNU0
UINY0uO5TU7W2e1uNQtLe4Ec1xEjgGL4s+PH7XXgfUtB0nxPrX7FOnah4j8W2Xgawt01r4uX
xtPE2p+GPE/jLT7HXmsI7lfDUF74c8HeI9St9S186dpsiac6fa/MliVwDqtN+In7bWsrePo+
pfsOaqmn2cmo6g+m+MfiPfLY6fFcXtnJfXjWtzKLazju9N1G1kupikKXFhewNIJbWdUAKsXx
S/bNngN1Br37CU1sttPetcxeOfiDJAtna6kuj3V2ZkvDGLa31eRNKnnLeVDqTrYyOt0wiIBO
PiT+2sYLW6GrfsMm1vtIuPENlcjxp8RTBeaBaY+165azfavLuNItiR9o1KJnsocjzJ1zQBR8
KfFr9sfx5qPiPSPBHiH9hLxfqvhC6sbLxVp3hnxv8RNdvfDt3qem2ms6bBrVtpl1czadJf6V
fWmoWYuki+02s6Swl1yQAdx9u/4KHf8AQD/ZD/8ABn8XP/iaAD7d/wAFDv8AoB/sh/8Agz+L
n/xNAB9u/wCCh3/QD/ZD/wDBn8XP/iaAD7d/wUO/6Af7If8A4M/i5/8AE0AH27/god/0A/2Q
/wDwZ/Fz/wCJoAPt3/BQ7/oB/sh/+DP4uf8AxNAB9u/4KHf9AP8AZD/8Gfxc/wDiaAD7d/wU
O/6Af7If/gz+Ln/xNAHj3wjm+O83/BQvVD8drP4VWeqj9jMDQF+Flz4ruLOTTz8boTeNrB8U
gSLci58sWgs/kMRmM3zCOgD9N6ACgAoAKACgAoAKACgAoAKAPh7w3okPib9sf9tHw5cXN3Z2
/iD9mT9knRJ7uxnktr61h1XXf2wrCW5s7mF45re7gS4aW3nikSSKZUkR1ZQwAPJ/h7/wTN8K
fBrwl8J/APwf+L3jLwt4L+Hvxbj+MPiXQPEeheHviNbfEjxHpuneDdD8J/20fGCXy6W3gbRf
CEcfhGWwie30jXry28Yx2DeKPD3hvU9LAPqb4E/s6W3wV8W/GfxzJ401Txb4i+OHiPw/4m8W
BtF0LwtoA1fw5o0uhRa/B4c8PW9vpv8Awl/iHTjZxeM/EiLC/iL+xdCBsLFNMjSQA+k6APir
/goV/wAmq+Lv+yi/s6f+tI/CSgBvxt/Yn8K/Hr4pa3438Z+N/EMfg7xd4V+APhTxt8NdN03R
obPxPZ/s4/GHxp8cfAiS+J5oZ9c0u0vvHXi+KXxNb6UbW51LStCsdMttQ0+G71Q3gB4fN/wS
1+HereGfB/hTxT8VPHniTTvBvhH4R/CSyln03w1p13efA34KfC/9oL4VeDfh9ezaZY2wOsXG
jftI+PdS8Q+OoEh1TUtXg0SS1sNNtLJ7SYA9l8Rfsb6n41+Cngv4O+OfjPqnjCP4cfEP4S+O
fBOu618OvAkltaWnwesPD9poPhnxD4Zhs4dL8UWWs3ei3es+JL6+khvJ9T1u7XSDoul2Wk6b
YgHzZ4a/4I/fBjwnZ2Gl6f4/8W6xpmkaz8LtT0s+NtI0Hxjqqaf8OPDPgPw9ceF7+91OJbK/
8MeI5fhr4S1ltMGk2v8AYd9aXEGmTf2c2n2emAElv/wSU8GSskut/Hv4oapfaZ8Nvhd8OvCO
s2+j+C9J1zwYnwrvvhHe6N4k0K+t9JlhTXryH4Yapot5fT2ct1LoHxD8U6dc3V2/2W6UA7jU
P+CX/wAMbnx5q3jHTfHvibQNN1TxxpHiyDwdo+h+GbbQvDum+Fde+B3irwf4Z8KH7Gbrw9b6
ZrnwH8NWutanYSJf+KfCOq6v4U1IpBHpV9pwB0niz/gnB8LfFf7PfwG/Z0/4SXVPDnhf4HeC
PE3g5Nb8K+HvDGja94tufFP7O3jD9njUfFl80Ng9jpfiWTTPGFz4unvLK0lS/wBfsbW3vo7j
S5Lm1lAOz+Bf7DPgX4J/FbUvjDH4gk8X+LdT8M+KNJDax4V8OWtroOt+Mvi38Ufiz4i1vwaL
OA3PhSwurr4ra54Zi8N6bcfYk0G2h+03N5f3mp3d4AeC2n/BJ74XaRo3w9sPDvxB1vQNT+H/
AMAtD+Cdnrlh4O8GiSbWfCuj/EDRPD3xdttIay/sOy+IE+n/ABL8R2Hi67uNP1OHxVpkWjWT
f2W2lx3UgBhXv/BIv4f6n4OufBOqfGDxVq2kz6H4h0VP7Y8H+EtWkthr2hftwaKL2E6hFcbr
rSD+3J4xv9KlmMssF14A8EvJLK51iS+APVvEn/BNzwN4k+EMvwif4j+JtM0r/hbfxu+KVnc6
Z4f8MQ2NjH8fPAXxC+HPjLwzD4aks5dDNvpeifE3xJqfhHVjANQ0PxRHpetOL6O3vbDUQDD8
X/8ABK34JeKH1908UeLYIda+KJ+IEOl6othrui2Gg6x8P/Hvg3x58OGs5EsrrUfDHjzxF8Wf
il8WdamvtQk1H/hZ3i9tYae50vTLbRXANHVf+CZ/w7vb3S9W07xzqehaxpXjz4zfEV9R07wh
4TSTxFr/AMVv2rPhj+1lpln41X7KreLfD/gjxV8LtM8GWmk6nKTrXgjWNYsr27t9QktNQtQD
z22/4JMeEdO1fwZqmm/H34mJH8OvD/hDRvBenahong/UNPspPCfjT4BfEKNdZsxp1pa+I9B1
DxX8ANGnm8Pajb+XbaP4n13w9aX8elaZ4Pg8NAH6Ffs8fBvT/wBnn4IfDD4IaTrt94m0v4X+
EtM8H6br2p2Wn6dqGpWGko0NpPeWWkw2+mW84t/LjkjsLe3tcpuht4EYRIAezUAfl3+zZ8E4
PjJ+yx8Eb638V6p4K8XfBz9qj9or4u+APEenWGnaxBZ+J7L45/tLeAb211rQ9UQ2us6LrHgz
4g+LdGu7QT2N1BLqFtqdhf2t9p9vJQB88eGP+CRnh7UPFXxl8Ha5rfi7wX8MNDt/AOm/Bfxh
on/CGHxv4v1Afs+aF8PvGXivxR4gsVfXJtIbxS3iC61j4d32n+H/AA3req/Z7+3t20qCyhhA
Prb4Q/8ABOf4e/Bz40+E/jV4c8WXUereGLv7YdEsvCmgaZp98Lj4Tan8MtT04aiputdttEv7
7Vbjxv8A2W2pXUcGuR20Pmy28CtQB+itAHxp/wAFEP8Akxj9q/8A7IZ8QP8A0x3NAF/4ofsv
fC34nftC6D8X/G2saZqHibTPgvrnwt8I+Cda0/QdStNPv77xjp3jez+JOlWuolry48S+G7/R
IjpB8iW10+WE6nA1vqFtFcRgHwp8bf8AglB4Yt/gB4n0L4S6vrms+M/C/wCyivwn8G+DrXTv
BXhux8e/EbwL+zx8evgp4I17UtSuI7Cz0BPGC/HbxBqnxB0kXlvoPiLXbLQdSv57a2s9Wt9Y
APRpP+CUvw41V9Q1PUviF4khuvF+o3nijxloa+FPBa+Gm8ST+Jfif4xsrTwvoSWlxbeCvCn9
q/FjX9P8beEtDvp9P+IuiWNhp/iG9leTUb7UADL1f/gkx4e1k+F47v8AaK+KE1p4R8J6l4T0
azvND8J3/wBmsdZ12XXdSjk1G7tpNa1eFZU0u20+58Vap4j8SxxaYkureJtbup2njAP0RuPh
V8NfG+reIvHC3+va6fHHhjVfB+qmw+JfjO+8F3miX2njw7qcWn+E7fxNN4Gsr37PavbS6npm
iQalFerdTtdC9mupJAD4k1r/AIJq2nijwr8HvBviv48eKvEOi/AHwLp3w4+EhvPAHgCPUvC/
hnRNZ+AWsaNdPqdtp8V1feLYpPgFpEd/4mDWstz/AMJLrp0+y0iFLK2hAOFn/wCCSHg/UNS1
3Wdc+OfjbX9X1rXNb8SLqeqeDfA0lzpeu6tp/wAG9Ji1jSFg0+C00nU7LT/gl4Z8ubSLXTrZ
L3UNXmsLPTbI6dpungHgX7PP/BNPXjr8fiT9pFtM8ExaN4u0LxjptjKdBuE8aa/4lutTuvGv
w+1QWfjnXbHWvDHw5j8J/Dc/BXxz5HhTxTE2o+PhrXgsw30G0A+t/jF/wTj+Gn7Q/i34l+PI
/ipcW2n/ABM8TeL/ABhJa6P4U8CeIYdD8ZeK/wBn3wn+zvfazpev3FrNdz3GjaH4L0bxNocV
1JLPpHimTVJ47n7NfC2gAN+2/wCCfHwq0zwF8fPg6fiFqE17+0d4ri8c6jqWs2eiat4yj8P+
HvjTrHxm/sSaHVJrhfFmjaN4r8f63oyald2MJsNG17T7W6EuqZ1G/APIdU/4JK+CLlL7+0/j
x4yXw3D4V+Inhiy0Cbwj4DtvD2g+HPiD480X4h65YR20dhBbTaXpt94a0m30qPU1uXsLFLy3
e7k05dIsNEAH2X/BJn4LatHbX9h8TdR1Hw/Nr39rz6LpHh3wrB4L8Q2c2uftPTa/pmtaZoL2
dprJudJ/aZ1/wxp1884m0C38D+FBGl1AmradfAHrnx9/4Ju+Avj74/8AHnj3WfiL4r0Wbxzq
Ol+IJ9Lt9F8MarDp3iHT/BXgn4czCK/1KwfUL7whd+EvA9hN/wAINfTy6Nb+NL2/8axsdTNv
DAATfHj/AIJ+/CX4yePPiF4y8SeNpfD/AIy+LXib4K6p4dKaT4cE9hJ8DdF1ZZfCNushs9X8
XeFvF2kyXGo+KfDb38At20aw1azltpNGgnhAPItQ/wCCW/w51/xt4qvrL9oDxSpm0zT9Aj8G
W2i+B7q38JeFdL8H/GHwb4a0FLKG3jkSDRdK+NXiGCyvb21W9vrXStCXVZtR1E63qutAHrHw
V/4JweAfghr3jDXfDXja+dvGXw0+J/w1v7OHwb4S0a3Wy+JmnfB6wl1KQ6Va25vZvDzfCKK8
0mzug1o114v8TPMpNypoA+ZfjV/wSh8P+H/g149HwT+0eMfiFJ+z98OfhF4U8KappPhDTNMl
8S+CtE0vwLe+OdNN7d6N4d0a48VeGf7S1fxloF2H03Wtda51CK7guL65guwDt/GH/BKT4L39
r4g0LVPjV4n8PP8AE6w+JVrNYCz8GWMTeL/iVp/7T2k6hN4F0u5t1/sXwnp0f7XPjs2/wy0s
3Oh3Vxo3gV72SaSz1k+IgD7a+Ff7L+mfBr4r/EX4g+AfFEPh/wAL/FLVfDviHxX8M9J8CeCt
L0STXfDvw18OfDW2m03WbDTINb0zSntPCmk6+ujW04gj16fWpzNLbaq9tAAfU9ABQAUAFABQ
AUAFABQB8St/ykdi/wCzJZ//AFe1vQB9tUAFABQAUAFABQAUAFABQAUAfHHw2/5Pp/ay/wCz
fv2Nf/Ur/a6oA+x6ACgAoA+Kv+ChX/Jqvi7/ALKL+zp/60j8JKAPtWgAoAKACgAoAKACgAoA
KACgAoAKACgAoAKACgD4t/4J9/8AJr3h/wD7Kt+07/61B8Y6APtKgAoAKAPjT/goh/yYx+1f
/wBkM+IH/pjuaAPOv2hP2M9X+O/7UXhT4walqNpY+CvA/wAD4NH0SLSdaTRfGNx8Y/CXxs8I
fF74eTyaoPCOo6zoHhHTtR8Kw3Grat4P8W+H9f1EPceG9QtdS8M6trFndgHyZ8UP2av+CiHg
L4IalqPhD9oPx54q8UeFv2WDLqtpo/xR+IXi3x7r3xz0r4A/HjSPHuh+C7C78OKniW4+JPxv
8W/Bvxh8PfFt5Nol/wDD60+HdzpOieG9MsL19H1sA9BX9mb/AIKFzObjTv2iL/StEvr/AFzV
/C+j3Hxc8VXXib4aeHNW8U/FXWNR8C6r4g8QfDTxBbfFPXPEXhXxX8PfDfhzxz460O7l+DGp
eDpL/Q9B8TwWkVvrQBnWv7Ln/BSiK3826/aZs5biw8DaBZaXpmlfE7xnpelatfWfjrxHeeOf
DniqfxB4H8d+Iota+IngfU9L/sz4p6F4mTWPhX4ttzp/hLTJvBegabputAGtdfse/td+H/2Y
/g18JfhT8TrT4b+NvAOsftV6/r114Z+M3j/TdMv9S+JF38WfEvwMj1DxGPBk2r+OLLwv438V
eB9c8XR+JdHgW6j0bWYJ4PEdrfXen6qAcv4x/Zb/AOClni1fidJD8fNL8Hv4g8T+OvEvgCy8
GfHv4s2Vr4Wur74OfFfwr4NtZb3VPA+o6g3h+1+K978HfH194W3XPhq1ttA8QwWmitb3l9oO
vgHvnwe/Z+/bK8L/ABz8MeJPiF8dtV1v4LeGdQ+I8mk+D7f4l6trmpPo2pfE/wDaG1Pwjo3j
9PEnw/uZ/iR53wz+IXwR0xNVuPEuja/4O1/4PNFYa1rGm399L4nAPqzWPgXpPjXQvD7fGBdB
+MnjbwH4j1vxf8P/ABLrvhqx8OL4d1qa+e+8ONZafpUl1Z29zocUGl2H9qtFcT3gsRfTwGaW
WJgD8nPgH/wTz/bV+A3hT4ceCfC/xo8MeGdGtbv4Pap8TtV+HfjG58I+INcvfBn7Pvwj+FP9
mLbD4Q3vhHVtB+HXib4Ya/caetz4asLz4z+EviJZ3HxLWHxl4IXVPEIB1kH7Hn7f2t6lY+J/
GPxS8JQ+LtO1DxjBoWu+GfjX8UZNa8F+D/H+v/sJ6x4w8IeFPFeveC7zxRDpOqzfs/8Ax/uI
7e61GSKCD4jeGrCCOztLnU7Pw4AerfDn9lb9tSz+Evxp+HnxL+PkHiyPxx8MJ/DWkab4q8W6
18UIvEGv6p4A+J3gvWdN1PxR4n8K6ZrXgbw9dyan8MdTn1DQLXW7u/vdF8Q313pX9o6pqN5r
YB5Z8Iv2GP21fg5oXhnwd4N+MXgnw3o8PjDSfFfiLW/C/iTXPDU2oatLpn7Jmny61r/gnw94
C0jwf4mTwZ4K+Dnxm+Dlr4UtYfDvhv4kWHjvwr8WfFdvpvxMvfFuqWYBC37H/wDwUc1ay0LU
dW+Pmi2nj/wZ4Y8TeF/BfiSL45/FTUdNsfEGq/sraT8I7L4pa1pH/CAabY+JLqT40eFYfile
+CPEOl61psaeNNV1FdTutbsL+010A7nRf2Rf20rn4t/Bnxd4w+Mdtrnh34beJ7/xn4b1LxP8
Ttd8a+IfhVe+Ivg9+1h8Otc0i18LN8NvDXhP4wXen638a/hpqGg+MfG17p3iOLwj4KvPCV5d
3ctsdZ8TgHGeNf2CP2uIfjj8afjp8Mvij8O9N8ZfEC68XWnhvxDPdXXhHXdJj174MfsgeDtT
8Zx3fhrwDeXFrrvjzVv2d/H/AIS1Xwvqt/4q8PfD3TPiB4Y+JvgC4tfFvh3XNE10AzPGHwN/
4KPaF4+8FeE9C+L3jjxJaeI9C8WXGg+O5viv4suNB8Ljwt8OvhTquh/Dn4upoPwx0Tw5a3N/
8RvDPxEi0n4yrpOreKPF2lePLbRdc0K8TRLyK9AO8X9mH/gozqH9qTa5+0pqOmeb4K1yx8PW
Pgn4u6hENC17UPiT8VNRWx1m48T/AAc1SXxrBH4L8VfDq50zxMLjwf4osrjwFJ4Js9W0LSbq
TxDqQB73+zZ+yN4l8M+J/FnjL9pnT/CXxS8bDxZ8MviF8OfFk/j/AOJPxJtvA3ifTvgN8Hvh
/wCP7XwfoXxSS+uPBUY+I3w11fxRpXiCx1rVNc8T6drWi3fiOW21zRnLgHCS/sx/tj/8LM0T
xbH+0L4vtPCV58fvjF4t8a+HLD4x+Jp1j+GF78XvDnjP4E2PhnStc8AeINEt7Lwz8OLXxx8O
PHnw1t7PT9P8QQeMNLuIfFdxeeEPDuraSAfOHwV/Z8/4KXeKfhB8P/EeofHXxf4E1XxJ4J8L
3Oo+Cvib8S/G9/498EfE+PwH4X0e6+KHiPUb/wAGSXuqaZbeJdM1rVNV/Ztv9vgbVJ9Ra9vN
fe6uZ1UA+lvg9+zD+1D8NPit8Kfi34n8e6h8VdVtPCnxs8JfErQfGP7SXxdn8OaY3j340+CN
Z8Ea/wCFtAuvCureGvEKeFfg5oGp6UuganoWgLD4vSweHV5ZNR1DxVaAH6g0AFABQAUAFABQ
B8St/wApHYv+zJZ//V7W9AH21QAUAFABQAUAFABQAUAFABQB8cfDb/k+n9rL/s379jX/ANSv
9rqgD7HoAKACgD4q/wCChX/Jqvi7/sov7On/AK0j8JKAPtWgAoAKACgAoAKACgAoAKACgAoA
KACgAoAKACgD4t/4J9/8mveH/wDsq37Tv/rUHxjoA+0qACgAoA+NP+CiH/JjH7V//ZDPiB/6
Y7mgDyn9ov8AZy+NPxX/AGsfBPxB8J+J/F/gj4d+A/gdDf2/iHwp4khs9Q1D4teEvjX4U8ea
F4MsNJn8XWNhZxeNfDekav4U8aa14h8FeKNA1b4f674h8Izy2Fzq0N3aAHzP8Ute/wCCqPwn
+Cep+OLrxdca1q/hT9ltfiF4u1Sbwz8CdTn0z4rWXwC+O+u/EvwrH4b8K+Ho59c8TaH8cYPg
NpvwgtfDenav4R1jwqPFdr4t1PXbmeW+oA9BEn/BVCeSSXSdRhm8P3d/rV74J1PV9I+AV54m
TwTe+KvinK3/AAt3RbHUPDuhX3xDsfA83wmf4V2Pw21fQPCd7rsWp2vxY1W2t5NWvogDyv4n
+FP+CpnxN8I6R4B17wbfXWg33g/Z46ubbx58C7U6x4z0z4hWHirwj4g8O3Oi2XgTxV4Uu9Pt
/DtnFdaTJqus6bBpOqQ6Ze3mta1aXniG8AP19vdN+Kt/4u162uNU+Hw+Fl/oFzZabYQ6P4mi
+IEOr3OnQQNPfa7/AMJA2gPpwvWvpBFa6DBeLataoLnz45ZZAD8U7Xwl+3b8CPBnwa0nw1J8
RvCvxM8deC/2df2Y54LTWfhh8TdR17xv8Dv2N/2rdW8S/EGe8+Il/wCMfBPh/wAG+K/jva/C
WbUfGWs3OieNPFOk2N5Bq1jHqGpaXaTgHT674P8A+CrFr4s+KnxO0zw1c3Pxh1v4SXXwx8O6
n4Y8YfAix+FOmatoXxV+MnibwJrPgrwv4wOqanf+GpfCetfDCDxWfiLZ2/jGfV7vxcumarpu
l6bFZX4B7l8ONB/4KTaZ4/8AB1n4j1/W4vAOq/HD4s+K/iFqWux/BfxtJZ+C9Y+Jfw88TfD3
wboEMPiPw/rmifDO2+E938S/BLvaSa5498MePbXS722tNc8L2WljVgDyj9p74Y/8FCPjd4w+
J/hxPAuq3Pwj07WvG8vwjjh8d/CDTL5ZNS+Cf7YvwuXULfU9G1Hwh4iTw/4oHj74D30GieMR
q2qeHtX/ALQvH1HzND1C9IB2P7U/wo/bi8cXXwb0H4daP4il8J/D7wJ8NvEVg/h7xd8L9Jkt
/itB8Kf2jPBHxIg8f3/ijWYPE2tTW2qeJvgjJ4Oj8M3s3ha6X/hOb7xHNfm2skoA6Pwtaf8A
BSqDxnoekeIY9csPhLLrngWx1XUvCkv7PK+PfCuhr8PPF1pqVnoemeK5vFGl63omj/Ea28HX
vjHxbrPiHUfFHiXwpqsdl4T8EaBq2heI7vXADH8J3/8AwVauJPCC+LdIe1/szxj8KLPxfDbv
+zukXirw3Y+FdA0f4u61p2tWd/qD6DZXfi+18QeNPD+kS+FpdW8RaNcN4Xi1H4Z3N9pF/o4B
z2g6N/wVNhmOva7bXs+t3fhfwd4f8Q65p198BIvEd7ZaR4t+OVzqV/4J8KXlzJ4B8LeINVXV
Pg5qesaH4nk8ZWekeFm8XaNonj7xDr1npc0YB658JYv+Cm9tqHxQl+Jt34V1K/vvg98Wv+Fe
2t5bfDGD4aaL8btM0f4Un4SHTJfCwt/iRceC/EPiXUfi+dXHi6bUbu28OaF4ajuzpOqOsutg
HOaDD/wU8/4TDwDe6rfaoPBFj4t0K41/SL62/ZyfXNa8G3Hxg/Z30/xJY/EG40mFIINW0/4V
3v7T+uaNL8L7vTUms9K+GEV5Pc+L/t+lawAZH7df7F3xe8af2Zqv7LV740HjDxh4p+MvjD4i
arrnxj8XWOn6Ve3v7Pfxi0DwBbeEjd+PdIk8Eag3xJ8WeHE8Dal4a03WdB+H3iu28M+N9a8J
avovhA2LAGd45u/+Csw0T4oXXgHSGGr3finV4PhN4cuG/Z6t7bw54Vs7Hx9q/gG/17xNrviT
xBd+LZ9UtR8OfB3xZ0W9stAvrTxqNa8R+BvFdx4PaeCcAwLj4e/8FL/CJ8SaL8Hb7xJ4K8HT
eOPjd4k0TR/M/Z08T5/4WL8bf27fHml3v2/x43iPWbRbXRNb/ZBXStG+3LpGjWeoa/pT6bjT
fEFtp4Bq/ta/Aj9u3422vwL17SI9Mt/EXhLwR8UNU8S2fw38a33wy1jTNV1Wx+AesaT4XtNf
b4jjSbX4w3mpeFvilpPw/wDiTb6b4n+G/hHVLnTP+Ej0IaBqupajOAa3jG9/4KzW8fjvUvCm
l6dfs0/xJtPDmgW0nwHt549V1XQP2uLP4V6n4VuPEF5HbDwD4dv7n9jXVvE8PjbVLjxpLrtj
8SIlg1rw/Jf6bMALHoH/AAVK0bxbrlr4W16afw7qXxI+O/izTNR+Ia/B/wAYaPFa6p4o8H+I
fgx4LuYdP8QeG/Fnh74Sx+Cbnxj4O1STSf7Y8deGvGlrHf29prHhq30htVAOSh+Bf7dmt/so
/tl+Fb6x1Gz+I/xwvfG3iXQ9L8U+KPBVt8TLzxf4g/Z2+AvhfRLrwX4r+FvjXQfhj4B0TTvi
34X+Ikt5p07Wd3LpkdjqVvf295qNxqWoAD9F8B/8FSvhpo2s+CvhnNoMOneHdO/aL1nwpda7
P4L8aeFfF/jrXPiB8a/Evw70hJfGfxEl8efDb4VHwt4h+DGn/Cjw5DdeKr34e6j4d8WeDfHk
2teErXSPEOpADPAPxM/4KaeN7/UZ/A+n6nq/h3Sfi/4/8CSTfFDTfgZod94Ztfh/8YPjBogt
viNH4fj0W41221jwJqfwfZ9b+FEOs297H4X12/0i/h1C5uH8SACeJvDn/BWvxN8N59DXxTrt
j4m8Q/Bb4jJfXOj2v7PPw61/wj8VG8LeI7jwjb6b4o0zXviHp/iF5/GFrpeh6bNZWfw+sdO0
nVvDniPUPEN0dO8ZaTIAfqR8HfhD4U+GNt4k1vRLXxhB4i+Juqx+NPHc3jbxTceI9an8T38c
l1f+db2+p3/hLQZEvb6+e50nwJBp3hOC6mmj0a1TTY7KOIA9moA+JW/5SOxf9mSz/wDq9reg
D7aoAKACgAoAKACgAoAKACgAoA+OPht/yfT+1l/2b9+xr/6lf7XVAH2PQAUAFAHxV/wUK/5N
V8Xf9lF/Z0/9aR+ElAH2rQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQB8W/wDBPv8A5Ne8
P/8AZVv2nf8A1qD4x0AfaVABQAUAfGn/AAUQ/wCTGP2r/wDshnxA/wDTHc0AeBftw/tR/tSf
A7xV49h+Afgjwp4/sfh/+z34R+LP/CH634Y1xtQ8W654j+NL/C3WrWP4gW/ifTtC8JaR4M8N
alD8R9Xmv/DutlNN8L6il/PpumahJqmmAHymP+Cin7ZttqkekXXgL4X6l4p0o/Byy+J3gXwt
4R8T+K7n4V+GviR8FfCfxA8U/G+/8V+HfHmp6X4g8F+BfEOp3cMehWlhZQ67pup2lvH4utJt
Pku7sA7qT9rn9srxdpPiDWYdV8GfDHQPAfjH9lOPV9R/4Ud4m1y/8TeAfip+2D42+Eniz4gQ
zav48jtdE8Kah8E/AekfEubTI9H1XUtD0X4hm6XxVaQWWmay4B2nhz9q79qbxt8HvD3jbVho
Hw61iw/4KCeHPgt4m1XQ/h9f+KPDGpfs7ahf2tpoviuFrrW72GO38eWeu+FtTvtT0/WJrj4d
atrNz8PNcvZfFPhjXZyAWPA/7XH7RvxF+B3iPxf4t8J2/hTVtJ+Jf7BdqLzRfC3i7w62l3fx
q+JPwhj/AGgfhLqFnqGr3V/fat8D4fEWt+HPEniOKextbm3aaLXfD2nnT9TjuAD5A+IP7ev7
YXjP4EeJNC1i3s/Aeu+JPhdbeMdP+Jvw8+GfxH0TVtJ8V33wc+GvxH0P4S6NZjxhqs+n+LNZ
13VPiDFB4pm1OSKPTfBV/os/hKe5a8njAPpDw9+2x8edM0X4mxazc6LoEvgi28Van4GHiH4Y
+PPF9/8AGKbX/wBqf4/fCO0utO1e18U6Zb+EPDvgOz8J/DY6hfXNtruk6LpHiaPXdcuNO8M3
WlSWoB4JYf8ABRH/AIKCHwn4J8Q6H8JPBfjPxl8WfiP8BNP1DwJ4l0O8+G+hfBLwp42/Y7+F
/wAT/EEkfiLXNdsv+Eni8UfHG8+Jng/QbTWdRt9YtdW8Lav4Tsr3UNUlsLbSgD179rX9oz9q
j4dfHb4pyeC/Gpjsfg/491Xxf8Nvh5dfDjxDeaF4n8A6b/wTn+NXxOvNM8UXPh/xLoMnjrQ/
Fnx28Kx+HtHuZpftPhjxpa2Edg17cwW2jzAHUeC/22v2iviT+07YeBYxo/gz4KaJ+054I8Ey
+LW+FfiVbnxj4G8V/DH9ryK98Ka0PEGqrP4ZvbL4r/Bf4daFp3iiBLGS9v8AxRpWpizm8O+K
NE0q/AOC1j9p79q3wp8a7DXT4qPi8+Gfin+0/wDDnxB8Mrz4d+ItK0W7+H0v/BQP9lf4P/Ci
yeLSvEdrYReNNM+BvxC1vxv4S+JVxpmpm88MyalPf6Nqtg+o6ooBpfs3/t0ft6fFlP2aj8Uf
gx8OPhfqH7QPxA8XeDLnQNKtr/xneeBYvBth8HPiNql34iv9P8Yxx6RqDfD5/wBojw/P4d8S
WPh/UfDvibwp4ZTU5tQ1u0l8MeLQC/8AFj/goZ8ePC3xy+Kvw30pvh94S8AaD8W/ht8OvB/x
K8Y/C7xveBbjxBD+0/pnjbR7rQZPGvhqXXtS0LXvhH8OpNI1Ozv9Ps9d0zxUdd061uNC8T+H
Z7YA8w0D9t79rb413Pg3QdYstJ8B30Xxx+DGlePtK8D+EvGmla98E9csvj7+xZbzeC/iPq03
i+8tfFGjeOvB/wAbvi/pfiHw5e6V4Uk/sT4WavdS3IjTWJLAA+nfBP7YX7Tuufst+BvjT4s8
LeFfCet+Mvjh4f8AhP4m1L/hAfFOoaH8KtA8OeG7vwr8VPH+reH08Uxanrml3Hx68I+KPC3h
4yarommaVo3iDw/ONX8V2dhD4g8TAHz7Yftmftc/FA+EtC8d6NbfCS4174jfAC6l0vwv4M8c
6F4o+H9/pXx3/wCCdD+OPDninW7vxTNa+KvDmseH/wBpP4yeG/FGjT6H4eX+wvhrqQurtzbe
IHtQD3XQP2nv2tPGX7Lnhf4xa2fD3wy8TH9qz4I/CDxW2n/DLVNXsNO8G6H8SPBnwg/aJ1u5
03VvEl3cf2DffEqL4iWularbTwReG/C+n2r2XiDxHEIPGl6AM8Fftn/tSeKvgL8RPHl/4K8M
+HfGGjaz+xxp2kXV98OPGjaP4a8S/Hzxv4L8OfHL4Y654ZuPFNhqniPW/wBnyDxDdwanr9nr
mgRzTy28usaPpY028F0AfOfjf/go3+3b8PdR/aOtPHHwh+GXg7wX8HvG3xY8D+GPizdaPrmv
Jrcnws+Fvx/8Z+F/E/iX4b6Z40i13wbofx01n4YfD2DwkutautpaWXj4w6Lr3iqe+0W5QAu/
GT/gpX+2d4Rk8XaL8MPgj4K8e+KNI8RalpX2TV9L8ReCtD8NaBe/ErwppXg/xlr3jDW9aPhu
TSNT8EeLtJmeWa70uxubnUdN1uPULS0lOnzAHS6r+23+2g/xZ1LSNWsfA3w88JeC/HV/oxuY
fAGo+L/CfjOG8/Za+K3j3S9G8R+KYfFyW/hO80v47eBrv4eXumRa7p2t3MWg6V4wllsfDHxF
8NadIAelah+2J+0la/CH9jP40eK0tPhp/wAJ74A/aN1v49eEk+FHiHx9ptn4/wDA/g6+1bwR
4FsrjSL611m7t7LVtC8Q2+meKfDc0em/E+w0s+KPDkUeg6pp0KAHi2mf8FGf2th8HfF/xY8Y
6P8ACzwM3gex+COj6v4a1P4e+K7iS98QfFX9qv4z/AnWNZ03xG3xBsrS5h8O+A/hp4d8eWeh
2GiaqdXufF8VwmowaLPpiTAGF4H/AG+v2/PiR4y0PTNX8H/C74dfC7RPHf7Jun6/8YvB9nZf
EK18a6F8U9N+Ft14z1rTvDMXi3U59J+G+v6p4516w0Dx1Y32qaKLfR7SDSvFl3eWWp3d4Ach
Yft9/t4fFvwB4Qtvir8LNN/Zsu/E/wAT/AmrabdeBZdd8V+J7u18I/tHfsmaR4n+Eer32i63
GPBWuf8ACJ+Pvirf+NbDxRpyaqfB/hq/s9S8OQ2Wm+INRugD6t+N37YP7Vfwl+L37RXhbw1p
+j+M9M8O+OPEsvwt0DUPhb4hup3tNB/Zm+Bfj34c/C6x1fw/rdg2rXvx9+KPin4q+H9C8XXa
Xk2hap4C13SrPTNZYxadogB9TWH7S/xIvP8AgoHe/szQ6Dp938IrT4Q+LfEmpeJ38L+I9L1f
Q/iJocXwX1fQ9CXXry9fRPEGl+IfDnxF8SX8eoafp8Nm93oF1odpcvq/hTxOsgBsN/ykdi/7
Mln/APV7W9AH21QAUAFABQAUAFABQAUAFABQB8cfDb/k+n9rL/s379jX/wBSv9rqgD7HoAKA
CgD4q/4KFf8AJqvi7/sov7On/rSPwkoA+1aACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP
i3/gn3/ya94f/wCyrftO/wDrUHxjoA+0qACgAoA+NP8Agoh/yYx+1f8A9kM+IH/pjuaAMD9p
T9tu1/Zz8e3/AIPuvhT4s8a6dofww8MfE7xJ4l8P6lokcGi6Z4y+JM/wl0GCXSbu7j1i7jTx
ncaC+uX9jaXFronhu/1HX7tvI0eeGUA+XdT/AG//AAvZfEHTtD+HPwii8AfFv4t67+zjrfxE
1PxNa6PeXFxBrHxn/ZS+D3ifwv43k0DVBLB4q0z4XftDaPe+B9Umvr/ydM0VdRvdNj0ZNOi1
MA9f/Zu/4KOaX+0H8QvAvgB/gz4w8DS/ELQBrOg6xqviHwhq1mJrv4P+BvjZpVhe2+i6vd39
s934S8YXEFxO1sYrHWNHksJizXKPGAeK+Kf+Cpuu+IvCPiKz+FvwR8XeH/if4Vl+Gt7rtj8R
I9Kh8P2Nrqfxt8N/Bn4haHDdQ6zZrqGp+HfiHL4l+Ed7eR3EFvpni60bXo01Xw5p9xPKAddZ
/wDBVzwxqmk67qWk/Ab4oXreE/CvhrVfFCPd+GLOz0zxL4g8S+HvDQ0CDVbvVotP1LTVvNcn
tbPxPZzSaXd6tpV9pcn2WWNpFAE+PH/BRTxp4Z+BfhH4j/Db4ZafYar48+DH7ZXjFZvG/iHT
3h8FfEH9lXSrlY/C40zT54rTx0nizxLpWt2tlDpniLSLq60bTzqdoW3TR2oBoeIf+CpegeHI
PFUNx8B/iXe658PfBnxx8XeP9O0688NXFjoi/BPxR8f/AAhqNvp+vPqcWla9Dqms/s+a4hur
GfdpcHjLwJPe24i1a+fTAD27wP8AtoX/AIy+JHxL+FF58GPGHhTxP8LvA+s+JPEuqX+peHtV
8L2WtWfgzwL4/wBG0ePVtM1JotSsfEPhn4i6LJput6c09h/bOjeLtEvZLKfSLefUADzX4af8
FGtJ8ZfB74z/ABI1D4ceIIr34Ffsx+Dv2i9b03zdM0y48eaZr/wqf4i3kfg62k1PUtOgt2vb
HWPC8C3HiO+l0vxFpl7pGvyWEsUE94AavgX/AIKMeGvGPxP8O/Cq6+E/jjRfEF98SLn4V+Jp
TeaDqlroPih/Hnx58B6Zc6cdN1Cd/FPhxbz4AeIdT8S67owlt/CmmeJvCNxqabb++OnAHifi
r/gqXN4X+N3jzw3B8L9d8T+BNKs5fBfg3w/o0dj/AMJ7qvxU8KfFj9o3wJ4xuPEDzaotj4T8
O6xZ/AmZPBNnrsFrd6tea94QuZrq1h8U+VpYBhfFb/gozo+gfELxl4j8P/s52sPjX4a+Bf2k
9DvfHPjnUdGsvF2h6V8JvAuq/EzSdN0PToysPiXS/iHc+GrzUNP0bSPGNhHqK6ZdWFxqdn4g
0XxDpuggHWfFH/go/wDCaxuPiJ/wsT4GX+sXn7P3iXxl4r+HV3qWqeEbxfFPi74SeMPGnw21
jV/BcAvrzUtF8Si3tb658NRT2q6hfaVreoAvb2VpqN0ADC8G/t6eEor7xlpbfAHQ/DvhP4ke
O/jjaXujaHqGjXl74+8RTfHH9mD4FeHvG/xJuDJplv4It/F2n/tAaP4k8Y3WsafrsA8Kabda
tDrbwaRb2+uAHpHwN/4KK/DbX9Y8LfDTwt+z98R/BngqDwiYPCtt4d0HTdbu7W60H4UfD34m
nwlonw48Gy6l4muraDw94ymttLvtF0m807UhopvdPe40+/gugAcfaf8ABSmbSrr4o/D34q/C
e/17V7T4kfGvwz4NvNLutA0Lwv4p+Hng/wCKH7S3hSCLxW+ua5I3hHWbLwr8BLvR7sa79lh8
V+LNf0Gz0u2shraW9qAdV8LP2+/Dep/Er4MfAX4U/AS58EeBtb8a+Gfh7B/wk1/pvgQ+E/B+
ufCL4k/EXwvrGi+Frayu7G7W8uPhtqXhiHQ4NTivLbXLbWNC1QWHinSb7RIwDmfiT/wUS8f+
GviT+0Zpfh/wxob/AA1+Dtj4Q+IXhLxPe+FvFd7N44+FHwX+M+i/DX9vq+0+7jvtN0zVdZ+E
+ma59t8IyaA+pQQ32kX0euWd35qQRAGz4A+Pf7UXxq+Ndl8DPGXwv+Gfiz4T+JvhX8MPHXxo
0q68M6lo6+HfhF+0PB+1Xb2uk67faz401S31LxJYaP8ADn4ReHdX8Hw+GL5dfvPFnjy4nuNF
0rTbTaAdd8Gf2+NO1/4k+AvghcfCzUdMttZ8Z638N7PxRo93oFl4c8Oz2Pjj9srwj4K0f/hH
zrd9rEtuNI/Y08SQ3epWga2L+IvC14lnYx6nc6dpIB5Wf+Cl/jfQvjIul+M/hRbw/DK11v4t
+AtfsfCetWHiPxvoeu+Bv2wU/Zj8HeLJbeW70y4vLfxet7pesXPgmx0a61qytLtNXsdQ1KyM
Ed2Ae9+H/wBviXxf8GfhR8VvDPwL8b3N98ZfjJonwf8ABPhHV9c8K6Fdahc+JvhzqXxH0TxM
2q3+qJp8GjNZWB0HUo7h4dQs/EUGpWsFre2tpBeXoB8++M/+CmPwZ8dfD+y1Lxn+zt4z1Pwn
qOtap4i8Ow+O/wDhFNEgvtK8A658O7GfV9HfWNVhuLL4m6LrXxE0Y2ngyAW/iSL+y/EN3YXc
kGlXMpAOj0L/AIKdfC7QD4Z+G/gn4CeNxcWlzoPhLR/Bfg6HwwtjoCW158ZdGvvDSQWd7baX
oeraNH8EdXTRfDt42ntqseraOts1vCmoy2IB6T8LP+Chdl8TPjnpfwxufh5F4B8JPafGiLX/
ABd448ZaVpGp6Rr3ww1z4K6VoGlwaIbd7HV08cWfxk0jWtHvdK128srzR5dP1LSLnVbS5nlt
gD9J6ACgD4lb/lI7F/2ZLP8A+r2t6APtqgAoAKACgAoAKACgAoAKACgD8vvFngfUfEH7aH7W
viuD40/Ff4S6Z4I/Ze/ZV1bVofhpd+BrWHWrW08Rftd6nPc6s3jPwX4rzPY29jLHZtaT6dAk
c8xuVlOySMA+Dvgx+0x8XPj38M/AXxJ8DfGP9o2yPi743+EPhFH4M8RfEn4J2virXItZ0P4Q
eIvFmteEo7T4C3mn3Vv8P9A8cfEDxD4lm1i80m1s9O+HlvDJcLeeIFhsgD60/ZW1/VP2pfFH
7Reh+H/2rf2pNItfgf8AFDR/BOlSXGufBuXU/E3hjXPh14P8Z6R4y1HTH+B8Enh8azf67rdp
puk3DzXn9laVZ6hdi2nvntIAD7G/4Zh8b/8AR4n7Un/gx+DH/wA5mgD4+/bx/Zy8Y6V+zL4p
vp/2r/2k9aij8f8AwBiOn6tf/CNrGRrv9oT4W2cc7iy+Edlc+dYyTrf2ZW4WMXltbm4jntxL
bygHHftAXPx9+Bfxr8OeFNR/aT+MzfCPUPhh8V/jPrvjS/8AHfw1j8UaT8O/gG/wnu/i7qEX
hqw/Zx1CC61Ox0L4lXuo+GtNj1PfrE3hia0nksX1K1egDjn/AGmPDBsNQ1O2+P8A/wAFBryx
0Twr4b8YeILiHQvgukWj6P4w+I3ij4XeGJnkm+Eka3ya74p8L3EOmTacbqC6t76ynjlYNJ5Y
BgXP7WPhFNCl8Tp+0t+3FY6XoUPivV/FljrNr8HrPXLfw94U+EH7RfxPvrzQrKH4MXMOq3gv
v2ZPif4YFtJc2kct5oE81tNOmoaIupgG34t/aQ8OaX4e8TjR/wBqf9s+Hxtodr4z0e40XxFD
8HrOx8N/ELR/E/xy+H/hPw14tu7b4N3LQQeLPHnwA8eaTb3+mJqEFnZ2lnfXzW0Op2DXABiL
+1x8PdJ8F6b4g8VftYfto2+rXXh9rpbLSIfg3d6ZrPibw+vhCw+ImgaBqlx8HLWI/wDCIeJf
Gej6At3qo06LW7y6hj0Y3rvtoA9w+HnxD0z4hw/FCSD9p39t7w5L8GvCOseLviTbeKIvghpU
/hS3sbaz1TRtN1YS/CXbZ6l4u8O3n/CTeGopmRL7QoJr4yIiruAPIIP2tvhP9nXVNQ/a1/bg
0zw5B4b8TeIdY8TS2PwXu9H0WTwpbftP3OqaNdTWHwiuZbnU2P7IXxpishYRXVvetpGlSW87
w67pklwAVte+MvxQ8P8A7Lnxs+O1x8d/2nZfHPgP46/FH4KfDz4WT+MPgnbX3jnWPBHiK7td
KtbnUrX4I6hBZald+GNP1PxFqaWS6jbQW+mXTwzSREMoBwniT9q3XtOvvFOneHv2i/2rfFDX
fxP+Cmj/AAb1fTdT+D0mhfEr4f8AxP0P9jHxVqzpfL8FT/ZnjjTPDX7WKajpOnXMY0fUxoNv
G2qxzS30doAegN+1l8PfsKakn7S/7fElk9t4LtzOujfBrani/wAd3nivTtF8ByA/CEMviU33
w/8AiBbyx4Nlu8JXjx3ckd/pT3oBtX/7Q2gjV7PS7D9p39tW1Fl8Q7DwP41ufEsPwh0MeERr
Ggaz4q8NTanbSfBWW7s77xl4X0lvEvhez1GGyjudDM17e3NkIsMAc/Y/tQaR4g1S1tfDn7Rv
7Z0mgifwHBrXjLU9X+AsOh6JeeKf2t7/APZL1bSZ4NP+EeoapfXel+KNIvNZs7/TLO80W+0+
602WXULW2lnuoADQi/as+GNxbeGL2D9qz9uiW08SHTL+S4TTPgyU0PwrrmifAnxTovjDWP8A
i0OYNG1Dwv8AtD+ANZ2R+Zf2gbV9PvbSDU9NuLRQD61+AehSftEaF4v8QeCv2uv2vLO08GeP
td+Her2uu3HwVsNUg17w/Bp9xfR3emH4PPeaZII9St3Wy1OK0vxE8Vw9ssFxbySAHu3/AAzD
43/6PE/ak/8ABj8GP/nM0AH/AAzD43/6PE/ak/8ABj8GP/nM0AfkDo174/8A2aP2Ivhn8S9L
/aS/aAkg8S/tSfGH4a32nf2t8PodJ0Ww1X9oP48/bvEsVppXwJ8X+ItSuxJ4e/tG90+xtLl5
57++ls44IYobRQD0XR/2q/Br+CbzxL4k/ae/bW07VPDHgf4c+I/iDbaNJ8FNf8LeEfEvjjw1
8IvEWo+FbjxxB8HIvD/keF4PjP4Ve88TXlxZaDeWEGt6haXkkGh6t9kAIfGX7TNna6l4ds/h
9+0z+2R4vMnjnVtK1+w/4s9Fq2s+DvD+lftLadrmq+ALaL4MTDW9dtfiT+zf4j8H2uiXbWM+
pJPb6lYmaz1HS57sA3bj9qv4Q2a3d7cftg/tuvoFl4G1z4mz+JbHSfhHqui/8K90vTfiVfWH
jGG5074NXLXOgeIrr4Q/EHRtI1CBJIDq+jW1pdPbtrWjm9AOV+Kmi/Ef41f8E9v21fHviH9o
j9pHS5fA837UPw0PhDV9c+Duo2mpab8LfEviHwrp8muvpPwktWWbWdP0+3utSt9L1MxxSTuL
PUHj2SUAe1/tNXMPwM+L/wAAPhr4i/aU/aG8Tf8AC8PEUXgjx/rV7qHwJe68EeA/FF/D4K8G
3eo2k/wKupdZ0rxf8YvE3hDwhFolzNb2L2194i1gefJo0tvOAeD6N8efgdrujN44tfjD+2W/
hXT/AAR45+It14wXwL+zzdWemfDL4LeD/gn468ReLXkt/gtLfJpnhbSvjP8ADq1g0+GJtR07
XbbUtCisoNU8N31taAGxb/Hz4BaBfaiB+0V+2R4d1Twh4cuda117fwB8E7S58Lzef418OaDp
Mt7YfAwCJfFkfw+1XTvDer2c7+H7+0ufD9oNSSLW9MinAPa/hXbWvi34QaR8Qvi/+1F8f/h/
e+Jfi98d/hhDoFyPgbrCTah8IP2g/iN8P7ZruW2+BlzbyX+pXPg238V3wDzWkGv6hcXNrdXT
ol9KAfNnxe+KNh8EP2o/iB8GfHfxp+NNt8PPh14Ij8R+JPHFt/wpSXXrTwXafBv4kfHzWLiD
R/8Ahm7+ydSh07xF4FtNJt/B9nr0mu6hqXiu38W2OkzW+j61cWgBveMfjv8ACTw/YQadrnxc
/bev9N0/w9q3i6TTG8CfAG5sdG8zS/2ndV1RI7O5+DAtVuNU0P8AZg+N+qLqNjG1jrmk29nd
w3t1b+J7BrwA1PEnxm/Z+0bUbi1vf2j/ANrC/wBMh1Pxpo1p4jTwd8BH0W8t7fxV4k+H/jq8
S5ufggr2lhqfxT0CD4c3q3qW8nirxT4l8ORwxala6tDckA7vQfiR8LtX0D45fESX9pf9sbQ7
b4I6INJ8earqnhL4LW97eTad418SfDrUvh9a3sfwPeS+1Hw/8RPDmr+F73w9cTrbwXElpqsM
T6NqNrqEwB81XH7RmgeDvhR8V5tS+Kf7UX/Cz/C3hj9onWfEPw18MaZ8A28P3Gj/AAZ+In7T
Pw48Cab401y1+BZ0iCPxjpH7NXiZJ5Zl1HRdFu57XRxcyJq+hjUQD0Lwr8YNF0jxBpvg/wAb
fHP9qLTPijaeKvG/hC61TwfovwRk8N6L4mi+J3j34ViGfW5/gTZalplx4z8ceA5rC7NvDcwy
y6rY3VxeXtok93GAchon7QPgHW9NsvFHi74tftN6JofiTVrLTdY1y8sP2fdYk8ZazP8AAb4T
fHvw++i2sHwGm1O/bULr4meE9H06TxhBok0V5axajIIZoEjiAPc/h54r+E/xX+KujfBfTPjv
+1rHrPifxRrWj3l5rPhD9n5fDtn8S4NN+P8AFr+hazct8E5kl8SPb/s6/GvTbrVBHcQX8Ghs
q6hcWXiDTnvgDiP+E38LfEb4l/Cr4T/CH43ftE+Jdd+KHxWi8N3useKdE+AOm6Lb+AoLX9ov
xBqXxAtg3wKnutS/tDxL+y58QtI0+xmig1CHU4tO8R3sC2Vzp816AcfB8RNd0rxnJoXjP4pf
F630rxf8R/jR8MtF17QNU+B+qzxaZ8IP25PhT+xDra/ECwf9my3msYPFi+P/AAX4o8PxQyap
pk8WhXug6jNa2+h216ADsbX9oH4O/atK1Hw98fv2y9W1OfxfqXgv7b4a8Ofs+Xl3pWoabqX7
M3giznbVLD4On/iX6kn7VPwT0ywms7mRY9P1O60+dYU0G+t7YA5+/wD2hvgtqmlw3Pg74x/t
kfEDUtaHwcGs6PZ+Ev2ebL7Fq/xn8e/DKz07QfEuqa38FrXSrfWdLuvixpHi68Oo3Ysb3ULf
U0sr2fW4ZQAD0bw38T/hj4z8eaH4Q8D/ABy/bR8U+IPFvxf1jwfpGpaV4L+A6Wep+L/B0nxB
tPEXi0avcfBWBJZPC8fw48fS32ptK2sWdjZW9ygFv4k0d9RAOWX4peHPCviXxb4M8efHX9ph
/FNj8Zf2ifhD4M0jwJYfALXdQ8R6d4H0rxV4ye1Omv8ABC11BdV+JEHg3WrW90+1t7nTNR8T
JaQahdSyahbuwBbuv2n/AINabHrHijT/ANqD9tnUki+GWt/E688Q+HvDnwUvjqnwz8JaF8S9
c0zxAmqWXwaMl/4f1C7+F3xL0HQp3meztNe0eSzmNmda01r0A7Lx5J/wqrxx8Eh4j+MX7Tnh
jTvi34J8c+IdLsrzS/gBZfEey+I+m/HL4D/Bv4e6BDaW/wAETZQf8Jprn7SN7fvrNzqtqmkR
XNxf3U8dtqeqzIAcTpXx0/Z58Qa1o6aN+09+1NfeIvGmh+CvFvhqYeHP2fI9W17XvGHxA+EH
gjSdIu5rj4LRXeleJbDxz8W/h2t1deIJbCGJ/O1mG+e30W4u7cA5Lw38Xb/QPA37G3jLx98Z
f2i/D/gb4/fAe7+OOujwhF8DtST4T+NX+Jf7PPw6s7uPTo/gTbRnSG1b9oOY6rrtii61ZPZv
cC2mtp9QuIADA8c+Kfgn8ZYdV8Ba58c/2ivEPwev7H4xaj8Qopbv4CaF4gb4m+ANZ/ZHvvDk
miajpvwgs7S5bxrof7UHh+/vfEcPiC01GOezbR76V3k1K3hAPRNA+N/wC8SXaPp/7QP7XHl+
I4vAvijwvq1z4N/Z/toPHHizxtB+zRr3hC0sLmX4KK6+Kmn/AGzfhFcHUtXNp/Zd54m1+4n1
C3bTNZljAJ9I+J/w/XxnaeA/Evxe/a00HUR8TpvCNulv4X+AV5D4Qv8AWPFX7PfgX+0fFCp8
DI00nVdR8eftCfDTR75tI/tJZluo7176dNLv/sAB9UfsxzW/7VfhLWPGvw9/a2/bCsdB03V7
DTLKfxDcfBCxl16DUvBfg7xzBq2kwR/CKeWWwh0vxxo1hqJlWObS/EEep6Dfxwappl5bRAH0
t/wzD43/AOjxP2pP/Bj8GP8A5zNAHhnww+HOsfDn/gofqNnrHxX+JPxWk1P9jAXMN98SJ/CM
95pCQfHCKJrTS28JeEfCUC21yzia4F7BeSmWOMxTRJvRgD9K6ACgAoAKACgAoAKACgAoAKAP
jL4fW8F3+3F+1xa3UMdxbXP7PH7HNvcQTIJIp4JvFH7Xkc0MqMCrxyxsyOjAhlYggg0Ae1at
+zz8CtdPhI6x8Ivh7qH/AAgepXms+Cxc+FdIdfDGqajdaVfX9/oq/ZQthc3t5oWi3N3JAENx
NpWnvLvNpAUAPRdK8L+HND1TxLrej6Jpmmav4y1Kz1jxXqVlZw2974i1XT9G07w7Y6jrNxGq
yahe2mg6PpWjW9xctJLFpmm2NkjC3tYUQA3qAPir/goV/wAmq+Lv+yi/s6f+tI/CSgD6n13w
D4I8Uavp+veJPCfh7X9Z0rQ/EvhnTtS1jSbLUbqz8O+M49Oh8XaFDJdwzFdI8TRaRpcWu6fz
a6pHp1kl7FMttEEAOOg/Z/8Agjb6dPpEPwp8Bppl1oOi+F7my/4RvTGt7jw54b8R3Xi/w9ok
8bwMJdM0TxRe3ev6VZyboLDVbma9tkjnkZyAZk/7Mn7PFzBc2tx8FfhpPbXlve2d1BL4Q0V4
bm11Gw8a6Vf208bWhWWC90z4kfECwuonDJPZ+NfFFvIGi1zUVuADQm/Z6+BVxdSXtx8Ivh3P
eTS+JJp7ubwno0tzPN4vutbvfE80872jSTTa3e+JvEl5fyys7zXfiHXLncJ9X1B7gA82+JP7
FP7NnxP0KLw/rHwx8O6Lax6toesNc+EtOsPDt/cT+HNOk0vSbe6urG1V7ixtrY2zi1fMb3ul
6NfuHu9IsJYQDrfh/wDsy/CD4eeFPHXg2z8OHxRpPxNS1tviFN4+mXxlqnjTS9O8Lab4H0fR
PFGp6xFNda/pGi+D9J0/w3pdrqz3jQaXb+U8ssks0sgBeh/Zo/Z7gjeGL4K/DIQy/aPNgbwb
ockE/wBrh8e29358Mlm0U4u4Pin8SorsTI4uU8feMBP5n/CRar9qAN3Qvgh8H/DFno2n+Hfh
r4M0Sy8PeJNW8Y6HbaZoNhZxaV4s1/Q9Q8Na54lsVhhTyNd1jQNV1TR9T1VMXt9Yalf29zNJ
HeXAkAObs/2Xv2c9Os306w+CHwws7F9N0bSPslt4N0OGBNN8OxeFbfQrWCOOzVbdNHg8C+CY
NOaARyWkHg/wvDC6R6DpS2oBrt+z58DW0290c/CT4ejS9Rj8KRXtinhTR47e4XwK93L4NZ0j
tVxL4Yk1C/k0SdNs2nSX169tIjXU5kALmvfA34M+KF1dfEfwr+H+uL4g1LSdZ15dU8JaJejW
9V0Hw3N4N0W/1cT2T/2ldaT4SuJ/DWny3nnNaaFNJpcBSzdoSAY9p+zb8ALA6YbL4NfDe1bR
7lbzTHg8I6NHJZ3aeLdP8fJdRSLah/tCeONK0/xgszs0i+JrWPXAw1IvcsAIP2a/2fVsYNMX
4L/DRNPtftwtrJPB2hpbQLqQ8MLexxQpZhEhni8FeD4PJUCKO18LeHrWJEt9HsIoAD0Hwl4E
8GeArXULPwX4X0PwvbatqP8Aa2qRaJp1tYDUtTFjZaWl9fNBGj3d1Fpem6bpkEs7SPBp2n2N
hCUtLS3hjAOsoAKAPgr9h7wh4V8X/sueBV8VeHtH8Qr4b+O/7RfizQF1iwttQXR/E2j/ALUH
xq/srXtOFzHILTVdO+03H2O+h2zwedL5brvbIB9DWv7NX7Pthpd9odh8GfhvYaLqdjpem6hp
Nj4S0ez0290/RbGHS9KsrmxtrWK2ltbHSbe10iCB4jGNItbXSmVtPtYLaMA2LD4EfBbS9Ui1
rTPhV4A07VrfxDaeLbfULDwro1pd23iWxTxClnrdtNb2kbW+oW//AAlviqSOeEoyz+JdfuP9
frGoSXABCPgD8D1tNNsE+Efw5j0/R/Bd18ONM0+PwfoUen2ngC9gv7W68Fx2KWS2p8Ly2+q6
rD/YbwtpyJqupiO3T+0bzzwD5i/ba+H/AII+G3/BP/8Aa08P+APCmg+DtEn+D3xO1mfSvDum
22l2M+r6po9xNqeqTQWscaS6hqM4+0X95IGuLu4LT3Ekkru7AHoH7QWsfs6aR4/+Evw8+Lvg
TS/EHiT9qvxHH8ItK1WfR9Gu0jX4X6F4u+NfheXxTqN/dW97a6NoPivQ0TwbPYwajcad8TfF
XhmSztrSa/l1K2APNPgn8LP2C/gzo9x4O8D658NNVtNTsvEvhFbbxV4q0fxQV8P6v4b8B6d4
y8JWKarNJaW/hvXdC0LwFqXi/S7aFNM1yZtJ17WY7mXULa5kAPWh4b/Y0vLVoH0v4FXVpqfw
/wBV0C4juY/Ck6aj8OtPuNabVtK1BbksbzRNPuj4kae2vvM+xTDXyFiZNSIAN39lLxr8OviB
8GbTxN8LPBFj8O/Bv/CxPjf4at/DWnRafBYnXPAXxt+IXgHxd4gtRpkcNrLB4x8WeGNa8XRX
TRRXt4muLdapFHqc14oAPl/xT8f/ANkrxF+2R49/ZY+JH7O+s/8ACbJbeEda1/41+PPAPwyu
Pgz4t1pvgr4+8V6DosXim78ZX3jK617R/g/b/FXTZpda8Cabo1nolr4x0X+2JNP1ApqIB7Xr
Fn+w0YrWHX4/gA8cnhmC3tl1iTwpI0vhWx034m6DDATeu0kmnWmleKfjBpLRyllhtta+IVnI
qrda+jAHRzaF+x9pN/4h0e40j4E2uoalqehweJdNnsfB5mvdX8NXc3j3Qk1G0kibz7zR9U8K
T+L4N6NJbazoM2tyY1Oxe4jAN2z079mLW9H+K0VlafCDU9A8V2cmufGO3ij8NXOka3Za5Dd3
c+reNbfDWdzDqu7ULm6vdRQi8v8A+0J7iSTUFumAB8j6R8T/ANhqb9nTx18a9e+FHww8M+HP
DXh79qbStY8D3OmeDJdd8T+DvhB8VPjJ4e+I0On2bGzt9a0bx94j8KePfFemW2omFL3/AISf
W7zUUtbu78SOoB1Pwo8bfsh/FXwnZfEHxN8G/A3wy+Ims6n4p1PVPh345sPAB+IjeLPCni3x
XrOv3NqdP1G6i1ieTxtpvi3WdN1R7izvbzVzf6heWmm6nNdQoAV/CXjT9gjxifBlnonw0+Gp
/wCEi0prHWLW78L+AIYPhlHpf7P/AIX1waH8QQdTktNNu7X4N6h4V8Jx/wDCPt4jtY9PXS9J
F6uj2ttdoAfQfg/R/wBkxPGfhqPwPYfBhPHsMFjrfhVPD8XhpfEix6fo3jawstT0tbPF8Z7f
RfFnxGtvtUWbkW2u+NVlcm81zeAeTfETx9+zD8GvFnwwn8D/AAt8D+Ovil4//aI0r4e6Dp/w
6svB8XifQfHXiHQviRqHi3xjf3e6G4sIfDfgkfFvUtYNoJLy7bUPFmnQQi51nXp1APnX9n79
qf8AZJ+OfxN+N/w41L9iv4r/AABi8E6vNrnj34kftD/Cf4OeEPh34u8X23i/wB8U9MstO1zw
/wDE/wAba5f+KPEGs/Ebwn8aNDsta0DR31BribxbO0OvWzRsAfXGl+Df2GdLF9pmjaB+z1Zf
8IkLa+vrHTbXwfEdF2ap8Ols7hre2AMLLq/gH4TJaNGpYXfhb4fxw/Np3h5UAOK8CXf7Hfij
xB8YPAD/AAt+EnhWw8G+LvBHwaiur6x8Gr4f+KWlav8ADj4VfHPwheeGhAiJqOkaefiX4ctN
PaeN5LDX9Ptm065MM2kSSAHqfh6+/Y+07xJ/anhe5+Cln4o8P+Ita8Ux3ujP4bi1HSfEviga
f4b1/XbWS0w1pqHiD/hYGm6bqN7bFG1RvGtqJXnfxEj3gB8J/Ef9pr9i7Tfi18QPB+q/syfE
vRfib4a+K37QvgnVPit4Y8D/AAe0rXdJ8Z/CT9nHTv2ofEvxQ8P+LLj4jweItOt/FXhHxvJp
fw58XXml22q3HxCudZs9b07w3odzP4hvgD1u+8afsZ+A/iv4d/ZQf4MeFNWtPCvwZ8GeAbHW
bPS/BOp6Novgvx7rPxJ8Gap8N/EyX15Y3KabpVr4R8Q6n4qsR/au+PxFqXl6VJez6wHAPqHX
tb/ZQ+IMHhbU/EWqfBzxhDdLN4C8HX2o3fhzWS39oa14I1R/DmgzySTvG914i034calDBZsk
j6zaeDL2BvtqaLLQB0A/Zh/Z0WS7mT4HfCyKW+srDTrp4fBHh+FpbLS5fCM+m2/7qxTYtjce
AfA9xatHseC58IeGriNlm0XTntwDaf4C/BOWw8F6VJ8KfAEml/DmxfS/Aemv4W0d7Dwjpcmo
aNq76XoFm1qbbTdMOq+HPD2p/wBn20aWY1DQdFvFhFxpdjJAAc5b/sr/ALNlpaQWFr8CvhZb
2VqwktbWHwVoUcNtIreDHSS3jWzCwSxn4c+ABFJFseJPBXhZI2VNC0xbYAtJ+zJ+zvFYNpcf
wT+GUenNYPpn2FPB2iLapp7WHgfSxawwrZhIIo9P+Gfw6tLcQqhtofAnhFbcxf8ACPaUbUAm
uv2bvgNdveTt8JfAcN5fTC6m1G18N6ZbaiL5NS8I61BqMV7FbrPHqFrrXgDwNrFreK/n2+qe
DvDN/G63Oi6fJAAc5+z7+yj8F/2ZdMm0v4VeHp9PWWIWkV3ql/Pqt9YaYNO8PaY+k6ZPccab
pl3H4W0W+1Gzskgh1LWbaTWLxZr+4lmIB9IUAfErf8pHYv8AsyWf/wBXtb0AfbVABQAUAFAB
QAUAFABQAUAFAHxx8Nv+T6f2sv8As379jX/1K/2uqAPsegAoAKAPir/goV/yar4u/wCyi/s6
f+tI/CSgD7VoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA+Lf+Cff/ACa94f8A+yrftO/+
tQfGOgD7SoAKACgD40/4KIf8mMftX/8AZDPiB/6Y7mgDkf2q/gR8DviZ8TvhVe/Ez4oat4N+
KfinVPC/hj9m+1S/SJdK+Ifws8TyftA32o+FrIWkkU2p+ILLwFaWfjJdWn+xat4W0G20C1MF
9qEMd4AfLP7PH/BNz4R+D/AmsfD/AOL3xa8K/Ee41X4f/E/4KWUfh5vC2gahBoPxT+HfwD8A
+MZm1Swxrk/jWyHwH8Mt4U1eK4h1jwvolxFoZnvDE95cAHq0n/BNL9lTUv7Xum8VapLd+LPh
veaVfajYa9oFo9w9vqfjXUX+JWipY20drpF7b3fxA8RJrI0aK28K60t4Y/EGmXpaTeAe/wDw
I+Dn7P8A4q+C+h6b4V1e/wDih4I0n4tfHjxNpviK8vr3R5v+Fga38cfiHqfxRiRfDv8Awj9r
JaaZ8TbrxfplnBHavpiWtnEun+dYi3mkAPmr42fs5/sV/Gj9pz4l6F42+JfibS/jz8S9F0bw
F4i0HTLzW9FSLw5qvwC+KWk3HgrT9Z/sdNAEvi74XXPi/wAaTWqavJr8Z8FTatpctpDpOqRM
AaXiX/gnf+yh4gtY4tX8eLC154LXR5LiHVPA1mL7T7vw1+1R4d1DxDbxDThb28mtf8NbfE/W
rufT44dPk1qz8OX0MaNo0QoA6DUf+Cdv7LFzc67beIPFGuXWoS6vDc27XnjKzs9X8M32tePb
v4xeLba3uoDb6i8/j6+l8TQal/a8t3c2fgTXPEPhvw42l+G55bZADsdN/YX/AGck8KftJeF9
E1i8g0T4+fbr7xdPpOuaal34Mtdd8Ua98UoIdG1O2Qz2+h23inxTqviXRNM1yS+0q00u6XRr
SAeGAmn0AfNHh79ij9iT4w6X41vdJ+KuueIE8SeG/jN4K8Ua3eXWl2MEVx48+N/7Uui+J9U0
ea+0S00XRdX074k/En4/+FdMTQBBbajYi1E9pqGnWegXVAHtV5+wF+zjqfxA1Pxh/wAJ9qv/
AAk6ePbvxXLaQa14VL6Nruo/GHxJ8VrjR4Lf7A1zYWs/i34hXekSaadjz6ZfWGkyK/nosoBw
ur/8E+f2SfDfg422r/E7X7Xwt4RtbjVZUg8R6JJeRap4G+AngP4Patq0v9l6fJrWr32n+Fvh
d4W8TavoIW9tpdatrvz9KksNWvbC6APWvAf7FX7O/wAJPidovxf03xzd2/ijwf4xTxNezaxr
vhuGBvFN94e/aQXV7fUt9rBLpVtrg/aZ+JXiOXw3aSWGm2ZtPD40uws9L8PWUEAAnh79ib9n
D4IfEHw18YpfF2q6Tqfw41jxJ8RtGTxJ4g017Cx8PaZo37QlxqUF1HeQfbNS0rw2v7SfxP1y
48Q3cl1r0SS6JDqGsSadoWmW8ABal+AH7P8A8fdL8R/EfTfiB4g8j4+fFPwp+0h4c1CS6sdM
kTXPAXwg0f4IWWreH/Duv6aiar4Wvvh34djlng1vTNTsJjep4ltjHMNPvIgD5/8Ahp/wTc+A
ugXPiLWtX+JtndWunePpPFHwNufDuvaSqeBfBnhq5/ZzudOt9dvdQm1I/ETULTX/ANnjwU+v
XPjCXW9HH2i9t0sLSbWdRa7AOjtv2BP2OdOuE8O6b8ULmCXRPCfgvUZNBuviHo908Xw50/Qv
gX4B0We5M8x1O20XXNV/ZN8BOPFtrc2uq/2rpHibStL1u1s9X1OxlAPPv2cv+Cbcfwg8WfDZ
Pid8Tfh/4x074X6ufic0Fnolt4f8Ya3JpXw++HngeCw8TXdvqMVtq/wwj8QfDT4e/EGCy1vT
L660TXvhp4BsY9dltLTVBqYB6f8AED9kr9jr4s+PPiVfXnxa87xp8T/FPxuvfFkvhzxL4fvp
9Mu/jB+yl4W+CPivRry8tbO9h0LT9N+EEGheJ/D8esXFsF1XVLfVYpbtry3iYA3T/wAE/v2d
r34gw+M4Pif4il1bxF4o1bxt4f0mPxL4YuYrq51H4gfEz4m6vHpbNZSaprWnnxl8U/Hl5mW6
vzY2N7FodvLBpGk2NlbAHhfiD/gmZ4S0rxv8GdU+D/xy0vwt4d+HfiPwvZT6drlj4S1++m8V
+EdL/Za8N2cemxywLp3/AAkSeGP2YfCOoWlqLJNVsvH+ov4ykkuf3mnXIB+tnhnxn4MvbFNN
03x9oHie70LVp/Auq3qa9o93qD+MPD6Na6zo+qJZzKkPieCa1uJdU0kQw3VtMs261iRcKAbl
v4p8MXcEN1aeI9Bura41GHSLe4t9X0+eCfVriFLi30uGaO4aOXUZ4JYp4bJGa5lhkSRI2R1Y
gHL+Avi38Ovib4W0jxn4M8VaZqmga5pupaxp1zLI2m3Mml6Pql5omq38unaktpqFtaafq2n3
ljdXNzbRQxT27qz4wSAdHYeMPCmrbP7J8TaBqzSySQwx6XrGnahJPPFaveyW8EdpcyvNcLZx
vdNDGGkFurTFfLBagDh/Bvx2+E3xA8OeA/FnhLxtpOr6B8S9Gn1/wfqEP2lI9Q0y10G28T3k
94JYEbRHsdDvLa/vINbGnT2yTxRyxrNIkbAGh4H+MXwz+I3he08Z+EfGWi6l4cvrrxVaWuoy
XaWCzS+CfFmqeB/FLpFqBtpmttI8VaNqGjz3qxmzkuIUeCeWC4t5ZQDtNO8QaDrEjQ6Treka
pKlrbXzxadqVnfSLZXoY2d4yW00rC1uwjm2uCPKnCMYnfacAHx43/KR2L/syWf8A9Xtb0Afb
VABQAUAFABQAUAFABQAUAFAHxx8Nv+T6f2sv+zfv2Nf/AFK/2uqAPsegAoAKAPir/goV/wAm
q+Lv+yi/s6f+tI/CSgD7VoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA+Lf+Cff/Jr3h//
ALKt+07/AOtQfGOgD7SoAKACgD40/wCCiH/JjH7V/wD2Qz4gf+mO5oAx/wBpv9jy/wD2g/HP
hn4kQ/E7VvC/iL4XRfD/AFb4QWEFl5mkeFfGfhP4q6L8RfFWtajHHeRLrdv8StE8NaJ8Otbt
L62mXSfDsd9c6Vi8v7kSAHxJ8AP+CVXiWy+HGq+GPjv4u8PW+vy/Cr4u/CzTNf8AAMWo3/iG
O8+LPwy/Zz8Cf8LOOv6/L/xLvGvw+PwHXTfBc2lWFrDdaFqjalrEaa9f6o0gB6fe/wDBKHwr
enxLOvxf8V6de+JPAFz4dV9Os5hZ+HPF91qvxG1O/wDFHhqwvdavYLXSPER+Jet23izwlf8A
9o2etQKES8sluLhXAPr/AOGP7Kmi+BfhZonwz1Txr4uvk0T4mfF/4mw6p4J1jV/hbHPqHxe+
LHjT4salo9zpng3VLS3uNE0fUvGt5pWnWFw81ubG0t5JYjcNK7AHyp+0N+wd8NfjN+0R8QPF
F58f9b8CfFP4zeBzolh4X0BdMfWNM8A2/wAF/iV8GPE97ptnPPJLHeXi+OzrukeL3t7XUNJv
vD9/oOnXdxpGseJbG4AMrxh/wSg8G+L4Ss/xGl0+eXwZL4YleDwlbXkUF9qHhr9sbSNb1jTx
qWsXdzarqWvftd3nixdPe6njtdU+GvhJUlZBKyAGref8EvvCfiObXdSv/jf42u9Tuddu9Q0j
X9NttLh1fSr3V/irqXjn4hRanfpJP/bt5qGi6943+EGiS6goufBvw98Taho9n5l9Al0ADtY/
+Ce3gnwt8P8A9qjw5ZfEzxFoFh8d7bXHt/EcUI+3/Djwy/jjxX8TLLw5Gs97Np+s+F/C+qeK
NS0TTdOlsrEf8ILDD4bu3uIw1yQDynQf+CbPhrxfouheL/DP7QEt9ofiO6074i+GvEPhHwro
ttpM0GvfG39pn9oOz1rwv/Z2pHS5tI1W3/ap1/wxb2lzFqWhan4R02wi1Gw1JNQugwB2H/Dt
P7NH4BXS/jdq9jdeBtdvpp9YPgvQp9d8Z+GR8ePgR8fdD0/xlqpuVuNa8S6X4g+A2i6Dc+Lp
v9N1DQPEGvQvbQ3VwLigDjpP+CT2lNoWraHB8cvE1lFqfgb4yeA43g8PWsyWGg/Fz4deIPAb
aTBDf6rdrc6R4Tvdah8X+GotQN3qeh6pp66NoOq6R4VubjRGAN3xL/wSx8OeKJ/EUmqfGLxN
fw654r1vxEbXVNC07UYJINc1T9prxBJDrCTXQ/tvVdN1j9pfVbbRtbudlzYeG/BXhfRRFI32
69uADvfih/wTv074ov4SfVfi/wCKrdvD3wT8AfCK/c6VYXkuqT/Dnwb8Y/Cmn+I7eWeffpqe
Km+M+r3nxA0WPz7TxVB4d8NabcTQW1rcm6AOI/aV/wCCdHib4qeBPh/pHgH4uy+H9T+D37P9
z8JvBPhyfR7fSPDuu+IF+D/xY+Eqa3resaPv1nS7DVNP+KH265sbSHUI9JvfDWk3GkJAbjVl
1AA8o8K/8EoNT8ReCvEtt8UfiNBofijxX4E+JHgaW38JW2p6rpGkXfjLxN8d9Si+IljFq+qx
w2/i7XdL+Pfic+NdJjt5/D0upWOiroQ0+z00LOAeneJf+CWega3F4xi074r3ugHxfb6nbR3d
h4P01NS8IpH+0P8AtAftA+DP+EO1GHUbe60qDwdf/tA6z4Yj0uaS70XXNF8MeHrXWNOuLBtU
0++APQPj1/wT6u/jl8Vrz4mTfHfxZ4VjHgUeDdG8OaT4d0T7FY7YfCU8kmpSo9sNe0q/1zwT
o9/qujajAyXumX2u+HzdR6ZeWcdgAcF4y/4Jb6F4rl+Ips/iiPC1t8SbX4gPq1n4d+H2g6dB
Z6v8SP2Y/Cv7Nmuz2C293Ft0qztfCOn+NtE0mXzBYa7cXsJuZYJVZADI+Gv/AAT/APiZ8LP2
yfCnxf0rxB4J8Q/B7w5rnjfxFp2k6qutafrXhmbx54k/ah8W3cHhnR9OlGkW114an/aDh8F6
At5Nd6XdeDrG9vL23g12w0VlAOn8B/8ABNGfwf8AFHRvilqHx98U+INX0v4u6R8V5Ufw1pem
Lcy6dY+DdK1Dw4LexvF0mLR/E+m+BtETXbdtKmgh1GKPWdAt9G1PT9KuLEA2dc/4JtaBqnjL
VPE9t8U9f0ux1P4xfEb4sy6Lpmh6VZTrL8S/jH8G/jnrNlDrEDpcRa7Z+MPhBHomk+LTC+oW
fgjxbr+gmGSb7LqEQB4P8JP+CTV/p/wu8B2PxE+LN7oPj9Ph94X8GePtK8BWFrL4Kg/snwR4
M8IX2t+EmvobK7g+Iyf8IdDdad8U5bW31lPt1yp0uJPKiiAL/jn/AIJVa5B8O/Fen/D74zal
qPjO60HXovD6a9ZRaFp0Wu674c+IHgiWNtV0j7XqNl4TtfDvxG1LxCvhKGOSw1H4i6Jo3iS8
uYhJeRkA9R/Yv/Yb8X/BP4j3PxI+IsPg3S59E8Gf8I34a0DwTq2r6zo+v+NNQ8S+Ob7WPjZr
lrrenWk/h/x7qXgHxNoXw71bTbDU9b0qZNK1i80250/TL7T9KswDgNL/AOCRui6L4P0bwho/
xz8RaRa6HpehwW8ul+EtHtY7rVtF+C3gz4STajf2a3htrm28Tz+B9L8ReMNMZRDr6XOo6NcS
La3ImQAu33/BJTw1qWj+LNMvfjJr8r+KfBPxG8MQtF4ctLPTfCuq/EH4g/H/AMa3Gu+FNDs9
Tt9K06KGy/aF8S+H73SpLe4gv49E0DUUltLuG5+0AH2l8Fv2VtC+CXxi+L3xP8Ma89vofxRs
vDdnb/DnT9Jt9O8M+F5fDtsliuo6Yvn3LwXt9p1tpmnXsemppen3kOl2d3fWV1qgkv3AOUb/
AJSOxf8AZks//q9regD7aoAKACgAoAKACgAoAKACgAoA+OPht/yfT+1l/wBm/fsa/wDqV/td
UAfY9ABQAUAfFX/BQr/k1Xxd/wBlF/Z0/wDWkfhJQB9q0AFABQAUAFABQAUAFABQAUAFABQA
UAFABQAUAfFv/BPv/k17w/8A9lW/ad/9ag+MdAH2lQAUAFAHxp/wUQ/5MY/av/7IZ8QP/THc
0AcP+1T+yT8V/jv8QofFngv413PgHSB8P9N8LQaYq+IvtHh/VdKl+Jc2tXuiHSfEGmafJZ/F
ex8c6B4W+IaahYz3ieH/AAHozaPcw37xz2YBzvjb9iP4gap4H/Zl8GfDv4xXvw3ufg1ofiK3
8X+JrSfxHrt54h8TeLLLQZ9e8V2Ona1rV3DLrw8TafqfiTw3r2o3Z1/wtqt4q2ep3Gg6h4n8
O+IQDxrw/wD8EzfHzeHdTsfGHxw1W/8AEKfAm+8JeDNdtNe+Ilyngr46ReJtX1zRfipp2n3v
i8W8+io13bXeoeE5Qqzz3evWQv8A7LqlzJMAXNe/4Jx/FzULnxuYP2jNcurfxR4S+H1lpoud
S8caXb6N4gsvFPw68UfFi3XTdG8VwQTeG/HXiHwp4r8ZaLAJo7zwnr3jrUrDT3OlQKsoB6j8
Z/2Al+JHxc0Hxj4f8QaT4c8E6T4G/Ze+GE+g7/FSeILj4d/A34q/Ejxp4y8K/wDCRadr9ndS
ad488LeNrDww0dw0rb9Kmm1V9Rgu/s8YB4X4t/4Jp/HbxHpfiLTh+0zeSG8k8eHSri5k8cQz
z6xrHgb9rHRPBnxB1uWy8YQO/jPQNf8Aj18J5r2PT2tdJn039nnwe1nb2l22lf8ACOgHr2u/
sJfEmf4MfEX4Y+F/irpvhO+8a/tY+OP2htS1Tw/beJtHbxr4V+IniTxL4q1v4f8AjO8tPEP9
owy6Zqfi120jWNDmtIvN8HeFbubTRI96lAHm03/BOf45WuueKb7TP2gotQ0PxP4rvdZ8ReF/
FU3xD1vS/H+hL8Wte8X6J4b8cF/G8c89tpfhHxJdWMs2my2ral4g02ymv0n0i5vtPkAPa/2R
P2QvjP8As0+JdFn1L4o+FfFng6D4T/Bb4W6z4fn0jxJcXMCfCn4Sab4EuNc8EX+oeIJpPCsG
u634Z8NajceFbv8At7w9bxP4h1DSLbSNa1/Urq6AP0hoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgD4lb/lI7F/2ZLP8A+r2t6APtqgAoAKACgAoAKACgAoAKACgD44+G3/J9P7WX
/Zv37Gv/AKlf7XVAH2PQAUAFAHxV/wAFCv8Ak1Xxd/2UX9nT/wBaR+ElAH2rQAUAFABQAUAF
ABQAUAFABQAUAFABQAUAFABQB8W/8E+/+TXvD/8A2Vb9p3/1qD4x0AfaVABQAUAfGn/BRD/k
xj9q/wD7IZ8QP/THc0AeVftj2P7Vl58XPgt44+Cfh7xBP8P/ANnrW/CfxJ8W2GkeIdPtD8YY
/G/i5fhr8SfB8Xh4+ItN/tp/hf8ABDUvHXxBttN8S2sOna14l1Xwv/wis974s0O3gtwD43/Z
1+M//BSX4/fDvV/GHhvxN4jtvFOjfDH4vawuh+Lvhx8GNA8FXXxvtfhb+zZrXwR+HFxraacd
T1Lwb4s8Ta78c9a1++0C5ttZ8EtLo3w58ZeIdP1vwnLqWtAHsV1qf/BWS3/4SGXS00nVLWz+
Gd/rPguDVvBHwb0vWPEOv3+rfEgT+GvF0ln8Tr/TfDvxO8L6TP8ADZ/B1/paap8LvFkmnXS+
LoNAl1jWG0AA+mv2dPB37THgf4C+H/DkMWkaV4xT42ftH69rsXxzkh8Q+IJfh34y/aI+KPjP
4dyx3Hwq8Qr4Zs9Yl8A+IPDbNp9jM2kaKpXR4NOslsPsyAHhH7UOl/8ABQH/AIaF1H4t/s4e
E5r7w/4L+H3jn4JeDvBureMPD1t4d8W3fjf4R+IPiLb/ABuv/D+qeKbPQZU8OfHLw58JfhjY
wa3bW/iq1sYPFd5a2g8H6/ql/KAeIeFPhN+3ifFfwt0DWPC/xPh+GGkftiXHx2nv9U8UfBZf
Eb+H9d/an+L3ibxH/wALSl0TxKZLfSbP4LeJfhrdeFvB3wsj/s171/Huj6/p8o07RrG6APef
G4/4Kp2vxL+J+meBbnwBqXw4tLj4zXHwr8Ratb/D+C61Kex0G2+JHwVsvEFkLaLUIfDms654
j/4Z18QKttb+I7SD4e6l8S5tWibxFp95cAGBe3H/AAVLuYvF+oaJPe2ltoXgD4maz8OtG1/R
/wBn5dd8b68vjPw/p3gPw98QJNP+0aTpHjceDdR8a65pMfhi+0bwJc33h/wFD4t1u1e78W6d
qIB5N4V8A/8ABSHwFoXi7TPh1Y/EbQZ9V8WeML/R9a8VXvwA8U+IV0DWvi//AMFHPiJYQXWn
ahrWq+DrG7ntvF37H8V2mk6bbwabDql7oWm+Xo+g6vaaSAanw9+Of7avxquv24PhtrUXiqw8
daB+z18VNG+DXgOx8E+B9B8Pn4u2EN74esZ4fHq3/wBu0LUR4ku9O0DRrHxn4kXSvG+nRaz8
SfB+oQ+GLeF9PAPpb4cav+31purftD3Pjfw9q3iTQB8Pfi9qvwJ0KVvgtoN9beNNF+K/xNsv
hJ4V0rW9Nmvd0vif4TN8N7+71T4i2usaXZ6vEz6rcW10dbsbkA+GL39pD/gp/a/EuD4Ntp+q
6b8T08GfES+8KaRqPgL4Var4d8Ya7e3n7VeofC7T/GXiDRpBa6dNN4D8M/BHX5/GmgXXh/wH
oni7TJPh/wCO4bLUvH0l3pQB7R440/8A4Ku6zo/jrRtA1/xGI9b+F3i3SPCmo2mhfs++CdV0
7xRrHwV/aE1nw1rTXdrr/iS/0fxroHxU0z9nnwZNdW2r3XhO4uvEHirX00uy0d2k8JAHo3xz
8Kft2WPx1034n/s0WWsSSa1+zv8AB3wpe2fxSuvhcfBWreK/DPif43a14wsPixYaRqJ1TQfE
1tpvi3wfPpur/CSyTSdT8Qsml3epS+FtMuIYQDyrRPD3/BTPRfibo3xim0zxJ4n1bV/hr4A8
KeM/Ck1p8CfCNnrFlp+tftT6zeaLqlrH4z8U6LpXi7wbqHiP4TrpvjjwqbKy8Q6dqWnpr+ja
ta6TrelwgGnNY/8ABV7xb8PPGWn65v0ibXvhl+0YbCwLfA638XWPiPwvL8Rx8DPDH23RII9I
ub/416T4/wDhpYavrtne+H7bwMfgp4knuJvD+qeNYry7AO6u3/4Kc6v42sNEtJpfA/gO/wDi
ZZ6RrniDSdL+COs3nhX4bz+PddtNE1rwRH4kbXLvVRbfCT+xtT+JbeMrLVtbtfidHb23gex1
Lww+qQSAHTftEap/wUfsfix41tPgJZJqPwoa28AxaLrD6N8Ijq+h27t4Vg8c3PhnQ/E+uQT+
O/EEs8+s6pZXXibXvAOj6Rplj4r0FfC+v6hN4E8SSgHA+NtH/wCCkHiL7FJe6l8Q7W+8O/Ev
x3pWs6R8NIP2fPD/AIB8afDnUvgJ8YNH+G/iTRV8S6xqvjbdN8UNS+G1z8TvD3iPXxP4c1UT
33gGbUrDRYNWABDo5/4KjbfCmhvaTeFtHS8+FWj+I7zSrf4Ka1caD4NfxL+zFYa5qPhKbxJe
65ear4tsfA1z+1Hc/En/AIS4apYxeJNJ8Cv8O01e1mSPUgDrfFS/8FGZNI/Z38Z6JFr8XjaX
9k+LSPjd4N0y5+Do8MWH7QU/jP4I3XjDVrzSNXupbG58RjwFH8Zf+FZz+HNUvfBUPjWz0LTf
EgtPCeq3xvgDvdT1H9v4+CvgpDb6eI/Fl5pfxxl8e3+lWvwpku7fxTpnjTR7j9mqy+J1rrF4
NEsfBfib4cx67a/HO7+EUd54j0nxjNY/8IF9n07EyAHlWgn/AIKrXj6NO13o9nZ6npXiSCa3
8aWHwbttS8OeIfC3w8+EPjXRLzxPF4Qt9StdT0L4lfF23+NvwWSLwtefbvDnwz1DwR48l+z+
KrW7vnAPUv2cLf8Ab41j4hfD25/aA8T6vovgK2+GHiDxB4w02LwX8EdJk1H4kT+JINL0rwLr
0/hvWfG+pmHS9GvdU16x1/wde6FpurWmk+HYtT+zX39uWWugHx94V8Cf8FSvAsuk+NfDSeLP
FHxSk+BHgX4beNF+K+rfBPVfCHjLx74Wg/bm1D/hI9SuPD2p2epWmlaR4x8Rfs3z6Xq+h2+j
69r/AIY15rHxVb6kNE1Kz0MA/W79nM/GF/hPoc3x1vbq9+IdzqHiK6vP7R8P+FvDWsWWi3Ov
6jN4a0rW9O8E+I/FHhSXV9K0F7CwvdT0TUo7XVXtxqEmnabdXFxZxAHuVAHxK3/KR2L/ALMl
n/8AV7W9AH21QAUAFABQAUAFABQAUAFABQB8cfDb/k+n9rL/ALN+/Y1/9Sv9rqgD7HoAKACg
D4q/4KFf8mq+Lv8Asov7On/rSPwkoA+1aACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAPi3
/gn3/wAmveH/APsq37Tv/rUHxjoA+0qACgAoA+NP+CiH/JjH7V//AGQz4gf+mO5oAxv2ifjh
+0D8OviNqWi+APhvr2t+CdK+Elh420nV/D/wU8bfGO+8e+N7vXfGWieIvAlvdeF/Gng3R/At
74H02x8CeMYl8Q3N5e+P9P8AEer6N4Us7jVdEnQAHx7pf7Y3/BRm68PQahf/ALKgttRm8L+B
W1FV+EXxlSHwnq1/8RvCPhDx7ret6TLdHxJr8ul+G9Y1Xxx4W8GfDTTPH9zqWgw6jNr2t6Bf
eCrnSvGIB7r8c/j5+3p8OJ/hfN8Pv2d/C/xWsvE/wh8D+K/H8PhfR/GFw3hHx/aeItJ8OfFf
w1plxqut+Hr+4N3/AMLB8GeJPhlpOvaHpGpyeF/h/wDGK88SzrdWGn2tgAfNmnfHn/gpL8Kb
74l+Fk+E938WINS+LXxEutD8deJfhR8a5tJ8B6LL8XfF2h29zZ2+hX/inxD46+HGo2Z8K3vg
Lw54R09tb8H+AtUfW5bvxPoOi3l5ZgH0t8Pf2i/2yZvFnx1tfiZ8DyvhrwZ8O/jd4m+HZ8E/
CP4jHUNY8UfDLXtDsfCHhvTdR8T+LdL0r4nXPxM07XL+88J2Gmj4e3mtw+F5J7ae0TVLltFA
OA+Gn7U/7eHiTxz8J7HxZ+z42jeC9Y8XWXhz4hzXHwQ+Lmiaqui6p8cv2gvAFp4wsdY1HxNN
png21sPhh4M+DPxN1ix1zSNdSKPxrdpLeaXZanYHSADx39on/gox+1V8HPGHj7Q5vhVo/gPw
iPG9/o/w4+IPxU+CnxeSxfw94asP2iLjxn4k1TTPCPijWW8T+BfC8Hwx+FPinXviB4avovsf
gb4nrrcXhaTUbvT9A0kA7LXf2tv+Cj0em6lruk/s2+HYo7TxB8X/ACPC8Pwg+Ofi3XH0r4c2
fibUvC2hvq1lfeHvDt8/xOg0nwpa+EviB4Sv/F/hzUrrxhqa2+lC78OQ6fqAB6nrHxY/bL0f
4O+HNdk8Oa54q+Kmmftc/tE+FNW08/Bn4i6Do9t8I/Den/tFy/BbUtd0nwT/AG7q/irwDqQ0
b4OTXHjXwrZ6lF4itdftNLs7W68ZpJcTAGl4r/ad/a80L4Q/s0+J9H/Z48Va78TPiJ4wWz+L
XhAfCPxVPp/hTwxYfF3wj4Q1x7y90bxvqF/4Elm+H2va7428Ha/4i0rVLfxNp/hqbV9a8P8A
gm8LeBpQDxa5+PX/AAUA1/VPhlrWoeDfFOj+G/F3g/4U6l4w+Hvh39mb4naJqXgb4iP+0N8C
9I+LfgfUfHdz4m1nUbq28D/DnxJ8Q7vT/HKabY+A/iT4X8P6rqmgWF9Fp19esAeXePv+Civ7
a3ws8PaLH8Tfhp4A+HmueKtQs9R0zxJ4t+CPx107w/4c8KWWh/EO+8aXniHw9ZeJNa1y+0Xw
E3hPwjq3jvxtpd5EnhvTPiHo9uPCd5JPY3cwB9R/tC/tTftl+Cfi38SvB3wc/Z91bxl4K8M+
DG1Dw54o1P4MfFDUbTxB4qsL/wCBV8+k+FPEnhDXdZ0PxZL4o8K+PfirbeHTqln4J0rS/G/w
5i0fxbquh+H7fUvE+pAHtMnx3/aH/wCGovgr8LLb4NeJZPhF4r8Dwap8UviDqXwx8QabpvhP
xDqPw/8AGviizWz8bab408S+F7S4s/FHhbSfB+u+E9VtGudJvfFOnC18Q6+t5ZXagHy7H+1N
/wAFCtJ0jwdrfiz4OfD/AEfRNc8B/FX4heJ9e1j4U/GXw1Z+Ck8B65q+jW/gfXoY/EHitfD+
vyeGtFT4naf4j8d3ngfwt41tNdt/CWiTabNpM+uaiAUfg9+2P+3j8RoPhnrUnwE0XVfAnjwf
CXxBonxA0b4TfE/QdM8Z+GfiCn7PF78QYhpet+MtRvvhfb/CDQ/iR8Zdb0jxj4zkv9I+M6fC
bT7Lwjp9jc6xt1AAg0740/8ABRK8vvhHrPjrw5fQ2Pj74d/sYeOdZ8E+Af2Z/ibolt4H8VeN
PjZe6d+0d4S8TeJp/HHinW9K1H4YeA7nw/eeINF8T/YYPEGhLc3OmaTp62PiS5lAOD/4eGft
f+EtS+BfhD4z+A/h/wDC3xH8Sdc+Hl74n1zxD8FPjbpGkaJ4V8ReHv2Lb7xpazaHJ4p1nUND
HhTxj8ffjT8KLbxtqGp3ukS/E34feB9C1zRtFstQ8W6lpwB9HeNP2kf239B+LfxI8N6N8Erf
WPhjYeP9Q8M+FfFlr8Fvipfaj4d8D6V42/ZN0q/+JV3NZeK5LL4q+Z4S+M3x31rSPCng/TfD
+o6xL8B7qTSp9TA1qwAB83+Jf2mv+Ckd/wCL/hr42f8AZx8beHNT8J+CdWPiT4UaB4A+JWp+
APEI8afDX9n/AFy48f8AiXxRpmoatYa3qPgvxHrvxotPDvwX02zn+IumX/w2bQH1e91fxnp0
WrgH0L8WPH/7aK6n+zF4x0vwxqdxcWfwb8Y+Lfi54U+H/gf4uXXgT/hPtV+MH7NfgbTtY1HT
ZbvwX441WbwN8IfG3xt+KeifBHxNavrPi658GaroK6dP4gstF1jTQCbwl8V/24/ip8KP2qJ/
iB8PX+Fd94Z/Z81wfC3RfCXw3+Ieh/Ejxd8SPEnw31XUdD8ReDfFN54x1CKG9sNS0+KaPwLp
fhq/8WeGPEPijTPDWsa/Hrnhe6XWwDgvAf7TP/BQrT4vDHhTxH8AJdbk0LUdB8P3/jS++Enx
U05PiHpr6z4UtPFOv3YPiHUpvAl18PvAutaj4xn1DUE8Qw/GPxDoeo+EfA1jpfiIT6VAAdn8
GPj9+3fr8Pxn8TfEP4SXa6xof7LE3jL4S/CZfg/4n8FeG/G3x78L+N/jzpOraDpnxN13xDd6
jaaZ4r07w/8AB+Tw7o3jvSfCPivWPDHi7TvFCeEvCV3ZeKLFwD0X4D/Gf9sj4i/GTRfDHjz4
f6N4J+E1nofxE1/UPG+sfBT4l+FtT8f2nh/xR4f8P+DbbTLfxF48WL4Ua5r8PiDV9Rm8OeLL
LxVrl7pngK413TrC10bxZaT6OAforQAUAfErf8pHYv8AsyWf/wBXtb0AfbVABQAUAFABQAUA
FABQAUAFAHxx8Nv+T6f2sv8As379jX/1K/2uqAPsegAoAKAPir/goV/yar4u/wCyi/s6f+tI
/CSgD7VoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA+Lf+Cff/ACa94f8A+yrftO/+tQfG
OgD7SoAKACgD40/4KIf8mMftX/8AZDPiB/6Y7mgDyv8Aa3/bk8W/s2fETXvC2i/DHw/418Pe
EPgx4J+LnifUr3xhqmha/Fb+PfjP/wAKP0200fSIfCmqaXqUGk+INT0LxFrUt14g0u7/AOEd
t9dj06zvdUTTba8APmXxT/wU68cax448B/CXTPCOnfDXxnqniT4DJ4sv7XVT4yHh3VdW/aJ/
Yi8H/Ef4dahDqXg6LSdU0/xN8Nf2s7W40rxT4bvZpdJjjguLbULbxGmo2HhsA6v9nX/gqD4/
+NHjTwJ4U1H9nvTZpfH/AITg8QaFpfw8+JA1bxTe6hqfwC+HHx+0vSYLf4ieGfhl4RgKaF4y
1XRtRutW8aaXBHqWl2sls9xHdSJCAaPi3/gpf458GXt9Pqvwa8KS6JJ8V/2ivh74cS0+IGuv
4h1iP9m341+G/g74l0+8sm8ADR9J8YeL5vGmh634SgbXbvwdHHpHiO117xhpg/se41AA8cuP
+CwniW/hs9d0H4XeEBo3hC61H/haOjXGveK7rXNQudO/Z0/aU+Mk3g7wXqEnhfSdMtPED65+
z5c6NZa5q0V94burXW7dbufTZN91EAdFqv8AwUu+K3iL4ifs1+AtO8BWPw91fxt8SPhVqHiP
R7TWNP8AFuo/Fb4d/EvUv2mfDuheHvBMup+HrbQPDlzqEvwQ03WNVvfFnifwTqWkX3iDStNg
v5NPs9ZursA9G+Nv7dnjvw9rPjHSdR/Ze8IeK7Xwf8ffBnwP8L+HPF/jnS/+Evsvihr/AOyh
pP7VttN4ltoPDfiXwJocVlpN7qXw6TXfCfjnxbHB4na01eKeXQnuHAB51qP/AAWE/suDx7q+
ofCXSNP0XwZrL6VdR3Xi3xBPrGjT/wBvftv+CobDxFb6b4GvbOXUZfF37HduDJ4XvPEOkppf
xFEg1KR/DYl1wA0bL/grH4u1jw34r8Z6f+z5aWfhHw34ltdButb1P4goZNNtdI8MeI/F3jvX
r7R7LQJ9SvtL0Xw5oMXiWxh0pJta1DQb25hsNH1Hxjp9v4P1cA9s+G/7anxj8X/Cb9nXX28F
fCnWPiR8df2mvjN8ALjTbfxH438MeE/DMfws0P4/eKm1Bru58I+JNUvdXfTfgfLo8tqsCaPd
6nrlrfw61bWaTQRgHgvhr/grP498R6d8IPEf/DOuj6boPxb07TPFejWd78TZZPE194U1j4jf
sjfD6Kz0qzsvCF1o6eLNO1D9qgw3dr4j1rw9olzP8PbqePWbew8SQXGkAGVB/wAFMPGfxqtd
F03wj+zz8KdU165+HHi/40+H7v4ieLddv9E8Ojwv8D/hp8brTSo7WP4cS6hdePPD+m/ENvD+
ti0fRvD93qlrZzeHPGdza3uonRwD6S/Zm/4KEH4sePfAXw6+Jeh+GfCt/wDEL4beBNe8DeI/
DU/i3VdM+IvjTX/hx8PviF4n0vRdMufDiXvhHTvDUPjaaxuP+E4uNLWf7Jpc+h6p4ifUdXtf
DQB6L+3H40+M/gO5/Z1m+FXxkm+GFr8T/j74C+A+tWsHw/8AB/jJriX4mXF4LXxMLjxTpuqt
b3HhyLQ7iK00y3jsbPUG1OaTUb3NvaKgB8F+Hf8AgpL8XNG8LP4c+Ieg+HfiPrOlfEv4gaWN
VjurXQx8UfA9zrP/AAUr8O+D/CPijRU+HJ0PwfqC6t+xVo+j6he6N/adrc6T4lstUvtReaDV
7HVgD374mf8ABSDUvgp8C/gT8Wv+FKaZq/hn4haR8cNJ1Lw/oXiVtDn8D+J/2dl1jxR4y8I2
9nJoNxY3FvoHwV+FX7QHiqS70ye50O68T/CzSfA/hLUfEdv498M+IJQD5e+Nf/BRv4/2E+sX
Gg65p3w2n0+31PVI9E03SNE8aWB0zVv2fv2avjZ4RWS/17wPDfre2kXxM1e11iANcRNNq1/b
w3ksdjpLacAetfHz9v8A8SfAb9ob9orw/wCNfht4a+M3hL4W+LLeb4ZRO2naT4z+Gclr+zf8
DfiTfXcU1x4M+w3/AIVvPEvjHVrm+1mHxVqHjyyu762sdM0O/wBHsIksAD3H4oft/ePPhf4f
/Zy1rW/g34et7v4ueHfFHifxzo1z4+vpbnwppnhT47/s+/Ba4/4Re70jwlq+n+JLzVYfjrb+
KrC31O58PxW8Oj/2XeXYmuJri1APAL//AIK9eMND+H2h/FzXP2aRbfDzxTcfExfD80PxJtJ/
EMifCnwjbfF7xvbalpUHh+4isb3w18EfBf7QPi+ZhdT22veIvhhoHg/QJLq8+IOkXNsAe4/t
A/8ABRfxL+zV4L+A/j7x/wDB/TtT0L4w/Cnxp8U9Uj8NeMru4v8AwlpnwzTwh8S/iMggufDM
Sat/wjf7M938SfifaRRSQXXiHxh8PIvhtpkRvvFei6m4BwGp/wDBTf4n6Z4tk+HF58B/B9j4
+Txf4D+HN1Y3vxM1ltF0Pxh4q8cfsVeC7y71nVtN8AakZvDDTftnaNd6Nd6BBrWqSJ8P9WXV
dM0065CdIAPJ9T/4KcfFk/HPxPo/2Pw1o/hrwtq/hD4d6l8OrGW51KWz8ZaD+01+0h8CPHeu
Xni6/wDh5FcT2Hiy7+EOnXemWOl3F3FYeFbizukm0nxJ9vTUAD2H4Pf8FLvin8ZPEnwp8E+H
/gL4QHifxtr3hqTxO8fxRvTougeCPEHg39lD4k3eq6Zdax4K0C91bXPDvgb9p6a/vtLawtot
R1X4c3+k6VcTz+JNNa0ALEH/AAUe8ZaP+0FqvwevvAmg+IdDt/2ib/4WX+v3PibUNK1nRdG1
P9on4U/s9+Hf7E0ew8Ay6drL2eo/FnR/EmoDV9dspvseka3Zpqt682nzoAeb/FD/AIKNfHH4
dftF+LNAutK+H2ofD34W/Fn4yeAvEPgzT5dd03WNf8E6Cf2Nn8M+KLzXL3wlr2zxvo8Px912
7sNK0PU9M8Ma1DcTWOvSWdzpVhekA+/P2Lf2p/EH7WPgjxL491T4Zn4c6La65Ba+FVk8S2ev
3msaXNbOboarb2ttbnSNX0TVLe70q/hV7uxvWijvtNu5rWUEAFFv+UjsX/Zks/8A6va3oA+2
qACgAoAKACgAoAKACgAoAKAPjj4bf8n0/tZf9m/fsa/+pX+11QB9j0AFABQB8Vf8FCv+TVfF
3/ZRf2dP/WkfhJQB9q0AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAfFv8AwT7/AOTXvD//
AGVb9p3/ANag+MdAH2lQAUAFAHxp/wAFEP8Akxj9q/8A7IZ8QP8A0x3NAHH/ALV37VHw1+Cf
jrwr4K1D4ZWvxI8T+K5/hv4d+JzTaLaSQ+GPgz8Vde+IGjaTPqmpXlhcprUWta/8PvF8WkeC
2aSz1O50nUG1F9NFxaXNwAeAfEf9vj9lfwj4H0/xppH7Pt3qvjjxJ8JYPib8MfCev/Djw14Z
1jxN4f0F/D1z4Oie6ure5vtBsjokmj+LPDst3aJBbaNpMcVgItZsrXTAAep+Gf2n/h9pHw++
Fvj+0/Zou9A8Y+MP2jfiD+yrpVhoXhrwVYtonjv4ZRfFfwh4g8WW+oRXdreW/wAOXk+DOv6T
ayxiLxKmhyWNpLoIWJ7YAHI/DP8A4KCfs0+MvhV8HfG3jH4Xz+EPE/jnxr8Lo7nwY/g3Tbt/
DHxm+Mvg34LeO9D1fSLm9tdOuNWXX5/2hvh+NP8AG9hYx6rcrrs+qa3DpSWOstYgHRz/ALZv
7JXg34Q/An45fEL4UzfDLQ/2jfBKfHPw7HqPw20DUtSsr22bwxfmfX7jwtHq0L+MLfS/ixqH
jCG6tp7u9TwpbfEPxNJcW1jpPiKWIA8O8fft6/Czwlq+kR/Dr9m7wPqGmeCILl/DVzr2nWfh
LVdE06WP9n/xno1/4Ys7fwZeW2kaZ4j0r4yy+IdLl0bUZY5pdK0fU5jDLqsyacAfTPxj/bK/
ZL+GHj/4o/DL4r+E7iC48LSWXiLxlrWo/DSHV/CXiLxbpvgbwp448O2K6oLO6h1vxifDWqaR
/Yct5EZbSXSfsa3tq1tZLIAeQab+1T+wPrHxN8a+KoPh9rt58QPGWh/C7wR430/UfhfrB03V
fF5+IWmT/DHwNrugahZjwzD8Sb/xn8fdM1DRvFWo2sP9t23ia3uo/Fl9pmjxHTQB/h/9tL4C
Wnwr+A/xP+Kv7O9h4Wj+NHw0+KHxb1660Hwj4X8SaX4Bi/Zv1jwp4FsbfXZZbTT9bv8AWGfx
romgeCl0rSNQn0uaeTSYWtLPZM4B2XxM/bd+C3wu074P+PbX4UPqXw78Q+O/2o5/iBqOn+Eo
k8afCTxp+z1pfjM/FzxS/hqy0y4/tHUtM1Dwt470/wAW67p2orfahYpJfaLd+I49VggvgClp
/wC0B+w9rsfiv9qPw38P9S1Y/s331/4E07XtA+Hl/Hp93N8bvjF4e8Ia1rngbRore20PX9d1
34m/DDSE1LxBb2x8Y6dbaJDePLbaR4itpNZALcP7fH7IGgXurT/8ID4h8OXPg7xZqXhzxLqj
fCVNMtvCHjvxFa6vaeNdF1jW4rVLLS/EZ8UeF4fh74nia9W51zxfdeH9Kt21eC8s7mgDn9C/
bv8A2S/C9/rtkPg9qHhzxx4P/wCFgX+oeE/BfwkfUfFnhzR/hK3xM0DSZdbt9N8O6bLo+s6h
F8M/HmgaLp1rJfWek3todD/thItX0578A6nXP+CmH7HmsWpvZF8Q+Orbw141fTdJl0/4fXni
P/iudF0bxd4u0yTwtG9tNLdatfeA/Bni3x94M1bSEb/hJPC9gbvwreajc6pplrfAHnPiH9sf
4M6l4d/a18XfDr4AeCfGHg/9nf8AZ0X46aDrWueGtO0OH4n6jZ/EL9qDwF4y8P2difDd/qFl
p9nrvws8Z21lrc9pJd6pe+M/EEn9jixv2v8AWwDoPHX/AAUk/Za8JeBvGmnaR8O/EniLxH8J
PAfxk1+7+EUfw/XTm8Kah8L9O+N+gX3hLWXaxutE8JR+LJfg38TPDGn6zGlxoBsHhS9uls/E
2kwaqAWrj9tP9mj7Rp+hePPg9J4i+K+ta/P4Jk0Dwp8KE8UDxV430HxFdfCTxjo/hm/1XTLS
51aLwZ458LW3w11q51FbWOK7ttLWze78PRW+ooAd/p37YP7NHxE8EfEH4x+DPBUPimzs/Gnw
q+DviXxFr/gOfSY/GGifGH4oeH/hDpssOvTeHdUuvEvhqPUb+ZbvSJYrjyk0u3g1m00nT72z
1CgDD8Sftj/s4SfAPwv8bNE+Fdv4s8C2PjzVfhBofh++8JaPY6zo02h+FdS8dahomk6DNp1+
PDt6k3gaw0s+FtdHhVtN8TWFjZeIzoV3pCiEAx/Gv7XXgzwldfs0W2hfs76baaD+0t4dtvjB
4ll8S2GjaVJ4UtPiF8TvgP8AAiRtWsvDOkeJo9U8a+JNU/aW0X+09RkLafd6Na6np2satFba
vLe2ABq2X/BRv9lDxho+lXmraF4nt7C58U+A/A1lZ+LfAUVvJDZfGTUl8BeH9btLLUGdrrwv
rGpXeoeG9SOlx3VybKz1SS5099FU3MoBwfwz/b6+D/j0+Hr34h/A2Kw8beOda+DPhq5fw14f
tvGrXPinxbruujwXHqGq32haNNc2HhxvCOoeKtOu4p9TvNA0jwz4p8TXdloWm+E7rUCAUNW/
b6/ZN8VW/hzX/hX8JbD4geK/iH8Qfgt58+u/Da28Opf+A/il8XvgJ8OIfi9deJNS0SQ6nYQW
nx58L6poew32q3Ws2l74f1OHRbnSddn0UA+2/Gf7H/7NXxG8XeB/H/iT4VeF7zxB4BudI1Dw
ne6bC+k2llc6HrXhXxJoV4llo8tnYyXGmax4I8IXVperCt09r4e0zR57i40KJtMcA9of4d/D
+TUJNWfwL4OfVZb8arLqb+GNEbUJNUGpWusDUpLw2RuXvxq9jZaqLxpDcDUrO1vvM+1W8UqA
DdQ+HPw91bUb3V9V8B+DNT1bUtv9o6pqHhfRL3Ub/ZHp8Kfbb25sZbm62Q6TpUS+fLJtj03T
0GFs7cRgG3o/h3w/4dXUE8P6Fo+hrq2p3etaouj6ZZaYupazqDiS/wBW1AWUEAvNTvZAHu7+
58y6uXAaaV2GaAPj1v8AlI7F/wBmSz/+r2t6APtqgAoAKACgAoAKACgAoAKACgD44+G3/J9P
7WX/AGb9+xr/AOpX+11QB9j0AFABQB8Vf8FCv+TVfF3/AGUX9nT/ANaR+ElAH2rQAUAFABQA
UAFABQAUAFABQAUAFABQAUAFABQB8W/8E+/+TXvD/wD2Vb9p3/1qD4x0AfaVABQAUAfGn/BR
D/kxj9q//shnxA/9MdzQB7R8QP2fPgl8VfEWk+LfiL8MPB/jDxPodnb6fpOva1pMFzqtlZWd
/Nqljax3nyzNDp+oXV7eackryDT59R1R7PyDqmofaQDktV/Y+/Zf1yeyudW+Bfw5vrjTvC+h
eC7Kebw9a+bb+FfDOkf2BoOiJIm1jZaXoSx6NaqxaRdLt7WxaRra0toogDsL39n/AOC2o6Te
6De/DTwpcaPf/Ea7+L1xp76agt/+Fn39/capqHjm2VWU2XiPUNQvL+8v9Rsmt5r2fUtTe6Mx
1O/+0AHH2v7H/wCzBZXWgXtr8Dfh3BeeFrnw7eeHblNAtxNo9x4R0/4e6X4XeykJLRDQLD4T
fDG30mPJisR4C8KSW6JLolhJCAdY/wCzz8DJfBfhf4c3Hwo8C3fgTwSmuR+EPCd94esL7Q/D
MPiXwz4l8F69b6JYXkU0Om2up+EPGXinwvc2tqsdudA1zUNJSNbGYwAAwdY/ZR/Zv8QXs+o6
x8F/AF/eXFrYWM00uhW6hrPStG8LeHtNtRFFsiS3sdD8EeENKtokjVIrHw3o8CKEsYQoBq+K
v2bfgL4417XPE/jD4TeCfEuv+JluV1/VdY0W3vrrVhd+ER4CuGvWmDLNI/g5U8PCVl8yPTo4
o43Roo3UAq3X7MX7P19Fq8N58JvBt0niDw9oHhbXftGmiZtY0jwrd6df+GhqckkjSXup6Be6
PpF1pGv3DSa/YT6TpcltqcbafZmEAfc/syfs+Xnhjwn4Lu/g94BuvCfgWx8V6Z4P8PXHh6yn
0nw9pfjmC6tvGGl6bZyRtFBpniOK7l/tXTtrWd1KlrO8Hn2NlJbgFjVv2b/gRr3h3wt4T1r4
U+C9U8OeC77XNT8M6RfaPBcWmmX/AIoXUF8V3YWTc13N4tXV9WHi1r9rr/hKP7V1I6+NRN/d
mYAtr+z98FU8O+LPCCfDTwmnhbxz4kh8X+K/DyaaiaPrPiS38QQ+LIdXn09WFtDdR+KIE8RL
9ljgi/ttp9UMZvbm4mlAHXXwA+Cd9L4zlvvhd4KvR8Q/EHh/xZ42t7zQrO6sPEvijwrrGmeI
dA8Q6pps8cmnzazp+v6NpOuJqQtlu59Y06z1O6lnvYI5wAM039n34J6P4tfx3pfwy8I6f4wl
v/Fmp3PiK00uKHU7698c6hdat4rm1GdCP7RGs6pf6hqU8V+LiCK/1HUru1jguNQvJJwDHh/Z
c/Z0tdFh8PWPwW+HWm6NbXfgi/trLS/DOnaWttefDfwrF4F8B3NtNp8NtcW8vhXwTCPB+jtD
Mn2bwtLdeHxnSry7tJwCWy/Zj/Z805fiOlj8H/AdpD8X9H1Tw98TraDQbVLPxvoWt6r4h13V
tH1+zC/ZbzTdQ1rxd4q1e5szCtvJqfiXXr4p9q1e/luACrc/srfs6XlpNY3Xwd8DzW134X8U
+C9RjfSE3ax4X8b3WtX/AIt0bXZQ4m16216/8SeI7/UG1mS+nlvvEWv3glW51rU5boA01/Zv
+AyeJH8YJ8JvA6eKH8U6T43OvJodqupL4t0O6u7/AE7xBFcqoeHU01K+vdVubmIo2o6vdT6t
qP2vUZXuSAWoP2fPgnbeGNd8FW/wz8JweEPEviux8ca34ah0xI9EvfFemeJLLxhp2sjTUItb
W4sPFWnWfiKzjs47e2t9Yh/tCKBbmSWRwCK2/Z2+Btp4dsPCUPwt8HHw5pvjCH4gWukT6TDd
Wv8AwmtvpjaHB4muvtXnSX+rxaIw0WO6v5Ll00eKDShiwtre3jAIJf2bfgRPp/gzSp/hb4Sm
074eaBp/hXwPaS6f5kXhfw5pPivwd460zR9I3SFrWxsfGPw+8D+JLaFWIi1fwpoV4pEmnW5Q
A5Nv2Mv2VXn025b4C/DY3OjjS10uf/hHrfzrBNEvm1TSIraTO+ODTtUZNVtIAfJh1S2stRVB
e2FlPbgE8X7Hn7L8Fzpd5B8D/AEF1olxY3WlTwaOIZLGfTYdUtrJ4DHIu0QWuua1aCM7o3s9
W1K0lV7a9uYpACzJ+yP+zNLD4cgf4JfD4w+ENSl1bwrGNCgRfDt5LrvhzxOo0bYV/s6ytPEP
g/wprWm6Za+Xpmlal4a0K70y0tJdKsWgAPdNA0HR/C2h6P4a8PadbaRoHh/TLHRtF0qyTyrP
TdK0y2js7CwtY8ny7e0tYYoIUydsaKM8UAa1ABQAUAfErf8AKR2L/syWf/1e1vQB9tUAFABQ
AUAFABQAUAFABQAUAfHHw2/5Pp/ay/7N+/Y1/wDUr/a6oA+x6ACgAoA+Kv8AgoV/yar4u/7K
L+zp/wCtI/CSgD7VoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA+Lf+Cff/Jr3h/8A7Kt+
07/61B8Y6APtKgAoAKAPjT/goh/yYx+1f/2Qz4gf+mO5oA6f4x/tWeE/gv8AEXwV8Mtb8C/F
TxFr/wAQoJpPClx4Q8D6trukatcWNjrur61p9pqNrGYJ77w7oXh+917xBbxF20nSZbK7vPKj
vbcuAcp8Nv8AgoH+yX8VPBvgjx14W+M/gafw/wCNPCWq+KGun8SaM48L3Ogj4Rx674Q8WGC9
mXRvG2k6h8c/hjo954XnJ1Yat4s0awS2e41OwS5APQ9f/a1/Z18K31hbeJPi54I0Ox1b4deF
/irpGvan4g0610PWPA/jO412LwzrmlajJcCHUbTVrbw1r2q201oZozo+k6jqrsthZXM8QBaT
9rD9meS81DT0+O3wte80vUNQ0rUIF8ZaKWttQ0nxF4U8I6nbs32vYzWHijx14O8P3Txs8UOr
+JdHsXcXF7EjAG0n7RnwFl8KeMvHUXxh+HM3g74e+IU8JeN/EsPi3RptH8MeJ5rnTbO20DV7
6K7eG11e+u9Y0m202wdvtGpz6pp8Vgly95biQA861T9uv9jHRNB1nxVq/wC1L8B9O8M+Hb/Q
9M13xDd/E/wlDoukaj4n0fxNr/h6z1DU31QWdtca1pHgrxjeaZHLMrXi+FPEcUIefRNSitgD
bP7Y37KQvPiHpv8Aw0V8G21L4TS6Zb/EzTU+IHhuTUvA1xrXiJvCOjweJrCPUGvNKn1bxOo0
HTYbmFJL7VJbeztVlmurdZQDj/EX7eX7LOheF/iX4xtPi54P8S+Hvgz45+D/AIF+LOqeHtd0
u/07wBP8btY8EaX4J8Q+INRW6Wwt/Cs9v4+0TWrnXo7mSwi0ePUrxZZF0+4CAHsHg39oX4Ff
EXV/D2geAvi/8OfGWteLfAmn/E/wvpvhrxfoms3fiD4e6rDZ3OneMdIisLydr/QLy21GwuoN
QtvMhe0vrS63fZ7mGRwDx22/b2/ZRuvEHirTI/jR4D/4Rzwd4R8O+LNa+Ix8UaKfh7APE3iH
VvD2n6Cvidb02D+IDJpkWq/2crmSbQdV0vWrYzadci4AB6He/tXfsz6dLq0V/wDHn4UWjaFr
mj+G9XefxxoEcFjruvr4hfSdMmuWvvs/2m7Twj4schZWW3Xwv4ia6eEaJqZtQDA8Pfti/s+e
JPEvx00Gx+I3hpNP/Z1tvBlx8UPGU2s6cvgzQZfGuq+MdCtbK48QrctYQ3mk654G13Sddhnl
jOmX0UcNwVLnABW8Vftxfsg+CbrVNN8T/tH/AAg0nWtI8L+PvGl34eufHOhJ4jbw18Lv+E8H
xC1S00E3g1S+g8ITfC74j2mui0tZn0++8D+KbK4VLrRNQitwCl4I/bc/Z6+I/ie80PwV430/
xDoth4E+IHxEvPHmnXFvceCrbw78NdG+CPiTxPPPrSSmKBrfw7+0B8PtchMyok2m3d5cq3l2
xLAHK/Cr/go1+xz8Ytd8T6F4Q+Onw/aXw74FsPina3WqeJ9F0uDxL8Mbjwlpfi/VPiB4djvL
2K6vvC3ha01RdP8AFWpmBItD1W0vbS+MTW0hAB7nN+0n+z/b2HhTVbn4zfDa20zxzol54k8H
6jc+LtFgsfEWhad4t8JeAdR1PSrua7SC6trDx14+8E+Db5lk3WninxXoGgXCx6rqtpaygHKX
v7Z37Jmm2mr3+pftHfBrT7LQNDTxNrt1f/EDw5ZwaN4fk8RaL4TGsapLcX8aWGnp4j8S+G9I
nuboxR2934i0EXBjTWdNe5AOG/4eAfstXXxE034c6F8UvDXiu+1Xwx4B8U22ueFdX07X/Dgt
/id4+8C/D3wVYTapptzcQxanr2q/Efwle6fasd91pupxzQhpP3ZAOm079uf9jXV/Dek+MdI/
ag+BureFtd8Vp4G0fX9L+JPhfUdL1HxhIfCATw3bXdnqM0Umrl/iF4Ch+xg+aLjxt4TtyBP4
i0iO8AHfGb9tL9m74G2PjlvGXxV8HHxH8Pb7wVpPiXwPYeI9Hm8X6fq/xE8S+EPCXg7T7zSH
vI5rBtV1zx94Ngmub77PaaXa+I9I1DVZrOyv7WeYA4bxb/wUY/ZE8CfE20+E/jH4yeDfDPiu
Lxqfhv4uXXfEGk6Tp/w9+IFz4K0bx5onhLxnqF/eW9rpWreJdH1uG30KMySJfata3+mq4ubS
ZEAPfZf2ivgNBp/xH1ab4w/DmLTfhBqMek/FC9fxdoq2/gPVJ9Vu9BttO8TyG8xpV7d+INP1
Dw9Z21ztmu/EOn6hoVskur2V1ZxAHGSftnfsmx3cNi37Rnwca8ufB+neP7W3i8feHp5LvwZr
Fr4MvdJ8RWghvpBdadqdp8Rvh7cWEkBke8i8d+DngSQeJtF+2gHMeIP2/wD9ijwwviA6t+1F
8Ekl8KL4In8S2lr8QvDl/f6FYfEbXvCfhvwZrGp2Nlfz3dtomvan468IfYtYeL+zpLLxFpOp
C4+w39rcSgH13FLHPFHPDIssM0aSxSowZJI5FDpIjDhldWDKw4IINAElABQB8St/ykdi/wCz
JZ//AFe1vQB9tUAFABQAUAFABQAUAFABQAUAfHHw2/5Pp/ay/wCzfv2Nf/Ur/a6oA+x6ACgA
oA+Kv+ChX/Jqvi7/ALKL+zp/60j8JKAPtWgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD4
t/4J9/8AJr3h/wD7Kt+07/61B8Y6APtKgAoAKAPjT/goh/yYx+1f/wBkM+IH/pjuaAOu+Jng
LwJ8Ufj18HpZ/iAdI+InwH0nxx48tPBFpFbTXOraB8X/AAZ4u+ElvrOoC42yxWNpLDr01g1m
7tNqGlyRXSpAu4gHwR4c/wCCZf7P+k3E3wT0j4wSS6xpnwk0SC78IR+GvDsFx/wjmqeFP2Xv
hdaeO3trJrdf7T1fWP2HNE1/+04JXnHjC88Q6jcebJa2rSAHsnxr/YF+GfxD0zwzrXin4tav
pFr8OPgb8Ovhk2vtpfh24vIdP+EVx4r1Sx8fJdFEgsvELtr+rG4SGym0pIVvLSOweC8uIgAc
pqf/AATG+HGrC71DTPjBruiJqvjjxf46uY7DQPDf9mrYfEPxT8H/AIj6vodnaXLGSxttR8Xf
BXw14okvXnluWutR8QCBILe8VIADv/C3/BO/4Z+BfgvqHwe0DxxqFnI3xQ+Gnxdg8WXmlaTe
ajdX/wAKNf0TVfB9v410u8uZNN8b2hg0G20fW73WI45NdhCz3oa5t4ioB5L41/4JhfBvUdS8
e6j44+MDm3+IesW17caLqfhXwLaaZajQvBf7V2k6HpWm6QI4be6fw94c/aX8ZXemn7LLfxWH
gXw9JlorG6mUAv8Ahv8A4JifCSK/svH+i/FfUrvUr7UrDx5Fq83hnwxNZ+Ir+58deF/iToN/
4tspgE8V6XCdAntLDTdc823EWr3N/EI7y1jJAO98OfsCfB/wB8OPGnwE0Xx20Gn/ABB1r9m/
4pW8eu+HvDur6r5n7JVt+z3oOn3WtXV5Fjxd4f8AEFx8HvA3/CSafrzyW8Vx4m182ocarOQA
aHwI/wCCc/wc/Z/8ZTeLNC8U6vqs7fDYeBbeLVls4NQ0KCXwtY+FtY1Dw1q9tcRz+H9Hv9H0
u1ki8MWkH9jaVcwLeWPlOgIAPM9R/wCCavwt0bR/AUWtfGC7tm8EeDfhl8ItCuG8H+EoLHWn
8MxeM/APhS68VaLCrWfinxFqujfFI6JdXepxySXGuWfh/wASSOL6wgKACW//AASb+DMVxp0Y
8feINQ0jTfFGia+vhrVbDTNU0bVINH8FeOPhtqsevwS3IutY1vXdD8aSLqfiS4uhd2+u6TFq
9nb21/qOqGcA7DQf+Cenww+H3wi/aU8D6h8Vdcn8LfGf4SeHfAes6/e6XoUOp+D/AA14D1r4
r+KNA8SXF/Buk8T65bT/ABJ1GTUdZ1zfda02h2s07maa4wAefWX/AATN+CXxN0eHxzP8W7vx
np3xM8P+LNcs/FUHhjwtBJrvhP4wQftq+INcl0a92Ga10XXbf9u3xfqPkwEQPB4R8GNcRv5c
pQA9f8F/sj/Cn9n3xhcfE7xb8VEubHx1Y678HZNKvPDvh7w74b1XW/jroH7KPwWtNLsLLR0a
3t73Vb/9m3wPY6Zp8UJtn1Xxbq9vNiNYCADxJP8AgkL8HYNA/sO5+KOt27WXw70n4avqul+G
fCnh7U4/Del/BXT/AIL6Ra3Nzp3kuLO4h0jTvFesac7JZeI9fS7a/jdb6aQAHt/xQ/4J2/Br
4r/C74UfDK88S6j4Zj+FOnfEjS9M1nwZFYaPNqH/AAtFbjXb1HsUnmisoNN+LWk+Bfi/o1hb
TGBPF/w28Pxhfscc8agHkHxR/wCCcP7OGh6be+JvGHxPuvCfgz+3fh3asNS0zQrjTm8VyXn7
NPgSPT9VuZo2fVtO8baj8BvBltL4YvEbTLXxZ4s8R+Io4xf3ZkUA7O3/AOCcPwrj+J2v+MfD
/wAUbjTjZfEHSvE8HhCw0Dwk8fhK8H7RHwt/ansPCs9xEVvzpw8SfD/StH8OadfxxHRvAmsx
aTo8KWNnYBgD5+1r/gk7q3gfW/gTD8G/FHhTVvCfw71PwJqXiLSPHPhTSItO1HUfh7oH7Hvh
HSdSutL05VguW1Sy/ZW07xrrF5aKmsy+PLmyuDNLp32xJwD6v8Wf8E5Phv4u+JniX4k6h4u1
qS51/wCJ+m/FNdJvdF0XVbaDVovi3+zd8X9a0m/uL5JJtc0W/wBY/Zk8G6To9nqIdPCuja34
ltdIUJfFSAY3xu/4Jm/DT42+Nfib4x1Xxdc6O3xM8SeKvGV5Y2vgzwtfS6V4s8VfAHwt+z/N
rdrq13EL+4uNI0Xwjp3ifQftDb9J8TXOp3tpNG99LJQB2Phv9gPwX4R8DfHbwb4d8aarY3Px
08dWnjHWPFU2g6PqOvWtnafGHxN8ZU8Nai2oNc2niaw/trxp4p0WO71K3jvYdD1ZoI3822tn
iAPhrwV/wSC1rRfG+paBrXj3R734T6N4d+HOjeBfEM2g2N544s1+FGmfsrQ+GY7mJ2WK5tPE
l5+zdpsHxC0W8lOi6nptpoSaYsEsN2JgD6PP/BKL4P297qN9pHiWTSnubvRrywgXwR4Xv7Ow
PhfxH+x34l8JafcQagtwdZ0Tw5efsceFLax0jVJJ7f7D428YW5K/at0oB+p8SeVFHFkHy40T
KosanYoXKovyoOOEX5VHA4FAElABQB8St/ykdi/7Mln/APV7W9AH21QAUAFABQAUAFABQAUA
FABQB+ZmqfGtfhJ+3j+0pbt8LPi78Rzrv7O37Idx53ww8NaP4gg0n7D4w/ayi8nWX1XxLoDW
s939o8yzSFLpZIoZmd4iqq4B7C/7aNrGY1k/Zn/arRppBFEJPh74ORpZTG0oiiDfEgGSUxI8
ojTc5jR5MbFYgAZD+2rY3Dzx2/7Nn7U1xLbP5dzHB4B8FzSW0nP7u4jj+JLPBJ8rfJKEbKsM
ZU4AJ/8AhsuP/o2L9rD/AMNz4R/+eNQB8h/t1/tZxa7+zT4o0w/s6ftP6SJvH/wDnN/qvw+8
Lw2Uf2H9oL4XX/lO8Hj+4l8+7+zfY7NFiIlvZ7eJ3iR2lQA+uG/bRtVljgf9mj9qtZ5lkeKB
vh74OWaVItvmvFEfiQJJFi3p5rIrCPem8jeuQCT/AIbLj/6Ni/aw/wDDc+Ef/njUAIP2y4jy
P2Yv2ryPUfDnwifr/wA1G9aAGSftoW0IQzfsz/tVwiSSOGMy/D3wdGJJpWCRQoX+JCh5ZXIS
KNcvI5CorMQKAJP+Gy484/4Zi/avyckD/hXXhHJAxkgf8LGyQCRk9sjPUUAVV/bZ01zchP2c
P2o3Nm2y8C+BPBLGzfLDbdgfEsm1bKuNs/lnKOMZVsAE6ftnQSKjx/sy/tWyJKgkjdPh34Pd
ZI2CsJI2X4jkOhDKQ6kqQykHBGQB/wDw2XH/ANGxftYf+G58I/8AzxqAD/hsuP8A6Ni/aw/8
Nz4R/wDnjUAH/DZcf/RsX7WH/hufCP8A88agBB+2ZEwyv7Mf7V7DJGR8OvCBGQSCMj4jHkEE
EdQQQeQaAF/4bLj/AOjYv2sP/Dc+Ef8A541AB/w2XH/0bF+1h/4bnwj/APPGoAP+Gy4/+jYv
2sP/AA3PhH/541AB/wANlx/9GxftYf8AhufCP/zxqAD/AIbLj/6Ni/aw/wDDc+Ef/njUAfIP
7D37XNr4c/Zt0ezm/Z4/aa1CC2+Jn7R13Jqlh4C8KHTRHfftH/FnUSj3F18QbUxzWIuvseoL
Iipb31vcxLJLHGszgH1vB+2pZXQka1/Zr/aouRFK8EzW3gDwZOIp48eZBKYviS4jmj3Lvici
RNy7lGRkAn/4bLj/AOjYv2sP/Dc+Ef8A541AEUP7aVpcx+bbfs0/tU3MXmTRGW3+H3g2ePzr
eaS3uYjJF8SHQS29xFLb3EZO+C4ilhlVZY3UAHyj+3j+1pFr37GX7TmjH9nP9p/SP7S+C/ju
0/tPV/h94Wg0uxM2iXKi51CeD4gXM0NpGcGeWOCZo49ziN9uCAeU/tL6e/x/+NFl8S7HwD+2
J8Mb2X4c+EPARufCnwz8JWXxA0tPBPjbxh44g1Xwb4kj+K0L6YdZfxTPofiOGfTtQiu9BhuL
aM2z3UkoAPD9H+CfijQtY8HeLdK8N/tcad428L+HPB2iv4kX4Q6frFzcXXh3Wvirqes3EH/C
SfHHWHj0rxXF8RLT+1fDV1Jd6CbzSLqVLEW2qSW0QAmkfBfWx4e1vw54is/2zdb1nWfA3x90
XVLWP4XeG49Kkv8A4rpr7fCzX30G4+Ml3d2th8G9e8afE/UfDttbXNvDq02s6bb3ExbwtZeW
Adc3w012+8YaTrviDw1+2br2h2XxC0vxdqvhm++Fmgm28XaC3j/SfHWveFPFDL8YVTU7LTrX
TZvAfgJjEkXhrwFq2p6HeW+rG5M4AOm+OvhrxT8XPiX498e6H4U/bN8D6Z4tHw4MPgyw+HFk
+iXA8BXvgx5bDW5Lb412d7b6NrmmeHdT07U9M8H3HhaHU5L7StT1n+0tS0S2umAOW1TwBcpp
+j2moeAP2mtSfwz8YdY8ceCvEXjv4P8Ah/XvFH9keM/hd8WvhYfAOveIdU+Ni3fiIeGT8XJp
/hncB4dQ0weH9Dsb4a1P9omnAMvw/wDCzxH4fstBttd0z9sjXdN8PXfwwuL1NZ+FugR2/iPT
/CXxD/Zs8c6/oXipz8Zo0vdCmtfgHqvgzwTaFoR4a8K/Fbxtpt4+sLfsWAOl8b+DPGvi74Yf
BLwCPD37YVnrPwo/Zvu/gTf+MP8AhVmnJrHiXV/+Ev8Agn4s0z4gyzWfxttLlr/SZ/hAkJ0r
Up9T07VI/EepWWtR3+k3d7p92Adx8ZIrv4kan4m1+T4f/tbeG9b1j4b/ALNHw+8J6inwx8N6
WdL1z4IfE7xd478SzPHpXxh0hJtN+N2meI7TwH410LRP7Kvbzwzpken2t7tECwAHFn4fW326
/m0Pwb+2tbx2d/8As03+k6ZN4I0bXR4K8U/B/wATfB3XviXq+m3uofGK61pNW+LfhL4J/DLR
D/bV9ez6Eh17XI/tk/jHVpLwA4RPgh4st/h74G8O6VL+3v4d8ceD9L8TWmoeP9J8E2d1feL9
WXR/hXc/DbxJr1pr3xp1ZV1Lwr8Sfgz4L+ImvWWnyWmh+Kb688ZaZcaZb6d4u1eGcA2dY+EG
qjW/Et/4Z8M/trW2kXXiXwlqXhrw/wCJ/h9beJdGg8I6R4R8L+Eta+G/izRpvjbBoniTwpM3
hseJ/D2NOsdU0jxPdSXl1fajay3dpcgGp4z8J+N9X8MfsyeC9K0v9rLwlo3wI+BegfBaO1s/
gz4TsJ/GmtaR8HfH3wsvda8+1+MVlcvbatpXii119/DUz6jHY3vg+xvbB4D9vmkAOX0z4PeL
tP1XwTcSaD+1vrGg+EPiL8NvHcfhfW/gxoWqaTY3Hw3+Jv7OPxTgn8Nw3PxpcaL4g8Q678Ef
Edrr2sN9qM+n/EK9EFvBc20txdgHI/tW+D/2jfiP4y+Inj/4deD/ANq7VIfiPrq2N14CuPhr
o/hjStG8G2mjeOTZwTSaD8ZtLh1zVodR1628OHUz/ZupWWn3cXiiK5uPEHhqxW7APR9K+Guv
3cXgjW9d+HH7X+ieILb4r+MviR450Hwz4LktNB1HRPGcmjappXgez1Sz+Nun67PL8JdUsNRt
vh5r95dNax2Oua2dR0O4bVJVUA465+Aniu48HeDvC1xpf7ZWuvoGo2lz4gu/F/wttPFVv4ru
NC8bfs+eMPDnjW407V/jlcWul/EqNfgKukaxr+lJa6VeW/j/AMZXlnoljf6h9oAB6x8YfBOs
/Er4lfGDxxoHgf8Aa98CWPxe8R3niDU7HR/hB4Zi1XTrvWv2e/CXwCu9Vt9Wtfi5aibxH4Ni
8FaX48+FerzWpPhHxfqviO7nh1OHUIIbUA/RLwx+2Brtlodja+Kf2d/2o9b16IXAv9U0/wCF
PhLS7S6LXc72xisD8TbkweTZtbwSZnfzZYnm+XzNigG9/wANlx/9GxftYf8AhufCP/zxqAD/
AIbLj/6Ni/aw/wDDc+Ef/njUAH/DZcf/AEbF+1h/4bnwj/8APGoAP+Gy4/8Ao2L9rD/w3PhH
/wCeNQAf8Nlx/wDRsX7WH/hufCP/AM8agA/4bLj/AOjYv2sP/Dc+Ef8A541AB/w2XH/0bF+1
h/4bnwj/APPGoAP+Gy4/+jYv2sP/AA3PhH/541AHjPwn+LK/Fn/goZqeoL8Ovif8Ov7H/YyF
mbP4neH9L0C81L7T8b4Zxc6VHpfiDX47m2g2GK5eaW2eOV4wqSByygH6aUAFABQAUAFABQAU
AFABQAUAfDWgWus3/wC2D+2rY+HbuKw8QXn7MH7JtroV9OZ/IstZudb/AGw4dMu5jbTQXIit
714JpDbzwz7EPlTRybXUA+F/hd+wb+0/8Nfh18FfAXjy68MfH3U7L4++HviR8QPHt98S/Evh
TxR4F8K+ALT4FW/hPQ/A2o63onji7urTxHrfwj07xF4+gtZNCuNR0XR5fBtjPaDxVea5pQB9
0fsZ/AXx58Cr/wCNFrr+i+GfD3grxd4n0vxD4P0uz1Sw8UeM31u4n8S3njrVfFfjTT/CXgxv
EOl6leajox8Ixazpt74i0u3t9Wj1PWLqC6sLTTwD7loA+Kv+ChJI/ZV8XEHn/hYv7OnP/dyP
wkoA8Q/ap/Z0/af8XfHO/wDi5+zbfeE/C3iT/hXGneGk8T+OfEa6vYAaRo/xJhtj4E0A+ELj
Vvhl8RJLrxtc+HrjxlpviPVfDeteE9dvbnXvCdzr3hjw3OgByniD9n39unX7JNP1r4n6/rMO
g69+zl4r8LXenfGa+8FXt54f8G/Ev4eeJ/i78OvGUPhvwHDb614m1PSdD8XR6P8AEITAalp+
o6ZoGq6d8l9qlyAcVp37PX/BS/R/Amr+HND+Kvh3RNTi8C/EDT/C8mn+ObqOysL3VfCPxJtf
C+nzwnwViTxZF8VtY8B/EKf4jP5ksPhfS9U8Fy6JeiVp70A9f+Nf7Nv7RHxX/ZVv/g7q40bx
V8T5fiJ8bU8IfEHxR468298JeBtV+IPje9+DN5ruov4J1DU9cI+HF54T8H+P/wCwJ/DXjKxs
xqs/hfxcNYSDVJAD2fxD4G+Nkn7UngP486P8NvDE9roH7P8A8fPhVr9hJ8VLyzTVtY8S/Fv4
TeIPhdOIz4KuYY7Q+Ffhv4h1TVbk2slzoGqeNotCthrdvZXmrzgHy5N+xj8bLf8AZx/bc+EX
hnQ/BGgf8Lt02J/hbpt54otr7xFL4y1HWvE+qeNda8afEjR/Anhy81DQb99S0GTwhHquiaz4
m0YWutwahq11b3mnW9gAcjqn7KH7c/hC4+IWpfBnXvBvhiL4g/8AC6b7w14aj+JPiPTrP4Kp
8RviB8MtX8MaH4V1O18MNd3yaVa+FvFXjDXo7ddJ0f8AtzxfqGi2Vjfafp1nLegHa6d8E/8A
gpB/wm+neKr/AOL4jt/+Ep8JatqGhL8RJbnwmunWPjD9laTxBZr4d/4Qu3WbTrvwfp/7Wsb6
Sl5bxXuoeI/AUbTWwtLS48OgHGQfs4f8FMILDwp4pu/jYusfEm0+G/inwt4lim+Jd7Y+FovE
d34s/Z71LWdS8O6ZY+CYLe4svHPhzwR8bLPwjc61DJq3wx1nx9oF3ZTS6bpkOm6SAfUfw7+G
P7YngjSPjz4k1v4g3vxE8eP8L/C3h34A6D4s8cxHwfJ4tj+Evg6z13WvGllpfg+ws7DVY/ir
omqXU2tWFhe/2lo+pancxWdnPqs9uoB8Aj4W/t7fs3+Jfg/+zt4H1jx3r3wp0X4n+Ota0D4j
eBxf332/w94/+KHwi8U6GfiPY3YntooPDninxB8Z7Xxn4e1rxTPYTfB3bqXhm6l8XLa6bZAH
0J4U+A3/AAUfjvPhVd+KvjZeXQsLXwcnxHs0+IwbTpr6f4keDbT4mfY4LTwJYTaxpdz8NIvi
Lqvg9b6aDUdN1zXdDsBc2EWi6VJpAB+gn7Kvgz4hfDn9nD4K+Afizf3OrfEvwZ8OvDPhjxzr
N34s1DxxNrfibRNOh07VtcHifVbHTdR1GDWbu3l1O0W7s4ZrG0uoNPfe1qZGAPoCgAoAKAPy
B+Ffwt8dfFH9kT4AHwZY6R4msPh/+2J8e/iF4/8Ahzr2t3Hh/S/if4I0743/ALUHh+Twpcan
FYapAkumeKfE3hbx9Y22o2M2nX+oeCrWyuXtvtCXduAZvhD9mf8Abj8CeINek+HOseCPhd4K
8R/FCPxxaeCfDXjy7u9N8LWhX9nyz1vT7iW/8By2/ijTtQ+HngX4m/DrwrY3elWtp4Z1/VNE
8dXFneyXc9jpAAyL4I/8FSl8Pw28Xxy8P2+t6f8ACvxbY6Fdt4nnmTUPiC+rfF+Gzu/H8Wqe
Fdd8+bxR4b8Q/CW5stQ8OTw2Xw98VeD9Xn0DTX0C4/sLUgD7t/Y8+GHjv4R/B/U/CnxFiSHx
FqHxn/aG8fxRL4rvPG08Xh/4qfHP4gfEzwxbX/iW/wBN0m61LVbHQPFmn2GqyPZKq6ha3Kwy
3EIjmcA5r/goh/yYx+1f/wBkM+IH/piuaAPBv2uP2U/jn8W/2nvhT8avhpfeFYfDvwz8JfDo
Xek65rV5pd74l17wp+0l4D+JV5pdtd2Oj3l74fjt/Cmh6nqMOrWN5s8Rz2z/AA98QWDeFvFe
sXtsAebx/BD/AIKhx+B/BNrafHPRG+JMWhfEmHxfqviHxU154Kg8X6n8M9F0Lwx4g0Wx0bwZ
pOs3Gm2/xN0a+8Y6LoXiN/EOi6boni7WtJuNGhm03w82mgFO8/Zx/b9tPHV98UNC8XaDJ4gm
0Gx8Mafa6j8S9TTXV+HifFv40axpvgDxF4qHgy9Gt6j4X8KfELwtro8Vvpn2i+1Dw+dCSMvZ
W2uXgBj6N+zH/wAFD9ImtdZHxH0y+8Wza3rXiLXtd1b4o6zqqPaeKfhf+z/p3ibw54Ps73wh
NF4Lv5/EfhD4v6HpGuaYpttLl8SaL4tj0/MT6TbgHuvwR+En7efhz42+CvFPxU+KUXiL4bWu
oNZ+JPDi+NZtRs/+EMufAvxdFrazaRJ4Wsk1fxjoviy5+COn3vicXli2uf2B4v8AEKxWbazc
abegHLeC/wBmv9snxB8bfgf4r+PfjrSPF/gL4afE7VPG2v6ZaeMtRe31LXo/BP7QGjQ+K9I0
FfDthbW3hvULzxh8FYtD+Hd3d3EHhC98GeJdbg1W8uNQjF2AeX3P7EX7V+ir+154g1fxB4P+
O198d/FtnF8PfBvinxb4k0XR/h94VvPi78Xda1TxPpsmu2njXRrbxn4e+GfjXQLLwfbDw/Np
Vp4ls42vheaZpskOqgHvXwp/Zd/aJ+Hf7SVt8WY/F+hXXw9g/Y1034L6B4E1jXdf1jUPBniv
w3J4Rfwj4P8A+EomBTxDpenX2m+I9Z174nzeGrLxJ4ivNXcXWhLElrDagHzzF+zZ/wAFKfGT
/D20+Kfjbwdquj+GPjV8MfifpNnB8TdfuF8JP4O+L/wx8f6o3iAT+EPtvxLso9CsPFui+GtD
1PVdOj0yTTlJu3h16AaKAWfh5+yp/wAFC9Ml8V6refFW18F+NPG3/CU+MvEfiTT/AIo6p4m0
/W/jBpf7Kf7Ovwz+HOs6/ptx4J083/gb/hdfws8c+INR8I20dpb2ngXxJaaUouvtF3ptsAei
S/Bb/gor9h8Px2fxf1CHzPhn4tsde/tHx/Y3+qaD401jxB4pvNBuvD11Z+CNLtPEM+hWOp6P
p1yPGMGotqnh+ysotF8QeDPEekza1rgBgy/BD/gqBP4b8XC7+M2ixeLJrLwJB4TstD8cahD4
I8q08IeEBrWm61Pf+F38fwtbeMNG8X2Oq+JdG8W2PiDW9H8XWfiO5n1K+0aPw6wB0X7VX7J/
7UnxR+N2o+NPh343v7Dwxv8Ag54k8ISw/FfXfDsngbxb4B+HP7SPhXxHcaJ4dHhzVdOtr3XN
c+Ifw5vpNdtp4573TLXxBa3VpHJHAbwA6b4L/B39ufw78Ufh9r/jvxd4f/4Q6T4k+PPFXxY0
Sw8YXM2na7pPiXwB4Zt9Pu7O007w3otzca9pPjzStRWw0zVp9R8NP4Y1W4C2ematpmlXpAPP
m+A//BRPS4vFNh4Y+ImmaLpd1pfxU/sKCDx3M39m674g/aY8TfEDwbq1lb2/hnTY7w6j8Ktd
t/DnxAtdXmGtD+z4x4H8b+GNRu7u/YAk1v4Qf8FP3udRsNK+J3hi30aKKC5lurX4jatcahq9
jqWrfs06nq/hjQJtT8FPe+H9S0O18OftBaTofi+/vtQu9QtvEWkrd29g2pyXGjgH6ifC2Dx1
ZeB9D0r4j+Tc+K9Ds7fQr/XI9Xt9Yn8W/wBj20FgvjLUHs/D/hmy07VPFLwSazqGjWOlrZaV
c3b2lpPPBGjAA9CoAKACgAoAKACgAoAKACgAoA+JW/5SOxf9mSz/APq9regD7aoAKACgAoAK
ACgAoAKACgAoA+OPhtn/AIbp/axPY/s/fsa8+48V/tdZ/mPz96APsegAoAKAPiz/AIKDqz/s
r+LVRWdm+I37OgCqCzE/8NI/CToBkk/SgD5c/a58cftl+E/2t9CuPgPoPxS8X/DzR/A/wD1h
vBugaRqy+D/F2tXHjD9pNfil4fk8Saj4dufh1p8t74e0n4Sw+Lb3xL4m0nWvDui3Omah4Ht7
7xRfQWd2AcB4e/aa/b3i+JvhL4k+Ifgx4gvPBPiX4b/D7TvFPw48OfCv413FnptzqnjH4utf
65o+m+KrbwrN4Y+JHhq2tPDlj4w03VzqGka9ocXh2e01jTLTWbHVbIA2Yf2rv+Cg/jHwR4mk
tf2cbnwzPf8AgT9oPUtB1mT4WfEjR9e06++EVnrupaDFd+GtS8Ttq1p4i+L2leI/hjpfwq0z
T01eafxVpXxJuJjfW+k2um24B2LftRft2XviPSvCegfs+RaPa6p438O+DH8VeMPhh8TtasfB
2jan448MeFNN8aeIbjTNf0C38YWfiXwbrGt/E/UZdEuNEtfhovhifwj48ng1bU4Z4AD9ZoBO
IIRdNE9yIoxcPAjxwPOEHnNDHJJLJHE0m4xo8sjqhCtI7AsQCWgAoAKACgAoAKACgAoAKACg
AoA+L/8Agn6rJ+zBoCurKy/Ff9p0MrAqwP8Aw1B8Y+CDyD9aAPtCgAoAKAPjb/gocrP+wz+1
eqKzt/wov4gnCgscLoN0zHAycBQWJ7AEngGgD7JoAKACgAoAKACgAoAKACgAoAKACgAoAKAC
gAoAKACgAoAKACgAoAKACgAoAKACgD4mYH/h45E2Dg/sTXABwcEj47WpIB6EgMCR1G4Z6igD
7ZoAKACgAoAKACgAoAKACgAoA/Kn4hfAj4O/Fj9sr9rfxX8T/h8fH2ofDz9lj9ly/wDD1lHr
HiHS7iRR4g/a61S502BNE1TT1nl1G4063ijadJpFcgRkAkEA/Kb4X6R4d8T/AA2+CmufGf4V
+Bf2ePif8Vf2gfDXgHwr4H8VWnjpdD8Z+BdHtPgPcfFjVdY1DVfE0Wq6Q1lca38TvC3g/S/D
Lr4m8RfEHxd4CsLaeDw74Z12+YA+4/2Hvgf8Af2jYvidH8Tv2ZbrwP4i8NX+k63Do6eJvGJ0
Hwpo3ijxB4/0HSfhlqN5/bdtrMfxZ8F2fgCPVPirouuyXU1jceMPDeraSNO8P+IdK0fTgD72
/wCHd37Hv/RILf8A8K7x3/8ANPQB8h/t1/sG/so+GP2afFGs6L8Kbe01GDx98A7aOc+KfG0w
EGp/tA/C7S76MpN4kdCJ7G9uYC23enmb42SRUdQDwr9of4E/DzwJ+0FqPw1+HnwK8PMNNl/Z
FPw58DazdfEK8b4/2vxs+NHi/wABftAXVv4ph8QXF/oFl8BPh/o+leOr6/8AD0bDwghl13x3
aax4d1zR9PUA8wtfE3wIuLPwDc3H/BPPUdIbx34T8YeJ7dfEnxm8d+FhbXXwytfCugfFbwxb
x+JI9KvdZ8R+BPiTe+PtPbStItLvUvEvgL4fjx3oNhPaeKLK108A5CXU/hV4P1XxH4h8Xfsd
6Zruk+IvhB8Ffih4N8BeHPiZ8Sp9N8Ky+MfhX+0F8WZPBjePf+EfstW8QfEr4oaZ8N/Bngvw
T4SvfD8dmPiJq82mWGqTQT2Nvq4Bh/Hv4lfs36Z4c/aO8LfDD9lSHw34x8CaN8RLXwB8T9e8
Z/FifwvB4l8LeCfjhrGn6Lqmgaz4fa5l+It54m+C1/omh+B7ywfS/ENzqirb61LZ21jd+IQD
6T+Nnwv/AGdfhX8ZfjXYal8JxYeFvg/8MPBfxE+FXwo0VPGut+K/2tpNX+Hvxk8V+NdJ8K+I
Zta1G/sR4b1DwPo9jFdeEoZn8MS6Vf3Pim01u18X+H9PQA861LXvgF/b2neG9C/Yf0HUpdTk
v9D07xFD8Zvi1qGj+I9du/iT8cPhX4M8ReBLO00aKXxj8PvE2ufCnRNcj1Ualol8dC8Uzpps
WpS2Om3mtAGZ4P8AEHwS1b4fReNtY/Yz+Gtxptknwj0LXvFWjfHT4123hjT/ABh8Tv2e9K+P
JvNUtrnwxqd34a8FWdwdW+E8OoXep6vqZ+Kd54U8NTWn/E0vbyxAMnXfBfgJ/wBnFfivpXwW
Twv4o1b9ujS/hCnhrxfqt94Y1rwr8KvENva6xJ4J8Ran4pvrvwt4b8ReFodQOial421/TLq3
0640yWfVGuCtxK4Bu6N4k/Zj0y5l8P6v+yzoXjLTLJ/D/hrSvjHbfFD4neH9H8QXTav+x9oG
t/FTx34Yj0Zbb4d/D4xftZ2niu5l0rUdcXT7P4ceMrR4bCz2X2lgHlXws+JfwSg8BeCLPxp+
x1pfxQ8bWnwv+E2s/ELVPCPxQ+JWmeI7LWfiB8G3+I2ofETxR8PbLQmh8H/CTwtrmm6l4Y8b
+J0u1uNFvb3SpbPwuZpLjRrcA77xT4w+AfhpfEesW/7F2jaxBp3hWbWrLQLz4wfE7RbG+s/C
XhP9urxpr3ivwx4gi8P6nqPiDRviHpX7IuhyfDc3en2lvqek/Fj4eamVsJNTnj1YA9c+Fuj/
ALO/iz42eH/hB4p/ZV8Fwp4r+O3x4+G1prXhr4nfFyfWPC/hb4d6zqz/AA3v/GPgu4nvdatr
/wCIXgmwh8WQ+LrWX/hW4t59PS61zQn8TeGYdQAOB8U+M/2YtKHjHTNB/Yr0TVPFfgrxHqvh
nWdF1b42fFfRYrXUdF1f9uCxvoLu4i8PapdWt0+l/sh+GtetLUWE5ms/jl4SSSWGKHTrzxGA
eceIvH/7P1n8VJtQ0T9kpZvhxB4K1jSJPAOr/EDxro2uaJ4wm+KXwS8N+Gvih8S/FWqfY9O8
B/D7VPDPxHv9U8Pyx63q2neINC1Lw7r13/ZQujLagH6Mfsx/s3fs9/Hy8+Ks/iX9lDw98N9C
+HXjCx8BWyL8ZfiH4p8S6h4m/wCEK8H+Nteiv7KCPS9AtdM0eLxrY6Fb6ro/iXX4dW1XSdXm
hS2shavKAfWP/Du79j3/AKJBb/8AhXeO/wD5p6APya8EfszfAHwX+yx8AtetPh1pnh3T/iF+
198Z/hj8T/ivf33jHV7H4S/DofF/9pSaw8W3FvdeIJPDmnC+8SeD/Anwwt9d8U2l3oOl3fjm
21HUIZ7tYHIB4r4J+Jnwh0zwp5HxN/YMt/Efjzwl4A0HXPH+l+BviV8U9L8XWc+tfBvSPivp
3xE8QfDTU4rp/h78Lb63vhYa3qWq+Kr2+8L6hqml2TWF5Mt7b2oB9OfBPSP2b/if8dvCHwf8
SfsYaJ4S03xYBYReKdK+PPjXxk0OrzfCG4+L9he28WjoPDWp+E9U0XTL63s9asPF805uNS0O
KSxE51GG2AP0z/4d3fse/wDRILf/AMK7x3/809AHyZ+3j+wZ+yh4Y/Yy/ac8Q6L8KLa01bR/
gx461DTro+KfG832e8t9EuXgn8qbxJJDIYnAcJKjxsQA6MuVIB8y/tr/AAK8I/BH4z+GND+E
nwO0rxD8N774c+Ex44srKLxv4l8Y+CvE3xE+Nmh/Dzwl8U7Jf+EjmbV/BOiTtJ4X+IehNbTP
oukeLrX4jwyW9l4K1mO8AKPgK3+A3xH+K3wb8H2n7G+g+B/B/jj4p2Xgbxp4i8ZfET4yvdeG
jr3gH40eJtL8ASyQjTNM0H44aDrHwmtLPxf4N1WTUtLt4/G3hPTrDV5L3WY7y3AOa1XxN8AN
K8W+KvDw/YU0TWLPR/EHxF8PaFNofx1+LN9r3iK88J+Kv2zPBHhlE8Pf8IqiQ3HirxB+yNBc
S21rquoNYaL8XPCFxYtrV5HFZ6qAcv408Zfsy+LPhh8XLv4Ufsz+HfCviHR/hN+0X4v8A+O/
EXxQ+JN5o/iHUvhX8PND8SaHbfDzTrjRr2w8c+OYLjxZpmv6l4M1FbLS5NB037RFqepWepzS
aaAdx8Y7L4CeGf2SfFnxF0b9l3RPDvxabx1+0d8DdP1hPiP8S9f+HvhPx58Ifht8W/F3hfxp
/aE+my3mt2njzUfh7ouheB/Dl/4Xhi1vxl4w0Tw611fJLANVAOUh8W/s5+GH8S2uu/sdT/EA
eHl+M999s8KePviB/amoR/DDwLeeMdL0uz8LaMupaxp9lr9npV7eN4y1W2ufC9r5Wq6N/btz
4kh8LaF4tAOl8WeK/wBljwf4i1TwbJ+yJ4J8XeIbWyu9X0PUPB37QfxAHg/xl4bn8A+FfGfh
rxZ4Z8U+LbHwvos+jeIb7VvEnhSxk1DUtPsLvxL4TvtJsNaumNzdWQBha34v/ZvjdLnS/wBi
7UL230m5+GuqS6P4Z8a/FbXPEfjzR/HXwJ+IPxSGhaLpmqaXYXXhjxVJ4n8Ix+C4PBni6Hwv
8Rbe6fT9Wk8Pto+u2ElwAdT4W1z9mjXvib4G8DT/ALFeinw/4j8ZeEvCWoeO9K+NnxVvNH1K
28afE/R/hbpfiz4cJdaBZx+MPDdlrPiOzk1e7v7zw79ln8NeN9PhNy2lWd3eAGLawfA34f8A
xZ+LngL4hfsw6R4s8H+G/wBorxB4Ms/H9r8QPiRoUnwt+HVz8WfgZ8ONAvPiZo9jpklnY6Rc
w/GqbxB4I8SPrV5ceMNF+Hfjf7dJatpp1FAC3o0Pwg8UfAf45fGXS/2U/hfoV94Etv2PfFXg
3wf4i+Inx2nvrT4f/tD+APgH408feIviE9rNZXI0n4f3HxI+I+kW3ifQbKGyjufhvrUWv6RZ
zeHtZW4AOG0/UPg34a1PWvDXij9mrwr4oudK+NXxdttB8Rad8U/F+iWfiz4ZaR8T/wBt/wAK
eEvD2tTahYWmieELnTE/Z08BafB4zS9vLfVPDnizSvF2t3VrdXNzaayAe++KLT9lvw78GPgd
8Vbf9i7UtbvPi5p/xP1K58PReO/ixYPYX3wz1610WH4caDcNBfN4i+KvxDNzcH4caHBHH4X8
XSaB4gu/DfjDXfD0Wk+INWAOZsf+FJN4l8D+GNV/4J+T6beeKvi34r+Ct7e3vxr8caFo1l47
+GfizR/DfxD0nSda8WDw9p3iA3dl4itPEXwpmsp/+Lm2Hhnx1DpkFpJoUc10AeI6t4s+Dfhi
wtPi34m/ZT8L2vg/xT+zVP8AErwP8JNL+JXxd1u71XxXa+PtU0Szj1LxrB4RtdQ0HxHrttom
vaJb+Gr6zl8OLPF4feLW28Qaomj3oB1F38Uv2XRa/EXU9K/Yi0bW9I8F6n4rsRd6T8ePiJf3
+kL4S8eaP4akt/GuijTbeay8TeJvDOtv418EeB/C934p8X+L9M8IeObbw3pGr6pp2k6drIB9
CfG/wl8APhD8Z7f4Qaf+wfrfjk+I9N+Gd/4P8Y6N8RfivH4dd/iva+NPCvhaLxVL/Ztx/YGf
jjoPhX4dawpluLnw/wCGfG1r8R9Zt7XTdLutJlAPj7Vbjwve39paaJ+zt8MrA2HxH+HkOn2m
peNfirY33j/w3rHxi/al+GPjbTry9ksdQs9M8IaZD8GPDtxYeKvDujN4h0u51DS11YXx8Qb0
APZ/j1Zfs96RB+zEPhv+zlY+DpPjB4Y/Zs+M2s3PjHxj8Qrz+0vBXxg8S3Oj+J/hv4eiWG/t
L7WvA9qthd/ELXnvfD914UsvEnhHULW3nbVjaUAUfBHiX9mjXpfBnhzUP2R/D+nap4n0f4IJ
H468V/F/4l6T4As9V+KPwQ1j4pT3njzX/DOka7YeAbm68V+Hb74U6R4Q1KztPFVx4x1nwte2
nh+fw94j0qeUAu2/jb9k258R23hc/sZWtvqNp8QfBfgHxdG3xd+J8+o+Fb3xJ8Wf2gPhVqhf
w1Fpy+JfEF1ol18GPDmu6hpvhfTNa1fS9B+KOka9qul2/h7QtS1eYAwfDvi39nLXdXs57n9j
3TdD0y/03T7G4t7/AOK/xCufCPg3VdS+LHg/wFP4x8Z/EnTbO90q48A6Lp/imG7bxZ4NufEX
hzUHktLa8fQ9XOt2XhcASL4i/s4HSvEGsaj+wIdAS08HDxHpGga58cfHuleMYtTsfDn7Hvir
xJ4e8RaJrlloun2Or6TpX7WU1tpGk22vz6t4r8QfCPxT4dsbKy1fWLO204A9H+OOlfs8/Cfx
VoVj4f8A2UNC8ZweLPgv8F/iHpekat8TPi54NttP1P4heHP2m/FevLcX134evvFEbadB8EvD
2jLpuseHtPv0n8TWRv8ASfD+pGSz1AA1vjfpf7OXgWw8Gp8N/wBii78Ya58RPgN4L+LfhKx1
Hx38Vzd6hrPxG0fx7d6foGj6NobXsvim3+F0/g/TNZ+NH2bV9F1DQPCPjDQNS06G4uryC2lA
Pnrwp4r+COhN8Q9V8a/ss+FPiR4fvbbQvEfgS/8Ah18TviLb2HheL/hU37CWq+L9O1U6hbWQ
l+HXh7xD+09428baj481jW7jWtF0XwD410fUrI2HhxNSsgD7y/Za+AfwC/aF1/4h2/iL9kjw
p8OPD/w+j8C6bdzw/Hfx34017UPFHjX4T/C/4rRw2VvpMdr4WvPCtnZeP9Q0iLxNpni7UWv7
7QUaPTIRd3UemgHtfwj+A/wp+BH/AAUM1TSvhV4Uj8K2PiD9jJdQ1eKPVNb1Q3l3Z/G+K2tp
GfWtS1F4vKhkkULA0StvJkDkKQAfpxQAUAFABQAUAFABQAUAFABQB8cfDb/k+n9rL/s379jX
/wBSv9rqgD7HoAKACgD4q/4KFf8AJqvi7/sov7On/rSPwkoAx/2gP28PB37P/wAUB8KdY+Hn
jLxBrlxongDVtJvrLUfCWiaR4jufiD8UfCvwqt9H8O6n4l13S9OvNT8Kav4z8Oaz43sr2903
UdC8N6zpmuw2Go6Vcy3lsAeL6B/wVl+D/iUlNN+FHxiBtpfAvhvWr690/wAL2nh3w18SviN4
x8L+BfCvhDXvFcniU+HbbQ9Q8ReLNOhj+I1tqN54OmtIL69try4hhi+0AHFeI/8AgpF8Q4vi
R4a8LaX4D8NaDodv8TdZ8KfESTWX0bxPrWi2lj8Tv2I/hbY6FpreHPijb6Nqd1cah+2Jbape
eN9J1DVbCBvD9lZ2Pg7VYJZ7q9AI/Fv/AAVr8Nav4L8N6p8Jvhh4v0/XfGeveBNV8Kaj8WdP
0zw94S1v4T6r8Zf2dvhx4q8VacR4p0/VNT8QQW3x+0nT7Twrp/nato3iGy1K61O2vdP0u3td
eAP2OoAKACgAoAKAOU0fwN4P8P8Aibxh4y0Tw7pWmeKviBLoU/jbXrO1SHUvE83hnSl0Pw/L
rFwvzXb6Ro6Lp1kz8w2irEDtUYAOroAKACgAoAKACgD4t/4J9/8AJr3h/wD7Kt+07/61B8Y6
APqjRfA3hDw74i8ZeLtC8O6XpXib4hXmjah431uytlh1DxRfeHtEtfDeh3esTr813Ppmg2Nn
pNpI/wA0VjawW4OyJAADqqACgD40/wCCiH/JjH7V/wD2Qz4gf+mO5oA83/ak/bQ8c/BT4t2H
wi8EfDLSPE2oyab+zJ4oGtat4v0Sxk1+z+N37Wfhr9nTWvBOi+G9Q1Lw/cQ65baZrEus6V4v
m1m60PSNVudNXXdGnsFkF0AecWv/AAVe+HupeFrPxno3wN+MWteHtYuvhboHh6fSZvh/qWoa
347+LH7Puh/tLaF4Fh0bT/GF3qdrqkHw5v8AWbeXVbu2j8N3XizQk0Gy1iddb0y/cA5H4x/8
Fc/h54b8F/Hi2+G3g/U9Q+KXw88K+Mr7wOnifUPCf/CB6trXh/4XftE/EFJvEesWPjC0gtYd
Huf2afiFo3iDwvaasniKXVYbLQrOa31T/hIT4WAPtz4CftYeDfjl4z+JXw8t9OuvCnjD4Zaj
Z6beaR4ivtJs9U8VW80utW0nizwnoiX9zqOo+B7yXQ57rRPEtsbzTb20uVsbq5sfFGkeKfDm
gAH1ZQAUAFABQAUAFABQAUAFABQAUAcr4T8DeEPAsOu2/g/w7pfhyDxP4q8QeOPEEWlWy2qa
v4v8V3zal4k8RXypxNqut6g73mo3R+e5uHaV8uxJAOqoAKACgAoAKACgAoAKACgAoAKAPiVv
+UjsX/Zks/8A6va3oA+2qACgAoAKACgAoAKACgAoAKAPjj4bf8n0/tZf9m/fsa/+pX+11QB9
j0AFABQB8Vf8FCv+TVfF3/ZRf2dP/WkfhJQB9CfGL4UaH8avA58B+I9S1rSdLPi74b+NBe6B
Lp8OpLqnwu+I3hX4n+H4Q+p6dqlp9iufEHg/S7fVY2szNcaXJeW9tcWdzLFeQAHqNABQAUAF
ABQAUAFABQAUAFABQAUAFABQAUAfFv8AwT7/AOTXvD//AGVb9p3/ANag+MdAH2lQAUAFAHxp
/wAFEP8Akxj9q/8A7IZ8QP8A0x3NAH2XQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAF
ABQAUAFABQAUAFABQAUAFAHxK3/KR2L/ALMln/8AV7W9AH21QAUAFABQAUAFABQAUAFABQB8
TeLvhr+0z4W/aO+Jfxk+Cth8C/Evh74ofC34MeCNS0v4oeM/H3hDWtE1f4Ta98ZNSe6sh4U+
Hfjax1HTdYtPijbKrT3NjdWtzpdwpglimjkABrf2v+37/wBE+/ZA/wDDzfGb/wCcLQAf2v8A
t+/9E+/ZA/8ADzfGb/5wtAB/a/7fv/RPv2QP/DzfGb/5wtAHjPx/+HH7e/x1+F2rfDS48M/s
ieHYtU8Q/DzX21aL4sfGTUXibwD8RvCfxBjtvsjfA6zDrqcnhddMeX7QptkvGulSZoRDIAez
f2v+37/0T79kD/w83xm/+cLQAf2v+37/ANE+/ZA/8PN8Zv8A5wtAB/a/7fv/AET79kD/AMPN
8Zv/AJwtAB/a/wC37/0T79kD/wAPN8Zv/nC0AH9r/t+/9E+/ZA/8PN8Zv/nC0AH9r/t+/wDR
Pv2QP/DzfGb/AOcLQAf2v+37/wBE+/ZA/wDDzfGb/wCcLQAf2v8At+/9E+/ZA/8ADzfGb/5w
tAB/a/7fv/RPv2QP/DzfGb/5wtAB/a/7fv8A0T79kD/w83xm/wDnC0AH9r/t+/8ARPv2QP8A
w83xm/8AnC0AH9r/ALfv/RPv2QP/AA83xm/+cLQAf2v+37/0T79kD/w83xm/+cLQAf2v+37/
ANE+/ZA/8PN8Zv8A5wtAB/a/7fv/AET79kD/AMPN8Zv/AJwtAB/a/wC37/0T79kD/wAPN8Zv
/nC0AeN/AP4c/t7/AAM+GVh8OLfwz+yJ4iisfFPxL8TDVZfix8ZNOeRviL8TPF/xHktDar8D
rwKuly+LH0pJvPY3SWS3TJA05gjAPZP7X/b9/wCiffsgf+Hm+M3/AM4WgA/tf9v3/on37IH/
AIeb4zf/ADhaAD+1/wBv3/on37IH/h5vjN/84WgDx79oL4eft8fHn4IfFT4M3Hhj9kTw5D8T
vBGv+DJdei+LHxk1KXSE12xlsmv0sG+B1mt49sJPMWBrqASEbTKoOaAPYf7X/b9/6J9+yB/4
eb4zf/OFoAP7X/b9/wCiffsgf+Hm+M3/AM4WgA/tf9v3/on37IH/AIeb4zf/ADhaAD+1/wBv
3/on37IH/h5vjN/84WgA/tf9v3/on37IH/h5vjN/84WgA/tf9v3/AKJ9+yB/4eb4zf8AzhaA
D+1/2/f+iffsgf8Ah5vjN/8AOFoAP7X/AG/f+iffsgf+Hm+M3/zhaAD+1/2/f+iffsgf+Hm+
M3/zhaAD+1/2/f8Aon37IH/h5vjN/wDOFoAP7X/b9/6J9+yB/wCHm+M3/wA4WgA/tf8Ab9/6
J9+yB/4eb4zf/OFoAP7X/b9/6J9+yB/4eb4zf/OFoAP7X/b9/wCiffsgf+Hm+M3/AM4WgA/t
f9v3/on37IH/AIeb4zf/ADhaAD+1/wBv3/on37IH/h5vjN/84WgA/tf9v3/on37IH/h5vjN/
84WgA/tf9v3/AKJ9+yB/4eb4zf8AzhaAD+1/2/f+iffsgf8Ah5vjN/8AOFoAP7X/AG/f+iff
sgf+Hm+M3/zhaAD+1/2/f+iffsgf+Hm+M3/zhaAD+1/2/f8Aon37IH/h5vjN/wDOFoAP7X/b
9/6J9+yB/wCHm+M3/wA4WgA/tf8Ab9/6J9+yB/4eb4zf/OFoAP7X/b9/6J9+yB/4eb4zf/OF
oAP7X/b9/wCiffsgf+Hm+M3/AM4WgA/tf9v3/on37IH/AIeb4zf/ADhaAM/4VfCv9oW7/aV1
X4+/G+D4NaFbxfA2H4QaD4e+Ffinxt4tnuZpfH3/AAml5rOr3vi3wN4Jjsookjhsba1s4tQe
Z5JZZZIFjRZAD7ToAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK
ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC
gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA
oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA
KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA
CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg
AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK
ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC
gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA
oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA
KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA
CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg
AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK
ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA//Z
AABQSwMEFAAGAAgAAAAhAOwwMMmGBAAA8AsAABEAAAB3b3JkL3NldHRpbmdzLnhtbKRW23Kj
OBB936r9BxfP6xgw+ELFmTJgdpNKdlJL5gMEyLZ2JERJwsTz9dsSECcbTWpq5gnRl6O+qbuv
Pz0zOjlhIQmvN4535ToTXJe8IvVh43x5yqYrZyIVqitEeY03zhlL59PN779dd5HESoGYnABE
LSNWbpyjUk00m8nyiBmSV7zBNTD3XDCk4FccZgyJr20zLTlrkCIFoUSdZ77rLpwBhm+cVtTR
ADFlpBRc8r3SKhHf70mJh8+oIX7k3l4z5WXLcK3MjTOBKdjAa3kkjRzR2M+igYvHEeT0kRMn
Rke5znM/khzc7bioXjR+xDyt0AheYikhQYz27jJE6hcYL3gH9BLqKwj1rL97pqFA3XPN6WK5
pO/0Ldnus3hPCoFEn2YoAG0FK6PbQ80FKigUVecFzg1U1DfO2aSLGixKSBKUo+86M80AZ/g+
V0hhYMsGU2rqs6QYAVgXHQRiUFkbp6cYnQrvUUvVEypyxRsQOiGweTlClkckUKmwyBtUAlrC
ayU4HeUq/jdXCVSpgCD2Rkh0wo8CnwjuHkmpWoHNPX0paytbibPdPTrzVr3i5P0zAeAaMXC2
lx9K/4FXWDvQCvIunt/Nh1YwzkDYPriIw7MWpMIQAYpzdaY4Ax9z8g1v6+qulYrAYzIP4Bcs
+MgAXOubP0MTeDo3OMNIxwwe2k+7+9FlJmEZJc0DEYKL27qCEvrVy2ZddEkv9MhK6jzrwz+c
qzENruuFbhqGvXmae+G4gRcsV1bO0veWQ33/T2cXLhZ2ncxN/cyG5gXudre2cr5rmxcG2yCx
6fjzebxe2jjzMAyDuY0T7OZru064mseuVWcBgQt2NrSF77vZwsZZBUHixjbO2vXj1Iq2Xiy3
rjWi62wRh6kNLfaCXWCNdRwHmd3qxPPieGtDS+bzdGvNTxIs05W1DpLlcrW05ifZ+uHCWm+p
N19urVancbDYWm1LUw9q0WZ1FnpZ6Fs5SZikBg3eyPAyWKRn4KO4ue5Put1MWN+qEsQKQdDk
QU9JaFosKsTXmNQjv8CwJeDXnLwtRuZ02jMkQ5Rm0LZHhgkbiyoimxTvDSx9QOJwwR0khJUK
I+LuBUuPHCz+FLxt+ts6gZq+jYzXeUEw4JFa3RM20mVb5KNWDZPuFautq88noQFnl/B0kYIF
ybTje1Qfxm6B6+mXXLdHjKTaSoI2zr9oeveotaERUZHrvQo/oKaBgQVyxcHbOJQcjsrTagr+
KtivzE9x8Aeeb3jwp3nmB5XaWZAeDlqgP4LUcLjQ5iNtfqHB9tDLBRdaONLCC20x0mC/66Ij
jAEBo/srzLrxqOl7TinvcPXXSNw470h9EEyX37aKj6N5mMTShEgeUYOhEPTch07NI0MYFgE5
OUX4GbYKXBEFS21DKoaeYclwfdNnBmlq5vcbWY2khZs31EmFFGTIvJvZG2XINWwpb23pogqX
BOo3P7PismZc9W5RIlWOG9hIFBcQEDPd/zA8L4gqXt7CSIFTv8JkSRLuhias2b3DtwwdcNqQ
i+DcNdWqjRlW9Zv/AAAA//8DAFBLAwQUAAYACAAAACEAh75GPrsCAABOIAAAFAAAAHdvcmQv
d2ViU2V0dGluZ3MueG1s7FpbT9swFH6ftP9Q5R1iO44vFQWNIaZJE5pW9gPSxG2tOXEUm2bs
1+80KaxA0ahUAg9+quvLqX2+c/vsnpz9Ls1opRqnbTWJ8DGKRqrKbaGrxST6eX15JKKR81lV
ZMZWahLdKhednX78cNKOWzWbKu9hphuBlMqNy3wSLb2vx3Hs8qUqM3dsa1XB4Nw2Zebha7OI
y6z5dVMf5basM69n2mh/GxOEWLQR07xEip3Pda4ubH5Tqsp36+NGGZBoK7fUtbuT1r5EWmub
om5srpyD85Sml1dmuroXg+kTQaXOG+vs3B/DYeJ+R/FaFCzHqGuVJhqV+fjrorJNNjOgwRbT
6BTUV+iV23yO2rEuJlHKhJQCo254ZovbC72CoVVmAJkoXk8G3X1Tc3/Xi+57f+jFckf3ta2f
zj233tvyUT9s57xo1r/h/62pAPMIJro/kwgsAxp1lsMZunZujQWoshtv+22YrZ3tt3L2YEf7
rW22T77P0rjDoDt033yEBkWCSIJlgGMfIzgEHL1zfF5qUzzEhFCRColE2mESnOGJCx5C+7uc
AXMiGcRoHhS/O/a9muIJ5ZwlPOmTRjD54UweJQRxxAQJNj+szUtBRIoxFUHxwyoeC0QYhQq0
r3lCsBku2EBVQwhOaND8M+TikAm2r3DcpsDcVe8wmkIM4ryvdwIXeyEDPCRIHQkAyrlmxpwj
lGK2KYICHG8Mh0RIUiySQI33uh95Le+QgmOSpmkIVu8CDgzEQWLwkb5+DdFqwGj17M2RRJII
QQKXG6C82s7cGEvKE8xEEsjcsGQObutSRlhKWdD862v+/5QCI5piTgkN7zvvJE2LlMADT9Ln
hJCmB0zTuyg35owilpAklLFv5h+bKLZ+dMuMse33qy/ds3Nhr6yfZiv1yU3hfdyoS20UjMD8
rX8BnP4FAAD//wMAUEsDBBQABgAIAAAAIQCjX3s3YAoAANdKAAAaAAAAd29yZC9zdHlsZXNX
aXRoRWZmZWN0cy54bWzUXNty2zgSfd+q/QcW3x3rZslWjTIV2/HYVU7GM3J2nikKsrimCC5J
WXG+fhsNEOJFEBsiUzWTF1sk0Kevp0GHrV9+/b4JnTeWpAGPZm7/Q891WOTzZRC9zNxvz3dn
l66TZl609EIesZn7zlL314///tcvu2mavYcsdUBAlE53sT9z11kWT8/PU3/NNl76YRP4CU/5
Kvvg8805X60Cn53veLI8H/T6PfwtTrjP0hTQbrzozUtdJW7DadI2np8LHvR6l+cbL4i0jLpG
PGYR6LviycbL0g88eYEdyes2PgMNYy8LFkEYZO+gX2+sxbzN3G0STZVVZ9oqsWcKCkzfNmG+
GNQ2r5UemMof+Y6kZugBJeWWW+5vNyzKUL3zhIWgMI/SdRDv/XaqNPDHOlfpqMEFY3dxf1TD
0+6hBP028XYQ+xx4F9fEHXDGUm7ahNIPIqH2aVSV2O8RIiJEaB0oKpQxc02Kybc7zTX7TNrF
UIBtCuq3hG9jbVUctJP2EL1qWYIHLDTrjbHUi6alVgJqXDFfezFznY0/fXiJeOItQtAIPO6I
jHQ/AjctuX/LVt42zFLxMXlK1Ef1CX/c8ShLnd3US/0geAbOAimbAATef4rSwIU7zEuzT2ng
FW9+VtfE/bVYWLypd/ppVhB4HSwD91yApj9g25sXztzBKL9yI5QoXQu96CW/xqKzb/OiMjNX
X1qA3JnrJWfzT0LYOVqa/yxYHGv75aqKe4BIgFbmks/BeWz1yP1XtpxncGPmQk/Ai98enpKA
J0CQM/fqSl2cs01wHyyXTLSPfGG0DpbsrzWLvqVsub/+xx0Sr5Lo822UgR8mYwxZmC4/f/dZ
LDgN8CJPhOOr2ADsCo4r4KBC22CvjbxQQcWL/8sh+9LbB1HWzBMNz0H9jwKh1dvWQANhUdEA
lGul67C9iFF7ERftRUCjbeuLSXsRcMxpq4XMjUJW0oOacV8mXzEnhldHUlbsqGVR445a0jTu
qOVI445aSjTuqGVA445awBt31OLbuKMWzqM7fA+Jq5pFQ/QGqbCfgyyEptbAdP2WVKeagvPk
Jd5L4sVrR3TBqtrHyHK+XWQ0VZFOTyfLeZZwcTZs8MhAlsHJnPx5E6+9NIAjdBNQS9c/i3OK
81sSwFmzAepCJl/NJjxCHGxhT6HnszUPlyxxntl3GVGL/V+5M489Hw/jDcq1DOtj8LLOHDjC
iZbb6ImxwelmT0j5j0GKPjjazccGU5qEk2I4NuSlWfgXtgy2m9w1hNPIWPK5RZgrEKjicReN
RIjqRdxohQgAxQTZLuxNQPkE/WVzsZcvYkzRX7aiE+UT9JeN60T5mB/H42vNNLfwBxOHVF4T
69q94SFPVtswr4FGephYV7CGoJlgXcRaPokkJtYVXKJP55Pvw5MbJU+tY7HnUQsU63BIFCw2
ui3WQanQXt/CIusAVbAGFljtuNYCyJp0/2RvgfgTsW0zQJbWZ83Gch4aPAAtiHSG/mPLs+Yz
9MDAeVSUhwj+XJIyh4Y2NFQeFU3lk+x3FjFu1/gsgNp1QAugdq3QAsiQH+Yzj+6JdJD2zdEC
y5qWdRfDtCMz88SamTWQXQvoqG8Szl+G6jXnQr1vElCsA1TvmwQU6+hUepnumwSszvomAcvQ
NcwxKnKqjVHWfbMIpE8CBIu6IW8CUDfkTQDqhrwJQO3JuxmkO/ImYFlzg+bUInkTgHCJzaO+
BiqSNwHImhsk26m/GeV9D6Ucf7jtgLwJKNYBqpM3AcU6OibyJmDhEptMqGBpqiNgdUPeBKBu
yJsA1A15E4C6IW8CUDfkTQBqT97NIN2RNwHLmhs0pxbJmwBkTQ8aqEjeBCBcYsMNB8kbq/6n
kzcBxTpAdfImoFhHp0Ko+pBKwLIOUAVLkzcBC5fYJIPCwuS2Maob8iZY1A15E4C6IW8CUDfk
TQBqT97NIN2RNwHLmhs0pxbJmwBkTQ8aqEjeBCBrbjhI3liMP528CSjWAaqTNwHFOjoVQtU8
R8CyDlAFS5M3AQvzpTV5E4BwyalANhZ1Q94Ei7ohbwJQN+RNAGpP3s0g3ZE3AcuaGzSnFsmb
AGRNDxqoSN4EIGtuOEjeWCM/nbwJKNYBqpM3AcU6OhVC1eRNwLIOUAVLUx0BqxvyJgBhYrYm
bwIQLjkBCKvIJkzdkDfBom7ImwDUnrybQbojbwKWNTdoTi2SNwHImh40UJG8CUDW3CDes4X3
Rcmvp/YNSUB9zyB/q4EMODAEiQqoDPyTrVgCM4es+e2QloC5hRaIhvSgmnjN+atDe7F7aEgQ
MlSwCAOOr3S/41s6hUGE4eTIJMHz7zfOvRyAqe3DlCq/eQMzRsVxIZxpEoNDoGf2HsPITpy/
WS6kwSiRGMJSI0A4MfoAA0FqrEdsFnM+sBDHn9Rl/H9bhQq/AyJubIDSwpUxA5wqKorPx3wG
0hsLD4aTfhezRjXwCN6gPnQ9DKLX/HoOc7P2EilwP7yRr1ETHOWmVjEPZrZSeNVUaQFDrKPR
Te9aSoS5LWH1K2PxV1AJd4oPj0HEUvyUype2YfuCwVgr+B9mV+Vmvs1AX/b4FubC8bV+cKcS
C1NxQnpycA7O+++ROThx0zgHV9q5n4MTl/dzcAvUfnEjrfDFe5+5lqO7y/71rcgeHKFDwoUh
N3zTUQ0mFKboxtLY9Edhig6vFYbhDOnjQ+Q8P2PJkUxV8xL6FTaclqjmrWGoAk2sJ0Vugx5o
k+tKr/jCJXPaZ2KQ4IjOOGhwtMQcXCI9V1cQZvtQpf1DwmENIUCLUOYQ/PIQiSTeqeE+yQXL
754UBfdvWBh+8TDjMh6bl4ZsJWoPBPV7eICqiFrwLOMb8/4E5wuMAsCtRWXkR2GE2d/RdrNg
iZpWMDKaOHi41cyAsQq8Lh2oKRm0R86hetqsWymH9xQITJwIsqopdK/voEoVDjyY7S11r/Jb
/6J3e3Eh00IxUKn8e/Dv7k7lZu4o8Q0BkPOgCrgCd5ldostDuwOzXZzXau7AO3Im55A/8Hax
K9WLBUZ1cGeZxItG2hTJNUyiw5cxiDSSRYJpoqwHZ6Q/Zq78My/wfj6ai+4DhtxmXOqiSuik
vbq8TtqdF99JmwMYpl6y+0rMyVbL7f85bTukE8Sp6P5/MmOVzmC6DO6fvzw+JeKYAN/2kLF6
NYgFTmnFoaIo1kPpQFQRf/RgRG4x5brq3fVuB4oc1CkGyl3Wi7fIQy/yX/THmMMXDVz11REB
Fh5c0L8cqhOhacVgMrqUlWVaMRyP1Ti/acXo4lKdy0wrLkZXDZqOR/0GTSfDQYOml4NRg6bg
sAZN+70eDO1jbpiM6feurhp07fevoMEflzIAdRuWDCejJnVH4wtUVxQ5Zgv8cuwMPHNv+DYJ
5MEQv+OhdMWHrMoXoPqF46hSpXQcxWsA2dC3Sq3c36ZwypmLJ6vqw1O1jLHOqgePWik7+3Ik
N/1j1S2jUu+HhiONuYwPPoXsHQwl+/eLgHxcHhz2vPoyiUFrjysUo6fljbJni0+PBz2bf1tJ
6Smt+j0n/8znOygx7HXpx/8DAAD//wMAUEsDBBQABgAIAAAAIQBKCdjGgAEAAPICAAARAAgB
ZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAACMkk1vwjAMhu+T9h+q3Evawr4qKNKGOA1pEkybdssSAxltEiWGwr9f2kKh
2w67xfHrx/abDMf7Ig92YJ3UakTiXkQCUFwLqVYj8rqYhvckcMiUYLlWMCIHcGScXV8NuUm5
tvBitQGLElzgScql3IzIGtGklDq+hoK5nlcon1xqWzD0oV1Rw/iGrYAmUXRLC0AmGDJaAUPT
EskRKXiLNFub1wDBKeRQgEJH415Mz1oEW7g/C+rMhbKQeDB+p+O4l2zBm2Sr3jvZCsuy7JX9
egw/f0zfZ8/zetVQqsorDiQbCp6ixByyIT0f/cltP7+AY3PdBj7BLTDUNpsj7CCYaKV3TNXF
p0zl+QYOpbbC+fpO5AECHLfSoH/Jht658OqcOZz5p11KEI+Hn41+C6p+Fnay+htZnNQd29gv
WPvZzA0i8A6ljZ+nzFv/abKYkiyJ4kEYJWEyWMR3aZKkUfRRLdaprxxrLorjiP8h3iyifpo8
dIknQONR95dm3wAAAP//AwBQSwMEFAAGAAgAAAAhAIJ0CSfDCQAAdUcAAA8AAAB3b3JkL3N0
eWxlcy54bWzUXNty2zgSfd+q/QcW3xOJlCzZrlGmYjseu8rJeEbO7jNFQRbHJKElqTjO10+j
QUK8CGRDZKp28hILBPr09QC00frl1+9RaH1jSRrweGE778e2xWKfr4P4eWF/fbp9d25baebF
ay/kMVvYbyy1f/3w73/98nqZZm8hSy0QEKeXkb+wt1m2uxyNUn/LIi99z3cshocbnkReBh+T
51HkJS/73TufRzsvC1ZBGGRvI3c8ntm5mIQihW82gc9uuL+PWJzh+lHCQpDI43Qb7NJC2itF
2itP1ruE+yxNwegolPIiL4iVGGfaEBQFfsJTvsnegzEjqdFIiILlzhh/ikLbivzL++eYJ94q
BOe9OlP7A3huzf0btvH2YZaKj8ljkn/MP+F/tzzOUuv10kv9IHgCl4KAKABZdx/jNLDhCfPS
7GMaeOWHn/Ix8XwrJpYfqpV+mpUEXgXrwB4J0PQHLPvmhQvbnRYj10KJyljoxc/FGIvffV2W
lVnYamgFche2l7xbfhTCRmhp8X/J4p2yX86quQcCC2FeymwD57HNA/df2HqZwYOFDRmLg1/v
H5OAJ5BRC/viIh9csii4C9ZrJpK7mBhvgzX775bFX1O2Poz/cYuZmkv0+T7OwA/zGYYsTNef
vvtsJ3IM8GJPhOOLWABRBseVcFChfXDQRg7UUHHwfwWkI719FGXLPFGOFurfCoRW73sDucKi
sgEo10jXSX8R0/4izvqLAGbq64t5fxFAwn21kLlRykp6UDPuy+Qr58TkoiVlxYpGFnWuaCRN
54pGjnSuaKRE54pGBnSuaAS8c0Ujvp0rGuFsXeF7SFz1LJqgN0iF/RRkIRPrWwnI6Ul1+aZg
PXqJ95x4u60ldsG62m1kudyvMpqqSKenk+UyS3j83OkRV5bByZz8KdptvTSAI02H692ern8S
RxTrtyRYd0KdyeRr2IRHiKNb2GPo+WzLwzVLrCf2XUbUYP0Xbi13ng+7YKdyPcP6EDxvM2u5
xS23E2ymcbreE1L+Q5CiD1qLaaYxpUs4KYYzTV7qhX9m62AfFa4hnEZmks8NwlyDQBXbXTQV
IWoWcacVIgAUE+R2YW4CyifoLzcXc/kixhT95VZ0onyC/nLjOlE+5kd7fI2Z5gbeMC1Sec2N
a/eahzzZ7MOiBjrpYW5cwQqCZoJxESv5JJKYG1dwhT6tj74Pb26UPDWOxYFHDVCMwyFRsNjo
thgHpUZ7joFFxgGqYbkGWP241gDImHT/ZN8C8Qss080AWVqdNTvLeaLxAGxBpDP0H3uedZ+h
XQ3nUVHuY/h1ScosGtpEU3lUtDyf5H5nEON+G58BUL8d0ACo31ZoAKTJD/2ZR+2JdJD+m6MB
ljEtq10M047MzHNjZlZAZlvAQPsm4fylqV59LjT3TQKKcYCa+yYBxTg6tb1M7ZsErMH2TQKW
ZtfQx6jMqSZGGe+bZSB1EiBYNAx5E4CGIW8C0DDkTQDqT97dIMORNwHLmBsUp5bJmwCEU0xe
9RVQmbwJQMbcINku/51Rse+hlPaX2wHIm4BiHKAmeRNQjKOjI28CFk4xyYQalqI6AtYw5E0A
Goa8CUDDkDcBaBjyJgANQ94EoP7k3Q0yHHkTsIy5QXFqmbwJQMb0oIDK5E0Awikm3HCUvLHq
fzp5E1CMA9QkbwKKcXRqhKoOqQQs4wDVsBR5E7Bwikky5FiY3CZGDUPeBIuGIW8C0DDkTQAa
hrwJQP3JuxtkOPImYBlzg+LUMnkTgIzpQQGVyZsAZMwNR8kbi/GnkzcBxThATfImoBhHp0ao
iucIWMYBqmEp8iZgYb70Jm8CEE45FcjEomHIm2DRMORNABqGvAlA/cm7G2Q48iZgGXOD4tQy
eROAjOlBAZXJmwBkzA1HyRtr5KeTNwHFOEBN8iagGEenRqiKvAlYxgGqYSmqI2ANQ94EIEzM
3uRNAMIpJwBhFZmEaRjyJlg0DHkTgPqTdzfIcORNwDLmBsWpZfImABnTgwIqkzcByJgbxD1b
uC9Kvp7qaJKAes+guNVABnQ1QaIC5gb+yTYsgY4o1n07pCdgYaEBoiY9qCZecf5i0S52TzQJ
QoYKVmHA8Ur3G97SKTUiTOYtnQRPv19bd7IBprEOU6p68wZ6jMrtQtjTJBqHQM/sbQctO7vi
ZrmQBq1EogkrbwHCfrZ7aAjK23rEYtHnAxOx/Skfxr/b5qjwMyDiwg4oJTw3xsWuorL4os3H
ld5YedCc9LvoNWqAx3CD+th4GMQvxXgBc731Einw0LxRzMk7OKqbWs086NlK4apprsV4fD6d
Xo+vpETo2xJWvzC2+wIq4Urx4SGIWYqfUnlpG5avGPQBgv+h2U8u5vsM9GUP38JCOF7rB3fm
YqErTkhPjvbBeX+19MGJh9o+uMrKQx+cGD70wa1Q+9W1tMIX9z4LLae3587VjcgebKFDwoUm
N7zpmDcmlLroZtLY9Eepiw7HSs1wmvTxIXKen7GkJVPzfgl1hQ27Jep5q2mqQBObSVHYoBra
5LzKFV8Y0qd9JhoJWnTGRoPWErNwivRcU0Ho7UOVDi8JxzWEAK1CmUPww30skhgaQvGPrpIL
1t89KQqeX7Mw/OxhxmV8p58aso2oPRDkjPEAVRO14lnGI/36BPsLtALArWVl5EdhhN7f8T5a
sSRvjdAymjh42PXMgLYKHJcOVJQM2iPnUD2t162SwwcKBCZOBFk1FLpTT1ClGgcezfaeutf5
zTkb35ydybTIGahS/mP4d3ub52bhKNE4DDkPqoArcJXeJao8lDsw28V5reEOfCJ7co75Ax+X
d6VmsUCrDq6sknjZSJMiuYL+ZmgVF2kkiwTTJLcenJH+WNjy17zA+0VrLroPGHKfcalLXkIn
rVXlddLqovhOWhxAM/Wa3dViTrZaLv/PacshnSBOZff/kxmrcgZTZXD39PnhMRHHBPi6gIw1
q0FMsCozjhVFuR4qB6Ka+NaDEXmLqdbV+HZ84+bkkJ9ioNxlvXirIvQi/8X+uOMpdKo7+REB
Jh6d4JxP8hOhboY7n57LytLNmMxmeTu/bsb07Dw/l+lmnE0vOjSdTZ0OTecTt0PTc3faoSk4
rENTZzyGpn3MDZ0xzvjiokNXx7mADb5digvqdkyZzKdd6k5nZ6iuKHLMFvih7Qy8sK/5Pgnk
wRC/46Ey4kNWFRNQ/dJxNFelchzFMYDs2LcqW7m/T+GUsxRvVvWXp3oZY53VDx6NUrYO5Uje
9NuqW0aluR9qjjT6Mj76FnJwMJTs/18E5Ouye9zz+ZdJuL09nqNoPS0fVD1bfns86tni20oq
b2n17zn5Z77fQYnhXpd++BsAAP//AwBQSwMEFAAGAAgAAAAhAHRD5QhYAgAAgQgAABIAAAB3
b3JkL2ZvbnRUYWJsZS54bWzcVb1u2zAQ3gv0HQTusShZSRwjcuC6MdClQ5E+AE1TNlGRFEja
qldn79yhfYQiQwt0ydsYyJpX6In6aWNXiNPWS2UYsj7yPvG+u/t8fvFepN6SacOVjFHQwchj
kqopl7MYvb0aH/WQZyyRU5IqyWK0YgZdDJ4/O8/7iZLWeBAvTV/QGM2tzfq+b+icCWI6KmMS
FhOlBbHwqGe+IPrdIjuiSmTE8glPuV35IcYnqKLR+7CoJOGUvVR0IZi0Lt7XLAVGJc2cZ6Zm
y/dhy5WeZlpRZgzkLNKSTxAuG5og2iESnGplVGI7kIxfnsgvqCA8wO6XSJEnaP/VTCpNJilo
lwcRGlTCeXlfEgHgiIiJ5sQtZEQqwwJYW5I0RjjEET7GXfhG+ATu8Iz8goHOiTbMNhtxCSdE
8HRVo2RhVYln3NJ5DS8JvA7OUy4ZPoOFhZngGF1iuMLxGJVIEKOoQKIGCeFM1VXt6T5EqONx
W4IzxwMI8DRRcHq/7JwdIe5vv9zffvXuPn64+/TZybGVZXT5T7KszhL8zBL38GmBVkiTZVAj
bVlC65ZR+2d5xQUz3muWe2+UILKl7KErd1H2Yyh69/BlD4dNkaFcI0jrtBfVEjWC4LPHy17y
7C/IiKQcBqBFiLETIHSTcPj+DyDvnf4fjhppniTEH/b/Zv1ts/6+ub7erG/+2ykYqYXmTLcU
HUPRH1zl3G/ZAUye88K/NL3qRd1f7KCCtu2gMYg2Oyji3Mzs3/1D8OK0RYYXYAIRdH79Obj3
/9YEamGe1PuPmkD1J2AGPwAAAP//AwBQSwMEFAAGAAgAAAAhAH7MgvmLAQAA3wIAABAACAFk
b2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAnFJNT+MwEL0j7X+IcqdOupQvTY1WRYgDIKQGOFv2JLFwbMs2iP57xoSmQdzW
p5k34zdvng1XH4Mp3jFE7ey6rBdVWaCVTmnbrcun5ub4vCxiElYJ4yyuyx3G8or/OYLH4DyG
pDEWRGHjuuxT8peMRdnjIOKCypYqrQuDSJSGjrm21RKvnXwb0Ca2rKpThh8JrUJ17CfCcmS8
fE//S6qczPric7PzJJhDg4M3IiF/yHLMQrk0AJtQaFwSptED8ro6pcKUwqPoMBIKbIzgxQUV
+bJaUt8Yw6YXQchELvK6Xq2od4bAP++NliKRw/xey+Cia1NxL6S2ycW+yCTA5l1AFm1RvgWd
dpzY5incaUuCLmj6GJHCILogfE+qzrLMKYWtFAY35ARvhYkI7ADAxg1e2B1v8BUNStL8DeQJ
r/HJN+46O/Z98yc4W/lFp37rhcwu/V2dXMyXn9VgSyaholX2jAcAbumZgsljyTjbodr3/C5k
O5/H/8rrk0VF58u8PUYGTB+JfwIAAP//AwBQSwECLQAUAAYACAAAACEA6VEQsI0BAADCBQAA
EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQDH
wie8DAEAAN8CAAALAAAAAAAAAAAAAAAAAMYDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA
IQAAaHXhIAEAALkDAAAcAAAAAAAAAAAAAAAAAAMHAAB3b3JkL19yZWxzL2RvY3VtZW50Lnht
bC5yZWxzUEsBAi0AFAAGAAgAAAAhAOqQEIP/NwAA82ABABEAAAAAAAAAAAAAAAAAZQkAAHdv
cmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhACFaooQhBwAA2x0AABUAAAAAAAAAAAAA
AAAAk0EAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItAAoAAAAAAAAAIQC3Ct/LlEkBAJRJ
AQAXAAAAAAAAAAAAAAAAAOdIAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ1BLAQItABQABgAI
AAAAIQDsMDDJhgQAAPALAAARAAAAAAAAAAAAAAAAALCSAQB3b3JkL3NldHRpbmdzLnhtbFBL
AQItABQABgAIAAAAIQCHvkY+uwIAAE4gAAAUAAAAAAAAAAAAAAAAAGWXAQB3b3JkL3dlYlNl
dHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCjX3s3YAoAANdKAAAaAAAAAAAAAAAAAAAAAFKa
AQB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAIAAAAIQBKCdjGgAEAAPIC
AAARAAAAAAAAAAAAAAAAAOqkAQBkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCC
dAknwwkAAHVHAAAPAAAAAAAAAAAAAAAAAKGnAQB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYA
CAAAACEAdEPlCFgCAACBCAAAEgAAAAAAAAAAAAAAAACRsQEAd29yZC9mb250VGFibGUueG1s
UEsBAi0AFAAGAAgAAAAhAH7MgvmLAQAA3wIAABAAAAAAAAAAAAAAAAAAGbQBAGRvY1Byb3Bz
L2FwcC54bWxQSwUGAAAAAA0ADQBOAwAA2rYBAAAA
--------------090300010300040604040808--


From nobody Tue Feb 25 01:04:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1C1A03C5 for ; Tue, 25 Feb 2014 01:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnRPraNlftsB for ; Tue, 25 Feb 2014 01:04:44 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C86BE1A033F for ; Tue, 25 Feb 2014 01:04:43 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1P93lH8018460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 10:04:40 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1P93jd3023882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 10:03:46 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 10:03:45 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 10:03:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [dime] #56: Bad Description of Overload Control State
Thread-Index: AQHPLKXn/K5opEUqEkqiVdwfHsd6G5rEUNjAgABMwyCAARmykA==
Date: Tue, 25 Feb 2014 09:03:44 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B462A@DEMUMBX014.nsn-intra.net>
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784A7E@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784A7E@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 6879
X-purgate-ID: 151667::1393319080-00005322-9D676A3D/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XMIUJ8HnrzsNW6WZleQdaQbHig8
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:04:47 -0000

Hi MCruz,

thank you for your comments.

I agree that there are dependencies withh issue#35.

Best regards
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Monday, February 24, 2014 5:23 PM
To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

Ulrich,

In your proposal you newly define overload control states per client/origin=
-host.
This is very related to the ongoing discussion in Issue#35. Then, at least =
I think we need to first conclude on that thread.

A part from that,  we need to take into account that 3GPP requirement on ov=
erload mitigation differentiation per client is a server option:
TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".

Therefore, it could be better to keep this differentiation per client/origi=
n-host out of chapter 5.5.1.

Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:44
To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

There has been no discussion of this ticket.

I propose to replace text in claues 5.5.1 as suggested in the ticket.

Regards
Ulrich


-----Original Message-----
From: ext dime issue tracker [mailto:trac+dime@grenache.tools.ietf.org]
Sent: Tuesday, February 18, 2014 1:35 PM
To: draft-docdt-dime-ovli@tools.ietf.org; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: [dime] #56: Bad Description of Overload Control State

#56: Bad Description of Overload Control State

 The description of Overload Control State in clause 5.5.1 is inaccurate,  =
incomplete and could be misleading. It does not differentiate between  Over=
load Control State in a reacting node versus Overload Control State in  a r=
eporting node. It also does not describe how Overload Control States  are m=
aintained.

 It is proposed to replace current text with the following:


 5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node (client) maintains per supported Diameter application
    a host-type Overload Control State for each Destination-Host towards
    which it sends host-type requests and a realm-type Overload Control  St=
ate
    for each Destination-Realm toward which it sends realm-type requests.
    A host-type Overload Control State may be identified by the pair of
    Application-Id and Destination-Host; a realm-type Overload Control  Sta=
te
    may be identified by the pair of Application-Id and Destination-Realm.
    The host-type/realm-type Overload Control State for a given pair of
    Application and Destination-Host / Destination-Realm could include the
    information as shown in table 1/table 2.

    

    Agents that take the role of a reacting node on behalf of clients MUST
    maintain Overload Control States per client.

    5.5.1.2   Overload Control States for reporting nodes

    A reporting node (server) maintains per supported Diameter application
    an Overload Control State for each Origin-Host from which it receives
    requests that contain an (explicit or implicit) indication of
    OLR_DEFAULT_ALGO support.

    A reporting node (agent that is configured to take the role of a
    reporting node for a given realm) maintains per supported Diameter
    application an Overload Control State for each Origin-Host from which  =
it
    receives realm-type requests (of that given realm) that contain an
    (explicit or implicit) indication of OLR_DEFAULT_ALGO support.

    A Overload Control State may be identified by the pair of Application- =
 Id
    and Origin-Host.

    The Overload Control State for a given pair of Application and Origin-
    Host could include the information as shown in table 3.
    

    Note: For nodes that support other features than just OLR_DEFAULT_ALGO
    the Overload Control State definitions may need to be extended.

    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS with OCS-Id =3D (x,A) when  recei=
ving
    an answer message of application x containing an Orig-Host of A and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS with OCS-Id =3D (x,A) when  rece=
iving
    an answer message of application x containing an Orig-Realm of A and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS with OCS-Id =3D (x,A) when
    receiving an answer message of application x containing an Orig-Host of
    A and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS with OCS-Id =3D (x,A) when
    receiving an answer message of application x containing an Orig-Realm  =
of
    A and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS with OCS-Id =3D (x,A) when receiving a
    request (indicating support of OLR_DEFAULT_ALGO) of application x
    containing an Orig-Host of A unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS with OCS-Id =3D (x,A) when they detect t=
he
    need to modify the requested amount of application x traffic reduction
    generated by A.

--=20
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |      Owner:  draft-docdt-dime-
  ulrich.wiehe@nsn.com   |  ovli@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  draft-       |    Version:
  docdt-dime-ovli        |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: 
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 Tue Feb 25 01:05:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A21A0649 for ; Tue, 25 Feb 2014 01:04:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE6uu6QS-MmE for ; Tue, 25 Feb 2014 01:04:48 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E0ED61A033F for ; Tue, 25 Feb 2014 01:04:47 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-f4-530c5cae1648
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 7B.6E.04853.EAC5C035; Tue, 25 Feb 2014 10:04:46 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:04:45 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue #23 Proposed resolution
Thread-Index: AQHPMYgSECydxGIpskK7qjdEofxvM5rExTAw///3QwCAAO+3EA==
Date: Tue, 25 Feb 2014 09:04:44 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se>
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com>
In-Reply-To: <530B9FF4.4070108@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784E89ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje66GJ5gg0WfFS3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqHmFYwFl1IqHj95zdjAeCWsi5GTQ0LARGLBmS5mCFtM4sK9 9WxdjFwcQgInGCWWHbjGDOEsZpTYMvkSI0gVm4CdxKXTL5i6GDk4RASUJU7/cgAxhQUMJb5/ EASpEBEwkmj4MpsJwnaS6Fi6CWw+i4CqxPXD/WBxXgFfif9rnjFBjJ8KtKtrCQtIglNAT+La z042EJsR6KDvp9aANTALiEvcejKfCeJQAYkle85DHS0q8fLxP1YIW0micckTVoj6fIlP09ax QywTlDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFmc Wlycm25koJebnluil1qUmVxcnJ+nV5y6iREYSwe3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGP02nCpZ//P0Z5fY+j2r1hfGbby/aZ7Su/fXpeqln38y WCxvavtIW3p5Slt77u1zHMxG6p/q5+t5HL1r57neNte3fULggy3PXon/u3d8B5fn4tApz0Jz 1wWefB5p9in+s2eGxpHsty4BL1f9m5148aCC/8JDD0tnvZy394SuT4ZhxhGjXs3dj14qsRRn JBpqMRcVJwIA+v6e13MCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RVHdcAemmqM0-F5hpo7c0x0-Jo0
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:04:51 -0000

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

Steve,

The discussion started around some proposed use cases by Ulrich, and to my =
knowledge that discussion is not concluded.
Then we have not agreed (at least yet) on having a differentiation between =
realm and realm-routed.
Even more, as far as I understand the proposal it is related to the ability=
 (by agent) to select the a server (in a farm, providing service to a realm=
) for new session establishment. This is something we discussed long time a=
go, and at that point in time we tend to agree that it was not required, bu=
t up to different applications to decide based on realm overload.
Enhancements could be done on top of this, but first we need to agree on th=
e basic use cases.

I hope this clarifies
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:40
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is indicate=
d by the origin-host AVP in the answer message carrying the report.  Can be=
 generated by a server or by an agent acting as a front-end to a group of s=
ervers.

- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated by a =
server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.  =
Can be generated by a server or an agent.  The method for determining the r=
ealm state is out of scope for the DOIC document.

Steve
On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
Hello,

I do not think we have agreed so far on the need to have two different repo=
rts (so called realm-routed and just realm).
Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: dime@ietf.org
Subject: [Dime] Issue #23 Proposed resolution

I propose the following resolution for issue 23:



Proposal - Change the name of realm report.

Proposed name - "Realm-Routed-Request" report.

Proposal - Update all discussion on "Realm-Routed-Request" reports to indic=
ate that they apply only to requests targeted to a realm when there is no d=
estination-host AVP in the request.  Specifically, section 4.6 requires upd=
ating.

There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.

Regards,

Steve




_______________________________________________

DiME mailing list

DiME@ietf.org

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


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











Steve=
,


=
 


The d=
iscussion started around some proposed use cases by Ulrich, and to my knowl=
edge that discussion is not concluded.


Then =
we have not agreed (at least yet) on having a differentiation between realm=
 and realm-routed.



Even =
more, as far as I understand the proposal it is related to the ability (by =
agent) to select the a server (in a farm, providing service to a realm) for=
 new session establishment. This is
 something we discussed long time ago, and at that point in time we tend to=
 agree that it was not required, but up to different applications to decide=
 based on realm overload.


Enhan=
cements could be done on top of this, but first we need to agree on the bas=
ic use cases.


=
 


I hop=
e this clarifies


Cheer=
s


/MCru=
z


=
 






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

Sent: lunes, 24 de febrero de 2014 20:40

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Maria Cruz,



I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect=
.



The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).



- Host report - Apply to all requests sent to a host.  The host is ind=
icated by the origin-host AVP in the answer message carrying the report.&nb=
sp; Can be generated by a server or by an agent acting as a front-end to a =
group of servers.



- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated =
by a server or by an agent acting as a front-end to a group of servers.



- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.&n=
bsp; Can be generated by a server or an agent.  The method for determi=
ning the realm state is out of scope for the
 DOIC document.



Steve




On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:=







Hello=
,


 =
;


I do =
not think we have agreed so far on the need to have two different reports (=
so called realm-routed and just realm).


Regar=
ds


/MCru=
z


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 18:44

To: dime@ietf.org

Subject: [Dime] Issue #23 Proposed resolution






 


I propose the following resolution for issue 23:










Proposal – Change the name of realm report.  




Proposed name - “Realm-Routed-Request” report.




Proposal – Update all discussion on “Realm-Routed-Request”=
; reports to indicate that they apply only to requests targeted to a realm =
when there is no destination-host AVP in the request.  Specifically, s=
ection 4.6 requires updating.



There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.



Regards,



Steve 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_087A34937E64E74E848732CFF8354B9209784E89ESESSMB101erics_--


From nobody Tue Feb 25 01:09:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE01A03C3 for ; Tue, 25 Feb 2014 01:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrJnNafzSA9Z for ; Tue, 25 Feb 2014 01:08:59 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C077E1A0658 for ; Tue, 25 Feb 2014 01:08:57 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-0f-530c5da84709
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F3.EA.23809.8AD5C035; Tue, 25 Feb 2014 10:08:56 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:08:55 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750AAFZYT7AASMSeAAAPq9AAABvZ3yABzGU6A=
Date: Tue, 25 Feb 2014 09:08:54 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com>
In-Reply-To: <530B9C5E.90800@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784EA0ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje6KWJ5gg7XfxCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvwdZ5gKXi9lrWjc/5G5gXHOBZYuRk4OCQETidXn7jBD2GIS F+6tZ+ti5OIQEjjEKHF8cwszhLOYUWL9/T1gHWwCdhKXTr9g6mLk4BARUJY4/csBJCwsoC5x 5/sFVhBbREBDovHNJ3aQXhGBLkaJL+efsoEkWARUJTbd6GQCsXkFfCWObFsA1iAk0M4hsWKG LYjNKaAjcWvFFLBdjEAXfT+1BqyeWUBc4taT+UwQlwpILNlzHupqUYmXj/+xQthKEo1LnrBC 1OdL9NxaDbVLUOLkzCcsExhFZiEZNQtJ2SwkZRBxPYkbU6ewQdjaEssWvmaGsHUlZvw7xIIs voCRfRUje25iZk56udEmRmC0HNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAWJ8pZXXgqPzqotKnm96ZyIn5vGLbxR+7RmabrVL45P+cabpM8zsXFm/0 nrFg424rJp0fu+puV9tpBvPKmn25IblIaLIYx+pde7+HHZolojzTRyRHzC2H87GjQs5JVskL iy5msp3hu7fv6/Q1d6aECedvYnprF3PkbN+yX1+P1b32sDSYfzeIQ4mlOCPRUIu5qDgRAHRn h9VkAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kDLf_hZEjaY6R-46pk3eOOgm4do
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:09:11 -0000

--_000_087A34937E64E74E848732CFF8354B9209784EA0ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, I agree with Steve.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Lionel,

The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents.

I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case then t=
here is little benefit (and significant overhead) to requiring an agent to =
maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is the cas=
e then the reporting node should indicate that it only applies to the origi=
n-host in the request and only then should agents be required to maintain s=
tate for the non-supporting client.

Steve
On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:
I really don't understand but it is not the first time :)

What about the DOIC association? What about my assumption about agent maint=
aining overload control state for non-DOIC enabled client?
So for me, the proposal from Ulrich is a clarification on the agent behavio=
r that was implicit if you consider the comments above.

For me, the option for the server is only to send a specific OLR for a spec=
ific client. So over two different DOIC association with the same server/re=
porting node, you can have two different OLRs.
But it does not change the way the OLR is handled by reacting nodes.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Maria Cruz,

To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of the ba=
se specification, as it is likely that most/all applications will want the =
same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origin-Hos=
t reports should be specified in a common way.

Steve
On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
Hello again,

I forgot to mention something else in this thread, that I already mentioned=
 in related thread #56.

This is all in order to take into account 3GPP requirement on overload miti=
gation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".



Therefore, we can even consider this new OLR out of the base draft, and be =
considered by 3GPP applications when required.



Best regards

/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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


___________________________________________________________________________=
______________________________________________



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_087A34937E64E74E848732CFF8354B9209784EA0ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Yes, I agree with Steve.<=
o:p>


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





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

Sent: lunes, 24 de febrero de 2014 20:24

To: lionel.morand@orange.com; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Lionel,



The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents. 




I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case t=
hen there is little benefit (and significant
 overhead) to requiring an agent to maintain state per non-supporting clien=
t.



I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is th=
e case then the reporting node should indicate that it only applies to the =
origin-host in the request and only then
 should agents be required to maintain state for the non-supporting client.=




Steve




On 2/24/14 12:57 PM, 
lionel.morand@orange.com wrote:






I really don't understand=
 but it is not the first time
J


 <=
/p>

What about the DOIC assoc=
iation? What about my assumption about agent maintaining overload control s=
tate for non-DOIC enabled client?


So for me, the proposal f=
rom Ulrich is a clarification on the agent behavior that was implicit if yo=
u consider the comments above.


 <=
/p>

For me, the option for th=
e server is only to send a specific OLR for a specific client. So over two =
different DOIC association with the same server/reporting
 node, you can have two different OLRs.


But it does not change th=
e way the OLR is handled by reacting nodes.


 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 19:50

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Maria Cruz,



To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of t=
he base specification, as it is likely that most/all applications will want=
 the same behavior.



Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origi=
n-Host reports should be specified in a common way.



Steve




On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:






Hello=
 again,


 =
;


I for=
got to mention something else in this thread, that I already mentioned in r=
elated thread #56.


 =
;


This =
is all in order to take into account 3GPP requirement on overload mitigatio=
n differentiation per client. But this is a server option:


TR 29809 ch. 6.4.7.1 states "It=
 may be up to the server/agent implementations to decide when and whether o=
verload mitigation differentiation per client is used".


 


Therefore, we can even consider this=
 new OLR out of the base draft, and be considered by 3GPP applications when=
 required.


 


Best regards


/MCruz


 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: lunes, 24 de febrero de 2014 19:19

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Steve, all,




I agree with Steve.


 <=
/p>

However, I would like to =
share one concern. We need to avoid that existing (if any) host OLR (“=
;all-client”) in the reacting node is replaced by new host OLR
 (per client).


Host OLR (per client) wit=
h the new AVP requires that the server uses a new sequence number, but exis=
ting host OLR (all) shall not be replaced, on the contrary
 both Host OLR (all) and new Host OLR (per client) should remain.


In order to achieve this,=
 it could be more convenient to use a dedicated OLR type (host per client),=
 instead of a new AVP.


 <=
/p>

Let me know your opinions=
.


Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Adding an AVP to indi=
cate that a report applies just to the Origin-Host in the request is not ju=
st an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






I=
s it implicit? 


&=
nbsp;


I=
f the agent detects that a client is not supporting DOIC, this agent will h=
ave to store the corresponding overload control state on behalf of this cli=
ent and only this client (saying that other clients may support DOIC). I'm =
assuming then that any agent will have to store somewhere the origin-host o=
f this client. And therefore, I don't see what would be the added-value of =
this AVP saying that this OLR is only for this client.

&=
nbsp;


E=
ven if this AVP is present, it would not preclude a reporting node to alway=
s put this AVP in every answer, even if the OLR is the same for all the cli=
ents.


&=
nbsp;


R=
egards,


&=
nbsp;


L=
ionel


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces=
@ietf.org] De la part de Maria Cruz Bartolome


E=
nvoy=E9 : lundi 24 f=E9vrier 2014 14:27


=
=C0 : dime@ietf.org


O=
bjet : Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello Ulrich,


&=
nbsp;


I=
 haven't proposed to limit this to host type OLR, I just wanted to clarify =
if this is what JJ got in mind.


&=
nbsp;


I=
 agree it could be done as you explained in the example below, but the open=
 question is whether it is better to add an AVP when OLR is just meant for =
one single client, or on the contrary the agent _always_ need to bind OLR t=
o one specific client, even if the server simply requires same OLR for any =
client. 


&=
nbsp;


I=
 think having a new AVP simplifies agent behavior.


&=
nbsp;


B=
est regards


/=
MCruz


&=
nbsp;


-=
----Original Message-----


F=
rom: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


S=
ent: lunes, 24 de febrero de 2014 14:19


T=
o: Maria Cruz Bartolome; dime@ietf.org=



S=
ubject: RE: [Dime] Issue#35 conclusion


&=
nbsp;


H=
i MCruz,


t=
here is no reason to limit this to host type OLRs.


&=
nbsp;


I=
f we have an agent A that is configured to take the role of the reporting n=
ode for realm-type reports for realm R, A could receive host type OLRs from=
 servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduct=
ion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2);=
 A then would aggregate these info and return realm type OLRs to C1 request=
ing 20% reduction of traffic from C1 to R, and to C2 requesting 30% reducti=
on of traffic from C2 to R.


&=
nbsp;


B=
est regards


U=
lrich


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Maria Cruz Bartolome


S=
ent: Monday, February 24, 2014 2:02 PM


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello JJ and all,


&=
nbsp;


A=
s per email thread, the latest proposal is:


&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR." 


&=
nbsp;


A=
n Ulrich comments on this:


&=
quot;This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server."


&=
nbsp;


I=
s your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 


B=
est regards


/=
MCruz


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)


S=
ent: lunes, 24 de febrero de 2014 13:43


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
i Mcruz and all


&=
nbsp;


I=
 think that you are  mixing the case of the DA that is the "repor=
ting" node which wants to indicate a realm OLR to clients, and for whi=
ch will use various (non standardized ) ways to determine among which it ca=
n reuse the Host-OLR AVPs received from various servers. But in this case, =
clients receiving realm OLRs are supporting DOIC. 


H=
ere I understand the on going  discussion is about the DA behavior whe=
n  clients is not supporting DOIC and to reuse the Host-OLR received f=
or one client for other clients  .


&=
nbsp;


F=
or me I remain on  my previous mail, with a baseline solution. We may =
always study new extensions, optimizations, but priority should be on the b=
aseline.


&=
nbsp;


B=
est regards


&=
nbsp;


J=
acques 


&=
nbsp;


&=
nbsp;  


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces=
@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lundi 24 =
f=E9vrier 2014 13:21 =C0 : dime@ietf.=
org Objet : Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello all,


&=
nbsp;


N=
ot sure we all have the same understanding here.


L=
et me try to explain my concerns.


&=
nbsp;


T=
he original 3GPP requirement we want to cover is the need for a server to r=
educe traffic for one specific client, i.e. traffic identified by "Ori=
gin-Host" in the request.


T=
hen, two options are under analysis about whether or not the OLR in the ser=
ver answer shall be marked:


&=
nbsp;


a=
) OLR does not need to include anything else Receiver of the answer (and OL=
R) is the client that sends the request, identified by "Origin-Host&qu=
ot; in the request.


T=
hen, as long as the reacting node=3D=3D"Origin-Host", the expecte=
d reduction is performed and requirement fulfilled.


B=
ut, when an agent is acting on behalf of a client as the reacting node, the=
n the "Origin-Host" identifies final client, but not the reacting=
 node.


T=
hen, this is why the proposal is to add following clarification about agent=
 behavior (possible clause 5.5):


&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR."


B=
ut this will imply that _always_ the reacting node applies this OLR to one =
specific client, what is not what we need to achieve.

H=
ow will this impact the case where the agent is providing access to a Realm=
? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider f=
ollowing example:


-=
 C1 sends a Realm request via Agent, that finally reaches S1


-=
 S1 answers with OLR (Host:50%).


-=
 Agent is acting as reacting node on behalf of C1, if it considers this OLR=
 only bind to C1... then... should it consider S1-OLR only as relevant for =
requests coming from C1? Should agent do not use this S1-OLR to calculate a=
ggregated Realm overload?


I=
n my opinion, in this case it does not make sense to consider OLR was only =
meant to C1. And this problem could be solved adding explicit information, =
as in b) below.


&=
nbsp;


b=
) OLR needs to be extended (new AVP) that identifies the client ("Orig=
in-Host" in the request) from which traffic reduction shall apply.


W=
ith this new AVP, reacting node will easy be able to identify when OLR shal=
l be applied to any client or just to the Origin-Host identified by new AVP=
.


&=
nbsp;


L=
et me know your opinions please


B=
est regards


/=
MCruz


&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

S=
ent: lunes, 24 de febrero de 2014 12:28


T=
o: ext Steve Donovan; dime@ietf.org


S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


S=
teve,


&=
nbsp;


p=
lease see inline.


&=
nbsp;


U=
lrich


&=
nbsp;


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Steve Donovan


S=
ent: Friday, February 21, 2014 4:53 PM


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


U=
lrich,


&=
nbsp;


I=
 have a couple of concerns with this approach, as currently outlined. =
 


&=
nbsp;


F=
irst, how do we handle the case where there are multiple DOIC supporting ag=
ents between the non supporting client and the reporting node.  This, =
I guess, is a general question, not just applying to this proposal.  I=
 suggest we capture in the agent behavior section that is currently missing=
 wording indicating that the first supporting agent that receives the reque=
st must be the reacting node for that non-supporting client.  Subseque=
nt DOIC supporting agents must not be the reacting node for the non-support=
ing client.


&=
lt;Ulrich>I fully agree</Ulrich>


&=
nbsp;


&=
nbsp;


W=
e need to think through the ramifications of having multiple agents being t=
he reacting node for the same non supporting clients, as this could easily =
happen in networks where multiple agents are involved in a single transacti=
on.  On the surface it doesn't seem to be an issue for the loss algori=
thm, but this might not be the case with other algorithms.


&=
lt;Ulrich>I agree that this is not an issue for loss; it is an issue e.g=
. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>


&=
nbsp;


M=
y other concern is that this puts a lot of extra onus on the agent even for=
 the case where the reporting node does not want to differentiate overload =
reports.


&=
lt;Ulrich> I agree </Ulrich>


T=
o this end I suggest we add an indication in the OLR marking the reports th=
at are specific to just the Origin-Host in the request.  Absence of th=
e "single-client-only" AVP would mean that the report applies to =
all clients.  Presence of the AVP would indicate that the OLR applies =
to the Origin-Host.


&=
lt;Ulrich>I understand that the proposal is an optimization for agents. =
Therefore the semantics of the marking should be reverse: unmarked OLRs are=
 client specific, marked OLRs indicate that the reporting node does not wan=
t to differentiate, and therefore allow agents not to do the binding to the=
 client.</Ulrich>     


&=
nbsp;


S=
teve


O=
n 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:=



B=
en,


&=
nbsp;


t=
he proposed conclusion was based on comments received so far (from Lionel, =
Nirav, Steve, MCruz, JJ). 


N=
ow you seem to address two points:


a=
) There is no dependency to DOIC support of the client.

T=
o address this I would like to propose rewording of the clarifying text for=
 5.5. as follows:


&=
nbsp;


W=
hen an agent takes the role of a reacting node, the agent needs to bind a r=
eceived OLR to the origin host of the client that initiated the request whi=
ch corresponds to the answer containing the OLR. 


&=
nbsp;


T=
his would cover not only the case where an agent takes the role of the reac=
ting node on behalf of a (or several) non supporting client, but also the c=
ase where an agent is configured to take the role of a reporting node (for =
realm-type reports) towards the client and at the same time the role of a r=
eacting node towards the server.


&=
nbsp;


b=
) There is no binding of the OLR to the orig-host of the client Here I disa=
gree. We have the 3GPP requirement to allow requesting different amount of =
reduction from different clients, and I think we have 3 options:=



1=
. ignore the 3GPP requirement


2=
. introduce new report types as originally proposed in #35 3. introduce the=
 binding between OLR and orig-host of the client.


&=
nbsp;


S=
o far I understood that people favoured option 3.


&=
nbsp;


S=
ee also inline.


&=
nbsp;


U=
lrich


&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: ext Ben Campbell [mailto:ben@nostru=
m.com]


S=
ent: Thursday, February 20, 2014 11:55 PM


T=
o: Wiehe, Ulrich (NSN - DE/Munich)


C=
c: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


&=
nbsp;


O=
n Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:=



&=
nbsp;


#=
35: additional report types are proposed


 =



D=
ear all,


 =



I=
 believe we can conclude, not to add additional report types. However, we a=
greed to add clarifying text to clause 5.5 as follows:

 =



W=
hen an agent received an OLR in response to a request initiated by a client=
 not supporting DOIC, this agent needs to bind the received OLR to the orig=
in-host of the client.


&=
nbsp;


I=
 do not agree.


&=
nbsp;


Y=
ou proposal implies that the server's OLR only applies to that client.=



&=
lt;Ulrich>exactly, that was the intention</Ulrich>  If there'=
s an intervening DOIC agent, then the agent, not the client, is the reactin=
g node from the server's perspective.


&=
lt;Ulrich> the server's perspective is agnostic. The server does not kno=
w whether it's the client or an agent on the path that takes the role of th=
e reacting node</Ulrich>  But, short of adding an origin-host ty=
pe, nothing binds the OLR to a particular client, regardless of DOIC suppor=
t at the clients.


&=
lt;Ulrich> the binding is always there, regardless of DOIC support at th=
e client</Ulrich>


&=
nbsp;


 =
Whether or not the client also supports DOIC doesn't change that. For DOIC-=
supporting clients, the agent has the additional option of reducing traffic=
 by asking the clients to reduce traffic (making them reacting nodes from t=
he perspective of the _agent_, but not the server.)  It doesn't have t=
hat option for non-DOIC clients.


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


&=
nbsp;


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;




 













_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime




 


_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.




 






--_000_087A34937E64E74E848732CFF8354B9209784EA0ESESSMB101erics_--


From nobody Tue Feb 25 01:16:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB1E1A044B for ; Tue, 25 Feb 2014 01:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3Z28TRfiiYl for ; Tue, 25 Feb 2014 01:16:31 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 135251A03C3 for ; Tue, 25 Feb 2014 01:16:30 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1P9G59B013641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 10:16:27 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1P9G33o023139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 10:16:05 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 10:16:04 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 10:16:04 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] Issue #23 Proposed resolution
Thread-Index: AQHPMYgSwlGz+BG9tU6NO0Z/p7pW15rEtPYAgAAHfQCAAOD5AIAAEn9A
Date: Tue, 25 Feb 2014 09:16:03 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net>
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4657DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 17618
X-purgate-ID: 151667::1393319787-00003660-4289031E/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AirdpyFFGDp9Fwzhke1MJU9NUTg
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:16:35 -0000

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

Steve, MCruz,

lets go step by step.


I'm ok to conclude on #23 to do the renaming from "realm report type" to "r=
ealm-routed-request report type" and clarify that it applies to destination=
-host-less traffic.


Whether or not to introduce a 3rd report type of "realm" is out of scope of=
 #23 and subject of #55.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 25, 2014 10:05 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Steve,

The discussion started around some proposed use cases by Ulrich, and to my =
knowledge that discussion is not concluded.
Then we have not agreed (at least yet) on having a differentiation between =
realm and realm-routed.
Even more, as far as I understand the proposal it is related to the ability=
 (by agent) to select the a server (in a farm, providing service to a realm=
) for new session establishment. This is something we discussed long time a=
go, and at that point in time we tend to agree that it was not required, bu=
t up to different applications to decide based on realm overload.
Enhancements could be done on top of this, but first we need to agree on th=
e basic use cases.

I hope this clarifies
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:40
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is indicate=
d by the origin-host AVP in the answer message carrying the report.  Can be=
 generated by a server or by an agent acting as a front-end to a group of s=
ervers.

- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated by a =
server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.  =
Can be generated by a server or an agent.  The method for determining the r=
ealm state is out of scope for the DOIC document.

Steve
On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
Hello,

I do not think we have agreed so far on the need to have two different repo=
rts (so called realm-routed and just realm).
Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: dime@ietf.org
Subject: [Dime] Issue #23 Proposed resolution

I propose the following resolution for issue 23:


Proposal - Change the name of realm report.

Proposed name - "Realm-Routed-Request" report.

Proposal - Update all discussion on "Realm-Routed-Request" reports to indic=
ate that they apply only to requests targeted to a realm when there is no d=
estination-host AVP in the request.  Specifically, section 4.6 requires upd=
ating.

There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.

Regards,

Steve



_______________________________________________

DiME mailing list

DiME@ietf.org

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


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











Steve=
, MCruz,


=
 


lets go step by step.


 


 


I’m ok to conclude on #23 to do the renaming from “re=
alm report type” to “realm-routed-request report type” an=
d clarify that it applies to destination-host-less traffic.


 


 


Whether or not to introduce a 3rd report type of ̶=
0;realm” is out of scope of #23 and subject of #55.=



 


 


Ulrich



 






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Tuesday, February 25, 2014 10:05 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Steve,


 


The discussion started around some proposed use cases by Ulrich, =
and to my knowledge that discussion is not concluded.


Then we have not agreed (at least yet) on having a differentiatio=
n between realm and realm-routed.



Even more, as far as I understand the proposal it is related to t=
he ability (by agent) to select the a server (in a farm, providing service =
to a realm) for new session establishment.
 This is something we discussed long time ago, and at that point in time we=
 tend to agree that it was not required, but up to different applications t=
o decide based on realm overload.


Enhancements could be done on top of this, but first we need to a=
gree on the basic use cases.


 


I hope this clarifies


Cheers


/MCruz


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:40

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


=
Maria Cruz,



I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect=
.



The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).



- Host report - Apply to all requests sent to a host.  The host is ind=
icated by the origin-host AVP in the answer message carrying the report.&nb=
sp; Can be generated by a server or by an agent acting as a front-end to a =
group of servers.



- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated =
by a server or by an agent acting as a front-end to a group of servers.



- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.&n=
bsp; Can be generated by a server or an agent.  The method for determi=
ning the realm state is out of scope for the
 DOIC document.



Steve




On 2/24/14 1:12 PM, Maria Cruz =
Bartolome wrote:






Hello,


 


I do not think we have agreed so far on the need to have two diff=
erent reports (so called realm-routed and just realm).


Regards


/MCruz


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 18:44

To: dime@ietf.org

Subject: [Dime] Issue #23 Proposed resolution






 


=
I propose the following resolution for issue 23:








Proposal – Change the name of realm rep=
ort.  




Proposed name - “Realm-Routed-Request” report.




Proposal – Update all discussion on “Realm-Routed-Request”=
; reports to indicate that they apply only to requests targeted to a realm =
when there is no destination-host AVP in the request.  Specifically, s=
ection 4.6 requires updating.



There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.



Regards,



Steve 









_______________________________________________


DiME mailing list


DiME@ietf.org


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



 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4657DEMUMBX014nsnin_--


From nobody Tue Feb 25 01:18:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105E11A03C3 for ; Tue, 25 Feb 2014 01:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byH_SfXdof0E for ; Tue, 25 Feb 2014 01:18:46 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB71A0656 for ; Tue, 25 Feb 2014 01:18:44 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-2e-530c5ff27b33
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 82.80.04853.2FF5C035; Tue, 25 Feb 2014 10:18:42 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:18:42 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#34 proposed conclusion
Thread-Index: AQHPMaGVPDwsXsJzXUKc4Q4jGi1p8JrFscMA
Date: Tue, 25 Feb 2014 09:18:41 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784EB7@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F31@DEMUMBX014.nsn-intra.net> <530BAFBC.80101@usdonovans.com>
In-Reply-To: <530BAFBC.80101@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784EB7ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje6neJ5gg8lnbSzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvqJ2xgL9ptXvGz6ydjAeMywi5GTQ0LARGJ63ztWCFtM4sK9 9WxdjFwcQgInGCXO3n/EDOEsZpS4sW4VO0gVm4CdxKXTL5i6GDk4RASUJU7/cgAJCwsYSFx7 fRJskIiAocT5X91MELaRxPnXixlBbBYBVYkVS2aA2bwCvhKfj7xjA7GFBAolbp+cC1bPKaAj MePhRbBVjEAHfT+1BizOLCAucevJfCaIQwUkluw5zwxhi0q8fPwP6gElicYlT1gh6vMl2ia/ Y4HYJShxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilGy OLW4ODfdyEAvNz23RC+1KDO5uDg/T684dRMjMJYObvlttIPx5B77Q4zSHCxK4rzXWWuChATS E0tSs1NTC1KL4otKc1KLDzEycXBKNTDOF6m8syowTL/BafpVXT1uz5Wp+s78b1lKZmq89zC7 mPWv9O6Dqs7Tyub5USu/pacV/ZYL0ztS/Dsw9tadt212R/4+ODNL48rehZcFL1VU8j9OFn1e JGfHrHDIUShmZ4vqQZ1FAjZR2RFbGQOTy/In7uSaKmKy4XOK32ld2e6MBhZbpv3f4pRYijMS DbWYi4oTAdMPVedzAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7SpLt-8aalt4Z25ys0bUtKLsGRg
Subject: Re: [Dime] Issue#34 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:18:48 -0000

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

Agreed

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 21:47
To: dime@ietf.org
Subject: Re: [Dime] Issue#34 proposed conclusion

+1
On 2/20/14 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
#34: Semantics of OC-Report-Type AVP

Dear all,

Apart from potentially renaming "realm report" to something else (I don't l=
ike "realm routed report" as its not the report that is realm-routed) I bel=
ieve we finally agreed to accept the text as proposed in ticket#34 and repl=
ace the corresponding text from clause 4.6.

Ulrich







_______________________________________________

DiME mailing list

DiME@ietf.org

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


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











Agreed<=
/p>

 <=
/p>





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

Sent: lunes, 24 de febrero de 2014 21:47

To: dime@ietf.org

Subject: Re: [Dime] Issue#34 proposed conclusion





 


+1




On 2/20/14 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:








#34: Semantics of OC-Report-Type AVP






 






Dear all,






 






Apart from potentially renaming “=
realm report” to something else (I don’t like “realm rout=
ed report” as its not the report that is realm-routed) I believe we f=
inally agreed
 to accept the text as proposed in ticket#34 and replace the corresponding =
text from clause 4.6.






 






Ulrich






 






 






 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_087A34937E64E74E848732CFF8354B9209784EB7ESESSMB101erics_--


From nobody Tue Feb 25 01:22:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9371A0653 for ; Tue, 25 Feb 2014 01:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibpa46NHpWLi for ; Tue, 25 Feb 2014 01:22:14 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A01881A044B for ; Tue, 25 Feb 2014 01:22:13 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-5c-530c60c3bb07
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 85.DC.23809.3C06C035; Tue, 25 Feb 2014 10:22:11 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:22:11 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #38: Server Farm Definition Issue
Thread-Index: AQHPMaSjzjTp4ZcRekCIPakGj68UjJrFsrrg
Date: Tue, 25 Feb 2014 09:22:10 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784EC8@ESESSMB101.ericsson.se>
References: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> <213D2B01-4A4F-4C06-9272-B93D98F629BC@gmail.com> <530BB4E5.7010301@usdonovans.com>
In-Reply-To: <530BB4E5.7010301@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784EC8ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje6RBJ5ggzXzRCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxutH3gVXvSvW/FzJ1sDY69TFyMkhIWAicfn1WWYIW0ziwr31 bF2MXBxCAocYJc496WCFcBYzSnTN/8IEUsUmYCdx6fQLIJuDQ0RAWeL0LweQsLCAjUT3JJBB IGFbiZ17/EHCIgJGEmdnfGYEsVkEVCXWfDvLAmLzCvhKrD+yhhFi/FxGiRNtXewgCU4BPYkp e2aDNTACHfT91BqwtcwC4hK3nsxngjhUQGLJnvNQR4tKvHz8jxXCVpJoXPKEFaI+X+Lds2ls EMsEJU7OfMIygVFkFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2Vcxsucm ZuaklxttYgRGycEtv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjPn3L87xtgv9KdA9Sbdr32P/mu4cRSnGbXlKR6PkPBdKSn3a6qTq8Ozdjev/rzb9t600 k7rOevjd9LliK+fvLmnTS/tT0vpW4ja//vFXFxZN5Zp4913QQZVZJVsY+3/quTZHzTWRirip W/0tZffyI8wJs8T2rnbKFL6p4Xqgd/dWm9tPLOa/1VFiKc5INNRiLipOBACt/u9XYAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/S1pd7ka4YOe93gD6eFU5tOAWjhw
Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:22:17 -0000

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

Yes, this issues goes away.
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 22:09
To: Jouni Korhonen; dime@ietf.org
Cc: ben@nostrum.com
Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue

I believe that we agreed to remove the discussion and definition of server =
farms when discussion issue #24.  If we still agree on that then this issue=
 goes away.

Steve
On 2/10/14 4:53 AM, Jouni Korhonen wrote:



Good point. I would clarify that a server farm could mean both: one with

a single identity and one with multiple identities. The selection is

implementation and deployment specific.



- Jouni





On Feb 7, 2014, at 10:37 PM, dime issue tracker  wrote:



#38: Server Farm Definition Issue



A "server farm" is defined as "A set of Diameter servers that can handle

any request for a given set of Diameter applications.". This is not

strictly true. For example, if a request includes a Destination-Server

AVP, then then in general only that particular server in the farm can

handle the request.



I assume that we don't mean to limit the server farm concept to situations

where the entire farm is known by a single Diameter-Identity, do we?



--

-------------------------+-------------------------------------------------

Reporter:               |      Owner:  draft-docdt-dime-

 ben@nostrum.com        |  ovli@tools.ietf.org

    Type:  defect       |     Status:  new

Priority:  minor        |  Milestone:

Component:  draft-       |    Version:  1.0

 docdt-dime-ovli        |   Keywords:

Severity:  Active WG    |

 Document               |

-------------------------+-------------------------------------------------



Ticket URL: 

dime 








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











Yes, this issues goes awa=
y.


Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





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

Sent: lunes, 24 de febrero de 2014 22:09

To: Jouni Korhonen; dime@ietf.org

Cc: ben@nostrum.com

Subject: Re: [Dime] [dime] #38: Server Farm Definition Issue






 


I believe that we agr=
eed to remove the discussion and definition of server farms when discussion=
 issue #24.  If we still agree on that then this issue goes away.



Steve




On 2/10/14 4:53 AM, Jouni Korhonen wrote:=







 


Good point. I would clarify that a server farm could mean both: one wi=
th


a single identity and one with multiple identities. The selection is <=
o:p>


implementation and deployment specific.


 


- Jouni


 


 


On Feb 7, 2014, at 10:37 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wrote:


 




#38: Server Farm Definition Issue


 


A "server farm" is defined as "A set of Diameter server=
s that can handle


any request for a given set of Diameter applications.". This is n=
ot


strictly true. For example, if a request includes a Destination-Server=



AVP, then then in general only that particular server in the farm can<=
o:p>


handle the request.


 


I assume that we don't mean to limit the server farm concept to situat=
ions


where the entire farm is known by a single Diameter-Identity, do we?


 


-- 


-------------------------+----------------------------------------=
---------


Reporter:           =
    |      Owner:  draft-=
docdt-dime-


 ben@nostrum.com  &nb=
sp;     |  =
ovli@tools.ietf.org


    Type:  defect     &nb=
sp; |     Status:  new


Priority:  minor        | =
; Milestone:


Component:  draft-       | &nb=
sp;  Version:  1.0


 docdt-dime-ovli        | &nbs=
p; Keywords:


Severity:  Active WG    |


 Document          &=
nbsp;    |


-------------------------+----------------------------------------=
---------


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/38>


dime <http://tools.ietf.=
org/wg/dime/>


 




 


 




 






--_000_087A34937E64E74E848732CFF8354B9209784EC8ESESSMB101erics_--


From nobody Tue Feb 25 01:23:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9B1A0659 for ; Tue, 25 Feb 2014 01:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxJp8v1sVQY7 for ; Tue, 25 Feb 2014 01:22:58 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E62BD1A0654 for ; Tue, 25 Feb 2014 01:22:57 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1P9I2Ur018771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 10:22:55 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1P90dfl028258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 10:00:41 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 10:00:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 10:00:40 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #56: Bad Description of Overload Control State
Thread-Index: AQHPLKXn/K5opEUqEkqiVdwfHsd6G5rEUNjAgABEvoCAARY+cA==
Date: Tue, 25 Feb 2014 09:00:40 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B461C@DEMUMBX014.nsn-intra.net>
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net> <530B7729.3010005@usdonovans.com>
In-Reply-To: <530B7729.3010005@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 7469
X-purgate-ID: 151667::1393320175-00003660-F287E6C5/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/czHq3am12NKnI2jN1Fp1l_YquDg
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:23:00 -0000

Steve,

thank you for your comments.

Please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 5:45 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

Ulrich,

See inline.

Steve
On 2/24/14 5:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
There has been no discussion of this ticket.

I propose to replace text in claues 5.5.1 as suggested in the ticket.

Regards
Ulrich


-----Original Message-----
From: ext dime issue tracker [mailto:trac+dime@grenache.tools.ietf.org]=20
Sent: Tuesday, February 18, 2014 1:35 PM
To: draft-docdt-dime-ovli@tools.ietf.org; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: [dime] #56: Bad Description of Overload Control State

#56: Bad Description of Overload Control State

 The description of Overload Control State in clause 5.5.1 is inaccurate,
 incomplete and could be misleading. It does not differentiate between
 Overload Control State in a reacting node versus Overload Control State in
 a reporting node. It also does not describe how Overload Control States
 are maintained.

 It is proposed to replace current text with the following:


 5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node (client) maintains per supported Diameter application

SRD> Why qualify with client.=A0 It applies to all reacting nodes.
 I agree to remove "(client)"


    a host-type Overload Control State for each Destination-Host towards
    which it sends host-type requests and a realm-type Overload Control
 State
SRD> ...and... (add the word and here)
 I do not agree 


    for each Destination-Realm toward which it sends realm-type requests.
    A host-type Overload Control State may be identified by the pair of
    Application-Id and Destination-Host; a realm-type Overload Control
 State
    may be identified by the pair of Application-Id and Destination-Realm.
    The host-type/realm-type Overload Control State for a given pair of
    Application and Destination-Host / Destination-Realm could include the
    information as shown in table 1/table 2.

    
SRD> Reception time and validity duration could be replaced with "expiratio=
n time"
 I agree 



    Agents that take the role of a reacting node on behalf of clients MUST
    maintain Overload Control States per client.
SRD> This depends on the resolution of the current discussion of issue 35.=
=A0 I propose it be modified to "Agents that take the reacting node on beha=
lf of non-supporting clients must maintain either the global overload state=
 or per client overload state if requested by the reporting node.
 I agree that this depends on the outcome of #35 



    5.5.1.2   Overload Control States for reporting nodes

    A reporting node (server) maintains per supported Diameter application
SRD> There is no reason to qualify the reporting node as a server.=A0 It co=
uld also be an agent and all of this still applies.
 the agent case is described below (agent that is configured to tak=
e the role of a reporting node for a given realm) and there are differences=
 =20

    an Overload Control State for each Origin-Host from which it receives
    requests that contain an (explicit or implicit) indication of
    OLR_DEFAULT_ALGO support.
SRD> It doesn't need to be per Origin-Host, per the discussion of issue 35.=
=A0 We should support a global overload state if the reporting node doesn't=
 which to keep per reacting node state.
 I agree that this depends on the outcome of #35 


    A reporting node (agent that is configured to take the role of a
    reporting node for a given realm) maintains per supported Diameter
    application an Overload Control State for each Origin-Host from which
 it
    receives realm-type requests (of that given realm) that contain an
    (explicit or implicit) indication of OLR_DEFAULT_ALGO support.

    A Overload Control State may be identified by the pair of Application-
 Id
    and Origin-Host.
SRD> I don't see this as a must.=A0 It could be identified by just Applicat=
ion-ID.
 I agree that this depends on the outcome of #35 


    The Overload Control State for a given pair of Application and Origin-
    Host could include the information as shown in table 3.
    
SRD> Expiration time should be sufficient.
 no, you need to store the validity duration since this will be sen=
t in OLRs


    Note: For nodes that support other features than just OLR_DEFAULT_ALGO
    the Overload Control State definitions may need to be extended.

    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS with OCS-Id =3D (x,A) when
 receiving
    an answer message of application x containing an Orig-Host of A and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS with OCS-Id =3D (x,A) when
 receiving
    an answer message of application x containing an Orig-Realm of A and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS with OCS-Id =3D (x,A) when
    receiving an answer message of application x containing an Orig-Host of
    A and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS with OCS-Id =3D (x,A) when
    receiving an answer message of application x containing an Orig-Realm
 of
    A and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS with OCS-Id =3D (x,A) when receiving a
    request (indicating support of OLR_DEFAULT_ALGO) of application x
    containing an Orig-Host of A unless such OCS already exists.
SRD> Why would the reporting node create an OCS when it is not overloaded?=
=A0 Shouldn't this be modified to say that the reporting nodes creates an O=
CS when receiving a request and when in an overloaded state for the applica=
tion?
 ok 

=A0 Also, we should not require that the reporting node keep state for all =
reacting nodes, it should be able to keep a single state for all reacting n=
odes.
 I agree that this depends on the outcome of #35 


    Reporting nodes delete an OCS when it expires.
SRD> or when the reporting node exits the overload state.=A0 This should be=
 after the reporting node sends an overload report with validity duration o=
f zero to reacting nodes.
 there are dependencies with #31 and #35: once a single OLR with va=
lidity duration of zero is sent you should not delete the OCS as there may =
be other agents (issue #31) or even other clients (issue #35) that did not =
get the "end of overload indication"


    Reporting nodes update the OCS with OCS-Id =3D (x,A) when they detect t=
he
    need to modify the requested amount of application x traffic reduction
    generated by A.



From nobody Tue Feb 25 01:31:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BB31A03F6 for ; Tue, 25 Feb 2014 01:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XZxrdeIQhoY for ; Tue, 25 Feb 2014 01:30:56 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 577991A03AB for ; Tue, 25 Feb 2014 01:30:55 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-88-530c62cd1586
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BD.62.04853.DC26C035; Tue, 25 Feb 2014 10:30:54 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:30:53 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpquSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8ICAABIAAIAAoHoQgADcMfCAEHWF2YAAyG6Q
Date: Tue, 25 Feb 2014 09:30:53 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784EE8@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com>  <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <579DC2BE-CC3C-43E6-819C-ADB7B1182CED@nostrum.com> <530BBA98.9080903@usdonovans.com>
In-Reply-To: <530BBA98.9080903@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784EE8ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje65JJ5gg1NfWCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtvj11gLHodUnNp8mq2B8Y97FyMnh4SAicTRWfeZIWwxiQv3 1rN1MXJxCAmcYJR4t3A5O4SzmFFi2uFDYFVsAnYSl06/YOpi5OAQEVCWOP3LASQsLOAt8ePD ZSYQW0TAR6K38QjYIBGBfYwShz6sBetlEVCVWDD7DQuIzSvgK3F63yWobW/YJe41nwPr5hTQ k5h7/Do7iM0IdNL3U2vA4swC4hK3nsxngjhVQGLJnvNQZ4tKvHz8jxXCVpJoXPKEFaI+X+L1 o5NQywQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFK FqcWF+emGxno5abnluilFmUmFxfn5+kVp25iBMbTwS2/jXYwntxjf4hRmoNFSZz3OmtNkJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbG7Wuel/ZKXLi1sOHYp7qOJsmEBtuTFiodrw6rau3h 6T7UvUKg9vuy55fN3AKY5Szc1G7H9HouUzf+cF+344x/qbTWC0WX9yzfN0gemR/J7iLRf1D0 /XXLWoeFeznfqE1nkSx+NtXdP9bc6cW3jDPFV5YuOzhB59CbOJWlVqsF8ph57dgf3XqkxFKc kWioxVxUnAgA2FJrX3UCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4G3w0LvGv_wCND1T9zuUs3nYleY
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:30:58 -0000

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

Fine

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 22:33
To: dime@ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I think the proposal here is the following:

A reporting node communicates that an overload report is no longer valid by=
 sending an OLR with a Validity-Period AVP with a value of zero.  This is t=
he only way for a reporting node to indicate that an overload report is no =
longer valid.  For instance, setting the reduction-percentage to zero does =
not make the overload report invalid.

Do we have agreement on this?

Steve
On 2/17/14 12:44 PM, Ben Campbell wrote:



On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com wrote:



I would like to highlight that my proposal is not related to the default Re=
duction-percentage algo.



Whatever the ago used, I think that an OLR can only be sent for two purpose=
s:

- Send an indication of overload situation

- Send an indication of end of the overload situation



For me, providing both indications in the same message would be a non-sense=
. And I don't understand why the validity period would prevail in that case=
.



So here's the question: Let's assume a reporting node sends you an OLR usin=
g the "loss" algorithm, a reduction-percentage of 50%, and a Validity-Durat=
ion of 10 minutes. 5 minutes later, it sends you a new OLR with an invalid =
reduction percentage and a Validity-Duration of 0.



What's the current overload state?



What if the second OLR used the "rate" algorithm, with a valid value, but s=
till had a validity duration of 0. Does that change anything?



I am arguing that, in both cases, the second OLR ends the overload period.



I'm actually okay if we have a normative statement to the effect that the r=
eporting node MUST NOT send an invalid reduction percentage, and that a rea=
cting node MUST ignore an OLR with an invalid value _except_ for the case o=
f a validity-duration set to zero.



This all comes down to how much guessing we are willing to do about the int=
ent of the sender when one receives an invalid OLR. I think it's reasonable=
 to guess that a zero validity duration means to end an overload condition,=
 without regard to the rest of the message. I _don't_ think it's reasonable=
 to try to guess what the sender meant with an invalid reduction percentage=
, when the validity period is non-zero.



Another, perhaps simpler, approach would be to assert that the reception of=
 _any_ invalid OLR automatically ends any existing overload condition. (I'm=
 not necessarily arguing for that--it's just something to think about.)





Now, if what is argued by Ben and supported by JJ and Steve is clear for th=
e rest of the group, I will not fight.



... but the fighting is the fun part :-)

_______________________________________________

DiME mailing list

DiME@ietf.org

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




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











Fine

 <=
/p>





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

Sent: lunes, 24 de febrero de 2014 22:33

To: dime@ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I think the proposal =
here is the following:



A reporting node communicates that an overload report is no longer valid by=
 sending an OLR with a Validity-Period AVP with a value of zero.  This=
 is the only way for a reporting node to indicate that an overload report i=
s no longer valid.  For instance, setting
 the reduction-percentage to zero does not make the overload report invalid=
.  



Do we have agreement on this?



Steve




On 2/17/14 12:44 PM, Ben Campbell wrote:<=
/p>





 


On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com wrote:


 




I would like to highlight that my proposal is not related to the defau=
lt Reduction-percentage algo.


 


Whatever the ago used, I think that an OLR can only be sent for two pu=
rposes:


- Send an indication of overload situation


- Send an indication of end of the overload situation


 


For me, providing both indications in the same message would be a non-=
sense. And I don't understand why the validity period would prevail in that=
 case.




 


So here's the question: Let's assume a reporting node sends you an OLR=
 using the "loss" algorithm, a reduction-percentage of 50%, and a=
 Validity-Duration of 10 minutes. 5 minutes later, it sends you a new OLR w=
ith an invalid reduction percentage and a Validity-Duration of 0.


 


What's the current overload state?


 


What if the second OLR used the "rate" algorithm, with a val=
id value, but still had a validity duration of 0. Does that change anything=
?


 


I am arguing that, in both cases, the second OLR ends the overload per=
iod.


 


I'm actually okay if we have a normative statement to the effect that =
the reporting node MUST NOT send an invalid reduction percentage, and that =
a reacting node MUST ignore an OLR with an invalid value _except_ for the c=
ase of a validity-duration set to zero.


 


This all comes down to how much guessing we are willing to do about th=
e intent of the sender when one receives an invalid OLR. I think it's reaso=
nable to guess that a zero validity duration means to end an overload condi=
tion, without regard to the rest of the message. I _don't_ think it's reaso=
nable to try to guess what the sender meant with an invalid reduction perce=
ntage, when the validity period is non-zero.


 


Another, perhaps simpler, approach would be to assert that the recepti=
on of _any_ invalid OLR automatically ends any existing overload condition.=
 (I'm not necessarily arguing for that--it's just something to think about.=
)


 




 


Now, if what is argued by Ben and supported by JJ and Steve is clear f=
or the rest of the group, I will not fight.




 


... but the fighting is the fun part :-)


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_087A34937E64E74E848732CFF8354B9209784EE8ESESSMB101erics_--


From nobody Tue Feb 25 01:33:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB74D1A042A for ; Tue, 25 Feb 2014 01:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pn6Xdsxm2nP for ; Tue, 25 Feb 2014 01:33:19 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6372D1A03AB for ; Tue, 25 Feb 2014 01:33:18 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-b1-530c635c96a3
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 36.D2.04853.C536C035; Tue, 25 Feb 2014 10:33:17 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:33:16 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue #23 Proposed resolution
Thread-Index: AQHPMYgSECydxGIpskK7qjdEofxvM5rExTAw///3QwCAAO+3EP//9GuAgAAVbaA=
Date: Tue, 25 Feb 2014 09:33:16 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784EF9@ESESSMB101.ericsson.se>
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784EF9ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW5sMk+wwd1/rBZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/D27YwFf7oYK85sXc3SwNhT2cXIySEhYCLx/lgXM4QtJnHh 3nq2LkYuDiGBE4wSH44tYoVwFjNKdNzvYAGpYhOwk7h0+gVTFyMHh4iAssTpXw4gprCAocT3 D4IgFSICRhINX2YzQdh+EhPuXgezWQRUJfpWt4BN4RXwlWg+9Z8JYvx8JomlE84yg8zhFAiQ +PfVEaSGEeie76fWgPUyC4hL3HoynwniTgGJJXvOQ90sKvHy8T9WCFtJonHJE1aI+nyJ1kv7 oHYJSpyc+YRlAqPILCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9ilCxO LS7OTTcy0MtNzy3RSy3KTC4uzs/TK07dxAiMpYNbfhvtYDy5x/4QozQHi5I473XWmiAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjNNDczjrV++ecXaf5FL5y1bW4S+1w00eS7kycu4Q0Ozr XJJ67/glI3H1gne6TUrsPxk2zT/Sx/5Pb8+exS4G/7s42xN2XAp66MA651vOksSUvXVrJ7/O /CXmZtwf/tH/UhPfnVMshUnVd+qVdWTfBZ379qTb7qhxdXKl24lfnKvXMXydYOv/SomlOCPR UIu5qDgRAJDDlmZzAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cNeczj_6eYnjCp31Rez12Aovfz0
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:33:23 -0000

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

Fine to agree

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: martes, 25 de febrero de 2014 10:16
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue #23 Proposed resolution

Steve, MCruz,

lets go step by step.


I'm ok to conclude on #23 to do the renaming from "realm report type" to "r=
ealm-routed-request report type" and clarify that it applies to destination=
-host-less traffic.


Whether or not to introduce a 3rd report type of "realm" is out of scope of=
 #23 and subject of #55.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 25, 2014 10:05 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Steve,

The discussion started around some proposed use cases by Ulrich, and to my =
knowledge that discussion is not concluded.
Then we have not agreed (at least yet) on having a differentiation between =
realm and realm-routed.
Even more, as far as I understand the proposal it is related to the ability=
 (by agent) to select the a server (in a farm, providing service to a realm=
) for new session establishment. This is something we discussed long time a=
go, and at that point in time we tend to agree that it was not required, bu=
t up to different applications to decide based on realm overload.
Enhancements could be done on top of this, but first we need to agree on th=
e basic use cases.

I hope this clarifies
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:40
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is indicate=
d by the origin-host AVP in the answer message carrying the report.  Can be=
 generated by a server or by an agent acting as a front-end to a group of s=
ervers.

- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated by a =
server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.  =
Can be generated by a server or an agent.  The method for determining the r=
ealm state is out of scope for the DOIC document.

Steve
On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
Hello,

I do not think we have agreed so far on the need to have two different repo=
rts (so called realm-routed and just realm).
Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: dime@ietf.org
Subject: [Dime] Issue #23 Proposed resolution

I propose the following resolution for issue 23:

Proposal - Change the name of realm report.

Proposed name - "Realm-Routed-Request" report.

Proposal - Update all discussion on "Realm-Routed-Request" reports to indic=
ate that they apply only to requests targeted to a realm when there is no d=
estination-host AVP in the request.  Specifically, section 4.6 requires upd=
ating.

There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.

Regards,

Steve


_______________________________________________

DiME mailing list

DiME@ietf.org

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


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











Fine =
to agree


=
 






From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wi=
ehe@nsn.com]


Sent: martes, 25 de febrero de 2014 10:16

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue #23 Proposed resolution<=
/p>





 


Steve, MCruz,


 


lets =
go step by step.


=
 


=
 


IR=
17;m ok to conclude on #23 to do the renaming from “realm report type=
” to “realm-routed-request report type” and clarify that =
it applies to destination-host-less traffic.


=
 


=
 


Wheth=
er or not to introduce a 3rd report type of “realm” =
is out of scope of #23 and subject of #55.


=
 


=
 


Ulric=
h 


=
 






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Tuesday, February 25, 2014 10:05 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Steve=
,


=
 


The d=
iscussion started around some proposed use cases by Ulrich, and to my knowl=
edge that discussion is not concluded.


Then =
we have not agreed (at least yet) on having a differentiation between realm=
 and realm-routed.



Even =
more, as far as I understand the proposal it is related to the ability (by =
agent) to select the a server (in a farm, providing service to a realm) for=
 new session establishment. This is
 something we discussed long time ago, and at that point in time we tend to=
 agree that it was not required, but up to different applications to decide=
 based on realm overload.


Enhan=
cements could be done on top of this, but first we need to agree on the bas=
ic use cases.


=
 


I hop=
e this clarifies


Cheer=
s


/MCru=
z


=
 






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:40

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Maria Cruz,



I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect=
.



The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).



- Host report - Apply to all requests sent to a host.  The host is ind=
icated by the origin-host AVP in the answer message carrying the report.&nb=
sp; Can be generated by a server or by an agent acting as a front-end to a =
group of servers.



- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated =
by a server or by an agent acting as a front-end to a group of servers.



- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.&n=
bsp; Can be generated by a server or an agent.  The method for determi=
ning the realm state is out of scope for the
 DOIC document.



Steve




On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:=







Hello=
,


 =
;


I do =
not think we have agreed so far on the need to have two different reports (=
so called realm-routed and just realm).


Regar=
ds


/MCru=
z


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 18:44

To: dime@ietf.org

Subject: [Dime] Issue #23 Proposed resolution






 


I propose the followi=
ng resolution for issue 23:






Proposal – Change the name of realm report.  




Proposed name - “Realm-Routed-Request” report.




Proposal – Update all discussion on “Realm-Routed-Request”=
; reports to indicate that they apply only to requests targeted to a realm =
when there is no destination-host AVP in the request.  Specifically, s=
ection 4.6 requires updating.



There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.



Regards,



Steve 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_087A34937E64E74E848732CFF8354B9209784EF9ESESSMB101erics_--


From nobody Tue Feb 25 01:55:20 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3611A0318 for ; Tue, 25 Feb 2014 01:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHkrVxX69u0w for ; Tue, 25 Feb 2014 01:55:18 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0421F1A066C for ; Tue, 25 Feb 2014 01:55:17 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-3c-530c68840a29
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id CE.66.04853.4886C035; Tue, 25 Feb 2014 10:55:16 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:55:15 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue #25 Proposed Resolution
Thread-Index: AQHPMbYNGJRK2achn0CXJLkLNKfuOprFu+SQ
Date: Tue, 25 Feb 2014 09:55:14 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784F50@ESESSMB101.ericsson.se>
References: <530B87D0.1040003@usdonovans.com> <214266C0-601C-4BDC-B2F9-910BF3BD9557@nostrum.com>
In-Reply-To: <214266C0-601C-4BDC-B2F9-910BF3BD9557@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+JvjW5LBk+wwbdbChZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49209awFzWwVR3ueMTUwfmLpYuTkkBAwkbjy4CcThC0mceHe ejYQW0jgBKPEmUeWEPZiRokpvxNBbDYBO4lLp18A1XNwiAgoS5z+5QBiCgsYStw7xwNSISJg JPFixmFGGPv9/7lgE1kEVCUONX5nB7F5BXwlbr96wAQxPUli4rZlzCA2p4C9xJ/tC8DijEDX fD+1BsxmFhCXuPVkPtSVAhJL9pxnhrBFJV4+/scKYStJNC55wgpRryOxYPcnNghbW2LZwtfM EHsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMksWpxcW56UYGernpuSV6qUWZycXF+Xl6 xambGIFRcXDLb6MdjCf32B9ilOZgURLnvc5aEyQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB UYOrwmRuc8iqji2WZ37cnywr/J9NoPROzeMoPo01pb5fQ331Zj04+Lhw+7qCDRGyKVu094mY l1zp1knmuu2kvqSgJdgwftk09+SYaHuzOSfP2nCY1d5+uuH2knkFl8/tfedlcXC2tDXTpBi5 TP67c8RdHC+78s1LMF/KtHrJs4dtvi3ci07OUGIpzkg01GIuKk4EAHnPpT5YAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JD1i597KAv3PCztbl9Mv2Zds1IE
Subject: Re: [Dime] Issue #25 Proposed Resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 09:55:19 -0000

Agreed

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 25 de febrero de 2014 0:13
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Issue #25 Proposed Resolution


On Feb 24, 2014, at 11:56 AM, Steve Donovan  wrot=
e:

> I propose that we close issue 25 as the resolution of issue 24 addressed =
the concerns raised in issue 25.
>=20
> Note that this requires a new section in the draft to define agent behavi=
or.  The actual wording of that section will need to be agreed to before is=
sue 24 can be closed.
>=20


Agreed.

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


From nobody Tue Feb 25 03:29:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835E21A0685 for ; Tue, 25 Feb 2014 02:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6COz9VzKfk1 for ; Tue, 25 Feb 2014 02:42:04 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CE61A0690 for ; Tue, 25 Feb 2014 02:42:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: dime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140225104203.30199.10903.idtracker@ietfa.amsl.com>
Date: Tue, 25 Feb 2014 02:42:03 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hDH2bgTZo7v8uYeSQq0heWbDmTc
X-Mailman-Approved-At: Tue, 25 Feb 2014 03:29:04 -0800
Subject: [Dime] Milestones changed for dime WG
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 10:42:05 -0000

Changed milestone "Submit 'Diameter Application Design Guidelines' to
the IESG for consideration as a BCP document", added
draft-ietf-dime-app-design-guide to milestone.

URL: http://datatracker.ietf.org/wg/dime/charter/


From nobody Tue Feb 25 05:12:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E177B1A06D9 for ; Tue, 25 Feb 2014 05:12:06 -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
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 54D0EeEuxZw3 for ; Tue, 25 Feb 2014 05:12:04 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E1BA31A0089 for ; Tue, 25 Feb 2014 05:12:04 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55546 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIHng-0005lg-Mo; Tue, 25 Feb 2014 05:12:00 -0800
Message-ID: <530C969C.3060107@usdonovans.com>
Date: Tue, 25 Feb 2014 07:11:56 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Maria Cruz Bartolome , "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" 
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------040207060205070808040208"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Yu2SZxgR5mOy3FS15QN1AeFzpYo
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 13:12:07 -0000

This is a multi-part message in MIME format.
--------------040207060205070808040208
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

How do agents learn about a set of servers ability to handle new
sessions (host-less requests) if servers never sent realm-routed-request
reports?

I agree that agents should sent to aggregated report but the servers
need to send RRR reports so the agent can route around them and generate
those aggregated reports.

Steve

On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Hi,
>
> I agree with MCruz.
>
>  
>
> Principle is that the server never sends OLRs with a report type of
> realm-routed-request (exept the case where the server knows (i.e.is
> configured) that there is no other server in that realm).
>
>  
>
> Only agents that are configured to take the role of a reporting node
> for a realm will insert OLRs with report type of realm-routed-requests
> into answer messages and the content should be the aggregation of
> percentages as received in host type OLRs from all the servers in the
> realm.
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, February 24, 2014 8:31 PM
> *To:* Maria Cruz Bartolome; dime@ietf.org;
> draft-docdt-dime-ovli@tools.ietf.org
> *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload
> report type
>
>  
>
> Maria Cruz,
>
> Thanks for the comments.  We obviously have a different understanding
> of the meaning of realm-routed-request report (new attempt at a name
> to try to make Ulrich happy :-) ).
>
> My definition is that it is a report generated by the server when the
> server does not want to receive new sessions. 
>
> Your definition appears to be that it is a report generated by an
> agent (or a server is there are no agents in the network?) to indicate
> that the network need to handle fewer new sessions.
>
> I actually think both cases apply but I don't think that an agent can
> generate a realm-routed-request report without knowing the status of
> servers and their ability to handle new Diameter sessions.
>
> Note that I'm discussing this in the context of session-based
> applications.  This could also be applied to pseudo session based
> applications and applications that always rely on realm routed requests.
>
> Everyone, which definition applies?
>
> Steve
>
> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>
>     Steve,
>
>      
>
>     See some comments below please.
>
>     /MCruz
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
>
>     Sent: lunes, 24 de febrero de 2014 17:20
>
>     To: draft-docdt-dime-ovli@tools.ietf.org ; srdonovan@usdonovans.com 
>
>     Cc: dime@ietf.org 
>
>     Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>
>      
>
>     #57: Handling of "Realm-Routed" Overload report type
>
>      
>
>      I'm assuming the name of the realm overload report in the -01 version will
>
>      be changed to realm-routed.  This issue applies independent of the actual
>
>      name of the report.
>
>      
>
>      The current behavior assumed for the realm-routed report is that the
>
>      reacting node, generally the client, will reduce the percentage of realm
>
>      routed requests sent to the reporting node.
>
>      
>
>      This is actually bad behavior and could result in the client throttling
>
>      traffic that could have been handled by the full set of servers for that
>
>      Diameter application.
>
>     [MCruz] This can only happen if the agent has miscalculated the realm overload.
>
>      
>
>      Consider the case where there are n servers for a Diameter application and
>
>      all of those server are able to handle any transaction for that
>
>      application.
>
>      
>
>      When one of those servers becomes overloaded and wishes to decrease the
>
>      number of new sessions, the primary use of realm-routed requests.  The
>
>      server will generate an OLR of type realm-routed.
>
>     [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>
>      
>
>      Assume in this case that the other servers are all healthy and able to
>
>      handle new sessions.
>
>      
>
>      Clients will not have the knowledge that there are other servers in the
>
>      network able to handle the new session and will have no choice but the
>
>      throttle a percentage of the new session requests.  Even when these
>
>      throttled requests could have been handled by any of the non overloaded
>
>      servers.
>
>      
>
>      The proposal is to specify that realm-routed reports must be handled by
>
>      DOIC-supporting agents.  Agents will understand if there are other servers
>
>      able to handle the new session and, if so, can adjust the percentage of
>
>      requests routed to the overloaded server.
>
>      
>
>      Agents that handle the realm-routed OLR must remove the request from the
>
>      answer before relaying the answer to client.  This prevents the report
>
>      from being acted on by either multiple agents (if multiple are in the
>
>      path) or by an agent and a client.
>
>      
>
>      Clients that receive the realm-routed OLR must handle the OLR by
>
>      throttling the requested percentage.
>
>      
>
>  
>


--------------040207060205070808040208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    How do agents learn about
      a set of servers ability to handle new sessions (host-less
      requests) if servers never sent realm-routed-request reports?

      

      I agree that agents should sent to aggregated report but the
      servers need to send RRR reports so the agent can route around
      them and generate those aggregated reports.

      

      Steve

      

    
    
On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Hi,

        
I agree with MCruz.

        
 

        
Principle is that the server never sends OLRs
            with a report type of realm-routed-request (exept the case
            where the server knows (i.e.is configured) that there is no
            other server in that realm).

        
 

        
Only agents that are configured to take the
            role of a reporting node for a realm will insert OLRs with
            report type of realm-routed-requests into answer messages
            and the content should be the aggregation of percentages as
            received in host type OLRs from all the servers in the
            realm.

        
 

        
Ulrich

        
 

        
 

        
 

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Monday, February 24, 2014 8:31 PM

                To: Maria Cruz Bartolome; dime@ietf.org;
                draft-docdt-dime-ovli@tools.ietf.org

                Subject: Re: [Dime] [dime] #57: Handling of
                "Realm-Routed" Overload report type

          

        

        
 

        
Maria Cruz,

          

          Thanks for the comments.  We obviously have a different
          understanding of the meaning of realm-routed-request report
          (new attempt at a name to try to make Ulrich happy :-) ).

          

          My definition is that it is a report generated by the server
          when the server does not want to receive new sessions. 
          

          

          Your definition appears to be that it is a report generated by
          an agent (or a server is there are no agents in the network?)
          to indicate that the network need to handle fewer new
          sessions.

          

          I actually think both cases apply but I don't think that an
          agent can generate a realm-routed-request report without
          knowing the status of servers and their ability to handle new
          Diameter sessions.

          

          Note that I'm discussing this in the context of session-based
          applications.  This could also be applied to pseudo session
          based applications and applications that always rely on realm
          routed requests.

          

          Everyone, which definition applies?

          

          Steve

        

          
On 2/24/14 12:51 PM, Maria Cruz Bartolome
            wrote:

        

        

          
Steve,

          
 

          
See some comments below please.

          
/MCruz

          
 

          
-----Original Message-----

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

          
Sent: lunes, 24 de febrero de 2014 17:20

          
To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

          
Cc: dime@ietf.org

          
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

          
 

          
#57: Handling of "Realm-Routed" Overload report type

          
 

          
 I'm assuming the name of the realm overload report in the -01 version will

          
 be changed to realm-routed.  This issue applies independent of the actual

          
 name of the report.

          
 

          
 The current behavior assumed for the realm-routed report is that the

          
 reacting node, generally the client, will reduce the percentage of realm

          
 routed requests sent to the reporting node.

          
 

          
 This is actually bad behavior and could result in the client throttling

          
 traffic that could have been handled by the full set of servers for that

          
 Diameter application.

          
[MCruz] This can only happen if the agent has miscalculated the realm overload.

          
 

          
 Consider the case where there are n servers for a Diameter application and

          
 all of those server are able to handle any transaction for that

          
 application.

          
 

          
 When one of those servers becomes overloaded and wishes to decrease the

          
 number of new sessions, the primary use of realm-routed requests.  The

          
 server will generate an OLR of type realm-routed.

          
[MCruz] I do not agree. Servers do not generate Realm-routed reports.

          
 

          
 Assume in this case that the other servers are all healthy and able to

          
 handle new sessions.

          
 

          
 Clients will not have the knowledge that there are other servers in the

          
 network able to handle the new session and will have no choice but the

          
 throttle a percentage of the new session requests.  Even when these

          
 throttled requests could have been handled by any of the non overloaded

          
 servers.

          
 

          
 The proposal is to specify that realm-routed reports must be handled by

          
 DOIC-supporting agents.  Agents will understand if there are other servers

          
 able to handle the new session and, if so, can adjust the percentage of

          
 requests routed to the overloaded server.

          
 

          
 Agents that handle the realm-routed OLR must remove the request from the

          
 answer before relaying the answer to client.  This prevents the report

          
 from being acted on by either multiple agents (if multiple are in the

          
 path) or by an agent and a client.

          
 

          
 Clients that receive the realm-routed OLR must handle the OLR by

          
 throttling the requested percentage.

          
 

        

        
 

      

    

    

  


--------------040207060205070808040208--


From nobody Tue Feb 25 05:22:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBBD1A06E8 for ; Tue, 25 Feb 2014 05:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz4fnaUK01Au for ; Tue, 25 Feb 2014 05:22:28 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2EACC1A06EB for ; Tue, 25 Feb 2014 05:22:28 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55559 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIHxm-0002OD-J5 for dime@ietf.org; Tue, 25 Feb 2014 05:22:24 -0800
Message-ID: <530C990E.4040301@usdonovans.com>
Date: Tue, 25 Feb 2014 07:22:22 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784EF9@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784EF9@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------020000020805000308020704"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WirwBS9U9fbi2m3WIToCsUGqgBs
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 13:22:30 -0000

This is a multi-part message in MIME format.
--------------020000020805000308020704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I believe the other issue then is whether servers generate RRR reports.

Consider the most basic case where there are no agents.

 C1--\
 C2-------S
 C3--/

Is it not appropriate for a server, in this case, to be able to send RRRs?

In an agent case, the server sending the RRR gives the agent the ability
to generate an aggregated RRR the covers all servers for the
application.  So I guess, there would be a DOIC association between the
client and the agent use to transport the aggregated RRR and a DOIC
associate between the agent and the server used to transport the server
specific RRR.

Steve

On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:
>
> Fine to agree
>
>  
>
> *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> *Sent:* martes, 25 de febrero de 2014 10:16
> *To:* Maria Cruz Bartolome; dime@ietf.org
> *Subject:* RE: [Dime] Issue #23 Proposed resolution
>
>  
>
> Steve, MCruz,
>
>  
>
> lets go step by step.
>
>  
>
>  
>
> I'm ok to conclude on #23 to do the renaming from "realm report type"
> to "realm-routed-request report type" and clarify that it applies to
> destination-host-less traffic.
>
>  
>
>  
>
> Whether or not to introduce a 3^rd report type of "realm" is out of
> scope of #23 and subject of #55.
>
>  
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Tuesday, February 25, 2014 10:05 AM
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] Issue #23 Proposed resolution
>
>  
>
> Steve,
>
>  
>
> The discussion started around some proposed use cases by Ulrich, and
> to my knowledge that discussion is not concluded.
>
> Then we have not agreed (at least yet) on having a differentiation
> between realm and realm-routed.
>
> Even more, as far as I understand the proposal it is related to the
> ability (by agent) to select the a server (in a farm, providing
> service to a realm) for new session establishment. This is something
> we discussed long time ago, and at that point in time we tend to agree
> that it was not required, but up to different applications to decide
> based on realm overload.
>
> Enhancements could be done on top of this, but first we need to agree
> on the basic use cases.
>
>  
>
> I hope this clarifies
>
> Cheers
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 20:40
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] Issue #23 Proposed resolution
>
>  
>
> Maria Cruz,
>
> I thought you had asserted that there was a 3GPP requirement to have
> the ability to have a realm report that control the total amount of
> traffic sent to a realm.  There is certainly an IETF DOC requirement
> to this effect.
>
> The proposal is to have three report types (or four depending on the
> resolution of the per client host report discussion).
>
> - Host report - Apply to all requests sent to a host.  The host is
> indicated by the origin-host AVP in the answer message carrying the
> report.  Can be generated by a server or by an agent acting as a
> front-end to a group of servers.
>
> - Realm-routed-request report - Applies to all requests sent to a
> realm without a destination-host AVP in the request message.  Can be
> generated by a server or by an agent acting as a front-end to a group
> of servers.
>
> - Realm report - Applies to all requests sent to the realm,
> independent of the presence or absence of a destination-host AVP in
> the request message.  Can be generated by a server or an agent.  The
> method for determining the realm state is out of scope for the DOIC
> document.
>
> Steve
>
> On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
>
>     Hello,
>
>      
>
>     I do not think we have agreed so far on the need to have two
>     different reports (so called realm-routed and just realm).
>
>     Regards
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve
>     Donovan
>     *Sent:* lunes, 24 de febrero de 2014 18:44
>     *To:* dime@ietf.org 
>     *Subject:* [Dime] Issue #23 Proposed resolution
>
>      
>
>     I propose the following resolution for issue 23:
>
>     Proposal -- Change the name of realm report.  
>
>
>     Proposed name - "Realm-Routed-Request" report.
>
>
>     Proposal -- Update all discussion on "Realm-Routed-Request"
>     reports to indicate that they apply only to requests targeted to a
>     realm when there is no destination-host AVP in the request. 
>     Specifically, section 4.6 requires updating.
>
>     There is also a proposal to add a new report type to handle all
>     transactions to a realm.  This is addressed by ticket number 55.
>
>     Regards,
>
>     Steve
>
>      
>
>     _______________________________________________
>
>     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


--------------020000020805000308020704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I believe the other issue
      then is whether servers generate RRR reports.

      

      Consider the most basic case where there are no agents.

      

       C1--\

       C2-------S

       C3--/

      

      Is it not appropriate for a server, in this case, to be able to
      send RRRs?

      

      In an agent case, the server sending the RRR gives the agent the
      ability to generate an aggregated RRR the covers all servers for
      the application.  So I guess, there would be a DOIC association
      between the client and the agent use to transport the aggregated
      RRR and a DOIC associate between the agent and the server used to
      transport the server specific RRR.

      

      Steve 

      

    
    
On 2/25/14 3:33 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Fine to agree

        
 

        

          

            
From:
                Wiehe, Ulrich (NSN - DE/Munich)
                [mailto:ulrich.wiehe@nsn.com]
                

                Sent: martes, 25 de febrero de 2014 10:16

                To: Maria Cruz Bartolome; dime@ietf.org

                Subject: RE: [Dime] Issue #23 Proposed resolution

          

        

        
 

        
Steve,
            MCruz,

        
 

        
lets go step by step.

        
 

        
 

        
I’m ok to conclude on
            #23 to do the renaming from “realm report type” to
            “realm-routed-request report type” and clarify that it
            applies to destination-host-less traffic.

        
 

        
 

        
Whether or not to
            introduce a 3rd report type of “realm” is out of
            scope of #23 and subject of #55.

        
 

        
 

        
Ulrich 

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Maria Cruz Bartolome

                Sent: Tuesday, February 25, 2014 10:05 AM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue #23 Proposed resolution

          

        

        
 

        
Steve,

        
 

        
The discussion
            started around some proposed use cases by Ulrich, and to my
            knowledge that discussion is not concluded.

        
Then we have not
            agreed (at least yet) on having a differentiation between
            realm and realm-routed.
            

        
Even more, as far as
            I understand the proposal it is related to the ability (by
            agent) to select the a server (in a farm, providing service
            to a realm) for new session establishment. This is something
            we discussed long time ago, and at that point in time we
            tend to agree that it was not required, but up to different
            applications to decide based on realm overload.

        
Enhancements could be
            done on top of this, but first we need to agree on the basic
            use cases.

        
 

        
I hope this clarifies

        
Cheers

        
/MCruz

        
 

        

          

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

                Sent: lunes, 24 de febrero de 2014 20:40

                To: dime@ietf.org

                Subject: Re: [Dime] Issue #23 Proposed resolution

          

        

        
 

        
Maria Cruz,

          

          I thought you had asserted that there was a 3GPP requirement
          to have the ability to have a realm report that control the
          total amount of traffic sent to a realm.  There is certainly
          an IETF DOC requirement to this effect.

          

          The proposal is to have three report types (or four depending
          on the resolution of the per client host report discussion).

          

          - Host report - Apply to all requests sent to a host.  The
          host is indicated by the origin-host AVP in the answer message
          carrying the report.  Can be generated by a server or by an
          agent acting as a front-end to a group of servers.

          

          - Realm-routed-request report - Applies to all requests sent
          to a realm without a destination-host AVP in the request
          message.  Can be generated by a server or by an agent acting
          as a front-end to a group of servers.

          

          - Realm report - Applies to all requests sent to the realm,
          independent of the presence or absence of a destination-host
          AVP in the request message.  Can be generated by a server or
          an agent.  The method for determining the realm state is out
          of scope for the DOIC document.

          

          Steve

        

          
On 2/24/14 1:12 PM, Maria Cruz Bartolome
            wrote:

        

        

          
Hello,

          
 

          
I do not think we
              have agreed so far on the need to have two different
              reports (so called realm-routed and just realm).

          
Regards

          
/MCruz

          
 

          

            

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

                  Sent: lunes, 24 de febrero de 2014 18:44

                  To: dime@ietf.org

                  Subject: [Dime] Issue #23 Proposed resolution

            

          

          
 

          
I propose
            the following resolution for issue 23:

            

            

          
Proposal
            – Change the name of realm report.  

          


            Proposed name - “Realm-Routed-Request” report.

          


              Proposal – Update all discussion on “Realm-Routed-Request”
              reports to indicate that they apply only to requests
              targeted to a realm when there is no destination-host AVP
              in the request.  Specifically, section 4.6 requires
              updating.

              

              There is also a proposal to add a new report type to
              handle all transactions to a realm.  This is addressed by
              ticket number 55.

              

              Regards,

              

              Steve 

          
 

          
_______________________________________________

          
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


    

    

  


--------------020000020805000308020704--


From nobody Tue Feb 25 06:18:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590101A06E7 for ; Tue, 25 Feb 2014 06:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvVUTuIZvlFr for ; Tue, 25 Feb 2014 06:18:25 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 449E61A045D for ; Tue, 25 Feb 2014 06:18:24 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1PEIKEn012721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 15:18:20 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1PEIKxB023471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 15:18:20 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 15:18:19 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Maria Cruz Bartolome , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
Thread-Index: AQHPMisvc6zzBhdNjkKe3lYGjzc2zZrGAadw
Date: Tue, 25 Feb 2014 14:18:19 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com>
In-Reply-To: <530C969C.3060107@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B473FDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 20225
X-purgate-ID: 151667::1393337900-00003660-713C35A6/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/22F9ZLanjYa7EUpAR4xIirIT9D8
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 14:18:28 -0000

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

My understanding is that RRR reports are always aggregated reports. Agents =
generating an RRR report (for use on the DOIC association towards the react=
ing node) take as an input the host-type reports received on the DOIC assoc=
iations with the servers.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, February 25, 2014 2:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf.org; d=
raft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

How do agents learn about a set of servers ability to handle new sessions (=
host-less requests) if servers never sent realm-routed-request reports?

I agree that agents should sent to aggregated report but the servers need t=
o send RRR reports so the agent can route around them and generate those ag=
gregated reports.

Steve
On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Hi,
I agree with MCruz.

Principle is that the server never sends OLRs with a report type of realm-r=
outed-request (exept the case where the server knows (i.e.is configured) th=
at there is no other server in that realm).

Only agents that are configured to take the role of a reporting node for a =
realm will insert OLRs with report type of realm-routed-requests into answe=
r messages and the content should be the aggregation of percentages as rece=
ived in host type OLRs from all the servers in the realm.

Ulrich




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-=
dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of th=
e meaning of realm-routed-request report (new attempt at a name to try to m=
ake Ulrich happy :-) ).

My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions.

Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and appli=
cations that always rely on realm routed requests.

Everyone, which definition applies?

Steve
On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:

Steve,



See some comments below please.

/MCruz



-----Original Message-----

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

Sent: lunes, 24 de febrero de 2014 17:20

To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

Cc: dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type



#57: Handling of "Realm-Routed" Overload report type



 I'm assuming the name of the realm overload report in the -01 version will

 be changed to realm-routed.  This issue applies independent of the actual

 name of the report.



 The current behavior assumed for the realm-routed report is that the

 reacting node, generally the client, will reduce the percentage of realm

 routed requests sent to the reporting node.



 This is actually bad behavior and could result in the client throttling

 traffic that could have been handled by the full set of servers for that

 Diameter application.

[MCruz] This can only happen if the agent has miscalculated the realm overl=
oad.



 Consider the case where there are n servers for a Diameter application and

 all of those server are able to handle any transaction for that

 application.



 When one of those servers becomes overloaded and wishes to decrease the

 number of new sessions, the primary use of realm-routed requests.  The

 server will generate an OLR of type realm-routed.

[MCruz] I do not agree. Servers do not generate Realm-routed reports.



 Assume in this case that the other servers are all healthy and able to

 handle new sessions.



 Clients will not have the knowledge that there are other servers in the

 network able to handle the new session and will have no choice but the

 throttle a percentage of the new session requests.  Even when these

 throttled requests could have been handled by any of the non overloaded

 servers.



 The proposal is to specify that realm-routed reports must be handled by

 DOIC-supporting agents.  Agents will understand if there are other servers

 able to handle the new session and, if so, can adjust the percentage of

 requests routed to the overloaded server.



 Agents that handle the realm-routed OLR must remove the request from the

 answer before relaying the answer to client.  This prevents the report

 from being acted on by either multiple agents (if multiple are in the

 path) or by an agent and a client.



 Clients that receive the realm-routed OLR must handle the OLR by

 throttling the requested percentage.





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











My underst=
anding is that RRR reports are always aggregated reports. Agents generating=
 an RRR report (for use on the DOIC association towards the
 reacting node) take as an input the host-type reports received on the DOIC=
 associations with the servers.


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Tuesday, February 25, 2014 2:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf=
.org; draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


How do agents learn a=
bout a set of servers ability to handle new sessions (host-less requests) i=
f servers never sent realm-routed-request reports?



I agree that agents should sent to aggregated report but the servers need t=
o send RRR reports so the agent can route around them and generate those ag=
gregated reports.



Steve




On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Hi,=



I agree wi=
th MCruz.


 


Principle =
is that the server never sends OLRs with a report type of realm-routed-requ=
est (exept the case where the server knows (i.e.is configured)
 that there is no other server in that realm).


 


Only agent=
s that are configured to take the role of a reporting node for a realm will=
 insert OLRs with report type of realm-routed-requests into
 answer messages and the content should be the aggregation of percentages a=
s received in host type OLRs from all the servers in the realm.=



 


Ulrich


 


 


 


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, February 24, 2014 8:31 PM

To: Maria Cruz Bartolome; dime@ietf=
.org;
draft-docdt-dime-ov=
li@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


Maria Cruz,



Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to try=
 to make Ulrich happy :-) ).



My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions. 




Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.



I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.



Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and =
applications that always rely on realm routed requests.



Everyone, which definition applies?



Steve




On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:






Steve,


 


See some comments below please.


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of dime issue tracker


Sent: lunes, 24 de febrero de 2014 17:20


To: draft-docd=
t-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com


Cc: dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overl=
oad report type


 


#57: Handling of "Realm-Routed" Overload report type


 


 I'm assuming the name of the realm overload report in the -01 version=
 will


 be changed to realm-routed.  This issue applies independent of t=
he actual


 name of the report.


 


 The current behavior assumed for the realm-routed report is that the<=
o:p>


 reacting node, generally the client, will reduce the percentage of re=
alm


 routed requests sent to the reporting node.


 


 This is actually bad behavior and could result in the client throttli=
ng


 traffic that could have been handled by the full set of servers for t=
hat


 Diameter application.


[MCruz] This can only happen if the agent has miscalculated the realm =
overload.


 


 Consider the case where there are n servers for a Diameter applicatio=
n and


 all of those server are able to handle any transaction for that<=
/o:p>


 application.


 


 When one of those servers becomes overloaded and wishes to decrease t=
he


 number of new sessions, the primary use of realm-routed requests.&nbs=
p; The


 server will generate an OLR of type realm-routed.


[MCruz] I do not agree. Servers do not generate Realm-routed reports.<=
o:p>


 


 Assume in this case that the other servers are all healthy and able t=
o


 handle new sessions.


 


 Clients will not have the knowledge that there are other servers in t=
he


 network able to handle the new session and will have no choice but th=
e


 throttle a percentage of the new session requests.  Even when th=
ese


 throttled requests could have been handled by any of the non overload=
ed


 servers.


 


 The proposal is to specify that realm-routed reports must be handled =
by


 DOIC-supporting agents.  Agents will understand if there are oth=
er servers


 able to handle the new session and, if so, can adjust the percentage =
of


 requests routed to the overloaded server.


 


 Agents that handle the realm-routed OLR must remove the request from =
the


 answer before relaying the answer to client.  This prevents the =
report


 from being acted on by either multiple agents (if multiple are in the=



 path) or by an agent and a client.


 


 Clients that receive the realm-routed OLR must handle the OLR by=



 throttling the requested percentage.


 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B473FDEMUMBX014nsnin_--


From nobody Tue Feb 25 06:23:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6641A0708 for ; Tue, 25 Feb 2014 06:23:33 -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
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 njaPbpGnw4P8 for ; Tue, 25 Feb 2014 06:23:32 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E2A541A06FA for ; Tue, 25 Feb 2014 06:23:31 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55657 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIIuo-0005jm-2l; Tue, 25 Feb 2014 06:23:30 -0800
Message-ID: <530CA759.6070302@usdonovans.com>
Date: Tue, 25 Feb 2014 08:23:21 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Maria Cruz Bartolome , "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" 
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------000403010802090803020709"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nBI9k6E9fwxZXZ1vvNbmbRMD-Bw
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 14:23:34 -0000

This is a multi-part message in MIME format.
--------------000403010802090803020709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I'm not comfortable with this model that assumes that agents have a
better understanding then servers on the servers ability to handle new
sessions.

Are you also saying that RRRs can never be sent if an agent is not in
the network? 

RRRs are a way to control a specific type of request, generally requests
that create new sessions, recognizing that those requests are more
expensive than what we have referred to as mid-session requests.

Yes, agents should be able to create aggregated RRR reports but servers
should be able to send them as well.

Steve

On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> My understanding is that RRR reports are always aggregated reports.
> Agents generating an RRR report (for use on the DOIC association
> towards the reacting node) take as an input the host-type reports
> received on the DOIC associations with the servers.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Tuesday, February 25, 2014 2:12 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome;
> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
> *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload
> report type
>
>  
>
> How do agents learn about a set of servers ability to handle new
> sessions (host-less requests) if servers never sent
> realm-routed-request reports?
>
> I agree that agents should sent to aggregated report but the servers
> need to send RRR reports so the agent can route around them and
> generate those aggregated reports.
>
> Steve
>
> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Hi,
>
>     I agree with MCruz.
>
>      
>
>     Principle is that the server never sends OLRs with a report type
>     of realm-routed-request (exept the case where the server knows
>     (i.e.is configured) that there is no other server in that realm).
>
>      
>
>     Only agents that are configured to take the role of a reporting
>     node for a realm will insert OLRs with report type of
>     realm-routed-requests into answer messages and the content should
>     be the aggregation of percentages as received in host type OLRs
>     from all the servers in the realm.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>      
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Monday, February 24, 2014 8:31 PM
>     *To:* Maria Cruz Bartolome; dime@ietf.org ;
>     draft-docdt-dime-ovli@tools.ietf.org
>     
>     *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed"
>     Overload report type
>
>      
>
>     Maria Cruz,
>
>     Thanks for the comments.  We obviously have a different
>     understanding of the meaning of realm-routed-request report (new
>     attempt at a name to try to make Ulrich happy :-) ).
>
>     My definition is that it is a report generated by the server when
>     the server does not want to receive new sessions. 
>
>     Your definition appears to be that it is a report generated by an
>     agent (or a server is there are no agents in the network?) to
>     indicate that the network need to handle fewer new sessions.
>
>     I actually think both cases apply but I don't think that an agent
>     can generate a realm-routed-request report without knowing the
>     status of servers and their ability to handle new Diameter sessions.
>
>     Note that I'm discussing this in the context of session-based
>     applications.  This could also be applied to pseudo session based
>     applications and applications that always rely on realm routed
>     requests.
>
>     Everyone, which definition applies?
>
>     Steve
>
>     On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>
>         Steve,
>
>          
>
>         See some comments below please.
>
>         /MCruz
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
>
>         Sent: lunes, 24 de febrero de 2014 17:20
>
>         To: draft-docdt-dime-ovli@tools.ietf.org ; srdonovan@usdonovans.com 
>
>         Cc: dime@ietf.org 
>
>         Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>
>          
>
>         #57: Handling of "Realm-Routed" Overload report type
>
>          
>
>          I'm assuming the name of the realm overload report in the -01 version will
>
>          be changed to realm-routed.  This issue applies independent of the actual
>
>          name of the report.
>
>          
>
>          The current behavior assumed for the realm-routed report is that the
>
>          reacting node, generally the client, will reduce the percentage of realm
>
>          routed requests sent to the reporting node.
>
>          
>
>          This is actually bad behavior and could result in the client throttling
>
>          traffic that could have been handled by the full set of servers for that
>
>          Diameter application.
>
>         [MCruz] This can only happen if the agent has miscalculated the realm overload.
>
>          
>
>          Consider the case where there are n servers for a Diameter application and
>
>          all of those server are able to handle any transaction for that
>
>          application.
>
>          
>
>          When one of those servers becomes overloaded and wishes to decrease the
>
>          number of new sessions, the primary use of realm-routed requests.  The
>
>          server will generate an OLR of type realm-routed.
>
>         [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>
>          
>
>          Assume in this case that the other servers are all healthy and able to
>
>          handle new sessions.
>
>          
>
>          Clients will not have the knowledge that there are other servers in the
>
>          network able to handle the new session and will have no choice but the
>
>          throttle a percentage of the new session requests.  Even when these
>
>          throttled requests could have been handled by any of the non overloaded
>
>          servers.
>
>          
>
>          The proposal is to specify that realm-routed reports must be handled by
>
>          DOIC-supporting agents.  Agents will understand if there are other servers
>
>          able to handle the new session and, if so, can adjust the percentage of
>
>          requests routed to the overloaded server.
>
>          
>
>          Agents that handle the realm-routed OLR must remove the request from the
>
>          answer before relaying the answer to client.  This prevents the report
>
>          from being acted on by either multiple agents (if multiple are in the
>
>          path) or by an agent and a client.
>
>          
>
>          Clients that receive the realm-routed OLR must handle the OLR by
>
>          throttling the requested percentage.
>
>          
>
>      
>
>  
>


--------------000403010802090803020709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I'm not comfortable with
      this model that assumes that agents have a better understanding then
      servers on the servers ability to handle new sessions.

      

      Are you also saying that RRRs can never be sent if an agent is not
      in the network?  

      

      RRRs are a way to control a specific type of request, generally
      requests that create new sessions, recognizing that those requests
      are more expensive than what we have referred to as mid-session
      requests.

      

      Yes, agents should be able to create aggregated RRR reports but
      servers should be able to send them as well.

      

      Steve

      

    
    
On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
My understanding is that RRR reports are always
            aggregated reports. Agents generating an RRR report (for use
            on the DOIC association towards the reacting node) take as
            an input the host-type reports received on the DOIC
            associations with the servers.

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Tuesday, February 25, 2014 2:12 PM

                To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz
                Bartolome; dime@ietf.org;
                draft-docdt-dime-ovli@tools.ietf.org

                Subject: Re: [Dime] [dime] #57: Handling of
                "Realm-Routed" Overload report type

          

        

        
 

        
How do agents
          learn about a set of servers ability to handle new sessions
          (host-less requests) if servers never sent
          realm-routed-request reports?

          

          I agree that agents should sent to aggregated report but the
          servers need to send RRR reports so the agent can route around
          them and generate those aggregated reports.

          

          Steve

        

          
On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Hi,

          
I agree with MCruz.

          
 

          
Principle is that the server never sends OLRs
              with a report type of realm-routed-request (exept the case
              where the server knows (i.e.is configured) that there is
              no other server in that realm).

          
 

          
Only agents that are configured to take the
              role of a reporting node for a realm will insert OLRs with
              report type of realm-routed-requests into answer messages
              and the content should be the aggregation of percentages
              as received in host type OLRs from all the servers in the
              realm.

          
 

          
Ulrich

          
 

          
 

          
 

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Monday, February 24, 2014 8:31 PM

                  To: Maria Cruz Bartolome; dime@ietf.org;
                  draft-docdt-dime-ovli@tools.ietf.org

                  Subject: Re: [Dime] [dime] #57: Handling of
                  "Realm-Routed" Overload report type

            

          

          
 

          
Maria Cruz,

            

            Thanks for the comments.  We obviously have a different
            understanding of the meaning of realm-routed-request report
            (new attempt at a name to try to make Ulrich happy :-) ).

            

            My definition is that it is a report generated by the server
            when the server does not want to receive new sessions. 
            

            

            Your definition appears to be that it is a report generated
            by an agent (or a server is there are no agents in the
            network?) to indicate that the network need to handle fewer
            new sessions.

            

            I actually think both cases apply but I don't think that an
            agent can generate a realm-routed-request report without
            knowing the status of servers and their ability to handle
            new Diameter sessions.

            

            Note that I'm discussing this in the context of
            session-based applications.  This could also be applied to
            pseudo session based applications and applications that
            always rely on realm routed requests.

            

            Everyone, which definition applies?

            

            Steve

          

            
On 2/24/14 12:51 PM, Maria Cruz
              Bartolome wrote:

          

          

            
Steve,

            
 

            
See some comments below please.

            
/MCruz

            
 

            
-----Original Message-----

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

            
Sent: lunes, 24 de febrero de 2014 17:20

            
To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

            
Cc: dime@ietf.org

            
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

            
 

            
#57: Handling of "Realm-Routed" Overload report type

            
 

            
 I'm assuming the name of the realm overload report in the -01 version will

            
 be changed to realm-routed.  This issue applies independent of the actual

            
 name of the report.

            
 

            
 The current behavior assumed for the realm-routed report is that the

            
 reacting node, generally the client, will reduce the percentage of realm

            
 routed requests sent to the reporting node.

            
 

            
 This is actually bad behavior and could result in the client throttling

            
 traffic that could have been handled by the full set of servers for that

            
 Diameter application.

            
[MCruz] This can only happen if the agent has miscalculated the realm overload.

            
 

            
 Consider the case where there are n servers for a Diameter application and

            
 all of those server are able to handle any transaction for that

            
 application.

            
 

            
 When one of those servers becomes overloaded and wishes to decrease the

            
 number of new sessions, the primary use of realm-routed requests.  The

            
 server will generate an OLR of type realm-routed.

            
[MCruz] I do not agree. Servers do not generate Realm-routed reports.

            
 

            
 Assume in this case that the other servers are all healthy and able to

            
 handle new sessions.

            
 

            
 Clients will not have the knowledge that there are other servers in the

            
 network able to handle the new session and will have no choice but the

            
 throttle a percentage of the new session requests.  Even when these

            
 throttled requests could have been handled by any of the non overloaded

            
 servers.

            
 

            
 The proposal is to specify that realm-routed reports must be handled by

            
 DOIC-supporting agents.  Agents will understand if there are other servers

            
 able to handle the new session and, if so, can adjust the percentage of

            
 requests routed to the overloaded server.

            
 

            
 Agents that handle the realm-routed OLR must remove the request from the

            
 answer before relaying the answer to client.  This prevents the report

            
 from being acted on by either multiple agents (if multiple are in the

            
 path) or by an agent and a client.

            
 

            
 Clients that receive the realm-routed OLR must handle the OLR by

            
 throttling the requested percentage.

            
 

          

          
 

        

        
 

      

    

    

  


--------------000403010802090803020709--


From nobody Tue Feb 25 06:24:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CCC1A037A for ; Tue, 25 Feb 2014 06:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD1KYWGCZ3jm for ; Tue, 25 Feb 2014 06:24:36 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id E47EA1A0453 for ; Tue, 25 Feb 2014 06:24:35 -0800 (PST)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 459943B4446; Tue, 25 Feb 2014 15:24:34 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 1DDBEC818E; Tue, 25 Feb 2014 15:24:34 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 25 Feb 2014 15:24:33 +0100
From: 
To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , Maria Cruz Bartolome , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
Thread-Index: AQHPMisxxOZ2qKT5nEiEsF3hiOz/X5rF88OAgAABaICAABEHQA==
Date: Tue, 25 Feb 2014 14:24:33 +0000
Message-ID: <21117_1393338274_530CA7A2_21117_18545_1_6B7134B31289DC4FAF731D844122B36E4BE369@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <530CA759.6070302@usdonovans.com>
In-Reply-To: <530CA759.6070302@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4BE369PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.25.85115
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oiE2QTEBBQXP-YcnRNvqvGwWCDk
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 14:24:39 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4BE369PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The general idea is that a reduction is required. This reduction is either =
towards a specific host or towards the entire realm. Obviously, the realm i=
s equal to the some of the servers inside this realm (for a given applicati=
on) and the realm reduction is equal to the average of the reduction of eac=
h server. I think it was what we have described when discussing the report =
types needed in the OLR.
Which entity is sending this info is not so relevant. Usually, it will be a=
n agent in front of the realm but it could be also a server when this serve=
r is aware of the overload state of other servers in the realm.


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 25 f=E9vrier 2014 15:23
=C0 : Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf.org;=
 draft-docdt-dime-ovli@tools.ietf.org
Objet : Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report t=
ype

I'm not comfortable with this model that assumes that agents have a better =
understanding then servers on the servers ability to handle new sessions.

Are you also saying that RRRs can never be sent if an agent is not in the n=
etwork?

RRRs are a way to control a specific type of request, generally requests th=
at create new sessions, recognizing that those requests are more expensive =
than what we have referred to as mid-session requests.

Yes, agents should be able to create aggregated RRR reports but servers sho=
uld be able to send them as well.

Steve
On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
My understanding is that RRR reports are always aggregated reports. Agents =
generating an RRR report (for use on the DOIC association towards the react=
ing node) take as an input the host-type reports received on the DOIC assoc=
iations with the servers.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, February 25, 2014 2:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

How do agents learn about a set of servers ability to handle new sessions (=
host-less requests) if servers never sent realm-routed-request reports?

I agree that agents should sent to aggregated report but the servers need t=
o send RRR reports so the agent can route around them and generate those ag=
gregated reports.

Steve
On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Hi,
I agree with MCruz.

Principle is that the server never sends OLRs with a report type of realm-r=
outed-request (exept the case where the server knows (i.e.is configured) th=
at there is no other server in that realm).

Only agents that are configured to take the role of a reporting node for a =
realm will insert OLRs with report type of realm-routed-requests into answe=
r messages and the content should be the aggregation of percentages as rece=
ived in host type OLRs from all the servers in the realm.

Ulrich




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-=
dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of th=
e meaning of realm-routed-request report (new attempt at a name to try to m=
ake Ulrich happy :-) ).

My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions.

Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and appli=
cations that always rely on realm routed requests.

Everyone, which definition applies?

Steve
On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:

Steve,



See some comments below please.

/MCruz



-----Original Message-----

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

Sent: lunes, 24 de febrero de 2014 17:20

To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

Cc: dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type



#57: Handling of "Realm-Routed" Overload report type



 I'm assuming the name of the realm overload report in the -01 version will

 be changed to realm-routed.  This issue applies independent of the actual

 name of the report.



 The current behavior assumed for the realm-routed report is that the

 reacting node, generally the client, will reduce the percentage of realm

 routed requests sent to the reporting node.



 This is actually bad behavior and could result in the client throttling

 traffic that could have been handled by the full set of servers for that

 Diameter application.

[MCruz] This can only happen if the agent has miscalculated the realm overl=
oad.



 Consider the case where there are n servers for a Diameter application and

 all of those server are able to handle any transaction for that

 application.



 When one of those servers becomes overloaded and wishes to decrease the

 number of new sessions, the primary use of realm-routed requests.  The

 server will generate an OLR of type realm-routed.

[MCruz] I do not agree. Servers do not generate Realm-routed reports.



 Assume in this case that the other servers are all healthy and able to

 handle new sessions.



 Clients will not have the knowledge that there are other servers in the

 network able to handle the new session and will have no choice but the

 throttle a percentage of the new session requests.  Even when these

 throttled requests could have been handled by any of the non overloaded

 servers.



 The proposal is to specify that realm-routed reports must be handled by

 DOIC-supporting agents.  Agents will understand if there are other servers

 able to handle the new session and, if so, can adjust the percentage of

 requests routed to the overloaded server.



 Agents that handle the realm-routed OLR must remove the request from the

 answer before relaying the answer to client.  This prevents the report

 from being acted on by either multiple agents (if multiple are in the

 path) or by an agent and a client.



 Clients that receive the realm-routed OLR must handle the OLR by

 throttling the requested percentage.






___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4BE369PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











The genera=
l idea is that a reduction is required. This reduction is either towards a =
specific host or towards the entire realm. Obviously, the
 realm is equal to the some of the servers inside this realm (for a given a=
pplication) and the realm reduction is equal to the average of the reductio=
n of each server. I think it was what we have described when discussing the=
 report types needed in the OLR.


Which enti=
ty is sending this info is not so relevant. Usually, it will be an agent in=
 front of the realm but it could be also a server when this
 server is aware of the overload state of other servers in the realm. =



 =
;


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 25 f=E9vrier 2014 15:23

=C0 : Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; di=
me@ietf.org; draft-docdt-dime-ovli@tools.ietf.org

Objet : Re: [Dime] [dime] #57: Handling of "Realm-Routed&q=
uot; Overload report type






 


I'm not comfortable w=
ith this model that assumes that agents have a better understanding then se=
rvers on the servers ability to handle new sessions.



Are you also saying that RRRs can never be sent if an agent is not in the n=
etwork? 




RRRs are a way to control a specific type of request, generally requests th=
at create new sessions, recognizing that those requests are more expensive =
than what we have referred to as mid-session requests.



Yes, agents should be able to create aggregated RRR reports but servers sho=
uld be able to send them as well.



Steve




On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






My underst=
anding is that RRR reports are always aggregated reports. Agents generating=
 an RRR report (for use on the DOIC association towards the
 reacting node) take as an input the host-type reports received on the DOIC=
 associations with the servers.


 


Ulrich


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, February 25, 2014 2:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; 
dime@ietf.org; =
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


How do agents learn a=
bout a set of servers ability to handle new sessions (host-less requests) i=
f servers never sent realm-routed-request reports?



I agree that agents should sent to aggregated report but the servers need t=
o send RRR reports so the agent can route around them and generate those ag=
gregated reports.



Steve




On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Hi,=



I agree wi=
th MCruz.


 


Principle =
is that the server never sends OLRs with a report type of realm-routed-requ=
est (exept the case where the server knows (i.e.is configured)
 that there is no other server in that realm).


 


Only agent=
s that are configured to take the role of a reporting node for a realm will=
 insert OLRs with report type of realm-routed-requests into
 answer messages and the content should be the aggregation of percentages a=
s received in host type OLRs from all the servers in the realm.=



 


Ulrich


 


 


 


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, February 24, 2014 8:31 PM

To: Maria Cruz Bartolome; dime@ietf=
.org;
draft-docdt-dime-ov=
li@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


Maria Cruz,



Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to try=
 to make Ulrich happy :-) ).



My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions. 




Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.



I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.



Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and =
applications that always rely on realm routed requests.



Everyone, which definition applies?



Steve




On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:






Steve,


 


See some comments below please.


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of dime issue tracker


Sent: lunes, 24 de febrero de 2014 17:20


To: draft-docd=
t-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com


Cc: dime@ietf.org


Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overl=
oad report type


 


#57: Handling of "Realm-Routed" Overload report type


 


 I'm assuming the name of the realm overload report in the -01 version=
 will


 be changed to realm-routed.  This issue applies independent of t=
he actual


 name of the report.


 


 The current behavior assumed for the realm-routed report is that the<=
o:p>


 reacting node, generally the client, will reduce the percentage of re=
alm


 routed requests sent to the reporting node.


 


 This is actually bad behavior and could result in the client throttli=
ng


 traffic that could have been handled by the full set of servers for t=
hat


 Diameter application.


[MCruz] This can only happen if the agent has miscalculated the realm =
overload.


 


 Consider the case where there are n servers for a Diameter applicatio=
n and


 all of those server are able to handle any transaction for that<=
/o:p>


 application.


 


 When one of those servers becomes overloaded and wishes to decrease t=
he


 number of new sessions, the primary use of realm-routed requests.&nbs=
p; The


 server will generate an OLR of type realm-routed.


[MCruz] I do not agree. Servers do not generate Realm-routed reports.<=
o:p>


 


 Assume in this case that the other servers are all healthy and able t=
o


 handle new sessions.


 


 Clients will not have the knowledge that there are other servers in t=
he


 network able to handle the new session and will have no choice but th=
e


 throttle a percentage of the new session requests.  Even when th=
ese


 throttled requests could have been handled by any of the non overload=
ed


 servers.


 


 The proposal is to specify that realm-routed reports must be handled =
by


 DOIC-supporting agents.  Agents will understand if there are oth=
er servers


 able to handle the new session and, if so, can adjust the percentage =
of


 requests routed to the overloaded server.


 


 Agents that handle the realm-routed OLR must remove the request from =
the


 answer before relaying the answer to client.  This prevents the =
report


 from being acted on by either multiple agents (if multiple are in the=



 path) or by an agent and a client.


 


 Clients that receive the realm-routed OLR must handle the OLR by=



 throttling the requested percentage.


 




 




 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4BE369PEXCVZYM13corpora_--


From nobody Tue Feb 25 06:27:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964B1A0742 for ; Tue, 25 Feb 2014 06:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHGzXKYBH8tq for ; Tue, 25 Feb 2014 06:26:55 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EF3131A0732 for ; Tue, 25 Feb 2014 06:26:54 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1PEQfQS028023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 15:26:41 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1PEQOD1022340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 15:26:24 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 15:26:23 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 15:26:23 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue #23 Proposed resolution
Thread-Index: AQHPMYgSwlGz+BG9tU6NO0Z/p7pW15rEtPYAgAAHfQCAAOD5AIAAEn9AgABGUu6AAA/rIA==
Date: Tue, 25 Feb 2014 14:26:22 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4761@DEMUMBX014.nsn-intra.net>
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784EF9@ESESSMB101.ericsson.se> <530C990E.4040301@usdonovans.com>
In-Reply-To: <530C990E.4040301@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4761DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 23453
X-purgate-ID: 151667::1393338401-00005322-B8AD4F9D/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AAjT9uL-yFWxgNpFbH-io-EUEOs
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 14:27:01 -0000

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

Steve,

see inline

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 25, 2014 2:22 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

I believe the other issue then is whether servers generate RRR reports.

Consider the most basic case where there are no agents.

 C1--\
 C2-------S
 C3--/

Is it not appropriate for a server, in this case, to be able to send RRRs?
no

In an agent case, the server sending the RRR gives the agent the ability to=
 generate an aggregated RRR the covers all servers for the application.
the agent should aggregate received host-type reports and convert i=
t into an RRR report
  So I guess, there would be a DOIC association between the client and the =
agent use to transport the aggregated RRR
yes
and a DOIC associate between the agent and the server used to transport the=
 server specific RRR
server specific host-type report
.

Steve
On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:
Fine to agree

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: martes, 25 de febrero de 2014 10:16
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue #23 Proposed resolution

Steve, MCruz,

lets go step by step.


I'm ok to conclude on #23 to do the renaming from "realm report type" to "r=
ealm-routed-request report type" and clarify that it applies to destination=
-host-less traffic.


Whether or not to introduce a 3rd report type of "realm" is out of scope of=
 #23 and subject of #55.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 25, 2014 10:05 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Steve,

The discussion started around some proposed use cases by Ulrich, and to my =
knowledge that discussion is not concluded.
Then we have not agreed (at least yet) on having a differentiation between =
realm and realm-routed.
Even more, as far as I understand the proposal it is related to the ability=
 (by agent) to select the a server (in a farm, providing service to a realm=
) for new session establishment. This is something we discussed long time a=
go, and at that point in time we tend to agree that it was not required, bu=
t up to different applications to decide based on realm overload.
Enhancements could be done on top of this, but first we need to agree on th=
e basic use cases.

I hope this clarifies
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:40
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is indicate=
d by the origin-host AVP in the answer message carrying the report.  Can be=
 generated by a server or by an agent acting as a front-end to a group of s=
ervers.

- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated by a =
server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.  =
Can be generated by a server or an agent.  The method for determining the r=
ealm state is out of scope for the DOIC document.

Steve
On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
Hello,

I do not think we have agreed so far on the need to have two different repo=
rts (so called realm-routed and just realm).
Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: dime@ietf.org
Subject: [Dime] Issue #23 Proposed resolution

I propose the following resolution for issue 23:


Proposal - Change the name of realm report.

Proposed name - "Realm-Routed-Request" report.

Proposal - Update all discussion on "Realm-Routed-Request" reports to indic=
ate that they apply only to requests targeted to a realm when there is no d=
estination-host AVP in the request.  Specifically, section 4.6 requires upd=
ating.

There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.

Regards,

Steve


_______________________________________________

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


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











Steve=
,


=
 


see i=
nline


=
 






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, February 25, 2014 2:22 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


I believe the other i=
ssue then is whether servers generate RRR reports.



Consider the most basic case where there are no agents.



 C1--\

 C2-------S

 C3--/



Is it not appropriate for a server, in this case, to be able to send RRRs?<=
span style=3D"color:#1F497D">


<Ulrich>no</Ulrich&=
gt;



In an agent case, the server sending the RRR gives the agent the ability to=
 generate an aggregated RRR the covers all servers for the application.


<Ulrich>the agent shou=
ld aggregate received host-type reports and convert it into an RRR report&l=
t;/Ulrich>


=
  So I guess, there would be a DOIC association between the client and=
 the agent use to transport the aggregated RRR


<Ulrich>yes</Ulrich=
>


=
and a DOIC associate between the agent and the server used to transport the=
 server specific RRR


<Ulrich>server specifi=
c host-type report</Ulrich>


=
.



Steve 




On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:=







Fine =
to agree


 =
;






From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: martes, 25 de febrero de 2014 10:16

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: RE: [Dime] Issue #23 Proposed resolution<=
/p>





 


Steve=
, MCruz,


 =
;


lets =
go step by step.


 =
;


 =
;


IR=
17;m ok to conclude on #23 to do the renaming from “realm report type=
” to “realm-routed-request report type” and clarify that =
it applies to destination-host-less traffic.


 =
;


 =
;


Wheth=
er or not to introduce a 3rd report type of “realm” =
is out of scope of #23 and subject of #55.


 =
;


 =
;


Ulric=
h 


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Tuesday, February 25, 2014 10:05 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Steve=
,


 =
;


The d=
iscussion started around some proposed use cases by Ulrich, and to my knowl=
edge that discussion is not concluded.


Then =
we have not agreed (at least yet) on having a differentiation between realm=
 and realm-routed.



Even =
more, as far as I understand the proposal it is related to the ability (by =
agent) to select the a server (in a farm, providing service to a realm) for=
 new session establishment. This is
 something we discussed long time ago, and at that point in time we tend to=
 agree that it was not required, but up to different applications to decide=
 based on realm overload.


Enhan=
cements could be done on top of this, but first we need to agree on the bas=
ic use cases.


 =
;


I hop=
e this clarifies


Cheer=
s


/MCru=
z


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:40

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Maria Cruz,



I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect=
.



The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).



- Host report - Apply to all requests sent to a host.  The host is ind=
icated by the origin-host AVP in the answer message carrying the report.&nb=
sp; Can be generated by a server or by an agent acting as a front-end to a =
group of servers.



- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated =
by a server or by an agent acting as a front-end to a group of servers.



- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.&n=
bsp; Can be generated by a server or an agent.  The method for determi=
ning the realm state is out of scope for the
 DOIC document.



Steve




On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:=







Hello=
,


 =
;


I do =
not think we have agreed so far on the need to have two different reports (=
so called realm-routed and just realm).


Regar=
ds


/MCru=
z


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 18:44

To: dime@ietf.org

Subject: [Dime] Issue #23 Proposed resolution






 


I propose the followi=
ng resolution for issue 23:








Proposal – Change the name of realm report.  




Proposed name - “Realm-Routed-Request” report.




Proposal – Update all discussion on “Realm-Routed-Request”=
; reports to indicate that they apply only to requests targeted to a realm =
when there is no destination-host AVP in the request.  Specifically, s=
ection 4.6 requires updating.



There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.



Regards,



Steve 


 <=
o:p>


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4761DEMUMBX014nsnin_--


From nobody Tue Feb 25 06:48:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C526F1A0770 for ; Tue, 25 Feb 2014 06:48:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.28
X-Spam-Level: 
X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cHsFbWBoTFs for ; Tue, 25 Feb 2014 06:48:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id A3FA31A0779 for ; Tue, 25 Feb 2014 06:48:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55742 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIJJA-0004rW-ES; Tue, 25 Feb 2014 06:48:37 -0800
Message-ID: <530CAD40.8050505@usdonovans.com>
Date: Tue, 25 Feb 2014 08:48:32 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784EF9@ESESSMB101.ericsson.se> <530C990E.4040301@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4761@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4761@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060503040202010002060606"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SCChshmu81q5zRwH6vzMHJUb4YQ
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 14:48:42 -0000

This is a multi-part message in MIME format.
--------------060503040202010002060606
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Please see inline.

Steve

On 2/25/14 8:26 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> see inline
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, February 25, 2014 2:22 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue #23 Proposed resolution
>
>  
>
> I believe the other issue then is whether servers generate RRR reports.
>
> Consider the most basic case where there are no agents.
>
>  C1--\
>  C2-------S
>  C3--/
>
> Is it not appropriate for a server, in this case, to be able to send RRRs?
>
> */no/*
>
SRD> Then we have a bigger disconnect then I thought.  I'm pretty sure
that we had discussed the ability of a server to use what we are now
calling RRRs to be able to indicate that it does not want to take on new
sessions.  Host reports are used to control the mid-session traffic (for
session based applications like those used in the 3GPP PCC architecture). 

SRD> I would also assert that PCC is a case where there is a strong need
for the server to be able to say that it wants to reduce the number of
new session taken on so that the DRA in that architecture can properly
route sessions that generate new bindings.

SRD> So, to summarize, I believe that we DO have a requirement to allow
the server to send RRRs.

SRD> Maybe we need two types of RRRs, one that applies to a single
server and one that applies to the full realm.  Yes Ben, these do start
to sound like scopes :-) but this can also be addressed by either
creating separate report types or qualifying the RRR report.
>
>
> In an agent case, the server sending the RRR gives the agent the
> ability to generate an aggregated RRR the covers all servers for the
> application.
>
> */the agent should aggregate received host-type reports and
> convert it into an RRR report/*
>
SRD> This is what an agent would do to generate the proposed new "realm"
report.  I'm skeptical that an agent can make reasonable decisions about
what RRR report to generate based on host reports received.
>
>   So I guess, there would be a DOIC association between the client and
> the agent use to transport the aggregated RRR
>
> */yes/*
>
> and a DOIC associate between the agent and the server used to
> transport the server specific RRR
>
> */server specific host-type report/*
>
> .
>
> Steve
>
> On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:
>
>     Fine to agree
>
>      
>
>     *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>     *Sent:* martes, 25 de febrero de 2014 10:16
>     *To:* Maria Cruz Bartolome; dime@ietf.org 
>     *Subject:* RE: [Dime] Issue #23 Proposed resolution
>
>      
>
>     Steve, MCruz,
>
>      
>
>     lets go step by step.
>
>      
>
>      
>
>     I'm ok to conclude on #23 to do the renaming from "realm report
>     type" to "realm-routed-request report type" and clarify that it
>     applies to destination-host-less traffic.
>
>      
>
>      
>
>     Whether or not to introduce a 3^rd report type of "realm" is out
>     of scope of #23 and subject of #55.
>
>      
>
>      
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Maria Cruz Bartolome
>     *Sent:* Tuesday, February 25, 2014 10:05 AM
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] Issue #23 Proposed resolution
>
>      
>
>     Steve,
>
>      
>
>     The discussion started around some proposed use cases by Ulrich,
>     and to my knowledge that discussion is not concluded.
>
>     Then we have not agreed (at least yet) on having a differentiation
>     between realm and realm-routed.
>
>     Even more, as far as I understand the proposal it is related to
>     the ability (by agent) to select the a server (in a farm,
>     providing service to a realm) for new session establishment. This
>     is something we discussed long time ago, and at that point in time
>     we tend to agree that it was not required, but up to different
>     applications to decide based on realm overload.
>
>     Enhancements could be done on top of this, but first we need to
>     agree on the basic use cases.
>
>      
>
>     I hope this clarifies
>
>     Cheers
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve
>     Donovan
>     *Sent:* lunes, 24 de febrero de 2014 20:40
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] Issue #23 Proposed resolution
>
>      
>
>     Maria Cruz,
>
>     I thought you had asserted that there was a 3GPP requirement to
>     have the ability to have a realm report that control the total
>     amount of traffic sent to a realm.  There is certainly an IETF DOC
>     requirement to this effect.
>
>     The proposal is to have three report types (or four depending on
>     the resolution of the per client host report discussion).
>
>     - Host report - Apply to all requests sent to a host.  The host is
>     indicated by the origin-host AVP in the answer message carrying
>     the report.  Can be generated by a server or by an agent acting as
>     a front-end to a group of servers.
>
>     - Realm-routed-request report - Applies to all requests sent to a
>     realm without a destination-host AVP in the request message.  Can
>     be generated by a server or by an agent acting as a front-end to a
>     group of servers.
>
>     - Realm report - Applies to all requests sent to the realm,
>     independent of the presence or absence of a destination-host AVP
>     in the request message.  Can be generated by a server or an
>     agent.  The method for determining the realm state is out of scope
>     for the DOIC document.
>
>     Steve
>
>     On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
>
>         Hello,
>
>          
>
>         I do not think we have agreed so far on the need to have two
>         different reports (so called realm-routed and just realm).
>
>         Regards
>
>         /MCruz
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *Steve Donovan
>         *Sent:* lunes, 24 de febrero de 2014 18:44
>         *To:* dime@ietf.org 
>         *Subject:* [Dime] Issue #23 Proposed resolution
>
>          
>
>         I propose the following resolution for issue 23:
>
>
>         Proposal -- Change the name of realm report.  
>
>
>         Proposed name - "Realm-Routed-Request" report.
>
>
>         Proposal -- Update all discussion on "Realm-Routed-Request"
>         reports to indicate that they apply only to requests targeted
>         to a realm when there is no destination-host AVP in the
>         request.  Specifically, section 4.6 requires updating.
>
>         There is also a proposal to add a new report type to handle
>         all transactions to a realm.  This is addressed by ticket
>         number 55.
>
>         Regards,
>
>         Steve
>
>          
>
>         _______________________________________________
>
>         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
>
>  
>


--------------060503040202010002060606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Please see inline.

      

      Steve

      

    
    
On 2/25/14 8:26 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
see inline

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Tuesday, February 25, 2014 2:22 PM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue #23 Proposed resolution

          

        

        
 

        
I believe the
          other issue then is whether servers generate RRR reports.

          

          Consider the most basic case where there are no agents.

          

           C1--\

           C2-------S

           C3--/

          

          Is it not appropriate for a server, in this case, to be able
          to send RRRs?

        
<Ulrich>no</Ulrich>

          

      

    

    SRD> Then we have a bigger disconnect then I thought.  I'm pretty
    sure that we had discussed the ability of a server to use what we
    are now calling RRRs to be able to indicate that it does not want to
    take on new sessions.  Host reports are used to control the
    mid-session traffic (for session based applications like those used
    in the 3GPP PCC architecture).  

    

    SRD> I would also assert that PCC is a case where there is a
    strong need for the server to be able to say that it wants to reduce
    the number of new session taken on so that the DRA in that
    architecture can properly route sessions that generate new bindings.

    

    SRD> So, to summarize, I believe that we DO have a requirement to
    allow the server to send RRRs.

    

    SRD> Maybe we need two types of RRRs, one that applies to a
    single server and one that applies to the full realm.  Yes Ben,
    these do start to sound like scopes :-) but this can also be
    addressed by either creating separate report types or qualifying the
    RRR report.

    

      

        

            

            In an agent case, the server sending the RRR gives the agent
            the ability to generate an aggregated RRR the covers all
            servers for the application.

        
<Ulrich>the
                agent should aggregate received host-type reports and
                convert it into an RRR report</Ulrich>

      

    

    SRD> This is what an agent would do to generate the proposed new
    "realm" report.  I'm skeptical that an agent can make reasonable
    decisions about what RRR report to generate based on host reports
    received.

    

      

        
  So I guess, there would be a DOIC association
            between the client and the agent use to transport the
            aggregated RRR

        
<Ulrich>yes</Ulrich>

        
and a DOIC associate between the agent and the
            server used to transport the server specific RRR

        
<Ulrich>server
                specific host-type report</Ulrich>

        
.

            

          Steve 

        

          
On 2/25/14 3:33 AM, Maria Cruz Bartolome
            wrote:

        

        

          
Fine to agree

          
 

          

            

              
From:
                  Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
                  

                  Sent: martes, 25 de febrero de 2014 10:16

                  To: Maria Cruz Bartolome; dime@ietf.org

                  Subject: RE: [Dime] Issue #23 Proposed
                  resolution

            

          

          
 

          
Steve, MCruz,

          
 

          
lets go step by
              step.

          
 

          
 

          
I’m ok to conclude
              on #23 to do the renaming from “realm report type” to
              “realm-routed-request report type” and clarify that it
              applies to destination-host-less traffic.

          
 

          
 

          
Whether or not to
              introduce a 3rd report type of “realm” is out
              of scope of #23 and subject of #55.

          
 

          
 

          
Ulrich 

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Maria Cruz Bartolome

                  Sent: Tuesday, February 25, 2014 10:05 AM

                  To: dime@ietf.org

                  Subject: Re: [Dime] Issue #23 Proposed
                  resolution

            

          

          
 

          
Steve,

          
 

          
The discussion
              started around some proposed use cases by Ulrich, and to
              my knowledge that discussion is not concluded.

          
Then we have not
              agreed (at least yet) on having a differentiation between
              realm and realm-routed.
            

          
Even more, as far
              as I understand the proposal it is related to the ability
              (by agent) to select the a server (in a farm, providing
              service to a realm) for new session establishment. This is
              something we discussed long time ago, and at that point in
              time we tend to agree that it was not required, but up to
              different applications to decide based on realm overload.

          
Enhancements could
              be done on top of this, but first we need to agree on the
              basic use cases.

          
 

          
I hope this
              clarifies

          
Cheers

          
/MCruz

          
 

          

            

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

                  Sent: lunes, 24 de febrero de 2014 20:40

                  To: dime@ietf.org

                  Subject: Re: [Dime] Issue #23 Proposed
                  resolution

            

          

          
 

          
Maria Cruz,

            

            I thought you had asserted that there was a 3GPP requirement
            to have the ability to have a realm report that control the
            total amount of traffic sent to a realm.  There is certainly
            an IETF DOC requirement to this effect.

            

            The proposal is to have three report types (or four
            depending on the resolution of the per client host report
            discussion).

            

            - Host report - Apply to all requests sent to a host.  The
            host is indicated by the origin-host AVP in the answer
            message carrying the report.  Can be generated by a server
            or by an agent acting as a front-end to a group of servers.

            

            - Realm-routed-request report - Applies to all requests sent
            to a realm without a destination-host AVP in the request
            message.  Can be generated by a server or by an agent acting
            as a front-end to a group of servers.

            

            - Realm report - Applies to all requests sent to the realm,
            independent of the presence or absence of a destination-host
            AVP in the request message.  Can be generated by a server or
            an agent.  The method for determining the realm state is out
            of scope for the DOIC document.

            

            Steve

          

            
On 2/24/14 1:12 PM, Maria Cruz
              Bartolome wrote:

          

          

            
Hello,

            
 

            
I do not think we
                have agreed so far on the need to have two different
                reports (so called realm-routed and just realm).

            
Regards

            
/MCruz

            
 

            

              

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

                    Sent: lunes, 24 de febrero de 2014 18:44

                    To: dime@ietf.org

                    Subject: [Dime] Issue #23 Proposed resolution

              

            

            
 

            
I propose
              the following resolution for issue 23:

              

              

              

            
Proposal
              – Change the name of realm report.  

            


              Proposed name - “Realm-Routed-Request” report.

            


                Proposal – Update all discussion on
                “Realm-Routed-Request” reports to indicate that they
                apply only to requests targeted to a realm when there is
                no destination-host AVP in the request.  Specifically,
                section 4.6 requires updating.

                

                There is also a proposal to add a new report type to
                handle all transactions to a realm.  This is addressed
                by ticket number 55.

                

                Regards,

                

                Steve 

            
 

            
_______________________________________________

            
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

        

        
 

      

    

    

  


--------------060503040202010002060606--


From nobody Tue Feb 25 07:02:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ED01A0077 for ; Tue, 25 Feb 2014 07:02:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbbU1we3g8QX for ; Tue, 25 Feb 2014 07:02:17 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6116F1A06E2 for ; Tue, 25 Feb 2014 07:02:16 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55769 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIJWN-0005mD-8m; Tue, 25 Feb 2014 07:02:15 -0800
Message-ID: <530CB073.7000802@usdonovans.com>
Date: Tue, 25 Feb 2014 09:02:11 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010800060404040909090202"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nWFNxItBhxmooL1MEPkO5Pzj4w0
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 15:02:18 -0000

This is a multi-part message in MIME format.
--------------010800060404040909090202
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I agree with the suggested change.

Steve

On 2/24/14 5:00 PM, Ben Campbell wrote:
> + 1, except as noted:
>
> On Feb 24, 2014, at 2:33 PM, Steve Donovan  wrote:
>
>> Ulrich,
>>
>> Would you agree to the following to replace the first two statements:
>>
>> Sequence number is of type Unsigned64.
>>
>> When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for any occurrence of overload at a reporting node.  This, I think, allows us to ignore wraparound issues as wraparound will never happen.  Unless we are worried about a server staying in overload for billions of years (assuming reports with a ten minute validity period refreshed every five minutes).
> s/ any occurrence of overload / the initial occurrence of an overload condition
>
>> The other two statements are good.
>>
>> Steve
>


--------------010800060404040909090202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I agree with the
      suggested change.

      

      Steve

      

    
    
On 2/24/14 5:00 PM, Ben Campbell wrote:

    

    

      
+ 1, except as noted:

On Feb 24, 2014, at 2:33 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
Ulrich,

Would you agree to the following to replace the first two statements:

Sequence number is of type Unsigned64.

When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for any occurrence of overload at a reporting node.  This, I think, allows us to ignore wraparound issues as wraparound will never happen.  Unless we are worried about a server staying in overload for billions of years (assuming reports with a ten minute validity period refreshed every five minutes).


      

      
s/ any occurrence of overload / the initial occurrence of an overload condition



      

        
The other two statements are good.

Steve


      

      



    

    

  


--------------010800060404040909090202--


From nobody Tue Feb 25 07:37:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E851A07A2 for ; Tue, 25 Feb 2014 07:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi-2qgJ4ad32 for ; Tue, 25 Feb 2014 07:36:56 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 505021A07A0 for ; Tue, 25 Feb 2014 07:36:49 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1PFak3H020701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 16:36:46 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1PFajFV008288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 16:36:45 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 16:36:45 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 16:36:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Maria Cruz Bartolome , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
Thread-Index: AQHPMisvc6zzBhdNjkKe3lYGjzc2zZrGAadw///zhICAACM0YA==
Date: Tue, 25 Feb 2014 15:36:44 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B478B@DEMUMBX014.nsn-intra.net>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <530CA759.6070302@usdonovans.com>
In-Reply-To: <530CA759.6070302@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B478BDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 24017
X-purgate-ID: 151667::1393342606-00005322-FBC8772F/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5p-0bgVLNfZVE_a3OaQv54Pm200
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 15:37:01 -0000

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

I don't think that it is the presence/absence of destination-host in a requ=
est that determines whether a session is new.


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, February 25, 2014 3:23 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf.org; d=
raft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

I'm not comfortable with this model that assumes that agents have a better =
understanding then servers on the servers ability to handle new sessions.

Are you also saying that RRRs can never be sent if an agent is not in the n=
etwork?

RRRs are a way to control a specific type of request, generally requests th=
at create new sessions, recognizing that those requests are more expensive =
than what we have referred to as mid-session requests.

Yes, agents should be able to create aggregated RRR reports but servers sho=
uld be able to send them as well.

Steve
On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
My understanding is that RRR reports are always aggregated reports. Agents =
generating an RRR report (for use on the DOIC association towards the react=
ing node) take as an input the host-type reports received on the DOIC assoc=
iations with the servers.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, February 25, 2014 2:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

How do agents learn about a set of servers ability to handle new sessions (=
host-less requests) if servers never sent realm-routed-request reports?

I agree that agents should sent to aggregated report but the servers need t=
o send RRR reports so the agent can route around them and generate those ag=
gregated reports.

Steve
On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Hi,
I agree with MCruz.

Principle is that the server never sends OLRs with a report type of realm-r=
outed-request (exept the case where the server knows (i.e.is configured) th=
at there is no other server in that realm).

Only agents that are configured to take the role of a reporting node for a =
realm will insert OLRs with report type of realm-routed-requests into answe=
r messages and the content should be the aggregation of percentages as rece=
ived in host type OLRs from all the servers in the realm.

Ulrich




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-=
dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type

Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of th=
e meaning of realm-routed-request report (new attempt at a name to try to m=
ake Ulrich happy :-) ).

My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions.

Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and appli=
cations that always rely on realm routed requests.

Everyone, which definition applies?

Steve
On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:

Steve,



See some comments below please.

/MCruz



-----Original Message-----

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

Sent: lunes, 24 de febrero de 2014 17:20

To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

Cc: dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type



#57: Handling of "Realm-Routed" Overload report type



 I'm assuming the name of the realm overload report in the -01 version will

 be changed to realm-routed.  This issue applies independent of the actual

 name of the report.



 The current behavior assumed for the realm-routed report is that the

 reacting node, generally the client, will reduce the percentage of realm

 routed requests sent to the reporting node.



 This is actually bad behavior and could result in the client throttling

 traffic that could have been handled by the full set of servers for that

 Diameter application.

[MCruz] This can only happen if the agent has miscalculated the realm overl=
oad.



 Consider the case where there are n servers for a Diameter application and

 all of those server are able to handle any transaction for that

 application.



 When one of those servers becomes overloaded and wishes to decrease the

 number of new sessions, the primary use of realm-routed requests.  The

 server will generate an OLR of type realm-routed.

[MCruz] I do not agree. Servers do not generate Realm-routed reports.



 Assume in this case that the other servers are all healthy and able to

 handle new sessions.



 Clients will not have the knowledge that there are other servers in the

 network able to handle the new session and will have no choice but the

 throttle a percentage of the new session requests.  Even when these

 throttled requests could have been handled by any of the non overloaded

 servers.



 The proposal is to specify that realm-routed reports must be handled by

 DOIC-supporting agents.  Agents will understand if there are other servers

 able to handle the new session and, if so, can adjust the percentage of

 requests routed to the overloaded server.



 Agents that handle the realm-routed OLR must remove the request from the

 answer before relaying the answer to client.  This prevents the report

 from being acted on by either multiple agents (if multiple are in the

 path) or by an agent and a client.



 Clients that receive the realm-routed OLR must handle the OLR by

 throttling the requested percentage.






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











I don̵=
7;t think that it is the presence/absence of destination-host in a request =
that determines whether a session is new.


 =
;


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Tuesday, February 25, 2014 3:23 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf=
.org; draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


I'm not comfortable w=
ith this model that assumes that agents have a better understanding then se=
rvers on the servers ability to handle new sessions.



Are you also saying that RRRs can never be sent if an agent is not in the n=
etwork? 




RRRs are a way to control a specific type of request, generally requests th=
at create new sessions, recognizing that those requests are more expensive =
than what we have referred to as mid-session requests.



Yes, agents should be able to create aggregated RRR reports but servers sho=
uld be able to send them as well.



Steve




On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






My underst=
anding is that RRR reports are always aggregated reports. Agents generating=
 an RRR report (for use on the DOIC association towards the
 reacting node) take as an input the host-type reports received on the DOIC=
 associations with the servers.


 


Ulrich


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, February 25, 2014 2:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; 
dime@ietf.org; =
draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


How do agents learn a=
bout a set of servers ability to handle new sessions (host-less requests) i=
f servers never sent realm-routed-request reports?



I agree that agents should sent to aggregated report but the servers need t=
o send RRR reports so the agent can route around them and generate those ag=
gregated reports.



Steve




On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Hi,=



I agree wi=
th MCruz.


 


Principle =
is that the server never sends OLRs with a report type of realm-routed-requ=
est (exept the case where the server knows (i.e.is configured)
 that there is no other server in that realm).


 


Only agent=
s that are configured to take the role of a reporting node for a realm will=
 insert OLRs with report type of realm-routed-requests into
 answer messages and the content should be the aggregation of percentages a=
s received in host type OLRs from all the servers in the realm.=



 


Ulrich


 


 


 


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, February 24, 2014 8:31 PM

To: Maria Cruz Bartolome; dime@ietf=
.org;
draft-docdt-dime-ov=
li@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed"=
 Overload report type






 


Maria Cruz,



Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to try=
 to make Ulrich happy :-) ).



My definition is that it is a report generated by the server when the serve=
r does not want to receive new sessions. 




Your definition appears to be that it is a report generated by an agent (or=
 a server is there are no agents in the network?) to indicate that the netw=
ork need to handle fewer new sessions.



I actually think both cases apply but I don't think that an agent can gener=
ate a realm-routed-request report without knowing the status of servers and=
 their ability to handle new Diameter sessions.



Note that I'm discussing this in the context of session-based applications.=
  This could also be applied to pseudo session based applications and =
applications that always rely on realm routed requests.



Everyone, which definition applies?



Steve




On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:






Steve,


 


See some comments below please.


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of dime issue tracker


Sent: lunes, 24 de febrero de 2014 17:20


To: draft-docd=
t-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com


Cc: dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overl=
oad report type


 


#57: Handling of "Realm-Routed" Overload report type


 


 I'm assuming the name of the realm overload report in the -01 version=
 will


 be changed to realm-routed.  This issue applies independent of t=
he actual


 name of the report.


 


 The current behavior assumed for the realm-routed report is that the<=
o:p>


 reacting node, generally the client, will reduce the percentage of re=
alm


 routed requests sent to the reporting node.


 


 This is actually bad behavior and could result in the client throttli=
ng


 traffic that could have been handled by the full set of servers for t=
hat


 Diameter application.


[MCruz] This can only happen if the agent has miscalculated the realm =
overload.


 


 Consider the case where there are n servers for a Diameter applicatio=
n and


 all of those server are able to handle any transaction for that<=
/o:p>


 application.


 


 When one of those servers becomes overloaded and wishes to decrease t=
he


 number of new sessions, the primary use of realm-routed requests.&nbs=
p; The


 server will generate an OLR of type realm-routed.


[MCruz] I do not agree. Servers do not generate Realm-routed reports.<=
o:p>


 


 Assume in this case that the other servers are all healthy and able t=
o


 handle new sessions.


 


 Clients will not have the knowledge that there are other servers in t=
he


 network able to handle the new session and will have no choice but th=
e


 throttle a percentage of the new session requests.  Even when th=
ese


 throttled requests could have been handled by any of the non overload=
ed


 servers.


 


 The proposal is to specify that realm-routed reports must be handled =
by


 DOIC-supporting agents.  Agents will understand if there are oth=
er servers


 able to handle the new session and, if so, can adjust the percentage =
of


 requests routed to the overloaded server.


 


 Agents that handle the realm-routed OLR must remove the request from =
the


 answer before relaying the answer to client.  This prevents the =
report


 from being acted on by either multiple agents (if multiple are in the=



 path) or by an agent and a client.


 


 Clients that receive the realm-routed OLR must handle the OLR by=



 throttling the requested percentage.


 




 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B478BDEMUMBX014nsnin_--


From nobody Tue Feb 25 07:51:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0EE1A00EE for ; Tue, 25 Feb 2014 07:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhw-UX7sen0j for ; Tue, 25 Feb 2014 07:51:02 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 111DE1A00DF for ; Tue, 25 Feb 2014 07:51:01 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-df-530cbbe41bc1
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AC.4A.23809.4EBBC035; Tue, 25 Feb 2014 16:51:00 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 16:50:59 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
Thread-Index: AQHPMbXQO3WJNz67k0mnyWn61pi1cJrFLMWAgAAFJwCAAOxHsA==
Date: Tue, 25 Feb 2014 15:50:59 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097862C8@ESESSMB101.ericsson.se>
References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com> <530BFE79.5020209@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje6T3TzBBu86pC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrI5E5gLXgtX7Fw+m62B8T1/FyMnh4SAiUT7lkYmCFtM4sK9 9WxdjFwcQgKHGCUePe9ggnAWM0p0zD7CAlLFJmAncen0C6AEB4eIgLLE6V8OIGFhgSyJC486 mUFsEYFsibfH30LZThJ7J89kB7FZBFQlFr+8ATaGV8BX4v+MBqj5uxklNnyfwQqS4BSwl+i8 uwvMZgS66PupNWDXMQuIS9x6Mh/qUgGJJXvOM0PYohIvH/9jhbCVJBqXPGGFqNeRWLD7ExuE rS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAwD+45bfq DsY750QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbF6v+BR/SNsZvy5 Bzp1otZusLXw3Lxy+gu2azOPCM6frW8fUL5F22EK+5XODZG6c64JL/hwOqj3itXKqoq6jQ38 ge4zc3bZJM/2Yo7wEzqnVq25fMqczYwf/mZMvxPnoGB77cekylPeNlcCNGKbrfhijzs9VXq7 YHX3Tz7dzW7ptVP9xb7WuSuxFGckGmoxFxUnAgCyYLiqSgIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OFvFnp_Z42Uexx0qG7GXlO-2YHo
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 15:51:04 -0000

Steve, Ben, all,

In my opinion, I think DIAMETER_TOO_BUSY is closer to our purpose.
I find a similarity between a single server getting overloaded (request is =
routed using specific server, not a realm) and returning back TOO_BUSY, and=
 a Realm getting overload and returning back TOO_BUSY. The reason is the sa=
me, the expected "destination" (either one specific host, or whole realm) i=
s not able to serve the request.

Regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 25 de febrero de 2014 3:41
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Clie=
nt that does not support DOIC


On Feb 24, 2014, at 8:22 PM, Steve Donovan  wrote=
:

> It looks like DIAMETER-TOO-BUSY fits best for requests throttled because =
of a Realm-Routed-Request (RRR) overload report handled by an agent.

I'm confused. I interpreted 6733 to explicitly forbid DIAMETER_TO_BUSY for =
realm routed requests:=20

"This error MUST only be used when a specific server is requested..."

What am I missing? (Yes, I recognize "... when a specific server is request=
ed..." is vague.)


>=20
> The only other option I see for agent handling of host overload reports i=
s DIAMETER_UNABLE_TO_COMPLY. =20
>    DIAMETER_UNABLE_TO_COMPLY 5012
>       This error is returned when a request is rejected for unspecified
>       reasons.
>=20
> This is the behavior definition:
> If the service cannot be
>    provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
>    message MUST be sent within the accounting request; a Diameter client
>    receiving an authorization response for a service that it cannot
>    perform MUST NOT substitute an alternate service and then send
>    accounting requests for the alternate service instead.
>=20
> Or we could use DIAMETER_UNABLE_TO_DELIVER  DIAMETER_UNABLE_TO_DELIVER=20
> 3002
>=20
>       This error is given when Diameter cannot deliver the message to
>       the destination, either because no host within the realm
>       supporting the required application was available to process the
>       request or because the Destination-Host AVP was given without the
>       associated Destination-Realm AVP.

This seems closer to the right semantics for RRRs.

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


From nobody Tue Feb 25 08:02:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946351A0744 for ; Tue, 25 Feb 2014 08:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Mj68QNkCZP for ; Tue, 25 Feb 2014 08:02:30 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8937E1A07A2 for ; Tue, 25 Feb 2014 08:02:27 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-7a-530cbe91f1a7
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1A.F3.10875.19EBC035; Tue, 25 Feb 2014 17:02:25 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 17:02:25 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue #23 Proposed resolution
Thread-Index: AQHPMYgSECydxGIpskK7qjdEofxvM5rExTAw///3QwCAAO+3EP//9GuAgAAVbaCAAC9lAIAAEeIAgAAGMQCAACQZ8A==
Date: Tue, 25 Feb 2014 16:02:24 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097862DC@ESESSMB101.ericsson.se>
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784EF9@ESESSMB101.ericsson.se> <530C990E.4040301@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4761@DEMUMBX014.nsn-intra.net> <530CAD40.8050505@usdonovans.com>
In-Reply-To: <530CAD40.8050505@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097862DCESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje7EfTzBBl+6LS3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqT579kL3r1grNh/eQFbA+P7k4xdjJwcEgImEp23r7FA2GIS F+6tZwOxhQQOMUos/p3cxcgFZC9mlLiy/BwrSIJNwE7i0ukXTF2MHBwiAsoSp385gJjCAoYS 3z8IglSICBhJNHyZDVWRJdHRDxZmEVCV2DbvGdgQXgFfibs7JjNBTP/ILDF1yVQ2kHpOAT2J ecvrQWoYga75fmoNE4jNLCAucevJfCaIKwUkluw5zwxhi0q8fPyPFcJWkmhc8oQVoj5f4vvP bYwQuwQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGy 5yZm5qSXG25iBEbJwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOM TBycUg2M3XIzjkqka7vvu/5O+FuEgt3Xm8rvl/Lr8coWdz4N+BGUULekb8G12c8Ua4rfbbZK uBgwu/jTIqOndUrJb+6w5fnxBF1NlBZ7LnAvMb3t+d7Ak+6iHwIvG9y5a/Zyb/sFxtenwo4J mu9TT+9t4bwS2Hzayqnr370jxUu1lhpeWvdd8t2yH4ZPlViKMxINtZiLihMBM8oHjGACAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/f5wSp5WpIC_EBFMI_VKVlEMQ0BI
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 16:02:36 -0000

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

Hello,

I agree to what is being stated by Ulrich here.

Realm aggregated report is calculated by an agent, based on individual serv=
er host-reports. Then, it is up to each application to determine, based on =
requested traffic reduction, whether it is convenient or not to start new s=
essions. This is application dependent, since load/resources required by a =
session compared to mid session traffic is application dependent. A part fr=
om that, it could be up to some other criteria, like e.g. whether or not mi=
d session traffic should be prioritized against new session creations, what=
 would depend eventually on each application.

Regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 25 de febrero de 2014 15:49
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Ulrich,

Please see inline.

Steve
On 2/25/14 8:26 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

see inline

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 25, 2014 2:22 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

I believe the other issue then is whether servers generate RRR reports.

Consider the most basic case where there are no agents.

 C1--\
 C2-------S
 C3--/

Is it not appropriate for a server, in this case, to be able to send RRRs?
no
SRD> Then we have a bigger disconnect then I thought.  I'm pretty sure that=
 we had discussed the ability of a server to use what we are now calling RR=
Rs to be able to indicate that it does not want to take on new sessions.  H=
ost reports are used to control the mid-session traffic (for session based =
applications like those used in the 3GPP PCC architecture).

SRD> I would also assert that PCC is a case where there is a strong need fo=
r the server to be able to say that it wants to reduce the number of new se=
ssion taken on so that the DRA in that architecture can properly route sess=
ions that generate new bindings.

SRD> So, to summarize, I believe that we DO have a requirement to allow the=
 server to send RRRs.

SRD> Maybe we need two types of RRRs, one that applies to a single server a=
nd one that applies to the full realm.  Yes Ben, these do start to sound li=
ke scopes :-) but this can also be addressed by either creating separate re=
port types or qualifying the RRR report.


In an agent case, the server sending the RRR gives the agent the ability to=
 generate an aggregated RRR the covers all servers for the application.
the agent should aggregate received host-type reports and convert i=
t into an RRR report
SRD> This is what an agent would do to generate the proposed new "realm" re=
port.  I'm skeptical that an agent can make reasonable decisions about what=
 RRR report to generate based on host reports received.

  So I guess, there would be a DOIC association between the client and the =
agent use to transport the aggregated RRR
yes
and a DOIC associate between the agent and the server used to transport the=
 server specific RRR
server specific host-type report
.

Steve
On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:
Fine to agree

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: martes, 25 de febrero de 2014 10:16
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue #23 Proposed resolution

Steve, MCruz,

lets go step by step.


I'm ok to conclude on #23 to do the renaming from "realm report type" to "r=
ealm-routed-request report type" and clarify that it applies to destination=
-host-less traffic.


Whether or not to introduce a 3rd report type of "realm" is out of scope of=
 #23 and subject of #55.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Tuesday, February 25, 2014 10:05 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Steve,

The discussion started around some proposed use cases by Ulrich, and to my =
knowledge that discussion is not concluded.
Then we have not agreed (at least yet) on having a differentiation between =
realm and realm-routed.
Even more, as far as I understand the proposal it is related to the ability=
 (by agent) to select the a server (in a farm, providing service to a realm=
) for new session establishment. This is something we discussed long time a=
go, and at that point in time we tend to agree that it was not required, bu=
t up to different applications to decide based on realm overload.
Enhancements could be done on top of this, but first we need to agree on th=
e basic use cases.

I hope this clarifies
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:40
To: dime@ietf.org
Subject: Re: [Dime] Issue #23 Proposed resolution

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is indicate=
d by the origin-host AVP in the answer message carrying the report.  Can be=
 generated by a server or by an agent acting as a front-end to a group of s=
ervers.

- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated by a =
server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.  =
Can be generated by a server or an agent.  The method for determining the r=
ealm state is out of scope for the DOIC document.

Steve
On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
Hello,

I do not think we have agreed so far on the need to have two different repo=
rts (so called realm-routed and just realm).
Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: dime@ietf.org
Subject: [Dime] Issue #23 Proposed resolution

I propose the following resolution for issue 23:



Proposal - Change the name of realm report.

Proposed name - "Realm-Routed-Request" report.

Proposal - Update all discussion on "Realm-Routed-Request" reports to indic=
ate that they apply only to requests targeted to a realm when there is no d=
estination-host AVP in the request.  Specifically, section 4.6 requires upd=
ating.

There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.

Regards,

Steve


_______________________________________________

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



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











Hello=
, 


=
 


I agr=
ee to what is being stated by Ulrich here.


=
 


Realm=
 aggregated report is calculated by an agent, based on individual server ho=
st-reports. Then, it is up to each application to determine, based on reque=
sted traffic reduction, whether it is
 convenient or not to start new sessions. This is application dependent, si=
nce load/resources required by a session compared to mid session traffic is=
 application dependent. A part from that, it could be up to some other crit=
eria, like e.g. whether or not mid
 session traffic should be prioritized against new session creations, what =
would depend eventually on each application.


=
 


Regar=
ds


/MCru=
z


=
 


=
 






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

Sent: martes, 25 de febrero de 2014 15:49

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Ulrich,



Please see inline.



Steve




On 2/25/14 8:26 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve=
,


 =
;


see i=
nline


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, February 25, 2014 2:22 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


I believe the other i=
ssue then is whether servers generate RRR reports.



Consider the most basic case where there are no agents.



 C1--\

 C2-------S

 C3--/



Is it not appropriate for a server, in this case, to be able to send RRRs?<=
o:p>


<Ulrich>no</Ulrich><=
/b>




SRD> Then we have a bigger disconnect then I thoug=
ht.  I'm pretty sure that we had discussed the ability of a server to =
use what we are now calling RRRs to be able to indicate that it
 does not want to take on new sessions.  Host reports are used to cont=
rol the mid-session traffic (for session based applications like those used=
 in the 3GPP PCC architecture). 




SRD> I would also assert that PCC is a case where there is a strong need=
 for the server to be able to say that it wants to reduce the number of new=
 session taken on so that the DRA in that architecture can properly route s=
essions that generate new bindings.



SRD> So, to summarize, I believe that we DO have a requirement to allow =
the server to send RRRs.



SRD> Maybe we need two types of RRRs, one that applies to a single serve=
r and one that applies to the full realm.  Yes Ben, these do start to =
sound like scopes :-) but this can also be addressed by either creating sep=
arate report types or qualifying the RRR
 report.








In an agent case, the server sending the RRR gives the agent the ability to=
 generate an aggregated RRR the covers all servers for the application.


<Ulrich>the agent should aggregate re=
ceived host-type reports and convert it into an RRR report</Ulrich>


SRD> This is what an agent would do to generate th=
e proposed new "realm" report.  I'm skeptical that an agent =
can make reasonable decisions about what RRR report to generate based on ho=
st
 reports received.






  So I guess, th=
ere would be a DOIC association between the client and the agent use to tra=
nsport the aggregated RRR


<Ulrich>yes</Ulrich>=



and a DOIC associate =
between the agent and the server used to transport the server specific RRR<=
o:p>


<Ulrich>server specific host-type rep=
ort</Ulrich>


.



Steve 




On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:=







Fine =
to agree


 =
;






From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: martes, 25 de febrero de 2014 10:16

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: RE: [Dime] Issue #23 Proposed resolution<=
/p>





 


Steve=
, MCruz,


 =
;


lets =
go step by step.


 =
;


 =
;


IR=
17;m ok to conclude on #23 to do the renaming from “realm report type=
” to “realm-routed-request report type” and clarify that =
it applies to destination-host-less traffic.


 =
;


 =
;


Wheth=
er or not to introduce a 3rd report type of “realm” =
is out of scope of #23 and subject of #55.


 =
;


 =
;


Ulric=
h 


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Tuesday, February 25, 2014 10:05 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Steve=
,


 =
;


The d=
iscussion started around some proposed use cases by Ulrich, and to my knowl=
edge that discussion is not concluded.


Then =
we have not agreed (at least yet) on having a differentiation between realm=
 and realm-routed.



Even =
more, as far as I understand the proposal it is related to the ability (by =
agent) to select the a server (in a farm, providing service to a realm) for=
 new session establishment. This is
 something we discussed long time ago, and at that point in time we tend to=
 agree that it was not required, but up to different applications to decide=
 based on realm overload.


Enhan=
cements could be done on top of this, but first we need to agree on the bas=
ic use cases.


 =
;


I hop=
e this clarifies


Cheer=
s


/MCru=
z


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:40

To: dime@ietf.org

Subject: Re: [Dime] Issue #23 Proposed resolution<=
/p>





 


Maria Cruz,



I thought you had asserted that there was a 3GPP requirement to have the ab=
ility to have a realm report that control the total amount of traffic sent =
to a realm.  There is certainly an IETF DOC requirement to this effect=
.



The proposal is to have three report types (or four depending on the resolu=
tion of the per client host report discussion).



- Host report - Apply to all requests sent to a host.  The host is ind=
icated by the origin-host AVP in the answer message carrying the report.&nb=
sp; Can be generated by a server or by an agent acting as a front-end to a =
group of servers.



- Realm-routed-request report - Applies to all requests sent to a realm wit=
hout a destination-host AVP in the request message.  Can be generated =
by a server or by an agent acting as a front-end to a group of servers.



- Realm report - Applies to all requests sent to the realm, independent of =
the presence or absence of a destination-host AVP in the request message.&n=
bsp; Can be generated by a server or an agent.  The method for determi=
ning the realm state is out of scope for the
 DOIC document.



Steve




On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:=







Hello=
,


 =
;


I do =
not think we have agreed so far on the need to have two different reports (=
so called realm-routed and just realm).


Regar=
ds


/MCru=
z


 =
;






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 18:44

To: dime@ietf.org

Subject: [Dime] Issue #23 Proposed resolution






 


I propose the followi=
ng resolution for issue 23:










Proposal – Change the name of realm report.  




Proposed name - “Realm-Routed-Request” report.




Proposal – Update all discussion on “Realm-Routed-Request”=
; reports to indicate that they apply only to requests targeted to a realm =
when there is no destination-host AVP in the request.  Specifically, s=
ection 4.6 requires updating.



There is also a proposal to add a new report type to handle all transaction=
s to a realm.  This is addressed by ticket number 55.



Regards,



Steve 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


 






--_000_087A34937E64E74E848732CFF8354B92097862DCESESSMB101erics_--


From nobody Tue Feb 25 08:21:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4571A016F for ; Tue, 25 Feb 2014 08:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTYW5dIrr_RW for ; Tue, 25 Feb 2014 08:21:15 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DE64B1A0183 for ; Tue, 25 Feb 2014 08:21:10 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1PGL70q004920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 17:21:07 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1PGL6gf009339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 17:21:06 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 17:21:05 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 17:21:05 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Issue#32 status
Thread-Index: Ac8tiAGtvQe9mwQAS968RUS8ackr7wEDzhQAAAUk0YAAIZgPgAAD5hfw
Date: Tue, 25 Feb 2014 16:21:05 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com>  <530CB073.7000802@usdonovans.com>
In-Reply-To: <530CB073.7000802@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1864
X-purgate-ID: 151667::1393345268-00005322-2949269B/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zb52c2LmTdP-zsnh_ZXsTn9rL2E
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 16:21:16 -0000

Steve, Ben,

for my clarification, your proposal is to say

***
Sequence number is of type Unsigned64.

When generated, a new sequence number must be greater than the sequence num=
ber contained in the active overload report to which it applies (including =
over reboot of that node).  Note: this allows sequence numbers to start at =
1 for the initial occurrence of an overload condition at a reporting node.
***

If so, what is meant by "initial occurrence of an overload condition"?

I guess it means something like moving from no overload to overload after a=
 sufficiently long periode of no overload

Please clarify

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 25, 2014 4:02 PM
To: Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#32 status

I agree with the suggested change.

Steve
On 2/24/14 5:00 PM, Ben Campbell wrote:
+ 1, except as noted:

On Feb 24, 2014, at 2:33 PM, Steve Donovan  wrote=
:

Ulrich,

Would you agree to the following to replace the first two statements:

Sequence number is of type Unsigned64.

When generated, a new sequence number must be greater than the sequence num=
ber contained in the active overload report to which it applies (including =
over reboot of that node).  Note: this allows sequence numbers to start at =
1 for any occurrence of overload at a reporting node.  This, I think, allow=
s us to ignore wraparound issues as wraparound will never happen.  Unless w=
e are worried about a server staying in overload for billions of years (ass=
uming reports with a ten minute validity period refreshed every five minute=
s).

s/ any occurrence of overload / the initial occurrence of an overload condi=
tion


The other two statements are good.

Steve




From nobody Tue Feb 25 08:23:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EAC1A07D8 for ; Tue, 25 Feb 2014 08:23:33 -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
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 Fmq4nhmyT2zN for ; Tue, 25 Feb 2014 08:23:30 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id DC43B1A07D1 for ; Tue, 25 Feb 2014 08:23:28 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56147 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIKmv-00049B-KQ; Tue, 25 Feb 2014 08:23:25 -0800
Message-ID: <530CC379.8060402@usdonovans.com>
Date: Tue, 25 Feb 2014 10:23:21 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Maria Cruz Bartolome , "dime@ietf.org" ,  "draft-docdt-dime-ovli@tools.ietf.org" 
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <530CA759.6070302@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B478B@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B478B@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------080103080606040908060608"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sIr_i70m7fMGXCYHXIBX_sitloA
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 16:23:33 -0000

This is a multi-part message in MIME format.
--------------080103080606040908060608
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

You of course are correct in the general sense.  There are, however,
many examples where the initial request is sent without the
destination-host and subsequent requests are sent with.

I do admit to over generalizing.  The basic argument is still the same,
there are applications where requests that do not have a
destination-host use that for routing the request that creates the
session on one of a group of servers.  The destination-host is then used
to route subsequent session-associated requests to the correct server. 
The session creating requests represent more work than
session-associated requests and it is thus a valid overload management
strategy to push back on those before pushing back on session-associated
requests.

Steve

On 2/25/14 9:36 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> I don't think that it is the presence/absence of destination-host in a
> request that determines whether a session is new.
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Tuesday, February 25, 2014 3:23 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome;
> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
> *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload
> report type
>
>  
>
> I'm not comfortable with this model that assumes that agents have a
> better understanding then servers on the servers ability to handle new
> sessions.
>
> Are you also saying that RRRs can never be sent if an agent is not in
> the network? 
>
> RRRs are a way to control a specific type of request, generally
> requests that create new sessions, recognizing that those requests are
> more expensive than what we have referred to as mid-session requests.
>
> Yes, agents should be able to create aggregated RRR reports but
> servers should be able to send them as well.
>
> Steve
>
> On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     My understanding is that RRR reports are always aggregated
>     reports. Agents generating an RRR report (for use on the DOIC
>     association towards the reacting node) take as an input the
>     host-type reports received on the DOIC associations with the servers.
>
>      
>
>     Ulrich
>
>      
>
>     *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Tuesday, February 25, 2014 2:12 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome;
>     dime@ietf.org ;
>     draft-docdt-dime-ovli@tools.ietf.org
>     
>     *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed"
>     Overload report type
>
>      
>
>     How do agents learn about a set of servers ability to handle new
>     sessions (host-less requests) if servers never sent
>     realm-routed-request reports?
>
>     I agree that agents should sent to aggregated report but the
>     servers need to send RRR reports so the agent can route around
>     them and generate those aggregated reports.
>
>     Steve
>
>     On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Hi,
>
>         I agree with MCruz.
>
>          
>
>         Principle is that the server never sends OLRs with a report
>         type of realm-routed-request (exept the case where the server
>         knows (i.e.is configured) that there is no other server in
>         that realm).
>
>          
>
>         Only agents that are configured to take the role of a
>         reporting node for a realm will insert OLRs with report type
>         of realm-routed-requests into answer messages and the content
>         should be the aggregation of percentages as received in host
>         type OLRs from all the servers in the realm.
>
>          
>
>         Ulrich
>
>          
>
>          
>
>          
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>         Steve Donovan
>         *Sent:* Monday, February 24, 2014 8:31 PM
>         *To:* Maria Cruz Bartolome; dime@ietf.org
>         ; draft-docdt-dime-ovli@tools.ietf.org
>         
>         *Subject:* Re: [Dime] [dime] #57: Handling of "Realm-Routed"
>         Overload report type
>
>          
>
>         Maria Cruz,
>
>         Thanks for the comments.  We obviously have a different
>         understanding of the meaning of realm-routed-request report
>         (new attempt at a name to try to make Ulrich happy :-) ).
>
>         My definition is that it is a report generated by the server
>         when the server does not want to receive new sessions. 
>
>         Your definition appears to be that it is a report generated by
>         an agent (or a server is there are no agents in the network?)
>         to indicate that the network need to handle fewer new sessions.
>
>         I actually think both cases apply but I don't think that an
>         agent can generate a realm-routed-request report without
>         knowing the status of servers and their ability to handle new
>         Diameter sessions.
>
>         Note that I'm discussing this in the context of session-based
>         applications.  This could also be applied to pseudo session
>         based applications and applications that always rely on realm
>         routed requests.
>
>         Everyone, which definition applies?
>
>         Steve
>
>         On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>
>             Steve,
>
>              
>
>             See some comments below please.
>
>             /MCruz
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
>
>             Sent: lunes, 24 de febrero de 2014 17:20
>
>             To: draft-docdt-dime-ovli@tools.ietf.org ; srdonovan@usdonovans.com 
>
>             Cc: dime@ietf.org 
>
>             Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>
>              
>
>             #57: Handling of "Realm-Routed" Overload report type
>
>              
>
>              I'm assuming the name of the realm overload report in the -01 version will
>
>              be changed to realm-routed.  This issue applies independent of the actual
>
>              name of the report.
>
>              
>
>              The current behavior assumed for the realm-routed report is that the
>
>              reacting node, generally the client, will reduce the percentage of realm
>
>              routed requests sent to the reporting node.
>
>              
>
>              This is actually bad behavior and could result in the client throttling
>
>              traffic that could have been handled by the full set of servers for that
>
>              Diameter application.
>
>             [MCruz] This can only happen if the agent has miscalculated the realm overload.
>
>              
>
>              Consider the case where there are n servers for a Diameter application and
>
>              all of those server are able to handle any transaction for that
>
>              application.
>
>              
>
>              When one of those servers becomes overloaded and wishes to decrease the
>
>              number of new sessions, the primary use of realm-routed requests.  The
>
>              server will generate an OLR of type realm-routed.
>
>             [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>
>              
>
>              Assume in this case that the other servers are all healthy and able to
>
>              handle new sessions.
>
>              
>
>              Clients will not have the knowledge that there are other servers in the
>
>              network able to handle the new session and will have no choice but the
>
>              throttle a percentage of the new session requests.  Even when these
>
>              throttled requests could have been handled by any of the non overloaded
>
>              servers.
>
>              
>
>              The proposal is to specify that realm-routed reports must be handled by
>
>              DOIC-supporting agents.  Agents will understand if there are other servers
>
>              able to handle the new session and, if so, can adjust the percentage of
>
>              requests routed to the overloaded server.
>
>              
>
>              Agents that handle the realm-routed OLR must remove the request from the
>
>              answer before relaying the answer to client.  This prevents the report
>
>              from being acted on by either multiple agents (if multiple are in the
>
>              path) or by an agent and a client.
>
>              
>
>              Clients that receive the realm-routed OLR must handle the OLR by
>
>              throttling the requested percentage.
>
>              
>
>          
>
>      
>
>  
>


--------------080103080606040908060608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      You of course are correct in the general sense.  There are,
      however, many examples where the initial request is sent without
      the destination-host and subsequent requests are sent with.

      

      I do admit to over generalizing.  The basic argument is still the
      same, there are applications where requests that do not have a
      destination-host use that for routing the request that creates the
      session on one of a group of servers.  The destination-host is
      then used to route subsequent session-associated requests to the
      correct server.  The session creating requests represent more work
      than session-associated requests and it is thus a valid overload
      management strategy to push back on those before pushing back on
      session-associated requests.

      

      Steve

      

    
    
On 2/25/14 9:36 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
I don’t think that it is the presence/absence
            of destination-host in a request that determines whether a
            session is new.

        
 

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Tuesday, February 25, 2014 3:23 PM

                To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz
                Bartolome; dime@ietf.org;
                draft-docdt-dime-ovli@tools.ietf.org

                Subject: Re: [Dime] [dime] #57: Handling of
                "Realm-Routed" Overload report type

          

        

        
 

        
I'm not
          comfortable with this model that assumes that agents have a
          better understanding then servers on the servers ability to
          handle new sessions.

          

          Are you also saying that RRRs can never be sent if an agent is
          not in the network? 
          

          

          RRRs are a way to control a specific type of request,
          generally requests that create new sessions, recognizing that
          those requests are more expensive than what we have referred
          to as mid-session requests.

          

          Yes, agents should be able to create aggregated RRR reports
          but servers should be able to send them as well.

          

          Steve

        

          
On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
My understanding is that RRR reports are
              always aggregated reports. Agents generating an RRR report
              (for use on the DOIC association towards the reacting
              node) take as an input the host-type reports received on
              the DOIC associations with the servers.

          
 

          
Ulrich

          
 

          

            

              
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Sent: Tuesday, February 25, 2014 2:12 PM

                  To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz
                  Bartolome; 
                    dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org

                  Subject: Re: [Dime] [dime] #57: Handling of
                  "Realm-Routed" Overload report type

            

          

          
 

          
How do
            agents learn about a set of servers ability to handle new
            sessions (host-less requests) if servers never sent
            realm-routed-request reports?

            

            I agree that agents should sent to aggregated report but the
            servers need to send RRR reports so the agent can route
            around them and generate those aggregated reports.

            

            Steve

          

            
On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN
              - DE/Munich) wrote:

          

          

            
Hi,

            
I agree with MCruz.

            
 

            
Principle is that the server never sends
                OLRs with a report type of realm-routed-request (exept
                the case where the server knows (i.e.is configured) that
                there is no other server in that realm).

            
 

            
Only agents that are configured to take the
                role of a reporting node for a realm will insert OLRs
                with report type of realm-routed-requests into answer
                messages and the content should be the aggregation of
                percentages as received in host type OLRs from all the
                servers in the realm.

            
 

            
Ulrich

            
 

            
 

            
 

            
 

            

              

                
From: DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of ext Steve Donovan

                    Sent: Monday, February 24, 2014 8:31 PM

                    To: Maria Cruz Bartolome; dime@ietf.org;
                    draft-docdt-dime-ovli@tools.ietf.org

                    Subject: Re: [Dime] [dime] #57: Handling of
                    "Realm-Routed" Overload report type

              

            

            
 

            
Maria
              Cruz,

              

              Thanks for the comments.  We obviously have a different
              understanding of the meaning of realm-routed-request
              report (new attempt at a name to try to make Ulrich happy
              :-) ).

              

              My definition is that it is a report generated by the
              server when the server does not want to receive new
              sessions. 
              

              

              Your definition appears to be that it is a report
              generated by an agent (or a server is there are no agents
              in the network?) to indicate that the network need to
              handle fewer new sessions.

              

              I actually think both cases apply but I don't think that
              an agent can generate a realm-routed-request report
              without knowing the status of servers and their ability to
              handle new Diameter sessions.

              

              Note that I'm discussing this in the context of
              session-based applications.  This could also be applied to
              pseudo session based applications and applications that
              always rely on realm routed requests.

              

              Everyone, which definition applies?

              

              Steve

            

              
On 2/24/14 12:51 PM, Maria Cruz
                Bartolome wrote:

            

            

              
Steve,

              
 

              
See some comments below please.

              
/MCruz

              
 

              
-----Original Message-----

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

              
Sent: lunes, 24 de febrero de 2014 17:20

              
To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

              
Cc: dime@ietf.org

              
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

              
 

              
#57: Handling of "Realm-Routed" Overload report type

              
 

              
 I'm assuming the name of the realm overload report in the -01 version will

              
 be changed to realm-routed.  This issue applies independent of the actual

              
 name of the report.

              
 

              
 The current behavior assumed for the realm-routed report is that the

              
 reacting node, generally the client, will reduce the percentage of realm

              
 routed requests sent to the reporting node.

              
 

              
 This is actually bad behavior and could result in the client throttling

              
 traffic that could have been handled by the full set of servers for that

              
 Diameter application.

              
[MCruz] This can only happen if the agent has miscalculated the realm overload.

              
 

              
 Consider the case where there are n servers for a Diameter application and

              
 all of those server are able to handle any transaction for that

              
 application.

              
 

              
 When one of those servers becomes overloaded and wishes to decrease the

              
 number of new sessions, the primary use of realm-routed requests.  The

              
 server will generate an OLR of type realm-routed.

              
[MCruz] I do not agree. Servers do not generate Realm-routed reports.

              
 

              
 Assume in this case that the other servers are all healthy and able to

              
 handle new sessions.

              
 

              
 Clients will not have the knowledge that there are other servers in the

              
 network able to handle the new session and will have no choice but the

              
 throttle a percentage of the new session requests.  Even when these

              
 throttled requests could have been handled by any of the non overloaded

              
 servers.

              
 

              
 The proposal is to specify that realm-routed reports must be handled by

              
 DOIC-supporting agents.  Agents will understand if there are other servers

              
 able to handle the new session and, if so, can adjust the percentage of

              
 requests routed to the overloaded server.

              
 

              
 Agents that handle the realm-routed OLR must remove the request from the

              
 answer before relaying the answer to client.  This prevents the report

              
 from being acted on by either multiple agents (if multiple are in the

              
 path) or by an agent and a client.

              
 

              
 Clients that receive the realm-routed OLR must handle the OLR by

              
 throttling the requested percentage.

              
 

            

            
 

          

          
 

        

        
 

      

    

    

  


--------------080103080606040908060608--


From nobody Tue Feb 25 10:42:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B046C1A0289 for ; Tue, 25 Feb 2014 10:42:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyJQ3rW4dWtj for ; Tue, 25 Feb 2014 10:42:36 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7AA1A06FA for ; Tue, 25 Feb 2014 10:42:36 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1PIgWbT051798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 12:42:34 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net>
Date: Tue, 25 Feb 2014 12:42:31 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <14D8073A-8630-4499-AF7C-3670D1503E71@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com>  <530CB073.7000802@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Rz8W2Is9kU661M29bxt8uiACQGU
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 18:42:39 -0000

On Feb 25, 2014, at 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Steve, Ben,
>=20
> for my clarification, your proposal is to say
>=20
> ***
> Sequence number is of type Unsigned64.
>=20
> When generated, a new sequence number must be greater than the =
sequence number contained in the active overload report to which it =
applies (including over reboot of that node).  Note: this allows =
sequence numbers to start at 1 for the initial occurrence of an overload =
condition at a reporting node.
> ***
>=20
> If so, what is meant by "initial occurrence of an overload condition"?
>=20
> I guess it means something like moving from no overload to overload =
after a sufficiently long periode of no overload

For the purpose of this discussion, yes.

Thanks!

Ben.=


From nobody Tue Feb 25 10:51:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3E01A00C6 for ; Tue, 25 Feb 2014 10:51:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ2ZD1pX5PT9 for ; Tue, 25 Feb 2014 10:51:42 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAF21A014B for ; Tue, 25 Feb 2014 10:51:41 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1PIpZZ4052111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 12:51:36 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net>
Date: Tue, 25 Feb 2014 12:51:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <59BC706B-A39F-4682-AEAC-AC3808ADECBE@nostrum.com>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kLFqaUKLhaFC5YyDfUO3LoBDU1Y
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 18:51:47 -0000

I think that both models are reasonable deployments. Our definitions of =
HRR and RRR should support both approaches. I say this with the caveat =
that, if a server sends an RRR report, it is claiming authoritative =
knowledge of all servers in the realm.

Agents sending reports to clients can take _any_ input they want to. =
That could be host reports from servers, RRR reports from servers, =
Diameter errors, transport errors, and any number of proprietary =
methods.

On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> My understanding is that RRR reports are always aggregated reports. =
Agents generating an RRR report (for use on the DOIC association towards =
the reacting node) take as an input the host-type reports received on =
the DOIC associations with the servers.
> =20
> Ulrich
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Tuesday, February 25, 2014 2:12 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; =
dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
> =20
> How do agents learn about a set of servers ability to handle new =
sessions (host-less requests) if servers never sent realm-routed-request =
reports?
>=20
> I agree that agents should sent to aggregated report but the servers =
need to send RRR reports so the agent can route around them and generate =
those aggregated reports.
>=20
> Steve
>=20
> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Hi,
> I agree with MCruz.
> =20
> Principle is that the server never sends OLRs with a report type of =
realm-routed-request (exept the case where the server knows (i.e.is =
configured) that there is no other server in that realm).
> =20
> Only agents that are configured to take the role of a reporting node =
for a realm will insert OLRs with report type of realm-routed-requests =
into answer messages and the content should be the aggregation of =
percentages as received in host type OLRs from all the servers in the =
realm.
> =20
> Ulrich
> =20
> =20
> =20
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Monday, February 24, 2014 8:31 PM
> To: Maria Cruz Bartolome; dime@ietf.org; =
draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
> =20
> Maria Cruz,
>=20
> Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to =
try to make Ulrich happy :-) ).
>=20
> My definition is that it is a report generated by the server when the =
server does not want to receive new sessions. =20
>=20
> Your definition appears to be that it is a report generated by an =
agent (or a server is there are no agents in the network?) to indicate =
that the network need to handle fewer new sessions.
>=20
> I actually think both cases apply but I don't think that an agent can =
generate a realm-routed-request report without knowing the status of =
servers and their ability to handle new Diameter sessions.
>=20
> Note that I'm discussing this in the context of session-based =
applications.  This could also be applied to pseudo session based =
applications and applications that always rely on realm routed requests.
>=20
> Everyone, which definition applies?
>=20
> Steve
>=20
> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
> Steve,
> =20
> See some comments below please.
> /MCruz
> =20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue =
tracker
> Sent: lunes, 24 de febrero de 2014 17:20
> To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
> Cc: dime@ietf.org
> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type
> =20
> #57: Handling of "Realm-Routed" Overload report type
> =20
>  I'm assuming the name of the realm overload report in the -01 version =
will
>  be changed to realm-routed.  This issue applies independent of the =
actual
>  name of the report.
> =20
>  The current behavior assumed for the realm-routed report is that the
>  reacting node, generally the client, will reduce the percentage of =
realm
>  routed requests sent to the reporting node.
> =20
>  This is actually bad behavior and could result in the client =
throttling
>  traffic that could have been handled by the full set of servers for =
that
>  Diameter application.
> [MCruz] This can only happen if the agent has miscalculated the realm =
overload.
> =20
>  Consider the case where there are n servers for a Diameter =
application and
>  all of those server are able to handle any transaction for that
>  application.
> =20
>  When one of those servers becomes overloaded and wishes to decrease =
the
>  number of new sessions, the primary use of realm-routed requests.  =
The
>  server will generate an OLR of type realm-routed.
> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
> =20
>  Assume in this case that the other servers are all healthy and able =
to
>  handle new sessions.
> =20
>  Clients will not have the knowledge that there are other servers in =
the
>  network able to handle the new session and will have no choice but =
the
>  throttle a percentage of the new session requests.  Even when these
>  throttled requests could have been handled by any of the non =
overloaded
>  servers.
> =20
>  The proposal is to specify that realm-routed reports must be handled =
by
>  DOIC-supporting agents.  Agents will understand if there are other =
servers
>  able to handle the new session and, if so, can adjust the percentage =
of
>  requests routed to the overloaded server.
> =20
>  Agents that handle the realm-routed OLR must remove the request from =
the
>  answer before relaying the answer to client.  This prevents the =
report
>  from being acted on by either multiple agents (if multiple are in the
>  path) or by an agent and a client.
> =20
>  Clients that receive the realm-routed OLR must handle the OLR by
>  throttling the requested percentage.
> =20
> =20
> =20


From nobody Tue Feb 25 10:56:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456001A00C6 for ; Tue, 25 Feb 2014 10:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPYP1ZRteHBS for ; Tue, 25 Feb 2014 10:56:05 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCB81A0164 for ; Tue, 25 Feb 2014 10:56:05 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1PItxlD052289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 12:56:01 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B478B@DEMUMBX014.nsn-intra.net>
Date: Tue, 25 Feb 2014 12:55:59 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AE856A4-9476-49D3-BD8B-D8EF061CB5E1@nostrum.com>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <530CA759.6070302@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B478B@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bvMDMkOVA3bbpDwDGcYzp_-CYiA
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 18:56:10 -0000

On Feb 25, 2014, at 9:36 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> I don=92t think that it is the presence/absence of destination-host in =
a request that determines whether a session is new.

That's absolutely true. But that presence or absence _does_ effect =
request routing, and by extension, the set of requests that become =
candidates for overload abatement.

But I agree that the absence destination-host is a poor proxy for =
determining whether a request will create a session. That's application =
(and deployment) specific. Our definitions of host and RRR reports =
should be application independent.

> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Tuesday, February 25, 2014 3:23 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; =
dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
> =20
> I'm not comfortable with this model that assumes that agents have a =
better understanding then servers on the servers ability to handle new =
sessions.
>=20
> Are you also saying that RRRs can never be sent if an agent is not in =
the network? =20
>=20
> RRRs are a way to control a specific type of request, generally =
requests that create new sessions, recognizing that those requests are =
more expensive than what we have referred to as mid-session requests.
>=20
> Yes, agents should be able to create aggregated RRR reports but =
servers should be able to send them as well.
>=20
> Steve
>=20
> On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> My understanding is that RRR reports are always aggregated reports. =
Agents generating an RRR report (for use on the DOIC association towards =
the reacting node) take as an input the host-type reports received on =
the DOIC associations with the servers.
> =20
> Ulrich
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Tuesday, February 25, 2014 2:12 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; =
dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
> =20
> How do agents learn about a set of servers ability to handle new =
sessions (host-less requests) if servers never sent realm-routed-request =
reports?
>=20
> I agree that agents should sent to aggregated report but the servers =
need to send RRR reports so the agent can route around them and generate =
those aggregated reports.
>=20
> Steve
>=20
> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Hi,
> I agree with MCruz.
> =20
> Principle is that the server never sends OLRs with a report type of =
realm-routed-request (exept the case where the server knows (i.e.is =
configured) that there is no other server in that realm).
> =20
> Only agents that are configured to take the role of a reporting node =
for a realm will insert OLRs with report type of realm-routed-requests =
into answer messages and the content should be the aggregation of =
percentages as received in host type OLRs from all the servers in the =
realm.
> =20
> Ulrich
> =20
> =20
> =20
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Monday, February 24, 2014 8:31 PM
> To: Maria Cruz Bartolome; dime@ietf.org; =
draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
> =20
> Maria Cruz,
>=20
> Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to =
try to make Ulrich happy :-) ).
>=20
> My definition is that it is a report generated by the server when the =
server does not want to receive new sessions. =20
>=20
> Your definition appears to be that it is a report generated by an =
agent (or a server is there are no agents in the network?) to indicate =
that the network need to handle fewer new sessions.
>=20
> I actually think both cases apply but I don't think that an agent can =
generate a realm-routed-request report without knowing the status of =
servers and their ability to handle new Diameter sessions.
>=20
> Note that I'm discussing this in the context of session-based =
applications.  This could also be applied to pseudo session based =
applications and applications that always rely on realm routed requests.
>=20
> Everyone, which definition applies?
>=20
> Steve
>=20
> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
> Steve,
> =20
> See some comments below please.
> /MCruz
> =20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue =
tracker
> Sent: lunes, 24 de febrero de 2014 17:20
> To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
> Cc: dime@ietf.org
> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report =
type
> =20
> #57: Handling of "Realm-Routed" Overload report type
> =20
>  I'm assuming the name of the realm overload report in the -01 version =
will
>  be changed to realm-routed.  This issue applies independent of the =
actual
>  name of the report.
> =20
>  The current behavior assumed for the realm-routed report is that the
>  reacting node, generally the client, will reduce the percentage of =
realm
>  routed requests sent to the reporting node.
> =20
>  This is actually bad behavior and could result in the client =
throttling
>  traffic that could have been handled by the full set of servers for =
that
>  Diameter application.
> [MCruz] This can only happen if the agent has miscalculated the realm =
overload.
> =20
>  Consider the case where there are n servers for a Diameter =
application and
>  all of those server are able to handle any transaction for that
>  application.
> =20
>  When one of those servers becomes overloaded and wishes to decrease =
the
>  number of new sessions, the primary use of realm-routed requests.  =
The
>  server will generate an OLR of type realm-routed.
> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
> =20
>  Assume in this case that the other servers are all healthy and able =
to
>  handle new sessions.
> =20
>  Clients will not have the knowledge that there are other servers in =
the
>  network able to handle the new session and will have no choice but =
the
>  throttle a percentage of the new session requests.  Even when these
>  throttled requests could have been handled by any of the non =
overloaded
>  servers.
> =20
>  The proposal is to specify that realm-routed reports must be handled =
by
>  DOIC-supporting agents.  Agents will understand if there are other =
servers
>  able to handle the new session and, if so, can adjust the percentage =
of
>  requests routed to the overloaded server.
> =20
>  Agents that handle the realm-routed OLR must remove the request from =
the
>  answer before relaying the answer to client.  This prevents the =
report
>  from being acted on by either multiple agents (if multiple are in the
>  path) or by an agent and a client.
> =20
>  Clients that receive the realm-routed OLR must handle the OLR by
>  throttling the requested percentage.
> =20
> =20
> =20
> =20


From nobody Tue Feb 25 11:01:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8694D1A01DB for ; Tue, 25 Feb 2014 11:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIZ8rPPHcpb7 for ; Tue, 25 Feb 2014 11:01:00 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 781101A01A7 for ; Tue, 25 Feb 2014 11:01:00 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1PJ0r4l052478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 13:00:54 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530CC379.8060402@usdonovans.com>
Date: Tue, 25 Feb 2014 13:00:52 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <857981A3-5E79-4E15-8BD3-2094F29372D7@nostrum.com>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <530CA759.6070302@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B478B@DEMUMBX014.nsn-intra.net> <530CC379.8060402@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vximPb3ZyOelTapmbgim9l9FTok
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 19:01:06 -0000

On Feb 25, 2014, at 10:23 AM, Steve Donovan  =
wrote:

> Ulrich,
>=20
> You of course are correct in the general sense.  There are, however, =
many examples where the initial request is sent without the =
destination-host and subsequent requests are sent with.

I don't think you can depend on that. Diameter allows you to insert a =
Destination-Host avp anytime you think a request needs to be handled by =
a particular server. Unless an application forbids it, that means any =
given implementation/deployment could decide to put a Destination-Host =
in an "initial" request. If doing that breaks treatment of the report =
types, then we need to normatively forbid it, or adjust around the =
possibility.

>=20
> I do admit to over generalizing.  The basic argument is still the =
same, there are applications where requests that do not have a =
destination-host use that for routing the request that creates the =
session on one of a group of servers.  The destination-host is then used =
to route subsequent session-associated requests to the correct server.  =
The session creating requests represent more work than =
session-associated requests and it is thus a valid overload management =
strategy to push back on those before pushing back on session-associated =
requests.
>=20

I think that, if we want to be able to request downstream nodes to =
reduce new session requests, but not reduce mid-session requests, we =
need to explicitly indicate that, and not try to infer that from =
realm-routing vs host-routing Explicit indication could take the form of =
a new report type, or some markup in an existing report type.

> Steve
>=20
> On 2/25/14 9:36 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> I don=92t think that it is the presence/absence of destination-host =
in a request that determines whether a session is new.
>> =20
>> =20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> Sent: Tuesday, February 25, 2014 3:23 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; =
dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>> =20
>> I'm not comfortable with this model that assumes that agents have a =
better understanding then servers on the servers ability to handle new =
sessions.
>>=20
>> Are you also saying that RRRs can never be sent if an agent is not in =
the network? =20
>>=20
>> RRRs are a way to control a specific type of request, generally =
requests that create new sessions, recognizing that those requests are =
more expensive than what we have referred to as mid-session requests.
>>=20
>> Yes, agents should be able to create aggregated RRR reports but =
servers should be able to send them as well.
>>=20
>> Steve
>>=20
>> On 2/25/14 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> My understanding is that RRR reports are always aggregated reports. =
Agents generating an RRR report (for use on the DOIC association towards =
the reacting node) take as an input the host-type reports received on =
the DOIC associations with the servers.
>> =20
>> Ulrich
>> =20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> Sent: Tuesday, February 25, 2014 2:12 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; =
dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>> =20
>> How do agents learn about a set of servers ability to handle new =
sessions (host-less requests) if servers never sent realm-routed-request =
reports?
>>=20
>> I agree that agents should sent to aggregated report but the servers =
need to send RRR reports so the agent can route around them and generate =
those aggregated reports.
>>=20
>> Steve
>>=20
>> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Hi,
>> I agree with MCruz.
>> =20
>> Principle is that the server never sends OLRs with a report type of =
realm-routed-request (exept the case where the server knows (i.e.is =
configured) that there is no other server in that realm).
>> =20
>> Only agents that are configured to take the role of a reporting node =
for a realm will insert OLRs with report type of realm-routed-requests =
into answer messages and the content should be the aggregation of =
percentages as received in host type OLRs from all the servers in the =
realm.
>> =20
>> Ulrich
>> =20
>> =20
>> =20
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>> Sent: Monday, February 24, 2014 8:31 PM
>> To: Maria Cruz Bartolome; dime@ietf.org; =
draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>> =20
>> Maria Cruz,
>>=20
>> Thanks for the comments.  We obviously have a different understanding =
of the meaning of realm-routed-request report (new attempt at a name to =
try to make Ulrich happy :-) ).
>>=20
>> My definition is that it is a report generated by the server when the =
server does not want to receive new sessions. =20
>>=20
>> Your definition appears to be that it is a report generated by an =
agent (or a server is there are no agents in the network?) to indicate =
that the network need to handle fewer new sessions.
>>=20
>> I actually think both cases apply but I don't think that an agent can =
generate a realm-routed-request report without knowing the status of =
servers and their ability to handle new Diameter sessions.
>>=20
>> Note that I'm discussing this in the context of session-based =
applications.  This could also be applied to pseudo session based =
applications and applications that always rely on realm routed requests.
>>=20
>> Everyone, which definition applies?
>>=20
>> Steve
>>=20
>> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>> Steve,
>> =20
>> See some comments below please.
>> /MCruz
>> =20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue =
tracker
>> Sent: lunes, 24 de febrero de 2014 17:20
>> To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
>> Cc: dime@ietf.org
>> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>> =20
>> #57: Handling of "Realm-Routed" Overload report type
>> =20
>>  I'm assuming the name of the realm overload report in the -01 =
version will
>>  be changed to realm-routed.  This issue applies independent of the =
actual
>>  name of the report.
>> =20
>>  The current behavior assumed for the realm-routed report is that the
>>  reacting node, generally the client, will reduce the percentage of =
realm
>>  routed requests sent to the reporting node.
>> =20
>>  This is actually bad behavior and could result in the client =
throttling
>>  traffic that could have been handled by the full set of servers for =
that
>>  Diameter application.
>> [MCruz] This can only happen if the agent has miscalculated the realm =
overload.
>> =20
>>  Consider the case where there are n servers for a Diameter =
application and
>>  all of those server are able to handle any transaction for that
>>  application.
>> =20
>>  When one of those servers becomes overloaded and wishes to decrease =
the
>>  number of new sessions, the primary use of realm-routed requests.  =
The
>>  server will generate an OLR of type realm-routed.
>> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>> =20
>>  Assume in this case that the other servers are all healthy and able =
to
>>  handle new sessions.
>> =20
>>  Clients will not have the knowledge that there are other servers in =
the
>>  network able to handle the new session and will have no choice but =
the
>>  throttle a percentage of the new session requests.  Even when these
>>  throttled requests could have been handled by any of the non =
overloaded
>>  servers.
>> =20
>>  The proposal is to specify that realm-routed reports must be handled =
by
>>  DOIC-supporting agents.  Agents will understand if there are other =
servers
>>  able to handle the new session and, if so, can adjust the percentage =
of
>>  requests routed to the overloaded server.
>> =20
>>  Agents that handle the realm-routed OLR must remove the request from =
the
>>  answer before relaying the answer to client.  This prevents the =
report
>>  from being acted on by either multiple agents (if multiple are in =
the
>>  path) or by an agent and a client.
>> =20
>>  Clients that receive the realm-routed OLR must handle the OLR by
>>  throttling the requested percentage.
>> =20
>> =20
>> =20
>> =20
>=20
>=20


From nobody Tue Feb 25 11:03:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90561A01DF for ; Tue, 25 Feb 2014 11:03:53 -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
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 dgXccI5noH8t for ; Tue, 25 Feb 2014 11:03:47 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4191A01D3 for ; Tue, 25 Feb 2014 11:03:47 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56425 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WINI6-0004Jy-BT; Tue, 25 Feb 2014 11:03:45 -0800
Message-ID: <530CE90E.9060605@usdonovans.com>
Date: Tue, 25 Feb 2014 13:03:42 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ben Campbell ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <59BC706B-A39F-4682-AEAC-AC3808ADECBE@nostrum.com>
In-Reply-To: <59BC706B-A39F-4682-AEAC-AC3808ADECBE@nostrum.com>
Content-Type: multipart/alternative; boundary="------------060809070002050200060103"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KeXE0axefpHrr4kWNY_eKP_PDr0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 19:03:54 -0000

This is a multi-part message in MIME format.
--------------060809070002050200060103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ben,

I'm asserting that there are valid use cases (3GPP PCC for one) for a
server sending a RRR that only impacts realm routed requests being sent
to that server.  This is different than a RRR that reports on all realm
routed requests sent to any server in the realm.

Steve


On 2/25/14 12:51 PM, Ben Campbell wrote:
> I think that both models are reasonable deployments. Our definitions of HRR and RRR should support both approaches. I say this with the caveat that, if a server sends an RRR report, it is claiming authoritative knowledge of all servers in the realm.
>
> Agents sending reports to clients can take _any_ input they want to. That could be host reports from servers, RRR reports from servers, Diameter errors, transport errors, and any number of proprietary methods.
>
> On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>
>> My understanding is that RRR reports are always aggregated reports. Agents generating an RRR report (for use on the DOIC association towards the reacting node) take as an input the host-type reports received on the DOIC associations with the servers.
>>  
>> Ulrich
>>  
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
>> Sent: Tuesday, February 25, 2014 2:12 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>>  
>> How do agents learn about a set of servers ability to handle new sessions (host-less requests) if servers never sent realm-routed-request reports?
>>
>> I agree that agents should sent to aggregated report but the servers need to send RRR reports so the agent can route around them and generate those aggregated reports.
>>
>> Steve
>>
>> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Hi,
>> I agree with MCruz.
>>  
>> Principle is that the server never sends OLRs with a report type of realm-routed-request (exept the case where the server knows (i.e.is configured) that there is no other server in that realm).
>>  
>> Only agents that are configured to take the role of a reporting node for a realm will insert OLRs with report type of realm-routed-requests into answer messages and the content should be the aggregation of percentages as received in host type OLRs from all the servers in the realm.
>>  
>> Ulrich
>>  
>>  
>>  
>>  
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Monday, February 24, 2014 8:31 PM
>> To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>>  
>> Maria Cruz,
>>
>> Thanks for the comments.  We obviously have a different understanding of the meaning of realm-routed-request report (new attempt at a name to try to make Ulrich happy :-) ).
>>
>> My definition is that it is a report generated by the server when the server does not want to receive new sessions.  
>>
>> Your definition appears to be that it is a report generated by an agent (or a server is there are no agents in the network?) to indicate that the network need to handle fewer new sessions.
>>
>> I actually think both cases apply but I don't think that an agent can generate a realm-routed-request report without knowing the status of servers and their ability to handle new Diameter sessions.
>>
>> Note that I'm discussing this in the context of session-based applications.  This could also be applied to pseudo session based applications and applications that always rely on realm routed requests.
>>
>> Everyone, which definition applies?
>>
>> Steve
>>
>> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>> Steve,
>>  
>> See some comments below please.
>> /MCruz
>>  
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
>> Sent: lunes, 24 de febrero de 2014 17:20
>> To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
>> Cc: dime@ietf.org
>> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>>  
>> #57: Handling of "Realm-Routed" Overload report type
>>  
>>  I'm assuming the name of the realm overload report in the -01 version will
>>  be changed to realm-routed.  This issue applies independent of the actual
>>  name of the report.
>>  
>>  The current behavior assumed for the realm-routed report is that the
>>  reacting node, generally the client, will reduce the percentage of realm
>>  routed requests sent to the reporting node.
>>  
>>  This is actually bad behavior and could result in the client throttling
>>  traffic that could have been handled by the full set of servers for that
>>  Diameter application.
>> [MCruz] This can only happen if the agent has miscalculated the realm overload.
>>  
>>  Consider the case where there are n servers for a Diameter application and
>>  all of those server are able to handle any transaction for that
>>  application.
>>  
>>  When one of those servers becomes overloaded and wishes to decrease the
>>  number of new sessions, the primary use of realm-routed requests.  The
>>  server will generate an OLR of type realm-routed.
>> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>>  
>>  Assume in this case that the other servers are all healthy and able to
>>  handle new sessions.
>>  
>>  Clients will not have the knowledge that there are other servers in the
>>  network able to handle the new session and will have no choice but the
>>  throttle a percentage of the new session requests.  Even when these
>>  throttled requests could have been handled by any of the non overloaded
>>  servers.
>>  
>>  The proposal is to specify that realm-routed reports must be handled by
>>  DOIC-supporting agents.  Agents will understand if there are other servers
>>  able to handle the new session and, if so, can adjust the percentage of
>>  requests routed to the overloaded server.
>>  
>>  Agents that handle the realm-routed OLR must remove the request from the
>>  answer before relaying the answer to client.  This prevents the report
>>  from being acted on by either multiple agents (if multiple are in the
>>  path) or by an agent and a client.
>>  
>>  Clients that receive the realm-routed OLR must handle the OLR by
>>  throttling the requested percentage.
>>  
>>  
>>  
>


--------------060809070002050200060103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ben,

      

      I'm asserting that there are valid use cases (3GPP PCC for one)
      for a server sending a RRR that only impacts realm routed requests
      being sent to that server.  This is different than a RRR that
      reports on all realm routed requests sent to any server in the
      realm.

      

      Steve

      

      

    
    
On 2/25/14 12:51 PM, Ben Campbell
      wrote:

    

    

      
I think that both models are reasonable deployments. Our definitions of HRR and RRR should support both approaches. I say this with the caveat that, if a server sends an RRR report, it is claiming authoritative knowledge of all servers in the realm.

Agents sending reports to clients can take _any_ input they want to. That could be host reports from servers, RRR reports from servers, Diameter errors, transport errors, and any number of proprietary methods.

On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:



      

        
My understanding is that RRR reports are always aggregated reports. Agents generating an RRR report (for use on the DOIC association towards the reacting node) take as an input the host-type reports received on the DOIC associations with the servers.
 
Ulrich
 
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: Tuesday, February 25, 2014 2:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
 
How do agents learn about a set of servers ability to handle new sessions (host-less requests) if servers never sent realm-routed-request reports?

I agree that agents should sent to aggregated report but the servers need to send RRR reports so the agent can route around them and generate those aggregated reports.

Steve

On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Hi,
I agree with MCruz.
 
Principle is that the server never sends OLRs with a report type of realm-routed-request (exept the case where the server knows (i.e.is configured) that there is no other server in that realm).
 
Only agents that are configured to take the role of a reporting node for a realm will insert OLRs with report type of realm-routed-requests into answer messages and the content should be the aggregation of percentages as received in host type OLRs from all the servers in the realm.
 
Ulrich
 
 
 
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
 
Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of the meaning of realm-routed-request report (new attempt at a name to try to make Ulrich happy :-) ).

My definition is that it is a report generated by the server when the server does not want to receive new sessions.  

Your definition appears to be that it is a report generated by an agent (or a server is there are no agents in the network?) to indicate that the network need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can generate a realm-routed-request report without knowing the status of servers and their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based applications.  This could also be applied to pseudo session based applications and applications that always rely on realm routed requests.

Everyone, which definition applies?

Steve

On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
Steve,
 
See some comments below please.
/MCruz
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
Sent: lunes, 24 de febrero de 2014 17:20
To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
 
#57: Handling of "Realm-Routed" Overload report type
 
 I'm assuming the name of the realm overload report in the -01 version will
 be changed to realm-routed.  This issue applies independent of the actual
 name of the report.
 
 The current behavior assumed for the realm-routed report is that the
 reacting node, generally the client, will reduce the percentage of realm
 routed requests sent to the reporting node.
 
 This is actually bad behavior and could result in the client throttling
 traffic that could have been handled by the full set of servers for that
 Diameter application.
[MCruz] This can only happen if the agent has miscalculated the realm overload.
 
 Consider the case where there are n servers for a Diameter application and
 all of those server are able to handle any transaction for that
 application.
 
 When one of those servers becomes overloaded and wishes to decrease the
 number of new sessions, the primary use of realm-routed requests.  The
 server will generate an OLR of type realm-routed.
[MCruz] I do not agree. Servers do not generate Realm-routed reports.
 
 Assume in this case that the other servers are all healthy and able to
 handle new sessions.
 
 Clients will not have the knowledge that there are other servers in the
 network able to handle the new session and will have no choice but the
 throttle a percentage of the new session requests.  Even when these
 throttled requests could have been handled by any of the non overloaded
 servers.
 
 The proposal is to specify that realm-routed reports must be handled by
 DOIC-supporting agents.  Agents will understand if there are other servers
 able to handle the new session and, if so, can adjust the percentage of
 requests routed to the overloaded server.
 
 Agents that handle the realm-routed OLR must remove the request from the
 answer before relaying the answer to client.  This prevents the report
 from being acted on by either multiple agents (if multiple are in the
 path) or by an agent and a client.
 
 Clients that receive the realm-routed OLR must handle the OLR by
 throttling the requested percentage.
 
 
 


      

      



    

    

  


--------------060809070002050200060103--


From nobody Tue Feb 25 11:23:20 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F4A1A0114 for ; Tue, 25 Feb 2014 11:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPCDXGPmbDLy for ; Tue, 25 Feb 2014 11:23:05 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A91A024B for ; Tue, 25 Feb 2014 11:23:00 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1PJMsHS053265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 13:22:55 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <530CE90E.9060605@usdonovans.com>
Date: Tue, 25 Feb 2014 13:22:53 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6633436F-4838-4B9D-BA2C-989547F76347@nostrum.com>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <59BC706B-A39F-4682-AEAC-AC3808ADECBE@nostrum.com> <530CE90E.9060605@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QqsV9LFBsN_xHJBR-t3i3Gcfpb8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 19:23:12 -0000

On Feb 25, 2014, at 1:03 PM, Steve Donovan  =
wrote:

> Ben,
>=20
> I'm asserting that there are valid use cases (3GPP PCC for one) for a =
server sending a RRR that only impacts realm routed requests being sent =
to that server.  This is different than a RRR that reports on all realm =
routed requests sent to any server in the realm.

Then that is something different than they way I expected RRR reports =
(and I assume others) expected them to be used, and I think it would =
give incorrect behavior for other use cases. (1)

For example, lets assume a client knows about (either through =
configuration or dynamic discovery) two next hop destinations (A and B)  =
that can handle the Foo realm for a given application. It, at least =
initially, has no idea if those destinations are agents or servers. If =
that client receives an RRR OLR from A, is it allowed (or even expected) =
 to shift load to B? My intent for the RRR report type, based on our =
early discussions of the mixed-state scenario, was no. But I think the =
way you describe it, the answer would be yes.

I think we are talking about two distinct use cases. One is reporting =
overload that impacts the entire pool of servers that handle a =
particular realm+application. Another is is to allow reporting of =
overload that is created due to some number-of-session constrained =
resource. I agree both use cases are interesting, and potentially =
needed. But I don't think a single report type, without further =
modification, can handle both use cases.=20

I also think a single host could be session-constrained, and a pool of =
servers handling a realm could become session constrained. That suggests =
we need a way of saying "reduce (new) sessions" that can work for both =
host and RRR reports. That could be a separate algorithm, or some markup =
that says "please reduce sessions". =20

(1) To some degree, I think we are suffering from our choice to use =
report-types to distinguish these sort of semantics, rather than the =
scope concept in the Roach draft. The fundamental difference is an OLR =
could combine multiple scopes (e.g. "new session for realm Foo at host =
A"  , but can only have one type. (e.g. "realm foo" or "host a".)

>=20
> Steve
>=20
>=20
> On 2/25/14 12:51 PM, Ben Campbell wrote:
>> I think that both models are reasonable deployments. Our definitions =
of HRR and RRR should support both approaches. I say this with the =
caveat that, if a server sends an RRR report, it is claiming =
authoritative knowledge of all servers in the realm.
>>=20
>> Agents sending reports to clients can take _any_ input they want to. =
That could be host reports from servers, RRR reports from servers, =
Diameter errors, transport errors, and any number of proprietary =
methods.
>>=20
>> On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich)=20
>> 
>>  wrote:
>>=20
>>=20
>>> My understanding is that RRR reports are always aggregated reports. =
Agents generating an RRR report (for use on the DOIC association towards =
the reacting node) take as an input the host-type reports received on =
the DOIC associations with the servers.
>>> =20
>>> Ulrich
>>> =20
>>> From: ext Steve Donovan [
>>> mailto:srdonovan@usdonovans.com
>>> ]=20
>>> Sent: Tuesday, February 25, 2014 2:12 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome;=20
>>> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>>> =20
>>> How do agents learn about a set of servers ability to handle new =
sessions (host-less requests) if servers never sent realm-routed-request =
reports?
>>>=20
>>> I agree that agents should sent to aggregated report but the servers =
need to send RRR reports so the agent can route around them and generate =
those aggregated reports.
>>>=20
>>> Steve
>>>=20
>>> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Hi,
>>> I agree with MCruz.
>>> =20
>>> Principle is that the server never sends OLRs with a report type of =
realm-routed-request (exept the case where the server knows (i.e.is =
configured) that there is no other server in that realm).
>>> =20
>>> Only agents that are configured to take the role of a reporting node =
for a realm will insert OLRs with report type of realm-routed-requests =
into answer messages and the content should be the aggregation of =
percentages as received in host type OLRs from all the servers in the =
realm.
>>> =20
>>> Ulrich
>>> =20
>>> =20
>>> =20
>>> =20
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of ext Steve Donovan
>>> Sent: Monday, February 24, 2014 8:31 PM
>>> To: Maria Cruz Bartolome;=20
>>> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>>> =20
>>> Maria Cruz,
>>>=20
>>> Thanks for the comments.  We obviously have a different =
understanding of the meaning of realm-routed-request report (new attempt =
at a name to try to make Ulrich happy :-) ).
>>>=20
>>> My definition is that it is a report generated by the server when =
the server does not want to receive new sessions. =20
>>>=20
>>> Your definition appears to be that it is a report generated by an =
agent (or a server is there are no agents in the network?) to indicate =
that the network need to handle fewer new sessions.
>>>=20
>>> I actually think both cases apply but I don't think that an agent =
can generate a realm-routed-request report without knowing the status of =
servers and their ability to handle new Diameter sessions.
>>>=20
>>> Note that I'm discussing this in the context of session-based =
applications.  This could also be applied to pseudo session based =
applications and applications that always rely on realm routed requests.
>>>=20
>>> Everyone, which definition applies?
>>>=20
>>> Steve
>>>=20
>>> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>>> Steve,
>>> =20
>>> See some comments below please.
>>> /MCruz
>>> =20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of dime issue tracker
>>> Sent: lunes, 24 de febrero de 2014 17:20
>>> To:=20
>>> draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
>>>=20
>>> Cc:=20
>>> dime@ietf.org
>>>=20
>>> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload =
report type
>>> =20
>>> #57: Handling of "Realm-Routed" Overload report type
>>> =20
>>>  I'm assuming the name of the realm overload report in the -01 =
version will
>>>  be changed to realm-routed.  This issue applies independent of the =
actual
>>>  name of the report.
>>> =20
>>>  The current behavior assumed for the realm-routed report is that =
the
>>>  reacting node, generally the client, will reduce the percentage of =
realm
>>>  routed requests sent to the reporting node.
>>> =20
>>>  This is actually bad behavior and could result in the client =
throttling
>>>  traffic that could have been handled by the full set of servers for =
that
>>>  Diameter application.
>>> [MCruz] This can only happen if the agent has miscalculated the =
realm overload.
>>> =20
>>>  Consider the case where there are n servers for a Diameter =
application and
>>>  all of those server are able to handle any transaction for that
>>>  application.
>>> =20
>>>  When one of those servers becomes overloaded and wishes to decrease =
the
>>>  number of new sessions, the primary use of realm-routed requests.  =
The
>>>  server will generate an OLR of type realm-routed.
>>> [MCruz] I do not agree. Servers do not generate Realm-routed =
reports.
>>> =20
>>>  Assume in this case that the other servers are all healthy and able =
to
>>>  handle new sessions.
>>> =20
>>>  Clients will not have the knowledge that there are other servers in =
the
>>>  network able to handle the new session and will have no choice but =
the
>>>  throttle a percentage of the new session requests.  Even when these
>>>  throttled requests could have been handled by any of the non =
overloaded
>>>  servers.
>>> =20
>>>  The proposal is to specify that realm-routed reports must be =
handled by
>>>  DOIC-supporting agents.  Agents will understand if there are other =
servers
>>>  able to handle the new session and, if so, can adjust the =
percentage of
>>>  requests routed to the overloaded server.
>>> =20
>>>  Agents that handle the realm-routed OLR must remove the request =
from the
>>>  answer before relaying the answer to client.  This prevents the =
report
>>>  from being acted on by either multiple agents (if multiple are in =
the
>>>  path) or by an agent and a client.
>>> =20
>>>  Clients that receive the realm-routed OLR must handle the OLR by
>>>  throttling the requested percentage.
>>> =20
>>> =20
>>> =20
>>>=20
>>=20
>=20


From nobody Tue Feb 25 12:07:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112E31A01E1 for ; Tue, 25 Feb 2014 12:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm-Fy7jiq_df for ; Tue, 25 Feb 2014 12:07:01 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E446A1A0157 for ; Tue, 25 Feb 2014 12:07:01 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56167 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIL0J-0004U9-1Q; Tue, 25 Feb 2014 08:37:14 -0800
Message-ID: <530CC6A2.5010702@usdonovans.com>
Date: Tue, 25 Feb 2014 10:36:50 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com>  <530CB073.7000802@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------080203010806070409000108"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jwZs0cX-Hc9wMIEwi3j8ddsmR60
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 20:07:03 -0000

This is a multi-part message in MIME format.
--------------080203010806070409000108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Yes, with that period being long enough for the reporting node to be
confident that all previously sent overload reports have expired.

Steve

On 2/25/14 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben,
>
> for my clarification, your proposal is to say
>
> ***
> Sequence number is of type Unsigned64.
>
> When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for the initial occurrence of an overload condition at a reporting node.
> ***
>
> If so, what is meant by "initial occurrence of an overload condition"?
>
> I guess it means something like moving from no overload to overload after a sufficiently long periode of no overload
>
> Please clarify
>
> Ulrich
>
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Tuesday, February 25, 2014 4:02 PM
> To: Ben Campbell
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#32 status
>
> I agree with the suggested change.
>
> Steve
> On 2/24/14 5:00 PM, Ben Campbell wrote:
> + 1, except as noted:
>
> On Feb 24, 2014, at 2:33 PM, Steve Donovan  wrote:
>
> Ulrich,
>
> Would you agree to the following to replace the first two statements:
>
> Sequence number is of type Unsigned64.
>
> When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for any occurrence of overload at a reporting node.  This, I think, allows us to ignore wraparound issues as wraparound will never happen.  Unless we are worried about a server staying in overload for billions of years (assuming reports with a ten minute validity period refreshed every five minutes).
>
> s/ any occurrence of overload / the initial occurrence of an overload condition
>
>
> The other two statements are good.
>
> Steve
>
>
>
>


--------------080203010806070409000108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Yes, with that period being long enough for the reporting node to
      be confident that all previously sent overload reports have
      expired.

      

      Steve

      

    
    
On 2/25/14 10:21 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Steve, Ben,

for my clarification, your proposal is to say

***
Sequence number is of type Unsigned64.

When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for the initial occurrence of an overload condition at a reporting node.
***

If so, what is meant by "initial occurrence of an overload condition"?

I guess it means something like moving from no overload to overload after a sufficiently long periode of no overload

Please clarify

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 25, 2014 4:02 PM
To: Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#32 status

I agree with the suggested change.

Steve
On 2/24/14 5:00 PM, Ben Campbell wrote:
+ 1, except as noted:

On Feb 24, 2014, at 2:33 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Ulrich,

Would you agree to the following to replace the first two statements:

Sequence number is of type Unsigned64.

When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for any occurrence of overload at a reporting node.  This, I think, allows us to ignore wraparound issues as wraparound will never happen.  Unless we are worried about a server staying in overload for billions of years (assuming reports with a ten minute validity period refreshed every five minutes).

s/ any occurrence of overload / the initial occurrence of an overload condition


The other two statements are good.

Steve






    

    

  


--------------080203010806070409000108--


From nobody Tue Feb 25 12:08:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268851A029D for ; Tue, 25 Feb 2014 12:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkMFUDWX5zvL for ; Tue, 25 Feb 2014 12:08:25 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id B96A31A0157 for ; Tue, 25 Feb 2014 12:08:25 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1PK8HWB054902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 14:08:18 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B92097862DC@ESESSMB101.ericsson.se>
Date: Tue, 25 Feb 2014 14:08:17 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <530B84F8.5030006@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784BED@ESESSMB101.ericsson.se> <530B9FF4.4070108@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784E89@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4657@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784EF9@ESESSMB101.ericsson.se> <530C990E.4040301@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4761@DEMUMBX014.nsn-intra.net> <530CAD40.8050505@usdonovans.com> <087A34937E64E74E848732CFF8354B92097862DC@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XbhBoGkQpH40N6TUNe04Rw6rRJM
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue #23 Proposed resolution
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 20:08:30 -0000

I think limiting RRR reports to agents is too restrictive. I think any =
node that has knowledge of the overload state of the realm should be =
able to send an RRR report. I concur that this would typically be done =
by agents, but if an operator chooses to deploy servers that share =
overload state so that any given server can report on the realm, we =
should let them. It would be better to say that aggregate RRR reports =
should only be sent by nodes that actually have an aggregate knowledge =
of the realm.

I recognize it's hard for a server to know if it's knowledge is =
complete. Perhaps there are servers it doesn't know about. But I think =
this is also true of agents--perhaps there are other agents that have =
other servers behind them that the first agent doesn't know about.=20

On Feb 25, 2014, at 10:02 AM, Maria Cruz Bartolome =
 wrote:

> Hello,
> =20
> I agree to what is being stated by Ulrich here.
> =20
> Realm aggregated report is calculated by an agent, based on individual =
server host-reports. Then, it is up to each application to determine, =
based on requested traffic reduction, whether it is convenient or not to =
start new sessions. This is application dependent, since load/resources =
required by a session compared to mid session traffic is application =
dependent. A part from that, it could be up to some other criteria, like =
e.g. whether or not mid session traffic should be prioritized against =
new session creations, what would depend eventually on each application.
> =20
> Regards
> /MCruz
> =20
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: martes, 25 de febrero de 2014 15:49
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Issue #23 Proposed resolution
> =20
> Ulrich,
>=20
> Please see inline.
>=20
> Steve
>=20
> On 2/25/14 8:26 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> see inline
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Tuesday, February 25, 2014 2:22 PM
> To: dime@ietf.org
> Subject: Re: [Dime] Issue #23 Proposed resolution
> =20
> I believe the other issue then is whether servers generate RRR =
reports.
>=20
> Consider the most basic case where there are no agents.
>=20
>  C1--\
>  C2-------S
>  C3--/
>=20
> Is it not appropriate for a server, in this case, to be able to send =
RRRs?
>=20
> no
>=20
> SRD> Then we have a bigger disconnect then I thought.  I'm pretty sure =
that we had discussed the ability of a server to use what we are now =
calling RRRs to be able to indicate that it does not want to take on new =
sessions.  Host reports are used to control the mid-session traffic (for =
session based applications like those used in the 3GPP PCC =
architecture). =20
>=20
> SRD> I would also assert that PCC is a case where there is a strong =
need for the server to be able to say that it wants to reduce the number =
of new session taken on so that the DRA in that architecture can =
properly route sessions that generate new bindings.
>=20
> SRD> So, to summarize, I believe that we DO have a requirement to =
allow the server to send RRRs.
>=20
> SRD> Maybe we need two types of RRRs, one that applies to a single =
server and one that applies to the full realm.  Yes Ben, these do start =
to sound like scopes :-) but this can also be addressed by either =
creating separate report types or qualifying the RRR report.
>=20
>=20
> In an agent case, the server sending the RRR gives the agent the =
ability to generate an aggregated RRR the covers all servers for the =
application.
>=20
> the agent should aggregate received host-type reports and =
convert it into an RRR report
>=20
> SRD> This is what an agent would do to generate the proposed new =
"realm" report.  I'm skeptical that an agent can make reasonable =
decisions about what RRR report to generate based on host reports =
received.
>=20
>   So I guess, there would be a DOIC association between the client and =
the agent use to transport the aggregated RRR
>=20
> yes
>=20
> and a DOIC associate between the agent and the server used to =
transport the server specific RRR
>=20
> server specific host-type report
>=20
> .
>=20
> Steve
>=20
> On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:
> Fine to agree
> =20
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
> Sent: martes, 25 de febrero de 2014 10:16
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: RE: [Dime] Issue #23 Proposed resolution
> =20
> Steve, MCruz,
> =20
> lets go step by step.
> =20
> =20
> I=92m ok to conclude on #23 to do the renaming from =93realm report =
type=94 to =93realm-routed-request report type=94 and clarify that it =
applies to destination-host-less traffic.
> =20
> =20
> Whether or not to introduce a 3rd report type of =93realm=94 is out of =
scope of #23 and subject of #55.
> =20
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz =
Bartolome
> Sent: Tuesday, February 25, 2014 10:05 AM
> To: dime@ietf.org
> Subject: Re: [Dime] Issue #23 Proposed resolution
> =20
> Steve,
> =20
> The discussion started around some proposed use cases by Ulrich, and =
to my knowledge that discussion is not concluded.
> Then we have not agreed (at least yet) on having a differentiation =
between realm and realm-routed.
> Even more, as far as I understand the proposal it is related to the =
ability (by agent) to select the a server (in a farm, providing service =
to a realm) for new session establishment. This is something we =
discussed long time ago, and at that point in time we tend to agree that =
it was not required, but up to different applications to decide based on =
realm overload.
> Enhancements could be done on top of this, but first we need to agree =
on the basic use cases.
> =20
> I hope this clarifies
> Cheers
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: lunes, 24 de febrero de 2014 20:40
> To: dime@ietf.org
> Subject: Re: [Dime] Issue #23 Proposed resolution
> =20
> Maria Cruz,
>=20
> I thought you had asserted that there was a 3GPP requirement to have =
the ability to have a realm report that control the total amount of =
traffic sent to a realm.  There is certainly an IETF DOC requirement to =
this effect.
>=20
> The proposal is to have three report types (or four depending on the =
resolution of the per client host report discussion).
>=20
> - Host report - Apply to all requests sent to a host.  The host is =
indicated by the origin-host AVP in the answer message carrying the =
report.  Can be generated by a server or by an agent acting as a =
front-end to a group of servers.
>=20
> - Realm-routed-request report - Applies to all requests sent to a =
realm without a destination-host AVP in the request message.  Can be =
generated by a server or by an agent acting as a front-end to a group of =
servers.
>=20
> - Realm report - Applies to all requests sent to the realm, =
independent of the presence or absence of a destination-host AVP in the =
request message.  Can be generated by a server or an agent.  The method =
for determining the realm state is out of scope for the DOIC document.
>=20
> Steve
>=20
> On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
> Hello,
> =20
> I do not think we have agreed so far on the need to have two different =
reports (so called realm-routed and just realm).
> Regards
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf OfSteve Donovan
> Sent: lunes, 24 de febrero de 2014 18:44
> To: dime@ietf.org
> Subject: [Dime] Issue #23 Proposed resolution
> =20
> I propose the following resolution for issue 23:
>=20
>=20
>=20
>=20
> Proposal =96 Change the name of realm report. =20
>=20
> Proposed name - =93Realm-Routed-Request=94 report.
>=20
> Proposal =96 Update all discussion on =93Realm-Routed-Request=94 =
reports to indicate that they apply only to requests targeted to a realm =
when there is no destination-host AVP in the request.  Specifically, =
section 4.6 requires updating.
>=20
> There is also a proposal to add a new report type to handle all =
transactions to a realm.  This is addressed by ticket number 55.
>=20
> Regards,
>=20
> Steve
> =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
>=20
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Feb 25 23:07:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621551A0864 for ; Tue, 25 Feb 2014 23:07:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDGz9FPmIueH for ; Tue, 25 Feb 2014 23:07:15 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4DA1A0866 for ; Tue, 25 Feb 2014 23:07:15 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1Q77CwJ028308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Feb 2014 01:07:13 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1Q779a0015167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Feb 2014 08:07:09 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 08:07:09 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYA==
Date: Wed, 26 Feb 2014 07:07:09 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266B9E6FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qnA9LdxTfwZMgWCXw1abqtQ47hI
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 07:07:31 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266B9E6FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve, MCruz and all

On my side,  I agree with Lionel.

I  have not the  same reading of the draft where I have  not found the Stev=
e's default case.
I agree with Lionel that the OLR for a DOIC association relates to this DOI=
C association  and the OLR can be different  for another DOIC association. =
The basic (or "default") principle is that each DOIC association has its "o=
wn life".

Then,  a server (local policy) can decide  to send  the same OLR to all its=
 clients (so for all its DOIC associations) , or it can define  particular =
OLR values for   certain clients.
Another  interest  is that  when the server wants to update the OLR values =
towards  clients, it is  not obliged to send the new values  simultaneously=
  to all the clients : it may  (local server policy) progressively  change =
 the  value  over a certain duration  to minimize  sharp transitions.

So for DOIC supporting clients, the current text allows these possibilities=
, and in particular it satisfies the 3GGP client mitigation requirement.

A second step is to address DAs supporting non DOIC clients. Over time,  we=
 may expect that clients will be more and more DOIC supporting; so, this is=
 the main target. DAs with non DOIC client would be more for   a transition=
 (to be considered  nevertheless and which may be long).

The current text says that DA is acting on behalf of "A" client; so princip=
le  with host OLR per DOIC association also applies, and there is no differ=
ence for the server, as this does not make a difference  between a DOIC sup=
porting client and a DA supporting non DOIC clients.
Nevertheless, and here I come to Steve's point,   this has a cost implying =
the DA to manage OLRs per client. Steve  introduces an optimization where i=
n fact a set of clients are considered for me as a pool regarding  DOIC whe=
re only one OLR applies and where throttling  applies  to the requests of t=
his  pool of clients.  I am not against to optimization process   but this =
pool concept is new and needs some further study. First about the concept o=
f DOIC association which evolves , as now linked to a pool .

There was a MCruz remark about sequence number, a new AVP or a  new report =
type.  I see that  we may have to review  the processing of the seq number =
 handling as also dependent of the new AVP or the OLR type; so   a "collate=
ral " effect of the optimization. I would also think that, instead of intro=
ducing a single node indication in the OLR (AVP or report type) , it should=
 be a global indication as the optimization   is to support a global DOIC a=
ssociation.  To also see if there are not other collateral effects to analy=
ze.

Ulrich  also mentioned that for realm OLRs we may also have  a different re=
alm  OLR sent to different clients, so this is the same principle as Lionel=
  for  a realm OLR per DOIC association, on which I agree.

The current text due to the DOIC association principle,  allows this realm =
OLR per DOIC association for both  DOIC  supporting clients and  DAs acting=
 on behalf of A client. Then I expect Steve  to do the same remark, with th=
e same reason  to have  an optimization  where all clients receives  the  s=
ame realm OLR, but to also see the collateral effects.

As a conclusion, I think we should remain with the current text as the base=
line, following the DOIC association principle that Lionel mentions, and af=
ter more investigation to assess the  optimization  for host and realm OLRs=
 with DA supporting non DOIC,  this optimization being optional.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 f=E9vrier 2014 10:09
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Yes, I agree with Steve.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange.com; dime@ietf.or=
g
Subject: Re: [Dime] Issue#35 conclusion

Lionel,

The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents.

I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case then t=
here is little benefit (and significant overhead) to requiring an agent to =
maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is the cas=
e then the reporting node should indicate that it only applies to the origi=
n-host in the request and only then should agents be required to maintain s=
tate for the non-supporting client.

Steve
On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:
I really don't understand but it is not the first time :)

What about the DOIC association? What about my assumption about agent maint=
aining overload control state for non-DOIC enabled client?
So for me, the proposal from Ulrich is a clarification on the agent behavio=
r that was implicit if you consider the comments above.

For me, the option for the server is only to send a specific OLR for a spec=
ific client. So over two different DOIC association with the same server/re=
porting node, you can have two different OLRs.
But it does not change the way the OLR is handled by reacting nodes.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Maria Cruz,

To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of the ba=
se specification, as it is likely that most/all applications will want the =
same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origin-Hos=
t reports should be specified in a common way.

Steve
On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
Hello again,

I forgot to mention something else in this thread, that I already mentioned=
 in related thread #56.

This is all in order to take into account 3GPP requirement on overload miti=
gation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".



Therefore, we can even consider this new OLR out of the base draft, and be =
considered by 3GPP applications when required.



Best regards

/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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


___________________________________________________________________________=
______________________________________________



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_E194C2E18676714DACA9C3A2516265D20266B9E6FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve, MCruz and all


 <=
/p>

On my side,  I agree=
 with Lionel.


 <=
/p>

I  have not the &nbs=
p;same reading of the draft where I have  not found the Steve’s =
default case.



I agree with Lionel that =
the OLR for a DOIC association relates to this DOIC association  and t=
he OLR can be different  for another DOIC association. The basic
 (or “default”) principle is that each DOIC association has its=
 “own life”.


 <=
/p>

Then,  a server (loc=
al policy) can decide  to send  the same OLR to all its clients (=
so for all its DOIC associations) , or it can define  particular OLR v=
alues
 for   certain clients. 


Another  interest &n=
bsp;is that  when the server wants to update the OLR values towards &n=
bsp;clients, it is  not obliged to send the new values  simultane=
ously  to all
 the clients : it may  (local server policy) progressively  chang=
e  the  value  over a certain duration  to minimize &nb=
sp;sharp transitions.


 <=
/p>

So for DOIC supporting cl=
ients, the current text allows these possibilities, and in particular it sa=
tisfies the 3GGP client mitigation requirement.


 <=
/p>

A second step is to addre=
ss DAs supporting non DOIC clients. Over time,  we may expect that cli=
ents will be more and more DOIC supporting; so, this is the main
 target. DAs with non DOIC client would be more for   a transitio=
n (to be considered  nevertheless and which may be long).


 <=
/p>

The current text says tha=
t DA is acting on behalf of “A” client; so principle  with=
 host OLR per DOIC association also applies, and there is no difference for
 the server, as this does not make a difference  between a DOIC suppor=
ting client and a DA supporting non DOIC clients.


Nevertheless, and here I =
come to Steve’s point,   this has a cost implying the DA to=
 manage OLRs per client. Steve  introduces an optimization where in fa=
ct
 a set of clients are considered for me as a pool regarding  DOIC wher=
e only one OLR applies and where throttling  applies  to the requ=
ests of this  pool of clients.  I am not against to optimization =
process   but this pool concept is new and needs some further
 study. First about the concept of DOIC association which evolves , as now =
linked to a pool .


 <=
/p>

There was a MCruz remark =
about sequence number, a new AVP or a  new report type.  I see th=
at  we may have to review  the processing of the seq number  =
;handling
 as also dependent of the new AVP or the OLR type; so   a “=
collateral “ effect of the optimization. I would also think that, ins=
tead of introducing a single node indication in the OLR (AVP or report type=
) , it should be a global indication as the optimization
   is to support a global DOIC association.  To also see if =
there are not other collateral effects to analyze.


 <=
/p>

Ulrich  also mention=
ed that for realm OLRs we may also have  a different realm  OLR s=
ent to different clients, so this is the same principle as Lionel  for
  a realm OLR per DOIC association, on which I agree.


 <=
/p>

The current text due to t=
he DOIC association principle,  allows this realm OLR per DOIC associa=
tion for both  DOIC  supporting clients and  DAs acting on b=
ehalf
 of A client. Then I expect Steve  to do the same remark, with the sam=
e reason  to have  an optimization  where all clients receiv=
es  the  same realm OLR, but to also see the collateral effects.



 <=
/p>

As a conclusion, I think =
we should remain with the current text as the baseline, following the DOIC =
association principle that Lionel mentions, and after more
 investigation to assess the  optimization  for host and realm OL=
Rs with DA supporting non DOIC,  this optimization being optional.


 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 25 f=E9vrier 2014 10:09

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Yes, I agree with Steve.<=
/span>


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:24

To: lionel.morand@orange=
.com;
dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Lionel,



The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents. 




I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case t=
hen there is little benefit (and significant
 overhead) to requiring an agent to maintain state per non-supporting clien=
t.



I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is th=
e case then the reporting node should indicate that it only applies to the =
origin-host in the request and only then
 should agents be required to maintain state for the non-supporting client.=




Steve




On 2/24/14 12:57 PM, 
lionel.morand@orange.com wrote:






I really don't understand=
 but it is not the first time
J


 <=
/p>

What about the DOIC assoc=
iation? What about my assumption about agent maintaining overload control s=
tate for non-DOIC enabled client?


So for me, the proposal f=
rom Ulrich is a clarification on the agent behavior that was implicit if yo=
u consider the comments above.


 <=
/p>

For me, the option for th=
e server is only to send a specific OLR for a specific client. So over two =
different DOIC association with the same server/reporting
 node, you can have two different OLRs.


But it does not change th=
e way the OLR is handled by reacting nodes.


 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 19:50

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Maria Cruz,



To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of t=
he base specification, as it is likely that most/all applications will want=
 the same behavior.



Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origi=
n-Host reports should be specified in a common way.



Steve




On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:






Hello=
 again,


 =
;


I for=
got to mention something else in this thread, that I already mentioned in r=
elated thread #56.


 =
;


This =
is all in order to take into account 3GPP requirement on overload mitigatio=
n differentiation per client. But this is a server option:


TR 29809 ch. 6.4.7.1 states "It=
 may be up to the server/agent implementations to decide when and whether o=
verload mitigation differentiation per client is used".


 


Therefore, we can even consider this=
 new OLR out of the base draft, and be considered by 3GPP applications when=
 required.


 


Best regards


/MCruz


 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: lunes, 24 de febrero de 2014 19:19

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Steve, all,




I agree with Steve.


 <=
/p>

However, I would like to =
share one concern. We need to avoid that existing (if any) host OLR (“=
;all-client”) in the reacting node is replaced by new host OLR
 (per client).


Host OLR (per client) wit=
h the new AVP requires that the server uses a new sequence number, but exis=
ting host OLR (all) shall not be replaced, on the contrary
 both Host OLR (all) and new Host OLR (per client) should remain.


In order to achieve this,=
 it could be more convenient to use a dedicated OLR type (host per client),=
 instead of a new AVP.


 <=
/p>

Let me know your opinions=
.


Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Adding an AVP to indi=
cate that a report applies just to the Origin-Host in the request is not ju=
st an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






I=
s it implicit? 


&=
nbsp;


I=
f the agent detects that a client is not supporting DOIC, this agent will h=
ave to store the corresponding overload control state on behalf of this cli=
ent and only this client (saying that other clients may support DOIC). I'm =
assuming then that any agent will have to store somewhere the origin-host o=
f this client. And therefore, I don't see what would be the added-value of =
this AVP saying that this OLR is only for this client.

&=
nbsp;


E=
ven if this AVP is present, it would not preclude a reporting node to alway=
s put this AVP in every answer, even if the OLR is the same for all the cli=
ents.


&=
nbsp;


R=
egards,


&=
nbsp;


L=
ionel


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces=
@ietf.org] De la part de Maria Cruz Bartolome


E=
nvoy=E9 : lundi 24 f=E9vrier 2014 14:27


=
=C0 : dime@ietf.org


O=
bjet : Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello Ulrich,


&=
nbsp;


I=
 haven't proposed to limit this to host type OLR, I just wanted to clarify =
if this is what JJ got in mind.


&=
nbsp;


I=
 agree it could be done as you explained in the example below, but the open=
 question is whether it is better to add an AVP when OLR is just meant for =
one single client, or on the contrary the agent _always_ need to bind OLR t=
o one specific client, even if the server simply requires same OLR for any =
client. 


&=
nbsp;


I=
 think having a new AVP simplifies agent behavior.


&=
nbsp;


B=
est regards


/=
MCruz


&=
nbsp;


-=
----Original Message-----


F=
rom: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


S=
ent: lunes, 24 de febrero de 2014 14:19


T=
o: Maria Cruz Bartolome; dime@ietf.org=



S=
ubject: RE: [Dime] Issue#35 conclusion


&=
nbsp;


H=
i MCruz,


t=
here is no reason to limit this to host type OLRs.


&=
nbsp;


I=
f we have an agent A that is configured to take the role of the reporting n=
ode for realm-type reports for realm R, A could receive host type OLRs from=
 servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduct=
ion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2);=
 A then would aggregate these info and return realm type OLRs to C1 request=
ing 20% reduction of traffic from C1 to R, and to C2 requesting 30% reducti=
on of traffic from C2 to R.


&=
nbsp;


B=
est regards


U=
lrich


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Maria Cruz Bartolome


S=
ent: Monday, February 24, 2014 2:02 PM


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello JJ and all,


&=
nbsp;


A=
s per email thread, the latest proposal is:


&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR." 


&=
nbsp;


A=
n Ulrich comments on this:


&=
quot;This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server."


&=
nbsp;


I=
s your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 


B=
est regards


/=
MCruz


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)


S=
ent: lunes, 24 de febrero de 2014 13:43


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
i Mcruz and all


&=
nbsp;


I=
 think that you are  mixing the case of the DA that is the "repor=
ting" node which wants to indicate a realm OLR to clients, and for whi=
ch will use various (non standardized ) ways to determine among which it ca=
n reuse the Host-OLR AVPs received from various servers. But in this case, =
clients receiving realm OLRs are supporting DOIC. 


H=
ere I understand the on going  discussion is about the DA behavior whe=
n  clients is not supporting DOIC and to reuse the Host-OLR received f=
or one client for other clients  .


&=
nbsp;


F=
or me I remain on  my previous mail, with a baseline solution. We may =
always study new extensions, optimizations, but priority should be on the b=
aseline.


&=
nbsp;


B=
est regards


&=
nbsp;


J=
acques 


&=
nbsp;


&=
nbsp;  


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces=
@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lundi 24 =
f=E9vrier 2014 13:21 =C0 : dime@ietf.=
org Objet : Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello all,


&=
nbsp;


N=
ot sure we all have the same understanding here.


L=
et me try to explain my concerns.


&=
nbsp;


T=
he original 3GPP requirement we want to cover is the need for a server to r=
educe traffic for one specific client, i.e. traffic identified by "Ori=
gin-Host" in the request.


T=
hen, two options are under analysis about whether or not the OLR in the ser=
ver answer shall be marked:


&=
nbsp;


a=
) OLR does not need to include anything else Receiver of the answer (and OL=
R) is the client that sends the request, identified by "Origin-Host&qu=
ot; in the request.


T=
hen, as long as the reacting node=3D=3D"Origin-Host", the expecte=
d reduction is performed and requirement fulfilled.


B=
ut, when an agent is acting on behalf of a client as the reacting node, the=
n the "Origin-Host" identifies final client, but not the reacting=
 node.


T=
hen, this is why the proposal is to add following clarification about agent=
 behavior (possible clause 5.5):


&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR."


B=
ut this will imply that _always_ the reacting node applies this OLR to one =
specific client, what is not what we need to achieve.

H=
ow will this impact the case where the agent is providing access to a Realm=
? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider f=
ollowing example:


-=
 C1 sends a Realm request via Agent, that finally reaches S1


-=
 S1 answers with OLR (Host:50%).


-=
 Agent is acting as reacting node on behalf of C1, if it considers this OLR=
 only bind to C1... then... should it consider S1-OLR only as relevant for =
requests coming from C1? Should agent do not use this S1-OLR to calculate a=
ggregated Realm overload?


I=
n my opinion, in this case it does not make sense to consider OLR was only =
meant to C1. And this problem could be solved adding explicit information, =
as in b) below.


&=
nbsp;


b=
) OLR needs to be extended (new AVP) that identifies the client ("Orig=
in-Host" in the request) from which traffic reduction shall apply.


W=
ith this new AVP, reacting node will easy be able to identify when OLR shal=
l be applied to any client or just to the Origin-Host identified by new AVP=
.


&=
nbsp;


L=
et me know your opinions please


B=
est regards


/=
MCruz


&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

S=
ent: lunes, 24 de febrero de 2014 12:28


T=
o: ext Steve Donovan; dime@ietf.org


S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


S=
teve,


&=
nbsp;


p=
lease see inline.


&=
nbsp;


U=
lrich


&=
nbsp;


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Steve Donovan


S=
ent: Friday, February 21, 2014 4:53 PM


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


U=
lrich,


&=
nbsp;


I=
 have a couple of concerns with this approach, as currently outlined. =
 


&=
nbsp;


F=
irst, how do we handle the case where there are multiple DOIC supporting ag=
ents between the non supporting client and the reporting node.  This, =
I guess, is a general question, not just applying to this proposal.  I=
 suggest we capture in the agent behavior section that is currently missing=
 wording indicating that the first supporting agent that receives the reque=
st must be the reacting node for that non-supporting client.  Subseque=
nt DOIC supporting agents must not be the reacting node for the non-support=
ing client.


&=
lt;Ulrich>I fully agree</Ulrich>


&=
nbsp;


&=
nbsp;


W=
e need to think through the ramifications of having multiple agents being t=
he reacting node for the same non supporting clients, as this could easily =
happen in networks where multiple agents are involved in a single transacti=
on.  On the surface it doesn't seem to be an issue for the loss algori=
thm, but this might not be the case with other algorithms.


&=
lt;Ulrich>I agree that this is not an issue for loss; it is an issue e.g=
. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>


&=
nbsp;


M=
y other concern is that this puts a lot of extra onus on the agent even for=
 the case where the reporting node does not want to differentiate overload =
reports.


&=
lt;Ulrich> I agree </Ulrich>


T=
o this end I suggest we add an indication in the OLR marking the reports th=
at are specific to just the Origin-Host in the request.  Absence of th=
e "single-client-only" AVP would mean that the report applies to =
all clients.  Presence of the AVP would indicate that the OLR applies =
to the Origin-Host.


&=
lt;Ulrich>I understand that the proposal is an optimization for agents. =
Therefore the semantics of the marking should be reverse: unmarked OLRs are=
 client specific, marked OLRs indicate that the reporting node does not wan=
t to differentiate, and therefore allow agents not to do the binding to the=
 client.</Ulrich>     


&=
nbsp;


S=
teve


O=
n 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:=



B=
en,


&=
nbsp;


t=
he proposed conclusion was based on comments received so far (from Lionel, =
Nirav, Steve, MCruz, JJ). 


N=
ow you seem to address two points:


a=
) There is no dependency to DOIC support of the client.

T=
o address this I would like to propose rewording of the clarifying text for=
 5.5. as follows:


&=
nbsp;


W=
hen an agent takes the role of a reacting node, the agent needs to bind a r=
eceived OLR to the origin host of the client that initiated the request whi=
ch corresponds to the answer containing the OLR. 


&=
nbsp;


T=
his would cover not only the case where an agent takes the role of the reac=
ting node on behalf of a (or several) non supporting client, but also the c=
ase where an agent is configured to take the role of a reporting node (for =
realm-type reports) towards the client and at the same time the role of a r=
eacting node towards the server.


&=
nbsp;


b=
) There is no binding of the OLR to the orig-host of the client Here I disa=
gree. We have the 3GPP requirement to allow requesting different amount of =
reduction from different clients, and I think we have 3 options:


1=
. ignore the 3GPP requirement


2=
. introduce new report types as originally proposed in #35 3. introduce the=
 binding between OLR and orig-host of the client.


&=
nbsp;


S=
o far I understood that people favoured option 3.


&=
nbsp;


S=
ee also inline.


&=
nbsp;


U=
lrich


&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: ext Ben Campbell [mailto:ben@nostru=
m.com]


S=
ent: Thursday, February 20, 2014 11:55 PM


T=
o: Wiehe, Ulrich (NSN - DE/Munich)


C=
c: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


&=
nbsp;


O=
n Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:


&=
nbsp;


#=
35: additional report types are proposed


 =



D=
ear all,


 =



I=
 believe we can conclude, not to add additional report types. However, we a=
greed to add clarifying text to clause 5.5 as follows:

 =



W=
hen an agent received an OLR in response to a request initiated by a client=
 not supporting DOIC, this agent needs to bind the received OLR to the orig=
in-host of the client.


&=
nbsp;


I=
 do not agree.


&=
nbsp;


Y=
ou proposal implies that the server's OLR only applies to that client.


&=
lt;Ulrich>exactly, that was the intention</Ulrich>  If there'=
s an intervening DOIC agent, then the agent, not the client, is the reactin=
g node from the server's perspective.


&=
lt;Ulrich> the server's perspective is agnostic. The server does not kno=
w whether it's the client or an agent on the path that takes the role of th=
e reacting node</Ulrich>  But, short of adding an origin-host ty=
pe, nothing binds the OLR to a particular client, regardless of DOIC suppor=
t at the clients.


&=
lt;Ulrich> the binding is always there, regardless of DOIC support at th=
e client</Ulrich>


&=
nbsp;


 =
Whether or not the client also supports DOIC doesn't change that. For DOIC-=
supporting clients, the agent has the additional option of reducing traffic=
 by asking the clients to reduce traffic (making them reacting nodes from t=
he perspective of the _agent_, but not the server.)  It doesn't have t=
hat option for non-DOIC clients.


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


&=
nbsp;


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.=



I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;




 















_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime




 


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


&=
nbsp;


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.=



I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.




 






--_000_E194C2E18676714DACA9C3A2516265D20266B9E6FR712WXCHMBA12z_--


From nobody Tue Feb 25 23:43:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361751A0041 for ; Tue, 25 Feb 2014 23:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4lX0NBmjMmE for ; Tue, 25 Feb 2014 23:43:23 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8A1A0047 for ; Tue, 25 Feb 2014 23:43:21 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1Q7hIua026263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Feb 2014 01:43:19 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1Q7hHYI009558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Feb 2014 08:43:17 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 08:43:17 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAACD12qAAAlPFjD///MvAIAAKsaA//1WeSA=
Date: Wed, 26 Feb 2014 07:43:16 +0000
Message-ID: 
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6C65.8080707@usdonovans.com>
In-Reply-To: <530B6C65.8080707@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266BA09FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sNe432GMxtZdd12Jh3j5puBWMgM
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 07:43:30 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266BA09FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

Remove "from now on" is acceptable for me, but  I have a preference for the=
 reverse wording Lionel proposes, which is shorter and brings the clarifica=
tion I was looking for,:

For example if an OC-Reduction-Percentage value of

 10 has been received, the reacting node which

 would normally send 100 packets MUST only send 90

 packets to the reporting node.


Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 17:00
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

I'm with Lionel.  I don't understand why the proposed wording is confusing.=
  Reacting nodes always only apply the reduction percentage for the period =
of time that the specific overload report is active.  That period either en=
ds when a new overload report is received or when the overload report expir=
es.

That said, I'm happy with just removing the words "from no on" as proposed =
by Lionel below.

Steve

On 2/24/14 7:26 AM, lionel.morand@orange.com wrote:

I don't see the issue, as explained in my mail but OK to remove it.



If "for now" is removed, the resulting text would be:



  For example if the reacting node has been sending

  100 packets per second to the reporting node, then

  a reception of OC-Reduction-Percentage value of 10

  would mean that from now on the reacting node MUST

  only send 90 packets per second.



Maybe it would be even easier to reverse the sentence as follow:



 For example if an OC-Reduction-Percentage value of

 10 has been received, the reacting node which

 would normally send 100 packets MUST only send 90

 packets to the reporting node.





But I'm fine if the initial proposed revised text is kept.



Lionel



De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:13

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



Hello,



I agree with Ulrich's proposal

Cheers

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 10:46

To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion



I share JJacques concern. Replacing "from now on" with "for the period that=
 the overload report is active"

is misleading. May be its better to simply remove "from now on".



Ulrich











From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)

Sent: Friday, February 21, 2014 7:11 PM

To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion



Hi MCruz, Steve



I also agree on the "would send " instead of the "would have sent"  for sur=
e.  But I have  a small concern/ clarification  about the Steve comment on =
  "for the period that the overload report is active" and the example to wh=
ich it refers.



During the time the OLR is active, which may be rather long,  the traffic t=
he reacting node would send may be 100 packet  when it has just received th=
e OLR. A bit later, the traffic it would send could be 120 (or 80), and fro=
m the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  whi=
ch I agree. This is in line  with the every 10th packet dropping  on which =
I also agree.



As the text   would  be written with the Steve modification , we may unders=
tand it is  80 Packet during all the time  the OLR is active. Not yet think=
 to an alternative text, but first to see if you agree with my remark.



JJacques





De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com

Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33

=C0 : Steve Donovan; dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



+1 (including Steve comment)



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



Maria Cruz,



I support your suggested changes.  I have one further suggested change belo=
w.



Steve

On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:

#52: Throttling not needed to be based on previous history



Following agreement is reached:



 Now (chapter 4.7):

    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

    and describes the percentage of the traffic that the sender is

    requested to reduce, compared to what it otherwise would have sent.



 Proposal:

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would send.          =
        <----





 Now (chapter 5.5.2):

      Indicates that the reporting node urges the reacting node to

      reduce its traffic by a given percentage.  For example if the

      reacting node has been sending 100 packets per second to the

      reporting node, then a reception of OC-Reduction-Percentage value

      of 10 would mean that from now on the reacting node MUST only send

      90 packets per second.  How the reacting node achieves the "true

      reduction" transactions leading to the sent request messages is up

      to the implementation.  The reacting node MAY simply drop every

      10th packet from its output queue and let the generic application

      logic try to recover from it.0 < value < 100



  Proposal:

 Indicates that the reporting node urges the reacting node to reduce

 its traffic by a given percentage. For example if the

 reacting node would send 100 packets to the                          <---

 reporting node, then a reception of OC-Reduction-Percentage value of

 10 would mean that from now on the reacting node MUST only send

 90 packets instead of 100. How the reacting node achieves the "true       =
<---

 reduction" transactions leading to the sent request messages is up to

 the implementation. The reacting node MAY simply drop every 10th

 packet from its output queue and let the generic application logic try

 to recover from it.

SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"















_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_E194C2E18676714DACA9C3A2516265D20266BA09FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

Remove “from now on=
” is acceptable for me, but  I have a preference for the reverse=
 wording Lionel proposes, which is shorter and brings the clarification I
 was looking for,:


For example if an OC-Reduction-Percentage value of 


 10 has been received, the reacting node which 


 would normally send 100 packets MUST only send 90 

 packets to the reporting node.


 <=
/p>

 <=
/p>

Best regards



 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 17:00

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


I'm with Lionel.  I don't understand why the pr=
oposed wording is confusing.  Reacting nodes always only apply the red=
uction percentage for the period of time that the specific overload report =
is active.  That period either ends when a new
 overload report is received or when the overload report expires.



That said, I'm happy with just removing the words "from no on" as=
 proposed by Lionel below.



Steve

 




On 2/24/14 7:26 AM, 
lionel.morand@orange.com wrote:






I don't see the issue, as explained in my mail but OK to remove it. 


 


If "for now" is removed, the resulting text would be:


 


  For example if the reacting node has been sending

  100 packets per second to the reporting node, then

  a reception of OC-Reduction-Percentage value of 10


  would mean that from now on the reacting node MUST

  only send 90 packets per second.


 


Maybe it would be even easier to reverse the sentence as follow:<=
/o:p>


 


 For example if an OC-Reduction-Percentage value of 


 10 has been received, the reacting node which 


 would normally send 100 packets MUST only send 90 

 packets to the reporting node.


 


 


But I'm fine if the initial proposed revised text is kept.<=
/pre>

 


Lionel


 


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:13


=C0 : dime@ietf.org


Objet : Re: [Dime] #52: Throttling not needed to be based on prev=
ious history - conclusion


 


Hello,


 


I agree with Ulrich's proposal


Cheers


/MCruz


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: lunes, 24 de febrero de 2014 10:46


To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org


Subject: Re: [Dime] #52: Throttling not needed to be based on previous=
 history - conclusion


 


I share JJacques concern. Replacing "from now on" with "=
;for the period that the overload report is active"


is misleading. May be its better to simply remove "from now on&qu=
ot;.


 


Ulrich


 


 


 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: Friday, February 21, 2014 7:11 PM


To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous=
 history - conclusion


 


Hi MCruz, Steve


 


I also agree on the "would send " instead of the "would=
 have sent"  for sure.  But I have  a small concern/ cl=
arification  about the Steve comment on   "for the peri=
od that the overload report is active" and the example to which it ref=
ers.


 


During the time the OLR is active, which may be rather long,  the=
 traffic the reacting node would send may be 100 packet  when it has j=
ust received the OLR. A bit later, the traffic it would send could be 120 (=
or 80), and from the OLR definition,   it would send 120x0,9 (or =
80* 0,9) packets, on  which I agree. This is in line  with the ev=
ery 10th packet dropping  on which I also agree. 


  


As the text   would  be written with the Steve modifica=
tion , we may understand it is  80 Packet during all the time  th=
e OLR is active. Not yet think to an alternative text, but first to see if =
you agree with my remark.


 


JJacques 


 


 


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de lionel.morand@orange.com


Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33


=C0 : Steve Donovan; dime@ietf.o=
rg


Objet : Re: [Dime] #52: Throttling not needed to be based on prev=
ious history - conclusion


 


+1 (including Steve comment)


 


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Steve Donovan


Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37


=C0 : dime@ietf.org


Objet : Re: [Dime] #52: Throttling not needed to be based on prev=
ious history - conclusion


 


Maria Cruz,


 


I support your suggested changes.  I have one further suggested c=
hange below.


 


Steve


On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:


#52: Throttling not needed to be based on previous history<=
/pre>

 


Following agreement is reached:


 


 Now (chapter 4.7):


    The OC-Reduction-Percentage AVP (AVP code TBD8) is =
type of Unsigned32


    and describes the percentage of the traffic that th=
e sender is


    requested to reduce, compared to what it otherwise =
would have sent.


 


 Proposal:


   The OC-Reduction-Percentage AVP (AVP code TBD8) is type o=
f Unsigned32  


   and describes the percentage of the traffic that the=
 sender is  


   requested to reduce, compared to what it otherwise w=
ould send.           =
;       <----


 


 


 Now (chapter 5.5.2):


      Indicates that the reporting node urges=
 the reacting node to


      reduce its traffic by a given percentag=
e.  For example if the


      reacting node has been sending 100 pack=
ets per second to the


      reporting node, then a reception of OC-=
Reduction-Percentage value


      of 10 would mean that from now on the r=
eacting node MUST only send


      90 packets per second.  How the re=
acting node achieves the "true


      reduction" transactions leading to=
 the sent request messages is up


      to the implementation.  The reacti=
ng node MAY simply drop every


      10th packet from its output queue and l=
et the generic application


      logic try to recover from it.0 < val=
ue < 100


 


  Proposal:


 Indicates that the reporting node urges the reacting node to reduce <=
o:p>


 its traffic by a given percentage. For example if the=



 reacting node would send 100 packets to the    &n=
bsp;            =
;         <---


 reporting node, then a reception of OC-Reduction-Percentage value of =



 10 would mean that from now on the reacting node MUST only send<=
o:p>


 90 packets instead of 100. How the reacting node achieves the "t=
rue       <---


 reduction" transactions leading to the sent request messages is =
up to 


 the implementation. The reacting node MAY simply drop every 10th=
 


 packet from its output queue and let the generic application log=
ic try 


 to recover from it.


SRD> Replace "from now on" in the above with "for th=
e period that the overload report is active"


 


 


 


 


 


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


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 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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_E194C2E18676714DACA9C3A2516265D20266BA09FR712WXCHMBA12z_--


From nobody Wed Feb 26 00:25:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51E71A00B7 for ; Wed, 26 Feb 2014 00:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr2mh95Htb7C for ; Wed, 26 Feb 2014 00:24:41 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E762D1A0075 for ; Wed, 26 Feb 2014 00:24:40 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1Q8OaGP014865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 09:24:36 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1Q8OYlN032290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 09:24:35 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 09:24:34 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 09:24:34 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Issue#32 status
Thread-Index: Ac8tiAGtvQe9mwQAS968RUS8ackr7wEDzhQAAAUk0YAAIZgPgAAD5hfw///7QQD//ueg0A==
Date: Wed, 26 Feb 2014 08:24:33 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4892@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com>  <530CB073.7000802@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net> <530CC6A2.5010702@usdonovans.com>
In-Reply-To: <530CC6A2.5010702@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4892DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 11250
X-purgate-ID: 151667::1393403077-00005322-4AF2DCFA/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bxC36UWdMT_pIzXMi3yDSDu7T24
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 08:24:48 -0000

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

I agree. It seems we can close issue#32.

I assume editors will convert the agreed principles to propper specificatio=
n text.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, February 25, 2014 5:37 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#32 status

Ulrich,

Yes, with that period being long enough for the reporting node to be confid=
ent that all previously sent overload reports have expired.

Steve
On 2/25/14 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve, Ben,



for my clarification, your proposal is to say



***

Sequence number is of type Unsigned64.



When generated, a new sequence number must be greater than the sequence num=
ber contained in the active overload report to which it applies (including =
over reboot of that node).  Note: this allows sequence numbers to start at =
1 for the initial occurrence of an overload condition at a reporting node.

***



If so, what is meant by "initial occurrence of an overload condition"?



I guess it means something like moving from no overload to overload after a=
 sufficiently long periode of no overload



Please clarify



Ulrich





From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Tuesday, February 25, 2014 4:02 PM

To: Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Issue#32 status



I agree with the suggested change.



Steve

On 2/24/14 5:00 PM, Ben Campbell wrote:

+ 1, except as noted:



On Feb 24, 2014, at 2:33 PM, Steve Donovan  wrote:



Ulrich,



Would you agree to the following to replace the first two statements:



Sequence number is of type Unsigned64.



When generated, a new sequence number must be greater than the sequence num=
ber contained in the active overload report to which it applies (including =
over reboot of that node).  Note: this allows sequence numbers to start at =
1 for any occurrence of overload at a reporting node.  This, I think, allow=
s us to ignore wraparound issues as wraparound will never happen.  Unless w=
e are worried about a server staying in overload for billions of years (ass=
uming reports with a ten minute validity period refreshed every five minute=
s).



s/ any occurrence of overload / the initial occurrence of an overload condi=
tion





The other two statements are good.



Steve










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











I agree. I=
t seems we can close issue#32.


 =
;


I assume e=
ditors will convert the agreed principles to propper specification text.


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Tuesday, February 25, 2014 5:37 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Issue#32 status






 


Ulrich,



Yes, with that period being long enough for the reporting node to be confid=
ent that all previously sent overload reports have expired.



Steve




On 2/25/14 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve, Ben,


 


for my clarification, your proposal is to say


 


***


Sequence number is of type Unsigned64.


 


When generated, a new sequence number must be greater than the sequenc=
e number contained in the active overload report to which it applies (inclu=
ding over reboot of that node).  Note: this allows sequence numbers to=
 start at 1 for the initial occurrence of an overload condition at a report=
ing node.


***


 


If so, what is meant by "initial occurrence of an overload condit=
ion"?


 


I guess it means something like moving from no overload to overload af=
ter a sufficiently long periode of no overload


 


Please clarify


 


Ulrich


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Tuesday, February 25, 2014 4:02 PM


To: Ben Campbell


Cc: dime@ietf.org list=



Subject: Re: [Dime] Issue#32 status


 


I agree with the suggested change.


 


Steve


On 2/24/14 5:00 PM, Ben Campbell wrote:


+ 1, except as noted:


 


On Feb 24, 2014, at 2:33 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


Ulrich,


 


Would you agree to the following to replace the first two statements:<=
o:p>


 


Sequence number is of type Unsigned64.


 


When generated, a new sequence number must be greater than the sequenc=
e number contained in the active overload report to which it applies (inclu=
ding over reboot of that node).  Note: this allows sequence numbers to=
 start at 1 for any occurrence of overload at a reporting node.  This,=
 I think, allows us to ignore wraparound issues as wraparound will never ha=
ppen.  Unless we are worried about a server staying in overload for bi=
llions of years (assuming reports with a ten minute validity period refresh=
ed every five minutes).


 


s/ any occurrence of overload / the initial occurrence of an overload =
condition


 


 


The other two statements are good.


 


Steve


 


 


 


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4892DEMUMBX014nsnin_--


From nobody Wed Feb 26 01:23:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7363A1A0178 for ; Wed, 26 Feb 2014 01:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc9SRGc4WvBR for ; Wed, 26 Feb 2014 01:23:24 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 335EA1A0149 for ; Wed, 26 Feb 2014 01:23:23 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1Q9NKPj011815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 10:23:21 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1Q9NKQH013546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 10:23:20 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 10:23:20 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 10:23:20 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzA=
Date: Wed, 26 Feb 2014 09:23:19 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com>
In-Reply-To: <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3144
X-purgate-ID: 151667::1393406601-00003660-E9C072C0/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/50H0DloZ7bPDPOfnHb5VSGR7ois
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 09:23:28 -0000

Steve, Ben, all,

on 1) we seem to agree that OC-Supported-Features in answers is not require=
d for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up=
 to drafts associated with new abatement algorithms to specify the requirem=
ent to include OC-Supported-Features in answers if so needed (I still don't=
 see the need even for rate or other algorithms); that needs to be discusse=
d when discussing those drafts.

On 2) I understand the usecase, but I'm not sure whether we have this requi=
rement of selective proactive throttling (see e-mail from Lionel). Anyway, =
given the conclusion on #31, OLR will be included in all answer messages (e=
xept when the reporting node is aware that the reacting node already knows)=
. Therefore the reacting node can deduce support of DOIC by the reporting n=
ode from the presence of OLR (if OLR is present then DOIC is supported by t=
he reporting node; if OLR is absent, then reacting node already knows wheth=
er or not DOIC is supported by the reporting node).

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Tuesday, February 25, 2014 12:02 AM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Feb 24, 2014, at 2:12 PM, Steve Donovan  wrote=
:

> I can see two additional reasons for requiring OC-Supported-Features:
>=20
> 1) If the reacting node needs to know in advance whether the type of over=
load abatement the reporting node will ask for.
>=20
> this is not needed in the case of the loss abatement algorithm as the rea=
cting node can just immediately start throttling the appropriate number of =
requests.  It does not require prior knowledge of the traffic sent.
>=20
> There are abatement algorithms that do require the client to keep state a=
bout traffic sent to specific destinations.  We can, if we choose, leave it=
 up to the drafts associated with the new abatement algorithms to specify t=
he requirement to include OC-Supported-Features, as proposed by Ulrich.
>=20
> 2) If the reacting node can use the absence of the OC-Supported-Features =
AVP in answer messages to know that there is no Diameter overload supported=
 in the network and thus take other measures to protect the Diameter networ=
k.  For example, I can envision a client implementation that adapts to the =
knowledge of whether servers support overload.  In the case that the server=
 does support overload the client can send unlimited traffic to the server,=
 up to the point that the server sends an OLR.  If the client determines th=
at the server does not support overload then it might have a configured max=
imum rate that it will send to the server.
>=20
> My inclination is to include the OC-Supported-Features AVP in answers bec=
ause most abatement algorithms will need it and because it can lead to bett=
er implementation client implementations.

+1 on both points
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Feb 26 02:00:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A260C1A01BA for ; Wed, 26 Feb 2014 02:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j5ZT0JIy6DJ for ; Wed, 26 Feb 2014 02:00:25 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01A1A01AF for ; Wed, 26 Feb 2014 02:00:24 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QA0KDY030546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 11:00:21 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QA09HD000573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 11:00:19 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 11:00:12 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 11:00:12 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPMagI3DCddS4DqUu7RccaCVEivZrHSnlQ
Date: Wed, 26 Feb 2014 10:00:12 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4917@DEMUMBX014.nsn-intra.net>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>  <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se>  <52FCB76E.6020202@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com>  <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <579DC2BE-CC3C-43E6-819C-ADB7B1182CED@nostrum.com> <530BBA98.9080903@usdonovans.com>
In-Reply-To: <530BBA98.9080903@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4917DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 13612
X-purgate-ID: 151667::1393408821-00003660-67040F24/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NRkxHJlTB8rpRg9M26x2ysPPtw0
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 10:00:30 -0000

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

My understanding was that e.g. if the reporting node has requested 30% redu=
ction but now detects that it needs a 50% reduction, it just sends a new OL=
R with 50% and that will implicitly indicate that the previous OLR with 30%=
 is no longer valid. This is a valid way to make the 30% OLR invalid; no ne=
ed to first send an zero validity time OLR to make the 30% OLR invalid. Any=
 (correctly coded) fresh OLR makes a previous OLR invalid.

The second sentence (at least in my understanding) is ambiguous: is it the =
OLR that contains a zero percentage that should not be regarded invalid or =
is it the previously received OLR?

I have no strong view whether or not to allow zero validity and/or zero per=
centage, but the proposed text is not understandable/acceptable.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 10:33 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I think the proposal here is the following:

A reporting node communicates that an overload report is no longer valid by=
 sending an OLR with a Validity-Period AVP with a value of zero.  This is t=
he only way for a reporting node to indicate that an overload report is no =
longer valid.  For instance, setting the reduction-percentage to zero does =
not make the overload report invalid.

Do we have agreement on this?

Steve
On 2/17/14 12:44 PM, Ben Campbell wrote:



On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com wrote:



I would like to highlight that my proposal is not related to the default Re=
duction-percentage algo.



Whatever the ago used, I think that an OLR can only be sent for two purpose=
s:

- Send an indication of overload situation

- Send an indication of end of the overload situation



For me, providing both indications in the same message would be a non-sense=
. And I don't understand why the validity period would prevail in that case=
.



So here's the question: Let's assume a reporting node sends you an OLR usin=
g the "loss" algorithm, a reduction-percentage of 50%, and a Validity-Durat=
ion of 10 minutes. 5 minutes later, it sends you a new OLR with an invalid =
reduction percentage and a Validity-Duration of 0.



What's the current overload state?



What if the second OLR used the "rate" algorithm, with a valid value, but s=
till had a validity duration of 0. Does that change anything?



I am arguing that, in both cases, the second OLR ends the overload period.



I'm actually okay if we have a normative statement to the effect that the r=
eporting node MUST NOT send an invalid reduction percentage, and that a rea=
cting node MUST ignore an OLR with an invalid value _except_ for the case o=
f a validity-duration set to zero.



This all comes down to how much guessing we are willing to do about the int=
ent of the sender when one receives an invalid OLR. I think it's reasonable=
 to guess that a zero validity duration means to end an overload condition,=
 without regard to the rest of the message. I _don't_ think it's reasonable=
 to try to guess what the sender meant with an invalid reduction percentage=
, when the validity period is non-zero.



Another, perhaps simpler, approach would be to assert that the reception of=
 _any_ invalid OLR automatically ends any existing overload condition. (I'm=
 not necessarily arguing for that--it's just something to think about.)





Now, if what is argued by Ben and supported by JJ and Steve is clear for th=
e rest of the group, I will not fight.



... but the fighting is the fun part :-)

_______________________________________________

DiME mailing list

DiME@ietf.org

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




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











My underst=
anding was that e.g. if the reporting node has requested 30% reduction but =
now detects that it needs a 50% reduction, it just sends a
 new OLR with 50% and that will implicitly indicate that the previous OLR w=
ith 30% is no longer valid. This is a valid way to make the 30% OLR invalid=
; no need to first send an zero validity time OLR to make the 30% OLR inval=
id. Any (correctly coded) fresh
 OLR makes a previous OLR invalid.


 =
;


The second=
 sentence (at least in my understanding) is ambiguous: is it the OLR that c=
ontains a zero percentage that should not be regarded invalid
 or is it the previously received OLR?


 =
;


I have no =
strong view whether or not to allow zero validity and/or zero percentage, b=
ut the proposed text is not understandable/acceptable.

 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, February 24, 2014 10:33 PM

To: dime@ietf.org

Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disa=
llowed?






 


I think the proposal =
here is the following:



A reporting node communicates that an overload report is no longer valid by=
 sending an OLR with a Validity-Period AVP with a value of zero.  This=
 is the only way for a reporting node to indicate that an overload report i=
s no longer valid.  For instance, setting
 the reduction-percentage to zero does not make the overload report invalid=
.  



Do we have agreement on this?



Steve




On 2/17/14 12:44 PM, Ben Campbell wrote:<=
/p>





 


On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com wrote:


 




I would like to highlight that my proposal is not related to the defau=
lt Reduction-percentage algo.


 


Whatever the ago used, I think that an OLR can only be sent for two pu=
rposes:


- Send an indication of overload situation


- Send an indication of end of the overload situation


 


For me, providing both indications in the same message would be a non-=
sense. And I don't understand why the validity period would prevail in that=
 case.




 


So here's the question: Let's assume a reporting node sends you an OLR=
 using the "loss" algorithm, a reduction-percentage of 50%, and a=
 Validity-Duration of 10 minutes. 5 minutes later, it sends you a new OLR w=
ith an invalid reduction percentage and a Validity-Duration of 0.


 


What's the current overload state?


 


What if the second OLR used the "rate" algorithm, with a val=
id value, but still had a validity duration of 0. Does that change anything=
?


 


I am arguing that, in both cases, the second OLR ends the overload per=
iod.


 


I'm actually okay if we have a normative statement to the effect that =
the reporting node MUST NOT send an invalid reduction percentage, and that =
a reacting node MUST ignore an OLR with an invalid value _except_ for the c=
ase of a validity-duration set to zero.


 


This all comes down to how much guessing we are willing to do about th=
e intent of the sender when one receives an invalid OLR. I think it's reaso=
nable to guess that a zero validity duration means to end an overload condi=
tion, without regard to the rest of the message. I _don't_ think it's reaso=
nable to try to guess what the sender meant with an invalid reduction perce=
ntage, when the validity period is non-zero.


 


Another, perhaps simpler, approach would be to assert that the recepti=
on of _any_ invalid OLR automatically ends any existing overload condition.=
 (I'm not necessarily arguing for that--it's just something to think about.=
)


 




 


Now, if what is argued by Ben and supported by JJ and Steve is clear f=
or the rest of the group, I will not fight.




 


... but the fighting is the fun part :-)


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4917DEMUMBX014nsnin_--


From nobody Wed Feb 26 02:04:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C603D1A01CF for ; Wed, 26 Feb 2014 02:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW2nesG8IT8G for ; Wed, 26 Feb 2014 02:03:54 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id A27071A01D2 for ; Wed, 26 Feb 2014 02:03:54 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1QA3pad017162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Feb 2014 04:03:53 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1QA3p9C006170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Feb 2014 11:03:51 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 11:03:50 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
Thread-Index: AQHPMZGJs8etUZ9zQk+PaBokCcufiprEug2AgADOqACAAFm1AIAAEoyAgABMWACAAANkAIAABVyAgAEBFWA=
Date: Wed, 26 Feb 2014 10:03:49 +0000
Message-ID: 
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <59BC706B-A39F-4682-AEAC-AC3808ADECBE@nostrum.com> <530CE90E.9060605@usdonovans.com> <6633436F-4838-4B9D-BA2C-989547F76347@nostrum.com>
In-Reply-To: <6633436F-4838-4B9D-BA2C-989547F76347@nostrum.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pQIHs8sGzR4lXShvhsjE7awZ2jw
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 10:04:02 -0000

Dear all

About this thread, I am in line with Ulrich and Mcruz comments that realm O=
LRS are generated  by DOICs DAs dealing with realm, overload.
Regarding Lionel comment that a server, aware of the overload  of other ser=
vers, can generate a realm OLR, in fact in this case  the node supports the=
 server functional entity  and a DA  functional entity addressing realm ove=
rload. This is common for implementations to do such integrations (eg in 3G=
PP) but it does not change the content of a functional entity=20

Regarding Steve concern, I think (as Ben) this is a new requirement where s=
erver would like to drive the behavior of a client on the type of requests.=
 My current understanding is that the server indicates an overload and then=
 this is to the client (and to the DA acting on realm requests) to decide o=
n what is throttled/rerouted and this is quite application dependent. Perso=
nally, I do not yet see the need for such a server requirement.=20

So this is a new extension to investigate later (including the requiremnt o=
r this extension)) and outside of our currents scope for the baseline draft=
.

Best regards

Jacques=20

=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoy=E9=A0: mardi 25 f=E9vrier 2014 20:23
=C0=A0: Steve Donovan
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report=
 type

On Feb 25, 2014, at 1:03 PM, Steve Donovan  wrote=
:

> Ben,
>=20
> I'm asserting that there are valid use cases (3GPP PCC for one) for a ser=
ver sending a RRR that only impacts realm routed requests being sent to tha=
t server.  This is different than a RRR that reports on all realm routed re=
quests sent to any server in the realm.

Then that is something different than they way I expected RRR reports (and =
I assume others) expected them to be used, and I think it would give incorr=
ect behavior for other use cases. (1)

For example, lets assume a client knows about (either through configuration=
 or dynamic discovery) two next hop destinations (A and B)  that can handle=
 the Foo realm for a given application. It, at least initially, has no idea=
 if those destinations are agents or servers. If that client receives an RR=
R OLR from A, is it allowed (or even expected)  to shift load to B? My inte=
nt for the RRR report type, based on our early discussions of the mixed-sta=
te scenario, was no. But I think the way you describe it, the answer would =
be yes.

I think we are talking about two distinct use cases. One is reporting overl=
oad that impacts the entire pool of servers that handle a particular realm+=
application. Another is is to allow reporting of overload that is created d=
ue to some number-of-session constrained resource. I agree both use cases a=
re interesting, and potentially needed. But I don't think a single report t=
ype, without further modification, can handle both use cases.=20

I also think a single host could be session-constrained, and a pool of serv=
ers handling a realm could become session constrained. That suggests we nee=
d a way of saying "reduce (new) sessions" that can work for both host and R=
RR reports. That could be a separate algorithm, or some markup that says "p=
lease reduce sessions". =20

(1) To some degree, I think we are suffering from our choice to use report-=
types to distinguish these sort of semantics, rather than the scope concept=
 in the Roach draft. The fundamental difference is an OLR could combine mul=
tiple scopes (e.g. "new session for realm Foo at host A"  , but can only ha=
ve one type. (e.g. "realm foo" or "host a".)

>=20
> Steve
>=20
>=20
> On 2/25/14 12:51 PM, Ben Campbell wrote:
>> I think that both models are reasonable deployments. Our definitions of =
HRR and RRR should support both approaches. I say this with the caveat that=
, if a server sends an RRR report, it is claiming authoritative knowledge o=
f all servers in the realm.
>>=20
>> Agents sending reports to clients can take _any_ input they want to. Tha=
t could be host reports from servers, RRR reports from servers, Diameter er=
rors, transport errors, and any number of proprietary methods.
>>=20
>> On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich)=20
>> 
>>  wrote:
>>=20
>>=20
>>> My understanding is that RRR reports are always aggregated reports. Age=
nts generating an RRR report (for use on the DOIC association towards the r=
eacting node) take as an input the host-type reports received on the DOIC a=
ssociations with the servers.
>>> =20
>>> Ulrich
>>> =20
>>> From: ext Steve Donovan [
>>> mailto:srdonovan@usdonovans.com
>>> ]
>>> Sent: Tuesday, February 25, 2014 2:12 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome;=20
>>> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload=20
>>> report type
>>> =20
>>> How do agents learn about a set of servers ability to handle new sessio=
ns (host-less requests) if servers never sent realm-routed-request reports?
>>>=20
>>> I agree that agents should sent to aggregated report but the servers ne=
ed to send RRR reports so the agent can route around them and generate thos=
e aggregated reports.
>>>=20
>>> Steve
>>>=20
>>> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Hi,
>>> I agree with MCruz.
>>> =20
>>> Principle is that the server never sends OLRs with a report type of rea=
lm-routed-request (exept the case where the server knows (i.e.is configured=
) that there is no other server in that realm).
>>> =20
>>> Only agents that are configured to take the role of a reporting node fo=
r a realm will insert OLRs with report type of realm-routed-requests into a=
nswer messages and the content should be the aggregation of percentages as =
received in host type OLRs from all the servers in the realm.
>>> =20
>>> Ulrich
>>> =20
>>> =20
>>> =20
>>> =20
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of ext Steve Donovan
>>> Sent: Monday, February 24, 2014 8:31 PM
>>> To: Maria Cruz Bartolome;
>>> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload=20
>>> report type
>>> =20
>>> Maria Cruz,
>>>=20
>>> Thanks for the comments.  We obviously have a different understanding o=
f the meaning of realm-routed-request report (new attempt at a name to try =
to make Ulrich happy :-) ).
>>>=20
>>> My definition is that it is a report generated by the server when the s=
erver does not want to receive new sessions. =20
>>>=20
>>> Your definition appears to be that it is a report generated by an agent=
 (or a server is there are no agents in the network?) to indicate that the =
network need to handle fewer new sessions.
>>>=20
>>> I actually think both cases apply but I don't think that an agent can g=
enerate a realm-routed-request report without knowing the status of servers=
 and their ability to handle new Diameter sessions.
>>>=20
>>> Note that I'm discussing this in the context of session-based applicati=
ons.  This could also be applied to pseudo session based applications and a=
pplications that always rely on realm routed requests.
>>>=20
>>> Everyone, which definition applies?
>>>=20
>>> Steve
>>>=20
>>> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>>> Steve,
>>> =20
>>> See some comments below please.
>>> /MCruz
>>> =20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of dime issue tracker
>>> Sent: lunes, 24 de febrero de 2014 17:20
>>> To:=20
>>> draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
>>>=20
>>> Cc:=20
>>> dime@ietf.org
>>>=20
>>> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload=20
>>> report type
>>> =20
>>> #57: Handling of "Realm-Routed" Overload report type
>>> =20
>>>  I'm assuming the name of the realm overload report in the -01=20
>>> version will  be changed to realm-routed.  This issue applies=20
>>> independent of the actual  name of the report.
>>> =20
>>>  The current behavior assumed for the realm-routed report is that=20
>>> the  reacting node, generally the client, will reduce the percentage=20
>>> of realm  routed requests sent to the reporting node.
>>> =20
>>>  This is actually bad behavior and could result in the client=20
>>> throttling  traffic that could have been handled by the full set of=20
>>> servers for that  Diameter application.
>>> [MCruz] This can only happen if the agent has miscalculated the realm o=
verload.
>>> =20
>>>  Consider the case where there are n servers for a Diameter=20
>>> application and  all of those server are able to handle any=20
>>> transaction for that  application.
>>> =20
>>>  When one of those servers becomes overloaded and wishes to decrease=20
>>> the  number of new sessions, the primary use of realm-routed=20
>>> requests.  The  server will generate an OLR of type realm-routed.
>>> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>>> =20
>>>  Assume in this case that the other servers are all healthy and able=20
>>> to  handle new sessions.
>>> =20
>>>  Clients will not have the knowledge that there are other servers in=20
>>> the  network able to handle the new session and will have no choice=20
>>> but the  throttle a percentage of the new session requests.  Even=20
>>> when these  throttled requests could have been handled by any of the=20
>>> non overloaded  servers.
>>> =20
>>>  The proposal is to specify that realm-routed reports must be=20
>>> handled by  DOIC-supporting agents.  Agents will understand if there=20
>>> are other servers  able to handle the new session and, if so, can=20
>>> adjust the percentage of  requests routed to the overloaded server.
>>> =20
>>>  Agents that handle the realm-routed OLR must remove the request=20
>>> from the  answer before relaying the answer to client.  This=20
>>> prevents the report  from being acted on by either multiple agents=20
>>> (if multiple are in the
>>>  path) or by an agent and a client.
>>> =20
>>>  Clients that receive the realm-routed OLR must handle the OLR by =20
>>> throttling the requested percentage.
>>> =20
>>> =20
>>> =20
>>>=20
>>=20
>=20

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


From nobody Wed Feb 26 03:23:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1863E1A0277 for ; Wed, 26 Feb 2014 03:23:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuhXQyi0FOwp for ; Wed, 26 Feb 2014 03:23:11 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BA30F1A027C for ; Wed, 26 Feb 2014 03:23:05 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QBMva1031401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 12:22:57 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QBMsTU011461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 12:22:57 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 12:22:55 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 12:22:55 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAABdR0aQAC5d2AAAC4oAAAAFtYgAAAPiMAAADxZgAAHM0YAAAuChOAAAj34gA=
Date: Wed, 26 Feb 2014 11:22:55 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4999DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 127046
X-purgate-ID: 151667::1393413777-00005322-DE2E713F/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Azw3MrWp-fUg79fBNcuXFoX9_KQ
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 11:23:26 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4999DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi JJacques,

thank you for the summary.

I think it does not matter whether we call

A)      "OLR per client" the base solution and "OLR for all clients" the op=
timization or

B)      "OLR for all clients" the base solution and "OLR per client" the (3=
GPP) extension
as long as we cover both.

I don't think there are impacts on sequence number handling, report types o=
r DOIC associations.

My proposal then is to add a new mandatory AVP of type enumerated to OC-OLR=
 with values

(0)    OLR per client

(1)    OLR for all clients

Reporting nodes that better like A) could allways send (0) unless they supp=
ort the "optimization" and want to use it;
Reporting nodes that better like B) could allways send (1) unless they supp=
ort the "(3GPP) extension" and want to use it.
Clients can safely ignore the new AVP.
Agents taking the role of the reacting node on behalf of a client must do t=
he binding when receiving (0).

We also need to say something on interactions e.g.:
A fresh OLR of type (1) makes all old OLRs of any type invalid
A fresh OLR of type (0) makes an old OLR of type (0) bound to the same clie=
nt invalid
A fresh OLR of type (0) makes an old OLR of type (1) invalid

(i.e. change of type is allowed, mixture is not allowed)

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Wednesday, February 26, 2014 8:07 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Steve, MCruz and all

On my side,  I agree with Lionel.

I  have not the  same reading of the draft where I have  not found the Stev=
e's default case.
I agree with Lionel that the OLR for a DOIC association relates to this DOI=
C association  and the OLR can be different  for another DOIC association. =
The basic (or "default") principle is that each DOIC association has its "o=
wn life".

Then,  a server (local policy) can decide  to send  the same OLR to all its=
 clients (so for all its DOIC associations) , or it can define  particular =
OLR values for   certain clients.
Another  interest  is that  when the server wants to update the OLR values =
towards  clients, it is  not obliged to send the new values  simultaneously=
  to all the clients : it may  (local server policy) progressively  change =
 the  value  over a certain duration  to minimize  sharp transitions.

So for DOIC supporting clients, the current text allows these possibilities=
, and in particular it satisfies the 3GGP client mitigation requirement.

A second step is to address DAs supporting non DOIC clients. Over time,  we=
 may expect that clients will be more and more DOIC supporting; so, this is=
 the main target. DAs with non DOIC client would be more for   a transition=
 (to be considered  nevertheless and which may be long).

The current text says that DA is acting on behalf of "A" client; so princip=
le  with host OLR per DOIC association also applies, and there is no differ=
ence for the server, as this does not make a difference  between a DOIC sup=
porting client and a DA supporting non DOIC clients.
Nevertheless, and here I come to Steve's point,   this has a cost implying =
the DA to manage OLRs per client. Steve  introduces an optimization where i=
n fact a set of clients are considered for me as a pool regarding  DOIC whe=
re only one OLR applies and where throttling  applies  to the requests of t=
his  pool of clients.  I am not against to optimization process   but this =
pool concept is new and needs some further study. First about the concept o=
f DOIC association which evolves , as now linked to a pool .

There was a MCruz remark about sequence number, a new AVP or a  new report =
type.  I see that  we may have to review  the processing of the seq number =
 handling as also dependent of the new AVP or the OLR type; so   a "collate=
ral " effect of the optimization. I would also think that, instead of intro=
ducing a single node indication in the OLR (AVP or report type) , it should=
 be a global indication as the optimization   is to support a global DOIC a=
ssociation.  To also see if there are not other collateral effects to analy=
ze.

Ulrich  also mentioned that for realm OLRs we may also have  a different re=
alm  OLR sent to different clients, so this is the same principle as Lionel=
  for  a realm OLR per DOIC association, on which I agree.

The current text due to the DOIC association principle,  allows this realm =
OLR per DOIC association for both  DOIC  supporting clients and  DAs acting=
 on behalf of A client. Then I expect Steve  to do the same remark, with th=
e same reason  to have  an optimization  where all clients receives  the  s=
ame realm OLR, but to also see the collateral effects.

As a conclusion, I think we should remain with the current text as the base=
line, following the DOIC association principle that Lionel mentions, and af=
ter more investigation to assess the  optimization  for host and realm OLRs=
 with DA supporting non DOIC,  this optimization being optional.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 f=E9vrier 2014 10:09
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Yes, I agree with Steve.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange.com; dime@ietf.or=
g
Subject: Re: [Dime] Issue#35 conclusion

Lionel,

The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents.

I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case then t=
here is little benefit (and significant overhead) to requiring an agent to =
maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is the cas=
e then the reporting node should indicate that it only applies to the origi=
n-host in the request and only then should agents be required to maintain s=
tate for the non-supporting client.

Steve
On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:
I really don't understand but it is not the first time :)

What about the DOIC association? What about my assumption about agent maint=
aining overload control state for non-DOIC enabled client?
So for me, the proposal from Ulrich is a clarification on the agent behavio=
r that was implicit if you consider the comments above.

For me, the option for the server is only to send a specific OLR for a spec=
ific client. So over two different DOIC association with the same server/re=
porting node, you can have two different OLRs.
But it does not change the way the OLR is handled by reacting nodes.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Maria Cruz,

To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of the ba=
se specification, as it is likely that most/all applications will want the =
same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origin-Hos=
t reports should be specified in a common way.

Steve
On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
Hello again,

I forgot to mention something else in this thread, that I already mentioned=
 in related thread #56.

This is all in order to take into account 3GPP requirement on overload miti=
gation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".



Therefore, we can even consider this new OLR out of the base draft, and be =
considered by 3GPP applications when required.



Best regards

/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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


___________________________________________________________________________=
______________________________________________



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_5BCBA1FC2B7F0B4C9D935572D9000668151B4999DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi JJacques,



 <=
/p>

thank you =
for the summary.


 =
;


I think it=
 does not matter whether we call


A)    
&n=
bsp;“OLR per client” the base solution and “OLR for all c=
lients” the optimization or


B)     
&#=
8220;OLR for all clients” the base solution and “OLR per client=
” the (3GPP) extension


as long as=
 we cover both.


 =
;


I don̵=
7;t think there are impacts on sequence number handling, report types or DO=
IC associations.


 =
;


My proposa=
l then is to add a new mandatory AVP of type enumerated to OC-OLR with valu=
es


(0)   
OL=
R per client


(1)   
OL=
R for all clients


 =
;


Reporting =
nodes that better like A) could allways send (0) unless they support the &#=
8220;optimization” and want to use it;


Reporting =
nodes that better like B) could allways send (1) unless they support the &#=
8220;(3GPP) extension” and want to use it.


Clients ca=
n safely ignore the new AVP.


Agents tak=
ing the role of the reacting node on behalf of a client must do the binding=
 when receiving (0).


 =
;


We also ne=
ed to say something on interactions e.g.:


A fresh OL=
R of type (1) makes all old OLRs of any type invalid


A fresh OL=
R of type (0) makes an old OLR of type (0) bound to the same client invalid=



A fresh OL=
R of type (0) makes an old OLR of type (1) invalid


 =
;


(i.e. chan=
ge of type is allowed, mixture is not allowed)


 =
;


Ulrich


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Wednesday, February 26, 2014 8:07 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Hi Steve, =
MCruz and all


 =
;


On my side=
,  I agree with Lionel.


 =
;


I  ha=
ve not the  same reading of the draft where I have  not found the=
 Steve’s default case.



I agree wi=
th Lionel that the OLR for a DOIC association relates to this DOIC associat=
ion  and the OLR can be different  for another DOIC association.
 The basic (or “default”) principle is that each DOIC associati=
on has its “own life”.


 =
;


Then, &nbs=
p;a server (local policy) can decide  to send  the same OLR to al=
l its clients (so for all its DOIC associations) , or it can define  p=
articular
 OLR values for   certain clients. 


Another &n=
bsp;interest  is that  when the server wants to update the OLR va=
lues towards  clients, it is  not obliged to send the new values =
 simultaneously
  to all the clients : it may  (local server policy) progressivel=
y  change  the  value  over a certain duration  to=
 minimize  sharp transitions.


 =
;


So for DOI=
C supporting clients, the current text allows these possibilities, and in p=
articular it satisfies the 3GGP client mitigation requirement.


 =
;


A second s=
tep is to address DAs supporting non DOIC clients. Over time,  we may =
expect that clients will be more and more DOIC supporting; so,
 this is the main target. DAs with non DOIC client would be more for  =
 a transition (to be considered  nevertheless and which may be lo=
ng).


 =
;


The curren=
t text says that DA is acting on behalf of “A” client; so princ=
iple  with host OLR per DOIC association also applies, and there is no
 difference for the server, as this does not make a difference  betwee=
n a DOIC supporting client and a DA supporting non DOIC clients.=



Neverthele=
ss, and here I come to Steve’s point,   this has a cost imp=
lying the DA to manage OLRs per client. Steve  introduces an optimizat=
ion
 where in fact a set of clients are considered for me as a pool regarding &=
nbsp;DOIC where only one OLR applies and where throttling  applies &nb=
sp;to the requests of this  pool of clients.  I am not against to=
 optimization process   but this pool concept is new and
 needs some further study. First about the concept of DOIC association whic=
h evolves , as now linked to a pool .


 =
;


There was =
a MCruz remark about sequence number, a new AVP or a  new report type.=
  I see that  we may have to review  the processing of the s=
eq
 number  handling as also dependent of the new AVP or the OLR type; so=
   a “collateral “ effect of the optimization. I woul=
d also think that, instead of introducing a single node indication in the O=
LR (AVP or report type) , it should be a global indication
 as the optimization   is to support a global DOIC association. &=
nbsp;To also see if there are not other collateral effects to analyze.=



 =
;


Ulrich &nb=
sp;also mentioned that for realm OLRs we may also have  a different re=
alm  OLR sent to different clients, so this is the same principle as
 Lionel  for  a realm OLR per DOIC association, on which I agree.=



 =
;


The curren=
t text due to the DOIC association principle,  allows this realm OLR p=
er DOIC association for both  DOIC  supporting clients and  =
DAs
 acting on behalf of A client. Then I expect Steve  to do the same rem=
ark, with the same reason  to have  an optimization  where a=
ll clients receives  the  same realm OLR, but to also see the col=
lateral effects.



 =
;


As a concl=
usion, I think we should remain with the current text as the baseline, foll=
owing the DOIC association principle that Lionel mentions,
 and after more investigation to assess the  optimization  for ho=
st and realm OLRs with DA supporting non DOIC,  this optimization bein=
g optional.


 =
;


Best regar=
ds


 =
;


JJacques



 =
;






De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 25 f=E9vrier 2014 10:09

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Yes, I agr=
ee with Steve.


 


Best regar=
ds


/MCruz


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:24

To: lionel.morand@orange=
.com;
dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion<=
o:p>






 


=
Lionel,



The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents. 




I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case t=
hen there is little benefit (and significant
 overhead) to requiring an agent to maintain state per non-supporting clien=
t.



I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is th=
e case then the reporting node should indicate that it only applies to the =
origin-host in the request and only then
 should agents be required to maintain state for the non-supporting client.=




Steve




On 2/24/14 12:57 PM, 
lionel.morand@orange.com wrote:






I really d=
on't understand but it is not the first time
J


 


What about=
 the DOIC association? What about my assumption about agent maintaining ove=
rload control state for non-DOIC enabled client?


So for me,=
 the proposal from Ulrich is a clarification on the agent behavior that was=
 implicit if you consider the comments above.


 


For me, th=
e option for the server is only to send a specific OLR for a specific clien=
t. So over two different DOIC association with the same server/reporting
 node, you can have two different OLRs.


But it doe=
s not change the way the OLR is handled by reacting nodes.


 


Lionel


 






De&nb=
sp;: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 19:50

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


=
Maria Cruz,



To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of t=
he base specification, as it is likely that most/all applications will want=
 the same behavior.



Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origi=
n-Host reports should be specified in a common way.



Steve




On 2/24/14 12:40 PM, Maria Cruz=
 Bartolome wrote:






Hello again,


 


I forgot to mention something else in this thread, that I already=
 mentioned in related thread #56.


 


This is all in order to take into account 3GPP requirement on ove=
rload mitigation differentiation per client. But this is a server option:


TR 29809 ch. 6.4.7.1 =
states "It may be up to the server/agent implementations to decide whe=
n and whether overload mitigation differentiation per client is
 used".


 


Therefore, we can eve=
n consider this new OLR out of the base draft, and be considered by 3GPP ap=
plications when required.


 


Best regards


/MCruz


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: lunes, 24 de febrero de 2014 19:19

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion<=
o:p>






 


Steve, all=
,




I agree with Steve.


 


However, I=
 would like to share one concern. We need to avoid that existing (if any) h=
ost OLR (“all-client”) in the reacting node is replaced by
 new host OLR (per client).

Host OLR (=
per client) with the new AVP requires that the server uses a new sequence n=
umber, but existing host OLR (all) shall not be replaced,
 on the contrary both Host OLR (all) and new Host OLR (per client) should r=
emain.


In order t=
o achieve this, it could be more convenient to use a dedicated OLR type (ho=
st per client), instead of a new AVP.


 


Let me kno=
w your opinions.


Best regar=
ds


/MCruz


 


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion<=
o:p>






 


=
Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






Is it implicit? 


 


If the agent detects that a client is not supporting DOIC, th=
is agent will have to store the corresponding overload control state on beh=
alf of this client and only this client (saying that other clients may supp=
ort DOIC). I'm assuming then that any agent will have to store somewhere th=
e origin-host of this client. And therefore, I don't see what would be the =
added-value of this AVP saying that this OLR is only for this client.


 


Even if this AVP is present, it would not preclude a reportin=
g node to always put this AVP in every answer, even if the OLR is the same =
for all the clients.


 


Regards,


 


Lionel


 


-----Message d'origine-----<=
/o:p>


De : DiME [mail=
to:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27


=C0 : dime@ietf.org=



Objet : Re: [Dime] Issue#35 conclusion


 


Hello Ulrich,

 


I haven't proposed to limit this to host type OLR, I just wan=
ted to clarify if this is what JJ got in mind.<=
o:p>


 


I agree it could be done as you explained in the example belo=
w, but the open question is whether it is better to add an AVP when OLR is =
just meant for one single client, or on the contrary the agent _always_ nee=
d to bind OLR to one specific client, even if the server simply requires sa=
me OLR for any client. 


 


I think having a new AVP simplifies agent behavior.


 


Best regards

/MCruz


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: lunes, 24 de febrero de 2014 14:19


To: Maria Cruz Bartolome; di=
me@ietf.org


Subject: RE: [Dime] Issue#35 conclusion


 


Hi MCruz,


there is no reason to limit this to host type OLRs.


 


If we have an agent A that is configured to take the role of =
the reporting node for realm-type reports for realm R, A could receive host=
 type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1=
 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% red=
uctin from C2); A then would aggregate these info and return realm type OLR=
s to C1 requesting 20% reduction of traffic from C1 to R, and to C2 request=
ing 30% reduction of traffic from C2 to R.=



 


Best regards

Ulrich


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Monday, February 24, 2014 2:02 PM


To: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


Hello JJ and all,


 


As per email thread, the latest proposal is:


"When an agent takes the role of a reacting node, the ag=
ent needs to bind a received OLR to the origin host of the client that init=
iated the request which corresponds to the answer containing the OLR."=
 


 


An Ulrich comments on this:<=
/o:p>


"This would cover not only the case where an agent takes=
 the role of the reacting node on behalf of a (or several) non supporting c=
lient, but also the case where an agent is configured to take the role of a=
 reporting node (for realm-type reports) towards the client and at the same=
 time the role of a reacting node towards the server."


 


Is your proposal limited to Host-OLR, i.e. Realm OLR is exclu=
ded? 


Best regards

/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: lunes, 24 de febrero de 2014 13:43


To: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


Hi Mcruz and all


 


I think that you are  mixing the case of the DA that is =
the "reporting" node which wants to indicate a realm OLR to clien=
ts, and for which will use various (non standardized ) ways to determine am=
ong which it can reuse the Host-OLR AVPs received from various servers. But=
 in this case, clients receiving realm OLRs are supporting DOIC. 


Here I understand the on going  discussion is about the =
DA behavior when  clients is not supporting DOIC and to reuse the Host=
-OLR received for one client for other clients  .


 


For me I remain on  my previous mail, with a baseline so=
lution. We may always study new extensions, optimizations, but priority sho=
uld be on the baseline.


 


Best regards

 


Jacques 


 


   

 


-----Message d'origine-----<=
/o:p>


De : DiME [mail=
to:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9&n=
bsp;: lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion


 


Hello all,

 


Not sure we all have the same understanding here.


Let me try to explain my concerns.


 


The original 3GPP requirement we want to cover is the need fo=
r a server to reduce traffic for one specific client, i.e. traffic identifi=
ed by "Origin-Host" in the request.


Then, two options are under analysis about whether or not the=
 OLR in the server answer shall be marked:=



 


a) OLR does not need to include anything else Receiver of the=
 answer (and OLR) is the client that sends the request, identified by "=
;Origin-Host" in the request.


Then, as long as the reacting node=3D=3D"Origin-Host&quo=
t;, the expected reduction is performed and requirement fulfilled.


But, when an agent is acting on behalf of a client as the rea=
cting node, then the "Origin-Host" identifies final client, but n=
ot the reacting node.


Then, this is why the proposal is to add following clarificat=
ion about agent behavior (possible clause 5.5):=



"When an agent takes the role of a reacting node, the ag=
ent needs to bind a received OLR to the origin host of the client that init=
iated the request which corresponds to the answer containing the OLR."=



But this will imply that _always_ the reacting node applies t=
his OLR to one specific client, what is not what we need to achieve.=



How will this impact the case where the agent is providing ac=
cess to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. L=
et's consider following example:


- C1 sends a Realm request via Agent, that finally reaches S1=



- S1 answers with OLR (Host:50%).=



- Agent is acting as reacting node on behalf of C1, if it con=
siders this OLR only bind to C1... then... should it consider S1-OLR only a=
s relevant for requests coming from C1? Should agent do not use this S1-OLR=
 to calculate aggregated Realm overload?


In my opinion, in this case it does not make sense to conside=
r OLR was only meant to C1. And this problem could be solved adding explici=
t information, as in b) below.


 


b) OLR needs to be extended (new AVP) that identifies the cli=
ent ("Origin-Host" in the request) from which traffic reduction s=
hall apply.


With this new AVP, reacting node will easy be able to identif=
y when OLR shall be applied to any client or just to the Origin-Host identi=
fied by new AVP.


 


Let me know your opinions please<=
o:p>


Best regards

/MCruz


 


 


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)


Sent: lunes, 24 de febrero de 2014 12:28


To: ext Steve Donovan; dime@=
ietf.org


Subject: Re: [Dime] Issue#35 conclusion


 


Steve,


 


please see inline.


 


Ulrich


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of ext Steve Donovan


Sent: Friday, February 21, 2014 4:53 PM


To: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


Ulrich,


 


I have a couple of concerns with this approach, as currently =
outlined.  


 


First, how do we handle the case where there are multiple DOI=
C supporting agents between the non supporting client and the reporting nod=
e.  This, I guess, is a general question, not just applying to this pr=
oposal.  I suggest we capture in the agent behavior section that is cu=
rrently missing wording indicating that the first supporting agent that rec=
eives the request must be the reacting node for that non-supporting client.=
  Subsequent DOIC supporting agents must not be the reacting node for =
the non-supporting client.

<Ulrich>I fully agree</Ulrich>


 


 


We need to think through the ramifications of having multiple=
 agents being the reacting node for the same non supporting clients, as thi=
s could easily happen in networks where multiple agents are involved in a s=
ingle transaction.  On the surface it doesn't seem to be an issue for =
the loss algorithm, but this might not be the case with other algorithms.


<Ulrich>I agree that this is not an issue for loss; it =
is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)<=
;/Ulrich>


 


My other concern is that this puts a lot of extra onus on the=
 agent even for the case where the reporting node does not want to differen=
tiate overload reports.


<Ulrich> I agree </Ulrich>


To this end I suggest we add an indication in the OLR marking=
 the reports that are specific to just the Origin-Host in the request. =
; Absence of the "single-client-only" AVP would mean that the rep=
ort applies to all clients.  Presence of the AVP would indicate that t=
he OLR applies to the Origin-Host.


<Ulrich>I understand that the proposal is an optimizati=
on for agents. Therefore the semantics of the marking should be reverse: un=
marked OLRs are client specific, marked OLRs indicate that the reporting no=
de does not want to differentiate, and therefore allow agents not to do the=
 binding to the client.</Ulrich>     


 


Steve


On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


Ben,


 


the proposed conclusion was based on comments received so far=
 (from Lionel, Nirav, Steve, MCruz, JJ). <=
/o:p>


Now you seem to address two points:


a) There is no dependency to DOIC support of the client.


To address this I would like to propose rewording of the clar=
ifying text for 5.5. as follows:


 


When an agent takes the role of a reacting node, the agent ne=
eds to bind a received OLR to the origin host of the client that initiated =
the request which corresponds to the answer containing the OLR. 


 


This would cover not only the case where an agent takes the r=
ole of the reacting node on behalf of a (or several) non supporting client,=
 but also the case where an agent is configured to take the role of a repor=
ting node (for realm-type reports) towards the client and at the same time =
the role of a reacting node towards the server.=



 


b) There is no binding of the OLR to the orig-host of the cli=
ent Here I disagree. We have the 3GPP requirement to allow requesting diffe=
rent amount of reduction from different clients, and I think we have 3 opti=
ons:


1. ignore the 3GPP requirement


2. introduce new report types as originally proposed in #35 3=
. introduce the binding between OLR and orig-host of the client.


 


So far I understood that people favoured option 3.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [ma=
ilto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


 


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) =
<ulrich.wiehe@nsn.com> wr=
ote:


 


#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional report types=
. However, we agreed to add clarifying text to clause 5.5 as follows:


 


When an agent received an OLR in response to a request initia=
ted by a client not supporting DOIC, this agent needs to bind the received =
OLR to the origin-host of the client.


 


I do not agree.=



 


You proposal implies that the server's OLR only applies to th=
at client.


<Ulrich>exactly, that was the intention</Ulrich>&=
nbsp; If there's an intervening DOIC agent, then the agent, not the client,=
 is the reacting node from the server's perspective.


<Ulrich> the server's perspective is agnostic. The serv=
er does not know whether it's the client or an agent on the path that takes=
 the role of the reacting node</Ulrich>  But, short of adding an=
 origin-host type, nothing binds the OLR to a particular client, regardless=
 of DOIC support at the clients.


<Ulrich> the binding is always there, regardless of DOI=
C support at the client</Ulrich>


 


 Whether or not the client also supports DOIC doesn't change =
that. For DOIC-supporting clients, the agent has the additional option of r=
educing traffic by asking the clients to reduce traffic (making them reacti=
ng nodes from the perspective of the _agent_, but not the server.)  It=
 doesn't have that option for non-DOIC clients.=



 


_______________________________________________


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


 


_______________________________________________


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


 


_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.

 


_______________________________________________


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




 


_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.



 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4999DEMUMBX014nsnin_--


From nobody Wed Feb 26 04:32:05 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2A1A02E6 for ; Wed, 26 Feb 2014 04:31:59 -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
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 9uzV-eV1P_z8 for ; Wed, 26 Feb 2014 04:31:46 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC7D1A02D1 for ; Wed, 26 Feb 2014 04:31:46 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59379 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIdeG-0004HD-02 for dime@ietf.org; Wed, 26 Feb 2014 04:31:45 -0800
Message-ID: <530DDEAB.20407@usdonovans.com>
Date: Wed, 26 Feb 2014 06:31:39 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------070007020902030002000804"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/faOpksjNi__vrQpJTjYOhM7Rw5Y
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 12:31:59 -0000

This is a multi-part message in MIME format.
--------------070007020902030002000804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

+1
On 2/26/14 5:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Hi JJacques,
>
>  
>
> thank you for the summary.
>
>  
>
> I think it does not matter whether we call
>
> A)      "OLR per client" the base solution and "OLR for all clients"
> the optimization or
>
> B)      "OLR for all clients" the base solution and "OLR per client"
> the (3GPP) extension
>
> as long as we cover both.
>
>  
>
> I don't think there are impacts on sequence number handling, report
> types or DOIC associations.
>
>  
>
> My proposal then is to add a new mandatory AVP of type enumerated to
> OC-OLR with values
>
> (0)    OLR per client
>
> (1)    OLR for all clients
>
>  
>
> Reporting nodes that better like A) could allways send (0) unless they
> support the "optimization" and want to use it;
>
> Reporting nodes that better like B) could allways send (1) unless they
> support the "(3GPP) extension" and want to use it.
>
> Clients can safely ignore the new AVP.
>
> Agents taking the role of the reacting node on behalf of a client must
> do the binding when receiving (0).
>
>  
>
> We also need to say something on interactions e.g.:
>
> A fresh OLR of type (1) makes all old OLRs of any type invalid
>
> A fresh OLR of type (0) makes an old OLR of type (0) bound to the same
> client invalid
>
> A fresh OLR of type (0) makes an old OLR of type (1) invalid
>
>  
>
> (i.e. change of type is allowed, mixture is not allowed)
>
>  
>
> Ulrich
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* Wednesday, February 26, 2014 8:07 AM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Hi Steve, MCruz and all
>
>  
>
> On my side,  I agree with Lionel.
>
>  
>
> I  have not the  same reading of the draft where I have  not found the
> Steve's default case.
>
> I agree with Lionel that the OLR for a DOIC association relates to
> this DOIC association  and the OLR can be different  for another DOIC
> association. The basic (or "default") principle is that each DOIC
> association has its "own life".
>
>  
>
> Then,  a server (local policy) can decide  to send  the same OLR to
> all its clients (so for all its DOIC associations) , or it can define
>  particular OLR values for   certain clients.
>
> Another  interest  is that  when the server wants to update the OLR
> values towards  clients, it is  not obliged to send the new values
>  simultaneously  to all the clients : it may  (local server policy)
> progressively  change  the  value  over a certain duration  to
> minimize  sharp transitions.
>
>  
>
> So for DOIC supporting clients, the current text allows these
> possibilities, and in particular it satisfies the 3GGP client
> mitigation requirement.
>
>  
>
> A second step is to address DAs supporting non DOIC clients. Over
> time,  we may expect that clients will be more and more DOIC
> supporting; so, this is the main target. DAs with non DOIC client
> would be more for   a transition (to be considered  nevertheless and
> which may be long).
>
>  
>
> The current text says that DA is acting on behalf of "A" client; so
> principle  with host OLR per DOIC association also applies, and there
> is no difference for the server, as this does not make a difference
>  between a DOIC supporting client and a DA supporting non DOIC clients.
>
> Nevertheless, and here I come to Steve's point,   this has a cost
> implying the DA to manage OLRs per client. Steve  introduces an
> optimization where in fact a set of clients are considered for me as a
> pool regarding  DOIC where only one OLR applies and where throttling
>  applies  to the requests of this  pool of clients.  I am not against
> to optimization process   but this pool concept is new and needs some
> further study. First about the concept of DOIC association which
> evolves , as now linked to a pool .
>
>  
>
> There was a MCruz remark about sequence number, a new AVP or a  new
> report type.  I see that  we may have to review  the processing of the
> seq number  handling as also dependent of the new AVP or the OLR type;
> so   a "collateral " effect of the optimization. I would also think
> that, instead of introducing a single node indication in the OLR (AVP
> or report type) , it should be a global indication as the optimization
>   is to support a global DOIC association.  To also see if there are
> not other collateral effects to analyze.
>
>  
>
> Ulrich  also mentioned that for realm OLRs we may also have  a
> different realm  OLR sent to different clients, so this is the same
> principle as Lionel  for  a realm OLR per DOIC association, on which I
> agree.
>
>  
>
> The current text due to the DOIC association principle,  allows this
> realm OLR per DOIC association for both  DOIC  supporting clients and
>  DAs acting on behalf of A client. Then I expect Steve  to do the same
> remark, with the same reason  to have  an optimization  where all
> clients receives  the  same realm OLR, but to also see the collateral
> effects.
>
>  
>
> As a conclusion, I think we should remain with the current text as the
> baseline, following the DOIC association principle that Lionel
> mentions, and after more investigation to assess the  optimization 
> for host and realm OLRs with DA supporting non DOIC,  this
> optimization being optional.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 25 février 2014 10:09
> *À :* dime@ietf.org 
> *Objet :* Re: [Dime] Issue#35 conclusion
>
>  
>
> Yes, I agree with Steve.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 20:24
> *To:* lionel.morand@orange.com ;
> dime@ietf.org 
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Lionel,
>
> The question is whether the reporting node is sending the overload
> report per client or it is sending a global overload report that
> applies to all clients. 
>
> I still believe that the default behavior of a reporting node will be
> to have a single overload reduction value for the application and that
> that overload reduction value will apply to all clients.  If this is
> the case then there is little benefit (and significant overhead) to
> requiring an agent to maintain state per non-supporting client.
>
> I also agree that there is value to the reporting node being able to
> have a different reduction value for specific reacting nodes.  If this
> is the case then the reporting node should indicate that it only
> applies to the origin-host in the request and only then should agents
> be required to maintain state for the non-supporting client.
>
> Steve
>
> On 2/24/14 12:57 PM, lionel.morand@orange.com
>  wrote:
>
>     I really don't understand but it is not the first time J
>
>      
>
>     What about the DOIC association? What about my assumption about
>     agent maintaining overload control state for non-DOIC enabled client?
>
>     So for me, the proposal from Ulrich is a clarification on the
>     agent behavior that was implicit if you consider the comments above.
>
>      
>
>     For me, the option for the server is only to send a specific OLR
>     for a specific client. So over two different DOIC association with
>     the same server/reporting node, you can have two different OLRs.
>
>     But it does not change the way the OLR is handled by reacting nodes.
>
>      
>
>     Lionel
>
>      
>
>     *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve
>     Donovan
>     *Envoyé :* lundi 24 février 2014 19:50
>     *À :* dime@ietf.org 
>     *Objet :* Re: [Dime] Issue#35 conclusion
>
>      
>
>     Maria Cruz,
>
>     To the degree possible we should minimize the per application
>     overload logic required.  To this end, it would be better to have
>     this as part of the base specification, as it is likely that
>     most/all applications will want the same behavior.
>
>     Whether a reporting node uses per Origin-Host reports is an
>     implementation detail of the reporting node.  How reacting nodes
>     respond to per Origin-Host reports should be specified in a common
>     way.
>
>     Steve
>
>     On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
>
>         Hello again,
>
>          
>
>         I forgot to mention something else in this thread, that I
>         already mentioned in related thread #56.
>
>          
>
>         This is all in order to take into account 3GPP requirement on
>         overload mitigation differentiation per client. But this is a
>         server option:
>
>         TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent
>         implementations to decide when and whether overload mitigation
>         differentiation per client is used".
>
>          
>
>         Therefore, we can even consider this new OLR out of the base
>         draft, and be considered by 3GPP applications when required.
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *Maria Cruz Bartolome
>         *Sent:* lunes, 24 de febrero de 2014 19:19
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Issue#35 conclusion
>
>          
>
>         Steve, all,
>
>
>         I agree with Steve.
>
>          
>
>         However, I would like to share one concern. We need to avoid
>         that existing (if any) host OLR ("all-client") in the reacting
>         node is replaced by new host OLR (per client).
>
>         Host OLR (per client) with the new AVP requires that the
>         server uses a new sequence number, but existing host OLR (all)
>         shall not be replaced, on the contrary both Host OLR (all) and
>         new Host OLR (per client) should remain.
>
>         In order to achieve this, it could be more convenient to use a
>         dedicated OLR type (host per client), instead of a new AVP.
>
>          
>
>         Let me know your opinions.
>
>         Best regards
>
>         /MCruz
>
>          
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *Steve Donovan
>         *Sent:* lunes, 24 de febrero de 2014 16:56
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Issue#35 conclusion
>
>          
>
>         Adding an AVP to indicate that a report applies just to the
>         Origin-Host in the request is not just an optimization for agents.
>
>         It had been my assumption all along that the default behavior
>         of a reporting node (server) would be to report a single
>         overload value to all reacting nodes, be they clients or
>         agents.  If this is the default behavior then it would be best
>         to have the default, implicit, meaning of an overload report
>         to be "applies to all reacting nodes".  The real value of this
>         new feature is to allow a server to further throttle a
>         specific, overly active, reacting node when then global
>         reduction percentage doesn't do the job.
>
>         In addition, if the normal case is that reporting nodes have a
>         single global reduction percentage then requiring agents to
>         bind an overload report to each non supporting clients pushes
>         a lot of extra work on agents when it adds no value.
>
>         My proposal is the following:
>
>         - Add an optional AVP (call it something like Single-Node???)
>         to overload reports that indicate when an overload report
>         applies to a specific reacting node.
>
>         - Absence of the AVP indicates that the report applies to all
>         reacting nodes (clients and agents acting on behalf of
>         non-DOIC clients).
>
>         - Reporting nodes should only include the Single-Node AVP if
>         the overload report contents are different from the global
>         overload report.
>
>         - DOIC-supporting agents receiving an OLR without the
>         Single-Node AVP must do the following:
>           - For transactions from DOIC-supporting clients the agent
>         must not act on the OLR.
>           - For transactions from non-DOIC-supporting clients the
>         agent must apply the OLR to traffic from the set of non
>         supporting clients.   This implies that when making throttling
>         decisions, the agent does not differentiate which non
>         supporting client originated the request.
>
>         - DOIC-supporting agents receiving an OLR with the Single-Node
>         AVP for a transaction originated by a non supporting client
>         must bind that OLR to that single client.
>
>         Note that the agent behavior is currently something that is
>         missing from the -01 version of the draft.  We will need
>         something like this wording independent of the resolution of
>         this issue.
>
>         Steve
>
>         On 2/24/14 8:06 AM, lionel.morand@orange.com
>          wrote:
>
>             Is it implicit? 
>
>              
>
>             If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.
>
>              
>
>             Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.
>
>              
>
>             Regards,
>
>              
>
>             Lionel
>
>              
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
>
>             Envoyé : lundi 24 février 2014 14:27
>
>             À : dime@ietf.org 
>
>             Objet : Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hello Ulrich,
>
>              
>
>             I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.
>
>              
>
>             I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 
>
>              
>
>             I think having a new AVP simplifies agent behavior.
>
>              
>
>             Best regards
>
>             /MCruz
>
>              
>
>             -----Original Message-----
>
>             From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>
>             Sent: lunes, 24 de febrero de 2014 14:19
>
>             To: Maria Cruz Bartolome; dime@ietf.org 
>
>             Subject: RE: [Dime] Issue#35 conclusion
>
>              
>
>             Hi MCruz,
>
>             there is no reason to limit this to host type OLRs.
>
>              
>
>             If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.
>
>              
>
>             Best regards
>
>             Ulrich
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
>
>             Sent: Monday, February 24, 2014 2:02 PM
>
>             To: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hello JJ and all,
>
>              
>
>             As per email thread, the latest proposal is:
>
>             "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 
>
>              
>
>             An Ulrich comments on this:
>
>             "This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."
>
>              
>
>             Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
>
>             Best regards
>
>             /MCruz
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>             Sent: lunes, 24 de febrero de 2014 13:43
>
>             To: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hi Mcruz and all
>
>              
>
>             I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
>
>             Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .
>
>              
>
>             For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.
>
>              
>
>             Best regards
>
>              
>
>             Jacques 
>
>              
>
>                
>
>              
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org  Objet : Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hello all,
>
>              
>
>             Not sure we all have the same understanding here.
>
>             Let me try to explain my concerns.
>
>              
>
>             The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.
>
>             Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:
>
>              
>
>             a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
>
>             Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
>
>             But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
>
>             Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):
>
>             "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."
>
>             But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.
>
>             How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:
>
>             - C1 sends a Realm request via Agent, that finally reaches S1
>
>             - S1 answers with OLR (Host:50%).
>
>             - Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?
>
>             In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.
>
>              
>
>             b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.
>
>             With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.
>
>              
>
>             Let me know your opinions please
>
>             Best regards
>
>             /MCruz
>
>              
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
>
>             Sent: lunes, 24 de febrero de 2014 12:28
>
>             To: ext Steve Donovan; dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Steve,
>
>              
>
>             please see inline.
>
>              
>
>             Ulrich
>
>              
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>
>             Sent: Friday, February 21, 2014 4:53 PM
>
>             To: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Ulrich,
>
>              
>
>             I have a couple of concerns with this approach, as currently outlined.  
>
>              
>
>             First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.
>
>             I fully agree
>
>              
>
>              
>
>             We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.
>
>             I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)
>
>              
>
>             My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.
>
>              I agree 
>
>             To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.
>
>             I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.     
>
>              
>
>             Steve
>
>             On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>             Ben,
>
>              
>
>             the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
>
>             Now you seem to address two points:
>
>             a) There is no dependency to DOIC support of the client.
>
>             To address this I would like to propose rewording of the clarifying text for 5.5. as follows:
>
>              
>
>             When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 
>
>              
>
>             This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.
>
>              
>
>             b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
>
>             1. ignore the 3GPP requirement
>
>             2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.
>
>              
>
>             So far I understood that people favoured option 3.
>
>              
>
>             See also inline.
>
>              
>
>             Ulrich
>
>              
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: ext Ben Campbell [mailto:ben@nostrum.com]
>
>             Sent: Thursday, February 20, 2014 11:55 PM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>              
>
>             On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)   wrote:
>
>              
>
>             #35: additional report types are proposed
>
>              
>
>             Dear all,
>
>              
>
>             I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>
>              
>
>             When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.
>
>              
>
>             I do not agree.
>
>              
>
>             You proposal implies that the server's OLR only applies to that client.
>
>             exactly, that was the intention  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
>
>              the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>
>              the binding is always there, regardless of DOIC support at the client
>
>              
>
>              Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.
>
>              
>
>             _______________________________________________
>
>             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
>
>              
>
>             _______________________________________________
>
>             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
>
>              
>
>             _________________________________________________________________________________________________________________________
>
>              
>
>             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.
>
>              
>
>             _______________________________________________
>
>             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
>
>      
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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.
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------070007020902030002000804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    
On 2/26/14 5:22 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Hi
            JJacques,
            

        
 

        
thank you for the summary.

        
 

        
I think it does not matter whether we call

        
A)    
               “OLR per client” the base solution and “OLR
            for all clients” the optimization or

        
B)     
              “OLR for all clients” the base solution and
            “OLR per client” the (3GPP) extension

        
as long as we cover both.

        
 

        
I don’t think there are impacts on sequence
            number handling, report types or DOIC associations.

        
 

        
My proposal then is to add a new mandatory AVP
            of type enumerated to OC-OLR with values

        
(0)   
              OLR per client

        
(1)   
              OLR for all clients

        
 

        
Reporting nodes that better like A) could
            allways send (0) unless they support the “optimization” and
            want to use it;

        
Reporting nodes that better like B) could
            allways send (1) unless they support the “(3GPP) extension”
            and want to use it.

        
Clients can safely ignore the new AVP.

        
Agents taking the role of the reacting node on
            behalf of a client must do the binding when receiving (0).

        
 

        
We also need to say something on interactions
            e.g.:

        
A fresh OLR of type (1) makes all old OLRs of
            any type invalid

        
A fresh OLR of type (0) makes an old OLR of
            type (0) bound to the same client invalid

        
A fresh OLR of type (0) makes an old OLR of
            type (1) invalid

        
 

        
(i.e. change of type is allowed, mixture is not
            allowed)

        
 

        
Ulrich

        
 

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: Wednesday, February 26, 2014 8:07 AM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Hi Steve, MCruz and all

        
 

        
On my side,  I agree with Lionel.

        
 

        
I  have not the  same reading of the draft
            where I have  not found the Steve’s default case.
            

        
I agree with Lionel that the OLR for a DOIC
            association relates to this DOIC association  and the OLR
            can be different  for another DOIC association. The basic
            (or “default”) principle is that each DOIC association has
            its “own life”.

        
 

        
Then,  a server (local policy) can decide  to
            send  the same OLR to all its clients (so for all its DOIC
            associations) , or it can define  particular OLR values for
              certain clients. 

        
Another  interest  is that  when the server
            wants to update the OLR values towards  clients, it is  not
            obliged to send the new values  simultaneously  to all the
            clients : it may  (local server policy) progressively
             change  the  value  over a certain duration  to minimize
             sharp transitions.

        
 

        
So for DOIC supporting clients, the current
            text allows these possibilities, and in particular it
            satisfies the 3GGP client mitigation requirement.

        
 

        
A second step is to address DAs supporting non
            DOIC clients. Over time,  we may expect that clients will be
            more and more DOIC supporting; so, this is the main target.
            DAs with non DOIC client would be more for   a transition
            (to be considered  nevertheless and which may be long).

        
 

        
The current text says that DA is acting on
            behalf of “A” client; so principle  with host OLR per DOIC
            association also applies, and there is no difference for the
            server, as this does not make a difference  between a DOIC
            supporting client and a DA supporting non DOIC clients.

        
Nevertheless, and here I come to Steve’s point,
              this has a cost implying the DA to manage OLRs per client.
            Steve  introduces an optimization where in fact a set of
            clients are considered for me as a pool regarding  DOIC
            where only one OLR applies and where throttling  applies  to
            the requests of this  pool of clients.  I am not against to
            optimization process   but this pool concept is new and
            needs some further study. First about the concept of DOIC
            association which evolves , as now linked to a pool .

        
 

        
There was a MCruz remark about sequence number,
            a new AVP or a  new report type.  I see that  we may have to
            review  the processing of the seq number  handling as also
            dependent of the new AVP or the OLR type; so   a “collateral
            “ effect of the optimization. I would also think that,
            instead of introducing a single node indication in the OLR
            (AVP or report type) , it should be a global indication as
            the optimization   is to support a global DOIC association.
             To also see if there are not other collateral effects to
            analyze.

        
 

        
Ulrich  also mentioned that for realm OLRs we
            may also have  a different realm  OLR sent to different
            clients, so this is the same principle as Lionel  for  a
            realm OLR per DOIC association, on which I agree.

        
 

        
The current text due to the DOIC association
            principle,  allows this realm OLR per DOIC association for
            both  DOIC  supporting clients and  DAs acting on behalf of
            A client. Then I expect Steve  to do the same remark, with
            the same reason  to have  an optimization  where all clients
            receives  the  same realm OLR, but to also see the
            collateral effects.
            

        
 

        
As a conclusion, I think we should remain with
            the current text as the baseline, following the DOIC
            association principle that Lionel mentions, and after more
            investigation to assess the  optimization  for host and
            realm OLRs with DA supporting non DOIC,  this optimization
            being optional.

        
 

        
Best regards

        
 

        
JJacques
            

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : mardi 25 février 2014 10:09

                À : dime@ietf.org

                Objet : Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Yes, I agree with Steve.

        
 

        
Best regards

        
/MCruz

        
 

        

          

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

                Sent: lunes, 24 de febrero de 2014 20:24

                To: lionel.morand@orange.com;
                dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Lionel,

            

            The question is whether the reporting node is sending the
            overload report per client or it is sending a global
            overload report that applies to all clients. 
            

            

            I still believe that the default behavior of a reporting
            node will be to have a single overload reduction value for
            the application and that that overload reduction value will
            apply to all clients.  If this is the case then there is
            little benefit (and significant overhead) to requiring an
            agent to maintain state per non-supporting client.

            

            I also agree that there is value to the reporting node being
            able to have a different reduction value for specific
            reacting nodes.  If this is the case then the reporting node
            should indicate that it only applies to the origin-host in
            the request and only then should agents be required to
            maintain state for the non-supporting client.

            

            Steve

        

          
On 2/24/14 12:57 PM, 
                lionel.morand@orange.com wrote:

        

        

          
I really don't understand but it is not the
              first time
            J

          
 

          
What about the DOIC association? What about
              my assumption about agent maintaining overload control
              state for non-DOIC enabled client?

          
So for me, the proposal from Ulrich is a
              clarification on the agent behavior that was implicit if
              you consider the comments above.

          
 

          
For me, the option for the server is only to
              send a specific OLR for a specific client. So over two
              different DOIC association with the same server/reporting
              node, you can have two different OLRs.

          
But it does not change the way the OLR is
              handled by reacting nodes.

          
 

          
Lionel

          
 

          

            

              
De : DiME [mailto:dime-bounces@ietf.org]
                  De la part de Steve Donovan

                  Envoyé : lundi 24 février 2014 19:50

                  À : dime@ietf.org

                  Objet : Re: [Dime] Issue#35 conclusion

            

          

          
 

          
Maria Cruz,

              

              To the degree possible we should minimize the per
              application overload logic required.  To this end, it
              would be better to have this as part of the base
              specification, as it is likely that most/all applications
              will want the same behavior.

              

              Whether a reporting node uses per Origin-Host reports is
              an implementation detail of the reporting node.  How
              reacting nodes respond to per Origin-Host reports should
              be specified in a common way.

              

              Steve

          

            
On 2/24/14 12:40 PM,
                Maria Cruz Bartolome wrote:

          

          

            
Hello
                again,

            
 

            
I
                forgot to mention something else in this thread, that I
                already mentioned in related thread #56.

            
 

            
This
                is all in order to take into account 3GPP requirement on
                overload mitigation differentiation per client. But this
                is a server option:

            
TR 29809 ch. 6.4.7.1 states "It may be up
                to the server/agent implementations to decide when and
                whether overload mitigation differentiation per client
                is used".

            
 

            
Therefore, we can even consider this new
                OLR out of the base draft, and be considered by 3GPP
                applications when required.

            
 

            
Best regards

            
/MCruz

            
 

            

              

                
From: DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of Maria Cruz Bartolome

                    Sent: lunes, 24 de febrero de 2014 19:19

                    To: dime@ietf.org

                    Subject: Re: [Dime] Issue#35 conclusion

              

            

            
 

            
Steve, all,

            


                I agree with Steve.

            
 

            
However, I would like to share one concern.
                We need to avoid that existing (if any) host OLR
                (“all-client”) in the reacting node is replaced by new
                host OLR (per client).

            
Host OLR (per client) with the new AVP
                requires that the server uses a new sequence number, but
                existing host OLR (all) shall not be replaced, on the
                contrary both Host OLR (all) and new Host OLR (per
                client) should remain.

            
In order to achieve this, it could be more
                convenient to use a dedicated OLR type (host per
                client), instead of a new AVP.

            
 

            
Let me know your opinions.

            
Best regards

            
/MCruz

            
 

            
 

            

              

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

                    Sent: lunes, 24 de febrero de 2014 16:56

                    To: dime@ietf.org

                    Subject: Re: [Dime] Issue#35 conclusion

              

            

            
 

            
Adding an AVP to indicate that a report
                applies just to the Origin-Host in the request is not
                just an optimization for agents.

                

                It had been my assumption all along that the default
                behavior of a reporting node (server) would be to report
                a single overload value to all reacting nodes, be they
                clients or agents.  If this is the default behavior then
                it would be best to have the default, implicit, meaning
                of an overload report to be "applies to all reacting
                nodes".  The real value of this new feature is to allow
                a server to further throttle a specific, overly active,
                reacting node when then global reduction percentage
                doesn't do the job.

                

                In addition, if the normal case is that reporting nodes
                have a single global reduction percentage then requiring
                agents to bind an overload report to each non supporting
                clients pushes a lot of extra work on agents when it
                adds no value.

                

                My proposal is the following:

                

                - Add an optional AVP (call it something like
                Single-Node???) to overload reports that indicate when
                an overload report applies to a specific reacting node.

                

                - Absence of the AVP indicates that the report applies
                to all reacting nodes (clients and agents acting on
                behalf of non-DOIC clients).

                

                - Reporting nodes should only include the Single-Node
                AVP if the overload report contents are different from
                the global overload report.

                

                - DOIC-supporting agents receiving an OLR without the
                Single-Node AVP must do the following:

                  - For transactions from DOIC-supporting clients the
                agent must not act on the OLR.

                  - For transactions from non-DOIC-supporting clients
                the agent must apply the OLR to traffic from the set of
                non supporting clients.   This implies that when making
                throttling decisions, the agent does not differentiate
                which non supporting client originated the request.

                

                - DOIC-supporting agents receiving an OLR with the
                Single-Node AVP for a transaction originated by a non
                supporting client must bind that OLR to that single
                client.

                

                Note that the agent behavior is currently something that
                is missing from the -01 version of the draft.  We will
                need something like this wording independent of the
                resolution of this issue.

                

                Steve

            

              
On 2/24/14 8:06
                  AM, 
                    lionel.morand@orange.com wrote:

            

            

              
Is it implicit? 

              
 

              
If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.

              
 

              
Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.

              
 

              
Regards,

              
 

              
Lionel

              
 

              
-----Message d'origine-----

              
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

              
Envoyé : lundi 24 février 2014 14:27

              
À : dime@ietf.org

              
Objet : Re: [Dime] Issue#35 conclusion

              
 

              
Hello Ulrich,

              
 

              
I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.

              
 

              
I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 

              
 

              
I think having a new AVP simplifies agent behavior.

              
 

              
Best regards

              
/MCruz

              
 

              
-----Original Message-----

              
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

              
Sent: lunes, 24 de febrero de 2014 14:19

              
To: Maria Cruz Bartolome; dime@ietf.org

              
Subject: RE: [Dime] Issue#35 conclusion

              
 

              
Hi MCruz,

              
there is no reason to limit this to host type OLRs.

              
 

              
If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

              
 

              
Best regards

              
Ulrich

              
 

              
-----Original Message-----

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome

              
Sent: Monday, February 24, 2014 2:02 PM

              
To: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Hello JJ and all,

              
 

              
As per email thread, the latest proposal is:

              
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 

              
 

              
An Ulrich comments on this:

              
"This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."

              
 

              
Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 

              
Best regards

              
/MCruz

              
 

              
-----Original Message-----

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

              
Sent: lunes, 24 de febrero de 2014 13:43

              
To: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Hi Mcruz and all

              
 

              
I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 

              
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

              
 

              
For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

              
 

              
Best regards

              
 

              
Jacques 

              
 

              
   

              
 

              
-----Message d'origine-----

              
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion

              
 

              
Hello all,

              
 

              
Not sure we all have the same understanding here.

              
Let me try to explain my concerns.

              
 

              
The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.

              
Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:

              
 

              
a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.

              
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.

              
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.

              
Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):

              
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."

              
But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.

              
How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:

              
- C1 sends a Realm request via Agent, that finally reaches S1

              
- S1 answers with OLR (Host:50%).

              
- Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?

              
In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.

              
 

              
b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.

              
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

              
 

              
Let me know your opinions please

              
Best regards

              
/MCruz

              
 

              
 

              
 

              
-----Original Message-----

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

              
Sent: lunes, 24 de febrero de 2014 12:28

              
To: ext Steve Donovan; dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Steve,

              
 

              
please see inline.

              
 

              
Ulrich

              
 

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

              
Sent: Friday, February 21, 2014 4:53 PM

              
To: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Ulrich,

              
 

              
I have a couple of concerns with this approach, as currently outlined.  

              
 

              
First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.

              
<Ulrich>I fully agree</Ulrich>

              
 

              
 

              
We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.

              
<Ulrich>I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>

              
 

              
My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.

              
<Ulrich> I agree </Ulrich>

              
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.

              
<Ulrich>I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

              
 

              
Steve

              
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

              
Ben,

              
 

              
the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 

              
Now you seem to address two points:

              
a) There is no dependency to DOIC support of the client.

              
To address this I would like to propose rewording of the clarifying text for 5.5. as follows:

              
 

              
When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 

              
 

              
This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.

              
 

              
b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:

              
1. ignore the 3GPP requirement

              
2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.

              
 

              
So far I understood that people favoured option 3.

              
 

              
See also inline.

              
 

              
Ulrich

              
 

              
 

              
 

              
-----Original Message-----

              
From: ext Ben Campbell [mailto:ben@nostrum.com]

              
Sent: Thursday, February 20, 2014 11:55 PM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
 

              
On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

              
 

              
#35: additional report types are proposed

              
 

              
Dear all,

              
 

              
I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:

              
 

              
When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

              
 

              
I do not agree.

              
 

              
You proposal implies that the server's OLR only applies to that client.

              
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.

              
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

              
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

              
 

              
 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.

              
 

              
_______________________________________________

              
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

              
 

              
_______________________________________________

              
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

              
 

              
_________________________________________________________________________________________________________________________

              
 

              
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.

              
 

              
_______________________________________________

              
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

          

          
 

          
_________________________________________________________________________________________________________________________

          
 

          
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.

        

        
 

      

      

      

      

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


    

    

  


--------------070007020902030002000804--


From nobody Wed Feb 26 04:35:29 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65E51A02E5 for ; Wed, 26 Feb 2014 04:35:20 -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
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 altj5eqX6k7r for ; Wed, 26 Feb 2014 04:35:19 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E2E421A02A2 for ; Wed, 26 Feb 2014 04:35:18 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59388 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIdhc-0008Eg-LN; Wed, 26 Feb 2014 04:35:16 -0800
Message-ID: <530DDF7B.6070801@usdonovans.com>
Date: Wed, 26 Feb 2014 06:35:07 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  ext Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060506040004060407090904"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dL3JedKg9xwkgO6j2DbRpTv7Ahg
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 12:35:22 -0000

This is a multi-part message in MIME format.
--------------060506040004060407090904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

An OLR is included in every answer message only when the reporting node
is in an overload state.  There are no overload reports when the
reacting node is not overloaded.

Steve

On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben, all,
>
> on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.
>
> On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).
>
> Ulrich
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Tuesday, February 25, 2014 12:02 AM
> To: Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>
>
> On Feb 24, 2014, at 2:12 PM, Steve Donovan  wrote:
>
>> I can see two additional reasons for requiring OC-Supported-Features:
>>
>> 1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.
>>
>> this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.
>>
>> There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.
>>
>> 2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.
>>
>> My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.
> +1 on both points
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------060506040004060407090904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      An OLR is included in every answer message only when the reporting
      node is in an overload state.  There are no overload reports when
      the reacting node is not overloaded.

      

      Steve

      

    
    
On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Steve, Ben, all,

on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.

On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Tuesday, February 25, 2014 12:02 AM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
I can see two additional reasons for requiring OC-Supported-Features:

1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.

this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.

There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.

2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.

My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.


      

      
+1 on both points
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



    

    

  


--------------060506040004060407090904--


From nobody Wed Feb 26 04:35:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5A51A02EE for ; Wed, 26 Feb 2014 04:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwFkTBcLLtno for ; Wed, 26 Feb 2014 04:35:32 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B776D1A02EB for ; Wed, 26 Feb 2014 04:35:31 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QCZTkZ030580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 13:35:29 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QCZTQw020860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 13:35:29 +0100
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 13:35:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 13:35:28 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC Issue Status
Thread-Index: AQHPMgRvZ4sdKrf8W0iuf9I4MThX8prHeUBQ
Date: Wed, 26 Feb 2014 12:35:28 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B49D8@DEMUMBX014.nsn-intra.net>
References: <530C100E.4070607@usdonovans.com>
In-Reply-To: <530C100E.4070607@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/mixed; boundary="_004_5BCBA1FC2B7F0B4C9D935572D9000668151B49D8DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 32621
X-purgate-ID: 151667::1393418129-00005322-C663CC3B/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qL5Fg0E9sluSN7QgOfc3u3LVgtM
Subject: Re: [Dime] DOIC Issue Status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 12:35:37 -0000

--_004_5BCBA1FC2B7F0B4C9D935572D9000668151B49D8DEMUMBX014nsnin_
Content-Type: multipart/alternative;
	boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B49D8DEMUMBX014nsnin_"

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

Steve,

please find some proposed updates attached.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 25, 2014 4:38 AM
To: dime@ietf.org
Subject: [Dime] DOIC Issue Status

All,

My apologies for the flood of messages to the DIME list today.  I was in th=
e process of compiling the attached document.

The document attempts to capture the status of all of the open trouble tick=
ets for the DIOC specification.  It is the first draft so be nice if there =
are obvious errors.

I am compiling this in advance of next weeks DIME working group meeting in =
London.  I hope to have resolved issues updated in a preliminary version of=
 a -02 version of the DOIC draft prior to the DIME meeting.

Please let me know if there is disagreement on the items I have marked as r=
esolved, as I will be making those updates to the DOIC draft first.

It is also possible that some of those I have marked as open can be moved p=
retty quickly to resolved.

Regards,

Steve

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











Steve,


 =
;


please fin=
d some proposed updates attached.


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, February 25, 2014 4:38 AM

To: dime@ietf.org

Subject: [Dime] DOIC Issue Status






 


All,



My apologies for the flood of messages to the DIME list today.  I was =
in the process of compiling the attached document.



The document attempts to capture the status of all of the open trouble tick=
ets for the DIOC specification.  It is the first draft so be nice if t=
here are obvious errors.



I am compiling this in advance of next weeks DIME working group meeting in =
London.  I hope to have resolved issues updated in a preliminary versi=
on of a -02 version of the DOIC draft prior to the DIME meeting.



Please let me know if there is disagreement on the items I have marked as r=
esolved, as I will be making those updates to the DOIC draft first.



It is also possible that some of those I have marked as open can be moved p=
retty quickly to resolved.



Regards,



Steve






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B49D8DEMUMBX014nsnin_--

--_004_5BCBA1FC2B7F0B4C9D935572D9000668151B49D8DEMUMBX014nsnin_
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
	name="DOIC issue status - 140224 UW.docx"
Content-Description: DOIC issue status - 140224 UW.docx
Content-Disposition: attachment;
	filename="DOIC issue status - 140224 UW.docx"; size=19008;
	creation-date="Wed, 26 Feb 2014 11:52:05 GMT";
	modification-date="Wed, 26 Feb 2014 12:30:42 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQA/i3ZBogEAAJUGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0
lU9r20AQxe+Bfgex1yKt00MJxXIOTXJsA3VorpvVyF66/9gZJ/G376wUixAbKYnxRSDE/ObNm8do
fvnsbPEICU3wtTivZqIAr0Nj/KoWd8ub8kIUSMo3ygYPtdgCisvFl7P5chsBC672WIs1UfwhJeo1
OIVViOD5SxuSU8SvaSWj0v/UCuS32ey71METeCopM8Ri/psFJNNAcasS/VKO+0i9QQru3llpCNxt
ChHPK4aK4mdfnQXUQsVojVbE8uWjb960LkPbGg1N0BvHDasBmnmQyAB+zUx5WMNTSA2LdbkWj26e
aTEFDYjsrrPVjryTcAWt2lgqrp/ZnX4hCSx+bOIXoyuu7FzBtYnDkAc6jFs6Zc7g7DhmejN75gxk
p4zfOXQoKN2SkLYWTrCinjvWnnV24ZScxKMjAnnzDTQl5+S9+ewl/jW0vm5b0O8KqsMy21bt1Y5N
2hsNRJzeU1j9Qp6UQHxkQHbP4y9Ch5ls2fLJWaoHC0dveC/nA3pSxBM8/DmZ+6/gY0KGtOuQPmHG
7jjl6gMZl91PZfEfAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJl
bHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfL
T9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+
ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kV
yAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5
x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDYOEzhRQEAAMoEAAAcAAgBd29y
ZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAKyUTU/DMAyG70j8hyp36m3AhtC6XQBpVxiCa5Y6bUSTVLEH7N8TNrZ1H/TUSyS/UV4/sZ2M
p9+2Sj4xkPEuE/20JxJ0yufGFZl4nT9d3YmEWLpcVt5hJlZIYjq5vBg/YyU5HqLS1JREF0eZKJnr
ewBSJVpJqa/RxR3tg5Ucw1BALdWHLBAGvd4QQtNDTA48k1meiTDLY/75qo6Zj7ytUcGT15wqb8Fr
bdTadXToCsSrCunNcPmoNSqm6CdDgZyJk600wgo4z3H9D8eZO25gHrxaWnR85qpAyBwr3GT5U9oQ
Rl0icGwR7muxDmG99tsYBl0ybBqwh9jEben7XaZXS2Jv32PPdyORprBTwTDa1mIMu6TR3vFcLqpG
U3ZSW0luu4SIb+l3ZhuDuVXaEG66RPjCxcvJ82iIWxA4+IEmPwAAAP//AwBQSwMEFAAGAAgAAAAh
AIpochsICgAAbyYAABEAAAB3b3JkL2RvY3VtZW50LnhtbNxY3W7bNhS+H7B3ILSbFphjSf5JbNQu
0jgpChRN4CYrsJuBkWiLiERqJGXHd3uHvcCeZY+yJ9nhj2RJUTM3bYetvXHDn3N4vvPxnI968fI+
S9GGCEk5m3nBke8hwiIeU7aeeTfXF70TD0mFWYxTzsjM2xHpvZx//92L7TTmUZERphCYYHK6gdlE
qXza78soIRmWRzwnDCZXXGRYwZ9i3c+wuCvyXsSzHCt6S1Oqdv3Q98eeM8NnXiHY1JnoZTQSXPKV
0lumfLWiEXE/5Q5xiF+7c+GObDz2BUnhDJzJhOaytJY91RqEmJRGNo8FscnSct02P8RbLPAW8pGl
9thbLuJc8IhICaMLO1lZDPzHfDsAtYlqxyFHaPosT5Jhyiozmh2t/FfJO4Lk9a3vvja1DwSwmAOX
bnm807/qNnU/V8L9573apQRtpxuczrxrfJuS14LGXt9Nf4Cp7cwD3sLuXQ6HwIXi1fRbvOOFquZW
9J7s977l/K607MM/vatvDlF51760pzX8nvHUOgv8yYn10Bge+iNjor06OO4aHp+MjBHrsPSjBLiA
2xgvISZ/eD6YTI51aGboCqju+8HIX4xG5eC1GRuHoX8xNlCqyCATuRAiB5A5MxiyGMX3uAzWLcxL
Jwf6XS7ICheperj8qnZIfZQqosbxzSH1nZ/KHEeQtlwQScSGePMfwgkyeTDZAB4ARLnNjIutM0ID
/38twvnlWe89+bWAokp674rslghEGdKjRZ5zoUjcuyBYFRD9E2IONLeeGHMtgY4+jgIPEmjgni+J
5OmGxB3HhPzU6XM2GCxOJyVD60xpztQdmfv8f7HSYHIZeQ3Pj4dpLoTF8xK6YweWuh48RnNTN/6l
lJ+uBSEx+uu339GSZBySb5jb4vNK8Kyb0ej0p6ujjhhbfJn44avFeRdfmjOP86W5ts665kzdis4E
9CYtY5aYrcl7hYXuFjSGImZLvO1DwH4QCySefp1oarS4Ejzn0qF+nRAkI9BRiK8Q/kjd0CgjKhFG
WhBAs1QCM4kjrW0+Hf1/4vbjYDq0GkEsKM6IgsLHeEwkUglWSNrqhxaXb85QVkgFVTFKixgODyF3
lkcbJkM4TZHQFJSgKRvpaObynMWtTJY31TQofzC+CE3HFLZViobSOHOsICsidPF27dKtLTlTztYd
wQVu9yx9py0yVTN82DeXXch/i+19EH477b3d269pRnpQRbIcgWAFjqItVYnt+Jdvlw26HiZrPqfF
dzGqXhj9YTA8hhee1ZeHFsagURgftDGt5vmdfujVq2movTAoBDPvl9f8FY7urJVy7f62hnaivGK6
LO8nS9/1q3w+Hg2PR1/4KhtHHVd5351bAvuT+nJTILib3xp8XE+4xfvG0a2lXQfvNW/cA1Fes6bm
bU5Da4Huox8O6IZJumYkHg+blddSudXWW/FYMrYGDw+yzHjDjFVSf/7Rca++6mGM3yciriv/ZHx8
6lcXz+XfDdqYPiSEoTVhRGjZ8SM0d0a2SDrphZh9SpjOeUsQ6DRYJnRvZaaDthdGnCl4rYOsgFqk
W6yWBxuQFfDtJ+U4ho6qXyNIcbRNaJQgqhDO85RCBXtmWzNoC7MclsKlVYYTupXrrv78y9Ph/Cw4
HVSPCFObaiylDCqrkWkDXVjgzZ9weAnfpEIf/gMlCdHjMaAy80I/GPb8sBeOr4PBNAymvv+zLRcW
63dckSmgojVUmvKtbOMMooXrz2AAEAQcIPiiZUCkjCqKU8SjqBBGJjidVsEKuMewhoNsgb0OZY2k
Rq3BWqMaoLp0swo92ybN9XDlAAQdwB6L4SdjEbaxEAR5HWFlBCQlkhyEHHSzNUrpHSzsDGAODwW9
xDwLGN9TDDCscMErTVdQrIX+pEdBf6c7BJ8Y1ygnggI2Gsja5m5P3vPGeBck5kPJ59HjAbc17n8D
AAD//+RXXW7jNhC+CqF97W7kfztYG0jspCjQrQ3b7T7T0tgiKpEqScVxn3qHXqBn6VF6kg4pySYd
2zWCDRCgQGJJ/BkOh9983/Dz9lYS/Fcsng+DMBy3WpO7QVA3zaTTOMLBevT3X59vzNP8Svubm468
nuJMqJs8K3XjBNa0SPXL4TOnyVje++eZKZ35mgAnEiJgTxB/RyhR8FsBPALCi2wFkjBFCgUx0YLE
oCHSRBQ6phrUjYQ8pTt1s5agEg5KfXpHG3tXUV74QVVErAk850xiYKc/zhX58vNiSX6aLskK8DQy
MKHHvtUOv2ikGd8QLmK4JsLth9Zg0DsCYKMTTjqdfaMDHX+4hU41+MZiU0flA5GKoN1DyUDMnzov
0eWvtLTw7zab4WM3sBbQHNqJZqW96CuieTsMGuGgb7zTuxyGQfxMg3r1cqCXHFesO79qh8aV/Y48
962T5DlLb1VOI3QpR4yDfIJg9KE9ICdwblK62tvJHbbDTvjudjiKaE5XLGWagSKUc1Fg6mfANckg
SihnKiMcIFYm/y02dSKKTaJfEYFGo/dmEei32+Pw3sTXELGLYnvG9kRG0xz4K/zu9juvxqYDw8su
RiIzYZ9TvoGFplLjVlg8DLomEaxOIL5OA3ImRS4UTW/JdPxxUeS5kBrij49AdYGoJXe/zEhWKG3O
j/EoLWJkFsYJTVNkF2R7pRXSPp450s2E0QxpXpZ0Q1RpzvDPZPrD+BPxob+9df1+4PGR19V5WGF8
GDfuWgNLArJMarnQuxRwzBNNh8G4igCskfoQhRUDVGPrdeped6ELOuoH3WUFv8dFjA24Rzj+2JNE
d53pw1GOlgkqK8vy1GSeTqjGHyApW4NmGRiBMN/n8xNno1jjwWAEtaRcGZkQ/JQEV9RkHv8/Fk+p
0nPgsdHTGd3APQrqr/aIz6TTh07DBznGDQu0KogHlj9SsPfJ76cZAZO/TvxX8OFb8vjgsXvfmZzj
8ZoEjkmy55LkS5o/x1L1NJelGmGr+9j8xixlF0IAYfZdB6ZvJDmXo1lywehuI1HgyT9//HlSP6x8
2PL0vHxgsaAU5tZBRqiVC1c+TPl6ipyOLj6+yy6r+j2XCdsf+5+E7Q93TRvCPoe6/gvU4WVJFWBD
uUyQcMzlSWmGOiuw9CAxU1GhFLI0wb+tuXkJvGCVTH86U412G51wZZurLepzHXI/pr63B0GufX1z
qNuFTkDd0GcJf71KTVQ9gfUvDe6p+z3u0byU6cmk0Ws2avJwrfg9l634YHCt+D3WStVkfVF4OZ5J
N8L+hAX2m2tTtSUbhM3id5xgLkCdfttWxwm+N5vlu5AMy7JhkFIeKywFbE2Eodt8oWYdLXIc3A/t
PMmwKsfPdjl1JbQW2aE7hbXTmwBFQRwGvaaduxYCS77956bQ9jMsAR6JVOFq1UXITLHbjUX0vWSm
4ksZhxnTEbre6tpePO0yGpbwViLe2RecUpgqd/QvAAAA//8DAFBLAwQUAAYACAAAACEAIDSSulMC
AACoCQAAEQAAAHdvcmQvY29tbWVudHMueG1s5FZLb5tAEL5X6n9YkbPNgo2dUOOosmuptypxFKm3
NQxmFdhFu2uI/31neTh9WCnOLe0FxDy+mZ3v2xGL2+ciJxUozaWIHG9MHQIilgkX+8h52G5G1w7R
homE5VJA5BxBO7fLjx8WdRjLogBhNEEIocMKvZkxZei6Os6gYHosSxDoTKUqmMFPtXcLpp4O5Qhz
S2b4jufcHF2f0pnTwcjIOSgRdhCjgsdKapkamxLKNOUxdK8+Qw2p22auZXywPTcVXQU59iCFznip
e7TirWh4xKwHqV47RFXkfVxdDqmWKFYjH0Xetl1LlZRKxqA1Wtet84To0ddqdwO0EKeMIS38WrPv
pGBcnGCsOn7j/0TeGMlz29quhXo5CM5i+aIlUoc8iRwUYR2yg8kkcvuQKx5n5JFDBtaeMIOVfOpN
R9Qf+bOtNwnpdUjpd+vlghvOco15jw1yiUZUd3KHsNSjk9nGt3GNaQ0pO+TmJ4/tpfymmte9OeaA
oRXLI2fVin0Lz8Zxlwv3FNbEqjZFnUu5gxQU3ino8rpYJoQ0jfwwoEVsofrmbFfBJlitps05zPIr
MRkXT/apScwE2QFRUMgKEpJhCcI04YZYJ9oUWndHcjW9IXh7yVXg2aZN0zoWsgdonsiMvRF/kuBd
RoIfBvNhJHyZBdN5cI6EzvNuSMBRC1kjCVrmyMKFA8aVd5nK/dnAAa+8z5ObswNuPe9pwGyvAJJP
RAO8QcTzS2fs+cNm/O9sEhSxFfDl+sU/g8v0+1/MdvBintC/7Atc0d1y1ssfAAAA//8DAFBLAwQU
AAYACAAAACEAIVqihCEHAADbHQAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/Ed
RnsvsRMnTaI6VezYDbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXe
zOyud+Jxk5QAFTSH1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTC
jKekGUyIDK5uvPvOFbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzW
aisLCaZpgFKcgNpbwyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8c
qQAxLBW8aAY18xcsbFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde
6jMAHIbgqbWlqrPRXa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28
AVn88gy+0dpst1ccvAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbp
KYY8VfNyLcH3uOgCQAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX3
8tl3L589Qcf3nx7f//H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYH
QvlMzXn+xeNfnz5+/uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZ
PPo7KnbQNyeYYQ+uRVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kY
V3F7GB/45m7j1IlvZ5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp
04GTTVOhbZpAXCY+AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcR
YRXXkQoiPSKMo05EpPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+
pChGu1z54DvcrRD9DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f
1bgT6Nu54xfXuKFVPv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn
4D/fnOfV88W35GkXhgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCB
gxsJbGSQ4OpDquJejDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4a
pRpj1cgcaIuJlrSCs062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX
4Myvp4bDDmYk0rzbGBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJif
P2ckuVAwJRkET1YTS6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e
82dVHW4u5hSMU8aZkGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpq
sCsjmjv7mHdCPlZE9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb
6quZouIs3PST0gbzVDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtl
MQ27AtZ90zsgW+B6Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZ
rshkVMVcmVmzB+SAsL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxO
ndhL6Pwt+C9NLFf36epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1
GAbL/UwGV0BI/wPrHxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZ
KxbrC96olvOeIFtbdpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INA
b8GV/5jZT1MygydTB9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lW
Ci75Dg2uYI7Xona1LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x7
8jkrZfag+MpAvQZl6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgA
AAAhAKeaVTe4AwAArgkAABEAAAB3b3JkL3NldHRpbmdzLnhtbJxW227jNhB9L9B/MPRcx7qQkq2u
s9C1FyTtot6+9I2SaFuIKAokZSf9+g4lcZ2k7GLRJ5NzZs4MOdQcf/j4zLrVhQrZ8n7veHeus6J9
zZu2P+2dPz+X662zkor0Del4T/fOC5XOx/vvv/twjSVVCtzkCih6GfO9M4o+lvWZMiLXrK0Fl/yo
1jVnMT8e25ouP84SIfbOWakh3myWoDs+0B7YjlwwouQdF6fNHJnzemS0VxvfdcONoB1RULA8t4M0
bOz/skGqsyG5fO0QF9YZv6vnfs1zOe6Vi+ZLxLeUpwMGwWsqJdws6+bjMtL2hkZ238Iz3+dDWwki
Xl6R3EPb/uacra7xQEUNFwo9911no4GGHsnYqc+kOig+gMuFQLLIwOeX4Uz76d7/gqdgcOTjObw+
E0FqRcVhIDVUn/FeCd4Zv4b/xlXG2SDgcEsE7IjSqUdJy+KBvPBRQSmbawxvZoHgZTZS++jFH5wr
Q+i6HnZzvGTX6A1xkYei7ZzlHRL5XrQc+B1S4DC0x5Ru7pc2Ns8NwtK3IshNip0V+c+qPYwSlNli
/CBId5EVKbyyQDYkwBijwIagItjZ2fA2SF1rDC5xllnzhNAGVNjyhL7vlqEN2SKUuakN2bl+mlvZ
dmGUuNb+7MowxbmNLfVQgaydS1NU2qvOPC9NExtbFgR5Yu1phqJ8a31VWRRtI2tPs8THofX15l4Q
Jdaq8xSFibW2PPfgZduqLkKMImueIvOSwHqeEnsltr7rMvH9zFpBmeEsnxD4fvWnBV8ti/Vw/STM
qoSZsGLzYMkIq0RLVo96/MJXz+JKPKVtb/CKggzQ18hhrAy4Xs+AZKTrSpg7BoDJOyNNK4ecHifi
7pGI0415ahSLhdUKU/DXL2x6QlLxk+DjMLNeBRl+6Rswm4QeQgtf26uHlhm7HKuDiephCr+Cxr75
/SI04eZ2QddYgXBSfUMPpD+ZWdbQtfkc6k4ctLjSRzIMMGDBpTp5e6drT2flObBVsGuIeJo21clf
MH/CYKexaUNqfTLwXhbaYV6C17K42QJjC242ZGzoZsPGhm+20NhCbQMNoaJr+ycQMbPU9iPvOn6l
zc/GuHf+ZdL3BSKlZSQZFTdS8qmt1QiaMqHyTAYKXdc6Bs+Px5NhETa5usT0GRSPNq2CfzVD2zDy
vHd8F08dXLy7SYbe+Gom7Ty8sa4aogjo59TIN8GThL2rRetr3cJzPbyw6iaLP8zH6lqpDnQABVVc
wIVM0vvjxHz7o3X/DwAAAP//AwBQSwMEFAAGAAgAAAAhAJRSG2ThAAAAVQEAABgAKABjdXN0b21Y
bWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
nJDBasMwDIbvg76D0d2122aZKXFKttTQ69hgV9dxEkNsB9sZG2PvPoeduuNO4pOQvh9Vpw87oXcd
ovGOw25LAWmnfGfcwOH1RWAGKCbpOjl5pzk4D6d6c1d18djJJGPyQV+Stig3TK6XlsMXE+UjE+0D
bop7gQtR7HDztD/jgpUlbQ7nljX0G1BWu3wmchhTmo+ERDVqK+PWz9rlYe+DlSljGIjve6N069Vi
tUtkT2lJ1JL19s1OUK95frefdR9vcY22BPNfy9VcJ+OHIOfxE0hdkT+qlW9eUf8AAAD//wMAUEsD
BBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxz
IKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhM/BigIxDAbgu+A7lNydzngQkel4
WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y2VM00FQ1KIyOeh9HAz/n79UWFIuNvZ0p
ooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwmDJYrShjLZKAcrJQyjzpZd7Uj6nVdb3T+bUD3YapD
byAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4yDaPKAa8YHi3mqrcC7pr9cd/3QsAAP//
AwBQSwMEFAAGAAgAAAAhACsTu7i0CgAAQ1AAAA8AAAB3b3JkL3N0eWxlcy54bWzcXNty2zgSfd+q
/QcW3zOWKFmyU6NMxbK9TpWT8Yyc3WeKgi2OKVJLUkmcr99GA4TAC8iGyKR2Ny+RQACnr6dBmq1f
f/u2i5wvLM3CJF64419GrsPiINmE8fPC/fx4++bCdbLcjzd+lMRs4b6yzP3t3d//9uvXt1n+GrHM
gQ3i7G26cLd5vn97dpYFW7bzs1+SPYvh2lOS7vwcvqbPZ8nTUxiw6yQ47Ficn3mj0ewsZZGfA3i2
DfeZK3f7Stnta5Ju9mkSsCwDaXeR2G/nh7H7DsTbJME1e/IPUZ7xr+lDKr/Kb/jfbRLnmfP1rZ8F
YfgIgoOKuzBO0rv3cRa6cIX5Wf4+C3394o0c49e3fKJ+Ua0Mslzb8CrchO4ZB82+w7IvfrRwvWkx
suRClMYiP34uxlj85vNKF2bhqqE17Ltw/fTN6j3f7Aw1Lf7XNN4r/cWsinnACeCSlXApGI893SfB
C9uscriwcCEscPDzh4c0TNIwf124l5dycMV24V242TAeQcXEeBtu2L+2LP6csc1x/I9bjAe5Y5Ac
4hzsMJujy6Jsc/MtYHseD4AX+9wdn/iCiG+baTgo0CE8SiMGKqg4+O8Cciys3YiyZT6PeQflbwVC
rQ+9gTyuka4A7msl66T/FtP+W5z332LWf4t5/y2A6fp6RMSGFpV0p+ZJIIJPj4nJZUvI8hW1KOpc
UQuazhW1GOlcUQuJzhW1COhcUXN454qafztX1NzZuiLwkbiqUTRBa5AS+zHMI8bXtxLQuCfVyaLg
PPip/5z6+63Dq2BV7DayXB3WOU1UpNPTyXKVp0n83GkRT6TByZx8s9tv/SyE40eH6b2epn/01xFz
/pGGm06ocxF8NZ3wCNFYwh4iP2DbJNqw1Hlk34RHLdZ/SpzV3g+gCnYK19Ot9+HzNndWWyy5nWAz
g9HNlhD734cZ2qA1mWYGVbo2J/lwZohL8+Yf2SY87ArTEE4jM8HnFm6uQKCI7SaachfVk7hTC+4A
igqiXNirgPsT5BfFxX5/7mOK/KIUnbg/QX5RuE7cH+Oj3b/WTHPtpy8OKb3m1rm7TKIkfTpERQ50
0sPcOoMVBE0F6yRW+5NIYm6dwSX6dN4HAdy5UeLU2hdHHrVAsXaHQMFko+ti7ZQK7Y0tNLJ2UAXL
s8Dqx7UWQNak+yf7EvKnRLbFAFlanTU703lisACUINIZ+o9DknefoT0D51FRPsTwuCRjDg1tYsg8
KpqMJ1HvLHzcr/BZAPWrgBZA/UqhBZAhPsxnHlUT6SD9i6MFljUtqyqGYUdm5rk1MysguxIwUN0k
nL8M2WuOhXrdJKBYO6heNwko1t6p1DJVNwlYg9VNApahaph9pHOqjVLWdVMHUicBgkbDkDcBaBjy
JgANQ94EoP7k3Q0yHHkTsKy5QXGqTt4EIJxic6uvgHTyJgBZc4NgO/nMqKh7uEv7ze0A5E1AsXZQ
nbwJKNbeMZE3AQun2ERCBUtRHQFrGPImAA1D3gSgYcibADQMeROAhiFvAlB/8u4GGY68CVjW3KA4
VSdvApA1PSggnbwJQDjFhhsayRuz/oeTNwHF2kF18iagWHunQqjqkErAsnZQBUuRNwELp9gEg8TC
4LZRahjyJmg0DHkTgIYhbwLQMORNAOpP3t0gw5E3AcuaGxSn6uRNALKmBwWkkzcByJobGskbk/GH
kzcBxdpBdfImoFh7p0KoiucIWNYOqmAp8iZgYbz0Jm8CEE45FchGo2HIm6DRMORNABqGvAlA/cm7
G2Q48iZgWXOD4lSdvAlA1vSggHTyJgBZc0MjeWOO/HDyJqBYO6hO3gQUa+9UCFWRNwHL2kEVLEV1
BKxhyJsAhIHZm7wJQDjlBCDMIhs3DUPeBI2GIW8CUH/y7gYZjrwJWNbcoDhVJ28CkDU9KCCdvAlA
1tzA37OF90XJr6eODUFAfc+geKuBDOgZnEQFlAr+yZ5YCm1HrPvtkJ6AhYYWiIbwoKp4lSQvDu3F
7okhQMhQ4ToKE3yl+xXf0tEaESbzlk6Cx9+Xzp1ogKmtw5Aqv3kDPUZ6uxD2NPHGIZAzf91Dy86+
eLOc7watRLwJS7YAYdPYB2gIkm09fDHv84GJ2P4kh/HvthIVP0OD2qaYMxp5N+PbG2yeAllwyw4h
FKxU08N+Ix24aADyhJ3WPrQt/c67kGpixfBuddN4FMYvxXgBs9z6qdjw2NZRzJG9HeVy16H4xXS6
HF2JHaGji2v9wtj+E4iEK/mX+zBmGX7LxOvcALhm0IcHnoGWO7E4OeQgL7v/EhXi4Av/YE65LfTL
8d3Txg45/6+WDjl+0dghV1p57JDjw8cOuTVKv14KLQL+Rmgh5fT2Ynx1zeMKm+uQiqH9Dd+BlC0L
Wn/dTCibfdf663BMa5MzhE8AnvODnKUtMSw7KdTLbdhHUY1oQ7sFqlgPikIH1eom5pVe/oUhc9jn
vMWgRWZsQWhNPgenCMvVBYSuPxTpePvQLKF6XQ8v5+tIxBN8+BDzTIYWT/zTrGCMzTdfbAvXlyyK
PvoYfXmyN0+N2BPPQ9hoPMJjVmWrdZLnyc68PsUuBOMGYGJdGPGVK2G2fXzYrVkqGyiMvMePJ241
SqD5AseFMRVxg/TIP1Srm2UrxfORDoGvU05cNYHu1BUUqcKHjZHfU3YgmxLJj89H1+fnIiwkG5Wo
YAT/bm9lnBaG4q3AEP8gCpgCV5lNolJFmQMjn5/qaubAK6Jzp8keeFmvXfXEgYYeXGlW0iZJrqD5
Gbq2eRiJJMEwkdqDMbLvC1c8DIYaUDTwovmALQ95ImSRKXTSWpVeJ60uku+kxSG0XG/YXcXnZK3F
8n+ethzCCfykm/9/mbFKJzWVBnePH+8fUn5kgNb9nNWzgU9wSjOakkLPh9LhqLJ96yGJXG7KeTW6
HV17khzkiQbSXeSLvy5cz+Of18p9kkE/+1geF2Bi44TxxUSeDk0zvPn0QmSWacZkNpNN/6YZ0/ML
eUYzzTifXnZIOpuOOySdT7wOSS+8aYekYLAOScej0bxD1PHo8rJD1vH4Ego8RpjJJGMPxO2YMplP
u8Sdzs5RXJ7kGC3woe08vHCXySENxSERfwmiNBJAVBUTUHztaCpFKR1NcQwgO+pWqZQHhwxOOSt+
/1W9xaqmMeZZ9eBRS2XnmI7kot+W3cIr9XpoONKY07jxjuRoYEjZ/z4PiJtqr9ny8icnvN4WlyhG
S4sLZcvqd5KNli1+06R0x1b9NZT/w3s9VQWXyY7/TM3xUVE1dfw4TuDnUfiPlUCxlE+wmgrhzzgt
38zOp/PyafnINkVl09lGjHWzTfMRQRoH+8xb7JLzPvQmk5jOBtq+Rx4ik0fDs5Ry1LdaCbr7JUtr
jwsG5uSqflXbyevYwN+XFzQsIzU0H69+ktFaQwueDf/FgvqdspZ1mZzSFGA15fXHdrWLegGTFyX+
T4rCtdABH3l152SgP5xqOQE0qGIKOKmuOeY0mx1tYrbb0BFnZ6DmyFItrFUjqAvoBfjlKvgtK/xI
Zh5TxoAvsaBwRPwAx5SGh+Sq6Fz5UZQkcSOvymvixz2aYt5EqtqmR9eRVTuFVMuPjRfuo79Ndj6/
1ZJntOMAPyTLb6jTMFWLmiFV01QjQ7e5OTfMBV5PEA1r6Oz46fYu4jp79x8AAAD//wMAUEsDBBQA
BgAIAAAAIQBHrekTZwEAALsCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACMkkFrgzAcxe+DfQfJXRN1K0PUwlZ6WqHQlo7dQvJvDdNEkkzb
b7+o1Tm2w47hvfx878V0ealKrwFthJIZCgOCPJBMcSHPGTrs1/4T8oylktNSScjQFQxa5vd3KasT
pjRstapBWwHGcyRpElZnqLC2TjA2rICKmsA5pBNPSlfUuqM+45qyD3oGHBGywBVYyqmluAP69URE
NyRnE7L+1GUP4AxDCRVIa3AYhPjba0FX5s8LvTJzVsJea9fpFnfO5mwQJ/fFiMnYtm3Qxn0Mlz/E
b5vXXV/VF7LbigHKU84SpoFapfOdhQa8lZKqoTLFM6VbsaTGbtzgJwH8+ZofSi1Y4R0FFJDi33p3
RUMjugfL494xHUfcVgtpgecRCR98EvnRYk+ekpgkhLxPzNHkkvbDDHGBe65qMgwzKsf4ZbVfozkv
DJPHaOCNrr6u++oErG6t/kmMpoQjcQTkfeifv1v+BQAA//8DAFBLAwQUAAYACAAAACEAhdp+sJgA
AADoAAAAEwAoAGN1c3RvbVhtbC9pdGVtMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAArI+9CsIwFEZ3wXcIeYCmODiEtlBQJxEhi4NLkt40gfyU5Bbs2xtEfALH73xw
4HSKi7RmDYUI8KARJoGbh54+x/vYPMSVkg+4yVBhZeTiDFpynhy6FCl5BR8LVz21iAtnrGgLQZYm
LRDrZ1IOEuvMM0vGOA2npNcAEdmhbY9MOeVdmrNc7PaV/UU1dOyXNux3bwAAAP//AwBQSwMEFAAG
AAgAAAAhAFPD15ZbAgAA+gcAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzcVb1u2zAQ3gv0HQTujShZ
/kXkIHHtsUPhPgAtUxYBkRRI2YpXZ+/coX2EokMLdMnbGMiaV+iJ+nFtR7CdoUMJCIK+I0939919
vL6557G1okozKXzkXGFkURHIORMLH32aTt71kKVTIuYkloL6aE01uhm+fXOdDUIpUm3BeaEHykdR
miYD29ZBRDnRVzKhAmyhVJyk8KkWtgxDFtD3MlhyKlLbxbhjKxqTFP6tI5ZoVHrLzvGWSTVPlAyo
1hAsjwt/nDCBhmV0VjYQhEPUI8JnihFjSIiQmjpgW5HYR9jFHm7jFjwe7sAbvpGdewgiojRN6424
gEPCWbyuUCU5EYUhYWkQVfiKwP9mMS1Mmi3AsNQz7KMxhuVOJqhAHB95OeLViAtBlavc09pHAuPH
bHH6xg8g4Kc+BeHbBT9HlXh+/P78+NN6+vL56es3U4+DNL3xS2mSZSovyrKMxdlliXu4m6MlUmfp
VEhTltAnxanzs5wyTrX1gWbWR8NPXoZj3l3Dd857G1hv/QPe3duaZeBrBHl1e15Vo7oiuH+a98LP
+RUZkZjBCDRMwMRUwDWzcOkE6IxpfVFvvDwBt6O6NrtKVLVp6g2MXzsB282v7eb39uFhu/nx387B
SC4Vo6qB9S50fh84dw373kX9z+WcqlL4hEynakmn64Qa4dwTwpDd0/mxCuYzDav1lz4USKUGux6o
kOYegC7I/Zw/DVMSgS40lOUOZMErLwQvH4ki+gOdBEkyye5fB68YBgdug3Hd+qUsdHD77lAo3VOy
4GDnpCyU94Ie/gEAAP//AwBQSwMEFAAGAAgAAAAhAKCnyk1uAgAAKCEAABQAAAB3b3JkL3dlYlNl
dHRpbmdzLnhtbOxaXW/TMBR9R+I/VH5nsR1/VksnjQleEEIwfkCauG2kJI5ir2H8em6TAi3rxCKt
2R78VNdfuT4nvvceO5dXP6pytjWtK2ydIHKB0czUmc2Lep2g77cf3ik0cz6t87S0tUnQvXHoavH2
zWU378zym/EeeroZzFK7eZugjffNPIpctjFV6i5sY2poW9m2Sj38bdeRXa2KzNzY7K4ytY8oxiJq
TZl6sMBtisah/WzdU2brbJs3rc2Mc2BIVQ7zVWlRowXYmBdbt/+ddfMiTxAXSmtFcN+8tPn9TbGF
pm1awvJRtOtcpe0ns/K/a/Gf2q/FenOi+tY2D/teW+9t9U89mHOdt7tn+L9jagAWQUf3M0EAPxSa
NAOo+3JmSwuwpnfeDmaUB5aNG7k8smjc2PZw5WOGRj0H/aKH4jEbjEkiMKMk0DHmJTgXHZxhRTUl
OtAxNR2Dr3q/Kcr8eItQprjSWPGek+CbHnjEc20GIqkWEJ5kAP50KDob8JRJKWIZs4D8xMjjmGKJ
haIB+WmR14oqTghTAfhpgScKU8FAEAw5T4iv08VXyGooJTELyD+i9Z4zwA7qy+0TzFNaTDAOPkjK
Id8J0viJgvw5SepFAJwA7A4qpMSYE7FPggIdL0yHxlgzouIgjUcdV51rd2glCeWcB2f1KuggIBw0
gT0y5K/BW03orR49OdJYU6Vo0HITpFeHkZsQzWRMhIqDmJtWzMFpHRdUcCYC8udH/v+SgmDGiWSU
heu2VxKmFadwwRMPMSGE6QnD9CnJTaRgWMQ0Dmnsi+2PvRfbXbqlZWm7L58/wlcAUHvwfcPiFwAA
AP//AwBQSwMEFAAGAAgAAAAhAPksDo7nAQAA5gMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASig
AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPBbtswDL0P2D8YvjeK060tAlnFkGLoYVsD
xG3PmkwnQmVJkNig2dePshtX2XpqTo+PxNPLI82vX3pT7CFE7WxdVrN5WYBVrtV2W5f3zfezq7KI
KG0rjbNQlweI5bX4/Imvg/MQUEMsSMLGutwh+iVjUe2gl3FGbUudzoVeIpVhy1zXaQU3Tj33YJEt
5vMLBi8ItoX2zE+C5ai43ONHRVunkr/40Bw8GRa8gd4biSB+JTtm1jrsOZtY3jiUptE9iDnRU8HX
cgtRLDgbAX90oaW6uuRshHy1k0EqpARFdX5JkxnBv3lvtJJI4YqfWgUXXYfF3RBDkQQ4y0c4RbMB
9Rw0HpKRvOQ/tCUrVcXZiMhbkNsg/S6K82RwqvhGSQMrCkB00kTg7I3gtyDTctdSk2O+x+UeFLpQ
RP2H1rsoi98yQoqtLvcyaGmR4ktjYzFg4yMG0Wg0pE29sR5gPpZj/UWQc5olcDqYyNEDNU7dDS/E
u47+G75jtsrNDh5Gq5mdDE5v/KO6cr2X9iAaeAIDihb4SqTEn+K9b9xNupzXKE/JbP2PGncbL1Va
0teri/wQshbf0L1AS5s9Cr4R/JZiDya9Skdkt9AeZ/5vpNN6GD9bUS1mc/oNt3Tk6CCm70n8BQAA
//8DAFBLAwQUAAYACAAAACEAo197N2AKAADXSgAAGgAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMu
eG1s1Fzbcts4En3fqv0HFt8d62bJVo0yFdvx2FVOxjNydp4pCrK4pgguSVlxvn4bDRDiRRAbIlM1
kxdbJNCnr6dBh61ffv2+CZ03lqQBj2Zu/0PPdVjk82UQvczcb893Z5euk2ZetPRCHrGZ+85S99eP
//7XL7tpmr2HLHVAQJROd7E/c9dZFk/Pz1N/zTZe+mET+AlP+Sr74PPNOV+tAp+d73iyPB/0+j38
LU64z9IU0G686M1LXSVuw2nSNp6fCx70epfnGy+ItIy6RjxmEei74snGy9IPPHmBHcnrNj4DDWMv
CxZBGGTvoF9vrMW8zdxtEk2VVWfaKrFnCgpM3zZhvhjUNq+VHpjKH/mOpGboASXlllvubzcsylC9
84SFoDCP0nUQ7/12qjTwxzpX6ajBBWN3cX9Uw9PuoQT9NvF2EPsceBfXxB1wxlJu2oTSDyKh9mlU
ldjvESIiRGgdKCqUMXNNism3O801+0zaxVCAbQrqt4RvY21VHLST9hC9almCByw0642x1IumpVYC
alwxX3sxc52NP314iXjiLULQCDzuiIx0PwI3Lbl/y1beNsxS8TF5StRH9Ql/3PEoS53d1Ev9IHgG
zgIpmwAE3n+K0sCFO8xLs09p4BVvflbXxP21WFi8qXf6aVYQeB0sA/dcgKY/YNubF87cwSi/ciOU
KF0Lveglv8ais2/zojIzV19agNyZ6yVn809C2Dlamv8sWBxr++WqinuASIBW5pLPwXls9cj9V7ac
Z3Bj5kJPwIvfHp6SgCdAkDP36kpdnLNNcB8sl0y0j3xhtA6W7K81i76lbLm//scdEq+S6PNtlIEf
JmMMWZguP3/3WSw4DfAiT4Tjq9gA7AqOK+CgQttgr428UEHFi//LIfvS2wdR1swTDc9B/Y8CodXb
1kADYVHRAJRrpeuwvYhRexEX7UVAo23ri0l7EXDMaauFzI1CVtKDmnFfJl8xJ4ZXR1JW7KhlUeOO
WtI07qjlSOOOWko07qhlQOOOWsAbd9Ti27ijFs6jO3wPiauaRUP0Bqmwn4MshKbWwHT9llSnmoLz
5CXeS+LFa0d0warax8hyvl1kNFWRTk8ny3mWcHE2bPDIQJbByZz8eROvvTSAI3QTUEvXP4tzivNb
EsBZswHqQiZfzSY8QhxsYU+h57M1D5cscZ7ZdxlRi/1fuTOPPR8P4w3KtQzrY/Cyzhw4womW2+iJ
scHpZk9I+Y9Bij442s3HBlOahJNiODbkpVn4F7YMtpvcNYTTyFjyuUWYKxCo4nEXjUSI6kXcaIUI
AMUE2S7sTUD5BP1lc7GXL2JM0V+2ohPlE/SXjetE+Zgfx+NrzTS38AcTh1ReE+vaveEhT1bbMK+B
RnqYWFewhqCZYF3EWj6JJCbWFVyiT+eT78OTGyVPrWOx51ELFOtwSBQsNrot1kGp0F7fwiLrAFWw
BhZY7bjWAsiadP9kb4H4E7FtM0CW1mfNxnIeGjwALYh0hv5jy7PmM/TAwHlUlIcI/lySMoeGNjRU
HhVN5ZPsdxYxbtf4LIDadUALoHat0ALIkB/mM4/uiXSQ9s3RAsualnUXw7QjM/PEmpk1kF0L6Khv
Es5fhuo150K9bxJQrANU75sEFOvoVHqZ7psErM76JgHL0DXMMSpyqo1R1n2zCKRPAgSLuiFvAlA3
5E0A6oa8CUDtybsZpDvyJmBZc4Pm1CJ5E4Bwic2jvgYqkjcByJobJNupvxnlfQ+lHH+47YC8CSjW
AaqTNwHFOjom8iZg4RKbTKhgaaojYHVD3gSgbsibANQNeROAuiFvAlA35E0Aak/ezSDdkTcBy5ob
NKcWyZsAZE0PGqhI3gQgXGLDDQfJG6v+p5M3AcU6QHXyJqBYR6dCqPqQSsCyDlAFS5M3AQuX2CSD
wsLktjGqG/ImWNQNeROAuiFvAlA35E0Aak/ezSDdkTcBy5obNKcWyZsAZE0PGqhI3gQga244SN5Y
jD+dvAko1gGqkzcBxTo6FULVPEfAsg5QBUuTNwEL86U1eROAcMmpQDYWdUPeBIu6IW8CUDfkTQBq
T97NIN2RNwHLmhs0pxbJmwBkTQ8aqEjeBCBrbjhI3lgjP528CSjWAaqTNwHFOjoVQtXkTcCyDlAF
S1MdAasb8iYAYWK2Jm8CEC45AQiryCZM3ZA3waJuyJsA1J68m0G6I28CljU3aE4tkjcByJoeNFCR
vAlA1twg3rOF90XJr6f2DUlAfc8gf6uBDDgwBIkKqAz8k61YAjOHrPntkJaAuYUWiIb0oJp4zfmr
Q3uxe2hIEDJUsAgDjq90v+NbOoVBhOHkyCTB8+83zr0cgKntw5Qqv3kDM0bFcSGcaRKDQ6Bn9h7D
yE6cv1kupMEokRjCUiNAODH6AANBaqxHbBZzPrAQx5/UZfx/W4UKvwMibmyA0sKVMQOcKiqKz8d8
BtIbCw+Gk34Xs0Y18AjeoD50PQyi1/x6DnOz9hIpcD+8ka9RExzlplYxD2a2UnjVVGkBQ6yj0U3v
WkqEuS1h9Stj8VdQCXeKD49BxFL8lMqXtmH7gsFYK/gfZlflZr7NQF/2+BbmwvG1fnCnEgtTcUJ6
cnAOzvvvkTk4cdM4B1fauZ+DE5f3c3AL1H5xI63wxXufuZaju8v+9a3IHhyhQ8KFITd801ENJhSm
6MbS2PRHYYoOrxWG4Qzp40PkPD9jyZFMVfMS+hU2nJao5q1hqAJNrCdFboMeaJPrSq/4wiVz2mdi
kOCIzjhocLTEHFwiPVdXEGb7UKX9Q8JhDSFAi1DmEPzyEIkk3qnhPskFy++eFAX3b1gYfvEw4zIe
m5eGbCVqDwT1e3iAqoha8CzjG/P+BOcLjALArUVl5EdhhNnf0XazYImaVjAymjh4uNXMgLEKvC4d
qCkZtEfOoXrarFsph/cUCEycCLKqKXSv76BKFQ48mO0tda/yW/+id3txIdNCMVCp/Hvw7+5O5Wbu
KPENAZDzoAq4AneZXaLLQ7sDs12c12ruwDtyJueQP/B2sSvViwVGdXBnmcSLRtoUyTVMosOXMYg0
kkWCaaKsB2ekP2au/DMv8H4+movuA4bcZlzqokropL26vE7anRffSZsDGKZesvtKzMlWy+3/OW07
pBPEqej+fzJjlc5gugzun788PiXimADf9pCxejWIBU5pxaGiKNZD6UBUEX/0YERuMeW66t31bgeK
HNQpBspd1ou3yEMv8l/0x5jDFw1c9dURARYeXNC/HKoToWnFYDK6lJVlWjEcj9U4v2nF6OJSnctM
Ky5GVw2ajkf9Bk0nw0GDppeDUYOm4LAGTfu9HgztY26YjOn3rq4adO33r6DBH5cyAHUblgwnoyZ1
R+MLVFcUOWYL/HLsDDxzb/g2CeTBEL/joXTFh6zKF6D6heOoUqV0HMVrANnQt0qt3N+mcMqZiyer
6sNTtYyxzqoHj1opO/tyJDf9Y9Uto1Lvh4YjjbmMDz6F7B0MJfv3i4B8XB4c9rz6MolBa48rFKOn
5Y2yZ4tPjwc9m39bSekprfo9J//M5zsoMex16cf/AwAA//8DAFBLAQItABQABgAIAAAAIQA/i3ZB
ogEAAJUGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA
AAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAA2wMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA
AAAhANg4TOFFAQAAygQAABwAAAAAAAAAAAAAAAAA/wYAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1s
LnJlbHNQSwECLQAUAAYACAAAACEAimhyGwgKAABvJgAAEQAAAAAAAAAAAAAAAACGCQAAd29yZC9k
b2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAIDSSulMCAACoCQAAEQAAAAAAAAAAAAAAAAC9EwAA
d29yZC9jb21tZW50cy54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFQAAAAAAAAAAAAAA
AAA/FgAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAKeaVTe4AwAArgkAABEA
AAAAAAAAAAAAAAAAkx0AAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAJRSG2ThAAAA
VQEAABgAAAAAAAAAAAAAAAAAeiEAAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBLAQItABQABgAI
AAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAAALkiAABjdXN0b21YbWwvX3JlbHMvaXRlbTEu
eG1sLnJlbHNQSwECLQAUAAYACAAAACEAKxO7uLQKAABDUAAADwAAAAAAAAAAAAAAAAC/JAAAd29y
ZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAEet6RNnAQAAuwIAABEAAAAAAAAAAAAAAAAAoC8A
AGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAIXafrCYAAAA6AAAABMAAAAAAAAAAAAA
AAAAPjIAAGN1c3RvbVhtbC9pdGVtMS54bWxQSwECLQAUAAYACAAAACEAU8PXllsCAAD6BwAAEgAA
AAAAAAAAAAAAAAAvMwAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAKCnyk1uAgAA
KCEAABQAAAAAAAAAAAAAAAAAujUAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAh
APksDo7nAQAA5gMAABAAAAAAAAAAAAAAAAAAWjgAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYA
CAAAACEAo197N2AKAADXSgAAGgAAAAAAAAAAAAAAAAB3OwAAd29yZC9zdHlsZXNXaXRoRWZmZWN0
cy54bWxQSwUGAAAAABAAEAAbBAAAD0YAAAAA

--_004_5BCBA1FC2B7F0B4C9D935572D9000668151B49D8DEMUMBX014nsnin_--


From nobody Wed Feb 26 04:55:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80CD1A02E6 for ; Wed, 26 Feb 2014 04:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4krAGubn4yh0 for ; Wed, 26 Feb 2014 04:55:49 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 203DE1A02B6 for ; Wed, 26 Feb 2014 04:55:47 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-46-530de4528b1f
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 2C.B2.04249.254ED035; Wed, 26 Feb 2014 13:55:46 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 13:55:45 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAACD12qAAAlPFjD///MvAIAAKsaA//1WeSD/+lRuMA==
Date: Wed, 26 Feb 2014 12:55:44 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097867F4@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6C65.8080707@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097867F4ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+JvjW7QE95gg7cdEhZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8rRbvaCHd8YKw4912pg7LvE2MXIySEhYCKxvnEuG4QtJnHh 3nogm4tDSOAIo8SNuxcYIZzFjBILdu9iBaliE7CTuHT6BVMXIweHiICyxOlfDiBhYYFYic2X OsBKRATiJJpOt0DZWRLNX/8ygdgsAqoSV08vBbN5BXwlPjXdh5q/m1Xiwf6fzCAJTqBBB/ce AbMZgS76fmoNWAOzgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WkHskBBQllvfLQZTnSzzd95cF YpegxMmZT1gmMIrMQjJpFpKyWUjKIOJ6EjemTmGDsLUlli18zQxh60rM+HeIBVl8ASP7KkaO 4tTipNx0I4NNjMBYObjlt8UOxst/bQ4xSnOwKInzfnzrHCQkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qBMZ13Y81u3Vd2wQaOV5xl25cmuur1PlC7EdHvV3paYeXLhAitfwHPAu/M2zSnryX9 QojKj+4bGYtZJ1QZHDfYf/xldflk19bmnKYb6mZ2Zh9YFQs7/jZqBNxw+JBVumZu3o1fyQ3T N/zotdHZXbg7I2aT83WeCFGTXYfb7v9ZlTpFMTJTw2SrEktxRqKhFnNRcSIAzBdVu2MCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GRI2KGCPf7jLG-e_QmlKu5SPhlk
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 12:55:57 -0000

--_000_087A34937E64E74E848732CFF8354B92097867F4ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Fine

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 26 de febrero de 2014 8:43
To: dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion

Hi

Remove "from now on" is acceptable for me, but  I have a preference for the=
 reverse wording Lionel proposes, which is shorter and brings the clarifica=
tion I was looking for,:

For example if an OC-Reduction-Percentage value of

 10 has been received, the reacting node which

 would normally send 100 packets MUST only send 90

 packets to the reporting node.


Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 17:00
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

I'm with Lionel.  I don't understand why the proposed wording is confusing.=
  Reacting nodes always only apply the reduction percentage for the period =
of time that the specific overload report is active.  That period either en=
ds when a new overload report is received or when the overload report expir=
es.

That said, I'm happy with just removing the words "from no on" as proposed =
by Lionel below.

Steve

On 2/24/14 7:26 AM, lionel.morand@orange.com wrote:

I don't see the issue, as explained in my mail but OK to remove it.



If "for now" is removed, the resulting text would be:



  For example if the reacting node has been sending

  100 packets per second to the reporting node, then

  a reception of OC-Reduction-Percentage value of 10

  would mean that from now on the reacting node MUST

  only send 90 packets per second.



Maybe it would be even easier to reverse the sentence as follow:



 For example if an OC-Reduction-Percentage value of

 10 has been received, the reacting node which

 would normally send 100 packets MUST only send 90

 packets to the reporting node.





But I'm fine if the initial proposed revised text is kept.



Lionel



De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:13

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



Hello,



I agree with Ulrich's proposal

Cheers

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 10:46

To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion



I share JJacques concern. Replacing "from now on" with "for the period that=
 the overload report is active"

is misleading. May be its better to simply remove "from now on".



Ulrich











From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)

Sent: Friday, February 21, 2014 7:11 PM

To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion



Hi MCruz, Steve



I also agree on the "would send " instead of the "would have sent"  for sur=
e.  But I have  a small concern/ clarification  about the Steve comment on =
  "for the period that the overload report is active" and the example to wh=
ich it refers.



During the time the OLR is active, which may be rather long,  the traffic t=
he reacting node would send may be 100 packet  when it has just received th=
e OLR. A bit later, the traffic it would send could be 120 (or 80), and fro=
m the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  whi=
ch I agree. This is in line  with the every 10th packet dropping  on which =
I also agree.



As the text   would  be written with the Steve modification , we may unders=
tand it is  80 Packet during all the time  the OLR is active. Not yet think=
 to an alternative text, but first to see if you agree with my remark.



JJacques





De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com

Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33

=C0 : Steve Donovan; dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



+1 (including Steve comment)



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



Maria Cruz,



I support your suggested changes.  I have one further suggested change belo=
w.



Steve

On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:

#52: Throttling not needed to be based on previous history



Following agreement is reached:



 Now (chapter 4.7):

    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

    and describes the percentage of the traffic that the sender is

    requested to reduce, compared to what it otherwise would have sent.



 Proposal:

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would send.          =
        <----





 Now (chapter 5.5.2):

      Indicates that the reporting node urges the reacting node to

      reduce its traffic by a given percentage.  For example if the

      reacting node has been sending 100 packets per second to the

      reporting node, then a reception of OC-Reduction-Percentage value

      of 10 would mean that from now on the reacting node MUST only send

      90 packets per second.  How the reacting node achieves the "true

      reduction" transactions leading to the sent request messages is up

      to the implementation.  The reacting node MAY simply drop every

      10th packet from its output queue and let the generic application

      logic try to recover from it.0 < value < 100



  Proposal:

 Indicates that the reporting node urges the reacting node to reduce

 its traffic by a given percentage. For example if the

 reacting node would send 100 packets to the                          <---

 reporting node, then a reception of OC-Reduction-Percentage value of

 10 would mean that from now on the reacting node MUST only send

 90 packets instead of 100. How the reacting node achieves the "true       =
<---

 reduction" transactions leading to the sent request messages is up to

 the implementation. The reacting node MAY simply drop every 10th

 packet from its output queue and let the generic application logic try

 to recover from it.

SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"















_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_087A34937E64E74E848732CFF8354B92097867F4ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Fine

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 26 de febrero de 2014 8:43

To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previo=
us history - conclusion






 


Hi


 <=
/p>

Remove “from now on=
” is acceptable for me, but  I have a preference for the reverse=
 wording Lionel proposes, which is shorter and brings the clarification I
 was looking for,:


For example if an OC-Reduction-Percentage value of 


 10 has been received, the reacting node which 


 would normally send 100 packets MUST only send 90 

 packets to the reporting node.


 <=
/p>

 <=
/p>

Best regards



 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 17:00

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


I'm with Lionel.  I don't understand why the pr=
oposed wording is confusing.  Reacting nodes always only apply the red=
uction percentage for the period of time that the specific overload report =
is active.  That period either ends when a new
 overload report is received or when the overload report expires.



That said, I'm happy with just removing the words "from no on" as=
 proposed by Lionel below.



Steve

 




On 2/24/14 7:26 AM, 
lionel.morand@orange.com wrote:






I don't see the issue, as explained in my mail but OK to remove it. 


 


If "for now" is removed, the resulting text would be:


 


  For example if the reacting node has been sending

  100 packets per second to the reporting node, then

  a reception of OC-Reduction-Percentage value of 10


  would mean that from now on the reacting node MUST

  only send 90 packets per second.


 


Maybe it would be even easier to reverse the sentence as follow:<=
/o:p>


 


 For example if an OC-Reduction-Percentage value of 


 10 has been received, the reacting node which 


 would normally send 100 packets MUST only send 90 

 packets to the reporting node.


 


 


But I'm fine if the initial proposed revised text is kept.<=
/pre>

 


Lionel


 


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:13


=C0 : dime@ietf.org


Objet : Re: [Dime] #52: Throttling not needed to be based on prev=
ious history - conclusion


 


Hello,


 


I agree with Ulrich's proposal


Cheers


/MCruz


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: lunes, 24 de febrero de 2014 10:46


To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org


Subject: Re: [Dime] #52: Throttling not needed to be based on previous=
 history - conclusion


 


I share JJacques concern. Replacing "from now on" with "=
;for the period that the overload report is active"


is misleading. May be its better to simply remove "from now on&qu=
ot;.


 


Ulrich


 


 


 


 


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: Friday, February 21, 2014 7:11 PM


To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous=
 history - conclusion


 


Hi MCruz, Steve


 


I also agree on the "would send " instead of the "would=
 have sent"  for sure.  But I have  a small concern/ cl=
arification  about the Steve comment on   "for the peri=
od that the overload report is active" and the example to which it ref=
ers.


 


During the time the OLR is active, which may be rather long,  the=
 traffic the reacting node would send may be 100 packet  when it has j=
ust received the OLR. A bit later, the traffic it would send could be 120 (=
or 80), and from the OLR definition,   it would send 120x0,9 (or =
80* 0,9) packets, on  which I agree. This is in line  with the ev=
ery 10th packet dropping  on which I also agree. 


  


As the text   would  be written with the Steve modifica=
tion , we may understand it is  80 Packet during all the time  th=
e OLR is active. Not yet think to an alternative text, but first to see if =
you agree with my remark.


 


JJacques 


 


 


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de lionel.morand@orange.com


Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33


=C0 : Steve Donovan; dime@ietf.o=
rg


Objet : Re: [Dime] #52: Throttling not needed to be based on prev=
ious history - conclusion


 


+1 (including Steve comment)


 


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Steve Donovan


Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37


=C0 : dime@ietf.org


Objet : Re: [Dime] #52: Throttling not needed to be based on prev=
ious history - conclusion


 


Maria Cruz,


 


I support your suggested changes.  I have one further suggested c=
hange below.


 


Steve


On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:


#52: Throttling not needed to be based on previous history<=
/pre>

 


Following agreement is reached:


 


 Now (chapter 4.7):


    The OC-Reduction-Percentage AVP (AVP code TBD8) is =
type of Unsigned32


    and describes the percentage of the traffic that th=
e sender is


    requested to reduce, compared to what it otherwise =
would have sent.


 


 Proposal:


   The OC-Reduction-Percentage AVP (AVP code TBD8) is type o=
f Unsigned32  


   and describes the percentage of the traffic that the=
 sender is  


   requested to reduce, compared to what it otherwise w=
ould send.           =
;       <----


 


 


 Now (chapter 5.5.2):


      Indicates that the reporting node urges=
 the reacting node to


      reduce its traffic by a given percentag=
e.  For example if the


      reacting node has been sending 100 pack=
ets per second to the


      reporting node, then a reception of OC-=
Reduction-Percentage value


      of 10 would mean that from now on the r=
eacting node MUST only send


      90 packets per second.  How the re=
acting node achieves the "true


      reduction" transactions leading to=
 the sent request messages is up


      to the implementation.  The reacti=
ng node MAY simply drop every


      10th packet from its output queue and l=
et the generic application


      logic try to recover from it.0 < val=
ue < 100


 


  Proposal:


 Indicates that the reporting node urges the reacting node to reduce <=
o:p>


 its traffic by a given percentage. For example if the=



 reacting node would send 100 packets to the    &n=
bsp;            =
;         <---


 reporting node, then a reception of OC-Reduction-Percentage value of =



 10 would mean that from now on the reacting node MUST only send<=
o:p>


 90 packets instead of 100. How the reacting node achieves the "t=
rue       <---


 reduction" transactions leading to the sent request messages is =
up to 


 the implementation. The reacting node MAY simply drop every 10th=
 


 packet from its output queue and let the generic application log=
ic try 


 to recover from it.


SRD> Replace "from now on" in the above with "for th=
e period that the overload report is active"


 


 


 


 


 


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


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 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.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_087A34937E64E74E848732CFF8354B92097867F4ESESSMB101erics_--


From nobody Wed Feb 26 04:59:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250661A02F5 for ; Wed, 26 Feb 2014 04:59: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
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 8wpXnSVSsVef for ; Wed, 26 Feb 2014 04:59:32 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 902EB1A02E3 for ; Wed, 26 Feb 2014 04:59:32 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59433 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIe5B-0000cO-KX for dime@ietf.org; Wed, 26 Feb 2014 04:59:31 -0800
Message-ID: <530DE531.2060703@usdonovans.com>
Date: Wed, 26 Feb 2014 06:59:29 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net> <530C969C.3060107@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B473F@DEMUMBX014.nsn-intra.net> <59BC706B-A39F-4682-AEAC-AC3808ADECBE@nostrum.com> <530CE90E.9060605@usdonovans.com> <6633436F-4838-4B9D-BA2C-989547F76347@nostrum.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060906050901090303070000"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SNy8v9M3Zyh0KWqpDFBlWwksAvY
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 12:59:35 -0000

This is a multi-part message in MIME format.
--------------060906050901090303070000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I'm ok with taking the feature that allows a server to control the rate
of new session requests into a separate extension draft.  I was
attempting to solve that problem with the RRR report and that doesn't
quite fit.

I'm also OK with leaving the definition of the RRR Ben outlined it in
previous emails.  It is an overload report that is realm wide in scope
and can be sent by any Diameter node that understands the realm overload
status. 

I will admit that I see limited value of the RRRs because the ability to
control realm wide overload with them is different per application and
is complicated.

The better way of controlling the traffic to the realm as a whole is to
support a true realm overload report as proposed in ticket #55.

Steve

On 2/26/14 4:03 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Dear all
>
> About this thread, I am in line with Ulrich and Mcruz comments that realm OLRS are generated  by DOICs DAs dealing with realm, overload.
> Regarding Lionel comment that a server, aware of the overload  of other servers, can generate a realm OLR, in fact in this case  the node supports the server functional entity  and a DA  functional entity addressing realm overload. This is common for implementations to do such integrations (eg in 3GPP) but it does not change the content of a functional entity 
>
> Regarding Steve concern, I think (as Ben) this is a new requirement where server would like to drive the behavior of a client on the type of requests. My current understanding is that the server indicates an overload and then this is to the client (and to the DA acting on realm requests) to decide on what is throttled/rerouted and this is quite application dependent. Personally, I do not yet see the need for such a server requirement. 
>
> So this is a new extension to investigate later (including the requiremnt or this extension)) and outside of our currents scope for the baseline draft.
>
> Best regards
>
> Jacques 
>
>  
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
> Envoyé : mardi 25 février 2014 20:23
> À : Steve Donovan
> Cc : dime@ietf.org
> Objet : Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
>
> On Feb 25, 2014, at 1:03 PM, Steve Donovan  wrote:
>
>> Ben,
>>
>> I'm asserting that there are valid use cases (3GPP PCC for one) for a server sending a RRR that only impacts realm routed requests being sent to that server.  This is different than a RRR that reports on all realm routed requests sent to any server in the realm.
> Then that is something different than they way I expected RRR reports (and I assume others) expected them to be used, and I think it would give incorrect behavior for other use cases. (1)
>
> For example, lets assume a client knows about (either through configuration or dynamic discovery) two next hop destinations (A and B)  that can handle the Foo realm for a given application. It, at least initially, has no idea if those destinations are agents or servers. If that client receives an RRR OLR from A, is it allowed (or even expected)  to shift load to B? My intent for the RRR report type, based on our early discussions of the mixed-state scenario, was no. But I think the way you describe it, the answer would be yes.
>
> I think we are talking about two distinct use cases. One is reporting overload that impacts the entire pool of servers that handle a particular realm+application. Another is is to allow reporting of overload that is created due to some number-of-session constrained resource. I agree both use cases are interesting, and potentially needed. But I don't think a single report type, without further modification, can handle both use cases. 
>
> I also think a single host could be session-constrained, and a pool of servers handling a realm could become session constrained. That suggests we need a way of saying "reduce (new) sessions" that can work for both host and RRR reports. That could be a separate algorithm, or some markup that says "please reduce sessions".  
>
> (1) To some degree, I think we are suffering from our choice to use report-types to distinguish these sort of semantics, rather than the scope concept in the Roach draft. The fundamental difference is an OLR could combine multiple scopes (e.g. "new session for realm Foo at host A"  , but can only have one type. (e.g. "realm foo" or "host a".)
>
>> Steve
>>
>>
>> On 2/25/14 12:51 PM, Ben Campbell wrote:
>>> I think that both models are reasonable deployments. Our definitions of HRR and RRR should support both approaches. I say this with the caveat that, if a server sends an RRR report, it is claiming authoritative knowledge of all servers in the realm.
>>>
>>> Agents sending reports to clients can take _any_ input they want to. That could be host reports from servers, RRR reports from servers, Diameter errors, transport errors, and any number of proprietary methods.
>>>
>>> On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) 
>>> 
>>>  wrote:
>>>
>>>
>>>> My understanding is that RRR reports are always aggregated reports. Agents generating an RRR report (for use on the DOIC association towards the reacting node) take as an input the host-type reports received on the DOIC associations with the servers.
>>>>  
>>>> Ulrich
>>>>  
>>>> From: ext Steve Donovan [
>>>> mailto:srdonovan@usdonovans.com
>>>> ]
>>>> Sent: Tuesday, February 25, 2014 2:12 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; 
>>>> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>>>>
>>>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload 
>>>> report type
>>>>  
>>>> How do agents learn about a set of servers ability to handle new sessions (host-less requests) if servers never sent realm-routed-request reports?
>>>>
>>>> I agree that agents should sent to aggregated report but the servers need to send RRR reports so the agent can route around them and generate those aggregated reports.
>>>>
>>>> Steve
>>>>
>>>> On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Hi,
>>>> I agree with MCruz.
>>>>  
>>>> Principle is that the server never sends OLRs with a report type of realm-routed-request (exept the case where the server knows (i.e.is configured) that there is no other server in that realm).
>>>>  
>>>> Only agents that are configured to take the role of a reporting node for a realm will insert OLRs with report type of realm-routed-requests into answer messages and the content should be the aggregation of percentages as received in host type OLRs from all the servers in the realm.
>>>>  
>>>> Ulrich
>>>>  
>>>>  
>>>>  
>>>>  
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Steve Donovan
>>>> Sent: Monday, February 24, 2014 8:31 PM
>>>> To: Maria Cruz Bartolome;
>>>> dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
>>>>
>>>> Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload 
>>>> report type
>>>>  
>>>> Maria Cruz,
>>>>
>>>> Thanks for the comments.  We obviously have a different understanding of the meaning of realm-routed-request report (new attempt at a name to try to make Ulrich happy :-) ).
>>>>
>>>> My definition is that it is a report generated by the server when the server does not want to receive new sessions.  
>>>>
>>>> Your definition appears to be that it is a report generated by an agent (or a server is there are no agents in the network?) to indicate that the network need to handle fewer new sessions.
>>>>
>>>> I actually think both cases apply but I don't think that an agent can generate a realm-routed-request report without knowing the status of servers and their ability to handle new Diameter sessions.
>>>>
>>>> Note that I'm discussing this in the context of session-based applications.  This could also be applied to pseudo session based applications and applications that always rely on realm routed requests.
>>>>
>>>> Everyone, which definition applies?
>>>>
>>>> Steve
>>>>
>>>> On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
>>>> Steve,
>>>>  
>>>> See some comments below please.
>>>> /MCruz
>>>>  
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of dime issue tracker
>>>> Sent: lunes, 24 de febrero de 2014 17:20
>>>> To: 
>>>> draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
>>>>
>>>> Cc: 
>>>> dime@ietf.org
>>>>
>>>> Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload 
>>>> report type
>>>>  
>>>> #57: Handling of "Realm-Routed" Overload report type
>>>>  
>>>>  I'm assuming the name of the realm overload report in the -01 
>>>> version will  be changed to realm-routed.  This issue applies 
>>>> independent of the actual  name of the report.
>>>>  
>>>>  The current behavior assumed for the realm-routed report is that 
>>>> the  reacting node, generally the client, will reduce the percentage 
>>>> of realm  routed requests sent to the reporting node.
>>>>  
>>>>  This is actually bad behavior and could result in the client 
>>>> throttling  traffic that could have been handled by the full set of 
>>>> servers for that  Diameter application.
>>>> [MCruz] This can only happen if the agent has miscalculated the realm overload.
>>>>  
>>>>  Consider the case where there are n servers for a Diameter 
>>>> application and  all of those server are able to handle any 
>>>> transaction for that  application.
>>>>  
>>>>  When one of those servers becomes overloaded and wishes to decrease 
>>>> the  number of new sessions, the primary use of realm-routed 
>>>> requests.  The  server will generate an OLR of type realm-routed.
>>>> [MCruz] I do not agree. Servers do not generate Realm-routed reports.
>>>>  
>>>>  Assume in this case that the other servers are all healthy and able 
>>>> to  handle new sessions.
>>>>  
>>>>  Clients will not have the knowledge that there are other servers in 
>>>> the  network able to handle the new session and will have no choice 
>>>> but the  throttle a percentage of the new session requests.  Even 
>>>> when these  throttled requests could have been handled by any of the 
>>>> non overloaded  servers.
>>>>  
>>>>  The proposal is to specify that realm-routed reports must be 
>>>> handled by  DOIC-supporting agents.  Agents will understand if there 
>>>> are other servers  able to handle the new session and, if so, can 
>>>> adjust the percentage of  requests routed to the overloaded server.
>>>>  
>>>>  Agents that handle the realm-routed OLR must remove the request 
>>>> from the  answer before relaying the answer to client.  This 
>>>> prevents the report  from being acted on by either multiple agents 
>>>> (if multiple are in the
>>>>  path) or by an agent and a client.
>>>>  
>>>>  Clients that receive the realm-routed OLR must handle the OLR by  
>>>> throttling the requested percentage.
>>>>  
>>>>  
>>>>  
>>>>
> _______________________________________________
> 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
>


--------------060906050901090303070000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I'm ok with taking the
      feature that allows a server to control the rate of new session
      requests into a separate extension draft.  I was attempting to
      solve that problem with the RRR report and that doesn't quite fit.

      

      I'm also OK with leaving the definition of the RRR Ben outlined it
      in previous emails.  It is an overload report that is realm wide
      in scope and can be sent by any Diameter node that understands the
      realm overload status.  

      

      I will admit that I see limited value of the RRRs because the
      ability to control realm wide overload with them is different per
      application and is complicated.

      

      The better way of controlling the traffic to the realm as a whole
      is to support a true realm overload report as proposed in ticket
      #55.

      

      Steve

      

    
    
On 2/26/14 4:03 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
Dear all

About this thread, I am in line with Ulrich and Mcruz comments that realm OLRS are generated  by DOICs DAs dealing with realm, overload.
Regarding Lionel comment that a server, aware of the overload  of other servers, can generate a realm OLR, in fact in this case  the node supports the server functional entity  and a DA  functional entity addressing realm overload. This is common for implementations to do such integrations (eg in 3GPP) but it does not change the content of a functional entity 

Regarding Steve concern, I think (as Ben) this is a new requirement where server would like to drive the behavior of a client on the type of requests. My current understanding is that the server indicates an overload and then this is to the client (and to the DA acting on realm requests) to decide on what is throttled/rerouted and this is quite application dependent. Personally, I do not yet see the need for such a server requirement. 

So this is a new extension to investigate later (including the requiremnt or this extension)) and outside of our currents scope for the baseline draft.

Best regards

Jacques 

 

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mardi 25 février 2014 20:23
À : Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

On Feb 25, 2014, at 1:03 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
Ben,

I'm asserting that there are valid use cases (3GPP PCC for one) for a server sending a RRR that only impacts realm routed requests being sent to that server.  This is different than a RRR that reports on all realm routed requests sent to any server in the realm.


      

      
Then that is something different than they way I expected RRR reports (and I assume others) expected them to be used, and I think it would give incorrect behavior for other use cases. (1)

For example, lets assume a client knows about (either through configuration or dynamic discovery) two next hop destinations (A and B)  that can handle the Foo realm for a given application. It, at least initially, has no idea if those destinations are agents or servers. If that client receives an RRR OLR from A, is it allowed (or even expected)  to shift load to B? My intent for the RRR report type, based on our early discussions of the mixed-state scenario, was no. But I think the way you describe it, the answer would be yes.

I think we are talking about two distinct use cases. One is reporting overload that impacts the entire pool of servers that handle a particular realm+application. Another is is to allow reporting of overload that is created due to some number-of-session constrained resource. I agree both use cases are interesting, and potentially needed. But I don't think a single report type, without further modification, can handle both use cases. 

I also think a single host could be session-constrained, and a pool of servers handling a realm could become session constrained. That suggests we need a way of saying "reduce (new) sessions" that can work for both host and RRR reports. That could be a separate algorithm, or some markup that says "please reduce sessions".  

(1) To some degree, I think we are suffering from our choice to use report-types to distinguish these sort of semantics, rather than the scope concept in the Roach draft. The fundamental difference is an OLR could combine multiple scopes (e.g. "new session for realm Foo at host A"  , but can only have one type. (e.g. "realm foo" or "host a".)



      

        
Steve


On 2/25/14 12:51 PM, Ben Campbell wrote:


        

          
I think that both models are reasonable deployments. Our definitions of HRR and RRR should support both approaches. I say this with the caveat that, if a server sends an RRR report, it is claiming authoritative knowledge of all servers in the realm.

Agents sending reports to clients can take _any_ input they want to. That could be host reports from servers, RRR reports from servers, Diameter errors, transport errors, and any number of proprietary methods.

On Feb 25, 2014, at 8:18 AM, Wiehe, Ulrich (NSN - DE/Munich) 
<ulrich.wiehe@nsn.com>
 wrote:




          

            
My understanding is that RRR reports are always aggregated reports. Agents generating an RRR report (for use on the DOIC association towards the reacting node) take as an input the host-type reports received on the DOIC associations with the servers.
 
Ulrich
 
From: ext Steve Donovan [
mailto:srdonovan@usdonovans.com
]
Sent: Tuesday, February 25, 2014 2:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; 
dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload 
report type
 
How do agents learn about a set of servers ability to handle new sessions (host-less requests) if servers never sent realm-routed-request reports?

I agree that agents should sent to aggregated report but the servers need to send RRR reports so the agent can route around them and generate those aggregated reports.

Steve

On 2/25/14 1:50 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Hi,
I agree with MCruz.
 
Principle is that the server never sends OLRs with a report type of realm-routed-request (exept the case where the server knows (i.e.is configured) that there is no other server in that realm).
 
Only agents that are configured to take the role of a reporting node for a realm will insert OLRs with report type of realm-routed-requests into answer messages and the content should be the aggregation of percentages as received in host type OLRs from all the servers in the realm.
 
Ulrich
 
 
 
 
From: DiME [
mailto:dime-bounces@ietf.org
] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome;
dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org

Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload 
report type
 
Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of the meaning of realm-routed-request report (new attempt at a name to try to make Ulrich happy :-) ).

My definition is that it is a report generated by the server when the server does not want to receive new sessions.  

Your definition appears to be that it is a report generated by an agent (or a server is there are no agents in the network?) to indicate that the network need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can generate a realm-routed-request report without knowing the status of servers and their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based applications.  This could also be applied to pseudo session based applications and applications that always rely on realm routed requests.

Everyone, which definition applies?

Steve

On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:
Steve,
 
See some comments below please.
/MCruz
 
-----Original Message-----
From: DiME [
mailto:dime-bounces@ietf.org
] On Behalf Of dime issue tracker
Sent: lunes, 24 de febrero de 2014 17:20
To: 
draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com

Cc: 
dime@ietf.org

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload 
report type
 
#57: Handling of "Realm-Routed" Overload report type
 
 I'm assuming the name of the realm overload report in the -01 
version will  be changed to realm-routed.  This issue applies 
independent of the actual  name of the report.
 
 The current behavior assumed for the realm-routed report is that 
the  reacting node, generally the client, will reduce the percentage 
of realm  routed requests sent to the reporting node.
 
 This is actually bad behavior and could result in the client 
throttling  traffic that could have been handled by the full set of 
servers for that  Diameter application.
[MCruz] This can only happen if the agent has miscalculated the realm overload.
 
 Consider the case where there are n servers for a Diameter 
application and  all of those server are able to handle any 
transaction for that  application.
 
 When one of those servers becomes overloaded and wishes to decrease 
the  number of new sessions, the primary use of realm-routed 
requests.  The  server will generate an OLR of type realm-routed.
[MCruz] I do not agree. Servers do not generate Realm-routed reports.
 
 Assume in this case that the other servers are all healthy and able 
to  handle new sessions.
 
 Clients will not have the knowledge that there are other servers in 
the  network able to handle the new session and will have no choice 
but the  throttle a percentage of the new session requests.  Even 
when these  throttled requests could have been handled by any of the 
non overloaded  servers.
 
 The proposal is to specify that realm-routed reports must be 
handled by  DOIC-supporting agents.  Agents will understand if there 
are other servers  able to handle the new session and, if so, can 
adjust the percentage of  requests routed to the overloaded server.
 
 Agents that handle the realm-routed OLR must remove the request 
from the  answer before relaying the answer to client.  This 
prevents the report  from being acted on by either multiple agents 
(if multiple are in the
 path) or by an agent and a client.
 
 Clients that receive the realm-routed OLR must handle the OLR by  
throttling the requested percentage.
 
 
 



          

          

        

        

      

      
_______________________________________________
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



    

    

  


--------------060906050901090303070000--


From nobody Wed Feb 26 05:02:14 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625331A02FE for ; Wed, 26 Feb 2014 05:02:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P7XFup_eQKb for ; Wed, 26 Feb 2014 05:01:59 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D20C91A02B6 for ; Wed, 26 Feb 2014 05:01:58 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QD1uje028734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 14:01:56 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QD1sSP014634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 14:01:55 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 14:01:53 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 14:01:53 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , ext Ben Campbell 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7Wrw
Date: Wed, 26 Feb 2014 13:01:53 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com>
In-Reply-To: <530DDF7B.6070801@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4A05DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 14707
X-purgate-ID: 151667::1393419716-00003660-AA32661B/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/egl5w_-oorFO8GDxK0upbBNcXFA
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 13:02:04 -0000

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

Steve,

that is neither correct nor did we agree so.

No OLR means "no change", it does not mean "no overload".
When a reporting node is not in overload, it still is allowed to send OLRs =
(indicating no overload/ end of overload) just to make sure that the reacti=
ng node has up to date information (it needs not do so when it knows that t=
he reacting node already has sufficiently up to date information).

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, February 26, 2014 1:35 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

Ulrich,

An OLR is included in every answer message only when the reporting node is =
in an overload state.  There are no overload reports when the reacting node=
 is not overloaded.

Steve
On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve, Ben, all,



on 1) we seem to agree that OC-Supported-Features in answers is not require=
d for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up=
 to drafts associated with new abatement algorithms to specify the requirem=
ent to include OC-Supported-Features in answers if so needed (I still don't=
 see the need even for rate or other algorithms); that needs to be discusse=
d when discussing those drafts.



On 2) I understand the usecase, but I'm not sure whether we have this requi=
rement of selective proactive throttling (see e-mail from Lionel). Anyway, =
given the conclusion on #31, OLR will be included in all answer messages (e=
xept when the reporting node is aware that the reacting node already knows)=
. Therefore the reacting node can deduce support of DOIC by the reporting n=
ode from the presence of OLR (if OLR is present then DOIC is supported by t=
he reporting node; if OLR is absent, then reacting node already knows wheth=
er or not DOIC is supported by the reporting node).



Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell

Sent: Tuesday, February 25, 2014 12:02 AM

To: Steve Donovan

Cc: dime@ietf.org list

Subject: Re: [Dime] Issue#30 status





On Feb 24, 2014, at 2:12 PM, Steve Donovan  wrote:



I can see two additional reasons for requiring OC-Supported-Features:



1) If the reacting node needs to know in advance whether the type of overlo=
ad abatement the reporting node will ask for.



this is not needed in the case of the loss abatement algorithm as the react=
ing node can just immediately start throttling the appropriate number of re=
quests.  It does not require prior knowledge of the traffic sent.



There are abatement algorithms that do require the client to keep state abo=
ut traffic sent to specific destinations.  We can, if we choose, leave it u=
p to the drafts associated with the new abatement algorithms to specify the=
 requirement to include OC-Supported-Features, as proposed by Ulrich.



2) If the reacting node can use the absence of the OC-Supported-Features AV=
P in answer messages to know that there is no Diameter overload supported i=
n the network and thus take other measures to protect the Diameter network.=
  For example, I can envision a client implementation that adapts to the kn=
owledge of whether servers support overload.  In the case that the server d=
oes support overload the client can send unlimited traffic to the server, u=
p to the point that the server sends an OLR.  If the client determines that=
 the server does not support overload then it might have a configured maxim=
um rate that it will send to the server.



My inclination is to include the OC-Supported-Features AVP in answers becau=
se most abatement algorithms will need it and because it can lead to better=
 implementation client implementations.



+1 on both points

_______________________________________________

DiME mailing list

DiME@ietf.org

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




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











Steve,<=
/p>

 <=
/p>

that is ne=
ither correct nor did we agree so.


 =
;


No OLR mea=
ns “no change”, it does not mean “no overload”.


When a rep=
orting node is not in overload, it still is allowed to send OLRs (indicatin=
g no overload/ end of overload) just to make sure that the
 reacting node has up to date information (it needs not do so when it knows=
 that the reacting node already has sufficiently up to date information).


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Wednesday, February 26, 2014 1:35 PM

To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Issue#30 status






 


Ulrich,



An OLR is included in every answer message only when the reporting node is =
in an overload state.  There are no overload reports when the reacting=
 node is not overloaded.



Steve




On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve, Ben, all,


 


on 1) we seem to agree that OC-Supported-Features in answers is not re=
quired for loss i.e. not required for  draft-ietf-dime-ovli. We can&nb=
sp; leave it up to drafts associated with new abatement algorithms to speci=
fy the requirement to include OC-Supported-Features in answers if so needed=
 (I still don't see the need even for rate or other algorithms); that needs=
 to be discussed when discussing those drafts.


 


On 2) I understand the usecase, but I'm not sure whether we have this =
requirement of selective proactive throttling (see e-mail from Lionel). Any=
way, given the conclusion on #31, OLR will be included in all answer messag=
es (exept when the reporting node is aware that the reacting node already k=
nows). Therefore the reacting node can deduce support of DOIC by the report=
ing node from the presence of OLR (if OLR is present then DOIC is supported=
 by the reporting node; if OLR is absent, then reacting node already knows =
whether or not DOIC is supported by the reporting node).


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Ben Campbell


Sent: Tuesday, February 25, 2014 12:02 AM


To: Steve Donovan


Cc: dime@ietf.org list=



Subject: Re: [Dime] Issue#30 status


 


 


On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




I can see two additional reasons for requiring OC-Supported-Features:<=
o:p>


 


1) If the reacting node needs to know in advance whether the type of o=
verload abatement the reporting node will ask for.


 


this is not needed in the case of the loss abatement algorithm as the =
reacting node can just immediately start throttling the appropriate number =
of requests.  It does not require prior knowledge of the traffic sent.=



 


There are abatement algorithms that do require the client to keep stat=
e about traffic sent to specific destinations.  We can, if we choose, =
leave it up to the drafts associated with the new abatement algorithms to s=
pecify the requirement to include OC-Supported-Features, as proposed by Ulr=
ich.


 


2) If the reacting node can use the absence of the OC-Supported-Featur=
es AVP in answer messages to know that there is no Diameter overload suppor=
ted in the network and thus take other measures to protect the Diameter net=
work.  For example, I can envision a client implementation that adapts=
 to the knowledge of whether servers support overload.  In the case th=
at the server does support overload the client can send unlimited traffic t=
o the server, up to the point that the server sends an OLR.  If the cl=
ient determines that the server does not support overload then it might hav=
e a configured maximum rate that it will send to the server.

 


My inclination is to include the OC-Supported-Features AVP in answers =
because most abatement algorithms will need it and because it can lead to b=
etter implementation client implementations.




 


+1 on both points


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4A05DEMUMBX014nsnin_--


From nobody Wed Feb 26 05:09:17 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3A01A02FE for ; Wed, 26 Feb 2014 05:09:12 -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
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 FXRQ8RQLQafX for ; Wed, 26 Feb 2014 05:09:09 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id D67D51A02B6 for ; Wed, 26 Feb 2014 05:09:09 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59475 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIeEM-00039p-KU; Wed, 26 Feb 2014 05:09:06 -0800
Message-ID: <530DE76A.1030305@usdonovans.com>
Date: Wed, 26 Feb 2014 07:08:58 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  ext Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------040807060805000805060307"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sN_F8QHxJvD0GQfkyZJw5dhUdsw
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 13:09:12 -0000

This is a multi-part message in MIME format.
--------------040807060805000805060307
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I agree that a server can send a continuing stream of OLRs with a
reduction percentage of zero.

I don't agree that the server MUST do so.

What is the point of sending the OLR for the 99% of the time when there
is no overload when absence of an OLR communicates exactly the same thing?

Steve

On 2/26/14 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> that is neither correct nor did we agree so.
>
>  
>
> No OLR means "no change", it does not mean "no overload".
>
> When a reporting node is not in overload, it still is allowed to send
> OLRs (indicating no overload/ end of overload) just to make sure that
> the reacting node has up to date information (it needs not do so when
> it knows that the reacting node already has sufficiently up to date
> information).
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, February 26, 2014 1:35 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> *Cc:* dime@ietf.org list
> *Subject:* Re: [Dime] Issue#30 status
>
>  
>
> Ulrich,
>
> An OLR is included in every answer message only when the reporting
> node is in an overload state.  There are no overload reports when the
> reacting node is not overloaded.
>
> Steve
>
> On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve, Ben, all,
>
>      
>
>     on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.
>
>      
>
>     On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).
>
>      
>
>     Ulrich
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
>
>     Sent: Tuesday, February 25, 2014 12:02 AM
>
>     To: Steve Donovan
>
>     Cc: dime@ietf.org  list
>
>     Subject: Re: [Dime] Issue#30 status
>
>      
>
>      
>
>     On Feb 24, 2014, at 2:12 PM, Steve Donovan   wrote:
>
>      
>
>         I can see two additional reasons for requiring OC-Supported-Features:
>
>          
>
>         1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.
>
>          
>
>         this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.
>
>          
>
>         There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.
>
>          
>
>         2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.
>
>          
>
>         My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.
>
>      
>
>     +1 on both points
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>  
>


--------------040807060805000805060307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I agree that a server can
      send a continuing stream of OLRs with a reduction percentage of
      zero.

      

      I don't agree that the server MUST do so.

      

      What is the point of sending the OLR for the 99% of the time when
      there is no overload when absence of an OLR communicates exactly
      the same thing?

      

      Steve

      

    
    
On 2/26/14 7:01 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
that is neither correct nor did we agree so.

        
 

        
No OLR means “no change”, it does not mean “no
            overload”.

        
When a reporting node is not in overload, it
            still is allowed to send OLRs (indicating no overload/ end
            of overload) just to make sure that the reacting node has up
            to date information (it needs not do so when it knows that
            the reacting node already has sufficiently up to date
            information).

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Wednesday, February 26, 2014 1:35 PM

                To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben
                Campbell

                Cc: dime@ietf.org list

                Subject: Re: [Dime] Issue#30 status

          

        

        
 

        
Ulrich,

          

          An OLR is included in every answer message only when the
          reporting node is in an overload state.  There are no overload
          reports when the reacting node is not overloaded.

          

          Steve

        

          
On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve, Ben, all,

          
 

          
on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.

          
 

          
On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).

          
 

          
Ulrich

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell

          
Sent: Tuesday, February 25, 2014 12:02 AM

          
To: Steve Donovan

          
Cc: dime@ietf.org list

          
Subject: Re: [Dime] Issue#30 status

          
 

          
 

          
On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

          
 

          

            
I can see two additional reasons for requiring OC-Supported-Features:

            
 

            
1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.

            
 

            
this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.

            
 

            
There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.

            
 

            
2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.

            
 

            
My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.

          

          
 

          
+1 on both points

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

          
 

        

        
 

      

    

    

  


--------------040807060805000805060307--


From nobody Wed Feb 26 05:28:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10C31A01E8 for ; Wed, 26 Feb 2014 05:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH6b0lCVgolz for ; Wed, 26 Feb 2014 05:27:53 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BF41A1A00A6 for ; Wed, 26 Feb 2014 05:27:52 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QDRoeA014064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 14:27:50 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QDRngi019512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 14:27:49 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 14:27:49 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , ext Ben Campbell 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIA==
Date: Wed, 26 Feb 2014 13:27:48 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com>
In-Reply-To: <530DE76A.1030305@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4A31DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 19975
X-purgate-ID: 151667::1393421270-00005322-5CEC3DA5/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DHvfHm6gM6us-Uryps6F9decisQ
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 13:27:58 -0000

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

I did not say that the server MUST do so.

For my clarification: what is the proposal for OC-Supported-Features in ans=
wer messages? Is it  a MUST in all answer messages that correspond to reque=
sts that indicated DOIC support? If so, why is it better
a) to always say "yes I support DOIC" rather than
b) to always say "current overload is xx"
where xx includes the possibility to say "no overload" and of course b) imp=
licitly indicates "yes I support DOIC"

Ulrich




From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, February 26, 2014 2:09 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

I agree that a server can send a continuing stream of OLRs with a reduction=
 percentage of zero.

I don't agree that the server MUST do so.

What is the point of sending the OLR for the 99% of the time when there is =
no overload when absence of an OLR communicates exactly the same thing?

Steve
On 2/26/14 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

that is neither correct nor did we agree so.

No OLR means "no change", it does not mean "no overload".
When a reporting node is not in overload, it still is allowed to send OLRs =
(indicating no overload/ end of overload) just to make sure that the reacti=
ng node has up to date information (it needs not do so when it knows that t=
he reacting node already has sufficiently up to date information).

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, February 26, 2014 1:35 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

Ulrich,

An OLR is included in every answer message only when the reporting node is =
in an overload state.  There are no overload reports when the reacting node=
 is not overloaded.

Steve
On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve, Ben, all,



on 1) we seem to agree that OC-Supported-Features in answers is not require=
d for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up=
 to drafts associated with new abatement algorithms to specify the requirem=
ent to include OC-Supported-Features in answers if so needed (I still don't=
 see the need even for rate or other algorithms); that needs to be discusse=
d when discussing those drafts.



On 2) I understand the usecase, but I'm not sure whether we have this requi=
rement of selective proactive throttling (see e-mail from Lionel). Anyway, =
given the conclusion on #31, OLR will be included in all answer messages (e=
xept when the reporting node is aware that the reacting node already knows)=
. Therefore the reacting node can deduce support of DOIC by the reporting n=
ode from the presence of OLR (if OLR is present then DOIC is supported by t=
he reporting node; if OLR is absent, then reacting node already knows wheth=
er or not DOIC is supported by the reporting node).



Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell

Sent: Tuesday, February 25, 2014 12:02 AM

To: Steve Donovan

Cc: dime@ietf.org list

Subject: Re: [Dime] Issue#30 status





On Feb 24, 2014, at 2:12 PM, Steve Donovan  wrote:



I can see two additional reasons for requiring OC-Supported-Features:



1) If the reacting node needs to know in advance whether the type of overlo=
ad abatement the reporting node will ask for.



this is not needed in the case of the loss abatement algorithm as the react=
ing node can just immediately start throttling the appropriate number of re=
quests.  It does not require prior knowledge of the traffic sent.



There are abatement algorithms that do require the client to keep state abo=
ut traffic sent to specific destinations.  We can, if we choose, leave it u=
p to the drafts associated with the new abatement algorithms to specify the=
 requirement to include OC-Supported-Features, as proposed by Ulrich.



2) If the reacting node can use the absence of the OC-Supported-Features AV=
P in answer messages to know that there is no Diameter overload supported i=
n the network and thus take other measures to protect the Diameter network.=
  For example, I can envision a client implementation that adapts to the kn=
owledge of whether servers support overload.  In the case that the server d=
oes support overload the client can send unlimited traffic to the server, u=
p to the point that the server sends an OLR.  If the client determines that=
 the server does not support overload then it might have a configured maxim=
um rate that it will send to the server.



My inclination is to include the OC-Supported-Features AVP in answers becau=
se most abatement algorithms will need it and because it can lead to better=
 implementation client implementations.



+1 on both points

_______________________________________________

DiME mailing list

DiME@ietf.org

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





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











I did not =
say that the server MUST do so.


 =
;


For my cla=
rification: what is the proposal for OC-Supported-Features in answer messag=
es? Is it  a MUST in all answer messages that correspond to
 requests that indicated DOIC support? If so, why is it better


a) to alwa=
ys say “yes I support DOIC” rather than


b) to alwa=
ys say “current overload is xx”  


where xx i=
ncludes the possibility to say “no overload” and of course b) i=
mplicitly indicates “yes I support DOIC”


 =
;


Ulrich


 =
;


 =
;


 =
;


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Wednesday, February 26, 2014 2:09 PM

To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Issue#30 status






 


I agree that a server=
 can send a continuing stream of OLRs with a reduction percentage of zero.<=
br>


I don't agree that the server MUST do so.



What is the point of sending the OLR for the 99% of the time when there is =
no overload when absence of an OLR communicates exactly the same thing?



Steve




On 2/26/14 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve,<=
/p>

 <=
/p>

that is ne=
ither correct nor did we agree so.


 


No OLR mea=
ns “no change”, it does not mean “no overload”.


When a rep=
orting node is not in overload, it still is allowed to send OLRs (indicatin=
g no overload/ end of overload) just to make sure that the
 reacting node has up to date information (it needs not do so when it knows=
 that the reacting node already has sufficiently up to date information).


 


Ulrich


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Wednesday, February 26, 2014 1:35 PM

To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Issue#30 status






 


Ulrich,



An OLR is included in every answer message only when the reporting node is =
in an overload state.  There are no overload reports when the reacting=
 node is not overloaded.



Steve




On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve, Ben, all,


 


on 1) we seem to agree that OC-Supported-Features in answers is not re=
quired for loss i.e. not required for  draft-ietf-dime-ovli. We can&nb=
sp; leave it up to drafts associated with new abatement algorithms to speci=
fy the requirement to include OC-Supported-Features in answers if so needed=
 (I still don't see the need even for rate or other algorithms); that needs=
 to be discussed when discussing those drafts.


 


On 2) I understand the usecase, but I'm not sure whether we have this =
requirement of selective proactive throttling (see e-mail from Lionel). Any=
way, given the conclusion on #31, OLR will be included in all answer messag=
es (exept when the reporting node is aware that the reacting node already k=
nows). Therefore the reacting node can deduce support of DOIC by the report=
ing node from the presence of OLR (if OLR is present then DOIC is supported=
 by the reporting node; if OLR is absent, then reacting node already knows =
whether or not DOIC is supported by the reporting node).


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Ben Campbell


Sent: Tuesday, February 25, 2014 12:02 AM


To: Steve Donovan


Cc: dime@ietf.org list=



Subject: Re: [Dime] Issue#30 status


 


 


On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




I can see two additional reasons for requiring OC-Supported-Features:<=
o:p>


 


1) If the reacting node needs to know in advance whether the type of o=
verload abatement the reporting node will ask for.


 


this is not needed in the case of the loss abatement algorithm as the =
reacting node can just immediately start throttling the appropriate number =
of requests.  It does not require prior knowledge of the traffic sent.=



 


There are abatement algorithms that do require the client to keep stat=
e about traffic sent to specific destinations.  We can, if we choose, =
leave it up to the drafts associated with the new abatement algorithms to s=
pecify the requirement to include OC-Supported-Features, as proposed by Ulr=
ich.


 


2) If the reacting node can use the absence of the OC-Supported-Featur=
es AVP in answer messages to know that there is no Diameter overload suppor=
ted in the network and thus take other measures to protect the Diameter net=
work.  For example, I can envision a client implementation that adapts=
 to the knowledge of whether servers support overload.  In the case th=
at the server does support overload the client can send unlimited traffic t=
o the server, up to the point that the server sends an OLR.  If the cl=
ient determines that the server does not support overload then it might hav=
e a configured maximum rate that it will send to the server.

 


My inclination is to include the OC-Supported-Features AVP in answers =
because most abatement algorithms will need it and because it can lead to b=
etter implementation client implementations.




 


+1 on both points


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4A31DEMUMBX014nsnin_--


From nobody Wed Feb 26 06:55:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74521A0420 for ; Wed, 26 Feb 2014 06:55:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiI7L-6kHkfU for ; Wed, 26 Feb 2014 06:55:30 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EFD401A0641 for ; Wed, 26 Feb 2014 06:55:29 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QEtRNF022321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 15:55:27 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QEtRCM022714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 15:55:27 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 15:55:26 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 15:55:26 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPLKfaNBG2qkbh0kelPIaMQYlrnZq6+hlQgAmztBKAAvg4YA==
Date: Wed, 26 Feb 2014 14:55:25 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com> <530B7D62.1080700@usdonovans.com>
In-Reply-To: <530B7D62.1080700@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4A6EDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 8459
X-purgate-ID: 151667::1393426527-00005322-64806032/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jKxM5Fzh3CwDsB6foHBfvRJOFDc
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 14:55:34 -0000

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

Ben, Steve, all

I still think we can conclude on #34.

The issue here is independent and is valid for both realm-routed-request re=
ports and realm reports (should we ever agree on them, see #55).  I shall o=
pen a new ticket on Multiple Reporting Nodes reporting realm-routed-request=
 reports for the same realm.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, February 24, 2014 6:12 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Ben,

One comment below.

Steve
On 2/20/14 5:16 PM, Ben Campbell wrote:



On Feb 18, 2014, at 8:54 AM, Steve Donovan  wrote:



- Reacting nodes should listen to only one realm overload reporting node.  =
It is up to the implementation of the realm overload detection element to m=
ake sure that all reporting nodes have the same state.



I think this should be restated that realm reports should only be _sent_ by=
 reporting nodes that have full knowledge of and authority for the realm's =
overload state. But there's no requirement that there be only one, just tha=
t if there are more than one they don't contradict each other.
SRD> The reason for this requirement is to handle the likelihood that each =
reporting node of the new realm report type will have independent sequence =
numbers.  Thus, as long as all reporting nodes report all updates to the re=
alm overload status, it should be sufficient for a reacting node to only li=
sten to one of the reporting nodes when determining if the OLR is new.








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











Ben, Steve, all


 <=
/p>

I still th=
ink we can conclude on #34.


 =
;


The issue =
here is independent and is valid for both realm-routed-request reports and =
realm reports (should we ever agree on them, see #55).  I
 shall open a new ticket on Multiple Reporting Nodes reporting realm-routed=
-request reports for the same realm.


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Monday, February 24, 2014 6:12 PM

To: Ben Campbell

Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP=







 


Ben,



One comment below.



Steve




On 2/20/14 5:16 PM, Ben Campbell wrote:





 


On Feb 18, 2014, at 8:54 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




- Reacting nodes should listen to only one realm overload reporting no=
de.  It is up to the implementation of the realm overload detection el=
ement to make sure that all reporting nodes have the same state.=





 


I think this should be restated that realm reports should only be _sen=
t_ by reporting nodes that have full knowledge of and authority for the rea=
lm's overload state. But there's no requirement that there be only one, jus=
t that if there are more than one they don't contradict each other.




SRD> The reason for this requirement is to handle=
 the likelihood that each reporting node of the new realm report type will =
have independent sequence numbers.  Thus, as long as all reporting nod=
es report all updates to the realm overload
 status, it should be sufficient for a reacting node to only listen to one =
of the reporting nodes when determining if the OLR is new.






 


 


 


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4A6EDEMUMBX014nsnin_--


From nobody Wed Feb 26 07:02:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1128C1A00E2 for ; Wed, 26 Feb 2014 07:02: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
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 Di8nB70DMTDd for ; Wed, 26 Feb 2014 07:02:40 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id DC8981A0454 for ; Wed, 26 Feb 2014 07:02:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60920 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIg0J-000704-JH; Wed, 26 Feb 2014 07:02:36 -0800
Message-ID: <530E020B.6070300@usdonovans.com>
Date: Wed, 26 Feb 2014 09:02:35 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Ben Campbell 
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com> <530B7D62.1080700@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------070504040704000103020704"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BNLkww8W4rNodPRiRIH53Fd_id0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:02:43 -0000

This is a multi-part message in MIME format.
--------------070504040704000103020704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Sounds good, thanks,

Steve

On 2/26/14 8:55 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Ben, Steve, all
>
>  
>
> I still think we can conclude on #34.
>
>  
>
> The issue here is independent and is valid for both
> realm-routed-request reports and realm reports (should we ever agree
> on them, see #55).  I shall open a new ticket on Multiple Reporting
> Nodes reporting realm-routed-request reports for the same realm.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Monday, February 24, 2014 6:12 PM
> *To:* Ben Campbell
> *Cc:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> Ben,
>
> One comment below.
>
> Steve
>
> On 2/20/14 5:16 PM, Ben Campbell wrote:
>
>      
>
>     On Feb 18, 2014, at 8:54 AM, Steve Donovan   wrote:
>
>      
>
>         - Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.
>
>      
>
>     I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.
>
> SRD> The reason for this requirement is to handle the likelihood that
> each reporting node of the new realm report type will have independent
> sequence numbers.  Thus, as long as all reporting nodes report all
> updates to the realm overload status, it should be sufficient for a
> reacting node to only listen to one of the reporting nodes when
> determining if the OLR is new.
>
>  
>  
>
>  
>
>  
>


--------------070504040704000103020704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Sounds good, thanks,

      

      Steve

      

    
    
On 2/26/14 8:55 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Ben,
            Steve, all

        
 

        
I still think we can conclude on #34.

        
 

        
The issue here is independent and is valid for
            both realm-routed-request reports and realm reports (should
            we ever agree on them, see #55).  I shall open a new ticket
            on Multiple Reporting Nodes reporting realm-routed-request
            reports for the same realm.

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Monday, February 24, 2014 6:12 PM

                To: Ben Campbell

                Cc: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] [dime] #34: Semantics of
                OC-Report-Type AVP

          

        

        
 

        
Ben,

          

          One comment below.

          

          Steve

        

          
On 2/20/14 5:16 PM, Ben Campbell wrote:

        

        

          
 

          
On Feb 18, 2014, at 8:54 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

          
 

          

            
- Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.

          

          
 

          
I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.

        

        
SRD> The reason for this requirement is
          to handle the likelihood that each reporting node of the new
          realm report type will have independent sequence numbers. 
          Thus, as long as all reporting nodes report all updates to the
          realm overload status, it should be sufficient for a reacting
          node to only listen to one of the reporting nodes when
          determining if the OLR is new.

          

          

        
 

        
 

        
 

        
 

      

    

    

  


--------------070504040704000103020704--


From nobody Wed Feb 26 07:09:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EE51A0401 for ; Wed, 26 Feb 2014 07:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq-cWUtZE-FQ for ; Wed, 26 Feb 2014 07:09:07 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C0A1A0403 for ; Wed, 26 Feb 2014 07:09:01 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QF8vIX011199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 09:08:59 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net>
Date: Wed, 26 Feb 2014 09:08:56 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <368CFE4F-0A31-4E1B-BFC1-4835AD5A3DE5@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gXQsUC5iMdwyN_MVxqkyKpJnmYk
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:09:09 -0000

We are going around in circles on this one. I don't agree for reasons I =
have stated before, but will state again for reference (see inline).

On Feb 26, 2014, at 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Steve, Ben, all,
>=20
> on 1) we seem to agree that OC-Supported-Features in answers is not =
required for loss i.e. not required for  draft-ietf-dime-ovli. We can  =
leave it up to drafts associated with new abatement algorithms to =
specify the requirement to include OC-Supported-Features in answers if =
so needed (I still don't see the need even for rate or other =
algorithms); that needs to be discussed when discussing those drafts.

I think it's best to keep it there for all algorithms. I'd like to be =
able to look for a single field and understand wether DOIC is supported, =
what algorithm is being used, as well as any parameters for that =
algorithm (even if none.) I don't want to have to look for the field, =
then if it's not there look other places.

>=20
> On 2) I understand the usecase, but I'm not sure whether we have this =
requirement of selective proactive throttling (see e-mail from Lionel). =
Anyway, given the conclusion on #31, OLR will be included in all answer =
messages (exept when the reporting node is aware that the reacting node =
already knows). Therefore the reacting node can deduce support of DOIC =
by the reporting node from the presence of OLR (if OLR is present then =
DOIC is supported by the reporting node; if OLR is absent, then reacting =
node already knows whether or not DOIC is supported by the reporting =
node).


We have a requirement to be able to operate effectively in a mixed =
environment. Working with nodes that do not support DOIC is going to =
require other strategies. Steve's example is a possible such strategy. =
Taking away the ability to quickly learn which peers support DOIC makes =
working effectively in a mixed environment harder.

I'm really surprised people are so opposed to including =
OC-Supported-Features in every answer. It's very easy and cheap to do =
it. Leaving it out makes implementations harder and more error prone. =
Leaving it out makes it hard or impossible to take proactive measures to =
work with other nodes that don't support DOIC. This should be an easy =
choice.

We've mentioned several advantages of requiring it in every answer. The =
only advantage I see for removing it is to save having to insert one =
more AVP. I don't find that convincing. Are there other reasons for =
leaving it out?=


From nobody Wed Feb 26 07:11:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D01A0678 for ; Wed, 26 Feb 2014 07:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQpkbwAWDeEa for ; Wed, 26 Feb 2014 07:11:27 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CB31A066E for ; Wed, 26 Feb 2014 07:10:56 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QFArod011288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 09:10:54 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net>
Date: Wed, 26 Feb 2014 09:10:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/R-FR99kcpMpSDwa7phbWVnh8irE
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:11:32 -0000

On Feb 26, 2014, at 7:27 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> I did not say that the server MUST do so.
> =20
> For my clarification: what is the proposal for OC-Supported-Features =
in answer messages? Is it  a MUST in all answer messages that correspond =
to requests that indicated DOIC support? If so, why is it better
> a) to always say =93yes I support DOIC=94 rather than
> b) to always say =93current overload is xx=94 =20
> where xx includes the possibility to say =93no overload=94 and of =
course b) implicitly indicates =93yes I support DOIC=94

Because B requires considerably more work for both sender and receiver, =
as well as more data overhead to essentially accomplish the same thing =
as A.


From nobody Wed Feb 26 07:13:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD0E1A0688 for ; Wed, 26 Feb 2014 07:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7MhlS7DcShb for ; Wed, 26 Feb 2014 07:13:54 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DB41A067D for ; Wed, 26 Feb 2014 07:13:54 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QFDpOK011369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 09:13:52 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net>
Date: Wed, 26 Feb 2014 09:13:49 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <18EEB293-F277-48EF-86B0-49FED3A87CD0@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/L-hJ3UO8NKbZ7WrPKqlf74id5PQ
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:13:57 -0000

On Feb 26, 2014, at 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Steve,
> =20
> that is neither correct nor did we agree so.
> =20
> No OLR means =93no change=94, it does not mean =93no overload=94.
> When a reporting node is not in overload, it still is allowed to send =
OLRs (indicating no overload/ end of overload) just to make sure that =
the reacting node has up to date information (it needs not do so when it =
knows that the reacting node already has sufficiently up to date =
information).

I agree that this is technically true. But in the case where the =
reacting node has not been informed of an overload condition, or all =
such conditions have expired, "no chance" is the same as "no overload". =
And unless we choose to mandate an OLR in every answer (which would be =
much more costly than mandating OC-Supported-Features), we are back =
where we started.

> =20
> Ulrich
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Wednesday, February 26, 2014 1:35 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
> =20
> Ulrich,
>=20
> An OLR is included in every answer message only when the reporting =
node is in an overload state.  There are no overload reports when the =
reacting node is not overloaded.
>=20
> Steve
>=20
> On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben, all,
> =20
> on 1) we seem to agree that OC-Supported-Features in answers is not =
required for loss i.e. not required for  draft-ietf-dime-ovli. We can  =
leave it up to drafts associated with new abatement algorithms to =
specify the requirement to include OC-Supported-Features in answers if =
so needed (I still don't see the need even for rate or other =
algorithms); that needs to be discussed when discussing those drafts.
> =20
> On 2) I understand the usecase, but I'm not sure whether we have this =
requirement of selective proactive throttling (see e-mail from Lionel). =
Anyway, given the conclusion on #31, OLR will be included in all answer =
messages (exept when the reporting node is aware that the reacting node =
already knows). Therefore the reacting node can deduce support of DOIC =
by the reporting node from the presence of OLR (if OLR is present then =
DOIC is supported by the reporting node; if OLR is absent, then reacting =
node already knows whether or not DOIC is supported by the reporting =
node).
> =20
> Ulrich
> =20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben =
Campbell
> Sent: Tuesday, February 25, 2014 12:02 AM
> To: Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
> =20
> =20
> On Feb 24, 2014, at 2:12 PM, Steve Donovan  =
wrote:
> =20
> I can see two additional reasons for requiring OC-Supported-Features:
> =20
> 1) If the reacting node needs to know in advance whether the type of =
overload abatement the reporting node will ask for.
> =20
> this is not needed in the case of the loss abatement algorithm as the =
reacting node can just immediately start throttling the appropriate =
number of requests.  It does not require prior knowledge of the traffic =
sent.
> =20
> There are abatement algorithms that do require the client to keep =
state about traffic sent to specific destinations.  We can, if we =
choose, leave it up to the drafts associated with the new abatement =
algorithms to specify the requirement to include OC-Supported-Features, =
as proposed by Ulrich.
> =20
> 2) If the reacting node can use the absence of the =
OC-Supported-Features AVP in answer messages to know that there is no =
Diameter overload supported in the network and thus take other measures =
to protect the Diameter network.  For example, I can envision a client =
implementation that adapts to the knowledge of whether servers support =
overload.  In the case that the server does support overload the client =
can send unlimited traffic to the server, up to the point that the =
server sends an OLR.  If the client determines that the server does not =
support overload then it might have a configured maximum rate that it =
will send to the server.
> =20
> My inclination is to include the OC-Supported-Features AVP in answers =
because most abatement algorithms will need it and because it can lead =
to better implementation client implementations.
> =20
> +1 on both points
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20


From nobody Wed Feb 26 07:15:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4951A066F for ; Wed, 26 Feb 2014 07:15:18 -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
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 7nSC8-NyFkab for ; Wed, 26 Feb 2014 07:15:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 989821A0674 for ; Wed, 26 Feb 2014 07:14:49 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60949 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WIgC2-0006EC-Mw; Wed, 26 Feb 2014 07:14:48 -0800
Message-ID: <530E04E2.2070405@usdonovans.com>
Date: Wed, 26 Feb 2014 09:14:42 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  ext Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------070005010008070303020506"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Np3AlH4aeM0qVputqKo9u0w2j-4
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:15:19 -0000

This is a multi-part message in MIME format.
--------------070005010008070303020506
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

See inline.

Steve
On 2/26/14 7:27 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> I did not say that the server MUST do so.
>
SRD> I assumed a MUST if this was to be used as a way to communicate
support for DOIC. 
>
>  
>
> For my clarification: what is the proposal for OC-Supported-Features
> in answer messages? Is it  a MUST in all answer messages that
> correspond to requests that indicated DOIC support? If so, why is it
> better
>
> a) to always say "yes I support DOIC" rather than
>
> b) to always say "current overload is xx"  
>
> where xx includes the possibility to say "no overload" and of course
> b) implicitly indicates "yes I support DOIC"
>
SRD> One is capability advertisement the other is overload reporting. 
We should not mix the semantics of the two.

SRD> We don't have consensus yet, but if we agree on the need for
reacting nodes to know whether there is support for DOIC in the Diameter
network then I think the requirement would be similar to how we are
handling overload reports.  The reporting node MUST ensure that all
reacting nodes receive the OC-Supported-Features AVP.  This can be done
by including the AVP in all answer messages or it can be done by
remembering to whom the AVP has been sent.
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, February 26, 2014 2:09 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> *Cc:* dime@ietf.org list
> *Subject:* Re: [Dime] Issue#30 status
>
>  
>
> I agree that a server can send a continuing stream of OLRs with a
> reduction percentage of zero.
>
> I don't agree that the server MUST do so.
>
> What is the point of sending the OLR for the 99% of the time when
> there is no overload when absence of an OLR communicates exactly the
> same thing?
>
> Steve
>
> On 2/26/14 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     that is neither correct nor did we agree so.
>
>      
>
>     No OLR means "no change", it does not mean "no overload".
>
>     When a reporting node is not in overload, it still is allowed to
>     send OLRs (indicating no overload/ end of overload) just to make
>     sure that the reacting node has up to date information (it needs
>     not do so when it knows that the reacting node already has
>     sufficiently up to date information).
>
>      
>
>     Ulrich
>
>      
>
>     *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Wednesday, February 26, 2014 1:35 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
>     *Cc:* dime@ietf.org  list
>     *Subject:* Re: [Dime] Issue#30 status
>
>      
>
>     Ulrich,
>
>     An OLR is included in every answer message only when the reporting
>     node is in an overload state.  There are no overload reports when
>     the reacting node is not overloaded.
>
>     Steve
>
>     On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Steve, Ben, all,
>
>          
>
>         on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.
>
>          
>
>         On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).
>
>          
>
>         Ulrich
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
>
>         Sent: Tuesday, February 25, 2014 12:02 AM
>
>         To: Steve Donovan
>
>         Cc: dime@ietf.org  list
>
>         Subject: Re: [Dime] Issue#30 status
>
>          
>
>          
>
>         On Feb 24, 2014, at 2:12 PM, Steve Donovan   wrote:
>
>          
>
>             I can see two additional reasons for requiring OC-Supported-Features:
>
>              
>
>             1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.
>
>              
>
>             this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.
>
>              
>
>             There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.
>
>              
>
>             2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.
>
>              
>
>             My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.
>
>          
>
>         +1 on both points
>
>         _______________________________________________
>
>         DiME mailing list
>
>         DiME@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>          
>
>      
>
>  
>


--------------070005010008070303020506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    See inline.

      

      Steve

    
    
On 2/26/14 7:27 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
I did not say that the server MUST do so.

      

    

    SRD> I assumed a MUST if this was to be used as a way to
    communicate support for DOIC.  

    

      

        

        
 

        
For my clarification: what is the proposal for
            OC-Supported-Features in answer messages? Is it  a MUST in
            all answer messages that correspond to requests that
            indicated DOIC support? If so, why is it better

      

    

    

      

        

        
a) to always say “yes I support DOIC” rather
            than

        
b) to always say “current overload is xx”  

        
where xx includes the possibility to say “no
            overload” and of course b) implicitly indicates “yes I
            support DOIC”

      

    

    SRD> One is capability advertisement the other is overload
    reporting.  We should not mix the semantics of the two.

    

    SRD> We don't have consensus yet, but if we agree on the need for
    reacting nodes to know whether there is support for DOIC in the
    Diameter network then I think the requirement would be similar to
    how we are handling overload reports.  The reporting node MUST
    ensure that all reacting nodes receive the OC-Supported-Features
    AVP.  This can be done by including the AVP in all answer messages
    or it can be done by remembering to whom the AVP has been sent.

    

      

        

        
 

        
Ulrich

        
 

        
 

        
 

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Wednesday, February 26, 2014 2:09 PM

                To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben
                Campbell

                Cc: dime@ietf.org list

                Subject: Re: [Dime] Issue#30 status

          

        

        
 

        
I agree that a
          server can send a continuing stream of OLRs with a reduction
          percentage of zero.

          

          I don't agree that the server MUST do so.

          

          What is the point of sending the OLR for the 99% of the time
          when there is no overload when absence of an OLR communicates
          exactly the same thing?

          

          Steve

        

          
On 2/26/14 7:01 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve,

          
 

          
that is neither correct nor did we agree so.

          
 

          
No OLR means “no change”, it does not mean
              “no overload”.

          
When a reporting node is not in overload, it
              still is allowed to send OLRs (indicating no overload/ end
              of overload) just to make sure that the reacting node has
              up to date information (it needs not do so when it knows
              that the reacting node already has sufficiently up to date
              information).

          
 

          
Ulrich

          
 

          

            

              
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Sent: Wednesday, February 26, 2014 1:35 PM

                  To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben
                  Campbell

                  Cc: dime@ietf.org list

                  Subject: Re: [Dime] Issue#30 status

            

          

          
 

          
Ulrich,

            

            An OLR is included in every answer message only when the
            reporting node is in an overload state.  There are no
            overload reports when the reacting node is not overloaded.

            

            Steve

          

            
On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN
              - DE/Munich) wrote:

          

          

            
Steve, Ben, all,

            
 

            
on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.

            
 

            
On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).

            
 

            
Ulrich

            
 

            
-----Original Message-----

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell

            
Sent: Tuesday, February 25, 2014 12:02 AM

            
To: Steve Donovan

            
Cc: dime@ietf.org list

            
Subject: Re: [Dime] Issue#30 status

            
 

            
 

            
On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

            
 

            

              
I can see two additional reasons for requiring OC-Supported-Features:

              
 

              
1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.

              
 

              
this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.

              
 

              
There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.

              
 

              
2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.

              
 

              
My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.

            

            
 

            
+1 on both points

            
_______________________________________________

            
DiME mailing list

            
DiME@ietf.org

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

            
 

          

          
 

        

        
 

      

    

    

  


--------------070005010008070303020506--


From nobody Wed Feb 26 07:15:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D100A1A066E for ; Wed, 26 Feb 2014 07:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6MDWBKm8f4m for ; Wed, 26 Feb 2014 07:15:30 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1331A0231 for ; Wed, 26 Feb 2014 07:15:14 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QFFB6M011425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 09:15:13 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
Date: Wed, 26 Feb 2014 09:15:09 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <07D74432-AB28-43BB-9C54-EA091D647250@nostrum.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum! .com> <530B7D62.1080700@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1g5vrqCpig67hvGTfzyvY7GW9go
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:15:33 -0000

Given the further discussion, what is the currently proposed conclusion?

On Feb 26, 2014, at 8:55 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Ben, Steve, all
> =20
> I still think we can conclude on #34.
> =20
> The issue here is independent and is valid for both =
realm-routed-request reports and realm reports (should we ever agree on =
them, see #55).  I shall open a new ticket on Multiple Reporting Nodes =
reporting realm-routed-request reports for the same realm.
> =20
> Ulrich
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Monday, February 24, 2014 6:12 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> Ben,
>=20
> One comment below.
>=20
> Steve
>=20
> On 2/20/14 5:16 PM, Ben Campbell wrote:
> =20
> On Feb 18, 2014, at 8:54 AM, Steve Donovan  =
wrote:
> =20
> - Reacting nodes should listen to only one realm overload reporting =
node.  It is up to the implementation of the realm overload detection =
element to make sure that all reporting nodes have the same state.
> =20
> I think this should be restated that realm reports should only be =
_sent_ by reporting nodes that have full knowledge of and authority for =
the realm's overload state. But there's no requirement that there be =
only one, just that if there are more than one they don't contradict =
each other.
> SRD> The reason for this requirement is to handle the likelihood that =
each reporting node of the new realm report type will have independent =
sequence numbers.  Thus, as long as all reporting nodes report all =
updates to the realm overload status, it should be sufficient for a =
reacting node to only listen to one of the reporting nodes when =
determining if the OLR is new.
>=20
> =20
> =20
> =20
> =20


From nobody Wed Feb 26 07:18:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3625D1A0698 for ; Wed, 26 Feb 2014 07:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH7xI_TCTpnt for ; Wed, 26 Feb 2014 07:18:44 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 807351A0697 for ; Wed, 26 Feb 2014 07:18:38 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QFIZlf011540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 09:18:36 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <530E04E2.2070405@usdonovans.com>
Date: Wed, 26 Feb 2014 09:18:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KORFC6NpGKrdzkKA4_VvNUgHPHY
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:18:48 -0000

On Feb 26, 2014, at 9:14 AM, Steve Donovan  =
wrote:

> SRD> We don't have consensus yet, but if we agree on the need for =
reacting nodes to know whether there is support for DOIC in the Diameter =
network then I think the requirement would be similar to how we are =
handling overload reports.  The reporting node MUST ensure that all =
reacting nodes receive the OC-Supported-Features AVP.  This can be done =
by including the AVP in all answer messages or it can be done by =
remembering to whom the AVP has been sent.

Given the trivial nature of sending and reading OC-Supported-Features, I =
think we should put it in every answer. This mirrors the way we handle =
it in requests.


From nobody Wed Feb 26 07:19:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ECF1A0097 for ; Wed, 26 Feb 2014 07:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV2p8TmiLjeb for ; Wed, 26 Feb 2014 07:19:04 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 641931A0660 for ; Wed, 26 Feb 2014 07:19:02 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QFIx13031303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 16:18:59 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QFIx6N029073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 16:18:59 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 16:18:59 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 16:18:59 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell 
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPLKfaNBG2qkbh0kelPIaMQYlrnZq6+hlQgAmztBKAAvg4YP//+vqAgAARmAA=
Date: Wed, 26 Feb 2014 15:18:58 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4AAB@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup>   <52FCBBF7.7000700@usdonovans.com>  <5302351F.6050902@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum! .com> <530B7D62.1080700@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net> <07D74432-AB28-43BB-9C54-EA091D647250@nostrum.com>
In-Reply-To: <07D74432-AB28-43BB-9C54-EA091D647250@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2321
X-purgate-ID: 151667::1393427940-00003660-92E82A4D/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dgtn3UX6W7kJlb58wbWzNSFmgrI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 15:19:07 -0000

#34 	Semantics of OC-Report-Type AVP	Resolved	Agreed - Replace text in sect=
ion 4.6 with text proposed in the ticket.

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Wednesday, February 26, 2014 4:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Given the further discussion, what is the currently proposed conclusion?

On Feb 26, 2014, at 8:55 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:

> Ben, Steve, all
> =20
> I still think we can conclude on #34.
> =20
> The issue here is independent and is valid for both realm-routed-request =
reports and realm reports (should we ever agree on them, see #55).  I shall=
 open a new ticket on Multiple Reporting Nodes reporting realm-routed-reque=
st reports for the same realm.
> =20
> Ulrich
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Monday, February 24, 2014 6:12 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
> =20
> Ben,
>=20
> One comment below.
>=20
> Steve
>=20
> On 2/20/14 5:16 PM, Ben Campbell wrote:
> =20
> On Feb 18, 2014, at 8:54 AM, Steve Donovan  wro=
te:
> =20
> - Reacting nodes should listen to only one realm overload reporting node.=
  It is up to the implementation of the realm overload detection element to=
 make sure that all reporting nodes have the same state.
> =20
> I think this should be restated that realm reports should only be _sent_ =
by reporting nodes that have full knowledge of and authority for the realm'=
s overload state. But there's no requirement that there be only one, just t=
hat if there are more than one they don't contradict each other.
> SRD> The reason for this requirement is to handle the likelihood that eac=
h reporting node of the new realm report type will have independent sequenc=
e numbers.  Thus, as long as all reporting nodes report all updates to the =
realm overload status, it should be sufficient for a reacting node to only =
listen to one of the reporting nodes when determining if the OLR is new.
>=20
> =20
> =20
> =20
> =20


From nobody Wed Feb 26 08:06:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888071A0454 for ; Wed, 26 Feb 2014 08:06:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds7yo7GGo8f1 for ; Wed, 26 Feb 2014 08:06:14 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6A31A067B for ; Wed, 26 Feb 2014 08:06:14 -0800 (PST)
Received: from localhost ([127.0.0.1]:36853 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WIgzr-0004x2-A1; Wed, 26 Feb 2014 17:06:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: ulrich.wiehe@nsn.com
X-Trac-Project: dime
Date: Wed, 26 Feb 2014 16:06:11 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/58
Message-ID: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org>
X-Trac-Ticket-ID: 58
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: ulrich.wiehe@nsn.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hc859JUNYsRFtuuRYndpRFwjHCU
Cc: dime@ietf.org
Subject: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 16:06:19 -0000

#58: Multiple Reporting Nodes for realm-routed-request type reports

 In deployments where more than one node is configured to take the role of
 a reporting node for realm-routed-request reports, reacting nodes may
 receive
 in different answer messages different realm-routed-request type OLRs
 inserted by the different reporting nodes. Although it is expected that
 the different reporting nodes report more or less the same content, it
 cannot be expected that reports are 100% synchronized. Especially sequence
 numbers may differ.
 To allow reacting nodes correctly detect outdates/replays/freshness of
 OLRs in this scenario, it is proposed that realm-routed-request type OLRs
 are extended to contain the Diameter Identity of the reporting node that
 inserted the realm-routed-request type OLR. (e.g. as already proposed in
 draft-donovan-dime-agent-overload-01).
 Reporting nodes that insert realm-routed-request type OLRs to answer
 messages MUST also insert their Diameter Identity.
 Reacting nodes MUST take the Diameter Identity received within the OLR
 into account in order to detect outdates/replays/freshness.

-- 
-----------------------------------+--------------------------
 Reporter:  ulrich.wiehe@nsn.com   |      Owner:  Ulrich Wiehe
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  draft-docdt-dime-ovli  |    Version:  1.0
 Severity:  Active WG Document     |   Keywords:
-----------------------------------+--------------------------

Ticket URL: 
dime 


From nobody Thu Feb 27 08:12:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F761A01EF for ; Thu, 27 Feb 2014 08:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg_uUAoaqmt9 for ; Thu, 27 Feb 2014 08:12:38 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id ECF8A1A0234 for ; Thu, 27 Feb 2014 08:12:36 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-8a-530f63f2b3ba
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 2F.D0.04249.2F36F035; Thu, 27 Feb 2014 17:12:34 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 17:12:33 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAABdR0aQAC5d2AAAC4oAAAAFtYgAAAPiMAAADxZgAAHM0YAAAuChOAAAj34gAAMkHSoA==
Date: Thu, 27 Feb 2014 16:12:33 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209787161@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209787161ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje6nZP5ggyNP5S3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr2tm5gLzh1kr1ix+jBzA+Ph02xdjJwcEgImEj+bdrFC2GIS F+6tB4pzcQgJHGGUmDb9HyuEs5hRYsvtv0wgVWwCdhKXTr8Asjk4RASUJU7/cgAJCwuoS9z5 fgFskIiAhkTjm0/sIL0iAssYJa5vPsUCkmARUJU4fnEnWBGvgK/E57sdzBALnnBKbG65wAyS 4BQIkFj46AsjiM0IdNL3U2vAFjMLiEvcejKfCeJUAYkle84zQ9iiEi8fg1zKAWQrSUzbmgZR ni9x5v1lqF2CEidnPmGZwCgyC8mkWUjKZiEpg4jrSdyYOoUNwtaWWLbwNTOErSsx498hFmTx BYzsqxg5ilOLk3LTjQw2MQLj5eCW3xY7GC//tTnEKM3BoiTO+/Gtc5CQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxtpp13mXxy4sW2TrI38luTDL4GsdT8D9S5f+//darcmwPGLDWtOqa8tF G+cdTrfxltgdY5S8LvRJwGLLjPcspxkfxDj8mFscorA2Kvt88Uumazf9rkQdbCkO9LT1WV0j LX7irWyrh+uXiBPz1gvdCjXln1p5VVryINvJi4s/i9/X2vT6lpC4mhJLcUaioRZzUXEiAC7C NatlAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9puqsfQO8decNKrKjs3_iaDlML8
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 27 Feb 2014 16:12:50 -0000

--_000_087A34937E64E74E848732CFF8354B9209787161ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Ulrich,

Being:

(0)    OLR per client

(1)    OLR for all clients

Some comments on the interactions you mentioned:

1.      A fresh OLR of type (1) makes all old OLRs of any type invalid

2.      A fresh OLR of type (0) makes an old OLR of type (0) bound to the s=
ame client invalid

3.      A fresh OLR of type (0) makes an old OLR of type (1) invalid

I do not think 3) is right. Why an OLR per one specific client shall invali=
date OLRs for rest of clients? This will imply that rest of clients will no=
t have any overload mitigation on until they receive a new value of (1), or=
 (0) for each of them.

Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: mi=E9rcoles, 26 de febrero de 2014 12:23
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi JJacques,

thank you for the summary.

I think it does not matter whether we call

A)      "OLR per client" the base solution and "OLR for all clients" the op=
timization or

B)     "OLR for all clients" the base solution and "OLR per client" the (3G=
PP) extension
as long as we cover both.

I don't think there are impacts on sequence number handling, report types o=
r DOIC associations.

My proposal then is to add a new mandatory AVP of type enumerated to OC-OLR=
 with values

(0)    OLR per client

(1)    OLR for all clients

Reporting nodes that better like A) could allways send (0) unless they supp=
ort the "optimization" and want to use it;
Reporting nodes that better like B) could allways send (1) unless they supp=
ort the "(3GPP) extension" and want to use it.
Clients can safely ignore the new AVP.
Agents taking the role of the reacting node on behalf of a client must do t=
he binding when receiving (0).

We also need to say something on interactions e.g.:
A fresh OLR of type (1) makes all old OLRs of any type invalid
A fresh OLR of type (0) makes an old OLR of type (0) bound to the same clie=
nt invalid
A fresh OLR of type (0) makes an old OLR of type (1) invalid

(i.e. change of type is allowed, mixture is not allowed)

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Wednesday, February 26, 2014 8:07 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Steve, MCruz and all

On my side,  I agree with Lionel.

I  have not the  same reading of the draft where I have  not found the Stev=
e's default case.
I agree with Lionel that the OLR for a DOIC association relates to this DOI=
C association  and the OLR can be different  for another DOIC association. =
The basic (or "default") principle is that each DOIC association has its "o=
wn life".

Then,  a server (local policy) can decide  to send  the same OLR to all its=
 clients (so for all its DOIC associations) , or it can define  particular =
OLR values for   certain clients.
Another  interest  is that  when the server wants to update the OLR values =
towards  clients, it is  not obliged to send the new values  simultaneously=
  to all the clients : it may  (local server policy) progressively  change =
 the  value  over a certain duration  to minimize  sharp transitions.

So for DOIC supporting clients, the current text allows these possibilities=
, and in particular it satisfies the 3GGP client mitigation requirement.

A second step is to address DAs supporting non DOIC clients. Over time,  we=
 may expect that clients will be more and more DOIC supporting; so, this is=
 the main target. DAs with non DOIC client would be more for   a transition=
 (to be considered  nevertheless and which may be long).

The current text says that DA is acting on behalf of "A" client; so princip=
le  with host OLR per DOIC association also applies, and there is no differ=
ence for the server, as this does not make a difference  between a DOIC sup=
porting client and a DA supporting non DOIC clients.
Nevertheless, and here I come to Steve's point,   this has a cost implying =
the DA to manage OLRs per client. Steve  introduces an optimization where i=
n fact a set of clients are considered for me as a pool regarding  DOIC whe=
re only one OLR applies and where throttling  applies  to the requests of t=
his  pool of clients.  I am not against to optimization process   but this =
pool concept is new and needs some further study. First about the concept o=
f DOIC association which evolves , as now linked to a pool .

There was a MCruz remark about sequence number, a new AVP or a  new report =
type.  I see that  we may have to review  the processing of the seq number =
 handling as also dependent of the new AVP or the OLR type; so   a "collate=
ral " effect of the optimization. I would also think that, instead of intro=
ducing a single node indication in the OLR (AVP or report type) , it should=
 be a global indication as the optimization   is to support a global DOIC a=
ssociation.  To also see if there are not other collateral effects to analy=
ze.

Ulrich  also mentioned that for realm OLRs we may also have  a different re=
alm  OLR sent to different clients, so this is the same principle as Lionel=
  for  a realm OLR per DOIC association, on which I agree.

The current text due to the DOIC association principle,  allows this realm =
OLR per DOIC association for both  DOIC  supporting clients and  DAs acting=
 on behalf of A client. Then I expect Steve  to do the same remark, with th=
e same reason  to have  an optimization  where all clients receives  the  s=
ame realm OLR, but to also see the collateral effects.

As a conclusion, I think we should remain with the current text as the base=
line, following the DOIC association principle that Lionel mentions, and af=
ter more investigation to assess the  optimization  for host and realm OLRs=
 with DA supporting non DOIC,  this optimization being optional.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 f=E9vrier 2014 10:09
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Yes, I agree with Steve.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange.com; dime@ietf.or=
g
Subject: Re: [Dime] Issue#35 conclusion

Lionel,

The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents.

I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case then t=
here is little benefit (and significant overhead) to requiring an agent to =
maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is the cas=
e then the reporting node should indicate that it only applies to the origi=
n-host in the request and only then should agents be required to maintain s=
tate for the non-supporting client.

Steve
On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:
I really don't understand but it is not the first time :)

What about the DOIC association? What about my assumption about agent maint=
aining overload control state for non-DOIC enabled client?
So for me, the proposal from Ulrich is a clarification on the agent behavio=
r that was implicit if you consider the comments above.

For me, the option for the server is only to send a specific OLR for a spec=
ific client. So over two different DOIC association with the same server/re=
porting node, you can have two different OLRs.
But it does not change the way the OLR is handled by reacting nodes.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Maria Cruz,

To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of the ba=
se specification, as it is likely that most/all applications will want the =
same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origin-Hos=
t reports should be specified in a common way.

Steve
On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
Hello again,

I forgot to mention something else in this thread, that I already mentioned=
 in related thread #56.

This is all in order to take into account 3GPP requirement on overload miti=
gation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".



Therefore, we can even consider this new OLR out of the base draft, and be =
considered by 3GPP applications when required.



Best regards

/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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


___________________________________________________________________________=
______________________________________________



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_087A34937E64E74E848732CFF8354B9209787161ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear Ulrich,


 <=
/p>

Being:<=
/p>

(0)&nb=
sp;  
OLR per client


(1)&nb=
sp;  
OLR for all clien=
ts


 <=
/p>

Some comments on the inte=
ractions you mentioned:


1.&nbs=
p;    
A fresh OLR of ty=
pe (1) makes all old OLRs of any type invalid


2.&nbs=
p;    
A fresh OLR of ty=
pe (0) makes an old OLR of type (0) bound to the same client invalid


3.&nbs=
p;    
A fresh OLR of ty=
pe (0) makes an old OLR of type (1) invalid


 <=
/p>

I do not think 3) is righ=
t. Why an OLR per one specific client shall invalidate OLRs for rest of cli=
ents? This will imply that rest of clients will not have
 any overload mitigation on until they receive a new value of (1), or (0) f=
or each of them.


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: mi=E9rcoles, 26 de febrero de 2014 12:23

To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Hi JJacques,



 


thank you for the summary=
.


 <=
/p>

I think it does not matte=
r whether we call


A)&nbs=
p;   
 “OLR =
per client” the base solution and “OLR for all clients” t=
he optimization or


B)&nbs=
p;   
“OLR for al=
l clients” the base solution and “OLR per client” the (3G=
PP) extension


as long as we cover both.=



 <=
/p>

I don’t think there=
 are impacts on sequence number handling, report types or DOIC associations=
.


 <=
/p>

My proposal then is to ad=
d a new mandatory AVP of type enumerated to OC-OLR with values


(0)&nb=
sp;  
OLR per client


(1)&nb=
sp;  
OLR for all clien=
ts


 <=
/p>

Reporting nodes that bett=
er like A) could allways send (0) unless they support the “optimizati=
on” and want to use it;


Reporting nodes that bett=
er like B) could allways send (1) unless they support the “(3GPP) ext=
ension” and want to use it.


Clients can safely ignore=
 the new AVP.


Agents taking the role of=
 the reacting node on behalf of a client must do the binding when receiving=
 (0).


 <=
/p>

We also need to say somet=
hing on interactions e.g.:


A fresh OLR of type (1) m=
akes all old OLRs of any type invalid


A fresh OLR of type (0) m=
akes an old OLR of type (0) bound to the same client invalid


A fresh OLR of type (0) m=
akes an old OLR of type (1) invalid


 <=
/p>

(i.e. change of type is a=
llowed, mixture is not allowed)


 <=
/p>

Ulrich<=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Wednesday, February 26, 2014 8:07 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Hi Steve, MCruz and all


 <=
/p>

On my side,  I agree=
 with Lionel.


 <=
/p>

I  have not the &nbs=
p;same reading of the draft where I have  not found the Steve’s =
default case.



I agree with Lionel that =
the OLR for a DOIC association relates to this DOIC association  and t=
he OLR can be different  for another DOIC association. The basic
 (or “default”) principle is that each DOIC association has its=
 “own life”.


 <=
/p>

Then,  a server (loc=
al policy) can decide  to send  the same OLR to all its clients (=
so for all its DOIC associations) , or it can define  particular OLR v=
alues
 for   certain clients. 


Another  interest &n=
bsp;is that  when the server wants to update the OLR values towards &n=
bsp;clients, it is  not obliged to send the new values  simultane=
ously  to all
 the clients : it may  (local server policy) progressively  chang=
e  the  value  over a certain duration  to minimize &nb=
sp;sharp transitions.


 <=
/p>

So for DOIC supporting cl=
ients, the current text allows these possibilities, and in particular it sa=
tisfies the 3GGP client mitigation requirement.


 <=
/p>

A second step is to addre=
ss DAs supporting non DOIC clients. Over time,  we may expect that cli=
ents will be more and more DOIC supporting; so, this is the main
 target. DAs with non DOIC client would be more for   a transitio=
n (to be considered  nevertheless and which may be long).


 <=
/p>

The current text says tha=
t DA is acting on behalf of “A” client; so principle  with=
 host OLR per DOIC association also applies, and there is no difference for
 the server, as this does not make a difference  between a DOIC suppor=
ting client and a DA supporting non DOIC clients.


Nevertheless, and here I =
come to Steve’s point,   this has a cost implying the DA to=
 manage OLRs per client. Steve  introduces an optimization where in fa=
ct
 a set of clients are considered for me as a pool regarding  DOIC wher=
e only one OLR applies and where throttling  applies  to the requ=
ests of this  pool of clients.  I am not against to optimization =
process   but this pool concept is new and needs some further
 study. First about the concept of DOIC association which evolves , as now =
linked to a pool .


 <=
/p>

There was a MCruz remark =
about sequence number, a new AVP or a  new report type.  I see th=
at  we may have to review  the processing of the seq number  =
;handling
 as also dependent of the new AVP or the OLR type; so   a “=
collateral “ effect of the optimization. I would also think that, ins=
tead of introducing a single node indication in the OLR (AVP or report type=
) , it should be a global indication as the optimization
   is to support a global DOIC association.  To also see if =
there are not other collateral effects to analyze.


 <=
/p>

Ulrich  also mention=
ed that for realm OLRs we may also have  a different realm  OLR s=
ent to different clients, so this is the same principle as Lionel  for
  a realm OLR per DOIC association, on which I agree.


 <=
/p>

The current text due to t=
he DOIC association principle,  allows this realm OLR per DOIC associa=
tion for both  DOIC  supporting clients and  DAs acting on b=
ehalf
 of A client. Then I expect Steve  to do the same remark, with the sam=
e reason  to have  an optimization  where all clients receiv=
es  the  same realm OLR, but to also see the collateral effects.



 <=
/p>

As a conclusion, I think =
we should remain with the current text as the baseline, following the DOIC =
association principle that Lionel mentions, and after more
 investigation to assess the  optimization  for host and realm OL=
Rs with DA supporting non DOIC,  this optimization being optional.


 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 25 f=E9vrier 2014 10:09

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Yes, I agree with Steve.<=
/span>


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:24

To: lionel.morand@orange=
.com;
dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Lionel,



The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents. 




I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case t=
hen there is little benefit (and significant
 overhead) to requiring an agent to maintain state per non-supporting clien=
t.



I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is th=
e case then the reporting node should indicate that it only applies to the =
origin-host in the request and only then
 should agents be required to maintain state for the non-supporting client.=




Steve




On 2/24/14 12:57 PM, 
lionel.morand@orange.com wrote:






I really don't understand=
 but it is not the first time
J


 <=
/p>

What about the DOIC assoc=
iation? What about my assumption about agent maintaining overload control s=
tate for non-DOIC enabled client?


So for me, the proposal f=
rom Ulrich is a clarification on the agent behavior that was implicit if yo=
u consider the comments above.


 <=
/p>

For me, the option for th=
e server is only to send a specific OLR for a specific client. So over two =
different DOIC association with the same server/reporting
 node, you can have two different OLRs.


But it does not change th=
e way the OLR is handled by reacting nodes.


 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 19:50

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Maria Cruz,



To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of t=
he base specification, as it is likely that most/all applications will want=
 the same behavior.



Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origi=
n-Host reports should be specified in a common way.



Steve




On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:






Hello=
 again,


 =
;


I for=
got to mention something else in this thread, that I already mentioned in r=
elated thread #56.


 =
;


This =
is all in order to take into account 3GPP requirement on overload mitigatio=
n differentiation per client. But this is a server option:


TR 29809 ch. 6.4.7.1 states "It=
 may be up to the server/agent implementations to decide when and whether o=
verload mitigation differentiation per client is used".


 


Therefore, we can even consider this=
 new OLR out of the base draft, and be considered by 3GPP applications when=
 required.


 


Best regards


/MCruz


 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: lunes, 24 de febrero de 2014 19:19

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Steve, all,




I agree with Steve.


 <=
/p>

However, I would like to =
share one concern. We need to avoid that existing (if any) host OLR (“=
;all-client”) in the reacting node is replaced by new host OLR
 (per client).


Host OLR (per client) wit=
h the new AVP requires that the server uses a new sequence number, but exis=
ting host OLR (all) shall not be replaced, on the contrary
 both Host OLR (all) and new Host OLR (per client) should remain.


In order to achieve this,=
 it could be more convenient to use a dedicated OLR type (host per client),=
 instead of a new AVP.


 <=
/p>

Let me know your opinions=
.


Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Adding an AVP to indi=
cate that a report applies just to the Origin-Host in the request is not ju=
st an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






I=
s it implicit? 


&=
nbsp;


I=
f the agent detects that a client is not supporting DOIC, this agent will h=
ave to store the corresponding overload control state on behalf of this cli=
ent and only this client (saying that other clients may support DOIC). I'm =
assuming then that any agent will have to store somewhere the origin-host o=
f this client. And therefore, I don't see what would be the added-value of =
this AVP saying that this OLR is only for this client.

&=
nbsp;


E=
ven if this AVP is present, it would not preclude a reporting node to alway=
s put this AVP in every answer, even if the OLR is the same for all the cli=
ents.


&=
nbsp;


R=
egards,


&=
nbsp;


L=
ionel


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces=
@ietf.org] De la part de Maria Cruz Bartolome


E=
nvoy=E9 : lundi 24 f=E9vrier 2014 14:27


=
=C0 : dime@ietf.org


O=
bjet : Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello Ulrich,


&=
nbsp;


I=
 haven't proposed to limit this to host type OLR, I just wanted to clarify =
if this is what JJ got in mind.


&=
nbsp;


I=
 agree it could be done as you explained in the example below, but the open=
 question is whether it is better to add an AVP when OLR is just meant for =
one single client, or on the contrary the agent _always_ need to bind OLR t=
o one specific client, even if the server simply requires same OLR for any =
client. 


&=
nbsp;


I=
 think having a new AVP simplifies agent behavior.


&=
nbsp;


B=
est regards


/=
MCruz


&=
nbsp;


-=
----Original Message-----


F=
rom: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


S=
ent: lunes, 24 de febrero de 2014 14:19


T=
o: Maria Cruz Bartolome; dime@ietf.org=



S=
ubject: RE: [Dime] Issue#35 conclusion


&=
nbsp;


H=
i MCruz,


t=
here is no reason to limit this to host type OLRs.


&=
nbsp;


I=
f we have an agent A that is configured to take the role of the reporting n=
ode for realm-type reports for realm R, A could receive host type OLRs from=
 servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduct=
ion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2);=
 A then would aggregate these info and return realm type OLRs to C1 request=
ing 20% reduction of traffic from C1 to R, and to C2 requesting 30% reducti=
on of traffic from C2 to R.


&=
nbsp;


B=
est regards


U=
lrich


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Maria Cruz Bartolome


S=
ent: Monday, February 24, 2014 2:02 PM


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello JJ and all,


&=
nbsp;


A=
s per email thread, the latest proposal is:


&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR." 


&=
nbsp;


A=
n Ulrich comments on this:


&=
quot;This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server."


&=
nbsp;


I=
s your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 


B=
est regards


/=
MCruz


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)


S=
ent: lunes, 24 de febrero de 2014 13:43


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
i Mcruz and all


&=
nbsp;


I=
 think that you are  mixing the case of the DA that is the "repor=
ting" node which wants to indicate a realm OLR to clients, and for whi=
ch will use various (non standardized ) ways to determine among which it ca=
n reuse the Host-OLR AVPs received from various servers. But in this case, =
clients receiving realm OLRs are supporting DOIC. 


H=
ere I understand the on going  discussion is about the DA behavior whe=
n  clients is not supporting DOIC and to reuse the Host-OLR received f=
or one client for other clients  .


&=
nbsp;


F=
or me I remain on  my previous mail, with a baseline solution. We may =
always study new extensions, optimizations, but priority should be on the b=
aseline.


&=
nbsp;


B=
est regards


&=
nbsp;


J=
acques 


&=
nbsp;


&=
nbsp;  


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces=
@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lundi 24 =
f=E9vrier 2014 13:21 =C0 : dime@ietf.=
org Objet : Re: [Dime] Issue#35 conclusion


&=
nbsp;


H=
ello all,


&=
nbsp;


N=
ot sure we all have the same understanding here.


L=
et me try to explain my concerns.


&=
nbsp;


T=
he original 3GPP requirement we want to cover is the need for a server to r=
educe traffic for one specific client, i.e. traffic identified by "Ori=
gin-Host" in the request.


T=
hen, two options are under analysis about whether or not the OLR in the ser=
ver answer shall be marked:


&=
nbsp;


a=
) OLR does not need to include anything else Receiver of the answer (and OL=
R) is the client that sends the request, identified by "Origin-Host&qu=
ot; in the request.


T=
hen, as long as the reacting node=3D=3D"Origin-Host", the expecte=
d reduction is performed and requirement fulfilled.


B=
ut, when an agent is acting on behalf of a client as the reacting node, the=
n the "Origin-Host" identifies final client, but not the reacting=
 node.


T=
hen, this is why the proposal is to add following clarification about agent=
 behavior (possible clause 5.5):


&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR."


B=
ut this will imply that _always_ the reacting node applies this OLR to one =
specific client, what is not what we need to achieve.

H=
ow will this impact the case where the agent is providing access to a Realm=
? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider f=
ollowing example:


-=
 C1 sends a Realm request via Agent, that finally reaches S1


-=
 S1 answers with OLR (Host:50%).


-=
 Agent is acting as reacting node on behalf of C1, if it considers this OLR=
 only bind to C1... then... should it consider S1-OLR only as relevant for =
requests coming from C1? Should agent do not use this S1-OLR to calculate a=
ggregated Realm overload?


I=
n my opinion, in this case it does not make sense to consider OLR was only =
meant to C1. And this problem could be solved adding explicit information, =
as in b) below.


&=
nbsp;


b=
) OLR needs to be extended (new AVP) that identifies the client ("Orig=
in-Host" in the request) from which traffic reduction shall apply.


W=
ith this new AVP, reacting node will easy be able to identify when OLR shal=
l be applied to any client or just to the Origin-Host identified by new AVP=
.


&=
nbsp;


L=
et me know your opinions please


B=
est regards


/=
MCruz


&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

S=
ent: lunes, 24 de febrero de 2014 12:28


T=
o: ext Steve Donovan; dime@ietf.org


S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


S=
teve,


&=
nbsp;


p=
lease see inline.


&=
nbsp;


U=
lrich


&=
nbsp;


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Steve Donovan


S=
ent: Friday, February 21, 2014 4:53 PM


T=
o: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


U=
lrich,


&=
nbsp;


I=
 have a couple of concerns with this approach, as currently outlined. =
 


&=
nbsp;


F=
irst, how do we handle the case where there are multiple DOIC supporting ag=
ents between the non supporting client and the reporting node.  This, =
I guess, is a general question, not just applying to this proposal.  I=
 suggest we capture in the agent behavior section that is currently missing=
 wording indicating that the first supporting agent that receives the reque=
st must be the reacting node for that non-supporting client.  Subseque=
nt DOIC supporting agents must not be the reacting node for the non-support=
ing client.


&=
lt;Ulrich>I fully agree</Ulrich>


&=
nbsp;


&=
nbsp;


W=
e need to think through the ramifications of having multiple agents being t=
he reacting node for the same non supporting clients, as this could easily =
happen in networks where multiple agents are involved in a single transacti=
on.  On the surface it doesn't seem to be an issue for the loss algori=
thm, but this might not be the case with other algorithms.


&=
lt;Ulrich>I agree that this is not an issue for loss; it is an issue e.g=
. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>


&=
nbsp;


M=
y other concern is that this puts a lot of extra onus on the agent even for=
 the case where the reporting node does not want to differentiate overload =
reports.


&=
lt;Ulrich> I agree </Ulrich>


T=
o this end I suggest we add an indication in the OLR marking the reports th=
at are specific to just the Origin-Host in the request.  Absence of th=
e "single-client-only" AVP would mean that the report applies to =
all clients.  Presence of the AVP would indicate that the OLR applies =
to the Origin-Host.


&=
lt;Ulrich>I understand that the proposal is an optimization for agents. =
Therefore the semantics of the marking should be reverse: unmarked OLRs are=
 client specific, marked OLRs indicate that the reporting node does not wan=
t to differentiate, and therefore allow agents not to do the binding to the=
 client.</Ulrich>     


&=
nbsp;


S=
teve


O=
n 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:=



B=
en,


&=
nbsp;


t=
he proposed conclusion was based on comments received so far (from Lionel, =
Nirav, Steve, MCruz, JJ). 


N=
ow you seem to address two points:


a=
) There is no dependency to DOIC support of the client.

T=
o address this I would like to propose rewording of the clarifying text for=
 5.5. as follows:


&=
nbsp;


W=
hen an agent takes the role of a reacting node, the agent needs to bind a r=
eceived OLR to the origin host of the client that initiated the request whi=
ch corresponds to the answer containing the OLR. 


&=
nbsp;


T=
his would cover not only the case where an agent takes the role of the reac=
ting node on behalf of a (or several) non supporting client, but also the c=
ase where an agent is configured to take the role of a reporting node (for =
realm-type reports) towards the client and at the same time the role of a r=
eacting node towards the server.


&=
nbsp;


b=
) There is no binding of the OLR to the orig-host of the client Here I disa=
gree. We have the 3GPP requirement to allow requesting different amount of =
reduction from different clients, and I think we have 3 options:


1=
. ignore the 3GPP requirement


2=
. introduce new report types as originally proposed in #35 3. introduce the=
 binding between OLR and orig-host of the client.


&=
nbsp;


S=
o far I understood that people favoured option 3.


&=
nbsp;


S=
ee also inline.


&=
nbsp;


U=
lrich


&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: ext Ben Campbell [mailto:ben@nostru=
m.com]


S=
ent: Thursday, February 20, 2014 11:55 PM


T=
o: Wiehe, Ulrich (NSN - DE/Munich)


C=
c: dime@ietf.org

S=
ubject: Re: [Dime] Issue#35 conclusion


&=
nbsp;


&=
nbsp;


O=
n Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:


&=
nbsp;


#=
35: additional report types are proposed


 =



D=
ear all,


 =



I=
 believe we can conclude, not to add additional report types. However, we a=
greed to add clarifying text to clause 5.5 as follows:

 =



W=
hen an agent received an OLR in response to a request initiated by a client=
 not supporting DOIC, this agent needs to bind the received OLR to the orig=
in-host of the client.


&=
nbsp;


I=
 do not agree.


&=
nbsp;


Y=
ou proposal implies that the server's OLR only applies to that client.


&=
lt;Ulrich>exactly, that was the intention</Ulrich>  If there'=
s an intervening DOIC agent, then the agent, not the client, is the reactin=
g node from the server's perspective.


&=
lt;Ulrich> the server's perspective is agnostic. The server does not kno=
w whether it's the client or an agent on the path that takes the role of th=
e reacting node</Ulrich>  But, short of adding an origin-host ty=
pe, nothing binds the OLR to a particular client, regardless of DOIC suppor=
t at the clients.


&=
lt;Ulrich> the binding is always there, regardless of DOIC support at th=
e client</Ulrich>


&=
nbsp;


 =
Whether or not the client also supports DOIC doesn't change that. For DOIC-=
supporting clients, the agent has the additional option of reducing traffic=
 by asking the clients to reduce traffic (making them reacting nodes from t=
he perspective of the _agent_, but not the server.)  It doesn't have t=
hat option for non-DOIC clients.


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


&=
nbsp;


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.=



I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.


&=
nbsp;


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


&=
nbsp;




 











_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime




 


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


&=
nbsp;


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.=



I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.




 






--_000_087A34937E64E74E848732CFF8354B9209787161ESESSMB101erics_--


From nobody Thu Feb 27 09:15:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348271A0401 for ; Thu, 27 Feb 2014 09:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAr-Mp8hCu7o for ; Thu, 27 Feb 2014 09:15:22 -0800 (PST)
Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) by ietfa.amsl.com (Postfix) with ESMTP id 802A21A03AB for ; Thu, 27 Feb 2014 09:15:22 -0800 (PST)
Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id 95B68253; Thu, 27 Feb 2014 17:15:20 +0000 (UTC)
Received: from G9W3616.americas.hpqcorp.net (16.216.186.51) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 27 Feb 2014 17:14:13 +0000
Received: from G9W0747.americas.hpqcorp.net ([169.254.4.56]) by G9W3616.americas.hpqcorp.net ([16.216.186.51]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 17:14:13 +0000
From: "Askerup, Anders" 
To: Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: AQHPMwYOwHyLYIFFpUiNcO4nB3MBYJrJVwvg
Date: Thu, 27 Feb 2014 17:14:12 +0000
Message-ID: <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com>
In-Reply-To: <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.210.48.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ez0vCFpehhxOl73-nZpjNYvabJw
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 27 Feb 2014 17:15:24 -0000

I also agree that including OC-Supported-Features in every answer is prefer=
able. In addition to mirroring Requests, it is in-line with how Supported-F=
eatures are managed in at least some 3GPP interfaces as well.

/Anders

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Wednesday, February 26, 2014 9:19 AM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Feb 26, 2014, at 9:14 AM, Steve Donovan  wrote=
:

> SRD> We don't have consensus yet, but if we agree on the need for reactin=
g nodes to know whether there is support for DOIC in the Diameter network t=
hen I think the requirement would be similar to how we are handling overloa=
d reports.  The reporting node MUST ensure that all reacting nodes receive =
the OC-Supported-Features AVP.  This can be done by including the AVP in al=
l answer messages or it can be done by remembering to whom the AVP has been=
 sent.

Given the trivial nature of sending and reading OC-Supported-Features, I th=
ink we should put it in every answer. This mirrors the way we handle it in =
requests.

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


From nobody Thu Feb 27 09:47:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DC71A0382 for ; Thu, 27 Feb 2014 09:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVclUiDDYJzr for ; Thu, 27 Feb 2014 09:47:15 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 870F81A037B for ; Thu, 27 Feb 2014 09:47:14 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1RHl93C031887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 18:47:09 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1RHl9eL019011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 18:47:09 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 27 Feb 2014 18:47:09 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 18:47:08 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAABdR0aQAC5d2AAAC4oAAAAFtYgAAAPiMAAADxZgAAHM0YAAAuChOAAAj34gAAMkHSoAAPR2vw
Date: Thu, 27 Feb 2014 17:47:08 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <53077659.1030909@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B43B7@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784859@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920978489B@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4441@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209787161@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209787161@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.125]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 141920
X-purgate-ID: 151667::1393523230-00005322-CDC6A6EE/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rs-n6dGvDbbFI6dLI55tgFC5FbM
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 27 Feb 2014 17:47:32 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear MCruz,

certainly a valid point. I don't have a strong view but I wanted to avoid t=
he mixture to keep things simple.
Maybe we should forbid the change from 1 to 0 during an ongoing overload.

Anyway, I don't think this is a blocking point for the proposal to add the =
new AVP.

Best regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, February 27, 2014 5:13 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Dear Ulrich,

Being:

(0)    OLR per client

(1)    OLR for all clients

Some comments on the interactions you mentioned:

1.       A fresh OLR of type (1) makes all old OLRs of any type invalid

2.       A fresh OLR of type (0) makes an old OLR of type (0) bound to the =
same client invalid

3.       A fresh OLR of type (0) makes an old OLR of type (1) invalid

I do not think 3) is right. Why an OLR per one specific client shall invali=
date OLRs for rest of clients? This will imply that rest of clients will no=
t have any overload mitigation on until they receive a new value of (1), or=
 (0) for each of them.

Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: mi=E9rcoles, 26 de febrero de 2014 12:23
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi JJacques,

thank you for the summary.

I think it does not matter whether we call

A)      "OLR per client" the base solution and "OLR for all clients" the op=
timization or

B)      "OLR for all clients" the base solution and "OLR per client" the (3=
GPP) extension
as long as we cover both.

I don't think there are impacts on sequence number handling, report types o=
r DOIC associations.

My proposal then is to add a new mandatory AVP of type enumerated to OC-OLR=
 with values

(0)    OLR per client

(1)    OLR for all clients

Reporting nodes that better like A) could allways send (0) unless they supp=
ort the "optimization" and want to use it;
Reporting nodes that better like B) could allways send (1) unless they supp=
ort the "(3GPP) extension" and want to use it.
Clients can safely ignore the new AVP.
Agents taking the role of the reacting node on behalf of a client must do t=
he binding when receiving (0).

We also need to say something on interactions e.g.:
A fresh OLR of type (1) makes all old OLRs of any type invalid
A fresh OLR of type (0) makes an old OLR of type (0) bound to the same clie=
nt invalid
A fresh OLR of type (0) makes an old OLR of type (1) invalid

(i.e. change of type is allowed, mixture is not allowed)

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Wednesday, February 26, 2014 8:07 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Steve, MCruz and all

On my side,  I agree with Lionel.

I  have not the  same reading of the draft where I have  not found the Stev=
e's default case.
I agree with Lionel that the OLR for a DOIC association relates to this DOI=
C association  and the OLR can be different  for another DOIC association. =
The basic (or "default") principle is that each DOIC association has its "o=
wn life".

Then,  a server (local policy) can decide  to send  the same OLR to all its=
 clients (so for all its DOIC associations) , or it can define  particular =
OLR values for   certain clients.
Another  interest  is that  when the server wants to update the OLR values =
towards  clients, it is  not obliged to send the new values  simultaneously=
  to all the clients : it may  (local server policy) progressively  change =
 the  value  over a certain duration  to minimize  sharp transitions.

So for DOIC supporting clients, the current text allows these possibilities=
, and in particular it satisfies the 3GGP client mitigation requirement.

A second step is to address DAs supporting non DOIC clients. Over time,  we=
 may expect that clients will be more and more DOIC supporting; so, this is=
 the main target. DAs with non DOIC client would be more for   a transition=
 (to be considered  nevertheless and which may be long).

The current text says that DA is acting on behalf of "A" client; so princip=
le  with host OLR per DOIC association also applies, and there is no differ=
ence for the server, as this does not make a difference  between a DOIC sup=
porting client and a DA supporting non DOIC clients.
Nevertheless, and here I come to Steve's point,   this has a cost implying =
the DA to manage OLRs per client. Steve  introduces an optimization where i=
n fact a set of clients are considered for me as a pool regarding  DOIC whe=
re only one OLR applies and where throttling  applies  to the requests of t=
his  pool of clients.  I am not against to optimization process   but this =
pool concept is new and needs some further study. First about the concept o=
f DOIC association which evolves , as now linked to a pool .

There was a MCruz remark about sequence number, a new AVP or a  new report =
type.  I see that  we may have to review  the processing of the seq number =
 handling as also dependent of the new AVP or the OLR type; so   a "collate=
ral " effect of the optimization. I would also think that, instead of intro=
ducing a single node indication in the OLR (AVP or report type) , it should=
 be a global indication as the optimization   is to support a global DOIC a=
ssociation.  To also see if there are not other collateral effects to analy=
ze.

Ulrich  also mentioned that for realm OLRs we may also have  a different re=
alm  OLR sent to different clients, so this is the same principle as Lionel=
  for  a realm OLR per DOIC association, on which I agree.

The current text due to the DOIC association principle,  allows this realm =
OLR per DOIC association for both  DOIC  supporting clients and  DAs acting=
 on behalf of A client. Then I expect Steve  to do the same remark, with th=
e same reason  to have  an optimization  where all clients receives  the  s=
ame realm OLR, but to also see the collateral effects.

As a conclusion, I think we should remain with the current text as the base=
line, following the DOIC association principle that Lionel mentions, and af=
ter more investigation to assess the  optimization  for host and realm OLRs=
 with DA supporting non DOIC,  this optimization being optional.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 f=E9vrier 2014 10:09
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Yes, I agree with Steve.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange.com; dime@ietf.or=
g
Subject: Re: [Dime] Issue#35 conclusion

Lionel,

The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents.

I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case then t=
here is little benefit (and significant overhead) to requiring an agent to =
maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is the cas=
e then the reporting node should indicate that it only applies to the origi=
n-host in the request and only then should agents be required to maintain s=
tate for the non-supporting client.

Steve
On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:
I really don't understand but it is not the first time :)

What about the DOIC association? What about my assumption about agent maint=
aining overload control state for non-DOIC enabled client?
So for me, the proposal from Ulrich is a clarification on the agent behavio=
r that was implicit if you consider the comments above.

For me, the option for the server is only to send a specific OLR for a spec=
ific client. So over two different DOIC association with the same server/re=
porting node, you can have two different OLRs.
But it does not change the way the OLR is handled by reacting nodes.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Maria Cruz,

To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of the ba=
se specification, as it is likely that most/all applications will want the =
same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origin-Hos=
t reports should be specified in a common way.

Steve
On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
Hello again,

I forgot to mention something else in this thread, that I already mentioned=
 in related thread #56.

This is all in order to take into account 3GPP requirement on overload miti=
gation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio=
ns to decide when and whether overload mitigation differentiation per clien=
t is used".



Therefore, we can even consider this new OLR out of the base draft, and be =
considered by 3GPP applications when required.



Best regards

/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing =
(if any) host OLR ("all-client") in the reacting node is replaced by new ho=
st OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new =
sequence number, but existing host OLR (all) shall not be replaced, on the =
contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OL=
R type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior then it =
would be best to have the default, implicit, meaning of an overload report =
to be "applies to all reacting nodes".  The real value of this new feature =
is to allow a server to further throttle a specific, overly active, reactin=
g node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.

- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:
  - For transactions from DOIC-supporting clients the agent must not act on=
 the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply =
the OLR to traffic from the set of non supporting clients.   This implies t=
hat when making throttling decisions, the agent does not differentiate whic=
h non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.

Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording indep=
endent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

Is it implicit?



If the agent detects that a client is not supporting DOIC, this agent will =
have to store the corresponding overload control state on behalf of this cl=
ient and only this client (saying that other clients may support DOIC). I'm=
 assuming then that any agent will have to store somewhere the origin-host =
of this client. And therefore, I don't see what would be the added-value of=
 this AVP saying that this OLR is only for this client.



Even if this AVP is present, it would not preclude a reporting node to alwa=
ys put this AVP in every answer, even if the OLR is the same for all the cl=
ients.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion



Hello Ulrich,



I haven't proposed to limit this to host type OLR, I just wanted to clarify=
 if this is what JJ got in mind.



I agree it could be done as you explained in the example below, but the ope=
n question is whether it is better to add an AVP when OLR is just meant for=
 one single client, or on the contrary the agent _always_ need to bind OLR =
to one specific client, even if the server simply requires same OLR for any=
 client.



I think having a new AVP simplifies agent behavior.



Best regards

/MCruz



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: lunes, 24 de febrero de 2014 14:19

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion



Hi MCruz,

there is no reason to limit this to host type OLRs.



If we have an agent A that is configured to take the role of the reporting =
node for realm-type reports for realm R, A could receive host type OLRs fro=
m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc=
tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)=
; A then would aggregate these info and return realm type OLRs to C1 reques=
ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct=
ion of traffic from C2 to R.



Best regards

Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome

Sent: Monday, February 24, 2014 2:02 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hello JJ and all,



As per email thread, the latest proposal is:

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."



An Ulrich comments on this:

"This would cover not only the case where an agent takes the role of the re=
acting node on behalf of a (or several) non supporting client, but also the=
 case where an agent is configured to take the role of a reporting node (fo=
r realm-type reports) towards the client and at the same time the role of a=
 reacting node towards the server."



Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded?

Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)

Sent: lunes, 24 de febrero de 2014 13:43

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Hi Mcruz and all



I think that you are  mixing the case of the DA that is the "reporting" nod=
e which wants to indicate a realm OLR to clients, and for which will use va=
rious (non standardized ) ways to determine among which it can reuse the Ho=
st-OLR AVPs received from various servers. But in this case, clients receiv=
ing realm OLRs are supporting DOIC.

Here I understand the on going  discussion is about the DA behavior when  c=
lients is not supporting DOIC and to reuse the Host-OLR received for one cl=
ient for other clients  .



For me I remain on  my previous mail, with a baseline solution. We may alwa=
ys study new extensions, optimizations, but priority should be on the basel=
ine.



Best regards



Jacques







-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=
 Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion



Hello all,



Not sure we all have the same understanding here.

Let me try to explain my concerns.



The original 3GPP requirement we want to cover is the need for a server to =
reduce traffic for one specific client, i.e. traffic identified by "Origin-=
Host" in the request.

Then, two options are under analysis about whether or not the OLR in the se=
rver answer shall be marked:



a) OLR does not need to include anything else Receiver of the answer (and O=
LR) is the client that sends the request, identified by "Origin-Host" in th=
e request.

Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti=
on is performed and requirement fulfilled.

But, when an agent is acting on behalf of a client as the reacting node, th=
en the "Origin-Host" identifies final client, but not the reacting node.

Then, this is why the proposal is to add following clarification about agen=
t behavior (possible clause 5.5):

"When an agent takes the role of a reacting node, the agent needs to bind a=
 received OLR to the origin host of the client that initiated the request w=
hich corresponds to the answer containing the OLR."

But this will imply that _always_ the reacting node applies this OLR to one=
 specific client, what is not what we need to achieve.

How will this impact the case where the agent is providing access to a Real=
m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll=
owing example:

- C1 sends a Realm request via Agent, that finally reaches S1

- S1 answers with OLR (Host:50%).

- Agent is acting as reacting node on behalf of C1, if it considers this OL=
R only bind to C1... then... should it consider S1-OLR only as relevant for=
 requests coming from C1? Should agent do not use this S1-OLR to calculate =
aggregated Realm overload?

In my opinion, in this case it does not make sense to consider OLR was only=
 meant to C1. And this problem could be solved adding explicit information,=
 as in b) below.



b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H=
ost" in the request) from which traffic reduction shall apply.

With this new AVP, reacting node will easy be able to identify when OLR sha=
ll be applied to any client or just to the Origin-Host identified by new AV=
P.



Let me know your opinions please

Best regards

/MCruz







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 12:28

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Steve,



please see inline.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Friday, February 21, 2014 4:53 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion



Ulrich,



I have a couple of concerns with this approach, as currently outlined.



First, how do we handle the case where there are multiple DOIC supporting a=
gents between the non supporting client and the reporting node.  This, I gu=
ess, is a general question, not just applying to this proposal.  I suggest =
we capture in the agent behavior section that is currently missing wording =
indicating that the first supporting agent that receives the request must b=
e the reacting node for that non-supporting client.  Subsequent DOIC suppor=
ting agents must not be the reacting node for the non-supporting client.

I fully agree





We need to think through the ramifications of having multiple agents being =
the reacting node for the same non supporting clients, as this could easily=
 happen in networks where multiple agents are involved in a single transact=
ion.  On the surface it doesn't seem to be an issue for the loss algorithm,=
 but this might not be the case with other algorithms.

I agree that this is not an issue for loss; it is an issue e.g. for=
 rate (i.e. for draft-donovan-dime-doc-rate-control)



My other concern is that this puts a lot of extra onus on the agent even fo=
r the case where the reporting node does not want to differentiate overload=
 reports.

 I agree 

To this end I suggest we add an indication in the OLR marking the reports t=
hat are specific to just the Origin-Host in the request.  Absence of the "s=
ingle-client-only" AVP would mean that the report applies to all clients.  =
Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I understand that the proposal is an optimization for agents. There=
fore the semantics of the marking should be reverse: unmarked OLRs are clie=
nt specific, marked OLRs indicate that the reporting node does not want to =
differentiate, and therefore allow agents not to do the binding to the clie=
nt.



Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Ben,



the proposed conclusion was based on comments received so far (from Lionel,=
 Nirav, Steve, MCruz, JJ).

Now you seem to address two points:

a) There is no dependency to DOIC support of the client.

To address this I would like to propose rewording of the clarifying text fo=
r 5.5. as follows:



When an agent takes the role of a reacting node, the agent needs to bind a =
received OLR to the origin host of the client that initiated the request wh=
ich corresponds to the answer containing the OLR.



This would cover not only the case where an agent takes the role of the rea=
cting node on behalf of a (or several) non supporting client, but also the =
case where an agent is configured to take the role of a reporting node (for=
 realm-type reports) towards the client and at the same time the role of a =
reacting node towards the server.



b) There is no binding of the OLR to the orig-host of the client Here I dis=
agree. We have the 3GPP requirement to allow requesting different amount of=
 reduction from different clients, and I think we have 3 options:

1. ignore the 3GPP requirement

2. introduce new report types as originally proposed in #35 3. introduce th=
e binding between OLR and orig-host of the client.



So far I understood that people favoured option 3.



See also inline.



Ulrich







-----Original Message-----

From: ext Ben Campbell [mailto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion





On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:



#35: additional report types are proposed



Dear all,



I believe we can conclude, not to add additional report types. However, we =
agreed to add clarifying text to clause 5.5 as follows:



When an agent received an OLR in response to a request initiated by a clien=
t not supporting DOIC, this agent needs to bind the received OLR to the ori=
gin-host of the client.



I do not agree.



You proposal implies that the server's OLR only applies to that client.

exactly, that was the intention  If there's an intervening=
 DOIC agent, then the agent, not the client, is the reacting node from the =
server's perspective.

 the server's perspective is agnostic. The server does not know whe=
ther it's the client or an agent on the path that takes the role of the rea=
cting node  But, short of adding an origin-host type, nothing bind=
s the OLR to a particular client, regardless of DOIC support at the clients=
.

 the binding is always there, regardless of DOIC support at the cli=
ent



 Whether or not the client also supports DOIC doesn't change that. For DOIC=
-supporting clients, the agent has the additional option of reducing traffi=
c by asking the clients to reduce traffic (making them reacting nodes from =
the perspective of the _agent_, but not the server.)  It doesn't have that =
option for non-DOIC clients.



_______________________________________________

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



_______________________________________________

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



___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

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


___________________________________________________________________________=
______________________________________________



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_5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear MCruz=
,


 =
;


certainly =
a valid point. I don’t have a strong view but I wanted to avoid the m=
ixture to keep things simple.



Maybe we s=
hould forbid the change from 1 to 0 during an ongoing overload.<=
/span>


 =
;


Anyway, I =
don’t think this is a blocking point for the proposal to add the new =
AVP.


 =
;


Best regar=
ds


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, February 27, 2014 5:13 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Dear Ulric=
h,


 =
;


Being:


(0)   
OL=
R per client


(1)   
OL=
R for all clients


 =
;


Some comme=
nts on the interactions you mentioned:


1.      
A =
fresh OLR of type (1) makes all old OLRs of any type invalid


2.      
A =
fresh OLR of type (0) makes an old OLR of type (0) bound to the same client=
 invalid


3.      
A =
fresh OLR of type (0) makes an old OLR of type (1) invalid


 =
;


I do not t=
hink 3) is right. Why an OLR per one specific client shall invalidate OLRs =
for rest of clients? This will imply that rest of clients
 will not have any overload mitigation on until they receive a new value of=
 (1), or (0) for each of them.


 =
;


Best regar=
ds


/MCruz


 =
;


 =
;






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: mi=E9rcoles, 26 de febrero de 2014 12:23

To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); 
dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Hi JJacques,



 <=
/p>

thank you =
for the summary.


 =
;


I think it=
 does not matter whether we call


A)    
&n=
bsp;“OLR per client” the base solution and “OLR for all c=
lients” the optimization or


B)     
&#=
8220;OLR for all clients” the base solution and “OLR per client=
” the (3GPP) extension


as long as=
 we cover both.


 =
;


I don̵=
7;t think there are impacts on sequence number handling, report types or DO=
IC associations.


 =
;


My proposa=
l then is to add a new mandatory AVP of type enumerated to OC-OLR with valu=
es


(0)   
OL=
R per client


(1)   
OL=
R for all clients


 =
;


Reporting =
nodes that better like A) could allways send (0) unless they support the &#=
8220;optimization” and want to use it;


Reporting =
nodes that better like B) could allways send (1) unless they support the &#=
8220;(3GPP) extension” and want to use it.


Clients ca=
n safely ignore the new AVP.


Agents tak=
ing the role of the reacting node on behalf of a client must do the binding=
 when receiving (0).


 =
;


We also ne=
ed to say something on interactions e.g.:


A fresh OL=
R of type (1) makes all old OLRs of any type invalid


A fresh OL=
R of type (0) makes an old OLR of type (0) bound to the same client invalid=



A fresh OL=
R of type (0) makes an old OLR of type (1) invalid


 =
;


(i.e. chan=
ge of type is allowed, mixture is not allowed)


 =
;


Ulrich


 =
;


 =
;






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Wednesday, February 26, 2014 8:07 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Hi Steve, =
MCruz and all


 =
;


On my side=
,  I agree with Lionel.


 =
;


I  ha=
ve not the  same reading of the draft where I have  not found the=
 Steve’s default case.



I agree wi=
th Lionel that the OLR for a DOIC association relates to this DOIC associat=
ion  and the OLR can be different  for another DOIC association.
 The basic (or “default”) principle is that each DOIC associati=
on has its “own life”.


 =
;


Then, &nbs=
p;a server (local policy) can decide  to send  the same OLR to al=
l its clients (so for all its DOIC associations) , or it can define  p=
articular
 OLR values for   certain clients. 


Another &n=
bsp;interest  is that  when the server wants to update the OLR va=
lues towards  clients, it is  not obliged to send the new values =
 simultaneously
  to all the clients : it may  (local server policy) progressivel=
y  change  the  value  over a certain duration  to=
 minimize  sharp transitions.


 =
;


So for DOI=
C supporting clients, the current text allows these possibilities, and in p=
articular it satisfies the 3GGP client mitigation requirement.


 =
;


A second s=
tep is to address DAs supporting non DOIC clients. Over time,  we may =
expect that clients will be more and more DOIC supporting; so,
 this is the main target. DAs with non DOIC client would be more for  =
 a transition (to be considered  nevertheless and which may be lo=
ng).


 =
;


The curren=
t text says that DA is acting on behalf of “A” client; so princ=
iple  with host OLR per DOIC association also applies, and there is no
 difference for the server, as this does not make a difference  betwee=
n a DOIC supporting client and a DA supporting non DOIC clients.=



Neverthele=
ss, and here I come to Steve’s point,   this has a cost imp=
lying the DA to manage OLRs per client. Steve  introduces an optimizat=
ion
 where in fact a set of clients are considered for me as a pool regarding &=
nbsp;DOIC where only one OLR applies and where throttling  applies &nb=
sp;to the requests of this  pool of clients.  I am not against to=
 optimization process   but this pool concept is new and
 needs some further study. First about the concept of DOIC association whic=
h evolves , as now linked to a pool .


 =
;


There was =
a MCruz remark about sequence number, a new AVP or a  new report type.=
  I see that  we may have to review  the processing of the s=
eq
 number  handling as also dependent of the new AVP or the OLR type; so=
   a “collateral “ effect of the optimization. I woul=
d also think that, instead of introducing a single node indication in the O=
LR (AVP or report type) , it should be a global indication
 as the optimization   is to support a global DOIC association. &=
nbsp;To also see if there are not other collateral effects to analyze.=



 =
;


Ulrich &nb=
sp;also mentioned that for realm OLRs we may also have  a different re=
alm  OLR sent to different clients, so this is the same principle as
 Lionel  for  a realm OLR per DOIC association, on which I agree.=



 =
;


The curren=
t text due to the DOIC association principle,  allows this realm OLR p=
er DOIC association for both  DOIC  supporting clients and  =
DAs
 acting on behalf of A client. Then I expect Steve  to do the same rem=
ark, with the same reason  to have  an optimization  where a=
ll clients receives  the  same realm OLR, but to also see the col=
lateral effects.



 =
;


As a concl=
usion, I think we should remain with the current text as the baseline, foll=
owing the DOIC association principle that Lionel mentions,
 and after more investigation to assess the  optimization  for ho=
st and realm OLRs with DA supporting non DOIC,  this optimization bein=
g optional.


 =
;


Best regar=
ds


 =
;


JJacques



 =
;






De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 25 f=E9vrier 2014 10:09

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Yes, I agr=
ee with Steve.


 


Best regar=
ds


/MCruz


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 20:24

To: lionel.morand@orange=
.com;
dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion<=
o:p>






 


=
Lionel,



The question is whether the reporting node is sending the overload report p=
er client or it is sending a global overload report that applies to all cli=
ents. 




I still believe that the default behavior of a reporting node will be to ha=
ve a single overload reduction value for the application and that that over=
load reduction value will apply to all clients.  If this is the case t=
hen there is little benefit (and significant
 overhead) to requiring an agent to maintain state per non-supporting clien=
t.



I also agree that there is value to the reporting node being able to have a=
 different reduction value for specific reacting nodes.  If this is th=
e case then the reporting node should indicate that it only applies to the =
origin-host in the request and only then
 should agents be required to maintain state for the non-supporting client.=




Steve




On 2/24/14 12:57 PM, 
lionel.morand@orange.com wrote:






I really d=
on't understand but it is not the first time
J


 


What about=
 the DOIC association? What about my assumption about agent maintaining ove=
rload control state for non-DOIC enabled client?


So for me,=
 the proposal from Ulrich is a clarification on the agent behavior that was=
 implicit if you consider the comments above.


 


For me, th=
e option for the server is only to send a specific OLR for a specific clien=
t. So over two different DOIC association with the same server/reporting
 node, you can have two different OLRs.


But it doe=
s not change the way the OLR is handled by reacting nodes.


 


Lionel


 






De&nb=
sp;: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 19:50

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


=
Maria Cruz,



To the degree possible we should minimize the per application overload logi=
c required.  To this end, it would be better to have this as part of t=
he base specification, as it is likely that most/all applications will want=
 the same behavior.



Whether a reporting node uses per Origin-Host reports is an implementation =
detail of the reporting node.  How reacting nodes respond to per Origi=
n-Host reports should be specified in a common way.



Steve




On 2/24/14 12:40 PM, Maria Cruz=
 Bartolome wrote:






Hello again,


 


I forgot to mention something else in this thread, that I already=
 mentioned in related thread #56.


 


This is all in order to take into account 3GPP requirement on ove=
rload mitigation differentiation per client. But this is a server option:


TR 29809 ch. 6.4.7.1 =
states "It may be up to the server/agent implementations to decide whe=
n and whether overload mitigation differentiation per client is
 used".


 


Therefore, we can eve=
n consider this new OLR out of the base draft, and be considered by 3GPP ap=
plications when required.


 


Best regards


/MCruz


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Maria Cruz Bartolome

Sent: lunes, 24 de febrero de 2014 19:19

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion<=
o:p>






 


Steve, all=
,




I agree with Steve.


 


However, I=
 would like to share one concern. We need to avoid that existing (if any) h=
ost OLR (“all-client”) in the reacting node is replaced by
 new host OLR (per client).

Host OLR (=
per client) with the new AVP requires that the server uses a new sequence n=
umber, but existing host OLR (all) shall not be replaced,
 on the contrary both Host OLR (all) and new Host OLR (per client) should r=
emain.


In order t=
o achieve this, it could be more convenient to use a dedicated OLR type (ho=
st per client), instead of a new AVP.


 


Let me kno=
w your opinions.


Best regar=
ds


/MCruz


 


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: lunes, 24 de febrero de 2014 16:56

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion<=
o:p>






 


=
Adding an AVP to indicate that a report applies just to the Origin-Host in =
the request is not just an optimization for agents.



It had been my assumption all along that the default behavior of a reportin=
g node (server) would be to report a single overload value to all reacting =
nodes, be they clients or agents.  If this is the default behavior the=
n it would be best to have the default,
 implicit, meaning of an overload report to be "applies to all reactin=
g nodes".  The real value of this new feature is to allow a serve=
r to further throttle a specific, overly active, reacting node when then gl=
obal reduction percentage doesn't do the job.



In addition, if the normal case is that reporting nodes have a single globa=
l reduction percentage then requiring agents to bind an overload report to =
each non supporting clients pushes a lot of extra work on agents when it ad=
ds no value.



My proposal is the following:



- Add an optional AVP (call it something like Single-Node???) to overload r=
eports that indicate when an overload report applies to a specific reacting=
 node.



- Absence of the AVP indicates that the report applies to all reacting node=
s (clients and agents acting on behalf of non-DOIC clients).



- Reporting nodes should only include the Single-Node AVP if the overload r=
eport contents are different from the global overload report.



- DOIC-supporting agents receiving an OLR without the Single-Node AVP must =
do the following:

  - For transactions from DOIC-supporting clients the agent must not a=
ct on the OLR.

  - For transactions from non-DOIC-supporting clients the agent must a=
pply the OLR to traffic from the set of non supporting clients.   This=
 implies that when making throttling decisions, the agent does not differen=
tiate which non supporting client originated
 the request.



- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr=
ansaction originated by a non supporting client must bind that OLR to that =
single client.



Note that the agent behavior is currently something that is missing from th=
e -01 version of the draft.  We will need something like this wording =
independent of the resolution of this issue.



Steve




On 2/24/14 8:06 AM, 
lionel.morand@orange.com wrote:






Is it implicit? 


 


If the agent detects that a client is not supporting DOIC, th=
is agent will have to store the corresponding overload control state on beh=
alf of this client and only this client (saying that other clients may supp=
ort DOIC). I'm assuming then that any agent will have to store somewhere th=
e origin-host of this client. And therefore, I don't see what would be the =
added-value of this AVP saying that this OLR is only for this client.


 


Even if this AVP is present, it would not preclude a reportin=
g node to always put this AVP in every answer, even if the OLR is the same =
for all the clients.


 


Regards,


 


Lionel


 


-----Message d'origine-----<=
/o:p>


De : DiME [mail=
to:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27


=C0 : dime@ietf.org=



Objet : Re: [Dime] Issue#35 conclusion


 


Hello Ulrich,

 


I haven't proposed to limit this to host type OLR, I just wan=
ted to clarify if this is what JJ got in mind.<=
o:p>


 


I agree it could be done as you explained in the example belo=
w, but the open question is whether it is better to add an AVP when OLR is =
just meant for one single client, or on the contrary the agent _always_ nee=
d to bind OLR to one specific client, even if the server simply requires sa=
me OLR for any client. 


 


I think having a new AVP simplifies agent behavior.


 


Best regards

/MCruz


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: lunes, 24 de febrero de 2014 14:19


To: Maria Cruz Bartolome; di=
me@ietf.org


Subject: RE: [Dime] Issue#35 conclusion


 


Hi MCruz,


there is no reason to limit this to host type OLRs.


 


If we have an agent A that is configured to take the role of =
the reporting node for realm-type reports for realm R, A could receive host=
 type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1=
 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% red=
uctin from C2); A then would aggregate these info and return realm type OLR=
s to C1 requesting 20% reduction of traffic from C1 to R, and to C2 request=
ing 30% reduction of traffic from C2 to R.=



 


Best regards

Ulrich


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome


Sent: Monday, February 24, 2014 2:02 PM


To: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


Hello JJ and all,


 


As per email thread, the latest proposal is:


"When an agent takes the role of a reacting node, the ag=
ent needs to bind a received OLR to the origin host of the client that init=
iated the request which corresponds to the answer containing the OLR."=
 


 


An Ulrich comments on this:<=
/o:p>


"This would cover not only the case where an agent takes=
 the role of the reacting node on behalf of a (or several) non supporting c=
lient, but also the case where an agent is configured to take the role of a=
 reporting node (for realm-type reports) towards the client and at the same=
 time the role of a reacting node towards the server."


 


Is your proposal limited to Host-OLR, i.e. Realm OLR is exclu=
ded? 


Best regards

/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: lunes, 24 de febrero de 2014 13:43


To: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


Hi Mcruz and all


 


I think that you are  mixing the case of the DA that is =
the "reporting" node which wants to indicate a realm OLR to clien=
ts, and for which will use various (non standardized ) ways to determine am=
ong which it can reuse the Host-OLR AVPs received from various servers. But=
 in this case, clients receiving realm OLRs are supporting DOIC. 


Here I understand the on going  discussion is about the =
DA behavior when  clients is not supporting DOIC and to reuse the Host=
-OLR received for one client for other clients  .


 


For me I remain on  my previous mail, with a baseline so=
lution. We may always study new extensions, optimizations, but priority sho=
uld be on the baseline.


 


Best regards

 


Jacques 


 


   

 


-----Message d'origine-----<=
/o:p>


De : DiME [mail=
to:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9&n=
bsp;: lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion


 


Hello all,

 


Not sure we all have the same understanding here.


Let me try to explain my concerns.


 


The original 3GPP requirement we want to cover is the need fo=
r a server to reduce traffic for one specific client, i.e. traffic identifi=
ed by "Origin-Host" in the request.


Then, two options are under analysis about whether or not the=
 OLR in the server answer shall be marked:=



 


a) OLR does not need to include anything else Receiver of the=
 answer (and OLR) is the client that sends the request, identified by "=
;Origin-Host" in the request.


Then, as long as the reacting node=3D=3D"Origin-Host&quo=
t;, the expected reduction is performed and requirement fulfilled.


But, when an agent is acting on behalf of a client as the rea=
cting node, then the "Origin-Host" identifies final client, but n=
ot the reacting node.


Then, this is why the proposal is to add following clarificat=
ion about agent behavior (possible clause 5.5):=



"When an agent takes the role of a reacting node, the ag=
ent needs to bind a received OLR to the origin host of the client that init=
iated the request which corresponds to the answer containing the OLR."=



But this will imply that _always_ the reacting node applies t=
his OLR to one specific client, what is not what we need to achieve.=



How will this impact the case where the agent is providing ac=
cess to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. L=
et's consider following example:


- C1 sends a Realm request via Agent, that finally reaches S1=



- S1 answers with OLR (Host:50%).=



- Agent is acting as reacting node on behalf of C1, if it con=
siders this OLR only bind to C1... then... should it consider S1-OLR only a=
s relevant for requests coming from C1? Should agent do not use this S1-OLR=
 to calculate aggregated Realm overload?


In my opinion, in this case it does not make sense to conside=
r OLR was only meant to C1. And this problem could be solved adding explici=
t information, as in b) below.


 


b) OLR needs to be extended (new AVP) that identifies the cli=
ent ("Origin-Host" in the request) from which traffic reduction s=
hall apply.


With this new AVP, reacting node will easy be able to identif=
y when OLR shall be applied to any client or just to the Origin-Host identi=
fied by new AVP.


 


Let me know your opinions please<=
o:p>


Best regards

/MCruz


 


 


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)


Sent: lunes, 24 de febrero de 2014 12:28


To: ext Steve Donovan; dime@=
ietf.org


Subject: Re: [Dime] Issue#35 conclusion


 


Steve,


 


please see inline.


 


Ulrich


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of ext Steve Donovan


Sent: Friday, February 21, 2014 4:53 PM


To: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


Ulrich,


 


I have a couple of concerns with this approach, as currently =
outlined.  


 


First, how do we handle the case where there are multiple DOI=
C supporting agents between the non supporting client and the reporting nod=
e.  This, I guess, is a general question, not just applying to this pr=
oposal.  I suggest we capture in the agent behavior section that is cu=
rrently missing wording indicating that the first supporting agent that rec=
eives the request must be the reacting node for that non-supporting client.=
  Subsequent DOIC supporting agents must not be the reacting node for =
the non-supporting client.

<Ulrich>I fully agree</Ulrich>


 


 


We need to think through the ramifications of having multiple=
 agents being the reacting node for the same non supporting clients, as thi=
s could easily happen in networks where multiple agents are involved in a s=
ingle transaction.  On the surface it doesn't seem to be an issue for =
the loss algorithm, but this might not be the case with other algorithms.


<Ulrich>I agree that this is not an issue for loss; it =
is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)<=
;/Ulrich>


 


My other concern is that this puts a lot of extra onus on the=
 agent even for the case where the reporting node does not want to differen=
tiate overload reports.


<Ulrich> I agree </Ulrich>


To this end I suggest we add an indication in the OLR marking=
 the reports that are specific to just the Origin-Host in the request. =
; Absence of the "single-client-only" AVP would mean that the rep=
ort applies to all clients.  Presence of the AVP would indicate that t=
he OLR applies to the Origin-Host.


<Ulrich>I understand that the proposal is an optimizati=
on for agents. Therefore the semantics of the marking should be reverse: un=
marked OLRs are client specific, marked OLRs indicate that the reporting no=
de does not want to differentiate, and therefore allow agents not to do the=
 binding to the client.</Ulrich>     


 


Steve


On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


Ben,


 


the proposed conclusion was based on comments received so far=
 (from Lionel, Nirav, Steve, MCruz, JJ). <=
/o:p>


Now you seem to address two points:


a) There is no dependency to DOIC support of the client.


To address this I would like to propose rewording of the clar=
ifying text for 5.5. as follows:


 


When an agent takes the role of a reacting node, the agent ne=
eds to bind a received OLR to the origin host of the client that initiated =
the request which corresponds to the answer containing the OLR. 


 


This would cover not only the case where an agent takes the r=
ole of the reacting node on behalf of a (or several) non supporting client,=
 but also the case where an agent is configured to take the role of a repor=
ting node (for realm-type reports) towards the client and at the same time =
the role of a reacting node towards the server.=



 


b) There is no binding of the OLR to the orig-host of the cli=
ent Here I disagree. We have the 3GPP requirement to allow requesting diffe=
rent amount of reduction from different clients, and I think we have 3 opti=
ons:


1. ignore the 3GPP requirement


2. introduce new report types as originally proposed in #35 3=
. introduce the binding between OLR and orig-host of the client.


 


So far I understood that people favoured option 3.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [ma=
ilto:ben@nostrum.com]

Sent: Thursday, February 20, 2014 11:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org=



Subject: Re: [Dime] Issue#35 conclusion


 


 


On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) =
<ulrich.wiehe@nsn.com> wr=
ote:


 


#35: additional report types are proposed


 


Dear all,


 


I believe we can conclude, not to add additional report types=
. However, we agreed to add clarifying text to clause 5.5 as follows:


 


When an agent received an OLR in response to a request initia=
ted by a client not supporting DOIC, this agent needs to bind the received =
OLR to the origin-host of the client.


 


I do not agree.=



 


You proposal implies that the server's OLR only applies to th=
at client.


<Ulrich>exactly, that was the intention</Ulrich>&=
nbsp; If there's an intervening DOIC agent, then the agent, not the client,=
 is the reacting node from the server's perspective.


<Ulrich> the server's perspective is agnostic. The serv=
er does not know whether it's the client or an agent on the path that takes=
 the role of the reacting node</Ulrich>  But, short of adding an=
 origin-host type, nothing binds the OLR to a particular client, regardless=
 of DOIC support at the clients.


<Ulrich> the binding is always there, regardless of DOI=
C support at the client</Ulrich>


 


 Whether or not the client also supports DOIC doesn't change =
that. For DOIC-supporting clients, the agent has the additional option of r=
educing traffic by asking the clients to reduce traffic (making them reacti=
ng nodes from the perspective of the _agent_, but not the server.)  It=
 doesn't have that option for non-DOIC clients.=



 


_______________________________________________


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


 


_______________________________________________


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


 


_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.

 


_______________________________________________


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




 


_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.



 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2DEMUMBX014nsnin_--


From nobody Thu Feb 27 12:30:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350071A0665 for ; Thu, 27 Feb 2014 12:11:08 -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
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 tH9PeCptxRxe for ; Thu, 27 Feb 2014 12:10:56 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05B1A01DD for ; Thu, 27 Feb 2014 12:10:56 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50267 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WJ7I3-0003Gt-O9 for dime@ietf.org; Thu, 27 Feb 2014 12:10:54 -0800
Message-ID: <530F9BC3.1010003@usdonovans.com>
Date: Thu, 27 Feb 2014 14:10:43 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209787161@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060204080409000703000007"
X-OutGoing-Spam-Status: No, score=-2.9
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
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8iY62KPOGBVmFGt3rX61dOjbxl8
X-Mailman-Approved-At: Thu, 27 Feb 2014 12:30:06 -0800
Subject: Re: [Dime] Issue#35 conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 27 Feb 2014 20:11:08 -0000

This is a multi-part message in MIME format.
--------------060204080409000703000007
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I think if you change number three to the following then it works better.

  3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for
the client to which the answer message is being routed.  The agent shall
apply the OLR or type (0) for traffic from that client. The old OLR of
type (1) continues to apply for all clients that do not have a "per
client" overload report.

I think it is important for a reporting node to be able to start with an
"all clients" overload report and then transition to "per client"
reports for chatty clients.

Steve


On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Dear MCruz,
>
>  
>
> certainly a valid point. I don't have a strong view but I wanted to
> avoid the mixture to keep things simple.
>
> Maybe we should forbid the change from 1 to 0 during an ongoing overload.
>
>  
>
> Anyway, I don't think this is a blocking point for the proposal to add
> the new AVP.
>
>  
>
> Best regards
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Thursday, February 27, 2014 5:13 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Dear Ulrich,
>
>  
>
> Being:
>
> (0)    OLR per client
>
> (1)    OLR for all clients
>
>  
>
> Some comments on the interactions you mentioned:
>
> 1.       A fresh OLR of type (1) makes all old OLRs of any type invalid
>
> 2.       A fresh OLR of type (0) makes an old OLR of type (0) bound to
> the same client invalid
>
> 3.       A fresh OLR of type (0) makes an old OLR of type (1) invalid
>
>  
>
> I do not think 3) is right. Why an OLR per one specific client shall
> invalidate OLRs for rest of clients? This will imply that rest of
> clients will not have any overload mitigation on until they receive a
> new value of (1), or (0) for each of them.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Wiehe,
> Ulrich (NSN - DE/Munich)
> *Sent:* miércoles, 26 de febrero de 2014 12:23
> *To:* ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
> 
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Hi JJacques,
>
>  
>
> thank you for the summary.
>
>  
>
> I think it does not matter whether we call
>
> A)      "OLR per client" the base solution and "OLR for all clients"
> the optimization or
>
> B)      "OLR for all clients" the base solution and "OLR per client"
> the (3GPP) extension
>
> as long as we cover both.
>
>  
>
> I don't think there are impacts on sequence number handling, report
> types or DOIC associations.
>
>  
>
> My proposal then is to add a new mandatory AVP of type enumerated to
> OC-OLR with values
>
> (0)    OLR per client
>
> (1)    OLR for all clients
>
>  
>
> Reporting nodes that better like A) could allways send (0) unless they
> support the "optimization" and want to use it;
>
> Reporting nodes that better like B) could allways send (1) unless they
> support the "(3GPP) extension" and want to use it.
>
> Clients can safely ignore the new AVP.
>
> Agents taking the role of the reacting node on behalf of a client must
> do the binding when receiving (0).
>
>  
>
> We also need to say something on interactions e.g.:
>
> A fresh OLR of type (1) makes all old OLRs of any type invalid
>
> A fresh OLR of type (0) makes an old OLR of type (0) bound to the same
> client invalid
>
> A fresh OLR of type (0) makes an old OLR of type (1) invalid
>
>  
>
> (i.e. change of type is allowed, mixture is not allowed)
>
>  
>
> Ulrich
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* Wednesday, February 26, 2014 8:07 AM
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Hi Steve, MCruz and all
>
>  
>
> On my side,  I agree with Lionel.
>
>  
>
> I  have not the  same reading of the draft where I have  not found the
> Steve's default case.
>
> I agree with Lionel that the OLR for a DOIC association relates to
> this DOIC association  and the OLR can be different  for another DOIC
> association. The basic (or "default") principle is that each DOIC
> association has its "own life".
>
>  
>
> Then,  a server (local policy) can decide  to send  the same OLR to
> all its clients (so for all its DOIC associations) , or it can define
>  particular OLR values for   certain clients.
>
> Another  interest  is that  when the server wants to update the OLR
> values towards  clients, it is  not obliged to send the new values
>  simultaneously  to all the clients : it may  (local server policy)
> progressively  change  the  value  over a certain duration  to
> minimize  sharp transitions.
>
>  
>
> So for DOIC supporting clients, the current text allows these
> possibilities, and in particular it satisfies the 3GGP client
> mitigation requirement.
>
>  
>
> A second step is to address DAs supporting non DOIC clients. Over
> time,  we may expect that clients will be more and more DOIC
> supporting; so, this is the main target. DAs with non DOIC client
> would be more for   a transition (to be considered  nevertheless and
> which may be long).
>
>  
>
> The current text says that DA is acting on behalf of "A" client; so
> principle  with host OLR per DOIC association also applies, and there
> is no difference for the server, as this does not make a difference
>  between a DOIC supporting client and a DA supporting non DOIC clients.
>
> Nevertheless, and here I come to Steve's point,   this has a cost
> implying the DA to manage OLRs per client. Steve  introduces an
> optimization where in fact a set of clients are considered for me as a
> pool regarding  DOIC where only one OLR applies and where throttling
>  applies  to the requests of this  pool of clients.  I am not against
> to optimization process   but this pool concept is new and needs some
> further study. First about the concept of DOIC association which
> evolves , as now linked to a pool .
>
>  
>
> There was a MCruz remark about sequence number, a new AVP or a  new
> report type.  I see that  we may have to review  the processing of the
> seq number  handling as also dependent of the new AVP or the OLR type;
> so   a "collateral " effect of the optimization. I would also think
> that, instead of introducing a single node indication in the OLR (AVP
> or report type) , it should be a global indication as the optimization
>   is to support a global DOIC association.  To also see if there are
> not other collateral effects to analyze.
>
>  
>
> Ulrich  also mentioned that for realm OLRs we may also have  a
> different realm  OLR sent to different clients, so this is the same
> principle as Lionel  for  a realm OLR per DOIC association, on which I
> agree.
>
>  
>
> The current text due to the DOIC association principle,  allows this
> realm OLR per DOIC association for both  DOIC  supporting clients and
>  DAs acting on behalf of A client. Then I expect Steve  to do the same
> remark, with the same reason  to have  an optimization  where all
> clients receives  the  same realm OLR, but to also see the collateral
> effects.
>
>  
>
> As a conclusion, I think we should remain with the current text as the
> baseline, following the DOIC association principle that Lionel
> mentions, and after more investigation to assess the  optimization 
> for host and realm OLRs with DA supporting non DOIC,  this
> optimization being optional.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 25 février 2014 10:09
> *À :* dime@ietf.org 
> *Objet :* Re: [Dime] Issue#35 conclusion
>
>  
>
> Yes, I agree with Steve.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 20:24
> *To:* lionel.morand@orange.com ;
> dime@ietf.org 
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Lionel,
>
> The question is whether the reporting node is sending the overload
> report per client or it is sending a global overload report that
> applies to all clients. 
>
> I still believe that the default behavior of a reporting node will be
> to have a single overload reduction value for the application and that
> that overload reduction value will apply to all clients.  If this is
> the case then there is little benefit (and significant overhead) to
> requiring an agent to maintain state per non-supporting client.
>
> I also agree that there is value to the reporting node being able to
> have a different reduction value for specific reacting nodes.  If this
> is the case then the reporting node should indicate that it only
> applies to the origin-host in the request and only then should agents
> be required to maintain state for the non-supporting client.
>
> Steve
>
> On 2/24/14 12:57 PM, lionel.morand@orange.com
>  wrote:
>
>     I really don't understand but it is not the first time J
>
>      
>
>     What about the DOIC association? What about my assumption about
>     agent maintaining overload control state for non-DOIC enabled client?
>
>     So for me, the proposal from Ulrich is a clarification on the
>     agent behavior that was implicit if you consider the comments above.
>
>      
>
>     For me, the option for the server is only to send a specific OLR
>     for a specific client. So over two different DOIC association with
>     the same server/reporting node, you can have two different OLRs.
>
>     But it does not change the way the OLR is handled by reacting nodes.
>
>      
>
>     Lionel
>
>      
>
>     *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve
>     Donovan
>     *Envoyé :* lundi 24 février 2014 19:50
>     *À :* dime@ietf.org 
>     *Objet :* Re: [Dime] Issue#35 conclusion
>
>      
>
>     Maria Cruz,
>
>     To the degree possible we should minimize the per application
>     overload logic required.  To this end, it would be better to have
>     this as part of the base specification, as it is likely that
>     most/all applications will want the same behavior.
>
>     Whether a reporting node uses per Origin-Host reports is an
>     implementation detail of the reporting node.  How reacting nodes
>     respond to per Origin-Host reports should be specified in a common
>     way.
>
>     Steve
>
>     On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
>
>         Hello again,
>
>          
>
>         I forgot to mention something else in this thread, that I
>         already mentioned in related thread #56.
>
>          
>
>         This is all in order to take into account 3GPP requirement on
>         overload mitigation differentiation per client. But this is a
>         server option:
>
>         TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent
>         implementations to decide when and whether overload mitigation
>         differentiation per client is used".
>
>          
>
>         Therefore, we can even consider this new OLR out of the base
>         draft, and be considered by 3GPP applications when required.
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *Maria Cruz Bartolome
>         *Sent:* lunes, 24 de febrero de 2014 19:19
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Issue#35 conclusion
>
>          
>
>         Steve, all,
>
>
>         I agree with Steve.
>
>          
>
>         However, I would like to share one concern. We need to avoid
>         that existing (if any) host OLR ("all-client") in the reacting
>         node is replaced by new host OLR (per client).
>
>         Host OLR (per client) with the new AVP requires that the
>         server uses a new sequence number, but existing host OLR (all)
>         shall not be replaced, on the contrary both Host OLR (all) and
>         new Host OLR (per client) should remain.
>
>         In order to achieve this, it could be more convenient to use a
>         dedicated OLR type (host per client), instead of a new AVP.
>
>          
>
>         Let me know your opinions.
>
>         Best regards
>
>         /MCruz
>
>          
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *Steve Donovan
>         *Sent:* lunes, 24 de febrero de 2014 16:56
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Issue#35 conclusion
>
>          
>
>         Adding an AVP to indicate that a report applies just to the
>         Origin-Host in the request is not just an optimization for agents.
>
>         It had been my assumption all along that the default behavior
>         of a reporting node (server) would be to report a single
>         overload value to all reacting nodes, be they clients or
>         agents.  If this is the default behavior then it would be best
>         to have the default, implicit, meaning of an overload report
>         to be "applies to all reacting nodes".  The real value of this
>         new feature is to allow a server to further throttle a
>         specific, overly active, reacting node when then global
>         reduction percentage doesn't do the job.
>
>         In addition, if the normal case is that reporting nodes have a
>         single global reduction percentage then requiring agents to
>         bind an overload report to each non supporting clients pushes
>         a lot of extra work on agents when it adds no value.
>
>         My proposal is the following:
>
>         - Add an optional AVP (call it something like Single-Node???)
>         to overload reports that indicate when an overload report
>         applies to a specific reacting node.
>
>         - Absence of the AVP indicates that the report applies to all
>         reacting nodes (clients and agents acting on behalf of
>         non-DOIC clients).
>
>         - Reporting nodes should only include the Single-Node AVP if
>         the overload report contents are different from the global
>         overload report.
>
>         - DOIC-supporting agents receiving an OLR without the
>         Single-Node AVP must do the following:
>           - For transactions from DOIC-supporting clients the agent
>         must not act on the OLR.
>           - For transactions from non-DOIC-supporting clients the
>         agent must apply the OLR to traffic from the set of non
>         supporting clients.   This implies that when making throttling
>         decisions, the agent does not differentiate which non
>         supporting client originated the request.
>
>         - DOIC-supporting agents receiving an OLR with the Single-Node
>         AVP for a transaction originated by a non supporting client
>         must bind that OLR to that single client.
>
>         Note that the agent behavior is currently something that is
>         missing from the -01 version of the draft.  We will need
>         something like this wording independent of the resolution of
>         this issue.
>
>         Steve
>
>         On 2/24/14 8:06 AM, lionel.morand@orange.com
>          wrote:
>
>             Is it implicit? 
>
>              
>
>             If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.
>
>              
>
>             Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.
>
>              
>
>             Regards,
>
>              
>
>             Lionel
>
>              
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
>
>             Envoyé : lundi 24 février 2014 14:27
>
>             À : dime@ietf.org 
>
>             Objet : Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hello Ulrich,
>
>              
>
>             I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.
>
>              
>
>             I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 
>
>              
>
>             I think having a new AVP simplifies agent behavior.
>
>              
>
>             Best regards
>
>             /MCruz
>
>              
>
>             -----Original Message-----
>
>             From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>
>             Sent: lunes, 24 de febrero de 2014 14:19
>
>             To: Maria Cruz Bartolome; dime@ietf.org 
>
>             Subject: RE: [Dime] Issue#35 conclusion
>
>              
>
>             Hi MCruz,
>
>             there is no reason to limit this to host type OLRs.
>
>              
>
>             If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.
>
>              
>
>             Best regards
>
>             Ulrich
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
>
>             Sent: Monday, February 24, 2014 2:02 PM
>
>             To: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hello JJ and all,
>
>              
>
>             As per email thread, the latest proposal is:
>
>             "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 
>
>              
>
>             An Ulrich comments on this:
>
>             "This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."
>
>              
>
>             Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
>
>             Best regards
>
>             /MCruz
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>             Sent: lunes, 24 de febrero de 2014 13:43
>
>             To: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hi Mcruz and all
>
>              
>
>             I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
>
>             Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .
>
>              
>
>             For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.
>
>              
>
>             Best regards
>
>              
>
>             Jacques 
>
>              
>
>                
>
>              
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org  Objet : Re: [Dime] Issue#35 conclusion
>
>              
>
>             Hello all,
>
>              
>
>             Not sure we all have the same understanding here.
>
>             Let me try to explain my concerns.
>
>              
>
>             The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.
>
>             Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:
>
>              
>
>             a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
>
>             Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
>
>             But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
>
>             Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):
>
>             "When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."
>
>             But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.
>
>             How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:
>
>             - C1 sends a Realm request via Agent, that finally reaches S1
>
>             - S1 answers with OLR (Host:50%).
>
>             - Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?
>
>             In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.
>
>              
>
>             b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.
>
>             With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.
>
>              
>
>             Let me know your opinions please
>
>             Best regards
>
>             /MCruz
>
>              
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
>
>             Sent: lunes, 24 de febrero de 2014 12:28
>
>             To: ext Steve Donovan; dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Steve,
>
>              
>
>             please see inline.
>
>              
>
>             Ulrich
>
>              
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>
>             Sent: Friday, February 21, 2014 4:53 PM
>
>             To: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>             Ulrich,
>
>              
>
>             I have a couple of concerns with this approach, as currently outlined.  
>
>              
>
>             First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.
>
>             I fully agree
>
>              
>
>              
>
>             We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.
>
>             I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)
>
>              
>
>             My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.
>
>              I agree 
>
>             To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.
>
>             I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.     
>
>              
>
>             Steve
>
>             On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>             Ben,
>
>              
>
>             the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
>
>             Now you seem to address two points:
>
>             a) There is no dependency to DOIC support of the client.
>
>             To address this I would like to propose rewording of the clarifying text for 5.5. as follows:
>
>              
>
>             When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 
>
>              
>
>             This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.
>
>              
>
>             b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
>
>             1. ignore the 3GPP requirement
>
>             2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.
>
>              
>
>             So far I understood that people favoured option 3.
>
>              
>
>             See also inline.
>
>              
>
>             Ulrich
>
>              
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: ext Ben Campbell [mailto:ben@nostrum.com]
>
>             Sent: Thursday, February 20, 2014 11:55 PM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: dime@ietf.org 
>
>             Subject: Re: [Dime] Issue#35 conclusion
>
>              
>
>              
>
>             On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich)   wrote:
>
>              
>
>             #35: additional report types are proposed
>
>              
>
>             Dear all,
>
>              
>
>             I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>
>              
>
>             When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.
>
>              
>
>             I do not agree.
>
>              
>
>             You proposal implies that the server's OLR only applies to that client.
>
>             exactly, that was the intention  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
>
>              the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>
>              the binding is always there, regardless of DOIC support at the client
>
>              
>
>              Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.
>
>              
>
>             _______________________________________________
>
>             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
>
>              
>
>             _______________________________________________
>
>             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
>
>              
>
>             _________________________________________________________________________________________________________________________
>
>              
>
>             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.
>
>              
>
>             _______________________________________________
>
>             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
>
>      
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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.
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------060204080409000703000007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I think if you change
      number three to the following then it works better.

      

        3. A fresh OLR of type (0) makes an old OLR of type (1) invalid
      for the client to which the answer message is being routed.  The
      agent shall apply the OLR or type (0) for traffic from that
      client. The old OLR of type (1) continues to apply for all clients
      that do not have a "per client" overload report.

      

      I think it is important for a reporting node to be able to start
      with an "all clients" overload report and then transition to "per
      client" reports for chatty clients.

      

      Steve

      

      

    
    
On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Dear MCruz,

        
 

        
certainly a valid point. I don’t have a strong
            view but I wanted to avoid the mixture to keep things
            simple.
            

        
Maybe we should forbid the change from 1 to 0
            during an ongoing overload.

        
 

        
Anyway, I don’t think this is a blocking point
            for the proposal to add the new AVP.

        
 

        
Best regards

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Maria Cruz Bartolome

                Sent: Thursday, February 27, 2014 5:13 PM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Dear Ulrich,

        
 

        
Being:

        
(0)   
              OLR per client

        
(1)   
              OLR for all clients

        
 

        
Some comments on the interactions you
            mentioned:

        
1.      
              A fresh OLR of type (1) makes all old OLRs of
            any type invalid

        
2.      
              A fresh OLR of type (0) makes an old OLR of
            type (0) bound to the same client invalid

        
3.      
              A fresh OLR of type (0) makes an old OLR of
            type (1) invalid

        
 

        
I do not think 3) is right. Why an OLR per one
            specific client shall invalidate OLRs for rest of clients?
            This will imply that rest of clients will not have any
            overload mitigation on until they receive a new value of
            (1), or (0) for each of them.

        
 

        
Best regards

        
/MCruz

        
 

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

                Sent: miércoles, 26 de febrero de 2014 12:23

                To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); 
                  dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Hi
            JJacques,
            

        
 

        
thank you for the summary.

        
 

        
I think it does not matter whether we call

        
A)    
               “OLR per client” the base solution and “OLR
            for all clients” the optimization or

        
B)     
              “OLR for all clients” the base solution and
            “OLR per client” the (3GPP) extension

        
as long as we cover both.

        
 

        
I don’t think there are impacts on sequence
            number handling, report types or DOIC associations.

        
 

        
My proposal then is to add a new mandatory AVP
            of type enumerated to OC-OLR with values

        
(0)   
              OLR per client

        
(1)   
              OLR for all clients

        
 

        
Reporting nodes that better like A) could
            allways send (0) unless they support the “optimization” and
            want to use it;

        
Reporting nodes that better like B) could
            allways send (1) unless they support the “(3GPP) extension”
            and want to use it.

        
Clients can safely ignore the new AVP.

        
Agents taking the role of the reacting node on
            behalf of a client must do the binding when receiving (0).

        
 

        
We also need to say something on interactions
            e.g.:

        
A fresh OLR of type (1) makes all old OLRs of
            any type invalid

        
A fresh OLR of type (0) makes an old OLR of
            type (0) bound to the same client invalid

        
A fresh OLR of type (0) makes an old OLR of
            type (1) invalid

        
 

        
(i.e. change of type is allowed, mixture is not
            allowed)

        
 

        
Ulrich

        
 

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: Wednesday, February 26, 2014 8:07 AM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Hi Steve, MCruz and all

        
 

        
On my side,  I agree with Lionel.

        
 

        
I  have not the  same reading of the draft
            where I have  not found the Steve’s default case.
            

        
I agree with Lionel that the OLR for a DOIC
            association relates to this DOIC association  and the OLR
            can be different  for another DOIC association. The basic
            (or “default”) principle is that each DOIC association has
            its “own life”.

        
 

        
Then,  a server (local policy) can decide  to
            send  the same OLR to all its clients (so for all its DOIC
            associations) , or it can define  particular OLR values for
              certain clients. 

        
Another  interest  is that  when the server
            wants to update the OLR values towards  clients, it is  not
            obliged to send the new values  simultaneously  to all the
            clients : it may  (local server policy) progressively
             change  the  value  over a certain duration  to minimize
             sharp transitions.

        
 

        
So for DOIC supporting clients, the current
            text allows these possibilities, and in particular it
            satisfies the 3GGP client mitigation requirement.

        
 

        
A second step is to address DAs supporting non
            DOIC clients. Over time,  we may expect that clients will be
            more and more DOIC supporting; so, this is the main target.
            DAs with non DOIC client would be more for   a transition
            (to be considered  nevertheless and which may be long).

        
 

        
The current text says that DA is acting on
            behalf of “A” client; so principle  with host OLR per DOIC
            association also applies, and there is no difference for the
            server, as this does not make a difference  between a DOIC
            supporting client and a DA supporting non DOIC clients.

        
Nevertheless, and here I come to Steve’s point,
              this has a cost implying the DA to manage OLRs per client.
            Steve  introduces an optimization where in fact a set of
            clients are considered for me as a pool regarding  DOIC
            where only one OLR applies and where throttling  applies  to
            the requests of this  pool of clients.  I am not against to
            optimization process   but this pool concept is new and
            needs some further study. First about the concept of DOIC
            association which evolves , as now linked to a pool .

        
 

        
There was a MCruz remark about sequence number,
            a new AVP or a  new report type.  I see that  we may have to
            review  the processing of the seq number  handling as also
            dependent of the new AVP or the OLR type; so   a “collateral
            “ effect of the optimization. I would also think that,
            instead of introducing a single node indication in the OLR
            (AVP or report type) , it should be a global indication as
            the optimization   is to support a global DOIC association.
             To also see if there are not other collateral effects to
            analyze.

        
 

        
Ulrich  also mentioned that for realm OLRs we
            may also have  a different realm  OLR sent to different
            clients, so this is the same principle as Lionel  for  a
            realm OLR per DOIC association, on which I agree.

        
 

        
The current text due to the DOIC association
            principle,  allows this realm OLR per DOIC association for
            both  DOIC  supporting clients and  DAs acting on behalf of
            A client. Then I expect Steve  to do the same remark, with
            the same reason  to have  an optimization  where all clients
            receives  the  same realm OLR, but to also see the
            collateral effects.
            

        
 

        
As a conclusion, I think we should remain with
            the current text as the baseline, following the DOIC
            association principle that Lionel mentions, and after more
            investigation to assess the  optimization  for host and
            realm OLRs with DA supporting non DOIC,  this optimization
            being optional.

        
 

        
Best regards

        
 

        
JJacques
            

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : mardi 25 février 2014 10:09

                À : dime@ietf.org

                Objet : Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Yes, I agree with Steve.

        
 

        
Best regards

        
/MCruz

        
 

        

          

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

                Sent: lunes, 24 de febrero de 2014 20:24

                To: lionel.morand@orange.com;
                dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Lionel,

            

            The question is whether the reporting node is sending the
            overload report per client or it is sending a global
            overload report that applies to all clients. 
            

            

            I still believe that the default behavior of a reporting
            node will be to have a single overload reduction value for
            the application and that that overload reduction value will
            apply to all clients.  If this is the case then there is
            little benefit (and significant overhead) to requiring an
            agent to maintain state per non-supporting client.

            

            I also agree that there is value to the reporting node being
            able to have a different reduction value for specific
            reacting nodes.  If this is the case then the reporting node
            should indicate that it only applies to the origin-host in
            the request and only then should agents be required to
            maintain state for the non-supporting client.

            

            Steve

        

          
On 2/24/14 12:57 PM, 
                lionel.morand@orange.com wrote:

        

        

          
I really don't understand but it is not the
              first time
            J

          
 

          
What about the DOIC association? What about
              my assumption about agent maintaining overload control
              state for non-DOIC enabled client?

          
So for me, the proposal from Ulrich is a
              clarification on the agent behavior that was implicit if
              you consider the comments above.

          
 

          
For me, the option for the server is only to
              send a specific OLR for a specific client. So over two
              different DOIC association with the same server/reporting
              node, you can have two different OLRs.

          
But it does not change the way the OLR is
              handled by reacting nodes.

          
 

          
Lionel

          
 

          

            

              
De : DiME [mailto:dime-bounces@ietf.org]
                  De la part de Steve Donovan

                  Envoyé : lundi 24 février 2014 19:50

                  À : dime@ietf.org

                  Objet : Re: [Dime] Issue#35 conclusion

            

          

          
 

          
Maria Cruz,

              

              To the degree possible we should minimize the per
              application overload logic required.  To this end, it
              would be better to have this as part of the base
              specification, as it is likely that most/all applications
              will want the same behavior.

              

              Whether a reporting node uses per Origin-Host reports is
              an implementation detail of the reporting node.  How
              reacting nodes respond to per Origin-Host reports should
              be specified in a common way.

              

              Steve

          

            
On 2/24/14 12:40 PM,
                Maria Cruz Bartolome wrote:

          

          

            
Hello
                again,

            
 

            
I
                forgot to mention something else in this thread, that I
                already mentioned in related thread #56.

            
 

            
This
                is all in order to take into account 3GPP requirement on
                overload mitigation differentiation per client. But this
                is a server option:

            
TR 29809 ch. 6.4.7.1 states "It may be up
                to the server/agent implementations to decide when and
                whether overload mitigation differentiation per client
                is used".

            
 

            
Therefore, we can even consider this new
                OLR out of the base draft, and be considered by 3GPP
                applications when required.

            
 

            
Best regards

            
/MCruz

            
 

            

              

                
From: DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of Maria Cruz Bartolome

                    Sent: lunes, 24 de febrero de 2014 19:19

                    To: dime@ietf.org

                    Subject: Re: [Dime] Issue#35 conclusion

              

            

            
 

            
Steve, all,

            


                I agree with Steve.

            
 

            
However, I would like to share one concern.
                We need to avoid that existing (if any) host OLR
                (“all-client”) in the reacting node is replaced by new
                host OLR (per client).

            
Host OLR (per client) with the new AVP
                requires that the server uses a new sequence number, but
                existing host OLR (all) shall not be replaced, on the
                contrary both Host OLR (all) and new Host OLR (per
                client) should remain.

            
In order to achieve this, it could be more
                convenient to use a dedicated OLR type (host per
                client), instead of a new AVP.

            
 

            
Let me know your opinions.

            
Best regards

            
/MCruz

            
 

            
 

            

              

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

                    Sent: lunes, 24 de febrero de 2014 16:56

                    To: dime@ietf.org

                    Subject: Re: [Dime] Issue#35 conclusion

              

            

            
 

            
Adding an AVP to indicate that a report
                applies just to the Origin-Host in the request is not
                just an optimization for agents.

                

                It had been my assumption all along that the default
                behavior of a reporting node (server) would be to report
                a single overload value to all reacting nodes, be they
                clients or agents.  If this is the default behavior then
                it would be best to have the default, implicit, meaning
                of an overload report to be "applies to all reacting
                nodes".  The real value of this new feature is to allow
                a server to further throttle a specific, overly active,
                reacting node when then global reduction percentage
                doesn't do the job.

                

                In addition, if the normal case is that reporting nodes
                have a single global reduction percentage then requiring
                agents to bind an overload report to each non supporting
                clients pushes a lot of extra work on agents when it
                adds no value.

                

                My proposal is the following:

                

                - Add an optional AVP (call it something like
                Single-Node???) to overload reports that indicate when
                an overload report applies to a specific reacting node.

                

                - Absence of the AVP indicates that the report applies
                to all reacting nodes (clients and agents acting on
                behalf of non-DOIC clients).

                

                - Reporting nodes should only include the Single-Node
                AVP if the overload report contents are different from
                the global overload report.

                

                - DOIC-supporting agents receiving an OLR without the
                Single-Node AVP must do the following:

                  - For transactions from DOIC-supporting clients the
                agent must not act on the OLR.

                  - For transactions from non-DOIC-supporting clients
                the agent must apply the OLR to traffic from the set of
                non supporting clients.   This implies that when making
                throttling decisions, the agent does not differentiate
                which non supporting client originated the request.

                

                - DOIC-supporting agents receiving an OLR with the
                Single-Node AVP for a transaction originated by a non
                supporting client must bind that OLR to that single
                client.

                

                Note that the agent behavior is currently something that
                is missing from the -01 version of the draft.  We will
                need something like this wording independent of the
                resolution of this issue.

                

                Steve

            

              
On 2/24/14 8:06
                  AM, 
                    lionel.morand@orange.com wrote:

            

            

              
Is it implicit? 

              
 

              
If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.

              
 

              
Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.

              
 

              
Regards,

              
 

              
Lionel

              
 

              
-----Message d'origine-----

              
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

              
Envoyé : lundi 24 février 2014 14:27

              
À : dime@ietf.org

              
Objet : Re: [Dime] Issue#35 conclusion

              
 

              
Hello Ulrich,

              
 

              
I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.

              
 

              
I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 

              
 

              
I think having a new AVP simplifies agent behavior.

              
 

              
Best regards

              
/MCruz

              
 

              
-----Original Message-----

              
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

              
Sent: lunes, 24 de febrero de 2014 14:19

              
To: Maria Cruz Bartolome; dime@ietf.org

              
Subject: RE: [Dime] Issue#35 conclusion

              
 

              
Hi MCruz,

              
there is no reason to limit this to host type OLRs.

              
 

              
If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

              
 

              
Best regards

              
Ulrich

              
 

              
-----Original Message-----

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome

              
Sent: Monday, February 24, 2014 2:02 PM

              
To: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Hello JJ and all,

              
 

              
As per email thread, the latest proposal is:

              
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 

              
 

              
An Ulrich comments on this:

              
"This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."

              
 

              
Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 

              
Best regards

              
/MCruz

              
 

              
-----Original Message-----

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

              
Sent: lunes, 24 de febrero de 2014 13:43

              
To: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Hi Mcruz and all

              
 

              
I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 

              
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

              
 

              
For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

              
 

              
Best regards

              
 

              
Jacques 

              
 

              
   

              
 

              
-----Message d'origine-----

              
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion

              
 

              
Hello all,

              
 

              
Not sure we all have the same understanding here.

              
Let me try to explain my concerns.

              
 

              
The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.

              
Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:

              
 

              
a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.

              
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.

              
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.

              
Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):

              
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."

              
But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.

              
How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:

              
- C1 sends a Realm request via Agent, that finally reaches S1

              
- S1 answers with OLR (Host:50%).

              
- Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?

              
In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.

              
 

              
b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.

              
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

              
 

              
Let me know your opinions please

              
Best regards

              
/MCruz

              
 

              
 

              
 

              
-----Original Message-----

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

              
Sent: lunes, 24 de febrero de 2014 12:28

              
To: ext Steve Donovan; dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Steve,

              
 

              
please see inline.

              
 

              
Ulrich

              
 

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

              
Sent: Friday, February 21, 2014 4:53 PM

              
To: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
Ulrich,

              
 

              
I have a couple of concerns with this approach, as currently outlined.  

              
 

              
First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.

              
<Ulrich>I fully agree</Ulrich>

              
 

              
 

              
We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.

              
<Ulrich>I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>

              
 

              
My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.

              
<Ulrich> I agree </Ulrich>

              
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.

              
<Ulrich>I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

              
 

              
Steve

              
On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

              
Ben,

              
 

              
the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 

              
Now you seem to address two points:

              
a) There is no dependency to DOIC support of the client.

              
To address this I would like to propose rewording of the clarifying text for 5.5. as follows:

              
 

              
When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 

              
 

              
This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.

              
 

              
b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:

              
1. ignore the 3GPP requirement

              
2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.

              
 

              
So far I understood that people favoured option 3.

              
 

              
See also inline.

              
 

              
Ulrich

              
 

              
 

              
 

              
-----Original Message-----

              
From: ext Ben Campbell [mailto:ben@nostrum.com]

              
Sent: Thursday, February 20, 2014 11:55 PM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: dime@ietf.org

              
Subject: Re: [Dime] Issue#35 conclusion

              
 

              
 

              
On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

              
 

              
#35: additional report types are proposed

              
 

              
Dear all,

              
 

              
I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:

              
 

              
When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

              
 

              
I do not agree.

              
 

              
You proposal implies that the server's OLR only applies to that client.

              
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.

              
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

              
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

              
 

              
 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.

              
 

              
_______________________________________________

              
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

              
 

              
_______________________________________________

              
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

              
 

              
_________________________________________________________________________________________________________________________

              
 

              
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.

              
 

              
_______________________________________________

              
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

          

          
 

          
_________________________________________________________________________________________________________________________

          
 

          
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.

        

        
 

      

      

      

      

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


    

    

  


--------------060204080409000703000007--


From nobody Thu Feb 27 23:50:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288D11A040E for ; Thu, 27 Feb 2014 23:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCFLEu7IgfF6 for ; Thu, 27 Feb 2014 23:50:53 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 86EBE1A0081 for ; Thu, 27 Feb 2014 23:50:52 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1S7oj86007812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 08:50:45 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1S7ogqw017446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 08:50:44 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Feb 2014 08:50:42 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 08:50:42 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext Askerup, Anders" , Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A
Date: Fri, 28 Feb 2014 07:50:41 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net>
In-Reply-To: <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.156]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2258
X-purgate-ID: 151667::1393573846-00005322-EDBF05E5/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/S4RqT3-rxhuaa264-PaNlF6EdA0
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 07:50:56 -0000

Anders,

Yes, if we conclude that there is a requirement for OC-Supported-Features t=
o be sent in answers, then it should be included in every answer. However, =
I still don't see that requirement. In addition we would need some text spe=
cifying the expected behaviour of the reacting node when receiving OC-Suppo=
rted-Features in an answer, keeping in mind that the reacting node cannot k=
now whether it was the server or an agent that inserted the OC-Supported-Fe=
ature, and whether or not a subsequent request will be routed via that node=
.

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Anders
Sent: Thursday, February 27, 2014 6:14 PM
To: Ben Campbell; Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

I also agree that including OC-Supported-Features in every answer is prefer=
able. In addition to mirroring Requests, it is in-line with how Supported-F=
eatures are managed in at least some 3GPP interfaces as well.

/Anders

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Wednesday, February 26, 2014 9:19 AM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Feb 26, 2014, at 9:14 AM, Steve Donovan  wrote=
:

> SRD> We don't have consensus yet, but if we agree on the need for reactin=
g nodes to know whether there is support for DOIC in the Diameter network t=
hen I think the requirement would be similar to how we are handling overloa=
d reports.  The reporting node MUST ensure that all reacting nodes receive =
the OC-Supported-Features AVP.  This can be done by including the AVP in al=
l answer messages or it can be done by remembering to whom the AVP has been=
 sent.

Given the trivial nature of sending and reading OC-Supported-Features, I th=
ink we should put it in every answer. This mirrors the way we handle it in =
requests.

_______________________________________________
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 Fri Feb 28 05:48:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79521A049E for ; Fri, 28 Feb 2014 05:48:41 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBOISpiBjVAt for ; Fri, 28 Feb 2014 05:48:40 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 95BDF1A048A for ; Fri, 28 Feb 2014 05:48:39 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id ec20so2751338lab.29 for ; Fri, 28 Feb 2014 05:48:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wPgaGZF08Y5bADAs12MXDh37losClV3F9kZ7lfFRI8E=; b=kl6xlWzGKhUjgmVL5Dd1R+B2k0FMimb/qFo25qyDVjekpDw/0smlnkreREsVjiV1IZ cGc4zqpp8e/noeNKoExR62T2Ccmm74hGmayIVMEbVfQ+DdSZekow3Ef0RQRrO6cmkeu5 ZAOOMNMvFq6keQZhBpMWPkl1Rji0prY/VOPzMBeNOrPgB0K5N/5PDFAeClVNE3K2TIw/ YTQe4iMrQcUeLVUTA5fy8BB3gi7waZqU54N82mWliifBf9s1hCKSqjTIx/scG1V4RePy y/XHPa9qmI1tOZ4mcDacN1vTK0Ky9nLHNX4gtPHHAIFi7CtjBPEbnRcDXPnbamkBpvKm +s9w==
X-Received: by 10.152.6.199 with SMTP id d7mr11590825laa.22.1393595317059; Fri, 28 Feb 2014 05:48:37 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id q8sm4009955lbr.3.2014.02.28.05.48.32 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 05:48:32 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net>
Date: Fri, 28 Feb 2014 15:48:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Gs4R3AnhBZ347OYKAao4FNxVxaE
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 13:48:42 -0000



Right. We are going back and forth and continue to do that as long
as none of these moving parts can be nailed down. My proposal here
is that we simply agree now that OC-Supported-Features is in every
answer message. Period. Get one corner nailed down.

The rest of the fixing inconsistencies and missing/excess parts
listed below then need to be done according to the above decision.

- JOuni


On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Anders,
>=20
> Yes, if we conclude that there is a requirement for =
OC-Supported-Features to be sent in answers, then it should be included =
in every answer. However, I still don't see that requirement. In =
addition we would need some text specifying the expected behaviour of =
the reacting node when receiving OC-Supported-Features in an answer, =
keeping in mind that the reacting node cannot know whether it was the =
server or an agent that inserted the OC-Supported-Feature, and whether =
or not a subsequent request will be routed via that node.
>=20
> Ulrich
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, =
Anders
> Sent: Thursday, February 27, 2014 6:14 PM
> To: Ben Campbell; Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>=20
> I also agree that including OC-Supported-Features in every answer is =
preferable. In addition to mirroring Requests, it is in-line with how =
Supported-Features are managed in at least some 3GPP interfaces as well.
>=20
> /Anders
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: Wednesday, February 26, 2014 9:19 AM
> To: Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>=20
>=20
> On Feb 26, 2014, at 9:14 AM, Steve Donovan  =
wrote:
>=20
>> SRD> We don't have consensus yet, but if we agree on the need for =
reacting nodes to know whether there is support for DOIC in the Diameter =
network then I think the requirement would be similar to how we are =
handling overload reports.  The reporting node MUST ensure that all =
reacting nodes receive the OC-Supported-Features AVP.  This can be done =
by including the AVP in all answer messages or it can be done by =
remembering to whom the AVP has been sent.
>=20
> Given the trivial nature of sending and reading OC-Supported-Features, =
I think we should put it in every answer. This mirrors the way we handle =
it in requests.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 05:50:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2C1A04A1 for ; Fri, 28 Feb 2014 05:50:51 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzoEGvns-cqV for ; Fri, 28 Feb 2014 05:50:48 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E4BD21A049E for ; Fri, 28 Feb 2014 05:50:47 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id hr13so2733775lab.31 for ; Fri, 28 Feb 2014 05:50:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4c57u9XmiKjBddxrCnxcI2xKG8yZrTDUv8zNrCvEDG8=; b=GpvSh7R4CxXST4Y7rDyujWhdiIVpdXRhwk3V/dSqIUB0Q+h4x+eB3C5tHG6dE0nq44 M4o5uKzs8w+tOxEanctpAFJWUvsG1RThdppjBDV7RJWItmEU0T0o5XaloMzIDAmjj2n1 LD1vugGb5Hj7NmZs93Oo1OBr1RDvAjoK+MSbBy0Ur/U8fL4gI8uLD0QPOW3KVDKo2Kme QrZe8fCmbnC/5hNK40KKX477q/6l6mFreCqWcGIhVVYg3+0RhrEqyBtwJqcR4hRPrFpw FmV0idHsXqUKseNzQHZLHDGQb7R7vPSUD8UDS9RUb5ddoStuAU/527Q3SnwiI12GeMOj ZPdg==
X-Received: by 10.152.28.200 with SMTP id d8mr1754535lah.59.1393595445456; Fri, 28 Feb 2014 05:50:45 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id td5sm4006180lbb.7.2014.02.28.05.50.41 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 05:50:41 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <3F08E5F1-0FDA-44D6-B129-42D0A58F51C6@nostrum.com>
Date: Fri, 28 Feb 2014 15:50:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B92097740BB@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B92097745AF@ESESSMB101.ericsson.se> <3F08E5F1-0FDA-44D6-B129-42D0A58F51C6@nostrum.com>
To: Ben Campbell , Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xg1ms7k_ihz5nbZXXBQCFWGpVhQ
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on previous history
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 13:50:51 -0000



Ok. We can conclude issue #52 sorted.=20

@Maria could you update the final text into the issue tracker and mark =
it as closed?

- Jouni


On Feb 14, 2014, at 11:24 PM, Ben Campbell  wrote:

> +1
>=20
> On Feb 12, 2014, at 7:34 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Thanks Jouni, I didn't realize.
>> One more correction added
>>=20
>>> Proposal:
>>> Indicates that the reporting node urges the reacting node to reduce=20=

>>> its traffic by a given percentage. For example if the
>>> reacting node would send 100 packets to the				=
<---
>>> reporting node, then a reception of OC-Reduction-Percentage value of=20=

>>> 10 would mean that from now on the reacting node MUST only send
>>> 90 packets instead of 100. How the reacting node achieves the "true  =
     <---
>>> reduction" transactions leading to the sent request messages is up =
to=20
>>> the implementation. The reacting node MAY simply drop every 10th=20
>>> packet from its output queue and let the generic application logic =
try=20
>>> to recover from it.
>>=20
>>=20
>> -----Original Message-----
>> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: mi=E9rcoles, 12 de febrero de 2014 10:36
>> To: Maria Cruz Bartolome
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] [dime] #52: Throttling not needed to be based on =
previous history
>>=20
>>=20
>> Fine by me.. though you then need to apply the same change to the =
rest of this paragraph, not only the first one.
>>=20
>> Also, please update this additional concern into the issue tracker =
issue #52.
>>=20
>> - Jouni
>>=20
>> On Feb 12, 2014, at 10:56 AM, Maria Cruz Bartolome =
 wrote:
>>=20
>>> Same comment also applies to following paragraph in 5.5.2
>>>=20
>>> Now:
>>> 0 < value < 100
>>>=20
>>>    Indicates that the reporting node urges the reacting node to
>>>    reduce its traffic by a given percentage.  For example if the
>>>    reacting node has been sending 100 packets per second to the
>>>    reporting node, then a reception of OC-Reduction-Percentage value
>>>    of 10 would mean that from now on the reacting node MUST only =
send
>>>    90 packets per second.  How the reacting node achieves the "true
>>>    reduction" transactions leading to the sent request messages is =
up
>>>    to the implementation.  The reacting node MAY simply drop every
>>>    10th packet from its output queue and let the generic application
>>>    logic try to recover from it.0 < value < 100
>>>=20
>>> Proposal:
>>> Indicates that the reporting node urges the reacting node to reduce=20=

>>> its traffic by a given percentage. For example if the
>>> reacting node would send 100 packets to the				=
<---
>>> reporting node, then a reception of OC-Reduction-Percentage value of=20=

>>> 10 would mean that from now on the reacting node MUST only send
>>> 90 packets per second. How the reacting node achieves the "true=20
>>> reduction" transactions leading to the sent request messages is up =
to=20
>>> the implementation. The reacting node MAY simply drop every 10th=20
>>> packet from its output queue and let the generic application logic =
try=20
>>> to recover from it.
>>>=20
>>>=20
>>> We should not specify a rates for the simple loss algorithm. It's up =
to the implementation how to reduce, but no time unit has to be =
specified.=20
>>>=20
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
>>> Sent: mi=E9rcoles, 12 de febrero de 2014 9:13
>>> To: Maria Cruz Bartolome
>>> Cc: dime@ietf.org
>>> Subject: [dime] #52: Throttling not needed to be based on previous=20=

>>> history
>>>=20
>>> #52: Throttling not needed to be based on previous history
>>>=20
>>> Now (chapter 4.7):
>>>  The OC-Reduction-Percentage AVP (AVP code TBD8) is type of =
Unsigned32
>>>  and describes the percentage of the traffic that the sender is
>>>  requested to reduce, compared to what it otherwise would have sent.
>>>=20
>>> Proposal:
>>> The OC-Reduction-Percentage AVP (AVP code TBD8) is type of =
Unsigned32  and describes the percentage of the traffic that the sender =
is  requested to reduce, compared to what it otherwise would send.
>>>=20
>>>=20
>>> The intention is to avoid that anyone may interpret reacting node is =
 required to consider history of sent information when throttling.
>>>=20
>>> --
>>> =
-----------------------------------------------+----------------------
>>> -----------------------------------------------+--
>>> -----------------------------------------------+---
>>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>>   Type:  defect                             |  Bartolom=E9
>>> Priority:  major                              |     Status:  new
>>> Component:  draft-docdt-dime-ovli              |  Milestone:
>>> Severity:  Active WG Document                 |    Version:  1.0
>>>                                             |   Keywords:
>>> =
-----------------------------------------------+----------------------
>>> -----------------------------------------------+--
>>> -----------------------------------------------+---
>>>=20
>>> Ticket URL: 
>>> dime 
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 05:59:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2887D1A0237 for ; Fri, 28 Feb 2014 05:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om4SeDatOIvb for ; Fri, 28 Feb 2014 05:58:57 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4D1A06E6 for ; Fri, 28 Feb 2014 05:58:56 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 903F6374336; Fri, 28 Feb 2014 14:58:53 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 65FCB158062; Fri, 28 Feb 2014 14:58:53 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 28 Feb 2014 14:58:53 +0100
From: 
To: Jouni Korhonen , "dime@ietf.org" 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAACD12qAAAlPFjD///MvAIAAKsaA//1WeSD/+lRuMP/xctkg
Date: Fri, 28 Feb 2014 13:58:52 +0000
Message-ID: <22770_1393595933_5310961D_22770_13149_1_6B7134B31289DC4FAF731D844122B36E4CF58D@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <53077290.8080501@usdonovans.com> <16056_1393003995_53078DDB_16056_14391_1_6B7134B31289DC4FAF731D844122B36E4B629F@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6C65.8080707@usdonovans.com>  <087A34937E64E74E848732CFF8354B92097867F4@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097867F4@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4CF58DPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.28.3017
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XPy01KJ9HB44lBnTriYb4hEE1ZA
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 13:59:04 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4CF58DPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Jouni, I'm assuming that you are OK with the conclusion given here too, rig=
ht? :)

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mercredi 26 f=E9vrier 2014 13:56
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

Fine

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 26 de febrero de 2014 8:43
To: dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion

Hi

Remove "from now on" is acceptable for me, but  I have a preference for the=
 reverse wording Lionel proposes, which is shorter and brings the clarifica=
tion I was looking for,:

For example if an OC-Reduction-Percentage value of

 10 has been received, the reacting node which

 would normally send 100 packets MUST only send 90

 packets to the reporting node.


Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 17:00
=C0 : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion

I'm with Lionel.  I don't understand why the proposed wording is confusing.=
  Reacting nodes always only apply the reduction percentage for the period =
of time that the specific overload report is active.  That period either en=
ds when a new overload report is received or when the overload report expir=
es.

That said, I'm happy with just removing the words "from no on" as proposed =
by Lionel below.

Steve

On 2/24/14 7:26 AM, lionel.morand@orange.com wrote:

I don't see the issue, as explained in my mail but OK to remove it.



If "for now" is removed, the resulting text would be:



  For example if the reacting node has been sending

  100 packets per second to the reporting node, then

  a reception of OC-Reduction-Percentage value of 10

  would mean that from now on the reacting node MUST

  only send 90 packets per second.



Maybe it would be even easier to reverse the sentence as follow:



 For example if an OC-Reduction-Percentage value of

 10 has been received, the reacting node which

 would normally send 100 packets MUST only send 90

 packets to the reporting node.





But I'm fine if the initial proposed revised text is kept.



Lionel



De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

Envoy=E9 : lundi 24 f=E9vrier 2014 14:13

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



Hello,



I agree with Ulrich's proposal

Cheers

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)

Sent: lunes, 24 de febrero de 2014 10:46

To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion



I share JJacques concern. Replacing "from now on" with "for the period that=
 the overload report is active"

is misleading. May be its better to simply remove "from now on".



Ulrich











From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)

Sent: Friday, February 21, 2014 7:11 PM

To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previous hist=
ory - conclusion



Hi MCruz, Steve



I also agree on the "would send " instead of the "would have sent"  for sur=
e.  But I have  a small concern/ clarification  about the Steve comment on =
  "for the period that the overload report is active" and the example to wh=
ich it refers.



During the time the OLR is active, which may be rather long,  the traffic t=
he reacting node would send may be 100 packet  when it has just received th=
e OLR. A bit later, the traffic it would send could be 120 (or 80), and fro=
m the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  whi=
ch I agree. This is in line  with the every 10th packet dropping  on which =
I also agree.



As the text   would  be written with the Steve modification , we may unders=
tand it is  80 Packet during all the time  the OLR is active. Not yet think=
 to an alternative text, but first to see if you agree with my remark.



JJacques





De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com

Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33

=C0 : Steve Donovan; dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



+1 (including Steve comment)



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan

Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on previous histo=
ry - conclusion



Maria Cruz,



I support your suggested changes.  I have one further suggested change belo=
w.



Steve

On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:

#52: Throttling not needed to be based on previous history



Following agreement is reached:



 Now (chapter 4.7):

    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

    and describes the percentage of the traffic that the sender is

    requested to reduce, compared to what it otherwise would have sent.



 Proposal:

   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32

   and describes the percentage of the traffic that the sender is

   requested to reduce, compared to what it otherwise would send.          =
        <----





 Now (chapter 5.5.2):

      Indicates that the reporting node urges the reacting node to

      reduce its traffic by a given percentage.  For example if the

      reacting node has been sending 100 packets per second to the

      reporting node, then a reception of OC-Reduction-Percentage value

      of 10 would mean that from now on the reacting node MUST only send

      90 packets per second.  How the reacting node achieves the "true

      reduction" transactions leading to the sent request messages is up

      to the implementation.  The reacting node MAY simply drop every

      10th packet from its output queue and let the generic application

      logic try to recover from it.0 < value < 100



  Proposal:

 Indicates that the reporting node urges the reacting node to reduce

 its traffic by a given percentage. For example if the

 reacting node would send 100 packets to the                          <---

 reporting node, then a reception of OC-Reduction-Percentage value of

 10 would mean that from now on the reacting node MUST only send

 90 packets instead of 100. How the reacting node achieves the "true       =
<---

 reduction" transactions leading to the sent request messages is up to

 the implementation. The reacting node MAY simply drop every 10th

 packet from its output queue and let the generic application logic try

 to recover from it.

SRD> Replace "from now on" in the above with "for the period that the overl=
oad report is active"















_______________________________________________

DiME mailing list

DiME@ietf.org

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





___________________________________________________________________________=
______________________________________________



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.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4CF58DPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Jouni, I'm=
 assuming that you are OK with the conclusion given here too, right?
J



 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mercredi 26 f=E9vrier 2014 13:56

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion






 


Fine


 






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 26 de febrero de 2014 8:43

To: dime@ietf.org

Subject: Re: [Dime] #52: Throttling not needed to be based on previo=
us history - conclusion






 


Hi<=
span lang=3D"EN-US">


 


Remove =
220;from now on” is acceptable for me, but  I have a preference =
for the reverse wording Lionel proposes, which is shorter and brings the cl=
arification
 I was looking for,:


For example if an OC-Reduction-Percentage value of 


 10 has been received, the reacting node which 


 would normally send 100 packets MUST only send 90 =



 packets to the reporting node.


 


 


Best regar=
ds



 


JJacques



 


 






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 f=E9vrier 2014 17:00

=C0 : dime@ietf.org

Objet : Re: [Dime] #52: Throttling not needed to be based on pr=
evious history - conclusion





 


I'm with Lionel.  I don't =
understand why the proposed wording is confusing.  Reacting nodes alwa=
ys only apply the reduction percentage for the period of time that the spec=
ific overload report is active.  That period either
 ends when a new overload report is received or when the overload report ex=
pires.



That said, I'm happy with just removing the words "from no on" as=
 proposed by Lionel below.



Steve

 




On 2/24/14 7:26 AM, 
lionel.morand@orange.com wrote:






I don't see the issue, as explained in my mail but OK to remo=
ve it. 


 


If "for now" is removed, the resulting text would b=
e:


 


  For example if the reacting node has been sending=



  100 packets per second to the reporting node, then


  a reception of OC-Reduction-Percentage value of 1=
0


  would mean that from now on the reacting node MUST


  only send 90 packets per second.

 


Maybe it would be even easier to reverse the sentence as foll=
ow:


 


 For example if an OC-Reduction-Percentage value of 


 10 has been received, the reacting node which 


 would normally send 100 packets MUST only send 90 =



 packets to the reporting node.


 


 


But I'm fine if the initial proposed revised text is kept.


 


Lionel


 


De : DiME [mail=
to:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome=



Envoy=E9 : lundi 24 f=E9vrier 2014 14:13


=C0 : dime@ietf.org=



Objet : Re: [Dime] #52: Throttling not needed to be base=
d on previous history - conclusion


 


Hello,


 


I agree with Ulrich's proposal


Cheers


/MCruz


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)=



Sent: lunes, 24 de febrero de 2014 10:46

To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org


Subject: Re: [Dime] #52: Throttling not needed to be based on=
 previous history - conclusion


 


I share JJacques concern. Replacing "from now on" w=
ith "for the period that the overload report is active"


is misleading. May be its better to simply remove "from =
now on".


 


Ulrich


 


 


 


 


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES)


Sent: Friday, February 21, 2014 7:11 PM

To: dime@ietf.org


Subject: Re: [Dime] #52: Throttling not needed to be based on=
 previous history - conclusion


 


Hi MCruz, Steve


 


I also agree on the "would send " instead of the &q=
uot;would have sent"  for sure.  But I have  a small co=
ncern/ clarification  about the Steve comment on   "for=
 the period that the overload report is active" and the example to whi=
ch it refers.


 


During the time the OLR is active, which may be rather long, =
 the traffic the reacting node would send may be 100 packet  when=
 it has just received the OLR. A bit later, the traffic it would send could=
 be 120 (or 80), and from the OLR definition,   it would send 120=
x0,9 (or 80* 0,9) packets, on  which I agree. This is in line  wi=
th the every 10th packet dropping  on which I also agree. <=
/span>


  


As the text   would  be written with the Steve=
 modification , we may understand it is  80 Packet during all the time=
  the OLR is active. Not yet think to an alternative text, but first t=
o see if you agree with my remark.


 


JJacques 


 


 


De : DiME [mail=
to:dime-bounces@ietf.org] De la part de lionel.morand@orange.com


Envoy=E9 : vendredi 21 f=E9vrier 2014 18:33


=C0 : Steve Donovan; di=
me@ietf.org


Objet : Re: [Dime] #52: Throttling not needed to be base=
d on previous history - conclusion


 


+1 (including Steve comment)


 


De : DiME [mail=
to:dime-bounces@ietf.org] De la part de Steve Donovan=



Envoy=E9 : vendredi 21 f=E9vrier 2014 16:37


=C0 : dime@ietf.org=



Objet : Re: [Dime] #52: Throttling not needed to be base=
d on previous history - conclusion


 


Maria Cruz,


 


I support your suggested changes.  I have one further su=
ggested change below.


 


Steve


On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:


#52: Throttling not needed to be based on previous history


 


Following agreement is reached:


 


 Now (chapter 4.7):


    The OC-Reduction-Percentage AVP (AVP code =
TBD8) is type of Unsigned32


    and describes the percentage of the traffi=
c that the sender is


    requested to reduce, compared to what it o=
therwise would have sent.


 


 Proposal:


   The OC-Reduction-Percentage AVP (AVP code TBD8) =
is type of Unsigned32  


   and describes the percentage of the traffic=
 that the sender is  


   requested to reduce, compared to what it ot=
herwise would send.         &n=
bsp;        <----

 


 


 Now (chapter 5.5.2):


      Indicates that the reporting n=
ode urges the reacting node to


      reduce its traffic by a given =
percentage.  For example if the


      reacting node has been sending=
 100 packets per second to the


      reporting node, then a recepti=
on of OC-Reduction-Percentage value


      of 10 would mean that from now=
 on the reacting node MUST only send


      90 packets per second.  H=
ow the reacting node achieves the "true


      reduction" transactions l=
eading to the sent request messages is up


      to the implementation.  T=
he reacting node MAY simply drop every


      10th packet from its output qu=
eue and let the generic application


      logic try to recover from it.0=
 < value < 100


 


  Proposal:


 Indicates that the reporting node urges the reacting node to=
 reduce 


 its traffic by a given percentage. For example if the


 reacting node would send 100 packets to the   =
;            &n=
bsp;          <---


 reporting node, then a reception of OC-Reduction-Percentage =
value of 


 10 would mean that from now on the reacting node MUST o=
nly send


 90 packets instead of 100. How the reacting node achieves th=
e "true       <---<=
/pre>

 reduction" transactions leading to the sent request mes=
sages is up to 


 the implementation. The reacting node MAY simply drop e=
very 10th 


 packet from its output queue and let the generic applic=
ation logic try 


 to recover from it.


SRD> Replace "from now on" in the above with &qu=
ot;for the period that the overload report is active"


 


 


 


 


 


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org=



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


 


 


_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


 


_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


 


_______________________________________________


DiME mailing list


DiME@ietf.org=



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


 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4CF58DPEXCVZYM13corpora_--


From nobody Fri Feb 28 06:01:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F931A021F for ; Fri, 28 Feb 2014 06:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h4_xlvfDpK5 for ; Fri, 28 Feb 2014 06:01:29 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 686301A0190 for ; Fri, 28 Feb 2014 06:01:28 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id 10so2718219lbg.35 for ; Fri, 28 Feb 2014 06:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=3hlxtnF+q4ty3JAQzpbEoLoNnex5RLUsf9F1h+O67bg=; b=Trpt683nMB1Y/0H5DksmQ36uQ4pPnIajUbEnldK9K8udC84bUQxvQNfAwN/Yw15T8d isXo7YPNChxEmMmtQgNuujfhSRngiA/f52SzCpgrQDDGFHqFwwv5uNLaPTZJLugk2FMa +ccVJ5GB77WIx3pT+DiNHHyEoZWCSKJaYpc0cB/AdDFHfWoCN8DnYHXUclSberkEqQm5 +LsrY2mNUNHuIVuofdsqqCwPyuQHdyGpALdqtMRw6RSNVOSpHlDp617Hl0ZjqDbiJ/wx VyNUYFvISX0qs6JgUn28fATUcM5qxo2U6RJQmt0gqdGj7MALUzPSWGLqmOt+dpjdaoEq NPIQ==
X-Received: by 10.152.4.68 with SMTP id i4mr11307360lai.8.1393596085821; Fri, 28 Feb 2014 06:01:25 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id pz10sm4032305lbb.10.2014.02.28.06.01.22 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 06:01:23 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <2771A62F-E982-4A31-A827-E2C4AC14132B@nostrum.com>
Date: Fri, 28 Feb 2014 16:01:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com> <2771A62F-E982-4A31-A827 -E2C4AC14132B@nostrum.com>
To: "dime@ietf.org list" , "Ulrich (NSN - DE/Munich) Wiehe" , "lionel.morand@orange.com Morand" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZJA4IN5YyIApB66Nzc64UmB8bw8
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within	OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 14:01:31 -0000



It seems we reached a conclusion here. So summarizing:

o Document that the sequence number is:
 - Globally/eternally unique.
 - increase monotonically over time, including over a reboot.
o Write a non-normative recommendation/suggestion how to create
  sequence numbers fulfilling the above requirements (e.g. using
  NTP as one component).

@Ulrich or Lionel could you update the above into the ticket
 and close it?



- JOuni


On Feb 14, 2014, at 11:28 PM, Ben Campbell  wrote:

> +1. It doesn't even have to be "suggested" in the since of a =
(non-normative) recommendation. It can merely be an example of an =
approach which meets the stated requirements.
>=20
> On Feb 13, 2014, at 6:25 AM, Steve Donovan  =
wrote:
>=20
>> Jouni,
>>=20
>> The important thing is to define the properties.  There should be no =
harm in giving one suggested implementation.
>>=20
>> Steve
>>=20
>> On 2/11/14 4:42 PM, Jouni Korhonen wrote:
>>> If the NTP is only going to be guidance when building the globally
>>> and eternally unique sequence number, IMHO better not mention NTP
>>> then at all. Just include the required properties below. One less
>>> mandatory reference..
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> It sounds reasonable to me as well.
>>>> /MCruz
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of Steve Donovan
>>>> Sent: lunes, 10 de febrero de 2014 14:59
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>=20
>>>> +1
>>>> On 2/10/14 7:47 AM,=20
>>>> lionel.morand@orange.com
>>>> wrote:
>>>> I would add, maybe even before the format (NTP time based), that =
the real requirements for the sequence-number are:
>>>>=20
>>>> - Globally/eternally unique
>>>> - increase monotonically over time, including over a reboot (as =
remind by Steve)=20
>>>>=20
>>>> The NTP time based type is just a guidance provided by the draft on =
how to generate sequence numbers with such properties.
>>>>=20
>>>> Lionel
>>>>=20
>>>> -----Message d'origine-----
>>>> De : DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] De la part de Jouni Korhonen
>>>> Envoy=E9 : samedi 8 f=E9vrier 2014 11:33
>>>> =C0 : Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>=20
>>>>=20
>>>> Sounds acceptable. Would the following then work for all:
>>>>=20
>>>> o clarify that once the overload report expires there is no
>>>>  reason to remember anything about it
>>>> o the sequence number would be similar to session-id.. based=20
>>>>  on the NTP time + any vendor specific data to make it=20
>>>>  "globally and eternally unique".
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>>=20
>>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>> 
>>>> wrote:
>>>>=20
>>>> Steve,
>>>>=20
>>>> sounds like an acceptable proposal which allows to come back to =
sync after OLR expiry.
>>>> This requires however an update of clause 5.5.2 to clearly state
>>>> Once the overload report expires there is no reason to remember =
anything about it and the next overload report received could, =
conceivably have any value.=20
>>>>=20
>>>>=20
>>>> Ulrich
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Steve Donovan
>>>> Sent: Thursday, February 06, 2014 4:50 PM
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>=20
>>>> A couple of things -=20
>>>>=20
>>>> The requirement is that the sequence number increase monotonically =
over time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time =
stamp to set the sequence number for the first overload report sent =
after a reboot and then increment the sequence number value by one for =
each subsequent overload report sent.  This actually has better =
properties than an NTP time stamp as it would take much longer to roll =
over.  One could also create a global sequence number service that is =
not tied to time and have a Diameter server query that global sequence =
number server after each reboot.
>>>>=20
>>>> We also have a duration timer on overload reports.  This gives us =
one way to reset.  It should only be required to remember the sequence =
number of an active overload report.  Once the overload report expires =
there is no reason to remember anything about it and the next overload =
report received could, conceivably have any value.=20
>>>>=20
>>>> The requirement we need is similar to the session-id in the base =
Diameter specification.  The wording there is -- "The Session-Id MUST be =
globally and eternally unique".  We just need eternally as the spacial =
differentiation is based on the context of the message carrying the =
overload report.
>>>>=20
>>>> It would be perfectly valid for the DOIC draft to suggest the use =
of NTP timestamps to populate the sequence number but it should be =
worded in a similar fashion as the Diameter base RFC -- The Session-Id =
includes a mandatory portion and an implementation-defined portion; a =
recommended format for the implementation-defined portion is outlined =
below ..."
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> I cannot understand what is the problem with mandating timestamp.
>>>> But I can see interoperability problems with the current =
definition:
>>>>=20
>>>> Assume the sender sends sequence numbers
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>>> but the receicer for any reason receives=20
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20=

>>>> The receiver would accept
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>>>> and then silently discards
>>>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
>>>> with no way to come back to sync.
>>>>=20
>>>> Are we sure that this cannot happen?
>>>>=20
>>>> Mandating timestamp for sequence number generation at the sender =
and plausibility checking (i.e. received value must be between stored =
value and time of reception) for the receiver may not be the only way to =
solve the problem. But in the moment I don't see another way.
>>>>=20
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Ben Campbell
>>>> Sent: Wednesday, February 05, 2014 4:57 PM
>>>> To: ext=20
>>>> lionel.morand@orange.com
>>>>=20
>>>> Cc:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>=20
>>>> My point is, we have an interop requirement that the sequence =
number always increases over time scope. We do not have the interop =
requirement that the sequence number be implemented as a time stamp. A =
time stamp is probably a good way to  meet the interop requirements, but =
it is not, in itself, an interop requirement.
>>>>=20
>>>> On Feb 5, 2014, at 9:53 AM,=20
>>>>  
>>>> wrote:
>>>>=20
>>>> Not sure to understand: if there is a kind of "interop =
requirement", it is a case for a "MUST".
>>>> We are not violating anything.
>>>>=20
>>>> Reporting and reacting nodes will just rely on the Diameter =
interfaces to know how to handle the received sequence-number. So any =
MUST on the format of the sequence-number is acceptable if it avoids =
interop issues.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : Ben Campbell [
>>>> mailto:ben@nostrum.com
>>>> ]=20
>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc : Steve Donovan;=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>=20
>>>> I concur with Steve on this one. Using a time stamp is a good way =
to meet the requirements, but it's not our job to normatively state an =
implementation. In fact, it violates an RFC 2119 "MUST" level =
requirement to do so. Section 6 of 2119 includes the following:
>>>>=20
>>>> "In particular, [normative requirements] MUST only be used where it =
is
>>>>  actually required for interoperation or to limit behavior which =
has
>>>>  potential for causing harm (e.g., limiting retransmisssions)  "
>>>>=20
>>>> The only appropriate reason to require a timestamp would be if we =
expected peers to interpret the field as a point in time. OTOH, it would =
be perfectly reasonable to state the actual interop requirements, then =
add a non-normative (probably indented) paragraph suggesting that a =
timestamp is a good way to do this.
>>>>=20
>>>> On Feb 5, 2014, at 9:37 AM,=20
>>>> lionel.morand@orange.com
>>>> wrote:
>>>>=20
>>>> I think the out-of-sync failover described by Ulrich is a good use =
case to mandate a specific semantic.
>>>>=20
>>>> Is there any specific NOT to mandate the use of NTP timestamps if =
it is a simple way to solve the possible issues and please everyone?
>>>>=20
>>>> Lionel
>>>>=20
>>>> De : DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] De la part de Steve Donovan
>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
>>>> =C0 :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>=20
>>>> How the sequence number is implemented is an implementation =
decision.  There is no reason to mandate that is be an NTP timestamp.  =
That should be included only as one way of addressing the requirement.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>>>> I also agree.
>>>>=20
>>>> Regards,
>>>> Nirav.
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
>>>>=20
>>>> Sent: Tuesday, February 04, 2014 11:50 PM
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>=20
>>>> The existing wording seems actually fuzzy.
>>>> If it is "like an NTP timestamp", be proud and say it loud!
>>>>=20
>>>> In summary: ok with the proposal if it clarifies this handling of =
this sequence-number.
>>>>=20
>>>> Lionel
>>>>=20
>>>> -----Message d'origine-----
>>>> De : dime issue tracker [
>>>> mailto:trac+dime@trac.tools.ietf.org
>>>> ]
>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>=20
>>>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>=20
>>>> The -01 draft says in clause 4.4:
>>>>   =46rom the functionality point of view, the OC-Sequence-Number =
AVP MUST
>>>>   be used as a non-volatile increasing counter between two overload
>>>>   control endpoints (neglecting the fact that the contents of the =
AVP
>>>>   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is =
only
>>>>   required to be unique between two overload control endpoints.
>>>>   Sequence numbers are treated in uni-directional manner, i.e. two
>>>>   sequence numbers on each direction between two endpoints are not
>>>>   related or correlated.
>>>>=20
>>>>   When generating sequence numbers, the new sequence number MUST be
>>>>   greater than any sequence number previously seen between two
>>>>   endpoints within a time window that tolerates the wraparound of =
the
>>>>   NTP timestamp (i.e. approximately 68 years).
>>>>=20
>>>>=20
>>>> With this mechanism it is difficult to get back to sync once you =
are out  of sync (for whatever reason).
>>>> It is proposed to mandate that the Sequence Number is a real 64-bit =
NTP  timestamp (RFC5905) indicating the point in time when the OLR was =
created,  and to mandate that  OLRs with a time stamp higher than time =
of reception  must be ignored by the reacting node.
>>>>=20
>>>>=20
>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>> they should not be distributed, used or copied without =
authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>> they should not be distributed, used or copied without =
authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>> they should not be distributed, used or copied without =
authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 06:02:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2629D1A021F for ; Fri, 28 Feb 2014 06:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ydecOEaF7j for ; Fri, 28 Feb 2014 06:02:09 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id B248B1A00A6 for ; Fri, 28 Feb 2014 06:02:08 -0800 (PST)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 4FAF51B825A; Fri, 28 Feb 2014 15:02:06 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 23FE7C804F; Fri, 28 Feb 2014 15:02:06 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 28 Feb 2014 15:02:05 +0100
From: 
To: Jouni Korhonen , "dime@ietf.org list" , "Ulrich (NSN - DE/Munich) Wiehe" 
Thread-Topic: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
Thread-Index: AQHPNI2Slr3GIPiJ+0GMZlo8E85tBprKsjKA
Date: Fri, 28 Feb 2014 14:02:05 +0000
Message-ID: <6815_1393596126_531096DE_6815_12932_1_6B7134B31289DC4FAF731D844122B36E4CF5FE@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com> <2771A62F-E982-4 A31-A827-E2C4AC14132B@nostrum.com> <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com>
In-Reply-To: <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.28.3017
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XBPVpD9JOVK5LMienTEB_KbsyH0
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 14:02:13 -0000

I will

-----Message d'origine-----
De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Envoy=E9=A0: vendredi 28 f=E9vrier 2014 15:01
=C0=A0: dime@ietf.org list; Ulrich (NSN - DE/Munich) Wiehe; MORAND Lionel I=
MT/OLN
Objet=A0: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within O=
C-OLR




It seems we reached a conclusion here. So summarizing:

o Document that the sequence number is:
 - Globally/eternally unique.
 - increase monotonically over time, including over a reboot.
o Write a non-normative recommendation/suggestion how to create
  sequence numbers fulfilling the above requirements (e.g. using
  NTP as one component).

@Ulrich or Lionel could you update the above into the ticket
 and close it?



- JOuni


On Feb 14, 2014, at 11:28 PM, Ben Campbell  wrote:

> +1. It doesn't even have to be "suggested" in the since of a (non-normati=
ve) recommendation. It can merely be an example of an approach which meets =
the stated requirements.
>=20
> On Feb 13, 2014, at 6:25 AM, Steve Donovan  wro=
te:
>=20
>> Jouni,
>>=20
>> The important thing is to define the properties.  There should be no har=
m in giving one suggested implementation.
>>=20
>> Steve
>>=20
>> On 2/11/14 4:42 PM, Jouni Korhonen wrote:
>>> If the NTP is only going to be guidance when building the globally
>>> and eternally unique sequence number, IMHO better not mention NTP
>>> then at all. Just include the required properties below. One less
>>> mandatory reference..
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> It sounds reasonable to me as well.
>>>> /MCruz
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of Steve Donovan
>>>> Sent: lunes, 10 de febrero de 2014 14:59
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> +1
>>>> On 2/10/14 7:47 AM,=20
>>>> lionel.morand@orange.com
>>>> wrote:
>>>> I would add, maybe even before the format (NTP time based), that the r=
eal requirements for the sequence-number are:
>>>>=20
>>>> - Globally/eternally unique
>>>> - increase monotonically over time, including over a reboot (as remind=
 by Steve)=20
>>>>=20
>>>> The NTP time based type is just a guidance provided by the draft on ho=
w to generate sequence numbers with such properties.
>>>>=20
>>>> Lionel
>>>>=20
>>>> -----Message d'origine-----
>>>> De : DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] De la part de Jouni Korhonen
>>>> Envoy=E9 : samedi 8 f=E9vrier 2014 11:33
>>>> =C0 : Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR
>>>>=20
>>>>=20
>>>> Sounds acceptable. Would the following then work for all:
>>>>=20
>>>> o clarify that once the overload report expires there is no
>>>>  reason to remember anything about it
>>>> o the sequence number would be similar to session-id.. based=20
>>>>  on the NTP time + any vendor specific data to make it=20
>>>>  "globally and eternally unique".
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>>=20
>>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>> 
>>>> wrote:
>>>>=20
>>>> Steve,
>>>>=20
>>>> sounds like an acceptable proposal which allows to come back to sync a=
fter OLR expiry.
>>>> This requires however an update of clause 5.5.2 to clearly state
>>>> Once the overload report expires there is no reason to remember anythi=
ng about it and the next overload report received could, conceivably have a=
ny value.=20
>>>>=20
>>>>=20
>>>> Ulrich
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Steve Donovan
>>>> Sent: Thursday, February 06, 2014 4:50 PM
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> A couple of things -=20
>>>>=20
>>>> The requirement is that the sequence number increase monotonically ove=
r time, including over a reboot.  Use of NTP time is one way of doing this =
but is not the only way.  Someone could, for instance, use a time stamp to =
set the sequence number for the first overload report sent after a reboot a=
nd then increment the sequence number value by one for each subsequent over=
load report sent.  This actually has better properties than an NTP time sta=
mp as it would take much longer to roll over.  One could also create a glob=
al sequence number service that is not tied to time and have a Diameter ser=
ver query that global sequence number server after each reboot.
>>>>=20
>>>> We also have a duration timer on overload reports.  This gives us one =
way to reset.  It should only be required to remember the sequence number o=
f an active overload report.  Once the overload report expires there is no =
reason to remember anything about it and the next overload report received =
could, conceivably have any value.=20
>>>>=20
>>>> The requirement we need is similar to the session-id in the base Diame=
ter specification.  The wording there is -- "The Session-Id MUST be globall=
y and eternally unique".  We just need eternally as the spacial differentia=
tion is based on the context of the message carrying the overload report.
>>>>=20
>>>> It would be perfectly valid for the DOIC draft to suggest the use of N=
TP timestamps to populate the sequence number but it should be worded in a =
similar fashion as the Diameter base RFC -- The Session-Id includes a manda=
tory portion and an implementation-defined portion; a recommended format fo=
r the implementation-defined portion is outlined below ..."
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> I cannot understand what is the problem with mandating timestamp.
>>>> But I can see interoperability problems with the current definition:
>>>>=20
>>>> Assume the sender sends sequence numbers
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>>> but the receicer for any reason receives=20
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>>> The receiver would accept
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>>>> and then silently discards
>>>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
>>>> with no way to come back to sync.
>>>>=20
>>>> Are we sure that this cannot happen?
>>>>=20
>>>> Mandating timestamp for sequence number generation at the sender and p=
lausibility checking (i.e. received value must be between stored value and =
time of reception) for the receiver may not be the only way to solve the pr=
oblem. But in the moment I don't see another way.
>>>>=20
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Ben Campbell
>>>> Sent: Wednesday, February 05, 2014 4:57 PM
>>>> To: ext=20
>>>> lionel.morand@orange.com
>>>>=20
>>>> Cc:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> My point is, we have an interop requirement that the sequence number a=
lways increases over time scope. We do not have the interop requirement tha=
t the sequence number be implemented as a time stamp. A time stamp is proba=
bly a good way to  meet the interop requirements, but it is not, in itself,=
 an interop requirement.
>>>>=20
>>>> On Feb 5, 2014, at 9:53 AM,=20
>>>>  
>>>> wrote:
>>>>=20
>>>> Not sure to understand: if there is a kind of "interop requirement", i=
t is a case for a "MUST".
>>>> We are not violating anything.
>>>>=20
>>>> Reporting and reacting nodes will just rely on the Diameter interfaces=
 to know how to handle the received sequence-number. So any MUST on the for=
mat of the sequence-number is acceptable if it avoids interop issues.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : Ben Campbell [
>>>> mailto:ben@nostrum.com
>>>> ]=20
>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc : Steve Donovan;=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR
>>>>=20
>>>> I concur with Steve on this one. Using a time stamp is a good way to m=
eet the requirements, but it's not our job to normatively state an implemen=
tation. In fact, it violates an RFC 2119 "MUST" level requirement to do so.=
 Section 6 of 2119 includes the following:
>>>>=20
>>>> "In particular, [normative requirements] MUST only be used where it is
>>>>  actually required for interoperation or to limit behavior which has
>>>>  potential for causing harm (e.g., limiting retransmisssions)  "
>>>>=20
>>>> The only appropriate reason to require a timestamp would be if we expe=
cted peers to interpret the field as a point in time. OTOH, it would be per=
fectly reasonable to state the actual interop requirements, then add a non-=
normative (probably indented) paragraph suggesting that a timestamp is a go=
od way to do this.
>>>>=20
>>>> On Feb 5, 2014, at 9:37 AM,=20
>>>> lionel.morand@orange.com
>>>> wrote:
>>>>=20
>>>> I think the out-of-sync failover described by Ulrich is a good use cas=
e to mandate a specific semantic.
>>>>=20
>>>> Is there any specific NOT to mandate the use of NTP timestamps if it i=
s a simple way to solve the possible issues and please everyone?
>>>>=20
>>>> Lionel
>>>>=20
>>>> De : DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] De la part de Steve Donovan
>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
>>>> =C0 :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR
>>>>=20
>>>> How the sequence number is implemented is an implementation decision. =
 There is no reason to mandate that is be an NTP timestamp.  That should be=
 included only as one way of addressing the requirement.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>>>> I also agree.
>>>>=20
>>>> Regards,
>>>> Nirav.
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
>>>>=20
>>>> Sent: Tuesday, February 04, 2014 11:50 PM
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> The existing wording seems actually fuzzy.
>>>> If it is "like an NTP timestamp", be proud and say it loud!
>>>>=20
>>>> In summary: ok with the proposal if it clarifies this handling of this=
 sequence-number.
>>>>=20
>>>> Lionel
>>>>=20
>>>> -----Message d'origine-----
>>>> De : dime issue tracker [
>>>> mailto:trac+dime@trac.tools.ietf.org
>>>> ]
>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>=20
>>>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>=20
>>>> The -01 draft says in clause 4.4:
>>>>   From the functionality point of view, the OC-Sequence-Number AVP MUST
>>>>   be used as a non-volatile increasing counter between two overload
>>>>   control endpoints (neglecting the fact that the contents of the AVP
>>>>   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
>>>>   required to be unique between two overload control endpoints.
>>>>   Sequence numbers are treated in uni-directional manner, i.e. two
>>>>   sequence numbers on each direction between two endpoints are not
>>>>   related or correlated.
>>>>=20
>>>>   When generating sequence numbers, the new sequence number MUST be
>>>>   greater than any sequence number previously seen between two
>>>>   endpoints within a time window that tolerates the wraparound of the
>>>>   NTP timestamp (i.e. approximately 68 years).
>>>>=20
>>>>=20
>>>> With this mechanism it is difficult to get back to sync once you are o=
ut  of sync (for whatever reason).
>>>> It is proposed to mandate that the Sequence Number is a real 64-bit NT=
P  timestamp (RFC5905) indicating the point in time when the OLR was create=
d,  and to mandate that  OLRs with a time stamp higher than time of recepti=
on  must be ignored by the reacting node.
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


___________________________________________________________________________=
______________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Feb 28 06:05:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1AA1A021F for ; Fri, 28 Feb 2014 06:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eESm4spA4qyS for ; Fri, 28 Feb 2014 06:05:52 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CE0FB1A0499 for ; Fri, 28 Feb 2014 06:05:51 -0800 (PST)
Received: from localhost ([127.0.0.1]:55673 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WJO4S-0004xT-Vd; Fri, 28 Feb 2014 15:05:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: lionel.morand@orange-ftgroup.com
X-Trac-Project: dime
Date: Fri, 28 Feb 2014 14:05:48 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/32#comment:1
Message-ID: <081.12fd2e82e420178e22ec6d03c237ff77@trac.tools.ietf.org>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>
X-Trac-Ticket-ID: 32
In-Reply-To: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1SvgLzZ9ZVEClcydMWTGwJxy8gw
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32 (draft-docdt-dime-ovli): Sequence-Number Time-Stamp values within OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2014 14:05:54 -0000

#32: Sequence-Number Time-Stamp values within OC-OLR

Changes (by lionel.morand@orange-ftgroup.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 It seems we reached a conclusion here. So summarizing:

 o Document that the sequence number is:
  - Globally/eternally unique.
  - increase monotonically over time, including over a reboot.
 o Write a non-normative recommendation/suggestion how to create
   sequence numbers fulfilling the above requirements (e.g. using
   NTP as one component).

-- 
--------------------------------------+---------------------------
 Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Fri Feb 28 06:07:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE1C1A01F8 for ; Fri, 28 Feb 2014 06:07:47 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XNqEKUJz1kU for ; Fri, 28 Feb 2014 06:07:45 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 527A61A021F for ; Fri, 28 Feb 2014 06:07:45 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id hr17so2712687lab.19 for ; Fri, 28 Feb 2014 06:07:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=V480y/UX7YGumUBy9xUl7sOEFJMiIhLfzv/Lvt24a3E=; b=o1fyJKY7av2nFOfuod2HQLOcohxzAxAE7nb51zsXGNmsm2Cqis0G3ZxP+X8bZNI/ws c1f8TIVx+NofUJeCSo62Haly9uSyVxwGg+o1P5v0R3MT8eLl+5mPE/1x8AqWSKecy5+d ws7IJBPb3IJFPJyi7eZ+D0erUKz93l5w1v02n/wa+NzC0hYoUzJn1DId+7cL1SUBB200 MbPjVraiqXNixcnsoUxIqaj+pWVvhuWwsu7x3yujwEG19wm2ykbdnHvKGXGJCpWrErOp BOc7XSB//fLDyk3u+u106V/PfRz3sAvuGcw2qBkSSG/WcN9KACpF4FaPSp6RNh96n2PV rxPg==
X-Received: by 10.152.120.201 with SMTP id le9mr1400111lab.68.1393596462893; Fri, 28 Feb 2014 06:07:42 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id uf9sm4043820lbb.14.2014.02.28.06.07.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 06:07:40 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <80595915-0FB5-456B-B2B6-67CC86C0B975@nostrum.com>
Date: Fri, 28 Feb 2014 16:07:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> <10919_1391877435_52F65D3B_10919_16935_1_6B7134B31289DC4FAF731D844122B36E4938A3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <52F9056B.6010405@usdonovans.com> <10970_1392053371_52F90C7A_10970_2992_1_6B7134B31289DC4FAF731D844122B36E497E39@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F91354.4090101@usdonovans.com> <80595915-0FB5-456B-B2B6-67CC86C0B975@nostrum.com>
To: Ben Campbell , "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Job9wR6Z8hRd6sVLCqZebKsZe-Y
Subject: Re: [Dime] [dime] #47: reduction percentages greater than 100 should be	ignored
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 14:07:47 -0000



We seem to have reached a conclusion that invalid reduction percentages
should be ignored.

@ben could you update the ticket and close it?

- JOuni


On Feb 15, 2014, at 12:29 AM, Ben Campbell  wrote:

>=20
> On Feb 10, 2014, at 11:58 AM, Steve Donovan  =
wrote:
>=20
>> I agree that a clarification is needed on what it means to be =
"treated as is the OC-Validity-Duration AVP was not present".  It would =
e better to say:
>>=20
>>  "Invalid validity duration values are given the default value".
>>=20
>>=20
>=20
> +1.
>=20
> I recognize this is different from what I said about reduction =
percentage. My reasoning is, if the sender includes an invalid duration, =
we don't know the intended duration. But since there is a default =
duration, we can assume it. Reduction-Percentage, however, has no such =
default (nor should it.). If we get an invalid reduction percentage, we =
really have no idea what the sender intended us to do.
>=20
>=20
>>=20
>> Steve
>>=20
>> On 2/10/14 11:29 AM, lionel.morand@orange.com wrote:
>>> Hi Steve,
>>>=20
>>> About the OC-Validity-Reduction AVP values greater than 24 hours, it =
is said that the default value 5s applies.
>>>=20
>>> I was therefore wondering if it should be also considered as an =
error and therefore discarded. It is a real open question. Not an issue =
per se as I'm fine with the existing text. I was reacting on the reason =
for change explained by Ben.
>>>=20
>>> Regards,
>>>=20
>>> Lionel
>>>=20
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>>> Envoy=E9 : lundi 10 f=E9vrier 2014 17:59
>>> =C0 : dime@ietf.org
>>> Objet : Re: [Dime] [dime] #47: reduction percentages greater than =
100 should be ignored
>>>=20
>>> It is possible, the range defined is zero to 24 hours.  I think the =
text is correct as it says that a value out of this range should be =
ignored.
>>>=20
>>> Steve
>>>=20
>>> On 2/10/14 10:50 AM, Ben Campbell wrote:
>>>=20
>>> On Feb 8, 2014, at 10:37 AM, lionel.morand@orange.com wrote:
>>>=20
>>> Hi Ben,
>>>=20
>>> OK with this statement.
>>> But if it is agreed, would it mean that the same consideration =
should apply for the OC-Validity-Duration AVP values?
>>>=20
>>>=20
>>> I'm not sure I follow the question. Is it possible to send an =
invalid OC-Validity-Duration value?
>>>=20
>>> Lionel
>>>=20
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue =
tracker
>>> Envoy=E9 : vendredi 7 f=E9vrier 2014 23:05
>>> =C0 : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
>>> Cc : dime@ietf.org
>>> Objet : [Dime] [dime] #47: reduction percentages greater than 100 =
should be ignored
>>>=20
>>> #47: reduction percentages greater than 100 should be ignored
>>>=20
>>> Section 4.7 says " [Reduction-Percentage] Values greater than 100 =
are
>>> interpreted as 100."
>>>=20
>>> An OLR with an invalid value should be ignored. An invalid value =
indicates
>>> incorrect behavior on the part of the sender. In this case, it's not =
safe
>>> to assume we know what the sender really intended.
>>>=20
>>> --=20
>>> =
-------------------------+------------------------------------------------=
-
>>> Reporter:               |      Owner:  draft-docdt-dime-
>>> ben@nostrum.com        |  ovli@tools.ietf.org
>>>    Type:  defect       |     Status:  new
>>> Priority:  minor        |  Milestone:
>>> Component:  draft-       |    Version:  1.0
>>> docdt-dime-ovli        |   Keywords:
>>> Severity:  Active WG    |
>>> Document               |
>>> =
-------------------------+------------------------------------------------=
-
>>>=20
>>> Ticket URL: 
>>> dime 
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =
__________________________________________________________________________=
_______________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> =
__________________________________________________________________________=
_______________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>> they should not be distributed, used or copied without =
authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 06:12:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988511A01F8 for ; Fri, 28 Feb 2014 06:12:33 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHh9-HMbv-49 for ; Fri, 28 Feb 2014 06:12:32 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B91E71A027F for ; Fri, 28 Feb 2014 06:12:31 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id mc6so2725322lab.36 for ; Fri, 28 Feb 2014 06:12:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uuFeB8qpq7eFjVOxoctX0zFGIbke6JEymnd9N9j4k/Q=; b=JPJcVp6MUPpSqsnVo25GW4G3lJF0IZIQLU3RmMrehrMoA2GdhGa9OIva351jZrO0P7 jGOXRNnmcj8eIRIzCxj1KHJV04yI9XLtqoYeYXPVjdoeOh8J2ElKPUvSfClROq4a81dV tMvcVtGV9L6IF+zvqzLw0yGzcGcX4CJByyc7KmX7U5fEk6WcFawhXFegznk5kMAzNfBl YCndqZXbHlDu5IgpIJvtUlOUVwDH7bZJ//MHOb5Oi0j9rX4tlel4Hd8/jXHxY0n96rRy wophVYDZWiKNEUPk5Q3HQK6fdnFG9NuJC2uDyoSJaoEAM0qn7fgmMUXCJ8WwmONArI7t noJQ==
X-Received: by 10.112.140.202 with SMTP id ri10mr10996893lbb.9.1393596749208;  Fri, 28 Feb 2014 06:12:29 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id g8sm13820490lae.1.2014.02.28.06.12.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 06:12:28 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=us-ascii
From: Jouni Korhonen 
X-Priority: 3
In-Reply-To: 
Date: Fri, 28 Feb 2014 16:12:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Kevin Peterson 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ml2p6HQ1YQdcGrTPRWTq6rpP50Y
Cc: dime@ietf.org
Subject: Re: [Dime] I have a doubt in Failover and Fallback mechanisms present under DIAMETER.
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 14:12:33 -0000

Kevin,

Are you now referring to Diameter applications that maintain state or =
not?
In case of the former, your client has learned the identity of the =
server
and will continue sending messages to it (i.e. the secondary) during the
lifetime of the entire session.

In case of latter, each request would have a different session-id.

- Jouni


On Feb 19, 2014, at 1:24 PM, Kevin Peterson  wrote:

> Hi,=20
>=20
> Failover and Fallback procedures we know very well.
>=20
> Suppose initial message was supposed to send to primary peer, but peer =
went down and message has been forwarded to Secondary peer i.e. =
Failover. Now suppose if Primary Peer has come up and according to =
DIAMETER theory the message should go to primary peer. So the next =
message will be Update message. Which will have the same session id =
which was used with the initial message.=20
>=20
> Now my doubt is how the primary peer will recognize the session-id of =
update message. Because it has no info for that session. The session was =
created with the secondary peer.=20
>=20
> Thanks,
> Kevin Peterson
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 07:08:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3331A01E8 for ; Fri, 28 Feb 2014 07:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20znbc4jI_uE for ; Fri, 28 Feb 2014 07:08:04 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 011EF1A0838 for ; Fri, 28 Feb 2014 07:07:58 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1SF7t4t022086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 16:07:55 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1SF7twt020021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 16:07:55 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Feb 2014 16:07:55 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 16:07:55 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen , "dime@ietf.org list" , "lionel.morand@orange.com Morand" 
Thread-Topic: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
Thread-Index: AQHPNI2TqhH4VHI0WUyT8/Gx+1refJrKw8vQ
Date: Fri, 28 Feb 2014 15:07:53 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4F0F@DEMUMBX014.nsn-intra.net>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com> <2771A62F-E982-4A31-A827-E2C4AC14132B@nostrum.com> <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com>
In-Reply-To: <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 18759
X-purgate-ID: 151667::1393600075-00005322-3948FD33/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/d-nwx9sNn5ExHdQyAcAwxMGEMIQ
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 15:08:09 -0000

Dear Jouni,
My understanding is that #32 is RESOLVED as follows:

Agreed - Sequence-Number is of type Unsigned64.
=20
Agreed - When generated, a new sequence number must be greater than the seq=
uence number contained in the active overload report to which it applies (i=
ncluding over reboot of that node).
Note: this allows sequence numbers to start at 1 for the initial occurrence=
 of an overload condition at a reporting node (where "initial occurrence me=
ans something like "moving from no overload to overload after a sufficientl=
y long periode of no overload").=20
When received, a sequence number is used to detect outdates/replays/freshne=
ss.
=20
Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.

Can be CLOSED when the next version of the draft correctly reflects this ag=
reement.

Ulrich




-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Friday, February 28, 2014 3:01 PM
To: dime@ietf.org list; Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@oran=
ge.com Morand
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC=
-OLR




It seems we reached a conclusion here. So summarizing:

o Document that the sequence number is:
 - Globally/eternally unique.
 - increase monotonically over time, including over a reboot.
o Write a non-normative recommendation/suggestion how to create
  sequence numbers fulfilling the above requirements (e.g. using
  NTP as one component).

@Ulrich or Lionel could you update the above into the ticket
 and close it?



- JOuni


On Feb 14, 2014, at 11:28 PM, Ben Campbell  wrote:

> +1. It doesn't even have to be "suggested" in the since of a (non-normati=
ve) recommendation. It can merely be an example of an approach which meets =
the stated requirements.
>=20
> On Feb 13, 2014, at 6:25 AM, Steve Donovan  wro=
te:
>=20
>> Jouni,
>>=20
>> The important thing is to define the properties.  There should be no har=
m in giving one suggested implementation.
>>=20
>> Steve
>>=20
>> On 2/11/14 4:42 PM, Jouni Korhonen wrote:
>>> If the NTP is only going to be guidance when building the globally
>>> and eternally unique sequence number, IMHO better not mention NTP
>>> then at all. Just include the required properties below. One less
>>> mandatory reference..
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> It sounds reasonable to me as well.
>>>> /MCruz
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of Steve Donovan
>>>> Sent: lunes, 10 de febrero de 2014 14:59
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> +1
>>>> On 2/10/14 7:47 AM,=20
>>>> lionel.morand@orange.com
>>>> wrote:
>>>> I would add, maybe even before the format (NTP time based), that the r=
eal requirements for the sequence-number are:
>>>>=20
>>>> - Globally/eternally unique
>>>> - increase monotonically over time, including over a reboot (as remind=
 by Steve)=20
>>>>=20
>>>> The NTP time based type is just a guidance provided by the draft on ho=
w to generate sequence numbers with such properties.
>>>>=20
>>>> Lionel
>>>>=20
>>>> -----Message d'origine-----
>>>> De : DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] De la part de Jouni Korhonen
>>>> Envoy=E9 : samedi 8 f=E9vrier 2014 11:33
>>>> =C0 : Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR
>>>>=20
>>>>=20
>>>> Sounds acceptable. Would the following then work for all:
>>>>=20
>>>> o clarify that once the overload report expires there is no
>>>>  reason to remember anything about it
>>>> o the sequence number would be similar to session-id.. based=20
>>>>  on the NTP time + any vendor specific data to make it=20
>>>>  "globally and eternally unique".
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>>=20
>>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>> 
>>>> wrote:
>>>>=20
>>>> Steve,
>>>>=20
>>>> sounds like an acceptable proposal which allows to come back to sync a=
fter OLR expiry.
>>>> This requires however an update of clause 5.5.2 to clearly state
>>>> Once the overload report expires there is no reason to remember anythi=
ng about it and the next overload report received could, conceivably have a=
ny value.=20
>>>>=20
>>>>=20
>>>> Ulrich
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Steve Donovan
>>>> Sent: Thursday, February 06, 2014 4:50 PM
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> A couple of things -=20
>>>>=20
>>>> The requirement is that the sequence number increase monotonically ove=
r time, including over a reboot.  Use of NTP time is one way of doing this =
but is not the only way.  Someone could, for instance, use a time stamp to =
set the sequence number for the first overload report sent after a reboot a=
nd then increment the sequence number value by one for each subsequent over=
load report sent.  This actually has better properties than an NTP time sta=
mp as it would take much longer to roll over.  One could also create a glob=
al sequence number service that is not tied to time and have a Diameter ser=
ver query that global sequence number server after each reboot.
>>>>=20
>>>> We also have a duration timer on overload reports.  This gives us one =
way to reset.  It should only be required to remember the sequence number o=
f an active overload report.  Once the overload report expires there is no =
reason to remember anything about it and the next overload report received =
could, conceivably have any value.=20
>>>>=20
>>>> The requirement we need is similar to the session-id in the base Diame=
ter specification.  The wording there is -- "The Session-Id MUST be globall=
y and eternally unique".  We just need eternally as the spacial differentia=
tion is based on the context of the message carrying the overload report.
>>>>=20
>>>> It would be perfectly valid for the DOIC draft to suggest the use of N=
TP timestamps to populate the sequence number but it should be worded in a =
similar fashion as the Diameter base RFC -- The Session-Id includes a manda=
tory portion and an implementation-defined portion; a recommended format fo=
r the implementation-defined portion is outlined below ..."
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> I cannot understand what is the problem with mandating timestamp.
>>>> But I can see interoperability problems with the current definition:
>>>>=20
>>>> Assume the sender sends sequence numbers
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>>> but the receicer for any reason receives=20
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>>> The receiver would accept
>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>>>> and then silently discards
>>>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
>>>> with no way to come back to sync.
>>>>=20
>>>> Are we sure that this cannot happen?
>>>>=20
>>>> Mandating timestamp for sequence number generation at the sender and p=
lausibility checking (i.e. received value must be between stored value and =
time of reception) for the receiver may not be the only way to solve the pr=
oblem. But in the moment I don't see another way.
>>>>=20
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Ben Campbell
>>>> Sent: Wednesday, February 05, 2014 4:57 PM
>>>> To: ext=20
>>>> lionel.morand@orange.com
>>>>=20
>>>> Cc:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> My point is, we have an interop requirement that the sequence number a=
lways increases over time scope. We do not have the interop requirement tha=
t the sequence number be implemented as a time stamp. A time stamp is proba=
bly a good way to  meet the interop requirements, but it is not, in itself,=
 an interop requirement.
>>>>=20
>>>> On Feb 5, 2014, at 9:53 AM,=20
>>>>  
>>>> wrote:
>>>>=20
>>>> Not sure to understand: if there is a kind of "interop requirement", i=
t is a case for a "MUST".
>>>> We are not violating anything.
>>>>=20
>>>> Reporting and reacting nodes will just rely on the Diameter interfaces=
 to know how to handle the received sequence-number. So any MUST on the for=
mat of the sequence-number is acceptable if it avoids interop issues.
>>>>=20
>>>> -----Message d'origine-----
>>>> De : Ben Campbell [
>>>> mailto:ben@nostrum.com
>>>> ]=20
>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc : Steve Donovan;=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR
>>>>=20
>>>> I concur with Steve on this one. Using a time stamp is a good way to m=
eet the requirements, but it's not our job to normatively state an implemen=
tation. In fact, it violates an RFC 2119 "MUST" level requirement to do so.=
 Section 6 of 2119 includes the following:
>>>>=20
>>>> "In particular, [normative requirements] MUST only be used where it is
>>>>  actually required for interoperation or to limit behavior which has
>>>>  potential for causing harm (e.g., limiting retransmisssions)  "
>>>>=20
>>>> The only appropriate reason to require a timestamp would be if we expe=
cted peers to interpret the field as a point in time. OTOH, it would be per=
fectly reasonable to state the actual interop requirements, then add a non-=
normative (probably indented) paragraph suggesting that a timestamp is a go=
od way to do this.
>>>>=20
>>>> On Feb 5, 2014, at 9:37 AM,=20
>>>> lionel.morand@orange.com
>>>> wrote:
>>>>=20
>>>> I think the out-of-sync failover described by Ulrich is a good use cas=
e to mandate a specific semantic.
>>>>=20
>>>> Is there any specific NOT to mandate the use of NTP timestamps if it i=
s a simple way to solve the possible issues and please everyone?
>>>>=20
>>>> Lionel
>>>>=20
>>>> De : DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] De la part de Steve Donovan
>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
>>>> =C0 :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values withi=
n OC-OLR
>>>>=20
>>>> How the sequence number is implemented is an implementation decision. =
 There is no reason to mandate that is be an NTP timestamp.  That should be=
 included only as one way of addressing the requirement.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>>>> I also agree.
>>>>=20
>>>> Regards,
>>>> Nirav.
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
>>>>=20
>>>> Sent: Tuesday, February 04, 2014 11:50 PM
>>>> To:=20
>>>> dime@ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values with=
in OC-OLR
>>>>=20
>>>> The existing wording seems actually fuzzy.
>>>> If it is "like an NTP timestamp", be proud and say it loud!
>>>>=20
>>>> In summary: ok with the proposal if it clarifies this handling of this=
 sequence-number.
>>>>=20
>>>> Lionel
>>>>=20
>>>> -----Message d'origine-----
>>>> De : dime issue tracker [
>>>> mailto:trac+dime@trac.tools.ietf.org
>>>> ]
>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
>>>> =C0 : MORAND Lionel IMT/OLN
>>>> Cc :=20
>>>> dime@ietf.org
>>>>=20
>>>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>=20
>>>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>=20
>>>> The -01 draft says in clause 4.4:
>>>>   From the functionality point of view, the OC-Sequence-Number AVP MUS=
T
>>>>   be used as a non-volatile increasing counter between two overload
>>>>   control endpoints (neglecting the fact that the contents of the AVP
>>>>   is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
>>>>   required to be unique between two overload control endpoints.
>>>>   Sequence numbers are treated in uni-directional manner, i.e. two
>>>>   sequence numbers on each direction between two endpoints are not
>>>>   related or correlated.
>>>>=20
>>>>   When generating sequence numbers, the new sequence number MUST be
>>>>   greater than any sequence number previously seen between two
>>>>   endpoints within a time window that tolerates the wraparound of the
>>>>   NTP timestamp (i.e. approximately 68 years).
>>>>=20
>>>>=20
>>>> With this mechanism it is difficult to get back to sync once you are o=
ut  of sync (for whatever reason).
>>>> It is proposed to mandate that the Sequence Number is a real 64-bit NT=
P  timestamp (RFC5905) indicating the point in time when the OLR was create=
d,  and to mandate that  OLRs with a time stamp higher than time of recepti=
on  must be ignored by the reacting node.
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> ______________________________________________________________________=
___________________________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 07:09:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DDA1A083D; Fri, 28 Feb 2014 07:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.047
X-Spam-Level: 
X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLUIS2bJtNcd; Fri, 28 Feb 2014 07:09:55 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4294D1A07C0; Fri, 28 Feb 2014 07:09:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1204; q=dns/txt; s=iport; t=1393600194; x=1394809794; h=message-id:date:from:mime-version:to:subject; bh=n2CcI9ffuLUL3RZ8LQECps/kMx1AGQ7jsaq2brkuB/4=; b=F773GV7T4USoK/1qmPj4MutVvFXN1THB7+fza2GDWqYX/r5TKFK9t0v2 fMeP288FxETSZM0f7IWzhDAK8On8gBNV0bAMbq+oFOKSnPQbvhfZjx1FC Qr9RVbZqlAChTbRH3eMbFShDTZzzp4f0OWnfYKGaJfVxw92Wz8WsnYPAr w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqkFABGmEFOQ/khR/2dsb2JhbABagwY7iTe5UhZ0ghyBCB8BHRYYAwIBAgFLAQwIAQGHdQ3LOReTEwSYOoEyhRiLYYMtPA
X-IronPort-AV: E=Sophos;i="4.97,562,1389744000"; d="scan'208,217";a="6475140"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 28 Feb 2014 15:09:53 +0000
Received: from [10.61.204.240] ([10.61.204.240]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1SF9qhf026988; Fri, 28 Feb 2014 15:09:52 GMT
Message-ID: <5310A6C0.2070300@cisco.com>
Date: Fri, 28 Feb 2014 15:09:52 +0000
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "radext@ietf.org" , dime mailing list 
Content-Type: multipart/alternative; boundary="------------050008090706030309080605"
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/40oFmhKvi_rPEmjgQ7wQ33VC5C0
Subject: [Dime] IETF 89: AAA tutorial on Sunday
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 15:09:57 -0000

This is a multi-part message in MIME format.
--------------050008090706030309080605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here is a reminder, just in case:

    1500-1650 GMT Introduction to Authentication, Authorization and
    Accounting (AAA) management for distributed IP networks - Buckingham
    

Regards, Benoit


--------------050008090706030309080605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    Here is a reminder, just in case:

    
1500-1650 GMT
      Introduction to Authentication, Authorization and Accounting (AAA)
      management for distributed IP networks - Buckingham

    

    Regards, Benoit

    

  


--------------050008090706030309080605--


From nobody Fri Feb 28 07:14:29 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BB71A080D for ; Fri, 28 Feb 2014 07:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGul4SMzQ0Tu for ; Fri, 28 Feb 2014 07:14:23 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EA1D01A07EB for ; Fri, 28 Feb 2014 07:14:22 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id u14so2515197lbd.19 for ; Fri, 28 Feb 2014 07:14:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lY9uzBpnWKs0DsYnrBQH8kaFt5kSgXPPsNGVvz3CcKQ=; b=QdBqxLaLnL5UvMcQkzUU1NDtEeAhjvme0D24apyuPPCBPzeqlDG2ICXFxfnCGSzhhS unThlOEKerDUOvfxmR+irHhRao1ydaNnCnLFSQ4Ryc6BOqrYqXd3XXVNA/9pCnj69v1Y Lk9RhTVxCSN6Fs7Tdtf0v7h5R4g8IcGr7zLwvoy9UfMpMhFg3ojD5BiWAfqaQE/qPU4E UJj2o+XBZpw1GVsYoMIk9cuITFUpJmsuoalCByCqaMNAglVUzKjw5oVEYExMOsK/mw+G v4qjTlGLPabUBcZ28ECIr8ps1uQLpZ01cvv+QnfSIvAz8Dx5Fh4XpefbeHaxvmBesjKA fvmA==
X-Received: by 10.112.22.196 with SMTP id g4mr6853303lbf.47.1393600460326; Fri, 28 Feb 2014 07:14:20 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id jt7sm4260563lbc.15.2014.02.28.07.14.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 07:14:17 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4F0F@DEMUMBX014.nsn-intra.net>
Date: Fri, 28 Feb 2014 17:14:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8273E45E-2063-459C-B8CF-F000FA457283@gmail.com>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com> <2771A62F-E982-4A31-A827 -E2C4AC14132B@nostrum.com> <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4F0F@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5QZTT5NJUq4O-2GWt-cYaoqiEG8
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 15:14:26 -0000

Uhh.. there was continuum to this thread. Sorry ;-) Let me come back to
this in a sec.

- Jouni

On Feb 28, 2014, at 5:07 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Dear Jouni,
> My understanding is that #32 is RESOLVED as follows:
>=20
> Agreed - Sequence-Number is of type Unsigned64.
>=20
> Agreed - When generated, a new sequence number must be greater than =
the sequence number contained in the active overload report to which it =
applies (including over reboot of that node).
> Note: this allows sequence numbers to start at 1 for the initial =
occurrence of an overload condition at a reporting node (where "initial =
occurrence means something like "moving from no overload to overload =
after a sufficiently long periode of no overload").=20
> When received, a sequence number is used to detect =
outdates/replays/freshness.
>=20
> Sequence numbers of expired OLRs MUST NOT be remembered by reacting =
nodes.
>=20
> Can be CLOSED when the next version of the draft correctly reflects =
this agreement.
>=20
> Ulrich
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Friday, February 28, 2014 3:01 PM
> To: dime@ietf.org list; Wiehe, Ulrich (NSN - DE/Munich); =
lionel.morand@orange.com Morand
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>=20
>=20
> 
>=20
> It seems we reached a conclusion here. So summarizing:
>=20
> o Document that the sequence number is:
> - Globally/eternally unique.
> - increase monotonically over time, including over a reboot.
> o Write a non-normative recommendation/suggestion how to create
>  sequence numbers fulfilling the above requirements (e.g. using
>  NTP as one component).
>=20
> @Ulrich or Lionel could you update the above into the ticket
> and close it?
>=20
>=20
>=20
> - JOuni
>=20
>=20
> On Feb 14, 2014, at 11:28 PM, Ben Campbell  wrote:
>=20
>> +1. It doesn't even have to be "suggested" in the since of a =
(non-normative) recommendation. It can merely be an example of an =
approach which meets the stated requirements.
>>=20
>> On Feb 13, 2014, at 6:25 AM, Steve Donovan  =
wrote:
>>=20
>>> Jouni,
>>>=20
>>> The important thing is to define the properties.  There should be no =
harm in giving one suggested implementation.
>>>=20
>>> Steve
>>>=20
>>> On 2/11/14 4:42 PM, Jouni Korhonen wrote:
>>>> If the NTP is only going to be guidance when building the globally
>>>> and eternally unique sequence number, IMHO better not mention NTP
>>>> then at all. Just include the required properties below. One less
>>>> mandatory reference..
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome=20
>>>> 
>>>> wrote:
>>>>=20
>>>>=20
>>>>> It sounds reasonable to me as well.
>>>>> /MCruz
>>>>>=20
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of Steve Donovan
>>>>> Sent: lunes, 10 de febrero de 2014 14:59
>>>>> To:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> +1
>>>>> On 2/10/14 7:47 AM,=20
>>>>> lionel.morand@orange.com
>>>>> wrote:
>>>>> I would add, maybe even before the format (NTP time based), that =
the real requirements for the sequence-number are:
>>>>>=20
>>>>> - Globally/eternally unique
>>>>> - increase monotonically over time, including over a reboot (as =
remind by Steve)=20
>>>>>=20
>>>>> The NTP time based type is just a guidance provided by the draft =
on how to generate sequence numbers with such properties.
>>>>>=20
>>>>> Lionel
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] De la part de Jouni Korhonen
>>>>> Envoy=E9 : samedi 8 f=E9vrier 2014 11:33
>>>>> =C0 : Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc :=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>>=20
>>>>> Sounds acceptable. Would the following then work for all:
>>>>>=20
>>>>> o clarify that once the overload report expires there is no
>>>>> reason to remember anything about it
>>>>> o the sequence number would be similar to session-id.. based=20
>>>>> on the NTP time + any vendor specific data to make it=20
>>>>> "globally and eternally unique".
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>>> 
>>>>> wrote:
>>>>>=20
>>>>> Steve,
>>>>>=20
>>>>> sounds like an acceptable proposal which allows to come back to =
sync after OLR expiry.
>>>>> This requires however an update of clause 5.5.2 to clearly state
>>>>> Once the overload report expires there is no reason to remember =
anything about it and the next overload report received could, =
conceivably have any value.=20
>>>>>=20
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Steve Donovan
>>>>> Sent: Thursday, February 06, 2014 4:50 PM
>>>>> To:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> A couple of things -=20
>>>>>=20
>>>>> The requirement is that the sequence number increase monotonically =
over time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time =
stamp to set the sequence number for the first overload report sent =
after a reboot and then increment the sequence number value by one for =
each subsequent overload report sent.  This actually has better =
properties than an NTP time stamp as it would take much longer to roll =
over.  One could also create a global sequence number service that is =
not tied to time and have a Diameter server query that global sequence =
number server after each reboot.
>>>>>=20
>>>>> We also have a duration timer on overload reports.  This gives us =
one way to reset.  It should only be required to remember the sequence =
number of an active overload report.  Once the overload report expires =
there is no reason to remember anything about it and the next overload =
report received could, conceivably have any value.=20
>>>>>=20
>>>>> The requirement we need is similar to the session-id in the base =
Diameter specification.  The wording there is -- "The Session-Id MUST be =
globally and eternally unique".  We just need eternally as the spacial =
differentiation is based on the context of the message carrying the =
overload report.
>>>>>=20
>>>>> It would be perfectly valid for the DOIC draft to suggest the use =
of NTP timestamps to populate the sequence number but it should be =
worded in a similar fashion as the Diameter base RFC -- The Session-Id =
includes a mandatory portion and an implementation-defined portion; a =
recommended format for the implementation-defined portion is outlined =
below ..."
>>>>>=20
>>>>> Steve
>>>>>=20
>>>>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>> I cannot understand what is the problem with mandating timestamp.
>>>>> But I can see interoperability problems with the current =
definition:
>>>>>=20
>>>>> Assume the sender sends sequence numbers
>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>>>> but the receicer for any reason receives=20
>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20=

>>>>> The receiver would accept
>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>>>>> and then silently discards
>>>>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
>>>>> with no way to come back to sync.
>>>>>=20
>>>>> Are we sure that this cannot happen?
>>>>>=20
>>>>> Mandating timestamp for sequence number generation at the sender =
and plausibility checking (i.e. received value must be between stored =
value and time of reception) for the receiver may not be the only way to =
solve the problem. But in the moment I don't see another way.
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Ben Campbell
>>>>> Sent: Wednesday, February 05, 2014 4:57 PM
>>>>> To: ext=20
>>>>> lionel.morand@orange.com
>>>>>=20
>>>>> Cc:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> My point is, we have an interop requirement that the sequence =
number always increases over time scope. We do not have the interop =
requirement that the sequence number be implemented as a time stamp. A =
time stamp is probably a good way to  meet the interop requirements, but =
it is not, in itself, an interop requirement.
>>>>>=20
>>>>> On Feb 5, 2014, at 9:53 AM,=20
>>>>>  
>>>>> wrote:
>>>>>=20
>>>>> Not sure to understand: if there is a kind of "interop =
requirement", it is a case for a "MUST".
>>>>> We are not violating anything.
>>>>>=20
>>>>> Reporting and reacting nodes will just rely on the Diameter =
interfaces to know how to handle the received sequence-number. So any =
MUST on the format of the sequence-number is acceptable if it avoids =
interop issues.
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : Ben Campbell [
>>>>> mailto:ben@nostrum.com
>>>>> ]=20
>>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
>>>>> =C0 : MORAND Lionel IMT/OLN
>>>>> Cc : Steve Donovan;=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> I concur with Steve on this one. Using a time stamp is a good way =
to meet the requirements, but it's not our job to normatively state an =
implementation. In fact, it violates an RFC 2119 "MUST" level =
requirement to do so. Section 6 of 2119 includes the following:
>>>>>=20
>>>>> "In particular, [normative requirements] MUST only be used where =
it is
>>>>> actually required for interoperation or to limit behavior which =
has
>>>>> potential for causing harm (e.g., limiting retransmisssions)  "
>>>>>=20
>>>>> The only appropriate reason to require a timestamp would be if we =
expected peers to interpret the field as a point in time. OTOH, it would =
be perfectly reasonable to state the actual interop requirements, then =
add a non-normative (probably indented) paragraph suggesting that a =
timestamp is a good way to do this.
>>>>>=20
>>>>> On Feb 5, 2014, at 9:37 AM,=20
>>>>> lionel.morand@orange.com
>>>>> wrote:
>>>>>=20
>>>>> I think the out-of-sync failover described by Ulrich is a good use =
case to mandate a specific semantic.
>>>>>=20
>>>>> Is there any specific NOT to mandate the use of NTP timestamps if =
it is a simple way to solve the possible issues and please everyone?
>>>>>=20
>>>>> Lionel
>>>>>=20
>>>>> De : DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] De la part de Steve Donovan
>>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
>>>>> =C0 :=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> How the sequence number is implemented is an implementation =
decision.  There is no reason to mandate that is be an NTP timestamp.  =
That should be included only as one way of addressing the requirement.
>>>>>=20
>>>>> Steve
>>>>>=20
>>>>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>>>>> I also agree.
>>>>>=20
>>>>> Regards,
>>>>> Nirav.
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org] On Behalf Of =
lionel.morand@orange.com
>>>>>=20
>>>>> Sent: Tuesday, February 04, 2014 11:50 PM
>>>>> To:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> The existing wording seems actually fuzzy.
>>>>> If it is "like an NTP timestamp", be proud and say it loud!
>>>>>=20
>>>>> In summary: ok with the proposal if it clarifies this handling of =
this sequence-number.
>>>>>=20
>>>>> Lionel
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : dime issue tracker [
>>>>> mailto:trac+dime@trac.tools.ietf.org
>>>>> ]
>>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
>>>>> =C0 : MORAND Lionel IMT/OLN
>>>>> Cc :=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : [dime] #32: Sequence-Number Time-Stamp values within =
OC-OLR
>>>>>=20
>>>>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>>=20
>>>>> The -01 draft says in clause 4.4:
>>>>>  =46rom the functionality point of view, the OC-Sequence-Number =
AVP MUST
>>>>>  be used as a non-volatile increasing counter between two overload
>>>>>  control endpoints (neglecting the fact that the contents of the =
AVP
>>>>>  is a 64-bit NTP timestamp [RFC5905]).  The sequence number is =
only
>>>>>  required to be unique between two overload control endpoints.
>>>>>  Sequence numbers are treated in uni-directional manner, i.e. two
>>>>>  sequence numbers on each direction between two endpoints are not
>>>>>  related or correlated.
>>>>>=20
>>>>>  When generating sequence numbers, the new sequence number MUST be
>>>>>  greater than any sequence number previously seen between two
>>>>>  endpoints within a time window that tolerates the wraparound of =
the
>>>>>  NTP timestamp (i.e. approximately 68 years).
>>>>>=20
>>>>>=20
>>>>> With this mechanism it is difficult to get back to sync once you =
are out  of sync (for whatever reason).
>>>>> It is proposed to mandate that the Sequence Number is a real =
64-bit NTP  timestamp (RFC5905) indicating the point in time when the =
OLR was created,  and to mandate that  OLRs with a time stamp higher =
than time of reception  must be ignored by the reacting node.
>>>>>=20
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> 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
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From nobody Fri Feb 28 07:30:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054101A086E for ; Fri, 28 Feb 2014 07:30: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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBjXwn5OkK-C for ; Fri, 28 Feb 2014 07:30:32 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id D9B091A0862 for ; Fri, 28 Feb 2014 07:30:29 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id p9so2511880lbv.24 for ; Fri, 28 Feb 2014 07:30:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xTEcn43emxT4OAprzdxZmFCXUwiyWbV7jB7uaEm1VJE=; b=POZZB+KYpOmZzkEU+i6/eRD7G0/kg5w7pMxLAamxubh64ltx0JatDiR1nNfwIvQ0i2 GdN2R982kybhFXQP7Gk52UrfEbjCJ5+sktB6FrJmHae6xupLsBy1xtRG3xLyCkJBM8GU p8F1DiGcOfE/OT8bFk+RYyFLEP4z2v2SOWyaEflYJYprSW/xgJDUEHL2OMikO4/iCuoX E3S5PyEHAWvyFtGFfm5oX0i32JYuapD6kkfB9c3mbiWczNuuy+7X/mBE9C4nMnTbjV5u YMS0oUh7u/KJr7Dz5yU6upfaTUNNdi+HslMUmdUPxcJIablyGV6I0MtS9NgTJWrQXMwb iciQ==
X-Received: by 10.112.63.193 with SMTP id i1mr2170587lbs.54.1393601427399; Fri, 28 Feb 2014 07:30:27 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id q8sm4342162lbr.3.2014.02.28.07.30.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 07:30:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net>
Date: Fri, 28 Feb 2014 17:30:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <30695D73-312B-498D-A855-B1FA5A0FF27D@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LYq6H60qwar1mAF6xx5ZeNOdXMU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 15:30:34 -0000

Going back in history..

On Feb 19, 2014, at 5:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> #32: Sequence-Number Time-Stamp values within OC-OLR
> =20
> I understand that we agreed the following principles:
> =20
> Sequence-Number is of type Time, however the value need not correspond =
to the point in time of generation.
> =20
> When generated, a new sequence number must be  greater than any =
sequence number previously generated by the same node (including over a =
reboot of that node)
> =20
> When received, a sequence number is used to detect =
outdates/replays/freshness.
> =20
> Sequence numbers of expired OLRs MUST NOT be remembered by reacting =
nodes.
> =20
> =20
> I did not understand the requirement for globally uniqueness as =
introduced by Jouni.
> Can Jouni please explain.

Originated from here:
http://www.ietf.org/mail-archive/web/dime/current/msg06600.html

So requiring global uniqueness is not desired anymore?=20

- Jouni



> =20
> Ulrich
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 07:37:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947AD1A0838 for ; Fri, 28 Feb 2014 07:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egxpO8JgGl4U for ; Fri, 28 Feb 2014 07:37:17 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 99CC61A083A for ; Fri, 28 Feb 2014 07:37:17 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1SFbEAk008000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 16:37:14 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1SFbD9i011322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 16:37:13 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Feb 2014 16:37:13 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 16:37:13 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] Issue#32 status
Thread-Index: Ac8tiAGtvQe9mwQAS968RUS8ackr7wHCZuSAAAJPGZA=
Date: Fri, 28 Feb 2014 15:37:12 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4F3D@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <30695D73-312B-498D-A855-B1FA5A0FF27D@gmail.com>
In-Reply-To: <30695D73-312B-498D-A855-B1FA5A0FF27D@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1465
X-purgate-ID: 151667::1393601834-00005322-6B956C43/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_MhGO0iytEyqg5jESu9htCUV3Dw
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 15:37:19 -0000

I think so; not required, not desired.

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Friday, February 28, 2014 4:30 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#32 status


Going back in history..

On Feb 19, 2014, at 5:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> #32: Sequence-Number Time-Stamp values within OC-OLR
> =20
> I understand that we agreed the following principles:
> =20
> Sequence-Number is of type Time, however the value need not correspond to=
 the point in time of generation.
> =20
> When generated, a new sequence number must be  greater than any sequence =
number previously generated by the same node (including over a reboot of th=
at node)
> =20
> When received, a sequence number is used to detect outdates/replays/fresh=
ness.
> =20
> Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes=
.
> =20
> =20
> I did not understand the requirement for globally uniqueness as introduce=
d by Jouni.
> Can Jouni please explain.

Originated from here:
http://www.ietf.org/mail-archive/web/dime/current/msg06600.html

So requiring global uniqueness is not desired anymore?=20

- Jouni



> =20
> Ulrich
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 07:44:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8980A1A00DE for ; Fri, 28 Feb 2014 07:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb9Ia8y__ZNv for ; Fri, 28 Feb 2014 07:44:02 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id F3D4A1A00E2 for ; Fri, 28 Feb 2014 07:44:01 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id n15so2775767lbi.41 for ; Fri, 28 Feb 2014 07:43:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ALlNYzdi91zjYJybsJ0W9LswigNUdC2ivKMNAzps5cg=; b=zzpYcI3Xw8tSBiaQ8JMxbZpcmslxDbxvKI1z8Ueq4a72rgY0SGNxM6Ww++t/hYN1oM Ll8OBlEhYnu3eTMw73c85ZHFPyDJ1x7OSyfRtNdBA9RgNI3xEEcECyhplGtLsdXL8iMp 9xpQc9dUZuFXb3sI6WGrGl4LtTdcl6Wx3tj1IdJoAk0qSU34bXfwWaJgxrt2RG1Rk14P fzUbXIZhp1hTYMVxD8wUUbLvXsWSYUH4y9O+JTfX9JuI7orI/9CTGLqeJ8jBovO/XLsu NGjbCUgNnddkiNBbaC+h9oClbtt3Ws+MthyQLSkMMzVa+eKSk+do7ELyiaejpZeek6v2 3I2A==
X-Received: by 10.112.139.134 with SMTP id qy6mr1835701lbb.66.1393602239340; Fri, 28 Feb 2014 07:43:59 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id td5sm4375481lbb.7.2014.02.28.07.43.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 07:43:58 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4F0F@DEMUMBX014.nsn-intra.net>
Date: Fri, 28 Feb 2014 17:43:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EB283C1-1B81-400A-8617-A07A6FAAB034@gmail.com>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <52F24BC0.6070600@usdonovans.com> <29564_1391614624_52F25AA0_29564_1057_1_6B7134B31289DC4FAF731D844122B36E487344@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2ACDC7E8-A46D-4618-92CE-B793AF3A8F75@nostrum.com> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com> <2771A62F-E982-4A31-A827 -E2C4AC14132B@nostrum.com> <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4F0F@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9RxDAk8_rHBQCd53fBaUm8cvnHw
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime]	#32:	Sequence-Number	Time-Stamp	values	within OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 15:44:05 -0000

First.. sorry for missing the continuum of the thread. My _bad_ mistake.


On Feb 28, 2014, at 5:07 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Dear Jouni,
> My understanding is that #32 is RESOLVED as follows:
>=20
> Agreed - Sequence-Number is of type Unsigned64.

This is/was ok, since time did not really fit anymore what was concluded =
even earlier.
=20
> Agreed - When generated, a new sequence number must be greater than =
the sequence number contained in the active overload report to which it =
applies (including over reboot of that node).

Ok.

> Note: this allows sequence numbers to start at 1 for the initial =
occurrence of an overload condition at a reporting node (where "initial =
occurrence means something like "moving from no overload to overload =
after a sufficiently long periode of no overload").=20
> When received, a sequence number is used to detect =
outdates/replays/freshness.
>=20
> Sequence numbers of expired OLRs MUST NOT be remembered by reacting =
nodes.

Ok.

>=20
> Can be CLOSED when the next version of the draft correctly reflects =
this agreement.

Different practises. In some groups we did close tickets once the =
proposed
change & conclusion was documented in the issue tracker.

One should still update the ticket to contain the conclusion even before
closing it. There is a place for comments. Makes it much easier to track
down the conclusions. (as seen here how easily one misses even a thread
of mails..)

- Jouni

>=20
> Ulrich
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Friday, February 28, 2014 3:01 PM
> To: dime@ietf.org list; Wiehe, Ulrich (NSN - DE/Munich); =
lionel.morand@orange.com Morand
> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>=20
>=20
> 
>=20
> It seems we reached a conclusion here. So summarizing:
>=20
> o Document that the sequence number is:
> - Globally/eternally unique.
> - increase monotonically over time, including over a reboot.
> o Write a non-normative recommendation/suggestion how to create
>  sequence numbers fulfilling the above requirements (e.g. using
>  NTP as one component).
>=20
> @Ulrich or Lionel could you update the above into the ticket
> and close it?
>=20
>=20
>=20
> - JOuni
>=20
>=20
> On Feb 14, 2014, at 11:28 PM, Ben Campbell  wrote:
>=20
>> +1. It doesn't even have to be "suggested" in the since of a =
(non-normative) recommendation. It can merely be an example of an =
approach which meets the stated requirements.
>>=20
>> On Feb 13, 2014, at 6:25 AM, Steve Donovan  =
wrote:
>>=20
>>> Jouni,
>>>=20
>>> The important thing is to define the properties.  There should be no =
harm in giving one suggested implementation.
>>>=20
>>> Steve
>>>=20
>>> On 2/11/14 4:42 PM, Jouni Korhonen wrote:
>>>> If the NTP is only going to be guidance when building the globally
>>>> and eternally unique sequence number, IMHO better not mention NTP
>>>> then at all. Just include the required properties below. One less
>>>> mandatory reference..
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome=20
>>>> 
>>>> wrote:
>>>>=20
>>>>=20
>>>>> It sounds reasonable to me as well.
>>>>> /MCruz
>>>>>=20
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of Steve Donovan
>>>>> Sent: lunes, 10 de febrero de 2014 14:59
>>>>> To:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> +1
>>>>> On 2/10/14 7:47 AM,=20
>>>>> lionel.morand@orange.com
>>>>> wrote:
>>>>> I would add, maybe even before the format (NTP time based), that =
the real requirements for the sequence-number are:
>>>>>=20
>>>>> - Globally/eternally unique
>>>>> - increase monotonically over time, including over a reboot (as =
remind by Steve)=20
>>>>>=20
>>>>> The NTP time based type is just a guidance provided by the draft =
on how to generate sequence numbers with such properties.
>>>>>=20
>>>>> Lionel
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] De la part de Jouni Korhonen
>>>>> Envoy=E9 : samedi 8 f=E9vrier 2014 11:33
>>>>> =C0 : Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc :=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>>=20
>>>>> Sounds acceptable. Would the following then work for all:
>>>>>=20
>>>>> o clarify that once the overload report expires there is no
>>>>> reason to remember anything about it
>>>>> o the sequence number would be similar to session-id.. based=20
>>>>> on the NTP time + any vendor specific data to make it=20
>>>>> "globally and eternally unique".
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>>> 
>>>>> wrote:
>>>>>=20
>>>>> Steve,
>>>>>=20
>>>>> sounds like an acceptable proposal which allows to come back to =
sync after OLR expiry.
>>>>> This requires however an update of clause 5.5.2 to clearly state
>>>>> Once the overload report expires there is no reason to remember =
anything about it and the next overload report received could, =
conceivably have any value.=20
>>>>>=20
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Steve Donovan
>>>>> Sent: Thursday, February 06, 2014 4:50 PM
>>>>> To:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> A couple of things -=20
>>>>>=20
>>>>> The requirement is that the sequence number increase monotonically =
over time, including over a reboot.  Use of NTP time is one way of doing =
this but is not the only way.  Someone could, for instance, use a time =
stamp to set the sequence number for the first overload report sent =
after a reboot and then increment the sequence number value by one for =
each subsequent overload report sent.  This actually has better =
properties than an NTP time stamp as it would take much longer to roll =
over.  One could also create a global sequence number service that is =
not tied to time and have a Diameter server query that global sequence =
number server after each reboot.
>>>>>=20
>>>>> We also have a duration timer on overload reports.  This gives us =
one way to reset.  It should only be required to remember the sequence =
number of an active overload report.  Once the overload report expires =
there is no reason to remember anything about it and the next overload =
report received could, conceivably have any value.=20
>>>>>=20
>>>>> The requirement we need is similar to the session-id in the base =
Diameter specification.  The wording there is -- "The Session-Id MUST be =
globally and eternally unique".  We just need eternally as the spacial =
differentiation is based on the context of the message carrying the =
overload report.
>>>>>=20
>>>>> It would be perfectly valid for the DOIC draft to suggest the use =
of NTP timestamps to populate the sequence number but it should be =
worded in a similar fashion as the Diameter base RFC -- The Session-Id =
includes a mandatory portion and an implementation-defined portion; a =
recommended format for the implementation-defined portion is outlined =
below ..."
>>>>>=20
>>>>> Steve
>>>>>=20
>>>>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>> I cannot understand what is the problem with mandating timestamp.
>>>>> But I can see interoperability problems with the current =
definition:
>>>>>=20
>>>>> Assume the sender sends sequence numbers
>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,....=20
>>>>> but the receicer for any reason receives=20
>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,....=20=

>>>>> The receiver would accept
>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000
>>>>> and then silently discards
>>>>> 3,  ... 3, 4, 4, ... 4, 5,....  4, 5, ....=20
>>>>> with no way to come back to sync.
>>>>>=20
>>>>> Are we sure that this cannot happen?
>>>>>=20
>>>>> Mandating timestamp for sequence number generation at the sender =
and plausibility checking (i.e. received value must be between stored =
value and time of reception) for the receiver may not be the only way to =
solve the problem. But in the moment I don't see another way.
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Ben Campbell
>>>>> Sent: Wednesday, February 05, 2014 4:57 PM
>>>>> To: ext=20
>>>>> lionel.morand@orange.com
>>>>>=20
>>>>> Cc:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> My point is, we have an interop requirement that the sequence =
number always increases over time scope. We do not have the interop =
requirement that the sequence number be implemented as a time stamp. A =
time stamp is probably a good way to  meet the interop requirements, but =
it is not, in itself, an interop requirement.
>>>>>=20
>>>>> On Feb 5, 2014, at 9:53 AM,=20
>>>>>  
>>>>> wrote:
>>>>>=20
>>>>> Not sure to understand: if there is a kind of "interop =
requirement", it is a case for a "MUST".
>>>>> We are not violating anything.
>>>>>=20
>>>>> Reporting and reacting nodes will just rely on the Diameter =
interfaces to know how to handle the received sequence-number. So any =
MUST on the format of the sequence-number is acceptable if it avoids =
interop issues.
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : Ben Campbell [
>>>>> mailto:ben@nostrum.com
>>>>> ]=20
>>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 16:47
>>>>> =C0 : MORAND Lionel IMT/OLN
>>>>> Cc : Steve Donovan;=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> I concur with Steve on this one. Using a time stamp is a good way =
to meet the requirements, but it's not our job to normatively state an =
implementation. In fact, it violates an RFC 2119 "MUST" level =
requirement to do so. Section 6 of 2119 includes the following:
>>>>>=20
>>>>> "In particular, [normative requirements] MUST only be used where =
it is
>>>>> actually required for interoperation or to limit behavior which =
has
>>>>> potential for causing harm (e.g., limiting retransmisssions)  "
>>>>>=20
>>>>> The only appropriate reason to require a timestamp would be if we =
expected peers to interpret the field as a point in time. OTOH, it would =
be perfectly reasonable to state the actual interop requirements, then =
add a non-normative (probably indented) paragraph suggesting that a =
timestamp is a good way to do this.
>>>>>=20
>>>>> On Feb 5, 2014, at 9:37 AM,=20
>>>>> lionel.morand@orange.com
>>>>> wrote:
>>>>>=20
>>>>> I think the out-of-sync failover described by Ulrich is a good use =
case to mandate a specific semantic.
>>>>>=20
>>>>> Is there any specific NOT to mandate the use of NTP timestamps if =
it is a simple way to solve the possible issues and please everyone?
>>>>>=20
>>>>> Lionel
>>>>>=20
>>>>> De : DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] De la part de Steve Donovan
>>>>> Envoy=E9 : mercredi 5 f=E9vrier 2014 15:34
>>>>> =C0 :=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> How the sequence number is implemented is an implementation =
decision.  There is no reason to mandate that is be an NTP timestamp.  =
That should be included only as one way of addressing the requirement.
>>>>>=20
>>>>> Steve
>>>>>=20
>>>>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
>>>>> I also agree.
>>>>>=20
>>>>> Regards,
>>>>> Nirav.
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org] On Behalf Of =
lionel.morand@orange.com
>>>>>=20
>>>>> Sent: Tuesday, February 04, 2014 11:50 PM
>>>>> To:=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values =
within OC-OLR
>>>>>=20
>>>>> The existing wording seems actually fuzzy.
>>>>> If it is "like an NTP timestamp", be proud and say it loud!
>>>>>=20
>>>>> In summary: ok with the proposal if it clarifies this handling of =
this sequence-number.
>>>>>=20
>>>>> Lionel
>>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : dime issue tracker [
>>>>> mailto:trac+dime@trac.tools.ietf.org
>>>>> ]
>>>>> Envoy=E9 : mardi 4 f=E9vrier 2014 09:50
>>>>> =C0 : MORAND Lionel IMT/OLN
>>>>> Cc :=20
>>>>> dime@ietf.org
>>>>>=20
>>>>> Objet : [dime] #32: Sequence-Number Time-Stamp values within =
OC-OLR
>>>>>=20
>>>>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>>>>=20
>>>>> The -01 draft says in clause 4.4:
>>>>>  =46rom the functionality point of view, the OC-Sequence-Number =
AVP MUST
>>>>>  be used as a non-volatile increasing counter between two overload
>>>>>  control endpoints (neglecting the fact that the contents of the =
AVP
>>>>>  is a 64-bit NTP timestamp [RFC5905]).  The sequence number is =
only
>>>>>  required to be unique between two overload control endpoints.
>>>>>  Sequence numbers are treated in uni-directional manner, i.e. two
>>>>>  sequence numbers on each direction between two endpoints are not
>>>>>  related or correlated.
>>>>>=20
>>>>>  When generating sequence numbers, the new sequence number MUST be
>>>>>  greater than any sequence number previously seen between two
>>>>>  endpoints within a time window that tolerates the wraparound of =
the
>>>>>  NTP timestamp (i.e. approximately 68 years).
>>>>>=20
>>>>>=20
>>>>> With this mechanism it is difficult to get back to sync once you =
are out  of sync (for whatever reason).
>>>>> It is proposed to mandate that the Sequence Number is a real =
64-bit NTP  timestamp (RFC5905) indicating the point in time when the =
OLR was created,  and to mandate that  OLRs with a time stamp higher =
than time of reception  must be ignored by the reacting node.
>>>>>=20
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> =
__________________________________________________________________________=
_______________________________________________
>>>>>=20
>>>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>>>>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>>>>=20
>>>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>>>>> they should not be distributed, used or copied without =
authorisation.
>>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>>> Thank you.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> 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
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From nobody Fri Feb 28 07:44:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805B31A02FF for ; Fri, 28 Feb 2014 07:44:41 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8sckBY8axAl for ; Fri, 28 Feb 2014 07:44:39 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id D976C1A00DE for ; Fri, 28 Feb 2014 07:44:38 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id p9so2551845lbv.38 for ; Fri, 28 Feb 2014 07:44:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bvIxADDLGsUnFTczQZuV0LO2xb7G+p+bOP3qth8ib9g=; b=v1U+vDaOyx2o6Yy+CyZbouzlm4FO/nFbvDxjZ7sgNE9iE2hbM2rhi/ftYOUr7Fbu5i T9jgbWAh32WfyYwfW3+Ewrtc/C6UJSit50v0DHiwzznax4pN+GlWnxWg7ijvItHns5bN rZEhNaBtAfOnL6SC71JG0V8m169Gfupq37/Qw6U/9tGiX7dZQhEkPM5hQAO5H5wr3Oqn gXTAoGKPEuEYSILz7cY/xivLNxH9ixkbr/YjYRPHY7OH1AOa9pofsmmWz7X7EVSN2bbA 3/jvUQmWhArHTLH7jRAHaBsnuHIltRFvIYi+vfJZGYlKrhEFntY/CPX8v4Gm4v9FNOlr 1XMA==
X-Received: by 10.153.4.43 with SMTP id cb11mr7290137lad.42.1393602276418; Fri, 28 Feb 2014 07:44:36 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id td5sm4375481lbb.7.2014.02.28.07.44.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 07:44:36 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4F3D@DEMUMBX014.nsn-intra.net>
Date: Fri, 28 Feb 2014 17:44:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <30695D73-312B-498D-A855-B1FA5A0FF27D@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4F3D@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kVBCraXJRL202Y5rmdnOlo-s_As
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 15:44:41 -0000

Ok.

On Feb 28, 2014, at 5:37 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> I think so; not required, not desired.
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Friday, February 28, 2014 4:30 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] Issue#32 status
>=20
>=20
> Going back in history..
>=20
> On Feb 19, 2014, at 5:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> #32: Sequence-Number Time-Stamp values within OC-OLR
>>=20
>> I understand that we agreed the following principles:
>>=20
>> Sequence-Number is of type Time, however the value need not =
correspond to the point in time of generation.
>>=20
>> When generated, a new sequence number must be  greater than any =
sequence number previously generated by the same node (including over a =
reboot of that node)
>>=20
>> When received, a sequence number is used to detect =
outdates/replays/freshness.
>>=20
>> Sequence numbers of expired OLRs MUST NOT be remembered by reacting =
nodes.
>>=20
>>=20
>> I did not understand the requirement for globally uniqueness as =
introduced by Jouni.
>> Can Jouni please explain.
>=20
> Originated from here:
> http://www.ietf.org/mail-archive/web/dime/current/msg06600.html
>=20
> So requiring global uniqueness is not desired anymore?=20
>=20
> - Jouni
>=20
>=20
>=20
>>=20
>> Ulrich
>>=20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From nobody Fri Feb 28 08:11:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166C21A00F3 for ; Fri, 28 Feb 2014 08:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id broThS2bmLUj for ; Fri, 28 Feb 2014 08:10:57 -0800 (PST)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7822F1A00DE for ; Fri, 28 Feb 2014 08:10:57 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id y1so2838981lam.34 for ; Fri, 28 Feb 2014 08:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2qEbRCQkEYjOo3lvv2hib21F/1AchVkFiyN+zm49ug0=; b=bGKYJaeVs7NKMa+uslMFNVHozDE8W+tzdmutrDJeecvtRVKUFqT7FUYF8ZLiViyPRB dHL6qVilJ9Aw2PausJMZ3XidMeN8EIQ8bnFoesHJYcVlNGttMTsx9Kl3M5qp23K019dg i13ucIO5azfUdDjxPp9sGSd1Vl/phpXUqE3A5PJZjDAVrEEQn+AZ5VozV87lz19kLpWG lnHBG5U6v4ssEKqAPfMctRb2qbmrNojru4nO8IbL3v3EazS4TVmf3M+Wb4UZuYFRQPJM vCOxckbJxjY6tsyXat6AAqdSeTv4wdiexCTqZaluym9C7LJDIKhS/ub82B9oQfRAieUX H69g==
X-Received: by 10.112.169.10 with SMTP id aa10mr1721388lbc.72.1393603854926; Fri, 28 Feb 2014 08:10:54 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id w2sm14310805lad.4.2014.02.28.08.10.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 08:10:52 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <52FCBEA4.3020000@usdonovans.com>
Date: Fri, 28 Feb 2014 18:10:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <612C78B4-6D66-487B-9C49-9CD6504027F7@gmail.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <52FCBEA4.3020000@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hwyEGz5nMwmDuticeFTAqCDoDdE
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 16:11:06 -0000

Steve,

Optimization as having the optional OC-Report-Type and when not present
using the default value. This was there to reduce the amount of =
transported
AVPs.

- JOuni

On Feb 13, 2014, at 2:46 PM, Steve Donovan  =
wrote:

> Jouni,
>=20
> Which optimization, defining a default value or Lionel's proposal to =
make it a required AVP?
>=20
> Steve
>=20
> On 2/13/14 6:05 AM, Jouni Korhonen wrote:
>> Agree that it is a small optimization, which I put there
>> because at the beginning there seemed to be a lot of worry
>> on every extra AVP ;-)
>>=20
>> I prefer having the AVP optional but with a default value
>> just like it is now. We have the same for the reduction
>> percentage and the validity time as well.
>>=20
>> - Jouni
>>=20
>> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"=20=

>> 
>>  wrote:
>>=20
>>=20
>>> Hi Mcruz
>>>=20
>>> The current description indicates that when not present the OLR is =
of type Host, which was fine for me and keeps my preference.=20
>>> We may have  deployments where Realm OLR is not used, or where =
statistically the HOST type is the most frequent, so to have the grouped =
OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a =
small optimization.
>>>=20
>>> Best regards
>>>=20
>>> JJacques=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : DiME [
>>> mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
>>>=20
>>> Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46
>>> =C0 :=20
>>> dime@ietf.org; maria.cruz.bartolome@ericsson.com
>>>=20
>>> Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>>=20
>>> Hi Maria Cruz,
>>>=20
>>> I'm assuming that you mean "required" instead of "mandatory", right?
>>>=20
>>> So instead of:
>>>=20
>>>   OC-OLR ::=3D < AVP Header: TBD2 >
>>>              < OC-Sequence-Number >
>>>              [ OC-Report-Type ]
>>>              [ OC-Reduction-Percentage ]
>>>              [ OC-Validity-Duration ]
>>>            * [ AVP ]
>>>=20
>>> You would prefer:
>>>=20
>>>   OC-OLR ::=3D < AVP Header: TBD2 >
>>>              < OC-Sequence-Number >
>>>              { OC-Report-Type }
>>>              [ OC-Reduction-Percentage ]
>>>              [ OC-Validity-Duration ]
>>>            * [ AVP ]
>>>=20
>>> And I'm fine with this proposal.
>>>=20
>>> Cheers,
>>>=20
>>> Lionel
>>>=20
>>> -----Message d'origine-----
>>> De : DiME [
>>> mailto:dime-bounces@ietf.org] De la part de dime issue tracker =
Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 : =
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org
>>>  Objet : [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>>=20
>>> #54: OC-Report-Type as mandatory AVP
>>>=20
>>> Now in chapter 4.6:
>>>=20
>>>    The default value of the OC-Report-Type AVP is 0 (i.e. the host
>>>    report).
>>>=20
>>> This AVP is always required, right? Then, I think it is more precise =
that  we define this AVP as mandatory.
>>>=20
>>> --=20
>>> =
-----------------------------------------------+------------------------
>>> -----------------------------------------------+---
>>> Reporter: =20
>>> maria.cruz.bartolome@ericsson.com
>>>   |      Owner:  MCruz
>>>     Type:  defect                             |  Bartolom=E9
>>> Priority:  major                              |     Status:  new
>>> Component:  draft-docdt-dime-ovli              |  Milestone:
>>> Severity:  Active WG Document                 |    Version:  1.0
>>>                                               |   Keywords:
>>> =
-----------------------------------------------+------------------------
>>> -----------------------------------------------+---
>>>=20
>>> Ticket URL:=20
>>> 
>>>=20
>>> dime=20
>>> 
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> =
__________________________________________________________________________=
_______________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>>=20
>> 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


From nobody Fri Feb 28 08:27:29 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFB11A032B for ; Fri, 28 Feb 2014 08:27:22 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h_dZjaMEwII for ; Fri, 28 Feb 2014 08:27:19 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id EE87E1A02D0 for ; Fri, 28 Feb 2014 08:27:18 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id mc6so2922918lab.27 for ; Fri, 28 Feb 2014 08:27:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RPzI+9KeRr/nOmsEwjn0y/UxaB0keJjiPhE18Ugk8c8=; b=Q12kRzC4iO+LGpiPGB32C/l+kYuCtlmE/M+lJ01KyxSJCpZLB9ckEHpNK1FNP8aKLm ljuS1ACFXlbEaNtz2G2819PoYff1IgqRxMY0R8Xja80ZKBH6gllyAKvxTfTQQZcumyAL nCC+WC0Nz5hGrgcqU5JWqyn15g/aBG8AHaBxmMirRo9We3cACYU2rVytsWmc02igfaTn +oXzxyyV4hRo/hoDmUpk/DTshfCIIhl5t+5Gv9XlVMB/+mAU7PyM+iYvxoP2cBXw/Amk IcYJ6+D4CTPCHetShfnQ1Um3lmBFy8L/1YNL0gm41Znog+kRghnTCYoWGBzWVF7VRK64 fEPQ==
X-Received: by 10.153.4.43 with SMTP id cb11mr7433394lad.42.1393604836269; Fri, 28 Feb 2014 08:27:16 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id cu8sm4499713lbb.12.2014.02.28.08.27.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 08:27:13 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>
Date: Fri, 28 Feb 2014 18:27:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oHozVgizsyyGkd0v9GxWuUZEDTM
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 16:27:22 -0000

Hi,

How having the AVP could be less error prone if it has a default
value and the receiver knows exactly how to proceed when the AVP
is not present?

If a node does not include it when it should, the implementation
is broken. Wouldn't a broken node be able to put wrong report
type into the AVP even if the AVP is mandatory?

Anyway, if it is my statement keeping issue #54 still open, consider
it resolved from my side. I am OK making the OC-Report-Type AVP as
required/mandatory AVP. Should we also consider it having a fixed
position just after the OC-Sequence-Number AVP as well since it is
going to in every OC-OLR?

- Jouni



On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome =
 wrote:

>=20
> Hello all,
>=20
> I understand JJ point of view, but I still tend to prefer to make it =
mandatory, since I think this is less error-prone, since the only node =
that knows the requested Report-Type is the reporting, if for any reason =
a reporting is omitting it (since it is optional), it will be always =
interpreted as HOST, but this type may be wrong.
>=20
> I think DEFAULT values should never be error-prone, but used in =
"general cases", as a simplification, like e.g. a default for the =
Validity-Duration. Default Validity-Duration will never be an "error", =
it could be not the best value (compared with another value perfectly =
tuned to reporting node overload situation) but never the use of a =
Default value should lead to an erroneous behavior.
>=20
> Best regards
> /MCruz
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: viernes, 14 de febrero de 2014 23:13
> To: Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>=20
> I actually prefer making it mandatory. The cost of adding it is =
trivial--even more so for a reporting node that only supports the =
default. The value of having it is less opportunity for interop errors.
>=20
> On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  =
wrote:
>=20
>>=20
>> Agree that it is a small optimization, which I put there because at=20=

>> the beginning there seemed to be a lot of worry on every extra AVP =
;-)
>>=20
>> I prefer having the AVP optional but with a default value just like =
it=20
>> is now. We have the same for the reduction percentage and the =
validity=20
>> time as well.
>>=20
>> - Jouni
>>=20
>> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:
>>=20
>>> Hi Mcruz
>>>=20
>>> The current description indicates that when not present the OLR is =
of type Host, which was fine for me and keeps my preference.=20
>>> We may have  deployments where Realm OLR is not used, or where =
statistically the HOST type is the most frequent, so to have the grouped =
OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a =
small optimization.
>>>=20
>>> Best regards
>>>=20
>>> JJacques
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de=20
>>> lionel.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =
=C0 :=20
>>> dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]=20=

>>> [dime] #54: OC-Report-Type as mandatory AVP
>>>=20
>>> Hi Maria Cruz,
>>>=20
>>> I'm assuming that you mean "required" instead of "mandatory", right?
>>>=20
>>> So instead of:
>>>=20
>>> OC-OLR ::=3D < AVP Header: TBD2 >
>>>            < OC-Sequence-Number >
>>>            [ OC-Report-Type ]
>>>            [ OC-Reduction-Percentage ]
>>>            [ OC-Validity-Duration ]
>>>          * [ AVP ]
>>>=20
>>> You would prefer:
>>>=20
>>> OC-OLR ::=3D < AVP Header: TBD2 >
>>>            < OC-Sequence-Number >
>>>            { OC-Report-Type }
>>>            [ OC-Reduction-Percentage ]
>>>            [ OC-Validity-Duration ]
>>>          * [ AVP ]
>>>=20
>>> And I'm fine with this proposal.
>>>=20
>>> Cheers,
>>>=20
>>> Lionel
>>>=20
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue=20
>>> tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :=20
>>> maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime]=20=

>>> [dime] #54: OC-Report-Type as mandatory AVP
>>>=20
>>> #54: OC-Report-Type as mandatory AVP
>>>=20
>>> Now in chapter 4.6:
>>>=20
>>>  The default value of the OC-Report-Type AVP is 0 (i.e. the host
>>>  report).
>>>=20
>>> This AVP is always required, right? Then, I think it is more precise =
that  we define this AVP as mandatory.
>>>=20
>>> --
>>> =
-----------------------------------------------+---------------------
>>> -----------------------------------------------+---
>>> -----------------------------------------------+---
>>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>>   Type:  defect                             |  Bartolom=E9
>>> Priority:  major                              |     Status:  new
>>> Component:  draft-docdt-dime-ovli              |  Milestone:
>>> Severity:  Active WG Document                 |    Version:  1.0
>>>                                             |   Keywords:
>>> =
-----------------------------------------------+---------------------
>>> -----------------------------------------------+---
>>> -----------------------------------------------+---
>>>=20
>>> Ticket URL: 
>>> dime 
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> =
_____________________________________________________________________
>>> ____________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 09:46:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DADF1A00B4 for ; Fri, 28 Feb 2014 09:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaTLeKHpt3Uf for ; Fri, 28 Feb 2014 09:46:28 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC681A0123 for ; Fri, 28 Feb 2014 09:46:28 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id hr13so2932694lab.17 for ; Fri, 28 Feb 2014 09:46:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=986VEqwSYsoOTCK+i0uuAVF/xCYNQKI1nkXYMwtIZdg=; b=kF6Iu61wIjDcV+sByOLeXx3TjaFP/EvX8uSdtQI/Bg8Cy0iRVVNzKTprre+EWXvyXS KzU9Bgbi8A7W6snxcu/lH+hoLIbmgAwUnczZlweMVkZtPvoG2lxKV3sT+jlsNCMo1J00 lvMzCeEPAa6NzyjXofX8sad8/1RqysYW9/IEXi/R0kFZnOnFgqhFP6lteIfRgP0ssgCn ZZ3/yw/WCPH9bn9WMmNiz7Wlo/mOmhFQ50gPq3c+iyCJF8b5+LG6ORDUC0yNO+F5fDKJ pN6S38vleZjw/8F9TnWXfjf20cZ6psSYMgMa+DJhGfg43RtO62exKr44WdKjnpYqVX/O f/ug==
X-Received: by 10.152.36.196 with SMTP id s4mr502452laj.24.1393609585865; Fri, 28 Feb 2014 09:46:25 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id gi5sm4723477lbc.4.2014.02.28.09.46.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 09:46:12 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com>
Date: Fri, 28 Feb 2014 19:46:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O0mH_sEJZp_n3L2MZjlzouZF8DE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 17:46:35 -0000

Ben,

On Feb 25, 2014, at 1:11 AM, Ben Campbell  wrote:

>=20
> On Feb 24, 2014, at 12:40 PM, Steve Donovan  =
wrote:
>=20
>> There has been no discussion of ticket #27.  I can't even find it on =
the DIME list, so I'm copying it here to initiate discussion.
>>=20
>> The proposal is for an agent to send a TOO-BUSY response when it =
throttles a request from a non supporting client.  The behavior of the =
agent in this case would be in the new section to be added to capture =
agent behavior as proposed in issue #24 (and various other places).
>>=20
>=20
> RFC6733 has the following to say about TOO_BUSY
>=20
> "When returned, a Diameter node SHOULD attempt to send the message to =
an alternate peer.  This error MUST only be used when a specific server =
is requested, and it cannot provide the requested saervice."

"when a specific server is requested" means the use of Destination-Host =
to me.

> Do those semantics and limitations apply to this usage? Is there a =
chance if incorrect behavior from a client that doesn't support DOIC, =
and therefore is not aware of this new usage of TOO_BUSY? For example, =
if an agent sends TOO_BUSY due due to a host OLR received from the an =
upstream server, the client might (actually SHOULD) try to reach that =
same server via an alternate agent. Is that okay?

I would say this could be a desired behaviour but I am not sure
whether it is okay. DIAMETER_TOO_BUSY is a protocol error, which
means an error-answer, which again probably is completely different
what the server sent (in the above example). Although this is allowed
(see the usage of Error-Reporting-Host AVP) but then RFC 6733 Section
6.2.2. MUST on sending STR to the server does not really fit our use
case.

A client knows from the Origin-Host & Error-Reporting-Host whether the
error came from the final destination or from an intermediate. It can
reason based that whether it needs to find a new server or just an
alternate path.

> I'm not sure I understand the original intent of the MUST only =
sentence. But the only way I know of to request a specific server is to =
use D-H. So would we allow the sending of a TOO_BUSY in response to a =
realm-routed request?

I would think twice updates to RFC6733. But if seen necessary,
I would do that in a separate I-D.

- Jouni


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


From nobody Fri Feb 28 10:15:17 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74741A0144 for ; Fri, 28 Feb 2014 10:15:14 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS4N1KoERzAz for ; Fri, 28 Feb 2014 10:15:10 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDD51A0252 for ; Fri, 28 Feb 2014 10:15:09 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id s7so2985603lbd.29 for ; Fri, 28 Feb 2014 10:15:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FaBJbN/kS1cj/NMtnyqlhZE96CzM30RUwCxnoE8PS8s=; b=oUNXP7XuPwa8deCoEa/UL7WXzpp8vD+OkRG6JUeJDDBYPj2exvbxNFL2vmX4RsNJVB xIhLDz47a/Q8ILC6sxQX3/AKqIPc8LREQfAQptiCByhQp/g9Thiwo97aytdRZk7UKSpA hFsbYh5xYnYuqgh+8r+RVVhRtuMnVPaZrtswTzdD45m84E/XSglBh+QGYZlTR+RxFz8N 47kzK33fV3x8gqw1GOc/GRljjhYc3QsujK8tju0L5ibMLgGjPTTecQ9UwmsOkMF+l9F4 5RRi3aDCIJnFAdPDkqWMatYyzWr7GodB/xm8CIOPzh6VKi1YoyahlwYFGcGsw6smGyEb mRCg==
X-Received: by 10.112.72.40 with SMTP id a8mr2096773lbv.68.1393611306362; Fri, 28 Feb 2014 10:15:06 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id q6sm14803780lal.3.2014.02.28.10.15.01 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 10:15:01 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <530BB87A.2000807@usdonovans.com>
Date: Fri, 28 Feb 2014 20:15:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B4649DF-1F73-4CD9-BA81-803F841C729F@gmail.com>
References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> <10919_1391878439_52F66127_10919_17464_1_6B7134B31289DC4FAF731D844122B36E4938F4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530BB87A.2000807@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cS0cggBmaKSDOTGDBN59elnf1vg
Cc: "ben@nostrum.com" , "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #44: Incorrect sequence number behavior
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 18:15:15 -0000

I am ok with the proposed wording here.

- Jouni


On Feb 24, 2014, at 11:24 PM, Steve Donovan  =
wrote:

> Lionel,
>=20
> I believe that Ben's issue was with the following wording in section =
4.3=20
>=20
> =20
>    The Sequence-Number AVP indicates the "freshness" of the OC-OLR =
AVP.
>    It is possible to replay the same OC-OLR AVP multiple times between
>    the overload control endpoints, however, when the OC-OLR AVP =
content
>    changes or sending endpoint otherwise wants the receiving endpoint =
to
>    update its overload control information, then the =
OC-Sequence-Number
>    AVP MUST contain a new greater value than the previously received.
>    The receiver SHOULD discard an OC-OLR AVP with a sequence number =
that
>    is less than previously received one.
>=20
>=20
> The wording you reference is in section 5.5.2.
>=20
> The above wording can be improved by changing the last sentence to =
"The reacting node SHOULD discard an OC-OLR AVP with a sequence number =
that is less than or equal to the previously received sequence number."
>=20
> Steve
>=20
> On 2/8/14 10:53 AM, lionel.morand@orange.com wrote:
>> Hi Ben,
>>=20
>> The case "equal" is discussed in the previous sentence.
>>=20
>> Check the following:
>>=20
>>    The received OC-Supported-Features AVP does not change the =
existing
>>    overload condition and/or traffic abatement algorithm settings if =
the
>>    OC-Sequence-Number AVP contains a value that is equal to the
>>    previously received/recorded one.  If the OC-Supported-Features =
AVP
>>    is received for the first time for the reporting node or the OC-
>>    Sequence-Number AVP value is less than the previously received/
>>    recorded one (and is outside the valid overflow window), then =
either
>>    the sequence number is stale (e.g. an intentional or unintentional
>>    replay) and SHOULD be silently discarded.
>>=20
>> The first sentence implies that the received OLR is ignored.=20
>>=20
>> And actually, there is something wrong in the last sentence. At the =
end,=20
>>=20
>>    recorded one (and is outside the valid overflow window), then =
either
>>    the sequence number is stale or replay (e.g. an intentional or =
unintentional
>>    replay) and SHOULD be silently discarded.
>>=20
>> The "either" in the first line should be removed.
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>>=20
>> -----Message d'origine-----
>> De : DiME [
>> mailto:dime-bounces@ietf.org
>> ] De la part de dime issue tracker
>> Envoy=E9 : vendredi 7 f=E9vrier 2014 22:49
>> =C0 :=20
>> draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
>>=20
>> Cc :=20
>> dime@ietf.org
>>=20
>> Objet : [Dime] [dime] #44: Incorrect sequence number behavior
>>=20
>> #44: Incorrect sequence number behavior
>>=20
>>  section 4.3 says that the receiver should discard an OLR with a =
sequence
>>  number less than the most recent. That should be less than or equal.
>>  Technically, re-applying the same OLR should make no difference, but =
it's
>>  never needed, and could be error prone if the sender screwed =
something up.
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 10:21:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246241A02A3 for ; Fri, 28 Feb 2014 10:21:52 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWa70-enPWF5 for ; Fri, 28 Feb 2014 10:21:50 -0800 (PST)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 97AD81A00FF for ; Fri, 28 Feb 2014 10:21:49 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id pv20so2198307lab.10 for ; Fri, 28 Feb 2014 10:21:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Roqnx+2Mv/z5dEG50cQLBeyUjdEsEdI3LluNbiqy6jk=; b=UoZh1r/9YRV/TVzTcNsE0spDW8d6BEssuEG0cPWO/5gYLHaIwKRRgiCjAXIm4d8DA/ KG0kfke+HMo0K8GAaSbK+D+E7cMcw9nGBCid8FMzxKN9Euu0vHBCrimD7k8Q7JCbvxdk BbZDASOoRsJJJKJATag/s4cv6/rMS63y3uN2gl0KryumVKqkCfeBBuNZKVrDbzRi5Y7T yg9K+BU1zAERwg7JEHGM/NjxaUXCNN9+VOtUQ2Og2aYoWgV5e77r8lhuuexWbLoB6Hr+ /XqdwIImXeAN1/n3BPE/QNPQVpq82g5NUit4FAgP2aie4H4P5bWRrM5czlsayCk9ptAS SX1A==
X-Received: by 10.152.88.82 with SMTP id be18mr12214630lab.3.1393611706981; Fri, 28 Feb 2014 10:21:46 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id mk5sm14813864lac.6.2014.02.28.10.21.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 10:21:42 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <530CC6A2.5010702@usdonovans.com>
Date: Fri, 28 Feb 2014 20:21:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com>  <530CB073.7000802@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net> <530CC6A2.5010702@usdonovans.com>
To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lHES7NkEkPqIbYaYgRX20-wZwfM
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Issue#32 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 18:21:52 -0000

A question.. how much is "a sufficiently long period of no overload"?
I'd like to see some guidance or minimum values documented.

- Jouni


On Feb 25, 2014, at 6:36 PM, Steve Donovan  =
wrote:

> Ulrich,
>=20
> Yes, with that period being long enough for the reporting node to be =
confident that all previously sent overload reports have expired.
>=20
> Steve
>=20
> On 2/25/14 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve, Ben,
>>=20
>> for my clarification, your proposal is to say
>>=20
>> ***
>> Sequence number is of type Unsigned64.
>>=20
>> When generated, a new sequence number must be greater than the =
sequence number contained in the active overload report to which it =
applies (including over reboot of that node).  Note: this allows =
sequence numbers to start at 1 for the initial occurrence of an overload =
condition at a reporting node.
>> ***
>>=20
>> If so, what is meant by "initial occurrence of an overload =
condition"?
>>=20
>> I guess it means something like moving from no overload to overload =
after a sufficiently long periode of no overload
>>=20
>> Please clarify
>>=20
>> Ulrich
>>=20
>>=20
>> From: DiME [
>> mailto:dime-bounces@ietf.org
>> ] On Behalf Of ext Steve Donovan
>> Sent: Tuesday, February 25, 2014 4:02 PM
>> To: Ben Campbell
>> Cc:=20
>> dime@ietf.org
>>  list
>> Subject: Re: [Dime] Issue#32 status
>>=20
>> I agree with the suggested change.
>>=20
>> Steve
>> On 2/24/14 5:00 PM, Ben Campbell wrote:
>> + 1, except as noted:
>>=20
>> On Feb 24, 2014, at 2:33 PM, Steve Donovan=20
>> 
>>  wrote:
>>=20
>> Ulrich,
>>=20
>> Would you agree to the following to replace the first two statements:
>>=20
>> Sequence number is of type Unsigned64.
>>=20
>> When generated, a new sequence number must be greater than the =
sequence number contained in the active overload report to which it =
applies (including over reboot of that node).  Note: this allows =
sequence numbers to start at 1 for any occurrence of overload at a =
reporting node.  This, I think, allows us to ignore wraparound issues as =
wraparound will never happen.  Unless we are worried about a server =
staying in overload for billions of years (assuming reports with a ten =
minute validity period refreshed every five minutes).
>>=20
>> s/ any occurrence of overload / the initial occurrence of an overload =
condition
>>=20
>>=20
>> The other two statements are good.
>>=20
>> Steve
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Feb 28 11:07:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585D41A016C for ; Fri, 28 Feb 2014 11:07:55 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBEmVNbMYUnm for ; Fri, 28 Feb 2014 11:07:53 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48C1A013A for ; Fri, 28 Feb 2014 11:07:52 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id 10so2960567lbg.21 for ; Fri, 28 Feb 2014 11:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OfMCfJz5tEsbyf9BsJrvi1WimlWFtP6Myq1TcpwEEkY=; b=oDUAxsn+jSua9neBmCZDjawqJXGg34vRLrk6cCNnub2NLD+A5jyuaIdOMJdc2DqoJq dXkzLLsufISzc2OsoqJUfzY8t5KbmrHjmBceUGdLbvD2ln3wJ/NWsvWt+rAb78BSX/e2 8dWKhxEwQ9JO9jUuyAp+i5oLAA1pHQrRPu6htKSca3wmGpK6EzYu0m7YCHRjU8tkTwyy 1Aus6HVB7DnyPrx737s1ZQf6Wlmq1KiJJG7HLzmhyaB2C9Lxtv4T9oHcFtLNyIERzI7H qeBzACg7/JJFn+ya/afGs3FO30d0h6MBMhSVQ3BY6UxuX1WuxMWp0qVUp3ES/IvwUHJN 7VHg==
X-Received: by 10.152.206.42 with SMTP id ll10mr12621981lac.16.1393614470521;  Fri, 28 Feb 2014 11:07:50 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id gi5sm4991384lbc.4.2014.02.28.11.07.45 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 11:07:45 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <530BC272.509@usdonovans.com>
Date: Fri, 28 Feb 2014 21:07:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <04C4A8D6-1F8E-4E42-ACF5-F35E0A6483BF@gmail.com>
References: <087A34937E64E74E848732CFF8354B9209784033@ESESSMB101.ericsson.se> <530771A6.4030002@usdonovans.com> <087A34937E64E74E848732CFF8354B920978435A@ESESSMB101.ericsson.se>  <530BC272.509@usdonovans.com>
To: Steve Donovan , Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AdFJ1RcPK54ULH0I_DA8VCUauZU
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 19:07:55 -0000

Taking #29 agreed part also into account some proposed text to 5.5.2:


OLD:
   The received OC-Supported-Features AVP does not change the existing
   overload condition and/or traffic abatement algorithm settings if the
   OC-Sequence-Number AVP contains a value that is equal to the
   previously received/recorded one.  If the OC-Supported-Features AVP
   is received for the first time for the reporting node or the OC-
   Sequence-Number AVP value is less than the previously received/
   recorded one (and is outside the valid overflow window), then either
   the sequence number is stale (e.g. an intentional or unintentional
   replay) and SHOULD be silently discarded.

   The OC-OLR AVP contains the necessary information of the overload
   condition on the reporting node.  Similarly to the OC-Supported-
   Features's sequence numbering, the OC-OLR AVP also has the OC-
   Sequence-Number AVP and its handling is similar to the one in the OC-
   Supported-Features AVP.  The reacting node MUST update its overload
   condition state whenever receiving the OC-OLR AVP for the first time
   or the OC-Sequence-Number sub-AVP indicates a change in the OC-OLR
   AVP.
NEW:
   The received OC-Supported-Features AVP does not change the existing
   traffic abatement algorithm settings if the AVP contains a value that
   is equal to the previously received/recorded one.

- Jouni


On Feb 25, 2014, at 12:06 AM, Steve Donovan  =
wrote:

> There is still an issue with the text Maria Cruz points out.  This =
part -- If the OC-Supported-Features AVP is received for the first time =
for the reporting node -- is erroneous and should be removed from the =
sentence.
>=20
> Steve
>=20
> On 2/21/14 11:24 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>> Hi MCruz
>> =20
>> The text  you propose to remove deals with the Seq number within  =
OC-Supported features, because of duplication with another text, but =
this other text text relates to the seq number handling within the =
OC-OLR AVP.
>> I think we can keep two texts, one for the seq number  within =
OC-Supported features  and another one for  the seq number  within =
OC-OLR AVP,. We will then see how the text  for seq number  within =
OC-Supported features evolves with the #29  outputs.
>> =20
>> Best regards
>> =20
>> JJacques =20
>> =20
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz =
Bartolome
>> Envoy=E9 : vendredi 21 f=E9vrier 2014 16:42
>> =C0 : dime@ietf.org
>> Objet : Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
>> =20
>> Steve,
>> =20
>> Extracted text is duplicated now, this paragraph I referred is simply =
wrong.
>> But I agree duplicated text should be revised due to issue#29, but =
this is up to this ticket to provide the alternative text.
>> =20
>> Cheers
>> /MCruz
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>> Sent: viernes, 21 de febrero de 2014 16:33
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #53: 5.5.2 chapter typo? - conclusion
>> =20
>> Maria Cruz,
>>=20
>> I think we need to see the replacement text before concluding this =
ticket.
>>=20
>> Steve
>>=20
>> On 2/21/14 2:51 AM, Maria Cruz Bartolome wrote:
>> =20
>> #53: 5.5.2 chapter typo?
>> =20
>> Following text will be deleted:
>> =20
>>     .........  If the OC-Supported-Features AVP
>>     is received for the first time for the reporting node or the OC-
>>     Sequence-Number AVP value is less than the previously received/
>>     recorded one (and is outside the valid overflow window), then =
either
>>     the sequence number is stale (e.g. an intentional or =
unintentional
>>     replay) and SHOULD be silently discarded.
>> =20
>>  As long as, the situations that it refers are covered later in the =
same chapter.
>> =20
>> =20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>> =20
>> =20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime