From nobody Mon Nov 3 06:27: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 713F31A0377 for ; Mon, 3 Nov 2014 06:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 uFqcFRqoct7D for ; Mon, 3 Nov 2014 06:27:44 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB631A0369 for ; Mon, 3 Nov 2014 06:27:44 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63284 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XlIbe-0008QS-ME for dime@ietf.org; Mon, 03 Nov 2014 06:27:43 -0800 Message-ID: <545790DD.3070702@usdonovans.com> Date: Mon, 03 Nov 2014 08:27:41 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-DER2FJ7_eeUElAnPFuSefpUKIg Subject: [Dime] Review of DOIC security section X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 14:27:45 -0000 All, I have the following comments/questions from a review of the security section in the -04 version of the DOIC draft. In general, the section looks good, with possible changes needed for the following comments: Section 9.1 - paragraph 5 - The Realm report attack would require the Origin-Realm in an answer to be different than the Destination-Realm in the request. To protect against this nodes should validate the routing headers in answer messages. This is already addressed in the previous paragraph on validating that an answer is properly constructed. It might be good to emphasize the need for making sure the answer message is properly constructed for this threat model as well. Section 9.3 - Should we add that with the loss algorithm there is no effective way for a reporting node to know if a reduction has been applied by reporting nodes? Regards, Steve From nobody Mon Nov 3 09: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 D10FF1A6ED8 for ; Mon, 3 Nov 2014 09:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.195 X-Spam-Level: X-Spam-Status: No, score=-13.195 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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.594, 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 P71pp5MQX8Bx for ; Mon, 3 Nov 2014 09:43:44 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C771D1A1B9C for ; Mon, 3 Nov 2014 09:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44141; q=dns/txt; s=iport; t=1415036622; x=1416246222; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=bsmIVpGoyo1IEzuUKPLZP0oCki6wUHvS2JjG8ORNswE=; b=MgKhjA1bKCi0L1wmADJxrONqbNI4gCm/oCJoL3Hft2RM7kfxSOmND5sJ uhKFKTk+enCwUdYW/PuQGZm4LiXZkCJFINnaN6iq6AVUdgRTE58pZqkS+ bWjHjiVrySjPw1gyPq5V9b4UHGQNrzAhR44Df3FoGYnDFrfTbapWH57Ua 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYEAMC9V1StJssW/2dsb2JhbABTCYNiWIhhxR8BCYdNAoE5AQEBAQF9hAMBAQMBAQEBFwFQAwoRCyEWAQENCQMCAQIBFTAGAQwGAgEBF4gdCQ3HdwEBAQEBAQQBAQEBAQEBARYEinSFQQMBXoRLBYY0AYlGh0SBIUyEVYExhkSHKg+DGYQJgXyBfTwvgQYBBhmBJQEBAQ X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208,217";a="234944340" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 03 Nov 2014 17:43:39 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA3Hhcg7017444; Mon, 3 Nov 2014 17:43:38 GMT Message-ID: <5457BECA.3050905@cisco.com> Date: Mon, 03 Nov 2014 18:43:38 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Ben Campbell , "dime@ietf.org list" References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> In-Reply-To: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> Content-Type: multipart/alternative; boundary="------------010601020906090602020407" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IN5EJeid-M9-TEVr3BD1W2k-AdM Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 17:43:52 -0000 This is a multi-part message in MIME format. --------------010601020906090602020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ben, Thanks for your detailed analysis. While this is good, what is required is the justification of why some requirements are not met with DOIC and why have you decided to postpone some RFC 7068 requirements? Then you can list those requirements. Regards, Benoit > Hi, > Benoit requested that the DOIC draft include a requirements analysis against the requirements from RFC 7068. I've made an attempt that that, below. > I realize not everyone will agree on my analysis, and there is considerable room for discussion. However, given Benoit's request, I think it's important to get these in as soon as possible; if not in 04, then soon afterwards (i.e. before WGLC, and preferably before Honolulu.) > I also created a branch called "Reqs-Analysis" in the GitHub repository that contains these in XML form. > Thanks! > Ben. > ---------------------------------------------- > Appendix D. Requirements Analysis > > This section analyzes the mechanism described in this document > against the set of requirements detailed in [RFC7068]. > > D.1. General > > REQ 1: The solution MUST provide a communication method for Diameter > nodes to exchange load and overload information. > > *Partially Compliant*. The mechanism uses new AVPs > piggybacked on existing Diameter messages to exchange > overload information. It does not currently support "load" > information. Indication of "Load" information has been left > for a future extension. > > > > REQ 2: The solution MUST allow Diameter nodes to support overload > control regardless of which Diameter applications they > support. Diameter clients and agents must be able to use the > received load and overload information to support graceful > behavior during an overload condition. Graceful behavior > under overload conditions is best described by REQ 3. > > *Compliant*. The DOIC AVPs can be used in any application > that allows the extension of AVPs. > > > > REQ 3: The solution MUST limit the impact of overload on the overall > useful throughput of a Diameter server, even when the > incoming load on the network is far in excess of its > capacity. The overall useful throughput under load is the > ultimate measure of the value of a solution. > > *Compliant*. DOIC provides information that nodes can use to > reduce the impact of overload. > > > > REQ 4: Diameter allows requests to be sent from either side of a > connection, and either side of a connection may have need to > provide its overload status. The solution MUST allow each > side of a connection to independently inform the other of its > overload status. > > *Compliant*. DOIC AVPs can be included regardless of > transaction "direction" > > > > REQ 5: Diameter allows nodes to determine their peers via dynamic > discovery or manual configuration. The solution MUST work > consistently without regard to how peers are determined. > > *Compliant*. DOIC contains no assumptions about how peers are > discovered. [Note: This may require further study] > > > > REQ 6: The solution designers SHOULD seek to minimize the amount of > new configuration required in order to work. For example, it > is better to allow peers to advertise or negotiate support > for the solution, rather than to require that this knowledge > to be configured at each node. > > *Partially Compliant*. Most DOIC parameters are advertised > using the DOIC capability announcement mechanism. However, > there are some situations where configuration is required. > For example, a DOIC node detect the fact that a peer may not > support DOIC when nodes on the other side of the non- > supporting node do support DOIC without configuration. > > > > D.2. Performance > > REQ 7: The solution and any associated default algorithm(s) MUST > ensure that the system remains stable. At some point after > an overload condition has ended, the solution MUST enable > capacity to stabilize and become equal to what it would be in > the absence of an overload condition. Note that this also > requires that the solution MUST allow nodes to shed load > without introducing non-converging oscillations during or > after an overload condition. > > *Compliant*. The specification offers guidance that > implementations should apply hysteresis when recovering from > overload, and avoid sudden ramp ups in offered load when > recovering. > > > > REQ 8: Supporting nodes MUST be able to distinguish current overload > information from stale information. > > *Partially Compliant*. DOIC overload reports are "soft > state", that is they expire after an indicated period. DOIC > nodes may also send reports that end existing overload > conditions. DOIC requires reporting nodes to ensure that all > relevant reacting nodes receive overload reports. > > However, since DOIC does not allow reports to send OLRs in > watchdog messages, if an overload condition results in zero > offered load, the reporting node cannot update the condition > until the expiration of the original OLR. > > > > REQ 9: The solution MUST function across fully loaded as well as > quiescent transport connections. This is partially derived > from the requirement for stability in REQ 7. > > *Not Compliant*. DOIC does not allow OLRs to be sent over > quiescent transport connections. This is due to the fact > that OLRs cannot be sent outside of the application to which > they apply. > > > > REQ 10: Consumers of overload information MUST be able to determine > when the overload condition improves or ends. > > *Partially Compliant*. (See response to previous two > requirements.) > > > > REQ 11: The solution MUST be able to operate in networks of different > sizes. > > *Compliant*. DOIC makes no assumptions about the size of the > network. DOIC can operate purely between clients and > servers, or across agents. > > > > REQ 12: When a single network node fails, goes into overload, or > suffers from reduced processing capacity, the solution MUST > make it possible to limit the impact of the affected node on > other nodes in the network. This helps to prevent a small- > scale failure from becoming a widespread outage. > > *Partially Compliant*. DOIC allows overload reports for an > entire realm, where abated traffic will not be redirected > towards another server. But in situations where nodes choose > to divert traffic to other nodes, DOIC offers no way of > knowing whether the new recipients can handle the traffic if > they have not already indicated overload. This may be > mitigated with the use of a future "load" extension, or with > the use of proprietary dynamic load-balancing mechanisms. > > > > REQ 13: The solution MUST NOT introduce substantial additional work > for a node in an overloaded state. For example, a > requirement for an overloaded node to send overload > information every time it received a new request would > introduce substantial work. > > *Not Compliant*. DOIC does in fact encourage an overloaded > node to send an OLR in every response. The working group > that other mechanisms to ensure that every relevant node > receives an OLR would create even more work. [Note: This > needs discussion.] > > > > REQ 14: Some scenarios that result in overload involve a rapid > increase of traffic with little time between normal levels > and levels that induce overload. The solution SHOULD provide > for rapid feedback when traffic levels increase. > > *Compliant*. The piggyback mechanism allows OLRs to be sent > at the same rate as application traffic. > > > > REQ 15: The solution MUST NOT interfere with the congestion control > mechanisms of underlying transport protocols. For example, a > solution that opened additional TCP connections when the > network is congested would reduce the effectiveness of the > underlying congestion control mechanisms. > > *Compliant*. DOIC does not require or recommend changes in > the handling of transport protocols or connections. > > > > D.3. Heterogeneous Support for Solution > > 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. > > *Partially Compliant*. DOIC works with most mixed-deployment > scenarios. However, it cannot work across a non-supporting > proxy that modifies Origin-Host AVPs in answer messages. > DOIC will have limited impact in networks where the nodes > that perform server selections do not support the mechanism. > > > > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. > > *Compliant*. In most mixed-support deployment, DOIC will > offer at least some value, and will not make things worse. > > > > 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. > > *Compliant*. DOIC provides mechanisms to abate load from non- > supporting sources. Furthermore, it recommends that > reporting nodes will still need to be able to apply whatever > protections they would ordinarily apply if DOIC were not in > use. > > > > REQ 19: It MUST be possible to use the solution between nodes in > different realms and in different administrative domains. > > *Partially Compliant*. DOIC allows sending OLRs across > administrative domains, and potentially to nodes in other > realms. However, an OLR cannot indicate overload for realms > other than the one in the Origin-Realm AVP of the containing > answer. > > > > REQ 20: Any explicit overload indication MUST be clearly > distinguishable from other errors reported via Diameter. > > *Compliant*. DOIC sends explicit overload indication in > overload reports. It does not depend on error result codes. > [Note: I don't think the resuse of too-busy and unable-to- > comply for throttled requests impacts this requirement. Do > others agree?] > > > > REQ 21: In cases where a network node fails, is so overloaded that it > cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > overload. The solution MUST result in at least as much > useful throughput as would have resulted if the solution were > not in place. > > *Compliant*. DOIC overload reports have the primary effect of > suppressing message retries in overload conditions. DOIC > recommends that messages never be silently dropped if at all > possible. > > > > D.4. Granular Control > > REQ 22: The solution MUST provide a way for a node to throttle the > amount of traffic it receives from a peer node. This > throttling SHOULD be graded so that it can be applied > gradually as offered load increases. Overload is not a > binary state; there may be degrees of overload. > > *Compliant*. The "loss" algorithm expresses a percentage > reduction. > > > > REQ 23: The solution MUST provide sufficient information to enable a > load-balancing node to divert messages that are rejected or > otherwise throttled by an overloaded upstream node to other > upstream nodes that are the most likely to have sufficient > capacity to process them. > > *Not Compliant*. DOIC provides no built in mechanism to > determine the best place to divert messages that would > otherwise be throttled. This can be accomplished with a > future "load" extension, or with proprietary load balancing > mechanisms. > > > > REQ 24: The solution MUST provide a mechanism for indicating load > levels, even when not in an overload condition, to assist > nodes in making decisions to prevent overload conditions from > occurring. > > *Not Compliant*. "Load" information has been left for a > future extension. > > > > D.5. Priority and Policy > > REQ 25: The base specification for the solution SHOULD offer general > guidance on which message types might be desirable to send or > process over others during times of overload, based on > application-specific considerations. For example, it may be > more beneficial to process messages for existing sessions > ahead of new sessions. Some networks may have a requirement > to give priority to requests associated with emergency > sessions. Any normative or otherwise detailed definition of > the relative priorities of message types during an overload > condition will be the responsibility of the application > specification. > > *Compliant*. The specification offers guidance on how > requests might be prioritized for different types of > applications. > > > > REQ 26: The solution MUST NOT prevent a node from prioritizing > requests based on any local policy, so that certain requests > are given preferential treatment, given additional > retransmission, not throttled, or processed ahead of others. > > *Compliant*. Nothing in the specification prevents > application-specific, implementation-specific, or local > policies. > > > > D.6. Security > > REQ 27: The solution MUST NOT provide new vulnerabilities to > malicious attack or increase the severity of any existing > vulnerabilities. This includes vulnerabilities to DoS and > DDoS attacks as well as replay and man-in-the-middle attacks. > Note that the Diameter base specification [RFC6733] lacks > end-to-end security and this must be considered (see the > Security Considerations in [RFC7068]). Note that this > requirement was expressed at a high level so as to not > preclude any particular solution. Is is expected that the > solution will address this in more detail. > > *Unknown*. [Needs further analysis.] > > > > REQ 28: The solution MUST NOT depend on being deployed in > environments where all Diameter nodes are completely trusted. > It SHOULD operate as effectively as possible in environments > where other nodes are malicious; this includes preventing > malicious nodes from obtaining more than a fair share of > service. Note that this does not imply any responsibility on > the solution to detect, or take countermeasures against, > malicious nodes. > > *Partially Compliant*. Since all Diameter security is > currently at the transport layer, nodes must trust immediate > peers to enforce trust policies. However, there are > situations where a DOIC node cannot determine if an immediate > peer supports DOIC. The authors recommend an expert security > review. > > > > REQ 29: It MUST be possible for a supporting node to make > authorization decisions about what information will be sent > to peer nodes based on the identity of those nodes. This > allows a domain administrator who considers the load of their > nodes to be sensitive information to restrict access to that > information. Of course, in such cases, there is no > expectation that the solution itself will help prevent > overload from that peer node. > > *Partially Compliant*. (See response to previous > requirement.) > > > > REQ 30: The solution MUST NOT interfere with any Diameter-compliant > method that a node may use to protect itself from overload > from non-supporting nodes or from denial-of-service attacks. > > *Compliant*. The specification recommends that any such > protection mechanism needed without DOIC should continue to > be employed with DOIC. > > > > D.7. Flexibility and Extensibility > > 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. > > *Partially Compliant*. All DOIC overload reports are scoped > to the specific application and realm. Inside that scope, > overload can be reported at the specific server or whole > realm scope. As currently specified, DOIC cannot indicate > local overload for an agent. At the time of this writing, > the DIME working group has plans to work on an agent-overload > extension. > > DOIC allows new "scopes" through the use of extended report > types. > > > > REQ 32: The solution MUST provide a method for extending the > information communicated and the algorithms used for overload > control. > > *Compliant*. DOIC allows new report types and abatement > algorithms to be created. These may be indicated using the > OC-Supported-Features AVP. > > > > REQ 33: The solution MUST provide a default algorithm that is > mandatory to implement. > > *Compliant*. The "loss" algorithm is mandatory to implement. > > > > REQ 34: The solution SHOULD provide a method for exchanging overload > and load information between elements that are connected by > intermediaries that do not support the solution. > > *Partially Compliant*. DOIC information can traverse non- > supporting agents, as long as those agents do not modify > certain AVPs. (e.g., Origin-Host) > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------010601020906090602020407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ben,

Thanks for your detailed analysis.
While this is good, what is required is the justification of why some requirements are not met with DOIC and why have you decided to postpone some RFC 7068 requirements? Then you can list those requirements.

Regards, Benoit
Hi,
Benoit requested that the DOIC draft include a requirements analysis against the requirements from RFC 7068. I’ve made an attempt that that, below.
I realize not everyone will agree on my analysis, and there is considerable room for discussion. However, given Benoit’s request, I think it’s important to get these in as soon as possible; if not in 04, then soon afterwards (i.e. before WGLC, and preferably before Honolulu.)
I also created a branch called “Reqs-Analysis" in the GitHub repository that contains  these in XML form.
Thanks!
Ben.
----------------------------------------------
Appendix D.  Requirements Analysis

   This section analyzes the mechanism described in this document
   against the set of requirements detailed in [RFC7068].

D.1.  General

   REQ 1:  The solution MUST provide a communication method for Diameter
           nodes to exchange load and overload information.

           *Partially Compliant*. The mechanism uses new AVPs
           piggybacked on existing Diameter messages to exchange
           overload information.  It does not currently support "load"
           information.  Indication of "Load" information has been left
           for a future extension.



   REQ 2:  The solution MUST allow Diameter nodes to support overload
           control regardless of which Diameter applications they
           support.  Diameter clients and agents must be able to use the
           received load and overload information to support graceful
           behavior during an overload condition.  Graceful behavior
           under overload conditions is best described by REQ 3.

           *Compliant*. The DOIC AVPs can be used in any application
           that allows the extension of AVPs.



   REQ 3:  The solution MUST limit the impact of overload on the overall
           useful throughput of a Diameter server, even when the
           incoming load on the network is far in excess of its
           capacity.  The overall useful throughput under load is the
           ultimate measure of the value of a solution.

           *Compliant*. DOIC provides information that nodes can use to
           reduce the impact of overload.



   REQ 4:  Diameter allows requests to be sent from either side of a
           connection, and either side of a connection may have need to
           provide its overload status.  The solution MUST allow each
           side of a connection to independently inform the other of its
           overload status.

           *Compliant*. DOIC AVPs can be included regardless of
           transaction "direction"



   REQ 5:  Diameter allows nodes to determine their peers via dynamic
           discovery or manual configuration.  The solution MUST work
           consistently without regard to how peers are determined.

           *Compliant*. DOIC contains no assumptions about how peers are
           discovered.  [Note: This may require further study]



   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require that this knowledge
           to be configured at each node.

           *Partially Compliant*. Most DOIC parameters are advertised
           using the DOIC capability announcement mechanism.  However,
           there are some situations where configuration is required.
           For example, a DOIC node detect the fact that a peer may not
           support DOIC when nodes on the other side of the non-
           supporting node do support DOIC without configuration.



D.2.  Performance

   REQ 7:  The solution and any associated default algorithm(s) MUST
           ensure that the system remains stable.  At some point after
           an overload condition has ended, the solution MUST enable
           capacity to stabilize and become equal to what it would be in
           the absence of an overload condition.  Note that this also
           requires that the solution MUST allow nodes to shed load
           without introducing non-converging oscillations during or
           after an overload condition.

           *Compliant*. The specification offers guidance that
           implementations should apply hysteresis when recovering from
           overload, and avoid sudden ramp ups in offered load when
           recovering.



   REQ 8:  Supporting nodes MUST be able to distinguish current overload
           information from stale information.

           *Partially Compliant*. DOIC overload reports are "soft
           state", that is they expire after an indicated period.  DOIC
           nodes may also send reports that end existing overload
           conditions.  DOIC requires reporting nodes to ensure that all
           relevant reacting nodes receive overload reports.

           However, since DOIC does not allow reports to send OLRs in
           watchdog messages, if an overload condition results in zero
           offered load, the reporting node cannot update the condition
           until the expiration of the original OLR.



   REQ 9:  The solution MUST function across fully loaded as well as
           quiescent transport connections.  This is partially derived
           from the requirement for stability in REQ 7.

           *Not Compliant*. DOIC does not allow OLRs to be sent over
           quiescent transport connections.  This is due to the fact
           that OLRs cannot be sent outside of the application to which
           they apply.



   REQ 10: Consumers of overload information MUST be able to determine
           when the overload condition improves or ends.

           *Partially Compliant*. (See response to previous two
           requirements.)



   REQ 11: The solution MUST be able to operate in networks of different
           sizes.

           *Compliant*. DOIC makes no assumptions about the size of the
           network.  DOIC can operate purely between clients and
           servers, or across agents.



   REQ 12: When a single network node fails, goes into overload, or
           suffers from reduced processing capacity, the solution MUST
           make it possible to limit the impact of the affected node on
           other nodes in the network.  This helps to prevent a small-
           scale failure from becoming a widespread outage.

           *Partially Compliant*. DOIC allows overload reports for an
           entire realm, where abated traffic will not be redirected
           towards another server.  But in situations where nodes choose
           to divert traffic to other nodes, DOIC offers no way of
           knowing whether the new recipients can handle the traffic if
           they have not already indicated overload.  This may be
           mitigated with the use of a future "load" extension, or with
           the use of proprietary dynamic load-balancing mechanisms.



   REQ 13: The solution MUST NOT introduce substantial additional work
           for a node in an overloaded state.  For example, a
           requirement for an overloaded node to send overload
           information every time it received a new request would
           introduce substantial work.

           *Not Compliant*. DOIC does in fact encourage an overloaded
           node to send an OLR in every response.  The working group
           that other mechanisms to ensure that every relevant node
           receives an OLR would create even more work.  [Note: This
           needs discussion.]



   REQ 14: Some scenarios that result in overload involve a rapid
           increase of traffic with little time between normal levels
           and levels that induce overload.  The solution SHOULD provide
           for rapid feedback when traffic levels increase.

           *Compliant*. The piggyback mechanism allows OLRs to be sent
           at the same rate as application traffic.



   REQ 15: The solution MUST NOT interfere with the congestion control
           mechanisms of underlying transport protocols.  For example, a
           solution that opened additional TCP connections when the
           network is congested would reduce the effectiveness of the
           underlying congestion control mechanisms.

           *Compliant*. DOIC does not require or recommend changes in
           the handling of transport protocols or connections.



D.3.  Heterogeneous Support for Solution

   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.

           *Partially Compliant*. DOIC works with most mixed-deployment
           scenarios.  However, it cannot work across a non-supporting
           proxy that modifies Origin-Host AVPs in answer messages.
           DOIC will have limited impact in networks where the nodes
           that perform server selections do not support the mechanism.



   REQ 17: In a mixed environment with nodes that support the solution
           and nodes that do not, the solution MUST NOT result in
           materially less useful throughput during overload as would
           have resulted if the solution were not present.  It SHOULD
           result in less severe overload in this environment.

           *Compliant*. In most mixed-support deployment, DOIC will
           offer at least some value, and will not make things worse.



   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.

           *Compliant*. DOIC provides mechanisms to abate load from non-
           supporting sources.  Furthermore, it recommends that
           reporting nodes will still need to be able to apply whatever
           protections they would ordinarily apply if DOIC were not in
           use.



   REQ 19: It MUST be possible to use the solution between nodes in
           different realms and in different administrative domains.

           *Partially Compliant*. DOIC allows sending OLRs across
           administrative domains, and potentially to nodes in other
           realms.  However, an OLR cannot indicate overload for realms
           other than the one in the Origin-Realm AVP of the containing
           answer.



   REQ 20: Any explicit overload indication MUST be clearly
           distinguishable from other errors reported via Diameter.

           *Compliant*. DOIC sends explicit overload indication in
           overload reports.  It does not depend on error result codes.
           [Note: I don't think the resuse of too-busy and unable-to-
           comply for throttled requests impacts this requirement.  Do
           others agree?]



   REQ 21: In cases where a network node fails, is so overloaded that it
           cannot process messages, or cannot communicate due to a
           network failure, it may not be able to provide explicit
           indications of the nature of the failure or its levels of
           overload.  The solution MUST result in at least as much
           useful throughput as would have resulted if the solution were
           not in place.

           *Compliant*. DOIC overload reports have the primary effect of
           suppressing message retries in overload conditions.  DOIC
           recommends that messages never be silently dropped if at all
           possible.



D.4.  Granular Control

   REQ 22: The solution MUST provide a way for a node to throttle the
           amount of traffic it receives from a peer node.  This
           throttling SHOULD be graded so that it can be applied
           gradually as offered load increases.  Overload is not a
           binary state; there may be degrees of overload.

           *Compliant*. The "loss" algorithm expresses a percentage
           reduction.



   REQ 23: The solution MUST provide sufficient information to enable a
           load-balancing node to divert messages that are rejected or
           otherwise throttled by an overloaded upstream node to other
           upstream nodes that are the most likely to have sufficient
           capacity to process them.

           *Not Compliant*. DOIC provides no built in mechanism to
           determine the best place to divert messages that would
           otherwise be throttled.  This can be accomplished with a
           future "load" extension, or with proprietary load balancing
           mechanisms.



   REQ 24: The solution MUST provide a mechanism for indicating load
           levels, even when not in an overload condition, to assist
           nodes in making decisions to prevent overload conditions from
           occurring.

           *Not Compliant*. "Load" information has been left for a
           future extension.



D.5.  Priority and Policy

   REQ 25: The base specification for the solution SHOULD offer general
           guidance on which message types might be desirable to send or
           process over others during times of overload, based on
           application-specific considerations.  For example, it may be
           more beneficial to process messages for existing sessions
           ahead of new sessions.  Some networks may have a requirement
           to give priority to requests associated with emergency
           sessions.  Any normative or otherwise detailed definition of
           the relative priorities of message types during an overload
           condition will be the responsibility of the application
           specification.

           *Compliant*. The specification offers guidance on how
           requests might be prioritized for different types of
           applications.



   REQ 26: The solution MUST NOT prevent a node from prioritizing
           requests based on any local policy, so that certain requests
           are given preferential treatment, given additional
           retransmission, not throttled, or processed ahead of others.

           *Compliant*. Nothing in the specification prevents
           application-specific, implementation-specific, or local
           policies.



D.6.  Security

   REQ 27: The solution MUST NOT provide new vulnerabilities to
           malicious attack or increase the severity of any existing
           vulnerabilities.  This includes vulnerabilities to DoS and
           DDoS attacks as well as replay and man-in-the-middle attacks.
           Note that the Diameter base specification [RFC6733] lacks
           end-to-end security and this must be considered (see the
           Security Considerations in [RFC7068]).  Note that this
           requirement was expressed at a high level so as to not
           preclude any particular solution.  Is is expected that the
           solution will address this in more detail.

           *Unknown*. [Needs further analysis.]



   REQ 28: The solution MUST NOT depend on being deployed in
           environments where all Diameter nodes are completely trusted.
           It SHOULD operate as effectively as possible in environments
           where other nodes are malicious; this includes preventing
           malicious nodes from obtaining more than a fair share of
           service.  Note that this does not imply any responsibility on
           the solution to detect, or take countermeasures against,
           malicious nodes.

           *Partially Compliant*. Since all Diameter security is
           currently at the transport layer, nodes must trust immediate
           peers to enforce trust policies.  However, there are
           situations where a DOIC node cannot determine if an immediate
           peer supports DOIC.  The authors recommend an expert security
           review.



   REQ 29: It MUST be possible for a supporting node to make
           authorization decisions about what information will be sent
           to peer nodes based on the identity of those nodes.  This
           allows a domain administrator who considers the load of their
           nodes to be sensitive information to restrict access to that
           information.  Of course, in such cases, there is no
           expectation that the solution itself will help prevent
           overload from that peer node.

           *Partially Compliant*. (See response to previous
           requirement.)



   REQ 30: The solution MUST NOT interfere with any Diameter-compliant
           method that a node may use to protect itself from overload
           from non-supporting nodes or from denial-of-service attacks.

           *Compliant*. The specification recommends that any such
           protection mechanism needed without DOIC should continue to
           be employed with DOIC.



D.7.  Flexibility and Extensibility

   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.

           *Partially Compliant*. All DOIC overload reports are scoped
           to the specific application and realm.  Inside that scope,
           overload can be reported at the specific server or whole
           realm scope.  As currently specified, DOIC cannot indicate
           local overload for an agent.  At the time of this writing,
           the DIME working group has plans to work on an agent-overload
           extension.

           DOIC allows new "scopes" through the use of extended report
           types.



   REQ 32: The solution MUST provide a method for extending the
           information communicated and the algorithms used for overload
           control.

           *Compliant*. DOIC allows new report types and abatement
           algorithms to be created.  These may be indicated using the
           OC-Supported-Features AVP.



   REQ 33: The solution MUST provide a default algorithm that is
           mandatory to implement.

           *Compliant*. The "loss" algorithm is mandatory to implement.



   REQ 34: The solution SHOULD provide a method for exchanging overload
           and load information between elements that are connected by
           intermediaries that do not support the solution.

           *Partially Compliant*. DOIC information can traverse non-
           supporting agents, as long as those agents do not modify
           certain AVPs. (e.g., Origin-Host)




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

--------------010601020906090602020407-- From nobody Mon Nov 3 13:26: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 585AC1A0392 for ; Mon, 3 Nov 2014 06:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.456 X-Spam-Level: *** X-Spam-Status: No, score=3.456 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=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 GTlL-wzvTu9b for ; Mon, 3 Nov 2014 06:35:37 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BE41A0382 for ; Mon, 3 Nov 2014 06:35:37 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63315 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XlIjH-00066j-97 for dime@ietf.org; Mon, 03 Nov 2014 06:35:36 -0800 Message-ID: <545792B6.8030502@usdonovans.com> Date: Mon, 03 Nov 2014 08:35:34 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------070206030601040508010203" 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/3y2ux_KBdznAPCz-GP67TsR0AHo X-Mailman-Approved-At: Mon, 03 Nov 2014 13:26:18 -0800 Subject: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 14:35:50 -0000 This is a multi-part message in MIME format. --------------070206030601040508010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I have done another end-to-end read of the DOIC specification, focusing on wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. Regards, Steve --------------070206030601040508010203 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed.
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Standards Track S. Donovan, Ed. Intended status: Standards Track S. Donovan, Ed.
Expires: April 30, 2015 B. Campbell Expires: April 25, 2015 B. Campbell
Oracle Oracle
L. Morand L. Morand
Orange Labs Orange Labs
October 27, 2014 October 22, 2014
Diameter Overload Indication Conveyance Diameter Overload Indication Conveyance
draft-ietf-dime-ovli-04.txt draft-ietf-dime-ovli-04.txt
Abstract Abstract
This specification documents a Diameter Overload Control (DOC) base This specification documents a Diameter Overload Control (DOC) base
solution and the dissemination of the overload report information. solution and the dissemination of the overload report information.
Requirements Requirements
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015. This Internet-Draft will expire on April 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 22 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 22
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 26
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 31
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 31
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Issues left for future specifications . . . . . . . 33 Appendix A. Issues left for future specifications . . . . . . . 33
A.1. Additional traffic abatement algorithms . . . . . . . . . 33 A.1. Additional traffic abatement algorithms . . . . . . . . . 34
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 34
A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 33 A.3. Requirements Conformance Analysis . . . . . . . . . . . . 34
A.4. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 34
Appendix B. Deployment Considerations . . . . . . . . . . . . . 34 Appendix B. Deployment Considerations . . . . . . . . . . . . . 34
Appendix C. Requirements Conformance Analysis . . . . . . . . . 34 Appendix C. Considerations for Applications Integrating the DOIC
Appendix D. Considerations for Applications Integrating the DOIC Solution . . . . . . . . . . . . . . . . . . . . . . 35
Solution . . . . . . . . . . . . . . . . . . . . . . 34 C.1. Application Classification . . . . . . . . . . . . . . . 35
D.1. Application Classification . . . . . . . . . . . . . . . 34 C.2. Application Type Overload Implications . . . . . . . . . 36
D.2. Application Type Overload Implications . . . . . . . . . 35 C.3. Request Transaction Classification . . . . . . . . . . . 37
D.3. Request Transaction Classification . . . . . . . . . . . 36 C.4. Request Type Overload Implications . . . . . . . . . . . 38
D.4. Request Type Overload Implications . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), referred to as Diameter Overload Indication Conveyance Control (DOC), referred to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
for the future specifications. See Appendix A for a list of for the future specifications. See Appendix A for a list of
extensions that are currently being considered. See Appendix C for extensions that are currently being considered. See Appendix A.3 for
an analysis of the conformance to the requirements specified in an analysis of the conformance to the requirements specified in
[RFC7068]. [RFC7068].
The solution defined in this specification addresses Diameter The solution defined in this specification addresses Diameter
overload control between Diameter nodes that support the DOIC overload control between Diameter nodes that support the DOIC
solution. Furthermore, the solution which is designed to apply to solution. Furthermore, the solution which is designed to apply to
existing and future Diameter applications, requires no changes to the existing and future Diameter applications, requires no changes to the
Diameter base protocol [RFC6733] and is deployable in environments Diameter base protocol [RFC6733] and is deployable in environments
where some Diameter nodes do not implement the Diameter overload where some Diameter nodes do not implement the Diameter overload
control solution defined in this specification. control solution defined in this specification.
skipping to change at page 4, line 35 skipping to change at page 4, line 35
AVP, or by some other local knowledge on the part of the reacting AVP, or by some other local knowledge on the part of the reacting
node. node.
Overload Control State (OCS) Overload Control State (OCS)
Reporting and reacting node internally maintained state describing Reporting and reacting node internally maintained state describing
occurrences of overload control. occurrences of overload control.
Overload Report (OLR) Overload Report (OLR)
Information sent by a reporting node indicating the start, Information sent by a reporting node indicating the start or
continuation or end of an occurrence of overload control. continuation of an occurrence of overload control.
Reacting Node Reacting Node
A Diameter node that acts upon an overload report. A Diameter node that acts upon an overload report.
Realm-Routed Request Realm-Routed Request
The set of requests that a reacting node does not know the host The set of requests that a reacting node does not know the host
that will service the request. that will service the request.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
solution. This capability is referred to as DOIC Capability solution. This capability is referred to as DOIC Capability
Announcement (DCA) and is separate from Diameter Capability Exchange. Announcement (DCA) and is separate from Diameter Capability Exchange.
The DCA solution uses the OC-Supported-Features AVPs to indicate the The DCA solution uses the OC-Supported-Features AVPs to indicate the
Diameter overload features supported. Diameter overload features supported.
The first node in the path of a Diameter request that supports the The first node in the path of a Diameter request that supports the
DOIC solution inserts the OC-Supported-Feature AVP in the request DOIC solution inserts the OC-Supported-Feature AVP in the request
message. This includes an indication that it supports the loss message. This includes an indication that it supports the loss
overload abatement algorithm defined in this specification (see overload abatement algorithm defined in this specification (see
Section 5). This ensures that there is at least one commonly Section 5). This insures that there is at least one commonly
supported overload abatement algorithm between the reporting node and supported overload abatement algorithm between the reporting node and
the reacting nodes in the path of the request. the reacting nodes in the path of the request.
DOIC must support deployments where Diameter Clients and/or DOIC must support deployments where Diameter Clients and/or
Diameter Servers do not support the DOIC solution. In this Diameter Servers do not support the DOIC solution. In this
scenario, it is assumed that Diameter Agents that support the DOIC scenario, it is assumed that Diameter Agents that support the DOIC
solution will handle overload abatement for the non supporting solution will handle overload abatement for the non supporting
Diameter nodes. In this case the DOIC agent will insert the OC- Diameter nodes. In this case the DOIC agent will insert the OC-
Supporting-Features AVP in requests that do not already contain Supporting-Features AVP in requests that do not already contain
one, telling the reporting node that there is a DOIC node that one, telling the reporting node that there is a DOIC node that
skipping to change at page 9, line 4 skipping to change at page 9, line 4
Reacting nodes can use the indicated overload abatement algorithm to Reacting nodes can use the indicated overload abatement algorithm to
prepare for possible overload reports and must use the indicated prepare for possible overload reports and must use the indicated
overload abatement algorithm if traffic reduction is actually overload abatement algorithm if traffic reduction is actually
requested. requested.
Note that the loss algorithm defined in this document is a Note that the loss algorithm defined in this document is a
stateless abatement algorithm. As a result it does not require stateless abatement algorithm. As a result it does not require
any actions by reacting nodes prior to the receipt of an overload any actions by reacting nodes prior to the receipt of an overload
report. Stateful abatement algorithms that base the abatement report. Stateful abatement algorithms that base the abatement
logic on a history of request messages sent might require reacting logic on a history of request messages sent might require reacting
nodes to maintain state to ensure that overload reports can be nodes to maintain state to insure that overload reports can be
properly handled. properly handled.
The individual features supported by the DOIC nodes are indicated in The individual features supported by the DOIC nodes are indicated in
the OC-Feature-Vector AVP. Any semantics associated with the the OC-Feature-Vector AVP. Any semantics associated with the
features will be defined in extension specifications that introduce features will be defined in extension specifications that introduce
the features. the features.
The DCA mechanism must also support the scenario where the set of The DCA mechanism must also support the scenario where the set of
features supported by the sender of a request and by agents in the features supported by the sender of a request and by agents in the
path of a request differ. In this case, the agent updates the OC- path of a request differ. In this case, the agent updates the OC-
skipping to change at page 11, line 10 skipping to change at page 11, line 10
The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes
to communicate supported features. The specific features supported to communicate supported features. The specific features supported
by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC
extensions must define new values for the OC-Feature-Vector AVP. extensions must define new values for the OC-Feature-Vector AVP.
DOIC extensions also have the ability to add new AVPs to the OC- DOIC extensions also have the ability to add new AVPs to the OC-
Supported-Features AVP, if additional information about the new Supported-Features AVP, if additional information about the new
feature is required. feature is required.
Reporting nodes use the OC-OLR AVP to communicate overload Reporting nodes use the OC-OLR AVP to communicate overload
occurrences. This AVP can also be extended to add new AVPs allowing occurrances. This AVP can also be extended to add new AVPs allowing
a reporting nodes to communicate additional information about a reporting nodes to communicate additional information about
handling an overload condition. handling an overload condition.
If necessary, new extensions can also define new top-level AVPs. It If necessary, new extensions can also define new top-level AVPs. It
is, however, recommended that DOIC extensions use the OC-Supported- is, however, recommended that DOIC extensions use the OC-Supported-
Features and OC-OLR to carry all DOIC related AVPs. Features and OC-OLR to carry all DOIC related AVPs.
3.5. Simplified Example Architecture 3.5. Simplified Example Architecture
Figure 1 illustrates the simplified architecture for Diameter Figure 1 illustrates the simplified architecture for Diameter
skipping to change at page 13, line 29 skipping to change at page 13, line 29
accordingly for the subsequent answer messages it initiates. accordingly for the subsequent answer messages it initiates.
The reporting node MUST indicate support for one and only one The reporting node MUST indicate support for one and only one
abatement algorithm in the OC-Feature-Vector AVP. The abatement abatement algorithm in the OC-Feature-Vector AVP. The abatement
algorithm included MUST be from the set of abatement algorithms algorithm included MUST be from the set of abatement algorithms
contained in the request message's OC-Supported-Features AVP. The contained in the request message's OC-Supported-Features AVP. The
abatement algorithm included MUST indicate the abatement algorithm abatement algorithm included MUST indicate the abatement algorithm
the reporting node wants the reacting node to use when the reporting the reporting node wants the reacting node to use when the reporting
node enters an overload condition. node enters an overload condition.
For an ongoing overload state, a reacting node MUST keep the The reporting node MUST NOT change the selected algorithm during a
algorithm that was selected by the reporting node in further requests period of time that it is in an overload condition and, as a result,
towards the reporting node. The reporting node SHOULD NOT change the is sending OC-OLR AVPs in answer messages.
selected algorithm during a period of time that it is in an overload
condition and, as a result, is sending OC-OLR AVPs in answer
messages.
The reporting node SHOULD indicate support for other DOIC features The reporting node SHOULD indicate support for other DOIC features
defined in extension drafts that it supports and that apply to the defined in extension drafts that it supports and that apply to the
transaction. transaction.
Note that not all DOIC features will apply to all Diameter Note that not all DOIC features will apply to all Diameter
applications or deployment scenarios. The features included in applications or deployment scenarios. The features included in
the OC-Feature-Vector AVP are based on local reporting node the OC-Feature-Vector AVP are based on local reporting node
policy. policy.
skipping to change at page 14, line 13 skipping to change at page 14, line 10
it to reflect a mixed set of DOIC features. it to reflect a mixed set of DOIC features.
An agent MAY modify the OC-Supported-Features AVP carried in answer An agent MAY modify the OC-Supported-Features AVP carried in answer
messages. messages.
For instance, if the agent supports a superset of the features For instance, if the agent supports a superset of the features
reported by the reacting node then the agent might choose, based reported by the reacting node then the agent might choose, based
on local policy, to advertise that superset of features to the on local policy, to advertise that superset of features to the
reporting node. reporting node.
If the agent modifies the OC-Supported-Features AVP sent to the If the agent modifies the OC-Supported-Features header sent to the
reporting node then it might also need to modify the OC-Supported- reporting node then it might also need to modify the OC-Supported-
Features AVP sent to a reacting node in the subsequent answer Features AVP sent to a reacting node in the subsequent answer
message, as it cannot send an indication of support for features message, as it cannot send an indication of support for features
that are not supported by the reacting node. that are not supported by the reacting node.
Editor's note: There is an open issue on the wording around agent
behavior in this case that needs to be resolved prior to finishing
this document.
4.2. Overload Report Processing 4.2. Overload Report Processing
4.2.1. Overload Control State 4.2.1. Overload Control State
Both reacting and reporting nodes maintain Overload Control State Both reacting and reporting nodes maintain Overload Control State
(OCS) for active overload conditions. (OCS) for active overload conditions.
4.2.1.1. Overload Control State for Reacting Nodes 4.2.1.1. Overload Control State for Reacting Nodes
A reacting node SHOULD maintain the following OCS per supported A reacting node SHOULD maintain the following OCS per supported
Diameter application: Diameter application:
o A host-type OCS entry for each Destination-Host to which it sends o A host-type OCS entry for each Destination-Host to which it sends
host-type requests and host-type requests and
o A realm-type OCS entry for each Destination-Realm to which it o A realm-type OCS entry for each Destination-Realm to which it
sends realm-type requests. sends realm-type requests.
A host-type OCS entry is identified by the pair of Application-Id and A host-type OCS entry MAY be identified by the pair of Application-Id
Host-Id. and Host-Id.
A realm-type OCS entry is identified by the pair of Application-Id A realm-type OCS entry MAY be identified by the pair of Application-
and Realm-Id. Id and Realm-Id.
The host-type and realm-type OCS entries MAY include the following The host-type and realm-type OCS entries MAY include the following
information (the actual information stored is an implementation information (the actual information stored is an implementation
decision): decision):
o Sequence number (as received in OC-OLR) o Sequence number (as received in OC-OLR)
o Time of expiry (derived from OC-Validity-Duration AVP received in o Time of expiry (derived from OC-Validity-Duration AVP received in
the OC-OLR AVP and time of reception of the message carrying OC- the OC-OLR AVP and time of reception of the message carrying OC-
OLR AVP) OLR AVP)
o Selected Abatement Algorithm (as received in OC-Supported-Features o Selected Abatement Algorithm (as received in OC-Supported-Features
AVP) AVP)
o Abatement Algorithm specific input data (as received within the o Abatement Algorithm specific input data (as received within the
OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss
abatement algorithm) abatement algorithm)
skipping to change at page 15, line 18 skipping to change at page 15, line 12
o Selected Abatement Algorithm (as received in OC-Supported-Features o Selected Abatement Algorithm (as received in OC-Supported-Features
AVP) AVP)
o Abatement Algorithm specific input data (as received within the o Abatement Algorithm specific input data (as received within the
OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss
abatement algorithm) abatement algorithm)
4.2.1.2. Overload Control State for Reporting Nodes 4.2.1.2. Overload Control State for Reporting Nodes
A reporting node SHOULD maintain OCS entries per supported Diameter A reporting node SHOULD maintain OCS entries per supported Diameter
application, per supported (and eventually selected) Abatement application and per supported (and eventually selected) Abatement
Algorithm and per report-type. Algorithm.
An OCS entry is identified by the pair of Application-Id and An OCS entry MAY be identified by the pair of Application-Id and
Abatement Algorithm. Abatement Algorithm.
The OCS entry for a given pair of Application and Abatement Algorithm The OCS entry for a given pair of Application and Abatement Algorithm
MAY include the information (the actual information stored is an MAY include the information (the actual information stored is an
implementation decision): implementation decision):
o Report type o Report type
o Sequence number o Sequence number
o Validity Duration o Validity Duration
o Expiration Time o Expiration Time
o Algorithm specific input data (for example, the Reduction o Algorithm specific input data (for example, the Reduction
Percentage for the Loss Abatement Algorithm) Percentage for the Loss Abatement Algorithm)
4.2.1.3. Reacting Node Maintenance of Overload Control State 4.2.1.3. Reacting Node Maintainence of Overload Control State
When a reacting node receives an OC-OLR AVP, it MUST determine if it When a reacting node receives an OC-OLR AVP, it MUST determine if it
is for an existing or new overload condition. is for an existing or new overload condition.
For the remainder of this section the term OLR referres to the For the remainder of this section the term OLR referres to the
combination of the contents of the received OC-OLR AVP and the combination of the contents of the received OC-OLR AVP and the
abatement algorithm indicated in the received OC-Supported- abatement algorithm indicated in the received OC-Supported-
Features AVP. Features AVP.
The OLR is for an existing overload condition if the reacting node The OLR is for an existing overload condition if the reacting node
skipping to change at page 16, line 31 skipping to change at page 16, line 25
MUST silently ignore the received OLR. The matching OCS MUST NOT be MUST silently ignore the received OLR. The matching OCS MUST NOT be
updated in this case. updated in this case.
If the received OLR is for a new overload condition then the reacting If the received OLR is for a new overload condition then the reacting
node MUST generate a new OCS entry for the overload condition. node MUST generate a new OCS entry for the overload condition.
For a host report-type this means it creates on OCS entry with the For a host report-type this means it creates on OCS entry with the
app-id of the application-id in the received message and host-id of app-id of the application-id in the received message and host-id of
the Origin-Host in the received message. the Origin-Host in the received message.
Note: This solution assumes that the Origin-Host AVP in the answer
message included by the reporting node is not changed along the
path to the reacting node.
For a realm report-type this means it creates on OCS entry with the For a realm report-type this means it creates on OCS entry with the
app-id of the application-id in the received message and realm-id of app-id of the application-id in the received message and realm-id of
the Origin-Realm in the received message. the Origin-Realm in the received message.
If the received OLR contains a validity duration of zero ("0") then If the received OLR contains a validity duration of zero ("0") then
the reacting node MUST update the OCS entry as being expired. the reacting node MUST update the OCS entry as being expired.
Note that it is not necessarily appropriate to delete the OCS Note that it is not necessarily appropriate to delete the OCS
entry, as there is recommended behavior that the reacting node entry, as there is recommended behavior that the reacting node
slowly returns to full traffic when ending an overload abatement slowly returns to full traffic when ending an overload abatement
skipping to change at page 17, line 15 skipping to change at page 17, line 5
4.2.1.4. Reporting Node Maintenance of Overload Control State 4.2.1.4. Reporting Node Maintenance of Overload Control State
A reporting node SHOULD create a new OCS entry when entering an A reporting node SHOULD create a new OCS entry when entering an
overload condition. overload condition.
If the reporting node knows through absence of the OC-Supported- If the reporting node knows through absence of the OC-Supported-
Features AVP in received messages that there are no reacting nodes Features AVP in received messages that there are no reacting nodes
supporting DOIC then the reporting node can choose to not create supporting DOIC then the reporting node can choose to not create
OCS entries. OCS entries.
When generating a new OCS entry the sequence number MAY be set to any When generating a new OCS entry the sequence nubmer MAY be set to any
value if there is no unexpired overload report for previous overload value if there is no unexpired overload report for previous overload
conditions sent to any reacting node for the same application and conditions at any reacting node.
report-type.
When generating sequence numbers for new overload conditions, the new When generating sequence numbers for new overload conditions, the new
sequence number MUST be greater than any sequence number in an active sequence number MUST be greater than any sequence number in an active
(unexpired) overload report previously sent by the reporting node. (unexpired) overload report previously sent by the reporting node.
This property MUST hold over a reboot of the reporting node. This property MUST hold over a reboot of the reporting node.
The reporting node MUST update an OCS entry when it needs to adjust The reporting node MUST update an OCS entry when it needs to adjust
the validity duration of the overload condition at reacting nodes. the validity duration of the overload contition at reacting nodes.
For instance, if the reporting node wishes to instruct reacting For instance, if the reporting node wishes to instruct reacting
nodes to continue overload abatement for a longer period of time nodes to continue overload abatement for a longer period of time
that originally communicated. This also applies if the reporting that originally communicated. This also applies if the reporting
node wishes to shorten the period of time that overload abatement node wishes to shorten the period of time that overload abatement
is to continue. is to continue.
A reporting node MUST NOT update the abatement algorithm in an active A reporting node MUST NOT update the abatement algorithm in an active
OCS entry. OCS entry.
A reporting node MUST update an OCS entry when it wishes to adjust A reporting node MUST update an OCS entry when it wishes to adjust
any abatement algorithm specific parameters, including the reduction the any abatement algorithm specific parameters, including the
percentage used for the Loss abatement algorithm. reduction percentage used for the Loss abatement algorithm.
For instance, if the reporting node wishes to change the reduction For instance, if the reporting node wishes to change the reduction
percentage either higher, if the overload condition has worsened, percentage either higher, if the overload condition has worsened,
or lower, if the overload condition has improved, then the or lower, if the overload condition has improved, then the
reporting node would update the appropriate OCS entry. reporting node would update the appropriate OCS entry.
The reporting node MUST update the sequence number associated with The reporting node MUST update the sequence number associated with
the OCS entry anytime the contents of the OCS entry are changed. the OCS entry anytime the contents of the OCS entry are changed.
This will result in a new sequence number being sent to reacting This will result in a new sequence number being sent to reacting
nodes, instructing the reacting nodes to process the OC-OLR AVP. nodes, instructing the reacting nodes to process the OC-OLR AVP.
A reporting node SHOULD update an OCS entry with a validity duration A reporting node SHOULD update an OCS entry with a validity duration
of zero ("0") when the overload condition ends. of zero ("0") when the overload condition ends.
If the reporting node knows that the OCS entries in the reacting If the reporting node knows that the OCS entries in the reacting
nodes are near expiration then the reporting node can decide to nodes are near expiration then the reporting node can decide
delete the OCS entry. delete the OCS entry.
The reporting node MUST keep an OCS entry with a validity duration of The reporting node MUST keep an OCS entry with a validity duration of
zero ("0") for a period of time long enough to ensure that any non- zero ("0") for a period of time long enough to ensure that any
expired reacting node's OCS entry created as a result of the overload reacting node OCS entry created as a result of the overload condition
condition in the reporting node is deleted. in the reporting node exists.
This period of time can be determined by calculating the time the
last overload report for the overload condition was sent plus the
validity duration included in that overload report.
4.2.2. Reacting Node Behavior 4.2.2. Reacting Node Behavior
When a reacting node sends a request it MUST determine if that When a reacting node sends a request it MUST determine if that
request matches an active OCS. request matches an active OCS.
If the request matches and active OCS then the reacting node MUST If the request matches and active OCS then the reacting number MUST
apply abatement treatment on the request. The abatement treatment apply abatement treatment on the request. The abatement treatment
applied depends on the abatement algorithm stored in the OCS. applied depends on the abatement algorithm stored in the OCS.
For the Loss abatement algorithm defined in this specification, see For the Loss abatement algorithm defined in this specification, see
Section 5 for the abatement logic applied. Section 5 for the abatement logic applied.
If the abatement treatment results in throttling of the request and If the abatement treatment results in throttling of the request and
if the reacting node is an agent then the agent MUST send an if the reacting node is an agent then the agent MUST send an
appropriate error as defined in section Section 7. appropriate error as defined in section Section 7.
skipping to change at page 18, line 52 skipping to change at page 18, line 47
contain the OC-Supported-Features AVP and that match the active OCS contain the OC-Supported-Features AVP and that match the active OCS
entry. entry.
A request matches if the application-id in the request matches the A request matches if the application-id in the request matches the
application-id in any active OCS entry and if the report-type in application-id in any active OCS entry and if the report-type in
the OCS entry matches a report-type supported by the reporting the OCS entry matches a report-type supported by the reporting
node as indicated in the OC-Supported-Features AVP. node as indicated in the OC-Supported-Features AVP.
The contents of the OC-OLR AVP MUST contain all information necessary The contents of the OC-OLR AVP MUST contain all information necessary
for the abatement algorithm indicated in the OC-Supported-Features for the abatement algorithm indicated in the OC-Supported-Features
AVP that is also included in the answer message. message that is also included in the answer message.
A reporting node MAY choose to not resend an overload report to a A reporting node MAY choose to not resend an overload report to a
reacting node if it can guarantee that this overload report is reacting node if it can guarantee that this overload report is
already active in the reacting node. already active in the reacting node.
Note - In some cases (e.g. when there are one or more agents in Note - In some cases (e.g. when there are one or more agents in
the path between reporting and reacting nodes, or when overload the path between reporting and reacting nodes, or when overload
reports are discarded by reacting nodes) the reporting node may reports are discarded by reacting nodes) the reporting node may
not be able to guarantee that the reacting node has received the not be able to guarantee that the reacting node has received the
report. report.
A reporting node MUST NOT send overload reports of a type that has A reporting node MUST NOT send overload reports of a type that has
not been advertised as supported by the reacting node. not been advertized as supported by the reacting node.
Note that a reacting node advertises support for the host and Note that a reacting node advertises support for the host and
realm report types by including the OC-Supported-Features AVP in realm report types by including the OC-Supported-Features AVP in
the request. Support for other report types must be explicitly the request. Support for other report types must be explicitly
indicated by new feature bits in the OC-Feature-Vector AVP. indicated by new feature bits in the OC-Feature-Vector AVP.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD ensure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
All OLRs sent have an expiration time calculated by adding the All OLRs sent have an expiration time calculated by adding the
validity-duration contained in the OLR to the time the message was validity-duration contained in the OLR to the time the message was
sent. Transit time for the OLR can be safely ignored. The sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload condition have expiration time for all OLRs sent for that overload contition have
expired. expired.
When a reporting node sends an OLR, it effectively delegates any When a reporting node sends an OLR, it effectively delegates any
necessary throttling to downstream nodes. Therefore, the reporting necessary throttling to downstream nodes. Therefore, the reporting
node SHOULD NOT apply throttling to the set of messages to which the node SHOULD NOT apply throttling to the set of messages to which the
OLR applies. That is, the same candidate set of messages SHOULD NOT OLR applies. That is, the same candidate set of messages SHOULD NOT
be throttled multiple times. be throttled multiple times.
However, when the reporting node sends and OLR downstream, it MAY However, when the reporting node sends and OLR downstream, it MAY
still be responsible to apply other abatement methods such as still be responsible to apply other abatement methods, such as
diversion. The reporting node might also need to throttle requests diversion, or request throttling requests for other reasons. For
for reasons other then overload. For example, an agent or server example, an agent or server might have a configured rate limit for
might have a configured rate limit for each client, and throttle each client, and throttle requests that exceed that limit, even if
requests that exceed that limit, even if such requests had already such requests had already been candidates for throttling by
been candidates for throttling by downstream nodes. downstream nodes.
This document assumes that there is a single source for realm-reports This document assumes that there is a single source for realm-reports
for a given realm, or that if multiple nodes can send realm reports, for a given realm, or that if multiple nodes can send realm reports,
that each such node has full knowledge of the overload state of the that each such node has full knowledge of the overload state of the
entire realm. A reacting node cannot distinguish between receiving entire realm. A reacting node cannot distinguish between receiving
realm-reports from a single node, or from multiple nodes. realm-reports from a single node, or from multiple nodes.
If multiple such nodes exist, they MUST ensure that realm-reports are
kept in sync. This includes synchronizing the sequence numbers as
well as the reported overload state. The method of doing so is up to
the implementation. One way to keep the sequence numbers in sync is
to generate the sequence numbers based on system time.
Editor's Note: There is not yet consensus on the above two Editor's Note: There is not yet consensus on the above two
paragraphs. Two alternatives are under consideration -- paragraphs.
synchronization of sequence numbers and attribution of reports.
If no consensus is reached then it will be left to be addressed as
an extension.
4.3. Protocol Extensibility 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality. abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature. support for the new feature.
The extension MAY define new AVPs for use in DOIC Capability The extension MAY define new AVPs for use in DOIC Capability
Announcement and for use in DOIC Overload reporting. These new AVPs Announcement and for use in DOIC Overload reporting. These new AVP
SHOULD be defined to be extensions to the OC-Supported-Features and SHOULD be defined to be extensions to the OC-Supported-Features and
OC-OLR AVPs defined in this document. OC-OLR AVPs defined in this document.
It should be noted that [RFC6733] defined Grouped AVP extension It should be noted that [RFC6733] defined Grouped AVP extension
mechanisms apply. This allows, for example, defining a new feature mechanisms apply. This allows, for example, defining a new feature
that is mandatory to be understood even when piggybacked on an that is mandatory to be understood even when piggybacked on an
existing application. existing applications.
The handling of feature bits in the OC-Feature-Vector AVP that are The handling of feature bits in the OC-Feature-Vector AVP that are
not associated with overload abatement algorithms MUST be specified not associated with overload abatement algorithms MUST be specified
by the extensions that define the features. by the extensions that define the features.
When defining new report type values, the corresponding specification When defining new report type values, the corresponding specification
MUST define the semantics of the new report types and how they affect MUST define the semantics of the new report types and how they affect
the OC-OLR AVP handling. The specification MUST also reserve a the OC-OLR AVP handling. The specification MUST also reserve a
corresponding new feature bit in the OC-Feature-Vector AVP. corresponding new feature bit in the OC-Feature-Vector AVP.
skipping to change at page 23, line 30 skipping to change at page 23, line 30
condition thrashing where an immediate transition from 100% condition thrashing where an immediate transition from 100%
reduction to 0% reduction results in the reporting node moving reduction to 0% reduction results in the reporting node moving
quickly back into an overload condition. quickly back into an overload condition.
6. Attribute Value Pairs 6. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) defined in this
document. document.
When added to existing commands, both OC-Feature-Vector and OC-OLR
AVPs SHOULD have the M-bit flag cleared to avoid backward
compatibility issues.
A new application specification can incorporate the overload control A new application specification can incorporate the overload control
mechanism specified in this document by making it mandatory to mechanism specified in this document by making it mandatory to
implement for the application and referencing this specification implement for the application and referencing this specification
normatively. It is the responsibility of the Diameter application normatively. In such a case, the rules for handling of the M-bit
designers to define how overload control mechanisms works on that must follow the guidance in [RFC6733]. It is the responsibility of
application. the Diameter application designers to define how overload control
mechanisms works on that application.
6.1. OC-Supported-Features AVP 6.1. OC-Supported-Features AVP
The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and
serves two purposes. First, it announces a node's support for the serves two purposes. First, it announces a node's support for the
DOIC solution in general. Second, it contains the description of the DOIC solution in general. Second, it contains the description of the
supported DOIC features of the sending node. The OC-Supported- supported DOIC features of the sending node. The OC-Supported-
Features AVP MUST be included in every Diameter request message a Features AVP MUST be included in every Diameter message a DOIC
DOIC supporting node sends. supporting node sends.
OC-Supported-Features ::= < AVP Header: TBD1 > OC-Supported-Features ::= < AVP Header: TBD1 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
* [ AVP ] * [ AVP ]
The OC-Feature-Vector sub-AVP is used to announce the DOIC features The OC-Feature-Vector sub-AVP is used to announce the DOIC features
supported by the DOIC node, in the form of a flag bits field in which supported by the DOIC node, in the form of a flag bits field in which
each bit announces one feature or capability supported by the node each bit announces one feature or capability supported by the node
(see Section 6.2). The absence of the OC-Feature-Vector AVP (see Section 6.2). The absence of the OC-Feature-Vector AVP
indicates that only the default traffic abatement algorithm described indicates that only the default traffic abatement algorithm described
skipping to change at page 25, line 19 skipping to change at page 25, line 24
Section 4.2. Section 4.2.
From the functionality point of view, the OC-Sequence-Number AVP MUST From the functionality point of view, the OC-Sequence-Number AVP MUST
be used as a non-volatile increasing counter for a sequence of be used as a non-volatile increasing counter for a sequence of
overload reports between two DOIC nodes for the same overload overload reports between two DOIC nodes for the same overload
occurrence. The sequence number is only required to be unique occurrence. The sequence number is only required to be unique
between two DOIC nodes. Sequence numbers are treated in a uni- between two DOIC nodes. Sequence numbers are treated in a uni-
directional manner, i.e. two sequence numbers on each direction directional manner, i.e. two sequence numbers on each direction
between two DOIC nodes are not related or correlated. between two DOIC nodes are not related or correlated.
When generating sequence numbers, the new sequence number MUST be
greater than any sequence number in an active, unexpired, overload
report previously sent by the reporting node. This property MUST
hold over a reboot of the reporting node.
6.5. OC-Validity-Duration AVP 6.5. OC-Validity-Duration AVP
The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
and indicates in milliseconds the validity time of the overload and indicates in seconds the validity time of the overload report.
report. The number of milliseconds is measured after reception of The number of seconds is measured after reception of the first OC-OLR
the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. AVP with a given value of OC-Sequence-Number AVP. The default value
The default value for the OC-Validity-Duration AVP is 5000 (i.e., 5 for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the
seconds). When the OC-Validity-Duration AVP is not present in the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the
OC-OLR AVP, the default value applies. Validity duration with values default value applies. Validity duration with values above 86400
above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration (i.e.; 24 hours) MUST NOT be used. Invalid duration values are
values are treated as if the OC-Validity-Duration AVP were not treated as if the OC-Validity-Duration AVP were not present and
present and result in the default value being used. result in the default value being used.
Editor's note: There is an open discussion on whether to have an
upper limit on the OC-Validity-Duration value, beyond that which can
be indicated by an Unsigned32.
A timeout of the overload report has specific concerns that need to A timeout of the overload report has specific concerns that need to
be taken into account by the DOIC node acting on the earlier received be taken into account by the DOIC node acting on the earlier received
overload report(s). Section 6.7 discusses the impacts of timeout in overload report(s). Section 6.7 discusses the impacts of timeout in
the scope of the traffic abatement algorithms. the scope of the traffic abatement algorithms.
When a reporting node has recovered from overload, it SHOULD
invalidate any existing overload reports in a timely matter. This
can be achieved by sending an updated overload report (meaning the
OLR contains a new sequence number) with the OC-Validity-Duration AVP
value set to zero ("0"). If the overload report is about to expire
naturally, the reporting node MAY choose to simply let it do so.
A reacting node MUST invalidate and remove an overload report that
expires without an explicit overload report containing an OC-
Validity-Duration value set to zero ("0").
6.6. OC-Report-Type AVP 6.6. OC-Report-Type AVP
The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The
value of the AVP describes what the overload report concerns. The value of the AVP describes what the overload report concerns. The
following values are initially defined: following values are initially defined:
0 A host report. The overload treatment should apply to requests 0 A host report. The overload treatment should apply to requests
for which all of the following conditions are true: for which all of the following conditions are true:
Either the Destination-Host AVP is present in the request and its Either the Destination-Host AVP is present in the request and its
value matches the value of the Origin-Host AVP of the received value matches the value of the Origin-Host AVP of the received
message that contained the OC-OLR AVP; or the Destination-Host is message that contained the OC-OLR AVP; or the Destination-Host is
not present in the request but the value of the peer identity not present in the request but the value of peer identity
associated with the connection used to send the request matches associated with the connection used to send the request matches
the value of the Origin-Host AVP of the received message that the value of the Origin-Host AVP of the received message that
contained the OC-OLR AVP. contained the OC-OLR AVP.
The value of the Destination-Realm AVP in the request matches the The value of the Destination-Realm AVP in the request matches the
value of the Origin-Realm AVP of the received message that value of the Origin-Realm AVP of the received message that
contained the OC-OLR AVP. contained the OC-OLR AVP.
The value of the Application-ID in the Diameter Header of the The value of the Application-ID in the Diameter Header of the
request matches the value of the Application-ID of the Diameter request matches the value of the Application-ID of the Diameter
Header of the received message that contained the OC-OLR AVP. Header of the received message that contained the OC-OLR AVP.
1 A realm report. The overload treatment should apply to requests 1 A realm report. The overload treatment should apply to requests
for which all of the following conditions are true: for which all of the following conditions are true:
The Destination-Host AVP is absent in the requestand the value of The Destination-Host AVP is absent in the request.
the peer identity associated with the connection used to send the
request does not match a server that could serve the request.
The value of the Destination-Realm AVP in the request matches the The value of the Destination-Realm AVP in the request matches the
value of the Origin-Realm AVP of the received message that value of the Origin-Realm AVP of the received message that
contained the OC-OLR AVP. contained the OC-OLR AVP.
The value of the Application-ID in the Diameter Header of the The value of the Application-ID in the Diameter Header of the
request matches the value of the Application-ID of the Diameter request matches the value of the Application-ID of the Diameter
Header of the received message that contained the OC-OLR AVP. Header of the received message that contained the OC-OLR AVP.
The OC-Report-Type AVP is envisioned to be useful for situations The OC-Report-Type AVP is envisioned to be useful for situations
skipping to change at page 27, line 48 skipping to change at page 28, line 17
command within that application that includes the AVP. command within that application that includes the AVP.
The Diameter overload control AVPs SHOULD always be sent with the The Diameter overload control AVPs SHOULD always be sent with the
M-bit cleared when used within existing Diameter applications to M-bit cleared when used within existing Diameter applications to
avoid backward compatibility issues. Otherwise, when reused in newly avoid backward compatibility issues. Otherwise, when reused in newly
defined Diameter applications, the DOC related AVPs SHOULD have the defined Diameter applications, the DOC related AVPs SHOULD have the
M-bit set. M-bit set.
7. Error Response Codes 7. Error Response Codes
When a DOIC node rejects a Diameter request due to overload, the DOIC When a DOIC node rejects a Diameter request due to throttling, the
node MUST select an appropriate error response code. This DOIC node MUST select an appropriate error response code. This
determination is made based on the probability of the request determination is made based on the probability of the request
succeeding if retried on a different path. succeeding if retried on a different path.
A reporting node rejecting a Diameter request due to an overload The DIAMETER_TOO_BUSY response code SHOULD be used when the request
condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can is likely to succeed on a different path.
assume that the same request may succeed on a different path.
If a reporting node knows or assumes that the same request will not
succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response
SHOULD be used. Retrying would consume valuable resources during an
occurrence of overload.
For instance, if the request arrived at the reporting node without For instance, if the request arrived at the reporting node without
a Destination-Host AVP then the reporting node might determine a Destination-Host AVP then the reporting node might determine
that there is an alternative Diameter node that could successfully that there is an alternative Diameter node that could successfully
process the request and that retrying the transaction would not process the request and that retrying the transaction would not
negatively impact the reporting node. DIAMETER_TOO_BUSY would be negatively impact the reporting node.
sent in this case.
The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to
indicate that the request should not be retried. This is used when
the request is not likely to succeed on a different path and retrying
would consume valuable resources during an occurance of overload.
For instance, if the request arrived at the reporting node with a For instance, if the request arrived at the reporting node with a
Destination-Host AVP populated with its own Diameter identity then Destination-Host AVP populated with its own Diameter identity then
the reporting node can assume that retrying the request would the reporting node can assume that retrying the request would
result in it coming to the same reporting node. result in it coming to the same reporting node.
DIAMETER_UNABLE_TO_COMPLY would be sent in this case.
A second example is when an agent that supports the DOIC solution A second example is when an agent that supports the DOIC solution
is performing the role of a reacting node for a non supporting is preforming the role of a reacting node for a non supporting
client. Requests that are rejected as a result of DOIC throttling client. Requests that are rejected as a result of DOIC throttling
by the agent in this scenario would generally be rejected with a in this scenario would generally be rejected with a
DIAMETER_UNABLE_TO_COMPLY response code. DIAMETER_UNABLE_TO_COMPLY response code.
8. IANA Considerations 8. IANA Considerations
8.1. AVP codes 8.1. AVP codes
New AVPs defined by this specification are listed in Section 6. All New AVPs defined by this specification are listed in Section 6. All
AVP codes allocated from the 'Authentication, Authorization, and AVP codes allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry. Accounting (AAA) Parameters' AVP Codes registry.
8.2. New registries 8.2. New registries
Two new registries are needed under the 'Authentication, Three new registries are needed under the 'Authentication,
Authorization, and Accounting (AAA) Parameters' registry. Authorization, and Accounting (AAA) Parameters' registry.
Section 6.2 defines a new "Overload Control Feature Vector" registry Section 6.2 defines a new "Overload Control Feature Vector" registry
including the initial assignments. New values can be added into the including the initial assignments. New values can be added into the
registry using the Specification Required policy [RFC5226]. See registry using the Specification Required policy [RFC5226]. See
Section 6.2 for the initial assignment in the registry. Section 6.2 for the initial assignment in the registry.
Section 6.6 defines a new "Overload Report Type" registry with its Section 6.6 defines a new "Overload Report Type" registry with its
initial assignments. New types can be added using the Specification initial assignments. New types can be added using the Specification
Required policy [RFC5226]. Required policy [RFC5226].
skipping to change at page 33, line 44 skipping to change at page 34, line 17
This specification describes only means for a simple loss based This specification describes only means for a simple loss based
algorithm. Future algorithms can be added using the designed algorithm. Future algorithms can be added using the designed
solution extension mechanism. The new algorithms need to be solution extension mechanism. The new algorithms need to be
registered with IANA. See Sections 6.1 and 8 for the required IANA registered with IANA. See Sections 6.1 and 8 for the required IANA
steps. steps.
A.2. Agent Overload A.2. Agent Overload
This specification focuses on Diameter endpoint (server or client) This specification focuses on Diameter endpoint (server or client)
overload. A separate extension will be required to outline the overload. A separate extension will be required to outline the
handling of the case of agent overload. handling the case of agent overload.
A.3. New Error Diagnostic AVP A.3. Requirements Conformance Analysis
The proposal was made to add a new Error Diagnostic AVP to supplement This section contains the result of an analysis of the DOIC solutions
the error responces to be able to indicate that overload was the conformance to the requirements defined in [RFC7068].
reason for the rejection of the message.
To be completed.
A.4. DIAMETER_TOO_BUSY clarifications
The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is
somewhat under specified. For example, there is no information how
long the specific Diameter node is willing to be unavailable. A
specification updating [RFC6733] should clarify the handling of
DIAMETER_TOO_BUSY from the error answer initiating Diameter node
point of view and from the original request initiating Diameter node
point of view. Further, the inclusion of possible additional
information providing AVPs should be discussed and possible be
recommended to be used.
Appendix B. Deployment Considerations Appendix B. Deployment Considerations
Non supporting agents Non supporting agents
Due to the way that realm-routed requests are handled in Diameter Due to the way that realm-routed requests are handled in Diameter
networks, with the server selection for the request done by an networks, with the server selection for the request done by an
agent, it is recommended that deployments enable all agents that agent, it is recommended that deployments upgrade all agents with
do server selection to support the DOIC solution prior to enabling direct connections to servers prior to enabling the DOIC solution
the DOIC solution in the Diameter network. in the Diameter network.
Topology hiding interactions Topology hiding interactions
There exist proxies that implement what is referred to as Topology There exist proxies that implement what is referred to as Topology
Hiding. This can include cases where the agent modifies the Hiding. This can include cases where the agent modifies the
Origin-Host in answer messages. The behavior of the DOIC solution Origin-Host in answer messages. The behavior of the DOIC solution
is not well understood when this happens. As such, the DOIC is not well understood when this happens. As such, the DOIC
solution does not address this scenario. solution does not address this scenario.
Appendix C. Requirements Conformance Analysis Appendix C. Considerations for Applications Integrating the DOIC
This section contains the result of an analysis of the DOIC solutions
conformance to the requirements defined in [RFC7068].
To be completed.
Appendix D. Considerations for Applications Integrating the DOIC
Solution Solution
This section outlines considerations to be taken into account when This section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications. integrating the DOIC solution into Diameter applications.
D.1. Application Classification C.1. Application Classification
The following is a classification of Diameter applications and The following is a classification of Diameter applications and
request types. This discussion is meant to document factors that request types. This discussion is meant to document factors that
play into decisions made by the Diameter identity responsible for play into decisions made by the Diameter identity responsible for
handling overload reports. handling overload reports.
Section 8.1 of [RFC6733] defines two state machines that imply two Section 8.1 of [RFC6733] defines two state machines that imply two
types of applications, session-less and session-based applications. types of applications, session-less and session-based applications.
The primary difference between these types of applications is the The primary difference between these types of applications is the
lifetime of Session-Ids. lifetime of Session-Ids.
skipping to change at page 35, line 30 skipping to change at page 36, line 8
Pseudo-session applications: Pseudo-session applications:
Applications that do not rely on the Session-Id AVP for Applications that do not rely on the Session-Id AVP for
correlation of application messages related to the same session correlation of application messages related to the same session
but use other session-related information in the Diameter requests but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application. example of a pseudo-session application.
The handling of overload reports must take the type of application The handling of overload reports must take the type of application
into consideration, as discussed in Appendix D.2. into consideration, as discussed in Appendix C.2.
D.2. Application Type Overload Implications C.2. Application Type Overload Implications
This section discusses considerations for mitigating overload This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type reported by a Diameter entity. This discussion focuses on the type
of application. Appendix D.3 discusses considerations for handling of application. Appendix C.3 discusses considerations for handling
various request types when the target server is known to be in an various request types when the target server is known to be in an
overloaded state. overloaded state.
These discussions assume that the strategy for mitigating the These discussions assume that the strategy for mitigating the
reported overload is to reduce the overall workload sent to the reported overload is to reduce the overall workload sent to the
overloaded entity. The concept of applying overload treatment to overloaded entity. The concept of applying overload treatment to
requests targeted for an overloaded Diameter entity is inherent to requests targeted for an overloaded Diameter entity is inherent to
this discussion. The method used to reduce offered load is not this discussion. The method used to reduce offered load is not
specified here but could include routing requests to another Diameter specified here but could include routing requests to another Diameter
entity known to be able to handle them, or it could mean rejecting entity known to be able to handle them, or it could mean rejecting
skipping to change at page 36, line 43 skipping to change at page 37, line 22
towards an overloaded Diameter entity for a session-based towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session ending rejecting intra-session requests. In addition, session ending
requests might be given a lower probability of being rejected as requests might be given a lower probability of being rejected as
rejecting session ending requests could result in session status rejecting session ending requests could result in session status
being out of sync between the Diameter clients and servers. being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates requests will need to consider whether the rejection invalidates
the session and any resulting session clean-up procedures. the session and any resulting session clean-up procedures.
D.3. Request Transaction Classification C.3. Request Transaction Classification
Independent Request: Independent Request:
An independent request is not correlated to any other requests An independent request is not correlated to any other requests
and, as such, the lifetime of the session-id is constrained to an and, as such, the lifetime of the session-id is constrained to an
individual transaction. individual transaction.
Session-Initiating Request: Session-Initiating Request:
A session-initiating request is the initial message that A session-initiating request is the initial message that
skipping to change at page 37, line 35 skipping to change at page 38, line 15
Pseudo-Session Requests: Pseudo-Session Requests:
Pseudo-session requests are independent requests and do not use Pseudo-session requests are independent requests and do not use
the same Session-Id but are correlated by other session-related the same Session-Id but are correlated by other session-related
information contained in the request. There exists Diameter information contained in the request. There exists Diameter
applications that define an expected ordering of transactions. applications that define an expected ordering of transactions.
This sequencing of independent transactions results in a pseudo This sequencing of independent transactions results in a pseudo
session. The AIR, MAR and SAR requests in the 3GPP defined Cx session. The AIR, MAR and SAR requests in the 3GPP defined Cx
[Cx] application are examples of pseudo-session requests. [Cx] application are examples of pseudo-session requests.
D.4. Request Type Overload Implications C.4. Request Type Overload Implications
The request classes identified in Appendix D.3 have implications on The request classes identified in Appendix C.3 have implications on
decisions about which requests should be throttled first. The decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy, exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application. unless specifically defined for the application.
Independent requests: Independent requests:
Independent requests can generally be given equal treatment when Independent requests can generally be given equal treatment when
 End of changes. 69 change blocks. 
141 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------070206030601040508010203-- From nobody Thu Nov 6 15:14: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 B30031A0055 for ; Thu, 6 Nov 2014 15:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cctObhnQvotY for ; Thu, 6 Nov 2014 15:13:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C574A1A0059 for ; Thu, 6 Nov 2014 15:13:57 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA6NDrsg035575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2014 17:13: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.23] Content-Type: multipart/alternative; boundary="Apple-Mail=_78AAB502-7503-4679-971A-97D332CE60EB" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <5457BECA.3050905@cisco.com> Date: Thu, 6 Nov 2014 17:13:53 -0600 X-Mao-Original-Outgoing-Id: 437008433.58286-2e5baada19a175834cdc75878bc90cb7 Message-Id: <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KUoL56SHa8mkBzMGh5jCG0I1NWQ Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 23:14:05 -0000 --Apple-Mail=_78AAB502-7503-4679-971A-97D332CE60EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On Nov 3, 2014, at 11:43 AM, Benoit Claise wrote: >=20 > Hi Ben, >=20 > Thanks for your detailed analysis. > While this is good, what is required is the justification of why some = requirements are not met with DOIC and why have you decided to postpone = some RFC 7068 requirements? Then you can list those requirements. >=20 Hi Benoit, Here's an updated version with a "summary" section at the front. = Hopefully this captures what you are looking for.=20 I've put this in version 05 in a branch in GitHub. If no one objects in = the next few days, I will send a pull request to merge it into the main = branch. Thanks! Ben. ---------------------- Appendix E. Requirements Analysis [RFC EDITOR: Please remove this section prior to publication as an RFC.] This section analyzes the mechanism described in this document against the set of requirements detailed in [RFC7068]. E.1. Requirements Summary This section summarizes areas where DOIC partially complies or does not comply with certain requirements. Please see Appendix E.2 for the text of each requirement. The following requirements have been deferred for future work, due to schedule constraints (3GPP CT4 needs to reference basic overload control for release 12): o Requirements 1 (partial), 12 (partial), 23, and 24 - DOIC does not currently support conveyance of load information when not otherwise overloaded. o Requirements 1 (partial), and 31 (partial) - DOIC does not currently allow the reporting of an overloaded agent. (DIME has a separate milestone for agent overload.) The following requirements could not be met due to certain working group decisions: o Requirements 6 (partial), 16 (partial), 28 (partial), 29 (partial) and 34 (partial). - The working group elected not to add a way to determine that non-supporting node exists between two DOIC supporting nodes. o Requirements 8 (partial), 9, 10 (partial), 19 (partial), and 34 (partial) - The application and server or realm to which an OLR applies is determined by the Application-Id and Origin-Realm AVPs of the enclosing answer. If a node that doesn't understand DOIC modifies certain AVPs in the enclosing answer, the OLR will become invalid, without a way for downstream nodes to detect it. It is currently not possible to construct an OLR that refers to an application, server, or realm different from that of the answer that carries it. o Requirement 13: While the requirement discourages sending OLRs in every response, the working group decided that not doing that would be less reliable, and require more stateful behavior. (Note that the document allows reporting nodes to avoid sending OLRs in every response if the node has some other way of determining that all relevant reacting nodes receive the report.) o The working group believes that DOIC is compliant with requirement 27 (no new vulnerabilities). However, this may warrant an early review from a security expert. E.2. Detailed Requirements E.2.1. General REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. *Partially Compliant*. The mechanism uses new AVPs piggybacked on existing Diameter messages to exchange overload information. It does not currently support "load" information or the ability to report overload of an agent. These have been left for future extensions. REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3. *Compliant*. The DOIC AVPs can be used in any application that allows the extension of AVPs. REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity. The overall useful throughput under load is the ultimate measure of the value of a solution. *Compliant*. DOIC provides information that nodes can use to reduce the impact of overload. REQ 4: Diameter allows requests to be sent from either side of a connection, and either side of a connection may have need to provide its overload status. The solution MUST allow each side of a connection to independently inform the other of its overload status. *Compliant*. DOIC AVPs can be included regardless of transaction "direction" REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined. *Compliant*. DOIC contains no assumptions about how peers are discovered. [Note: This may require further study] REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge to be configured at each node. *Partially Compliant*. Most DOIC parameters are advertised using the DOIC capability announcement mechanism. However, there are some situations where configuration is required. For example, a DOIC node detect the fact that a peer may not support DOIC when nodes on the other side of the non- supporting node do support DOIC without configuration. E.2.2. Performance REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition. *Compliant*. The specification offers guidance that implementations should apply hysteresis when recovering from overload, and avoid sudden ramp ups in offered load when recovering. REQ 8: Supporting nodes MUST be able to distinguish current overload information from stale information. *Partially Compliant*. DOIC overload reports are "soft state", that is they expire after an indicated period. DOIC nodes may also send reports that end existing overload conditions. DOIC requires reporting nodes to ensure that all relevant reacting nodes receive overload reports. However, since DOIC does not allow reports to send OLRs in watchdog messages, if an overload condition results in zero offered load, the reporting node cannot update the condition until the expiration of the original OLR. REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections. This is partially derived from the requirement for stability in REQ 7. *Not Compliant*. DOIC does not allow OLRs to be sent over quiescent transport connections. This is due to the fact that OLRs cannot be sent outside of the application to which they apply. REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends. *Partially Compliant*. (See response to previous two requirements.) REQ 11: The solution MUST be able to operate in networks of different sizes. *Compliant*. DOIC makes no assumptions about the size of the network. DOIC can operate purely between clients and servers, or across agents. REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small- scale failure from becoming a widespread outage. *Partially Compliant*. DOIC allows overload reports for an entire realm, where abated traffic will not be redirected towards another server. But in situations where nodes choose to divert traffic to other nodes, DOIC offers no way of knowing whether the new recipients can handle the traffic if they have not already indicated overload. This may be mitigated with the use of a future "load" extension, or with the use of proprietary dynamic load-balancing mechanisms. REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work. *Not Compliant*. DOIC does in fact encourage an overloaded node to send an OLR in every response. The working group that other mechanisms to ensure that every relevant node receives an OLR would create even more work. [Note: This needs discussion.] REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase. *Compliant*. The piggyback mechanism allows OLRs to be sent at the same rate as application traffic. REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms. *Compliant*. DOIC does not require or recommend changes in the handling of transport protocols or connections. E.2.3. Heterogeneous Support for Solution 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. *Partially Compliant*. DOIC works with most mixed-deployment scenarios. However, it cannot work across a non-supporting proxy that modifies Origin-Host AVPs in answer messages. DOIC will have limited impact in networks where the nodes that perform server selections do not support the mechanism. REQ 17: In a mixed environment with nodes that support the solution and nodes that do not, the solution MUST NOT result in materially less useful throughput during overload as would have resulted if the solution were not present. It SHOULD result in less severe overload in this environment. *Compliant*. In most mixed-support deployment, DOIC will offer at least some value, and will not make things worse. 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. *Compliant*. DOIC provides mechanisms to abate load from non- supporting sources. Furthermore, it recommends that reporting nodes will still need to be able to apply whatever protections they would ordinarily apply if DOIC were not in use. REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains. *Partially Compliant*. DOIC allows sending OLRs across administrative domains, and potentially to nodes in other realms. However, an OLR cannot indicate overload for realms other than the one in the Origin-Realm AVP of the containing answer. REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter. *Compliant*. DOIC sends explicit overload indication in overload reports. It does not depend on error result codes. [Note: I don't think the resuse of too-busy and unable-to- comply for throttled requests impacts this requirement. Do others agree?] REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of overload. The solution MUST result in at least as much useful throughput as would have resulted if the solution were not in place. *Compliant*. DOIC overload reports have the primary effect of suppressing message retries in overload conditions. DOIC recommends that messages never be silently dropped if at all possible. E.2.4. Granular Control REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node. This throttling SHOULD be graded so that it can be applied gradually as offered load increases. Overload is not a binary state; there may be degrees of overload. *Compliant*. The "loss" algorithm expresses a percentage reduction. REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. *Not Compliant*. DOIC provides no built in mechanism to determine the best place to divert messages that would otherwise be throttled. This can be accomplished with a future "load" extension, or with proprietary load balancing mechanisms. REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring. *Not Compliant*. "Load" information has been left for a future extension. E.2.5. Priority and Policy REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be desirable to send or process over others during times of overload, based on application-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition will be the responsibility of the application specification. *Compliant*. The specification offers guidance on how requests might be prioritized for different types of applications. REQ 26: The solution MUST NOT prevent a node from prioritizing requests based on any local policy, so that certain requests are given preferential treatment, given additional retransmission, not throttled, or processed ahead of others. *Compliant*. Nothing in the specification prevents application-specific, implementation-specific, or local policies. E.2.6. Security REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack or increase the severity of any existing vulnerabilities. This includes vulnerabilities to DoS and DDoS attacks as well as replay and man-in-the-middle attacks. Note that the Diameter base specification [RFC6733] lacks end-to-end security and this must be considered (see the Security Considerations in [RFC7068]). Note that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail. *Compliant*. The working group is not aware of any such vulnerabilities. [This may need further analysis.] REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes. *Partially Compliant*. Since all Diameter security is currently at the transport layer, nodes must trust immediate peers to enforce trust policies. However, there are situations where a DOIC node cannot determine if an immediate peer supports DOIC. The authors recommend an expert security review. REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node. *Partially Compliant*. (See response to previous requirement.) REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks. *Compliant*. The specification recommends that any such protection mechanism needed without DOIC should continue to be employed with DOIC. E.2.7. Flexibility and Extensibility 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. *Partially Compliant*. All DOIC overload reports are scoped to the specific application and realm. Inside that scope, overload can be reported at the specific server or whole realm scope. As currently specified, DOIC cannot indicate local overload for an agent. At the time of this writing, the DIME working group has plans to work on an agent-overload extension. DOIC allows new "scopes" through the use of extended report types. REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control. *Compliant*. DOIC allows new report types and abatement algorithms to be created. These may be indicated using the OC-Supported-Features AVP. REQ 33: The solution MUST provide a default algorithm that is mandatory to implement. *Compliant*. The "loss" algorithm is mandatory to implement. REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution. *Partially Compliant*. DOIC information can traverse non- supporting agents, as long as those agents do not modify certain AVPs. (e.g., Origin-Host). DOIC does not provide a way for supporting nodes to detect such modification. --Apple-Mail=_78AAB502-7503-4679-971A-97D332CE60EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Nov 3, 2014, at = 11:43 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Ben,

Thanks for your detailed = analysis.
While this is good, what is required is the = justification of why some requirements are not met with DOIC and = why have you decided to postpone some RFC 7068 requirements? = Then you can list those requirements.


Hi Benoit,

Here's an updated = version with a "summary" section at the front. Hopefully this captures = what you are looking for. 

I've put = this in version 05 in a branch in GitHub. If no one objects in the next = few days, I will send a pull request to merge it into the main = branch.

Thanks!

Ben.

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

Appendix E. Requirements Analysis [RFC EDITOR: Please remove this section prior to publication as an RFC.] This section analyzes the mechanism described in this document against the set of requirements detailed in [RFC7068]. E.1. Requirements Summary This section summarizes areas where DOIC partially complies or does not comply with certain requirements. Please see Appendix E.2 for the text of each requirement. The following requirements have been deferred for future work, due to schedule constraints (3GPP CT4 needs to reference basic overload control for release 12): o Requirements 1 (partial), 12 (partial), 23, and 24 - DOIC does not currently support conveyance of load information when not otherwise overloaded. o Requirements 1 (partial), and 31 (partial) - DOIC does not currently allow the reporting of an overloaded agent. (DIME has a separate milestone for agent overload.) The following requirements could not be met due to certain working group decisions: o Requirements 6 (partial), 16 (partial), 28 (partial), 29 (partial) and 34 (partial). - The working group elected not to add a way to determine that non-supporting node exists between two DOIC supporting nodes. o Requirements 8 (partial), 9, 10 (partial), 19 (partial), and 34 (partial) - The application and server or realm to which an OLR applies is determined by the Application-Id and Origin-Realm AVPs of the enclosing answer. If a node that doesn't understand DOIC modifies certain AVPs in the enclosing answer, the OLR will become invalid, without a way for downstream nodes to detect it. It is currently not possible to construct an OLR that refers to an application, server, or realm different from that of the answer that carries it. o Requirement 13: While the requirement discourages sending OLRs in every response, the working group decided that not doing that would be less reliable, and require more stateful behavior. (Note that the document allows reporting nodes to avoid sending OLRs in every response if the node has some other way of determining that all relevant reacting nodes receive the report.) o The working group believes that DOIC is compliant with requirement 27 (no new vulnerabilities). However, this may warrant an early review from a security expert. E.2. Detailed Requirements E.2.1. General REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. *Partially Compliant*. The mechanism uses new AVPs piggybacked on existing Diameter messages to exchange overload information. It does not currently support "load" information or the ability to report overload of an agent. These have been left for future extensions. REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3. *Compliant*. The DOIC AVPs can be used in any application that allows the extension of AVPs. REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity. The overall useful throughput under load is the ultimate measure of the value of a solution. *Compliant*. DOIC provides information that nodes can use to reduce the impact of overload. REQ 4: Diameter allows requests to be sent from either side of a connection, and either side of a connection may have need to provide its overload status. The solution MUST allow each side of a connection to independently inform the other of its overload status. *Compliant*. DOIC AVPs can be included regardless of transaction "direction" REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined. *Compliant*. DOIC contains no assumptions about how peers are discovered. [Note: This may require further study] REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge to be configured at each node. *Partially Compliant*. Most DOIC parameters are advertised using the DOIC capability announcement mechanism. However, there are some situations where configuration is required. For example, a DOIC node detect the fact that a peer may not support DOIC when nodes on the other side of the non- supporting node do support DOIC without configuration. E.2.2. Performance REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition. *Compliant*. The specification offers guidance that implementations should apply hysteresis when recovering from overload, and avoid sudden ramp ups in offered load when recovering. REQ 8: Supporting nodes MUST be able to distinguish current overload information from stale information. *Partially Compliant*. DOIC overload reports are "soft state", that is they expire after an indicated period. DOIC nodes may also send reports that end existing overload conditions. DOIC requires reporting nodes to ensure that all relevant reacting nodes receive overload reports. However, since DOIC does not allow reports to send OLRs in watchdog messages, if an overload condition results in zero offered load, the reporting node cannot update the condition until the expiration of the original OLR. REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections. This is partially derived from the requirement for stability in REQ 7. *Not Compliant*. DOIC does not allow OLRs to be sent over quiescent transport connections. This is due to the fact that OLRs cannot be sent outside of the application to which they apply. REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends. *Partially Compliant*. (See response to previous two requirements.) REQ 11: The solution MUST be able to operate in networks of different sizes. *Compliant*. DOIC makes no assumptions about the size of the network. DOIC can operate purely between clients and servers, or across agents. REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small- scale failure from becoming a widespread outage. *Partially Compliant*. DOIC allows overload reports for an entire realm, where abated traffic will not be redirected towards another server. But in situations where nodes choose to divert traffic to other nodes, DOIC offers no way of knowing whether the new recipients can handle the traffic if they have not already indicated overload. This may be mitigated with the use of a future "load" extension, or with the use of proprietary dynamic load-balancing mechanisms. REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work. *Not Compliant*. DOIC does in fact encourage an overloaded node to send an OLR in every response. The working group that other mechanisms to ensure that every relevant node receives an OLR would create even more work. [Note: This needs discussion.] REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase. *Compliant*. The piggyback mechanism allows OLRs to be sent at the same rate as application traffic. REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms. *Compliant*. DOIC does not require or recommend changes in the handling of transport protocols or connections. E.2.3. Heterogeneous Support for Solution 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. *Partially Compliant*. DOIC works with most mixed-deployment scenarios. However, it cannot work across a non-supporting proxy that modifies Origin-Host AVPs in answer messages. DOIC will have limited impact in networks where the nodes that perform server selections do not support the mechanism. REQ 17: In a mixed environment with nodes that support the solution and nodes that do not, the solution MUST NOT result in materially less useful throughput during overload as would have resulted if the solution were not present. It SHOULD result in less severe overload in this environment. *Compliant*. In most mixed-support deployment, DOIC will offer at least some value, and will not make things worse. 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. *Compliant*. DOIC provides mechanisms to abate load from non- supporting sources. Furthermore, it recommends that reporting nodes will still need to be able to apply whatever protections they would ordinarily apply if DOIC were not in use. REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains. *Partially Compliant*. DOIC allows sending OLRs across administrative domains, and potentially to nodes in other realms. However, an OLR cannot indicate overload for realms other than the one in the Origin-Realm AVP of the containing answer. REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter. *Compliant*. DOIC sends explicit overload indication in overload reports. It does not depend on error result codes. [Note: I don't think the resuse of too-busy and unable-to- comply for throttled requests impacts this requirement. Do others agree?] REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of overload. The solution MUST result in at least as much useful throughput as would have resulted if the solution were not in place. *Compliant*. DOIC overload reports have the primary effect of suppressing message retries in overload conditions. DOIC recommends that messages never be silently dropped if at all possible. E.2.4. Granular Control REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node. This throttling SHOULD be graded so that it can be applied gradually as offered load increases. Overload is not a binary state; there may be degrees of overload. *Compliant*. The "loss" algorithm expresses a percentage reduction. REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. *Not Compliant*. DOIC provides no built in mechanism to determine the best place to divert messages that would otherwise be throttled. This can be accomplished with a future "load" extension, or with proprietary load balancing mechanisms. REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring. *Not Compliant*. "Load" information has been left for a future extension. E.2.5. Priority and Policy REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be desirable to send or process over others during times of overload, based on application-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition will be the responsibility of the application specification. *Compliant*. The specification offers guidance on how requests might be prioritized for different types of applications. REQ 26: The solution MUST NOT prevent a node from prioritizing requests based on any local policy, so that certain requests are given preferential treatment, given additional retransmission, not throttled, or processed ahead of others. *Compliant*. Nothing in the specification prevents application-specific, implementation-specific, or local policies. E.2.6. Security REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack or increase the severity of any existing vulnerabilities. This includes vulnerabilities to DoS and DDoS attacks as well as replay and man-in-the-middle attacks. Note that the Diameter base specification [RFC6733] lacks end-to-end security and this must be considered (see the Security Considerations in [RFC7068]). Note that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail. *Compliant*. The working group is not aware of any such vulnerabilities. [This may need further analysis.] REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes. *Partially Compliant*. Since all Diameter security is currently at the transport layer, nodes must trust immediate peers to enforce trust policies. However, there are situations where a DOIC node cannot determine if an immediate peer supports DOIC. The authors recommend an expert security review. REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node. *Partially Compliant*. (See response to previous requirement.) REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks. *Compliant*. The specification recommends that any such protection mechanism needed without DOIC should continue to be employed with DOIC. E.2.7. Flexibility and Extensibility 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. *Partially Compliant*. All DOIC overload reports are scoped to the specific application and realm. Inside that scope, overload can be reported at the specific server or whole realm scope. As currently specified, DOIC cannot indicate local overload for an agent. At the time of this writing, the DIME working group has plans to work on an agent-overload extension. DOIC allows new "scopes" through the use of extended report types. REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control. *Compliant*. DOIC allows new report types and abatement algorithms to be created. These may be indicated using the OC-Supported-Features AVP. REQ 33: The solution MUST provide a default algorithm that is mandatory to implement. *Compliant*. The "loss" algorithm is mandatory to implement. REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution. *Partially Compliant*. DOIC information can traverse non- supporting agents, as long as those agents do not modify certain AVPs. (e.g., Origin-Host). DOIC does not provide a way for supporting nodes to detect such modification.

= --Apple-Mail=_78AAB502-7503-4679-971A-97D332CE60EB-- From nobody Fri Nov 7 00:11: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 40B211ACF5E for ; Fri, 7 Nov 2014 00:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 RNWz3-VlkGZh for ; Fri, 7 Nov 2014 00:11:27 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118631ACF5B for ; Fri, 7 Nov 2014 00:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49344; q=dns/txt; s=iport; t=1415347886; x=1416557486; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=yohBOW/MtZqsvZFB1yfx9lYZyZcr8JbY+PxdvIEsp6Q=; b=Sdz+rnxJ0lHZ6oiIMKyYeYgQZolKxMQAVBqm7Id4YoCEbEdN6vVXLhS9 wUBQVVzzKmYdgAJvBN7iizfhBNvAmxq4exevqJqACln3yWSN0pZteXGSv 8+veWSUSeHDcokLGKYwwHtkXQ7X6MAbqEC2daEtprNCVJ6vndApXdXov2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUHAO19XFStJssW/2dsb2JhbABSCYQ7iGHKNQKBLwEBAQEBfYQDAQEEGgFMBA0BEAsYCRYBAQYHCQMCAQIBNBEGDQEFAgEBF4gmznkBAQEBAQEEAQEBAQEBAQEBARiKdYVBAwFXB4RLBYY2AYlMh0uBcIRYgTKDToJ3hzIPgxqECYF9gX08L4EGAQYZgSUBAQE X-IronPort-AV: E=Sophos;i="5.07,330,1413244800"; d="scan'208,217";a="232392785" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 07 Nov 2014 08:11:22 +0000 Received: from [10.61.75.99] (ams3-vpn-dhcp2915.cisco.com [10.61.75.99]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sA78BLQ8010219; Fri, 7 Nov 2014 08:11:21 GMT Message-ID: <545C7EA8.6070706@cisco.com> Date: Fri, 07 Nov 2014 09:11:20 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Ben Campbell References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> In-Reply-To: <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> Content-Type: multipart/alternative; boundary="------------010004060709060909030802" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Hvvv_1H_-eiW9V8-KUO9Mq1avZg Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 08:11:33 -0000 This is a multi-part message in MIME format. --------------010004060709060909030802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ben, I believe that the E1, at least, must be part of draft. I'm referring to [RFC EDITOR: Please remove this section prior to publication as an RFC.] For E2, up to the WG to decide. Regards, Benoit > >> On Nov 3, 2014, at 11:43 AM, Benoit Claise > > wrote: >> >> Hi Ben, >> >> Thanks for your detailed analysis. >> While this is good, what is required is the justification of why some >> requirements are not met with DOIC and why have you decided to >> postpone some RFC 7068 requirements? Then you can list >> those requirements. >> > > Hi Benoit, > > Here's an updated version with a "summary" section at the front. > Hopefully this captures what you are looking for. > > I've put this in version 05 in a branch in GitHub. If no one objects > in the next few days, I will send a pull request to merge it into the > main branch. > > Thanks! > > Ben. > > ---------------------- > > Appendix E. Requirements Analysis > > [RFC EDITOR: Please remove this section prior to publication as an > RFC.] > > This section analyzes the mechanism described in this document > against the set of requirements detailed in [RFC7068]. > > E.1. Requirements Summary > > This section summarizes areas where DOIC partially complies or does > not comply with certain requirements. Please see Appendix E.2 for > the text of each requirement. > > The following requirements have been deferred for future work, due to > schedule constraints (3GPP CT4 needs to reference basic overload > control for release 12): > > o Requirements 1 (partial), 12 (partial), 23, and 24 - DOIC does not > currently support conveyance of load information when not > otherwise overloaded. > > o Requirements 1 (partial), and 31 (partial) - DOIC does not > currently allow the reporting of an overloaded agent. (DIME has a > separate milestone for agent overload.) > > The following requirements could not be met due to certain working > group decisions: > > o Requirements 6 (partial), 16 (partial), 28 (partial), 29 (partial) > and 34 (partial). - The working group elected not to add a way to > determine that non-supporting node exists between two DOIC > supporting nodes. > > o Requirements 8 (partial), 9, 10 (partial), 19 (partial), and 34 > (partial) - The application and server or realm to which an OLR > applies is determined by the Application-Id and Origin-Realm AVPs > of the enclosing answer. If a node that doesn't understand DOIC > modifies certain AVPs in the enclosing answer, the OLR will become > invalid, without a way for downstream nodes to detect it. It is > currently not possible to construct an OLR that refers to an > application, server, or realm different from that of the answer > that carries it. > > o Requirement 13: While the requirement discourages sending OLRs in > every response, the working group decided that not doing that > would be less reliable, and require more stateful behavior. (Note > that the document allows reporting nodes to avoid sending OLRs in > every response if the node has some other way of determining that > all relevant reacting nodes receive the report.) > > o The working group believes that DOIC is compliant with requirement > 27 (no new vulnerabilities). However, this may warrant an early > review from a security expert. > > E.2. Detailed Requirements > > E.2.1. General > > REQ 1: The solution MUST provide a communication method for Diameter > nodes to exchange load and overload information. > > *Partially Compliant*. The mechanism uses new AVPs > piggybacked on existing Diameter messages to exchange > overload information. It does not currently support "load" > information or the ability to report overload of an agent. > These have been left for future extensions. > > > > REQ 2: The solution MUST allow Diameter nodes to support overload > control regardless of which Diameter applications they > support. Diameter clients and agents must be able to use the > received load and overload information to support graceful > behavior during an overload condition. Graceful behavior > under overload conditions is best described by REQ 3. > > *Compliant*. The DOIC AVPs can be used in any application > that allows the extension of AVPs. > > > > REQ 3: The solution MUST limit the impact of overload on the overall > useful throughput of a Diameter server, even when the > incoming load on the network is far in excess of its > capacity. The overall useful throughput under load is the > ultimate measure of the value of a solution. > > *Compliant*. DOIC provides information that nodes can use to > reduce the impact of overload. > > > > REQ 4: Diameter allows requests to be sent from either side of a > connection, and either side of a connection may have need to > provide its overload status. The solution MUST allow each > side of a connection to independently inform the other of its > overload status. > > *Compliant*. DOIC AVPs can be included regardless of > transaction "direction" > > > > REQ 5: Diameter allows nodes to determine their peers via dynamic > discovery or manual configuration. The solution MUST work > consistently without regard to how peers are determined. > > *Compliant*. DOIC contains no assumptions about how peers are > discovered. [Note: This may require further study] > > > > REQ 6: The solution designers SHOULD seek to minimize the amount of > new configuration required in order to work. For example, it > is better to allow peers to advertise or negotiate support > for the solution, rather than to require that this knowledge > to be configured at each node. > > *Partially Compliant*. Most DOIC parameters are advertised > using the DOIC capability announcement mechanism. However, > there are some situations where configuration is required. > For example, a DOIC node detect the fact that a peer may not > support DOIC when nodes on the other side of the non- > supporting node do support DOIC without configuration. > > > > E.2.2. Performance > > REQ 7: The solution and any associated default algorithm(s) MUST > ensure that the system remains stable. At some point after > an overload condition has ended, the solution MUST enable > capacity to stabilize and become equal to what it would be in > the absence of an overload condition. Note that this also > requires that the solution MUST allow nodes to shed load > without introducing non-converging oscillations during or > after an overload condition. > > *Compliant*. The specification offers guidance that > implementations should apply hysteresis when recovering from > overload, and avoid sudden ramp ups in offered load when > recovering. > > > > REQ 8: Supporting nodes MUST be able to distinguish current overload > information from stale information. > > *Partially Compliant*. DOIC overload reports are "soft > state", that is they expire after an indicated period. DOIC > nodes may also send reports that end existing overload > conditions. DOIC requires reporting nodes to ensure that all > relevant reacting nodes receive overload reports. > > However, since DOIC does not allow reports to send OLRs in > watchdog messages, if an overload condition results in zero > offered load, the reporting node cannot update the condition > until the expiration of the original OLR. > > > > REQ 9: The solution MUST function across fully loaded as well as > quiescent transport connections. This is partially derived > from the requirement for stability in REQ 7. > > *Not Compliant*. DOIC does not allow OLRs to be sent over > quiescent transport connections. This is due to the fact > that OLRs cannot be sent outside of the application to which > they apply. > > > > REQ 10: Consumers of overload information MUST be able to determine > when the overload condition improves or ends. > > *Partially Compliant*. (See response to previous two > requirements.) > > > > REQ 11: The solution MUST be able to operate in networks of different > sizes. > > *Compliant*. DOIC makes no assumptions about the size of the > network. DOIC can operate purely between clients and > servers, or across agents. > > > > REQ 12: When a single network node fails, goes into overload, or > suffers from reduced processing capacity, the solution MUST > make it possible to limit the impact of the affected node on > other nodes in the network. This helps to prevent a small- > scale failure from becoming a widespread outage. > > *Partially Compliant*. DOIC allows overload reports for an > entire realm, where abated traffic will not be redirected > towards another server. But in situations where nodes choose > to divert traffic to other nodes, DOIC offers no way of > knowing whether the new recipients can handle the traffic if > they have not already indicated overload. This may be > mitigated with the use of a future "load" extension, or with > the use of proprietary dynamic load-balancing mechanisms. > > > > REQ 13: The solution MUST NOT introduce substantial additional work > for a node in an overloaded state. For example, a > requirement for an overloaded node to send overload > information every time it received a new request would > introduce substantial work. > > *Not Compliant*. DOIC does in fact encourage an overloaded > node to send an OLR in every response. The working group > that other mechanisms to ensure that every relevant node > receives an OLR would create even more work. [Note: This > needs discussion.] > > > > REQ 14: Some scenarios that result in overload involve a rapid > increase of traffic with little time between normal levels > and levels that induce overload. The solution SHOULD provide > for rapid feedback when traffic levels increase. > > *Compliant*. The piggyback mechanism allows OLRs to be sent > at the same rate as application traffic. > > > > REQ 15: The solution MUST NOT interfere with the congestion control > mechanisms of underlying transport protocols. For example, a > solution that opened additional TCP connections when the > network is congested would reduce the effectiveness of the > underlying congestion control mechanisms. > > *Compliant*. DOIC does not require or recommend changes in > the handling of transport protocols or connections. > > > > E.2.3. Heterogeneous Support for Solution > > 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. > > *Partially Compliant*. DOIC works with most mixed-deployment > scenarios. However, it cannot work across a non-supporting > proxy that modifies Origin-Host AVPs in answer messages. > DOIC will have limited impact in networks where the nodes > that perform server selections do not support the mechanism. > > > > REQ 17: In a mixed environment with nodes that support the solution > and nodes that do not, the solution MUST NOT result in > materially less useful throughput during overload as would > have resulted if the solution were not present. It SHOULD > result in less severe overload in this environment. > > *Compliant*. In most mixed-support deployment, DOIC will > offer at least some value, and will not make things worse. > > > > 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. > > *Compliant*. DOIC provides mechanisms to abate load from non- > supporting sources. Furthermore, it recommends that > reporting nodes will still need to be able to apply whatever > protections they would ordinarily apply if DOIC were not in > use. > > > > REQ 19: It MUST be possible to use the solution between nodes in > different realms and in different administrative domains. > > *Partially Compliant*. DOIC allows sending OLRs across > administrative domains, and potentially to nodes in other > realms. However, an OLR cannot indicate overload for realms > other than the one in the Origin-Realm AVP of the containing > answer. > > > > REQ 20: Any explicit overload indication MUST be clearly > distinguishable from other errors reported via Diameter. > > *Compliant*. DOIC sends explicit overload indication in > overload reports. It does not depend on error result codes. > [Note: I don't think the resuse of too-busy and unable-to- > comply for throttled requests impacts this requirement. Do > others agree?] > > > > REQ 21: In cases where a network node fails, is so overloaded that it > cannot process messages, or cannot communicate due to a > network failure, it may not be able to provide explicit > indications of the nature of the failure or its levels of > overload. The solution MUST result in at least as much > useful throughput as would have resulted if the solution were > not in place. > > *Compliant*. DOIC overload reports have the primary effect of > suppressing message retries in overload conditions. DOIC > recommends that messages never be silently dropped if at all > possible. > > > > E.2.4. Granular Control > > REQ 22: The solution MUST provide a way for a node to throttle the > amount of traffic it receives from a peer node. This > throttling SHOULD be graded so that it can be applied > gradually as offered load increases. Overload is not a > binary state; there may be degrees of overload. > > *Compliant*. The "loss" algorithm expresses a percentage > reduction. > > > > REQ 23: The solution MUST provide sufficient information to enable a > load-balancing node to divert messages that are rejected or > otherwise throttled by an overloaded upstream node to other > upstream nodes that are the most likely to have sufficient > capacity to process them. > > *Not Compliant*. DOIC provides no built in mechanism to > determine the best place to divert messages that would > otherwise be throttled. This can be accomplished with a > future "load" extension, or with proprietary load balancing > mechanisms. > > > > REQ 24: The solution MUST provide a mechanism for indicating load > levels, even when not in an overload condition, to assist > nodes in making decisions to prevent overload conditions from > occurring. > > *Not Compliant*. "Load" information has been left for a > future extension. > > > > E.2.5. Priority and Policy > > REQ 25: The base specification for the solution SHOULD offer general > guidance on which message types might be desirable to send or > process over others during times of overload, based on > application-specific considerations. For example, it may be > more beneficial to process messages for existing sessions > ahead of new sessions. Some networks may have a requirement > to give priority to requests associated with emergency > sessions. Any normative or otherwise detailed definition of > the relative priorities of message types during an overload > condition will be the responsibility of the application > specification. > > *Compliant*. The specification offers guidance on how > requests might be prioritized for different types of > applications. > > > > REQ 26: The solution MUST NOT prevent a node from prioritizing > requests based on any local policy, so that certain requests > are given preferential treatment, given additional > retransmission, not throttled, or processed ahead of others. > > *Compliant*. Nothing in the specification prevents > application-specific, implementation-specific, or local > policies. > > > > E.2.6. Security > > REQ 27: The solution MUST NOT provide new vulnerabilities to > malicious attack or increase the severity of any existing > vulnerabilities. This includes vulnerabilities to DoS and > DDoS attacks as well as replay and man-in-the-middle attacks. > Note that the Diameter base specification [RFC6733] lacks > end-to-end security and this must be considered (see the > Security Considerations in [RFC7068]). Note that this > requirement was expressed at a high level so as to not > preclude any particular solution. Is is expected that the > solution will address this in more detail. > > *Compliant*. The working group is not aware of any such > vulnerabilities. [This may need further analysis.] > > > > REQ 28: The solution MUST NOT depend on being deployed in > environments where all Diameter nodes are completely trusted. > It SHOULD operate as effectively as possible in environments > where other nodes are malicious; this includes preventing > malicious nodes from obtaining more than a fair share of > service. Note that this does not imply any responsibility on > the solution to detect, or take countermeasures against, > malicious nodes. > > *Partially Compliant*. Since all Diameter security is > currently at the transport layer, nodes must trust immediate > peers to enforce trust policies. However, there are > situations where a DOIC node cannot determine if an immediate > peer supports DOIC. The authors recommend an expert security > review. > > > > REQ 29: It MUST be possible for a supporting node to make > authorization decisions about what information will be sent > to peer nodes based on the identity of those nodes. This > allows a domain administrator who considers the load of their > nodes to be sensitive information to restrict access to that > information. Of course, in such cases, there is no > expectation that the solution itself will help prevent > overload from that peer node. > > *Partially Compliant*. (See response to previous > requirement.) > > > > REQ 30: The solution MUST NOT interfere with any Diameter-compliant > method that a node may use to protect itself from overload > from non-supporting nodes or from denial-of-service attacks. > > *Compliant*. The specification recommends that any such > protection mechanism needed without DOIC should continue to > be employed with DOIC. > > > > E.2.7. Flexibility and Extensibility > > 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. > > *Partially Compliant*. All DOIC overload reports are scoped > to the specific application and realm. Inside that scope, > overload can be reported at the specific server or whole > realm scope. As currently specified, DOIC cannot indicate > local overload for an agent. At the time of this writing, > the DIME working group has plans to work on an agent-overload > extension. > > DOIC allows new "scopes" through the use of extended report > types. > > > > REQ 32: The solution MUST provide a method for extending the > information communicated and the algorithms used for overload > control. > > *Compliant*. DOIC allows new report types and abatement > algorithms to be created. These may be indicated using the > OC-Supported-Features AVP. > > > > REQ 33: The solution MUST provide a default algorithm that is > mandatory to implement. > > *Compliant*. The "loss" algorithm is mandatory to implement. > > > > REQ 34: The solution SHOULD provide a method for exchanging overload > and load information between elements that are connected by > intermediaries that do not support the solution. > > *Partially Compliant*. DOIC information can traverse non- > supporting agents, as long as those agents do not modify > certain AVPs. (e.g., Origin-Host). DOIC does not provide a > way for supporting nodes to detect such modification. > --------------010004060709060909030802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ben,

I believe that the E1, at least, must be part of draft. I'm referring to
   [RFC EDITOR: Please remove this section prior to publication as an
   RFC.]
For E2, up to the WG to decide.


Regards, Benoit

On Nov 3, 2014, at 11:43 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Ben,

Thanks for your detailed analysis.
While this is good, what is required is the justification of why some requirements are not met with DOIC and why have you decided to postpone some RFC 7068 requirements? Then you can list those requirements.


Hi Benoit,

Here's an updated version with a "summary" section at the front. Hopefully this captures what you are looking for. 

I've put this in version 05 in a branch in GitHub. If no one objects in the next few days, I will send a pull request to merge it into the main branch.

Thanks!

Ben.

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

Appendix E.  Requirements Analysis

   [RFC EDITOR: Please remove this section prior to publication as an
   RFC.]

   This section analyzes the mechanism described in this document
   against the set of requirements detailed in [RFC7068].

E.1.  Requirements Summary

   This section summarizes areas where DOIC partially complies or does
   not comply with certain requirements.  Please see Appendix E.2 for
   the text of each requirement.

   The following requirements have been deferred for future work, due to
   schedule constraints (3GPP CT4 needs to reference basic overload
   control for release 12):

   o  Requirements 1 (partial), 12 (partial), 23, and 24 - DOIC does not
      currently support conveyance of load information when not
      otherwise overloaded.

   o  Requirements 1 (partial), and 31 (partial) - DOIC does not
      currently allow the reporting of an overloaded agent.  (DIME has a
      separate milestone for agent overload.)

   The following requirements could not be met due to certain working
   group decisions:

   o  Requirements 6 (partial), 16 (partial), 28 (partial), 29 (partial)
      and 34 (partial). - The working group elected not to add a way to
      determine that non-supporting node exists between two DOIC
      supporting nodes.

   o  Requirements 8 (partial), 9, 10 (partial), 19 (partial), and 34
      (partial) - The application and server or realm to which an OLR
      applies is determined by the Application-Id and Origin-Realm AVPs
      of the enclosing answer.  If a node that doesn't understand DOIC
      modifies certain AVPs in the enclosing answer, the OLR will become
      invalid, without a way for downstream nodes to detect it.  It is
      currently not possible to construct an OLR that refers to an
      application, server, or realm different from that of the answer
      that carries it.

   o  Requirement 13: While the requirement discourages sending OLRs in
      every response, the working group decided that not doing that
      would be less reliable, and require more stateful behavior.  (Note
      that the document allows reporting nodes to avoid sending OLRs in
      every response if the node has some other way of determining that
      all relevant reacting nodes receive the report.)

   o  The working group believes that DOIC is compliant with requirement
      27 (no new vulnerabilities).  However, this may warrant an early
      review from a security expert.

E.2.  Detailed Requirements

E.2.1.  General

   REQ 1:  The solution MUST provide a communication method for Diameter
           nodes to exchange load and overload information.

           *Partially Compliant*. The mechanism uses new AVPs
           piggybacked on existing Diameter messages to exchange
           overload information.  It does not currently support "load"
           information or the ability to report overload of an agent.
           These have been left for future extensions.



   REQ 2:  The solution MUST allow Diameter nodes to support overload
           control regardless of which Diameter applications they
           support.  Diameter clients and agents must be able to use the
           received load and overload information to support graceful
           behavior during an overload condition.  Graceful behavior
           under overload conditions is best described by REQ 3.

           *Compliant*. The DOIC AVPs can be used in any application
           that allows the extension of AVPs.



   REQ 3:  The solution MUST limit the impact of overload on the overall
           useful throughput of a Diameter server, even when the
           incoming load on the network is far in excess of its
           capacity.  The overall useful throughput under load is the
           ultimate measure of the value of a solution.

           *Compliant*. DOIC provides information that nodes can use to
           reduce the impact of overload.



   REQ 4:  Diameter allows requests to be sent from either side of a
           connection, and either side of a connection may have need to
           provide its overload status.  The solution MUST allow each
           side of a connection to independently inform the other of its
           overload status.

           *Compliant*. DOIC AVPs can be included regardless of
           transaction "direction"



   REQ 5:  Diameter allows nodes to determine their peers via dynamic
           discovery or manual configuration.  The solution MUST work
           consistently without regard to how peers are determined.

           *Compliant*. DOIC contains no assumptions about how peers are
           discovered.  [Note: This may require further study]



   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require that this knowledge
           to be configured at each node.

           *Partially Compliant*. Most DOIC parameters are advertised
           using the DOIC capability announcement mechanism.  However,
           there are some situations where configuration is required.
           For example, a DOIC node detect the fact that a peer may not
           support DOIC when nodes on the other side of the non-
           supporting node do support DOIC without configuration.



E.2.2.  Performance

   REQ 7:  The solution and any associated default algorithm(s) MUST
           ensure that the system remains stable.  At some point after
           an overload condition has ended, the solution MUST enable
           capacity to stabilize and become equal to what it would be in
           the absence of an overload condition.  Note that this also
           requires that the solution MUST allow nodes to shed load
           without introducing non-converging oscillations during or
           after an overload condition.

           *Compliant*. The specification offers guidance that
           implementations should apply hysteresis when recovering from
           overload, and avoid sudden ramp ups in offered load when
           recovering.



   REQ 8:  Supporting nodes MUST be able to distinguish current overload
           information from stale information.

           *Partially Compliant*. DOIC overload reports are "soft
           state", that is they expire after an indicated period.  DOIC
           nodes may also send reports that end existing overload
           conditions.  DOIC requires reporting nodes to ensure that all
           relevant reacting nodes receive overload reports.

           However, since DOIC does not allow reports to send OLRs in
           watchdog messages, if an overload condition results in zero
           offered load, the reporting node cannot update the condition
           until the expiration of the original OLR.



   REQ 9:  The solution MUST function across fully loaded as well as
           quiescent transport connections.  This is partially derived
           from the requirement for stability in REQ 7.

           *Not Compliant*. DOIC does not allow OLRs to be sent over
           quiescent transport connections.  This is due to the fact
           that OLRs cannot be sent outside of the application to which
           they apply.



   REQ 10: Consumers of overload information MUST be able to determine
           when the overload condition improves or ends.

           *Partially Compliant*. (See response to previous two
           requirements.)



   REQ 11: The solution MUST be able to operate in networks of different
           sizes.

           *Compliant*. DOIC makes no assumptions about the size of the
           network.  DOIC can operate purely between clients and
           servers, or across agents.



   REQ 12: When a single network node fails, goes into overload, or
           suffers from reduced processing capacity, the solution MUST
           make it possible to limit the impact of the affected node on
           other nodes in the network.  This helps to prevent a small-
           scale failure from becoming a widespread outage.

           *Partially Compliant*. DOIC allows overload reports for an
           entire realm, where abated traffic will not be redirected
           towards another server.  But in situations where nodes choose
           to divert traffic to other nodes, DOIC offers no way of
           knowing whether the new recipients can handle the traffic if
           they have not already indicated overload.  This may be
           mitigated with the use of a future "load" extension, or with
           the use of proprietary dynamic load-balancing mechanisms.



   REQ 13: The solution MUST NOT introduce substantial additional work
           for a node in an overloaded state.  For example, a
           requirement for an overloaded node to send overload
           information every time it received a new request would
           introduce substantial work.

           *Not Compliant*. DOIC does in fact encourage an overloaded
           node to send an OLR in every response.  The working group
           that other mechanisms to ensure that every relevant node
           receives an OLR would create even more work.  [Note: This
           needs discussion.]



   REQ 14: Some scenarios that result in overload involve a rapid
           increase of traffic with little time between normal levels
           and levels that induce overload.  The solution SHOULD provide
           for rapid feedback when traffic levels increase.

           *Compliant*. The piggyback mechanism allows OLRs to be sent
           at the same rate as application traffic.



   REQ 15: The solution MUST NOT interfere with the congestion control
           mechanisms of underlying transport protocols.  For example, a
           solution that opened additional TCP connections when the
           network is congested would reduce the effectiveness of the
           underlying congestion control mechanisms.

           *Compliant*. DOIC does not require or recommend changes in
           the handling of transport protocols or connections.



E.2.3.  Heterogeneous Support for Solution

   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.

           *Partially Compliant*. DOIC works with most mixed-deployment
           scenarios.  However, it cannot work across a non-supporting
           proxy that modifies Origin-Host AVPs in answer messages.
           DOIC will have limited impact in networks where the nodes
           that perform server selections do not support the mechanism.



   REQ 17: In a mixed environment with nodes that support the solution
           and nodes that do not, the solution MUST NOT result in
           materially less useful throughput during overload as would
           have resulted if the solution were not present.  It SHOULD
           result in less severe overload in this environment.

           *Compliant*. In most mixed-support deployment, DOIC will
           offer at least some value, and will not make things worse.



   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.

           *Compliant*. DOIC provides mechanisms to abate load from non-
           supporting sources.  Furthermore, it recommends that
           reporting nodes will still need to be able to apply whatever
           protections they would ordinarily apply if DOIC were not in
           use.



   REQ 19: It MUST be possible to use the solution between nodes in
           different realms and in different administrative domains.

           *Partially Compliant*. DOIC allows sending OLRs across
           administrative domains, and potentially to nodes in other
           realms.  However, an OLR cannot indicate overload for realms
           other than the one in the Origin-Realm AVP of the containing
           answer.



   REQ 20: Any explicit overload indication MUST be clearly
           distinguishable from other errors reported via Diameter.

           *Compliant*. DOIC sends explicit overload indication in
           overload reports.  It does not depend on error result codes.
           [Note: I don't think the resuse of too-busy and unable-to-
           comply for throttled requests impacts this requirement.  Do
           others agree?]



   REQ 21: In cases where a network node fails, is so overloaded that it
           cannot process messages, or cannot communicate due to a
           network failure, it may not be able to provide explicit
           indications of the nature of the failure or its levels of
           overload.  The solution MUST result in at least as much
           useful throughput as would have resulted if the solution were
           not in place.

           *Compliant*. DOIC overload reports have the primary effect of
           suppressing message retries in overload conditions.  DOIC
           recommends that messages never be silently dropped if at all
           possible.



E.2.4.  Granular Control

   REQ 22: The solution MUST provide a way for a node to throttle the
           amount of traffic it receives from a peer node.  This
           throttling SHOULD be graded so that it can be applied
           gradually as offered load increases.  Overload is not a
           binary state; there may be degrees of overload.

           *Compliant*. The "loss" algorithm expresses a percentage
           reduction.



   REQ 23: The solution MUST provide sufficient information to enable a
           load-balancing node to divert messages that are rejected or
           otherwise throttled by an overloaded upstream node to other
           upstream nodes that are the most likely to have sufficient
           capacity to process them.

           *Not Compliant*. DOIC provides no built in mechanism to
           determine the best place to divert messages that would
           otherwise be throttled.  This can be accomplished with a
           future "load" extension, or with proprietary load balancing
           mechanisms.



   REQ 24: The solution MUST provide a mechanism for indicating load
           levels, even when not in an overload condition, to assist
           nodes in making decisions to prevent overload conditions from
           occurring.

           *Not Compliant*. "Load" information has been left for a
           future extension.



E.2.5.  Priority and Policy

   REQ 25: The base specification for the solution SHOULD offer general
           guidance on which message types might be desirable to send or
           process over others during times of overload, based on
           application-specific considerations.  For example, it may be
           more beneficial to process messages for existing sessions
           ahead of new sessions.  Some networks may have a requirement
           to give priority to requests associated with emergency
           sessions.  Any normative or otherwise detailed definition of
           the relative priorities of message types during an overload
           condition will be the responsibility of the application
           specification.

           *Compliant*. The specification offers guidance on how
           requests might be prioritized for different types of
           applications.



   REQ 26: The solution MUST NOT prevent a node from prioritizing
           requests based on any local policy, so that certain requests
           are given preferential treatment, given additional
           retransmission, not throttled, or processed ahead of others.

           *Compliant*. Nothing in the specification prevents
           application-specific, implementation-specific, or local
           policies.



E.2.6.  Security

   REQ 27: The solution MUST NOT provide new vulnerabilities to
           malicious attack or increase the severity of any existing
           vulnerabilities.  This includes vulnerabilities to DoS and
           DDoS attacks as well as replay and man-in-the-middle attacks.
           Note that the Diameter base specification [RFC6733] lacks
           end-to-end security and this must be considered (see the
           Security Considerations in [RFC7068]).  Note that this
           requirement was expressed at a high level so as to not
           preclude any particular solution.  Is is expected that the
           solution will address this in more detail.

           *Compliant*. The working group is not aware of any such
           vulnerabilities.  [This may need further analysis.]



   REQ 28: The solution MUST NOT depend on being deployed in
           environments where all Diameter nodes are completely trusted.
           It SHOULD operate as effectively as possible in environments
           where other nodes are malicious; this includes preventing
           malicious nodes from obtaining more than a fair share of
           service.  Note that this does not imply any responsibility on
           the solution to detect, or take countermeasures against,
           malicious nodes.

           *Partially Compliant*. Since all Diameter security is
           currently at the transport layer, nodes must trust immediate
           peers to enforce trust policies.  However, there are
           situations where a DOIC node cannot determine if an immediate
           peer supports DOIC.  The authors recommend an expert security
           review.



   REQ 29: It MUST be possible for a supporting node to make
           authorization decisions about what information will be sent
           to peer nodes based on the identity of those nodes.  This
           allows a domain administrator who considers the load of their
           nodes to be sensitive information to restrict access to that
           information.  Of course, in such cases, there is no
           expectation that the solution itself will help prevent
           overload from that peer node.

           *Partially Compliant*. (See response to previous
           requirement.)



   REQ 30: The solution MUST NOT interfere with any Diameter-compliant
           method that a node may use to protect itself from overload
           from non-supporting nodes or from denial-of-service attacks.

           *Compliant*. The specification recommends that any such
           protection mechanism needed without DOIC should continue to
           be employed with DOIC.



E.2.7.  Flexibility and Extensibility

   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.

           *Partially Compliant*. All DOIC overload reports are scoped
           to the specific application and realm.  Inside that scope,
           overload can be reported at the specific server or whole
           realm scope.  As currently specified, DOIC cannot indicate
           local overload for an agent.  At the time of this writing,
           the DIME working group has plans to work on an agent-overload
           extension.

           DOIC allows new "scopes" through the use of extended report
           types.



   REQ 32: The solution MUST provide a method for extending the
           information communicated and the algorithms used for overload
           control.

           *Compliant*. DOIC allows new report types and abatement
           algorithms to be created.  These may be indicated using the
           OC-Supported-Features AVP.



   REQ 33: The solution MUST provide a default algorithm that is
           mandatory to implement.

           *Compliant*. The "loss" algorithm is mandatory to implement.



   REQ 34: The solution SHOULD provide a method for exchanging overload
           and load information between elements that are connected by
           intermediaries that do not support the solution.

           *Partially Compliant*. DOIC information can traverse non-
           supporting agents, as long as those agents do not modify
           certain AVPs. (e.g., Origin-Host).  DOIC does not provide a
           way for supporting nodes to detect such modification.


--------------010004060709060909030802-- From nobody Fri Nov 7 08:38: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 A7EEB1A87EF for ; Fri, 7 Nov 2014 08:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvspReHZsBbe for ; Fri, 7 Nov 2014 08:38:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AF71A87D1 for ; Fri, 7 Nov 2014 08:37:54 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA7GbmMF041053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2014 10:37: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.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <545C7EA8.6070706@cisco.com> Date: Fri, 7 Nov 2014 10:37:48 -0600 X-Mao-Original-Outgoing-Id: 437071068.299379-cd5f34a0494bb36ffd2ecc52a22e4e65 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> <545C7EA8.6070706@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/A65fo5DXGf_QU1o8OCXuWtCFCNA Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:38:22 -0000 Hi Benoit,=20 I will remove that. I had mixed emotions about putting it in, since I don't know if we want = the detailed sections to stay in the RFC. But the way the summary is = currently structured, it just mentions requirements by number and = depends on the detailed section for, well, details. So my personal = inclination is to have all of Appendix E stay in the RFC. Otherwise, we = would probably need to add more detail to the summary. Does anyone else have thoughts on this? Thanks! Ben. > On Nov 7, 2014, at 2:11 AM, Benoit Claise wrote: >=20 > Hi Ben, >=20 > I believe that the E1, at least, must be part of draft. I'm referring = to > [RFC EDITOR: Please remove this section prior to publication as an > RFC.] >=20 > For E2, up to the WG to decide. >=20 >=20 > Regards, Benoit >>=20 >>> On Nov 3, 2014, at 11:43 AM, Benoit Claise = wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for your detailed analysis. >>> While this is good, what is required is the justification of why = some requirements are not met with DOIC and why have you decided to = postpone some RFC 7068 requirements? Then you can list those = requirements. >>>=20 >>=20 >> Hi Benoit, >>=20 >> Here's an updated version with a "summary" section at the front. = Hopefully this captures what you are looking for.=20 >>=20 >> I've put this in version 05 in a branch in GitHub. If no one objects = in the next few days, I will send a pull request to merge it into the = main branch. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> ---------------------- >>=20 >> Appendix E. Requirements Analysis >>=20 >> [RFC EDITOR: Please remove this section prior to publication as an >> RFC.] >>=20 >> This section analyzes the mechanism described in this document >> against the set of requirements detailed in [RFC7068]. >>=20 >> E.1. Requirements Summary >>=20 >> This section summarizes areas where DOIC partially complies or = does >> not comply with certain requirements. Please see Appendix E.2 for >> the text of each requirement. >>=20 >> The following requirements have been deferred for future work, due = to >> schedule constraints (3GPP CT4 needs to reference basic overload >> control for release 12): >>=20 >> o Requirements 1 (partial), 12 (partial), 23, and 24 - DOIC does = not >> currently support conveyance of load information when not >> otherwise overloaded. >>=20 >> o Requirements 1 (partial), and 31 (partial) - DOIC does not >> currently allow the reporting of an overloaded agent. (DIME = has a >> separate milestone for agent overload.) >>=20 >> The following requirements could not be met due to certain working >> group decisions: >>=20 >> o Requirements 6 (partial), 16 (partial), 28 (partial), 29 = (partial) >> and 34 (partial). - The working group elected not to add a way = to >> determine that non-supporting node exists between two DOIC >> supporting nodes. >>=20 >> o Requirements 8 (partial), 9, 10 (partial), 19 (partial), and 34 >> (partial) - The application and server or realm to which an OLR >> applies is determined by the Application-Id and Origin-Realm = AVPs >> of the enclosing answer. If a node that doesn't understand = DOIC >> modifies certain AVPs in the enclosing answer, the OLR will = become >> invalid, without a way for downstream nodes to detect it. It = is >> currently not possible to construct an OLR that refers to an >> application, server, or realm different from that of the answer >> that carries it. >>=20 >> o Requirement 13: While the requirement discourages sending OLRs = in >> every response, the working group decided that not doing that >> would be less reliable, and require more stateful behavior. = (Note >> that the document allows reporting nodes to avoid sending OLRs = in >> every response if the node has some other way of determining = that >> all relevant reacting nodes receive the report.) >>=20 >> o The working group believes that DOIC is compliant with = requirement >> 27 (no new vulnerabilities). However, this may warrant an = early >> review from a security expert. >>=20 >> E.2. Detailed Requirements >>=20 >> E.2.1. General >>=20 >> REQ 1: The solution MUST provide a communication method for = Diameter >> nodes to exchange load and overload information. >>=20 >> *Partially Compliant*. The mechanism uses new AVPs >> piggybacked on existing Diameter messages to exchange >> overload information. It does not currently support = "load" >> information or the ability to report overload of an agent. >> These have been left for future extensions. >>=20 >>=20 >>=20 >> REQ 2: The solution MUST allow Diameter nodes to support overload >> control regardless of which Diameter applications they >> support. Diameter clients and agents must be able to use = the >> received load and overload information to support graceful >> behavior during an overload condition. Graceful behavior >> under overload conditions is best described by REQ 3. >>=20 >> *Compliant*. The DOIC AVPs can be used in any application >> that allows the extension of AVPs. >>=20 >>=20 >>=20 >> REQ 3: The solution MUST limit the impact of overload on the = overall >> useful throughput of a Diameter server, even when the >> incoming load on the network is far in excess of its >> capacity. The overall useful throughput under load is the >> ultimate measure of the value of a solution. >>=20 >> *Compliant*. DOIC provides information that nodes can use = to >> reduce the impact of overload. >>=20 >>=20 >>=20 >> REQ 4: Diameter allows requests to be sent from either side of a >> connection, and either side of a connection may have need = to >> provide its overload status. The solution MUST allow each >> side of a connection to independently inform the other of = its >> overload status. >>=20 >> *Compliant*. DOIC AVPs can be included regardless of >> transaction "direction" >>=20 >>=20 >>=20 >> REQ 5: Diameter allows nodes to determine their peers via dynamic >> discovery or manual configuration. The solution MUST work >> consistently without regard to how peers are determined. >>=20 >> *Compliant*. DOIC contains no assumptions about how peers = are >> discovered. [Note: This may require further study] >>=20 >>=20 >>=20 >> REQ 6: The solution designers SHOULD seek to minimize the amount = of >> new configuration required in order to work. For example, = it >> is better to allow peers to advertise or negotiate support >> for the solution, rather than to require that this = knowledge >> to be configured at each node. >>=20 >> *Partially Compliant*. Most DOIC parameters are advertised >> using the DOIC capability announcement mechanism. = However, >> there are some situations where configuration is required. >> For example, a DOIC node detect the fact that a peer may = not >> support DOIC when nodes on the other side of the non- >> supporting node do support DOIC without configuration. >>=20 >>=20 >>=20 >> E.2.2. Performance >>=20 >> REQ 7: The solution and any associated default algorithm(s) MUST >> ensure that the system remains stable. At some point = after >> an overload condition has ended, the solution MUST enable >> capacity to stabilize and become equal to what it would be = in >> the absence of an overload condition. Note that this also >> requires that the solution MUST allow nodes to shed load >> without introducing non-converging oscillations during or >> after an overload condition. >>=20 >> *Compliant*. The specification offers guidance that >> implementations should apply hysteresis when recovering = from >> overload, and avoid sudden ramp ups in offered load when >> recovering. >>=20 >>=20 >>=20 >> REQ 8: Supporting nodes MUST be able to distinguish current = overload >> information from stale information. >>=20 >> *Partially Compliant*. DOIC overload reports are "soft >> state", that is they expire after an indicated period. = DOIC >> nodes may also send reports that end existing overload >> conditions. DOIC requires reporting nodes to ensure that = all >> relevant reacting nodes receive overload reports. >>=20 >> However, since DOIC does not allow reports to send OLRs in >> watchdog messages, if an overload condition results in = zero >> offered load, the reporting node cannot update the = condition >> until the expiration of the original OLR. >>=20 >>=20 >>=20 >> REQ 9: The solution MUST function across fully loaded as well as >> quiescent transport connections. This is partially = derived >> from the requirement for stability in REQ 7. >>=20 >> *Not Compliant*. DOIC does not allow OLRs to be sent over >> quiescent transport connections. This is due to the fact >> that OLRs cannot be sent outside of the application to = which >> they apply. >>=20 >>=20 >>=20 >> REQ 10: Consumers of overload information MUST be able to = determine >> when the overload condition improves or ends. >>=20 >> *Partially Compliant*. (See response to previous two >> requirements.) >>=20 >>=20 >>=20 >> REQ 11: The solution MUST be able to operate in networks of = different >> sizes. >>=20 >> *Compliant*. DOIC makes no assumptions about the size of = the >> network. DOIC can operate purely between clients and >> servers, or across agents. >>=20 >>=20 >>=20 >> REQ 12: When a single network node fails, goes into overload, or >> suffers from reduced processing capacity, the solution = MUST >> make it possible to limit the impact of the affected node = on >> other nodes in the network. This helps to prevent a = small- >> scale failure from becoming a widespread outage. >>=20 >> *Partially Compliant*. DOIC allows overload reports for an >> entire realm, where abated traffic will not be redirected >> towards another server. But in situations where nodes = choose >> to divert traffic to other nodes, DOIC offers no way of >> knowing whether the new recipients can handle the traffic = if >> they have not already indicated overload. This may be >> mitigated with the use of a future "load" extension, or = with >> the use of proprietary dynamic load-balancing mechanisms. >>=20 >>=20 >>=20 >> REQ 13: The solution MUST NOT introduce substantial additional = work >> for a node in an overloaded state. For example, a >> requirement for an overloaded node to send overload >> information every time it received a new request would >> introduce substantial work. >>=20 >> *Not Compliant*. DOIC does in fact encourage an overloaded >> node to send an OLR in every response. The working group >> that other mechanisms to ensure that every relevant node >> receives an OLR would create even more work. [Note: This >> needs discussion.] >>=20 >>=20 >>=20 >> REQ 14: Some scenarios that result in overload involve a rapid >> increase of traffic with little time between normal levels >> and levels that induce overload. The solution SHOULD = provide >> for rapid feedback when traffic levels increase. >>=20 >> *Compliant*. The piggyback mechanism allows OLRs to be = sent >> at the same rate as application traffic. >>=20 >>=20 >>=20 >> REQ 15: The solution MUST NOT interfere with the congestion = control >> mechanisms of underlying transport protocols. For = example, a >> solution that opened additional TCP connections when the >> network is congested would reduce the effectiveness of the >> underlying congestion control mechanisms. >>=20 >> *Compliant*. DOIC does not require or recommend changes in >> the handling of transport protocols or connections. >>=20 >>=20 >>=20 >> E.2.3. Heterogeneous Support for Solution >>=20 >> 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. >>=20 >> *Partially Compliant*. DOIC works with most = mixed-deployment >> scenarios. However, it cannot work across a = non-supporting >> proxy that modifies Origin-Host AVPs in answer messages. >> DOIC will have limited impact in networks where the nodes >> that perform server selections do not support the = mechanism. >>=20 >>=20 >>=20 >> REQ 17: In a mixed environment with nodes that support the = solution >> and nodes that do not, the solution MUST NOT result in >> materially less useful throughput during overload as would >> have resulted if the solution were not present. It SHOULD >> result in less severe overload in this environment. >>=20 >> *Compliant*. In most mixed-support deployment, DOIC will >> offer at least some value, and will not make things worse. >>=20 >>=20 >>=20 >> 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. >>=20 >> *Compliant*. DOIC provides mechanisms to abate load from = non- >> supporting sources. Furthermore, it recommends that >> reporting nodes will still need to be able to apply = whatever >> protections they would ordinarily apply if DOIC were not = in >> use. >>=20 >>=20 >>=20 >> REQ 19: It MUST be possible to use the solution between nodes in >> different realms and in different administrative domains. >>=20 >> *Partially Compliant*. DOIC allows sending OLRs across >> administrative domains, and potentially to nodes in other >> realms. However, an OLR cannot indicate overload for = realms >> other than the one in the Origin-Realm AVP of the = containing >> answer. >>=20 >>=20 >>=20 >> REQ 20: Any explicit overload indication MUST be clearly >> distinguishable from other errors reported via Diameter. >>=20 >> *Compliant*. DOIC sends explicit overload indication in >> overload reports. It does not depend on error result = codes. >> [Note: I don't think the resuse of too-busy and unable-to- >> comply for throttled requests impacts this requirement. = Do >> others agree?] >>=20 >>=20 >>=20 >> REQ 21: In cases where a network node fails, is so overloaded that = it >> cannot process messages, or cannot communicate due to a >> network failure, it may not be able to provide explicit >> indications of the nature of the failure or its levels of >> overload. The solution MUST result in at least as much >> useful throughput as would have resulted if the solution = were >> not in place. >>=20 >> *Compliant*. DOIC overload reports have the primary effect = of >> suppressing message retries in overload conditions. DOIC >> recommends that messages never be silently dropped if at = all >> possible. >>=20 >>=20 >>=20 >> E.2.4. Granular Control >>=20 >> REQ 22: The solution MUST provide a way for a node to throttle the >> amount of traffic it receives from a peer node. This >> throttling SHOULD be graded so that it can be applied >> gradually as offered load increases. Overload is not a >> binary state; there may be degrees of overload. >>=20 >> *Compliant*. The "loss" algorithm expresses a percentage >> reduction. >>=20 >>=20 >>=20 >> REQ 23: The solution MUST provide sufficient information to enable = a >> load-balancing node to divert messages that are rejected = or >> otherwise throttled by an overloaded upstream node to = other >> upstream nodes that are the most likely to have sufficient >> capacity to process them. >>=20 >> *Not Compliant*. DOIC provides no built in mechanism to >> determine the best place to divert messages that would >> otherwise be throttled. This can be accomplished with a >> future "load" extension, or with proprietary load = balancing >> mechanisms. >>=20 >>=20 >>=20 >> REQ 24: The solution MUST provide a mechanism for indicating load >> levels, even when not in an overload condition, to assist >> nodes in making decisions to prevent overload conditions = from >> occurring. >>=20 >> *Not Compliant*. "Load" information has been left for a >> future extension. >>=20 >>=20 >>=20 >> E.2.5. Priority and Policy >>=20 >> REQ 25: The base specification for the solution SHOULD offer = general >> guidance on which message types might be desirable to send = or >> process over others during times of overload, based on >> application-specific considerations. For example, it may = be >> more beneficial to process messages for existing sessions >> ahead of new sessions. Some networks may have a = requirement >> to give priority to requests associated with emergency >> sessions. Any normative or otherwise detailed definition = of >> the relative priorities of message types during an = overload >> condition will be the responsibility of the application >> specification. >>=20 >> *Compliant*. The specification offers guidance on how >> requests might be prioritized for different types of >> applications. >>=20 >>=20 >>=20 >> REQ 26: The solution MUST NOT prevent a node from prioritizing >> requests based on any local policy, so that certain = requests >> are given preferential treatment, given additional >> retransmission, not throttled, or processed ahead of = others. >>=20 >> *Compliant*. Nothing in the specification prevents >> application-specific, implementation-specific, or local >> policies. >>=20 >>=20 >>=20 >> E.2.6. Security >>=20 >> REQ 27: The solution MUST NOT provide new vulnerabilities to >> malicious attack or increase the severity of any existing >> vulnerabilities. This includes vulnerabilities to DoS and >> DDoS attacks as well as replay and man-in-the-middle = attacks. >> Note that the Diameter base specification [RFC6733] lacks >> end-to-end security and this must be considered (see the >> Security Considerations in [RFC7068]). Note that this >> requirement was expressed at a high level so as to not >> preclude any particular solution. Is is expected that the >> solution will address this in more detail. >>=20 >> *Compliant*. The working group is not aware of any such >> vulnerabilities. [This may need further analysis.] >>=20 >>=20 >>=20 >> REQ 28: The solution MUST NOT depend on being deployed in >> environments where all Diameter nodes are completely = trusted. >> It SHOULD operate as effectively as possible in = environments >> where other nodes are malicious; this includes preventing >> malicious nodes from obtaining more than a fair share of >> service. Note that this does not imply any responsibility = on >> the solution to detect, or take countermeasures against, >> malicious nodes. >>=20 >> *Partially Compliant*. Since all Diameter security is >> currently at the transport layer, nodes must trust = immediate >> peers to enforce trust policies. However, there are >> situations where a DOIC node cannot determine if an = immediate >> peer supports DOIC. The authors recommend an expert = security >> review. >>=20 >>=20 >>=20 >> REQ 29: It MUST be possible for a supporting node to make >> authorization decisions about what information will be = sent >> to peer nodes based on the identity of those nodes. This >> allows a domain administrator who considers the load of = their >> nodes to be sensitive information to restrict access to = that >> information. Of course, in such cases, there is no >> expectation that the solution itself will help prevent >> overload from that peer node. >>=20 >> *Partially Compliant*. (See response to previous >> requirement.) >>=20 >>=20 >>=20 >> REQ 30: The solution MUST NOT interfere with any = Diameter-compliant >> method that a node may use to protect itself from overload >> from non-supporting nodes or from denial-of-service = attacks. >>=20 >> *Compliant*. The specification recommends that any such >> protection mechanism needed without DOIC should continue = to >> be employed with DOIC. >>=20 >>=20 >>=20 >> E.2.7. Flexibility and Extensibility >>=20 >> 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. >>=20 >> *Partially Compliant*. All DOIC overload reports are = scoped >> to the specific application and realm. Inside that scope, >> overload can be reported at the specific server or whole >> realm scope. As currently specified, DOIC cannot indicate >> local overload for an agent. At the time of this writing, >> the DIME working group has plans to work on an = agent-overload >> extension. >>=20 >> DOIC allows new "scopes" through the use of extended = report >> types. >>=20 >>=20 >>=20 >> REQ 32: The solution MUST provide a method for extending the >> information communicated and the algorithms used for = overload >> control. >>=20 >> *Compliant*. DOIC allows new report types and abatement >> algorithms to be created. These may be indicated using = the >> OC-Supported-Features AVP. >>=20 >>=20 >>=20 >> REQ 33: The solution MUST provide a default algorithm that is >> mandatory to implement. >>=20 >> *Compliant*. The "loss" algorithm is mandatory to = implement. >>=20 >>=20 >>=20 >> REQ 34: The solution SHOULD provide a method for exchanging = overload >> and load information between elements that are connected = by >> intermediaries that do not support the solution. >>=20 >> *Partially Compliant*. DOIC information can traverse non- >> supporting agents, as long as those agents do not modify >> certain AVPs. (e.g., Origin-Host). DOIC does not provide = a >> way for supporting nodes to detect such modification. >>=20 >>=20 >=20 From nobody Fri Nov 7 21: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 D506B1A0275 for ; Fri, 7 Nov 2014 21:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 myF9TwKcdwAB for ; Fri, 7 Nov 2014 21:17:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EE61A01C6 for ; Fri, 7 Nov 2014 21:17:31 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id F091B3B4198; Sat, 8 Nov 2014 06:17:29 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id C931E1580AE; Sat, 8 Nov 2014 06:17:29 +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.0210.002; Sat, 8 Nov 2014 06:17:29 +0100 From: To: "dime@ietf.org" Thread-Topic: Offline discussion on Overload/load control mechanism during IETF#91 Thread-Index: Ac/7Ev9PHx0gXXhUSnO+NIUyg4hsbA== Date: Sat, 8 Nov 2014 05:17:28 +0000 Message-ID: <8682_1415423849_545DA769_8682_18165_1_6B7134B31289DC4FAF731D844122B36E8ABA96@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.4] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E8ABA96PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.7.111519 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1kbIHPY9XyJ2IDKo9W1a_GginQY Subject: [Dime] Offline discussion on Overload/load control mechanism during IETF#91 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 05:17:35 -0000 --_000_6B7134B31289DC4FAF731D844122B36E8ABA96PEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An offline discussion on overload/load control mechanism will be organized = on Wed, Nov 12, in "South Pacific 2" meeting room, from 9am to 12am. The aim of this discussion is to close any possible pending open issue on t= he Diameter Overload draft and initiate discussion on load control mechanis= m. This offline discussion is open to any people interested by these topics. Of course, no official position/decision will be taken during this meeting = and any proposed decision/way forward will be discussed on the official Dim= e mailing list. Regards, Lionel & Jouni ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E8ABA96PEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An offline discussion on overlo= ad/load control mechanism will be organized on Wed, Nov 12, in "South = Pacific 2" meeting room, from 9am to 12am.

The aim of this discussion is t= o close any possible pending open issue on the Diameter Overload draft and = initiate discussion on load control mechanism.

 

This offline discussion is open= to any people interested by these topics.

Of course, no official position= /decision will be taken during this meeting and any proposed decision/way f= orward will be discussed on the official Dime mailing list.

 

Regards,

 

Lionel & Jouni

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E8ABA96PEXCVZYM13corpora_-- From nobody Sat Nov 8 17:16: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 E56921A005A for ; Sat, 8 Nov 2014 17:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNZYP-HoudQT for ; Sat, 8 Nov 2014 17:16:49 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4421A0030 for ; Sat, 8 Nov 2014 17:16:46 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-39-545ec07cbfea Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.7C.04231.C70CE545; Sun, 9 Nov 2014 02:16:44 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.145]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Sun, 9 Nov 2014 02:16:44 +0100 From: Maria Cruz Bartolome To: Benoit Claise , Ben Campbell , "dime@ietf.org list" Thread-Topic: [Dime] DOIC Requirements Analysis Thread-Index: AQHP+hdkYaHIAJGIfEKORBGRlKAhiZxUv+AAgAJDs/A= Date: Sun, 9 Nov 2014 01:16:43 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920985724A@ESESSMB101.ericsson.se> References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> <545C7EA8.6070706@cisco.com> In-Reply-To: <545C7EA8.6070706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/mixed; boundary="_004_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM+JvjW7NgbgQgy1zNS2OPpawmN95mt1i bu8KNgdmjym/N7J6LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZW++9ZCto2cle8bnnCFMD Y/NJti5GTg4JAROJ3ctWM0LYYhIX7q0HinNxCAkcYZTYfaqJBcJZzChxcdcvdpAqNgE7iUun XzCB2CICuRIHlz1hBrGFBfQkXuw7ww4R15e4cXcxM4RtJfFndgfYNhYBFYntG0+B1fAK+Ers 2/IczBYS2MgocbzXFsTmFNCUWPr6BthFjEAXfT+1BmwXs4C4xK0n85kgLhWReHjxNNQHohIv H/9jhbCVJNYe3s4CUZ8p0Xf8PdQuQYmTM5+wTGAUmYVk1CwkZbOQlEHE8yWmzVgAZetILNj9 iQ3C1pZYtvA1M4x95sBjJkzxaonWufOgeg0ktr0/CmRzAdk7GSXm/DnJCJFQlJjS/ZB9ASPP KkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzASD+45bfuDsbVrx0PMQpwMCrx8Bq0x4YIsSaW FVfmHmKU5mBREudddG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGFRmNeQedL9Z0hJTK JsWeECzxV+H6XCsgaCpyjH9eUXioizHv9tULQhycvi0sV4u2ElJJK1qh0/qt5+Ib3k1sjf0v A3b6tjBsehr+74TSzoRnvGofHbMl6tX6DHRSNvUIsh5jcctwO6f52PNX6uYGnds1dV4CoTkz 1Xe96apeE/coif2NgBJLcUaioRZzUXEiAAzRhHDVAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/FVzTeX32QD6zS4kFDJTDw4ikj_o Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 01:16:56 -0000 --_004_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_ Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_" --_000_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Ben, See my comments inserted in attached doc. Thanks /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Benoit Claise Sent: viernes, 07 de noviembre de 2014 9:11 To: Ben Campbell Cc: dime@ietf.org list Subject: Re: [Dime] DOIC Requirements Analysis Hi Ben, I believe that the E1, at least, must be part of draft. I'm referring to [RFC EDITOR: Please remove this section prior to publication as an RFC.] For E2, up to the WG to decide. Regards, Benoit On Nov 3, 2014, at 11:43 AM, Benoit Claise > wrote: Hi Ben, Thanks for your detailed analysis. While this is good, what is required is the justification of why some requi= rements are not met with DOIC and why have you decided to postpone some RFC= 7068 requirements? Then you can list those requirements. Hi Benoit, Here's an updated version with a "summary" section at the front. Hopefully = this captures what you are looking for. I've put this in version 05 in a branch in GitHub. If no one objects in the= next few days, I will send a pull request to merge it into the main branch= . Thanks! Ben. ---------------------- Appendix E. Requirements Analysis [RFC EDITOR: Please remove this section prior to publication as an RFC.] This section analyzes the mechanism described in this document against the set of requirements detailed in [RFC7068]. E.1. Requirements Summary This section summarizes areas where DOIC partially complies or does not comply with certain requirements. Please see Appendix E.2 for the text of each requirement. The following requirements have been deferred for future work, due to schedule constraints (3GPP CT4 needs to reference basic overload control for release 12): o Requirements 1 (partial), 12 (partial), 23, and 24 - DOIC does not currently support conveyance of load information when not otherwise overloaded. o Requirements 1 (partial), and 31 (partial) - DOIC does not currently allow the reporting of an overloaded agent. (DIME has a separate milestone for agent overload.) The following requirements could not be met due to certain working group decisions: o Requirements 6 (partial), 16 (partial), 28 (partial), 29 (partial) and 34 (partial). - The working group elected not to add a way to determine that non-supporting node exists between two DOIC supporting nodes. o Requirements 8 (partial), 9, 10 (partial), 19 (partial), and 34 (partial) - The application and server or realm to which an OLR applies is determined by the Application-Id and Origin-Realm AVPs of the enclosing answer. If a node that doesn't understand DOIC modifies certain AVPs in the enclosing answer, the OLR will become invalid, without a way for downstream nodes to detect it. It is currently not possible to construct an OLR that refers to an application, server, or realm different from that of the answer that carries it. o Requirement 13: While the requirement discourages sending OLRs in every response, the working group decided that not doing that would be less reliable, and require more stateful behavior. (Note that the document allows reporting nodes to avoid sending OLRs in every response if the node has some other way of determining that all relevant reacting nodes receive the report.) o The working group believes that DOIC is compliant with requirement 27 (no new vulnerabilities). However, this may warrant an early review from a security expert. E.2. Detailed Requirements E.2.1. General REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. *Partially Compliant*. The mechanism uses new AVPs piggybacked on existing Diameter messages to exchange overload information. It does not currently support "load" information or the ability to report overload of an agent. These have been left for future extensions. REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3. *Compliant*. The DOIC AVPs can be used in any application that allows the extension of AVPs. REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity. The overall useful throughput under load is the ultimate measure of the value of a solution. *Compliant*. DOIC provides information that nodes can use to reduce the impact of overload. REQ 4: Diameter allows requests to be sent from either side of a connection, and either side of a connection may have need to provide its overload status. The solution MUST allow each side of a connection to independently inform the other of its overload status. *Compliant*. DOIC AVPs can be included regardless of transaction "direction" REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined. *Compliant*. DOIC contains no assumptions about how peers are discovered. [Note: This may require further study] REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge to be configured at each node. *Partially Compliant*. Most DOIC parameters are advertised using the DOIC capability announcement mechanism. However, there are some situations where configuration is required. For example, a DOIC node detect the fact that a peer may not support DOIC when nodes on the other side of the non- supporting node do support DOIC without configuration. E.2.2. Performance REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition. *Compliant*. The specification offers guidance that implementations should apply hysteresis when recovering from overload, and avoid sudden ramp ups in offered load when recovering. REQ 8: Supporting nodes MUST be able to distinguish current overload information from stale information. *Partially Compliant*. DOIC overload reports are "soft state", that is they expire after an indicated period. DOIC nodes may also send reports that end existing overload conditions. DOIC requires reporting nodes to ensure that all relevant reacting nodes receive overload reports. However, since DOIC does not allow reports to send OLRs in watchdog messages, if an overload condition results in zero offered load, the reporting node cannot update the condition until the expiration of the original OLR. REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections. This is partially derived from the requirement for stability in REQ 7. *Not Compliant*. DOIC does not allow OLRs to be sent over quiescent transport connections. This is due to the fact that OLRs cannot be sent outside of the application to which they apply. REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends. *Partially Compliant*. (See response to previous two requirements.) REQ 11: The solution MUST be able to operate in networks of different sizes. *Compliant*. DOIC makes no assumptions about the size of the network. DOIC can operate purely between clients and servers, or across agents. REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small- scale failure from becoming a widespread outage. *Partially Compliant*. DOIC allows overload reports for an entire realm, where abated traffic will not be redirected towards another server. But in situations where nodes choose to divert traffic to other nodes, DOIC offers no way of knowing whether the new recipients can handle the traffic if they have not already indicated overload. This may be mitigated with the use of a future "load" extension, or with the use of proprietary dynamic load-balancing mechanisms. REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work. *Not Compliant*. DOIC does in fact encourage an overloaded node to send an OLR in every response. The working group that other mechanisms to ensure that every relevant node receives an OLR would create even more work. [Note: This needs discussion.] REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase. *Compliant*. The piggyback mechanism allows OLRs to be sent at the same rate as application traffic. REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms. *Compliant*. DOIC does not require or recommend changes in the handling of transport protocols or connections. E.2.3. Heterogeneous Support for Solution 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. *Partially Compliant*. DOIC works with most mixed-deployment scenarios. However, it cannot work across a non-supporting proxy that modifies Origin-Host AVPs in answer messages. DOIC will have limited impact in networks where the nodes that perform server selections do not support the mechanism. REQ 17: In a mixed environment with nodes that support the solution and nodes that do not, the solution MUST NOT result in materially less useful throughput during overload as would have resulted if the solution were not present. It SHOULD result in less severe overload in this environment. *Compliant*. In most mixed-support deployment, DOIC will offer at least some value, and will not make things worse. 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. *Compliant*. DOIC provides mechanisms to abate load from non- supporting sources. Furthermore, it recommends that reporting nodes will still need to be able to apply whatever protections they would ordinarily apply if DOIC were not in use. REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains. *Partially Compliant*. DOIC allows sending OLRs across administrative domains, and potentially to nodes in other realms. However, an OLR cannot indicate overload for realms other than the one in the Origin-Realm AVP of the containing answer. REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter. *Compliant*. DOIC sends explicit overload indication in overload reports. It does not depend on error result codes. [Note: I don't think the resuse of too-busy and unable-to- comply for throttled requests impacts this requirement. Do others agree?] REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of overload. The solution MUST result in at least as much useful throughput as would have resulted if the solution were not in place. *Compliant*. DOIC overload reports have the primary effect of suppressing message retries in overload conditions. DOIC recommends that messages never be silently dropped if at all possible. E.2.4. Granular Control REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node. This throttling SHOULD be graded so that it can be applied gradually as offered load increases. Overload is not a binary state; there may be degrees of overload. *Compliant*. The "loss" algorithm expresses a percentage reduction. REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. *Not Compliant*. DOIC provides no built in mechanism to determine the best place to divert messages that would otherwise be throttled. This can be accomplished with a future "load" extension, or with proprietary load balancing mechanisms. REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring. *Not Compliant*. "Load" information has been left for a future extension. E.2.5. Priority and Policy REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be desirable to send or process over others during times of overload, based on application-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition will be the responsibility of the application specification. *Compliant*. The specification offers guidance on how requests might be prioritized for different types of applications. REQ 26: The solution MUST NOT prevent a node from prioritizing requests based on any local policy, so that certain requests are given preferential treatment, given additional retransmission, not throttled, or processed ahead of others. *Compliant*. Nothing in the specification prevents application-specific, implementation-specific, or local policies. E.2.6. Security REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack or increase the severity of any existing vulnerabilities. This includes vulnerabilities to DoS and DDoS attacks as well as replay and man-in-the-middle attacks. Note that the Diameter base specification [RFC6733] lacks end-to-end security and this must be considered (see the Security Considerations in [RFC7068]). Note that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail. *Compliant*. The working group is not aware of any such vulnerabilities. [This may need further analysis.] REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes. *Partially Compliant*. Since all Diameter security is currently at the transport layer, nodes must trust immediate peers to enforce trust policies. However, there are situations where a DOIC node cannot determine if an immediate peer supports DOIC. The authors recommend an expert security review. REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node. *Partially Compliant*. (See response to previous requirement.) REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks. *Compliant*. The specification recommends that any such protection mechanism needed without DOIC should continue to be employed with DOIC. E.2.7. Flexibility and Extensibility 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. *Partially Compliant*. All DOIC overload reports are scoped to the specific application and realm. Inside that scope, overload can be reported at the specific server or whole realm scope. As currently specified, DOIC cannot indicate local overload for an agent. At the time of this writing, the DIME working group has plans to work on an agent-overload extension. DOIC allows new "scopes" through the use of extended report types. REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control. *Compliant*. DOIC allows new report types and abatement algorithms to be created. These may be indicated using the OC-Supported-Features AVP. REQ 33: The solution MUST provide a default algorithm that is mandatory to implement. *Compliant*. The "loss" algorithm is mandatory to implement. REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution. *Partially Compliant*. DOIC information can traverse non- supporting agents, as long as those agents do not modify certain AVPs. (e.g., Origin-Host). DOIC does not provide a way for supporting nodes to detect such modification. --_000_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Ben,

 <= /p>

See my comments inserted = in attached doc.

Thanks<= /p>

/MCruz<= /p>

 <= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: viernes, 07 de noviembre de 2014 9:11
To: Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] DOIC Requirements Analysis

 

Hi Ben,

I believe that the E1, at least, must be part of draft. I'm referring to 

   [RFC EDITOR: Please remove this section prior to publicat=
ion as an
   RFC.]

For E2, up to the WG to decide.


Regards, Benoit

 

On Nov 3, 2014, at 11= :43 AM, Benoit Claise <bclaise@cisc= o.com> wrote:

Hi Ben,

Thanks for your detailed analysis.
While this is good, what is required is the justification of why some = requirements are not met with DOIC and why have you decided to postpon= e some RFC 7068 requirements? Then you can list those requirement= s.

 

Hi Benoit,

Here's an updated version with a "summary" section at the front. = Hopefully this captures what you are looking for. 

I've put this in version 05 in a branch in GitHub. If no one objects in the= next few days, I will send a pull request to merge it into the main branch= .

Thanks!

Ben.

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

 

Appendix E. =
 Requirements Analysis
 
   [RFC EDITOR: Please remove this section prior to publicat=
ion as an
   RFC.]
 
   This section analyzes the mechanism described in this doc=
ument
   against the set of requirements detailed in [RFC7068].
 
E.1.  Requirements Summary
 
   This section summarizes areas where DOIC partially compli=
es or does
   not comply with certain requirements.  Please see Ap=
pendix E.2 for
   the text of each requirement.
 
   The following requirements have been deferred for future =
work, due to
   schedule constraints (3GPP CT4 needs to reference basic o=
verload
   control for release 12):
 
   o  Requirements 1 (partial), 12 (partial), 23, and 2=
4 - DOIC does not
      currently support conveyance of load in=
formation when not
      otherwise overloaded.
 
   o  Requirements 1 (partial), and 31 (partial) - DOIC=
 does not
      currently allow the reporting of an ove=
rloaded agent.  (DIME has a
      separate milestone for agent overload.)=

 
   The following requirements could not be met due to certai=
n working
   group decisions:
 
   o  Requirements 6 (partial), 16 (partial), 28 (parti=
al), 29 (partial)
      and 34 (partial). - The working group e=
lected not to add a way to
      determine that non-supporting node exis=
ts between two DOIC
      supporting nodes.
 
   o  Requirements 8 (partial), 9, 10 (partial), 19 (pa=
rtial), and 34
      (partial) - The application and server =
or realm to which an OLR
      applies is determined by the Applicatio=
n-Id and Origin-Realm AVPs
      of the enclosing answer.  If a nod=
e that doesn't understand DOIC
      modifies certain AVPs in the enclosing =
answer, the OLR will become
      invalid, without a way for downstream n=
odes to detect it.  It is
      currently not possible to construct an =
OLR that refers to an
      application, server, or realm different=
 from that of the answer
      that carries it.
 
   o  Requirement 13: While the requirement discourages=
 sending OLRs in
      every response, the working group decid=
ed that not doing that
      would be less reliable, and require mor=
e stateful behavior.  (Note
      that the document allows reporting node=
s to avoid sending OLRs in
      every response if the node has some oth=
er way of determining that
      all relevant reacting nodes receive the=
 report.)
 
   o  The working group believes that DOIC is compliant=
 with requirement
      27 (no new vulnerabilities).  Howe=
ver, this may warrant an early
      review from a security expert.
 
E.2.  Detailed Requirements
 
E.2.1.  General
 
   REQ 1:  The solution MUST provide a communication me=
thod for Diameter
           nodes to =
exchange load and overload information.
 
           *Partiall=
y Compliant*. The mechanism uses new AVPs
           piggyback=
ed on existing Diameter messages to exchange
           overload =
information.  It does not currently support "load"
           informati=
on or the ability to report overload of an agent.
           These hav=
e been left for future extensions.
 
 
 
   REQ 2:  The solution MUST allow Diameter nodes to su=
pport overload
           control r=
egardless of which Diameter applications they
           support.&=
nbsp; Diameter clients and agents must be able to use the
           received =
load and overload information to support graceful
           behavior =
during an overload condition.  Graceful behavior
           under ove=
rload conditions is best described by REQ 3.
 
           *Complian=
t*. The DOIC AVPs can be used in any application
           that allo=
ws the extension of AVPs.
 
 
 
   REQ 3:  The solution MUST limit the impact of overlo=
ad on the overall
           useful th=
roughput of a Diameter server, even when the
           incoming =
load on the network is far in excess of its
           capacity.=
  The overall useful throughput under load is the
           ultimate =
measure of the value of a solution.
 
           *Complian=
t*. DOIC provides information that nodes can use to
           reduce th=
e impact of overload.
 
 
 
   REQ 4:  Diameter allows requests to be sent from eit=
her side of a
           connectio=
n, and either side of a connection may have need to
           provide i=
ts overload status.  The solution MUST allow each
           side of a=
 connection to independently inform the other of its
           overload =
status.
 
           *Complian=
t*. DOIC AVPs can be included regardless of
           transacti=
on "direction"
 
 
 
   REQ 5:  Diameter allows nodes to determine their pee=
rs via dynamic
           discovery=
 or manual configuration.  The solution MUST work
           consisten=
tly without regard to how peers are determined.
 
           *Complian=
t*. DOIC contains no assumptions about how peers are
           discovere=
d.  [Note: This may require further study]
 
 
 
   REQ 6:  The solution designers SHOULD seek to minimi=
ze the amount of
           new confi=
guration required in order to work.  For example, it
           is better=
 to allow peers to advertise or negotiate support
           for the s=
olution, rather than to require that this knowledge
           to be con=
figured at each node.
 
           *Partiall=
y Compliant*. Most DOIC parameters are advertised
           using the=
 DOIC capability announcement mechanism.  However,
           there are=
 some situations where configuration is required.
           For examp=
le, a DOIC node detect the fact that a peer may not
           support D=
OIC when nodes on the other side of the non-
           supportin=
g node do support DOIC without configuration.
 
 
 
E.2.2.  Performance
 
   REQ 7:  The solution and any associated default algo=
rithm(s) MUST
           ensure th=
at the system remains stable.  At some point after
           an overlo=
ad condition has ended, the solution MUST enable
           capacity =
to stabilize and become equal to what it would be in
           the absen=
ce of an overload condition.  Note that this also
           requires =
that the solution MUST allow nodes to shed load
           without i=
ntroducing non-converging oscillations during or
           after an =
overload condition.
 
           *Complian=
t*. The specification offers guidance that
           implement=
ations should apply hysteresis when recovering from
           overload,=
 and avoid sudden ramp ups in offered load when
           recoverin=
g.
 
 
 
   REQ 8:  Supporting nodes MUST be able to distinguish=
 current overload
           informati=
on from stale information.
 
           *Partiall=
y Compliant*. DOIC overload reports are "soft
           state&quo=
t;, that is they expire after an indicated period.  DOIC

           nodes may=
 also send reports that end existing overload


           condition=
s.  DOIC requires reporting nodes to ensure that all


           relevant =
reacting nodes receive overload reports.


 


           However, =
since DOIC does not allow reports to send OLRs in


           watchdog =
messages, if an overload condition results in zero


           offered l=
oad, the reporting node cannot update the condition


           until the=
 expiration of the original OLR.


 


 


 


   REQ 9:  The solution MUST function across fully load=
ed as well as


           quiescent=
 transport connections.  This is partially derived


           from the =
requirement for stability in REQ 7.


 


           *Not Comp=
liant*. DOIC does not allow OLRs to be sent over


           quiescent=
 transport connections.  This is due to the fact


           that OLRs=
 cannot be sent outside of the application to which


           they appl=
y.


 


 


 


   REQ 10: Consumers of overload information MUST be able to=
 determine


           when the =
overload condition improves or ends.


 


           *Partiall=
y Compliant*. (See response to previous two


           requireme=
nts.)


 


 


 


   REQ 11: The solution MUST be able to operate in networks =
of different


           sizes.


 


           *Complian=
t*. DOIC makes no assumptions about the size of the


           network.&=
nbsp; DOIC can operate purely between clients and


           servers, =
or across agents.


 


 


 


   REQ 12: When a single network node fails, goes into overl=
oad, or


           suffers f=
rom reduced processing capacity, the solution MUST


           make it p=
ossible to limit the impact of the affected node on


           other nod=
es in the network.  This helps to prevent a small-


           scale fai=
lure from becoming a widespread outage.


 


           *Partiall=
y Compliant*. DOIC allows overload reports for an


           entire re=
alm, where abated traffic will not be redirected


           towards a=
nother server.  But in situations where nodes choose


           to divert=
 traffic to other nodes, DOIC offers no way of


           knowing w=
hether the new recipients can handle the traffic if


           they have=
 not already indicated overload.  This may be


           mitigated=
 with the use of a future "load" extension, or with

           the use o=
f proprietary dynamic load-balancing mechanisms.


 


 


 


   REQ 13: The solution MUST NOT introduce substantial addit=
ional work


           for a nod=
e in an overloaded state.  For example, a


           requireme=
nt for an overloaded node to send overload


           informati=
on every time it received a new request would


           introduce=
 substantial work.


 


           *Not Comp=
liant*. DOIC does in fact encourage an overloaded


           node to s=
end an OLR in every response.  The working group


           that othe=
r mechanisms to ensure that every relevant node


           receives =
an OLR would create even more work.  [Note: This


           needs dis=
cussion.]


 


 


 


   REQ 14: Some scenarios that result in overload involve a =
rapid


           increase =
of traffic with little time between normal levels


           and level=
s that induce overload.  The solution SHOULD provide


           for rapid=
 feedback when traffic levels increase.


 


           *Complian=
t*. The piggyback mechanism allows OLRs to be sent


           at the sa=
me rate as application traffic.


 


 


 


   REQ 15: The solution MUST NOT interfere with the congesti=
on control


           mechanism=
s of underlying transport protocols.  For example, a


           solution =
that opened additional TCP connections when the


           network i=
s congested would reduce the effectiveness of the


           underlyin=
g congestion control mechanisms.


 


           *Complian=
t*. DOIC does not require or recommend changes in


           the handl=
ing of transport protocols or connections.


 


 


 


E.2.3.  Heterogeneous Support for Solution


 


   REQ 16: The solution is likely to be deployed incremental=
ly.  The


           solution =
MUST support a mixed environment where some, but not


           all, node=
s implement it.


 


           *Partiall=
y Compliant*. DOIC works with most mixed-deployment


           scenarios=
.  However, it cannot work across a non-supporting


           proxy tha=
t modifies Origin-Host AVPs in answer messages.


           DOIC will=
 have limited impact in networks where the nodes


           that perf=
orm server selections do not support the mechanism.


 


 


 


   REQ 17: In a mixed environment with nodes that support th=
e solution


           and nodes=
 that do not, the solution MUST NOT result in


           materiall=
y less useful throughput during overload as would


           have resu=
lted if the solution were not present.  It SHOULD


           result in=
 less severe overload in this environment.


 


           *Complian=
t*. In most mixed-support deployment, DOIC will


           offer at =
least some value, and will not make things worse.


 


 


 


   REQ 18: In a mixed environment of nodes that support the =
solution and


           nodes tha=
t do not, the solution MUST NOT preclude elements


           that supp=
ort overload control from treating elements that do


           not suppo=
rt overload control in an equitable fashion relative


           to those =
that do.  Users and operators of nodes that do not


           support t=
he solution MUST NOT unfairly benefit from the


           solution.=
  The solution specification SHOULD provide guidance


           to implem=
entors for dealing with elements not supporting


           overload =
control.


 


           *Complian=
t*. DOIC provides mechanisms to abate load from non-


           supportin=
g sources.  Furthermore, it recommends that


           reporting=
 nodes will still need to be able to apply whatever


           protectio=
ns they would ordinarily apply if DOIC were not in


           use.=



 


 


 


   REQ 19: It MUST be possible to use the solution between n=
odes in


           different=
 realms and in different administrative domains.


 


           *Partiall=
y Compliant*. DOIC allows sending OLRs across


           administr=
ative domains, and potentially to nodes in other


           realms.&n=
bsp; However, an OLR cannot indicate overload for realms


           other tha=
n the one in the Origin-Realm AVP of the containing


           answer.


 


 


 


   REQ 20: Any explicit overload indication MUST be clearly<=
o:p>


           distingui=
shable from other errors reported via Diameter.


 


           *Complian=
t*. DOIC sends explicit overload indication in


           overload =
reports.  It does not depend on error result codes.


           [Note: I =
don't think the resuse of too-busy and unable-to-


           comply fo=
r throttled requests impacts this requirement.  Do


           others ag=
ree?]


 


 


 


   REQ 21: In cases where a network node fails, is so overlo=
aded that it


           cannot pr=
ocess messages, or cannot communicate due to a


           network f=
ailure, it may not be able to provide explicit


           indicatio=
ns of the nature of the failure or its levels of


           overload.=
  The solution MUST result in at least as much


           useful th=
roughput as would have resulted if the solution were


           not in pl=
ace.


 


           *Complian=
t*. DOIC overload reports have the primary effect of


           suppressi=
ng message retries in overload conditions.  DOIC


           recommend=
s that messages never be silently dropped if at all


           possible.=



 


 


 


E.2.4.  Granular Control


 


   REQ 22: The solution MUST provide a way for a node to thr=
ottle the


           amount of=
 traffic it receives from a peer node.  This


           throttlin=
g SHOULD be graded so that it can be applied


           gradually=
 as offered load increases.  Overload is not a


           binary st=
ate; there may be degrees of overload.


 


           *Complian=
t*. The "loss" algorithm expresses a percentage


           reduction=
.


 


 


 


   REQ 23: The solution MUST provide sufficient information =
to enable a


           load-bala=
ncing node to divert messages that are rejected or


           otherwise=
 throttled by an overloaded upstream node to other


           upstream =
nodes that are the most likely to have sufficient


           capacity =
to process them.


 


           *Not Comp=
liant*. DOIC provides no built in mechanism to


           determine=
 the best place to divert messages that would


           otherwise=
 be throttled.  This can be accomplished with a


           future &q=
uot;load" extension, or with proprietary load balancing

           mechanism=
s.


 


 


 


   REQ 24: The solution MUST provide a mechanism for indicat=
ing load


           levels, e=
ven when not in an overload condition, to assist


           nodes in =
making decisions to prevent overload conditions from


           occurring=
.


 


           *Not Comp=
liant*. "Load" information has been left for a


           future ex=
tension.


 


 


 


E.2.5.  Priority and Policy


 


   REQ 25: The base specification for the solution SHOULD of=
fer general


           guidance =
on which message types might be desirable to send or


           process o=
ver others during times of overload, based on


           applicati=
on-specific considerations.  For example, it may be


           more bene=
ficial to process messages for existing sessions


           ahead of =
new sessions.  Some networks may have a requirement


           to give p=
riority to requests associated with emergency


           sessions.=
  Any normative or otherwise detailed definition of


           the relat=
ive priorities of message types during an overload


           condition=
 will be the responsibility of the application


           specifica=
tion.


 


           *Complian=
t*. The specification offers guidance on how


           requests =
might be prioritized for different types of


           applicati=
ons.


 


 


 


   REQ 26: The solution MUST NOT prevent a node from priorit=
izing


           requests =
based on any local policy, so that certain requests


           are given=
 preferential treatment, given additional


           retransmi=
ssion, not throttled, or processed ahead of others.


 


           *Complian=
t*. Nothing in the specification prevents


           applicati=
on-specific, implementation-specific, or local


           policies.=



 


 


 


E.2.6.  Security


 


   REQ 27: The solution MUST NOT provide new vulnerabilities=
 to


           malicious=
 attack or increase the severity of any existing


           vulnerabi=
lities.  This includes vulnerabilities to DoS and


           DDoS atta=
cks as well as replay and man-in-the-middle attacks.


           Note that=
 the Diameter base specification [RFC6733] lacks


           end-to-en=
d security and this must be considered (see the


           Security =
Considerations in [RFC7068]).  Note that this


           requireme=
nt was expressed at a high level so as to not


           preclude =
any particular solution.  Is is expected that the


           solution =
will address this in more detail.


 


           *Complian=
t*. The working group is not aware of any such


           vulnerabi=
lities.  [This may need further analysis.]


 


 


 


   REQ 28: The solution MUST NOT depend on being deployed in=



           environme=
nts where all Diameter nodes are completely trusted.


           It SHOULD=
 operate as effectively as possible in environments


           where oth=
er nodes are malicious; this includes preventing


           malicious=
 nodes from obtaining more than a fair share of


           service.&=
nbsp; Note that this does not imply any responsibility on


           the solut=
ion to detect, or take countermeasures against,


           malicious=
 nodes.


 


           *Partiall=
y Compliant*. Since all Diameter security is


           currently=
 at the transport layer, nodes must trust immediate


           peers to =
enforce trust policies.  However, there are


           situation=
s where a DOIC node cannot determine if an immediate


           peer supp=
orts DOIC.  The authors recommend an expert security


           review.


 


 


 


   REQ 29: It MUST be possible for a supporting node to make=



           authoriza=
tion decisions about what information will be sent


           to peer n=
odes based on the identity of those nodes.  This


           allows a =
domain administrator who considers the load of their


           nodes to =
be sensitive information to restrict access to that


           informati=
on.  Of course, in such cases, there is no


           expectati=
on that the solution itself will help prevent


           overload =
from that peer node.


 


           *Partiall=
y Compliant*. (See response to previous


           requireme=
nt.)


 


 


 


   REQ 30: The solution MUST NOT interfere with any Diameter=
-compliant


           method th=
at a node may use to protect itself from overload


           from non-=
supporting nodes or from denial-of-service attacks.


 


           *Complian=
t*. The specification recommends that any such


           protectio=
n mechanism needed without DOIC should continue to


           be employ=
ed with DOIC.


 


 


 


E.2.7.  Flexibility and Extensibility


 


   REQ 31: There are multiple situations where a Diameter no=
de may be


           overloade=
d for some purposes but not others.  For example,


           this can =
happen to an agent or server that supports multiple


           applicati=
ons, 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 indica=
te overload with sufficient granularity to allow


           clients t=
o take action based on the overloaded resources


           without u=
nreasonably forcing available capacity to go unused.


           The solut=
ion MUST support specification of overload


           informati=
on with granularities of at least "Diameter node",

           "rea=
lm", and "Diameter application" and MUST allow

           extensibi=
lity for others to be added in the future.


 


           *Partiall=
y Compliant*. All DOIC overload reports are scoped


           to the sp=
ecific application and realm.  Inside that scope,


           overload =
can be reported at the specific server or whole


           realm sco=
pe.  As currently specified, DOIC cannot indicate


           local ove=
rload for an agent.  At the time of this writing,


           the DIME =
working group has plans to work on an agent-overload


           extension=
.


 


           DOIC allo=
ws new "scopes" through the use of extended report

           types.


 


 


 


   REQ 32: The solution MUST provide a method for extending =
the


           informati=
on communicated and the algorithms used for overload


           control.<=
o:p>


 


           *Complian=
t*. DOIC allows new report types and abatement


           algorithm=
s to be created.  These may be indicated using the


           OC-Suppor=
ted-Features AVP.


 


 


 


   REQ 33: The solution MUST provide a default algorithm tha=
t is


           mandatory=
 to implement.


 


           *Complian=
t*. The "loss" algorithm is mandatory to implement.

 


 


 


   REQ 34: The solution SHOULD provide a method for exchangi=
ng overload


           and load =
information between elements that are connected by


           intermedi=
aries that do not support the solution.


 


           *Partiall=
y Compliant*. DOIC information can traverse non-


           supportin=
g agents, as long as those agents do not modify


           certain A=
VPs. (e.g., Origin-Host).  DOIC does not provide a


           way for s=
upporting nodes to detect such modification.

 

 

--_000_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_-- --_004_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Req SoC appendix_MCruz.docx" Content-Description: Req SoC appendix_MCruz.docx Content-Disposition: attachment; filename="Req SoC appendix_MCruz.docx"; size=29557; creation-date="Sat, 08 Nov 2014 06:26:02 GMT"; modification-date="Sat, 08 Nov 2014 17:44:38 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDnNG2tjQEAABEGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1PwzAMhu9I/IcqV9Rm44AQWrcDjCNMYohzlrprRPOhOPv697jdVg20rYOxS6U08fs+dmL3Bktd RnPwqKxJWTfpsAiMtJky05S9j5/jexZhECYTpTWQshUgG/Svr3rjlQOMKNpgyooQ3APnKAvQAhPr wNBObr0WgZZ+yp2Qn2IK/LbTuePSmgAmxKHSYP3eE+RiVoZouKTfaxIPJbLocX2w8kqZcK5UUgQi 5XOT/XCJNw4JRdZnsFAObwiD8b0O1c5hg03cK5XGqwyikfDhRWjC4AvrM55ZOdOUQ3JcZg+nzXMl oYmv1Jy3EhCp5rpMmh0tlNnyH+TAsCoB/59irXui/YcKxTDPQdJlt9dDY1wlnawtdmLb3SAEKtIp Jt+fYNxWdNwotyIsYPJ2MYod8VYQaXX1/i5Qi61yK0JO3TkWkxJOuPRf3kcj3QoRaOQAr7/dszlq mWOW1Jwjbx3SCPN/SHs7o6romLregQ8Kmim1r8sbRxp/Z+cH1YDNINvjzeuB3v8CAAD//wMAUEsD BBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9h yH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99r eG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1 jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDP JZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD/ /wMAUEsDBBQABgAIAAAAIQBOQdr7MgEAADwEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwu cmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTzU6EMBSF9ya+A+leCqPO GDMwGzWZrWJcd8otEKElvdcf3t4OExxQBl2wIeltes7Xc+h681mV3jtYLIyOWOgHzAMtTVroLGLP ycPFDfOQhE5FaTRErAFkm/j8bP0IpSB3CPOiRs+paIxYTlTfco4yh0qgb2rQbkcZWwlyS5vxWshX kQFfBMGS274Giwea3jaNmN2ml8xLmto5/61tlCok3Bn5VoGmEQuOQORuhk5T2AwoYt3Ed5yMjyOs 5kQgFw0c/dslb7/hFMPiBENVSGvQKPKlqfghgf3NV8NwOVJTAr4UlN8rBZL6EfzcmuIIT3CMVP2P OlrnYxgHyCn75Zz2ymhKxK7s1fE9moK4nhPC1bb/W3t9dJMphKs5ET5g9/TrYfSGHQgfvPn4CwAA //8DAFBLAwQUAAYACAAAACEAO1vYPgA2AADuIAIAEQAAAHdvcmQvZG9jdW1lbnQueG1s7H1rc9tI ku33jbj/AcEv6+6Q3HrYllt3rAm/1HZE91jX1sxG3In5AAEgiTUIcPEQrf71e04WCkSBhAkJ9IAC OBHT1osoVFZWPk9m/uWv32aBdevFiR+Fr0bHT49Glhc6keuHk1ejv19fHr4cWUlqh64dRKH3anTn JaO/Xvyf//jL4tyNnGzmhamFR4TJ+WLuvBpN03R+/ssviTP1ZnbydOY7cZRE4/SpE81+icZj3/F+ WUSx+8vJ0fGRfDWPI8dLEqz31g5v7WSUP262+rRo7oVYaxzFMztNnkbx5JeZHX/N5od4+txO/Rs/ 8NM7PPvohX5M9GqUxeF5/kKHxQvxI+fqhfJ/9CfilV2sWVd98l1OAVnxl9gL8A5RmEz9+XIbD30a tjjVr3T7vU3czgL9d4v58bOV9YotNzmDd7G9wFEsH7jyuDXEcNWHZoGiA893earVJx4ffW8z+Ynw EcU7NHkFc039JjPbD4vHPIw0ZeLiRrTh79/iKJsXrzP32z3tY/i1eBYv5j3e7OiF3Lzy1pJ7PWDl 6n6Z2nNvZM2c84+TMIrtmwBvtDh+ZpEjRxcQFjeRe8d/59biHMLG/fxqdHT05sWLy5fPR/pH77yx nQXp6m+uSj+Sh1zF8s+X9C7w8OlbO3g1+nD9x+9XsaekQ+q5o18u/vILFsz/No6i8fs4xl+nd3O8 3SS2Z19SO075d3gn/ie9eD2HjHH9b9b7p/xwKo9Qi617wPtQltEfp+g6T+a2g+fPYy/x4ltvdGFZ n73/yfzYo7BMrNehHdwlfmI8ny8qW9K0KO1Y/+jHkafb1TdRz/rn58u31vt3H68/fT63rgLPTjwL 1IxuPSud+omVeA7lrjWP/Si20siaZzeB74gwtuzEssMdovXG3RrvCrZYx3erjAsSPf1Xk4/mLNvt kXe7+sYjuC5zlc37+qeXgNc8a+Y5Uzv0k5nleokT+zeea/mhYkNtDxmnsOM7Nd61MbPZEyjWJG3y 4WYSkqRNvNSKxrjYJVnpeqntB4rGlAJnRy9e/suUzN0SuNvVNSNfvH963OQwVsXGU1M5NXlIsxP9 ks1gm98ZD+yWWN2uro+qzkSwDJmTCPV8Sh07hr6zFlMv9qx3nz6+teawWXw7CO4sej2Bj7+B1nMj b5csio3bNRijseAJoy0KHSHfnbXw06nleDEkTWhIH9yN3NhIPM8qWYYnFoxMYwM7zlvGuzYmNoRy kw82kwep903Eu2c70zKV98KcvKN8FOWDfEdCeGC8IIjooZdpmFhTG7bwjeeFMEvGXhxDY4JFrXGW ZhAbcI6/HlhuBnM5Mk60l2zLUI+bBVvkXQcxnTSGeID39uT0t6sr6+31Myv0PBdGYYSTAMkRNMMJ 2InvWPBL4iCy3f6TGoRJ4ygwNlojXppJCTItwmji4R2f/HRuPLlbbu129R+kT6MfZf4dW09yO+Wn A+v4pPzdyekBPHLXOnlmHSqLhraLVVXtO05vy7IM5qxh+1WL28kgnsM0ME3jmo83uzVJNp9HcQp7 MLz17mxKIjhSFEHwTVU8jOER2JDhYMgcwXqJF36yRTWg5brn7o0W3s5GRsvDLsm/Ry5RCp2WJNVe Hm0n3g3nNFpIuCz2KJhorkIg2WFhGsE+tSeQgnCxnrz7+Md7GLDwdA1e6av8TzwoRjvdolyaIUKW pMjOis0vdC0I/fSnHSLqjh/pNYKQNf6VE2WBS90JJwsx4DR3poqwAT0scPkO0foHGYwT5jCNbbay XFzP8Yk8SPaW/mPVqC/Ktv2x8d3Jy/LvTn5dfmdw0I6LhQdb+jAvjH22uimnz5bUewpDhcIqlzqW XEoLbrODtLdIKUQlbBc61lrYd48s6PNgciNX5MUzP9yiZk2ndgp6hoe5h0VDJoxcz/K++QmCQTde umDQLV1E4skax91Xtl7SwthuK+4mUZO9V/VYdYAh539FwOdoKazwXUnwq9DP6TODdXb/pjwx3reG 1VdjPXkIrMmHK5Gei59yGW/PkeLTUBb4q4IpipnxQ14wmDH+vJj6yKnAu/r0+2djqd2nq/G6jckq NKmkO2s+XCFrTW4FGKJCe7jWDVQmtCsSfpryhx+hS0H8T7E/8cPDz0L51/+4elQZ1wcr1mjc5Jia UZqERaokiAj4BU2ThRcjCPAR0QGlWUXlMiAc/mdqZaELZDLRx8NRrzNgr8dI6m+P5jq3TYZVYKXV MzgQlocAQTo8CGDYIDluGlJ9FSY+QOeB/xBL/eJAsANRluaGNrNXbrRgstCzZ8LPkiCkbHFSy2e4 6yP+Nc+2r4T9AYkOBmDmEYoFgC+m5lOJ2Qy0VdoPTAyDXfKxQvjHBfx8sIAu2QgPkBpgY2VUHCyt CoggyWmn1jiOYGSQrIjgUnormW2s01cO5raNjbYyMhw7jgnWghgwHtot9bpd/QdFKc30kUHtVkd4 fHpu/dcU4Xa5CSWkquX6CWLEMYLvhKOjggDWDbQp9a2x/I6T+8EiyAPmZYsZbdROzBEV9pRZYsa5 GDN2EecSoUSN4Eak9spl7SupF8xFGEzViqeR0ED6KCHsxmfdjvLQc962ZhHwY5sWS+ZeEKx6vzDc U2+cbYQHycebuQ83HpBuKPJg3vBvUSWJ1tcDX+HsVudNHa4rFSzJ1PLsdZpWAnE0rezbyGe0YS/K pCxrXRFOM5bVoszylf0k8WOmuxN4WJbAVCRKD/NKxyAGJc7AgpvkC0v1mhI78G5tlCTDAUNNWB6u J4M7ni/lYqwcI7PvE+Ok+g/G8FxvE0FuWgE3UFcwOliVBd9ECiMQxVMVEWQAQfWXLDSDx/qqKU7O rCdhBGTywrrNgtBDIS4r4uF1/GT6HK00iPUhWtDeo3EGms+QYlzAtyHV4YZ7dlzBNvaV2rF363sL g7Fa0VVcbRs6F5ETtDFAknGOqhTz4LqlZbera2cR1W4nTai+apHCbHyXVxQ2eUAznfO5VLBoPLVb anW7en5WgZ2kn2FDoj7CvYJz/AZ6+avU26c8xRZVi795FG/3MR26JUi3q+urU5P/QhXA+/9nHZ9b AitJoiCTevo//v7lGkX10S38bYS4oVxnWaiTkUDBTSNVZvTOt/Gd96hK4hDpkP8ZN7ZGfK8KEnGT mny0mQiBv+V9Y2H5BM44YfvMeGm4eRnDv1cGvEeNgOf6gH++Kupl30q9LOyUn58Koy+L+bOEFSgw mx5hUrcFG8/9yeTuxna+elsMKKHSROBR9L60ZABmNkkkOFpideP+7Lh81NxkvHNjcaGvcpNPN5MY pboelVTUNVRWkXazdFnQiCJlZKzda2qXaGNsuua4mhEcqV3JfqkWY4yQqTjCUkyrCgeB3++SmN6o +jVrw1lHX51lJXHgjZH+w77zKmIUcHuhgLV3aXvdcvKQV9/IWLQpT9balKpAqFAORdBZS6y18rJb Wm/crb5GTUTOqkG59Urq2JvYsSuZHQgmBREsCF4CDDCA5pmZu14TOmexJqfUSDEwpJC7P5aDkCR7 BNB6Fz2QVFNndKHwJ59p6QsToLeb76LXm9GEbpYlUmjEdBw1DaxTnpLxzr0+pDxcv0WjdKUfw+K8 fBY46spJ6KZ77MP3Gg1F37wZSZvA3PcwOg/Cr5BT1X0g8sO8RHcEdO45txPH96FdZ+gKiPqEKP7w GnqUXQ+n/GLtb5wEB1584I3v+uqhThRAI+cdD+0sjfhj8EKs3kvvSb8J/rJgL/6VbIH/kaata1oV 1jmeZEMtnZGOcVbyur3mR512Nm5gK3PSRYgX/lGpJJZgNhex+iiESPktJzGAmCrhbazca1pnjBYa 221FaG1KLMkLTA4rdyBily38APmmtXK6t2zJW/eLr0D6ASi/jKpILk6wxg7YG/ASqC9pkmiHd1bJ 8jDOuNcsvV0AR47ZgH5AnCV3yQjOJMn3/Kv5t1uG6nb1jb6KyLq1nlngz/xUIh0+OqoDWA3GKkQo InvkOn5fRW3s+IbbOWcQYA1gbM1RKukUVfST6RyFAwwaLR0IjcNGdj1v1wN6D0dO+hg8AAPZbKPQ SvtLMiVn2xDFumjTQO0/tmMWwiDnQuQjzsBPH1tNhnC0wRo1hFoTa7BxswEwaPLpig98Adv0eikC qNpxMyAVCoYW8y3vPSWxBWOVfouJIPUxtcG8sDWnUqFrTV52hkZ4bOAIDqXgRaESejiKyNA52r3C J0s93GBVHXVViptg/WW3NMGVqcgk7ViJwTyq7pntdB4AG5mzRVYm/66aFHv21ezbrWTsdvVG9uoz 2KtFpDX3gYjvhCMvtX5wNIFWzwvWPPR09mILc0aUvByOEkIUKVTjMIw9N1NDKAVkALBKPcZO8ocK 2lNyhGx/i6igscqOs1E7iZgDoYwNNyNrjXaH0bn0rRIUy2RJbl5p7W4JAktly9g421i718TmzTV2 24rSYjKVmBjBbB9hRo76gchAJ32l+JV3K5JjaD6B9vG3R/OcoY0Hdsuy3a6+Uclp6fRzOaC6EkyF jxxkLH80Erw7ROXG+zTeueZ6rzqv6MMeJqzticImD2jmZ41cTOeSZ+4STKpbfh3y6ht5mAHU52sM 0gLJokv5JHHvx9bcQyMb69a3LfcutDGS0WDebmm9cbdaMhnv3PjGSmn8dsvDkQKf2WFmB7RMx/4k Q0NdlTi9hptpWk+M+Rkv3mtigx4YLYis0FYbzLOYjm1ulM4hFmCKBs+KpzGfqChc3XdGvyCrtY1H 4RA5jIgzETC+ELOg5uRu4IpueAgG6YfD2VqMbBGqDm/LoJ+JCRLbIwfQHBv4rH+y9cA5AuF59aNu ljDOYhV2SDP3rjqMUUNzCP2CVVJ5ML4tpqI+eriRUAv3AHCjboXtfnUIozJr/RsH7m4YZkUL6kU1 BQ1Ajj9BXV9j3ORJ+V6uD7N8+fDp77+/+95FX95G/bgyyU4vz94/v3zE4D/ZlLqN2tK7wEC7r1Tj yLYi4f+n6mdkz6IMAdRKu8du71D+xt+pI11/6tpkxb8VEd9wni6KwZp8sJl/aVipsKJkwqlgojDn HHFqnATNVOijS5i23jcbiCo04vHN7mM7cRJ1wNElwZuQbdWvrzRFrPEumpEbbblRjUqqqtCpMlT5 rQs/JMVQIHa6C71JlPrI12pgq/HivSY2spzGZltRGyZP4XIdWPDEmHlB9hRgIRZJCa/ze8KKYDB9 DaMFJvpOzPBur8ldyZK0ojbSXFqaIAgIospATcYd9rlUMtH9oADra4P/iAAOVsgAjOqR0naZw7uU H2ZlQq+ZN2On5u1KCyGtAxRSXkxphyEsDwf1DjA/iqJsaEPdaMZYvtfUpvA0JWMracHgTMI+Y4mf ZhIj06OktRCRHxITp62SXRIj2l69r41X9rXLbvxp2V24MGwtoDA5XJuCVMJZjml7oY4GARhVTfOM pTuovZlG8avRH2/j7E/+wIUl8Wp0cnT87PD4+PDo5fXx2fnp8/Ojo/+vfIeyT1Hy8NOLFeQhVtpY p0OlOyY+VxSrLbE4yc2jIeZwbsu2i/kUD+RzMuGMWhrxLDaNRpOQ9hwKMzg6b1URqJu2rCqT66cD zYZ0MuhsxuiWrru+2jXXLK+Pix9X3Z5sCvpOYikqoHKxS/K5W1U85NW1ZpQuWieVG9IwxAED68qL BfEK46vJM3L3e0/42vpZ1UnrrBrYlIpwlr8lSeQw5uDCyBjbWYCWicEkQru/6exJ8pPgvYyD6JbU msvua381ZEC0EwG63dhvK2s3DzLA2r1DCnQGk3YmabQkZSU92P11qqzhOTqGg/LjQfUsqwzDaEVp DRdbVtXKBF8PeDpX9Ww3k/BeyBMwTrrXnE3n9oElNjV3DbE0sjHauSJaT3GiRvRYiK8BBoHfLhhh Q+2etIdn2e2jmzwgIWSDR2p4dDV6DJO8yQebhY/tGwDJHQUcX46sXrI6BAkTwKWYph0kAwJC55EC 02+tOapmFF8KbqP1pIreF5iqZAq1udLIo9dyJPeHtsfb0HtxhMoeNp+gDwtHCykRDLXDhHa0KQmC PEiU96eo5Al6TetVc6AVTyP/saol984bWeh+MfoyHPqauaY5BsCMdRvaiIOqEmuS+a5NoU1RYlyX XvMsKuoCCZura2tsvBX3JsD7YeI923XcWVOa05hjgSixxMaAlSZrU2iwZ7mxaq/JrS+0seNmdM5L q/KxKpmLwhPkSmdzK5uz7hSoC/Bxrt+EysYavabqkp2MPTek616kapHaLZN0u/rGSAXxZi8RlvmS zc1ZR1JiB3dJN9sDzpSDYzI/mepeuoUiN/hzxzesATnGO9fcqVWHqlQJ3+QBzcx8GXABLxZdDUvP 319gfYE3MrE+05qe5pJC0ToK0S8yugIujJJoPCCzCDz2oDYcFyMGrxhHUW1RAcWbozJMRQrZrA9V ozQ8oacxmsWPXIQCSHTjivRaLogzbmy3RqQ0kwicHcTgiQyaKzhWjsBjIfo3JYwHKIDhmKtukA8J s7BNjwgDHarJSau8fia2ETBU0fccQFAZwtZrHsakSxkStz02rpk2VxXFe013b02nEWAAMNG7F6Yu Rh2o+GDlGOuwP8/L2J/1QXatMb/zRIg1IAzYU1c/rww4ePfy+PL410dcKyCbwiGVAQfMPFAYP85x xi2SCgs7daZutEXwo56CAmg/+v6tCxBCUCfICktI4E8vHlBWIQ+AVO7e2kxyM9uCmQKVi1T3Wis/ C+28gJJD4IWQPeg/QVQrZWus3msliEof/z7T0zb4JqSiGMsKT5o3rAOwAakF5CchO/bKTyu/bvmq 29U3sJGCz/xahc9IjGYMiDjroC3biSO07UTjScSmecvhjmGe8gJDyPHvcK4wKmu8xAFm3thyK39M uqswbMBsd97yK4EzIaXOcIrnxSw1lK1hoLJrLL3jrKWjJ8Y715BrNSK2kumo+WQz5UR5mTtnUvUA FJ7Gd2DyK/IBjFee7WWmlpkb5YY+3J8BzbDKKcN1LoOYsrBrEfaVnoF01Ayu6DUndyA3XPStBb3J 9axaGA6tV9LRraSG8G1uvha8m6XlwoTSgAWFCvOH1DYQDPaQttbrwwEq+72XwVoGdysUu119o/6h vj4+OofqAah5RkgKfKAiAFhKd6menuWEI0cnoxGDiWDc8e1qdWtI8hrZtmpLEUXS5JPNbamC0kXc nN2m0debRVxoqRC6+9kopPg9sVeVQ6qLrb4ox1Yv1hRVf+c5OOM8oqqfUo6ovnhxenZy9IgjqrIp EL4cUcX46SdfPDoAyRziQkyjeezd+lGGzMxiQEG/kgtkOu41oqQiEC6e/mRwVrdCc786Tq18eXer 29Tx8bnMLjErU0qKOEJOnxFheN/5rBhR4q4v0LxKmKXbw95ojrTTzwmKTB52H/fX8d46diVYMbO/ wmpZ2/uRDjQPh8Ylvt4hav9gjswvpLHhpjoix0Jwiou+4nPUHSJ4jEZRCw9A3NLgXmOFfl9yL0bY 60HX/IA2dR6GV4OO914yeYWFDd3yTLerbxQC4iVjJvx/wQHE4Du2FgIYVE9mk5YQY9sPkgNrEkEG olopKpxoMt2AbmcmhS3GhpsJvJpgloBv1VQnoBfjiKPvmBLXpaprynaNxXecs9oZPFS5xm5bkRpV uHNkKP18fPu6mZpU5DZO2CGWVPi+Ms+g1+SOsH3zLreit6oQhdlOqubCRCctp16AAhuIETrY7C8G qTMDcGxI3XscIO63x90U0DCfpPRLVaFTjNjWAiN7ElDZdi20KYdZsLcJeInvV+xYOaa6gNvZVgJu +illn/3F6xcvL98/4oCbbAqErwTcJA0sgFE49bB7ZTKsBnwy+15pj9Fr+Qs5iLKGCq+1gNrh0gez A5YtQi7YN1IgASjJGFW6EAuA5RBvh0gLzA8ZtDMk3EgaLezYfYibVWPI2SAmW+yqYdHQc28wFALK b6XFo1KLzjSKEvOse83b22y26wLiBCyUZmU6I0J6oeyBQqPnBegI1yxQzLKLzdN/VMtudnKG6t+e GIH8EPIqM24BceH4cx/CKiFmFx2GQhfeIn+rT8QfG6v3m7G3im1QMzwhlu2AJhsxZ7q0TatHbUKz SOtmQBJk5qf+hDrM4K1WHgr7uAjjcow0Yrc20KspjegR7ZARoNMY2ZQA3CqRNf61sXbf+drYbCtC 5/SFLTOPfS+14zs9cE2Qwoc3doA2IXRYij7Te2AAyb+PXSqPoV5ZSuzydF0O8W+frhmqlMZKyM9k N6g/hoWNugfbVXUl+HJYc+jgUW3vUtsqQgYbt1QzhbiZlHlDS10S4aOHptjGur2WnCX0hLHpVhJU +cKFj6zDk7B9pQpQGwfGgr2mcgm7Z2y6FZURi4RqSn205ke0GIaux2oK2AWYO4RvZay9auVorNlz Quci1NhyKzKXZbFMWDIe3S01u119Y6pOJ1S+U1ABgSwzCNAtM8II1gliP8ua1or5/Eh2a/BHDeut 4lkZD2jyyQp8rSbAo0UtiAnAP0M7SlpouKD4ZZ4YFDRkJ3GUzY3Ve03r7VZUqHjO0heoNsbQlFcd I8QOuTeprzAm5Ojo7cnR2xdHnBQigz7fqfbf/I0Jk7sq/YhjQPIEwtyYXPDh+o/fr2IPunpmY9aZ m6cDVK5h6k+mAf6PXsDnt3bwanSHyshowb8BZ8gkBHLIvRITxqYb34tcr201+Cl3QjU5dhC5AF6P eT1rFsGbzofoVV421jQ3DkJGrDQm2OI8vSiNfTVW6Py6bWd/NdJI64H7D1LczmtdhJ533/D5dlau IQgHEWfI7kfhU3PGb7d8sF8dYkkffEmG6h9tX+A2FqISOXh2bn2RSVyo2LbRO4wdxtBpTPX7oJLX nhW+vo2CWxhTaBA6980oZLen3NhoNORjY3WBFj+Q6JVkVc2nm5lShMkWeUiEYAM/TZlCoN+lwZ8h lWhgQcN7gampek1sJFOanFIzOiviKY5GIiFDqybNzrm1WqDu83nMrM0CYMR4hV7Te6sRMREM1hia 8cZ2vqquzJrR87PQl2mPwmksp7Wp83MZkn+NdOPcn0zuhNKFp6BGCyeqKxY8NqAb2EpgOPxcabPe SkwzpZtg0CqnB0PvoWcp+o7rDu85X+/5WPNxt2Ky29U3WiBiaz3/TpYGE8+IUioysigYnnho+YzG QvgSEUizK9aOb1eLLEPu1NzF1bhVIc1Mu6fm881MAZhcGcZAxcEdg1O4vCGKXAGigcJPIycKkgEn bLQR1OS0mlFbfAhUNYVMHiyTjddvr8odnHIDYV8w1gLjiO5XuagAqVX8SVVTCK7DEyw/cjghyioG V523vPDb4+xVubyHbJSivdoY2KgQtYYwjFqzKVaeR2ZRH2dxzNCRzLUcwO2gGBGNMM601/oQdqix 2VaKUOCK1IEqCFFVg6Q2eLxosmcs3C2V96vj4HXcsJNQooz1PTVYooYXV4062Fcf2FIomkAZoaNI k6c0Mzby2SkWISJf8kl9xtOHzDgbBbF4Ji8qngmsisD/ylp0FUNwvXkQ3cHCkPANW0OiZuVOxdB2 iNQbN6u1jvHOjVl4+3aydJBN1OwfBNZn/jfQ2Atv/TgKpQGnql1JEKE/sG5QUIEiC+Pdu2XtH0xv 8Jix2ZqDqkgJjDTLKy/1FDpgmfZhGnLKvXLr35vmw4w2WhsTPj6LklQx7qGSEuRb49h6zaPsdCx5 M2PLDTmVOjFaEMyB1vtobqw6wJO4RRsL8HJ4mEsIWG3GKr0mLHzib1tsmikRiVmErknoTm19kg7w hx/Iu6//cSVzDRARWqB+TQ9D2CWJ0VjOigMlpY1SSCMl/tTaM8z9lmq8ooOUUiyMcIuwHA5fbReo hd5cRDvlVY/4J0DvBARtE8uNqKwBu5fBfhKNKeKau8Rb3QqRIa++8VaLaX52bn1kU5o1tiHVrzJ1 RLqVWW2tqdotsTdut51xvlXgQImq6h6vaUNjsb6mwMkMR4AC2okhC/T/jD03M3lqwGsBw9MoksPw DEhKIIcn0zm8HT3uHQaSNEbgOA0OgDYW7jVXU40bu21FZsWtNAikT5+lpQSGlCD3SHU1x5/Afodh +jG1FCbGWL7XxFbkMfbbitxAzwljJ7Twl9AjourSKUIsJUd/bxGQs+7nn1YOSmUI0s/MD0j4EaFS TsR7aTSlKTA03/k0AgqVzxpR19Oj43dvHnErGiEIyF1pRQMro+TLa2Ni6dPnjSXoXRi067VIkDYa xnZbSQQgawNASeEWEHOLKogMcT1YLst2NGz5RukQTqjr4mTfrorUF8nQLaN1u/pG41l8BUySr/EV kOwr2bT6cgvALc+YkA0NRt/xDbfzFlaDHq3utfhf3/cUYFk5QeaiLijwGCI1E2C9JvZ2Qy6aeTWS W+PjVOe/lMVXTG9rMkOYQuq6A5peUM0RteLsWmrDiEUlKErC/dRmR9GxnUyJVkQHaxxAxWvpN3ub vNWK3OkUXdE0y8IL+zvaqQF3DAtB9QiHRUDgRkmWK6kzHMmdM6Sx4ZYkB8pbK0FJyDKwk4VoKAq0 KBD0oTdGckYaFVeROL3ma02UB5D6QkEDlnRN5miahr6Lag6vWWxjTTLfRfsjM9DRa9JusxvgpuMB 6YNgFY+DnJAyRCBSGj2ikmavieQRhOOi7yZVsOSHCz1cyoYMKpGp7ZRNRJ7E9qwZjfOCgH3MiDLi h8SMfm0RM9KfLceMLo9PX7y/fMQxI9kUyF2JGUm+Oa+ZTEpAaMLGpOGutLdTupNABuMO9FrC52ZK VdK1slQStLPBfATo1ssshikSs7uEIEcKfLQq3x4OmVWr7K1SWdnWAqJA/RW7RKOeNcdBiqdD3kYh 4B3KV5AKQ2h/OORmtVQOcDA23YqtwcmgJfN6AJ+7PuFUIK4iMRJVCtOiE1RDwv0jIfoAKl/s7QJt F3SrYbpdPdfVAbINnz1WPnruFXqhvUF87CtaLqFzUI0Fb1kSS/4VseS0mApcHhwDtkSEouQ0L1tW YNTGoCpz1g9hbCUNcT7BTIV8EGIrFkAZJYYx+wkqVxldQ0BzZvvhvkkwBeQ9fYA1g4Ax+lbUTD6J AxAI6KGJ6qKgBsoZgngnbnb9/W2XGjEZzdh3K8bOOVblO+ewI6QXsSoxUTYX+H11BFOvaa0u+wNo zABbAR3POzLm8HHdMb9odSOFUWtW6jVlVxmpFfMiiaTmeEWhTOKl/stB5J8psIkiz+urJR8F2Vx1 SnpNbgWefxAjGx/qlkj71XFJynErswfo546b1Z0cnVuvwzs0VWcbHuRkdGgVNqdMCWH+UTI4aHvk AGiD/M0OcddGDEc7vY0GkEx8Z34yZZjC2Hgr2SeZL9WR1otjZiBV1AVRkVvftt75aJEESPDe7aT4 uF84ukAjagOUlieAod9j8CFFQPQF3x4z57P1YD7Bu3U5zZd5KaAcQXgL4kM4HAyeZAEK8tBAe6dc rMV5Hcr1+Kicsqh17bWIyZsGfwQJwv/EKDEADr+KU7+J0jXZRBJsc7RKPvw+dBu8KrtTRNHhTZYg FIijyUIKtcM0GlAOAWeNMPOmE2meN2RultUVbDbqgsdlnAMCNlIdyMwBMOml4R24I+9MaEu39tEP 1p+i4TamwptT257EnvdXsxezeX9xE3KceXF7y8bXyzdnb9+ePOKkodoVmAZZw25ZZ7/6bhv2xwJc dtBkGah3Na5VT8wWrBvQhX6QINWZAFJUmP1MyxHc6Q+o34AK8mxPJyCjh5Qyc/dJgvQAaMwGUKoR AW2NLCRoC/HmDEF/JD6Nlbu9Vj9YH+Sl8saG2/lRakK5JOw5vJKGJxxVnVPOYRSF8W8s3GtKL733 LapfGpDsbmDLQMv8Oz0kHjzuY3xr3pN6SNNxW3hUK6BOCbXkrhLh4Lq4CWW6s8wZ0KxQuD6oXDYu bCtJUSqB1iXPGDOMrJ8iNvTeugJeY/1eC4ytVjiAc+eB7ewL7cg/beNXWryAU+dor5wotqUgxuDb Gefeqpa0yJUMh12JBcTNTaoZoVYyIjfYQOgUI4Wlg1FBfACE1YBXYgWZ2B4OrZdISGPPrUgtToY2 kOGXAPIngxX8ADlsJLBdjHWeK6EMHVjtWtdrSaxxQQ8g9h6nRqKJwO2WRbpdXXtx0lv2WRM+Wq1l gZT7DR39s8A2sbitbv3bnRu7sBsHVZtbIGzw5KTSSVZ8BO3a2tYCfi/D0PnsbEQUdECa3ppx+ju+ W51JMd65huFWOdaeRVmlTWbNZ5unS/KJYsiLQwlycHOiCi9sa+5BYxFjhYtyjSi/8c69pnPOXVu1 vPLqRYRukAxwofcRkszjkIycSUyHg4KGNGqYlMi22xMMnq90XwGBpfmXnhxGm/aT7giGgDDDaAMK S96wQGKLScEkRXj3/1L6okUVw5Lga9dj7koqzbVPsUd3UE4+HN1xDRd4FERJMoKDMIli9G6cMdRL vxCUpoxGbRf6qk8GpAVlUg3bpRoKqZki3LsPJNrefVAlqfVgeLFKT79nlSbZGJ0JfFw+4AjZzVc1 KYBtitbebG0yIO1CTXt4Ywdox7BVm4nGJ/OHLsxSTF0rgiliN9nQPLH33ygshK6PTBeu19apQE4W /mbgVHPUiXanXOuGwKlyrjybo3rIs2cqo47DWMXI95raev8PUDY1Pq8qWyl4mGFuaaG4nJ0iWZul gDGW7jWxHRst5/10i4YqGFaDFUDo2d4g1epfR9BqmFQHKizrZ4P9TCyahCg0Gu24DNC8+BscrAKo /J1HlOBs+gFlONvby9OTo7PHDGeTXYHq322CEWLocuYDPIy8YtHwH6rPINxOXP2HlAZrZjJ2U2Ow r0a9XNYJoIzVdHFqPt4s8EWZe4NBuSqHW2tiDKxt+A8wLBAWKGyLPIxYRLscQSqj8AT2mzR9GpDF PM4IMGpyH5oxNIIEtjtCaAAFsglcYwHkCVGh/ZBE91Jm0SUitt5O3wnZUu+PtZMghUQ1Y9jNRMg+ ZEA23YcMGoUMnn0vZIBxLB4n0frJTNJZGsGIngG8mYY06PV9VAhKY78N7+KBBRxFqEaAM4RPAOHS XWURtYKwYPIKYMcAzyQDQnmLY/kAqta4ADRF7a8I6CCy7/jUKqj2oTvFIyiV0RZEV5lD4wV6zcaR 42Rx/LCI116rkE/umRoxfEoUv45+F6unHH+dIgF440FEBN4Y7XcJGhgOQ27bqizMyX3YRDNrtwKt 29V1yEhAV8+Na1WjvledeTiBV7HPTOYWg3ws9b2K0N3BfGa31Op2dX1WNbpdtWs7ea7M1RuU0Flm s21V9Vtq15bjVwRcYXEae2ybtQs7vt92HuTaZuM1TN/MY0fXgMXUdzAKWdXQWendHCn9mT+ZSoEX egj4sa7yYoOHQeW48ph9ExnTkNyEX6tibT0gMPVBerZf0mgVDEvHRQChTWRBrxmbDVPzBvuHWgJs j+pwDRIfXSQlN04I1iUMMu+bzS7yRUXjjRkH6zW52Xt5e+RVUyYcjNVUjplZlCvWr/dNNfjBkGF4 wzgOY/Ve09qeepWgSjuBjQEq3qKgI5j5C8exFbOxiYKTxK0NWAIG3MQysGk45K4kq1rResJmpQhb i51I3i7ajiCmE4HhiflQgyJmXgxrZKcsv422VztbZO1NbkZuFuOyF1qo8EogMuRxkfZBnCdFtTlI 62J4TegTYzeokjukBY372oyoNSa2Hmml+ZjldjA2THMvn1VcimEaL9Br+VzEDY0tt6K59N+XnKNU Pc9pftz4AZxNkp5Z35K9Yyzba0prw07MMGPbzai9D1aSaPcMVhbgFwQqr8F5xiGAHcec0ab9SjaR m0YL42x6zZJaoRs7bsaNNfK28Jxzu8H/E4qMYYxlN3TlYg+piLwk7kzLvxmp9xe/uPjd3sZuV99o 0Apc/sW63DenIuqMYV6+KZ1hi0taTZ/t+E7bme7bl3o6YoU0OPE9DkIBc4mEHxQFhg6w8+gsXvhQ hsjtNblRImBstpnQq9Ev9EnR9CX2oLiR/5agC4DxKccyH1jqt7ar4AdDCo2zlQgauc98iS89gN4X B1KNWeAEBbuWB4ChwiWMQ/NdRW/3qUhe2YeXFCKHjra9EyJn6A+ZVmkuqU1Tod8iYjvxb/BwMRpV vKwimC7cLILZuBq9JqpoIMQ7jB03E757i5NEk/vdLYt0u7q2OAVq8KIJH62FGnzxgNC6H9Sg2313 u7qmeo0FlIMGzurt/OgW2T5Jk9xmASECEnxj5LOSHdjxfbaz8mcYZO34UfYQ+VdDejtNbecro/W6 oYXS3uwqlkc36QDobJ9xYXpN6wqfGRtvpnHWUxyJEva8IbmDjAMKKwsxKbVpMdhW62aov4u+NPpk M2ADsE/G03py2nW02zLx5FqhkQYaiOOs+C9aUAbI5BJSNrPDQz88hJl8OPNdlzX96u93yQfZKLO1 LIPhz2Is9Bqk3a/n7wjkpeIF/PPz5dsXZ6en/7LQ4fSrKcV6wl4sjV+1GICy4qwQ/GNcqTZyBHgB ZYIIR8mwjFmGwkMkqTQ4Bj7uk8Tj2ZjRil6TWltmqBEuQ4TolpL9zo5evPzXT+Y9a3UMVpn9d7GX 2b+/rrYOpdKKzguIUN2gCLEbNNmypoA0qqbpDEni91CdYTSguhxEVcSI2J5Qoa03t+PUd9i9EmQN MoI1YLR8TB5qllQuxRouEJ3czCoBC6jGLFrhGHvvtWTTh2HseA01m3dnEVQDQsvs+gUtIVYpWoag /40C7Jhislvidrt6Y2Po52p2fhHFUuo2iaNszokxkFCWvWCTIYSeed+SQQ0nqLg7W2NmiKjKs2Ld 7uMqfjU6Onr58uzNr0bDD+qPQGDxi/NbO3g1uoOpHi3YbQTcFqtQeHrxT/HXZESKx8x/FsOgQvlX aAd3qAN9as7U6pZP96tDIOpz56nv2MjYl3UhruXIxxtPVcbOg+gO7Dak+ZpeeOvHUcjEp+kcttNy aoIXvPDCN1WdsiiDpVUI+sBw8HsM/8lzd0npNVY7mB6q66jQuZMTsmguAwrmpMguY3P4VjfHpytU S+luBUjj/VZEPZK60fh9TIlPKNar0Xo3XGa5NfloM1tU8sbQ54zikZeK8Cz715ZDfHn2c1CIlIIY 26O3orSa/3xD5AkFpZircAbQr4Fj+eCzTJVtZazba7ZOvPjWd8wYTzOJSdi+Gb9YDiFm2pnhyjtE LhMD8BwOh7TV0Fkzsq6P/BfeNOMU7D3mAN6DxEtqf6UeykJ2I/PsBP2bIE8m4O8kPRgOqX+UwNgl ff5IxNDPVwwBsX/+stMiwOZfkLOCYVE2pIogdCXI80g2atyumru9Gs1ncxaYqNuchZ0nTwTwNsek MiRI7ryY+DUaFxLYF/MUYKCZ57JMzXj1XpOb40K26A5A+Hrsqw1WViTVoCLowg/RgolvNHlSPkMF 5tlrMid+mqlyaoO1am5FMwtZD0/m0DfhZT3Lt2i9ydGRsN0eztYquPP67dnl2dlIe/7vvLGdBelq AOCq9KOLv2BvKsgz/5LeIQubh4E+XP/x+xXguFLLCI8wbz+r/rRB0Ihsci8cZROCr4oh3osmn2x2 VJwKKCMSeVarwTT4yXTLP9vhxJNXAbF899Xo+CSnjia9cR4kcR5Ha0A3OG8X1yyly9JphBqmYnge OYSBf8hFrXCMjXd+L7ez+RqzUefZVwKcG73e7bzWBfqy+Z5ZQrZRKmxpadN4M3tEg6+xylom5C0/ en92/PL1Y27wLFcLvI0Gz91y+H518Lvm6JIG0T/avrohxRupECmQ+vXcQgBQZtvdoL0Bxvr4HBTC GkUb6SUR7IyV0Jqk84nuiwOyH5U68f98aJFyjVhe9q60b6IsRdMlGPHljoG6Zhw9lgaESajgcTcq CpoIde2Zi0GBaL2YN1CiZW4BC4w6KV17H6HHmPhJsFqYqtst0+B7+3u4ZpenXsAVjxbmflvR20b0 b8aKPttFW3z090EmATJkMY0KTBlxAp7q960aH/imDdqtqvjB+QPhMoO9WpEbkhjiGuIBrhf70pSF B36HMCBmaTtACziOADTUXEdj/V6Tu0QPY9PNiM7Y9qcxA6txwp5goQAt4ICizY128AWOYTy71wRV 4Kkt60ENxFqGt/008YIx2ighUjj1grmu0x4OoXXjP2PHzdi2xtqQrJeQulCKpm/ULeN2u3pjsV8T 2H7yBSjpPMslBvKcLm+1zuaR7LEJz60Gk9phdi+e/mQs2y2p9qtD1GjfdPfc1dOjOhCUzxQouyDk Y3uQe9aQnUMB6vj2kFypmYc46BYrRkR95L1SCGfM4DjBzkQYkbloK1fbCl+BLMiwRodw24YMa6Wu wyg8rARe0KQvtoS48F6RXD2Mxoc5cmMXy7+6FaLNNXoZb105v9qcxakxUJApB7NbRZF4oLfLUpPB obRzmYDSjwpN1+YcmmWYljOKQuCoAW1ln1VGziQ7mODLwGWcIfXDjILJWPmRsKPxzjUSZNX4qjSq rvlcMyp7gG0JcFi62Eoyr/JS5WtRyqHoS1E2HC5fPz/79fljzqHIrsA8+xzKnDHDbszC3bi80vLj rHIZ1sqz1RuKWNJlgCYIqudrk2c0u62sBn+vZiuueXS3dOt29Y0WADNfp8fiSsBhEPw1IB8+BgBY SygLB7rxt4UfoXJgtH4rQnfHd6tTBU1Yb5V9dTzK26I3wexiwkb18yxGyhEwtRvocla35f3UzKEM xov3mtjE/hu7baXPHWBfpui2ihaB8NXwjY2u9KAxiA/YN+rQxEIt0Duz/A4YL9BrcrftRKsm2k5B X+TKFUlVMRYcNgwq1DKFI8tilPztHmG7KPBPkFVBUsogRjM2v2D/UEgNZA/zMUUii2GU4md51IG+ wRTzAnJJYqzSb16uAE6bkbQuZZARwG3fYvICxz1Jdhy6MS/pV3ARySCbytE81F6Tu+JjtqJ2PnN3 ycQqhplk4zF6dlFkoyYtZFcFAhcoypm8Hw5rOwGJYDJXK4KDhFI5Y6PEEYLaAIiUBAnSOmtkVa/Z Oo+rGLzVitRZiH7ESRRCjNwRVeYQTFYIFqTU57aTc/UksrIQgeXHWUYroUBDQOaGVSVACOWlWcyg cq/Zqh0co0ZJSZRqKRnzWTaIuQbguNQa6fyP+G2jR1kONzJYpOYirvpsuHLBQzISF6MDuAluiXQl C3kkvxKk6MD0Tz5yeE2UpeZEmgVw6AUrf5c6HXAutNORrg2Ck1Nzk/dADcrFRnBmHeaoAWq8Zu0h a4m09AVqQ1WtMP6TONG8EuHotUDepvlKVKdOgpVnWYm8EFEE/+GjdNTLIw4k9qOUxw8Tx5rjmny6 mehgZAcCQ3EwZEZeA1qcQh6MgIABADcYEGD/oZqvxsQQsQDufZ1YReWu5nXPPVACBYfB0KX24oxT 7rUQWZ0g0Eof6muiik/yaCWJr7rDcjQyQz/SH2UBVxiexICECKSswVmtSP3u4x/vLbO93JRtfgIM TaExwl8xhKljxof6bIxX6DVz50bfg1AM+4ER5JP7mW1im4ljgT6HmGk8EtmbjHDf0f4Q3VppZhB2 BhEgZ0NbWSnA4TClDAs0tttMDOwZsmDIboVWt6s3S4yfrMPYAuwgczRsDAsmtFSUtLqHjOhVtdOO 71P7ik2u0mp45YdEswitykLfkTHiDMJQ3tnBhOPGp7OEok8RfXiqmMC+ODLTp3u5B1gaiLCx+8i9 FbHRhriqlZXCtdTQWnKpfQOGZXsP4yr1+vovL6Wx52YcWeNoqgCgA/cVTWNUuhWmjsIaFZ6lCyHw iIXtp7eHX1RDAc89vMROpVvd639c7YOc+pJ2e2+6Xb2ZcXL6fePEVd2blooTahTBsQqqasc32s46 wYQgl7X3d1uVTsUkyf1l1Zd1I8PqczQ06jXMulGAPivIp2nrjr39i2Nj/GVPbUy1Ut3TNLW7vbPd rr6R0wTQ/KwiGvOu3jWem4O+xxNaE8PzJyAgtycbWepotN+48dKFB0ioF4hdrOvAkGSEHxOqCTQ3 pnDece7ScqwJ0dZ5y9KcGJ1H44eN360zmanYXRnbpBtVic+sUYp7RaVF50bxoQ+4JnUuTmAp6MFO nGiAagNyK/2TwkODM3rNzcvKXGPPrZw/geWjsQwyMEFEeBxlBltTqV9oJp9Frj8ekOBw0LQTHaW2 R2e4msnT6qifhlVcT7ynk6cH1qfYh9I8/BAl6VYnAcoVcyNUwjCVXKhsY++9vlcL2+TsVhdK6ovM 3oWS1lSd81UzJ7lNDLdyRt1mOp++OHr/5nRdl+D8N5j8tDhHi9n0CqCL8zjx3c/sn5H/VmJ1ky9/ 4lcLdr49eXbEZ03x9fOX+Fo+PZ/8gcF56GkXzfHzZ+pPwHBTdCPW395EaRrNlt8H3rj026lnux5G Vp0dveTjxxHaMyy/nWQwqjnQSi3nRAFGzJ4nQOBi7Ak/Im/hRs5vsc/+qIEfeld+6uAtsQ3+Fiyo tihf3kTunXyBj2SMAV78rwAAAAD//wMAUEsDBBQABgAIAAAAIQC2X8ARyQcAAGEiAAARAAAAd29y ZC9jb21tZW50cy54bWzcWt1u2zYUvh+wdyB8XcdWnMSO0biInXgN0KJBk2LAbgZGomMuEqmRlF3v qq8xYAN2tQfZo/RJ9h1KcmxH8+QuGbLdNKlIHpLn5zvfOczLVx+TmM2EsVKrk0aw124woUIdSXV7 0vhwPW72Gsw6riIeayVOGgthG68GX3/1ct4PdZII5SyDCGX78zQ8aUydS/utlg2nIuF2L5Gh0VZP 3B4mt/RkIkPRmmsTtfbbQdv/lhodCmux34irGbeNQlzyUJpOhcJeE20S7uyeNrethJu7LG1Cesqd vJGxdAvIbh+VYvRJIzOqXxyouTwQLennByp+lCvMg1tU7JuvPNNhRirwO7aMiHEGrexUpvfX+FJp uOK0PNJs2yVmSVzOm6fBwYP9lleuY4Mzw+cwxb3AB+IqlBHli5I41wPZ996qmxKD9rbLFBYhEcsz 1DnC+p7lSRIu1VLMl6lmVbmIiH/i398YnaXL46Tyn0m7UHdLWRSYO5ysfeQjb/VqdicBD0L3aspT 0WBJ2L+4VdrwmxgnmgcHjDyyMbgHCzbvy+ikAZSZ93nmphrRdm5kaK1W388C+hxxh8XAh4NmEDTb veug2+90+u32dzQqlXSSxzjv25HJfvKyU3wHgEXvIbh9iugfDmmq/3QmJjyL3coInSa9NP7HlVvE AlNnPD5pjHI8uxYfXaM1eNlaTvNzTb7EVC15LybCADZFsa6Yy5XSzkMCJuQSc1G0txtcSaxgnz/9 Emseff70K5OWYQELNfBYRC8YdywW3DomHbNTncURuxEs5cbFC8xK0lhy5fAt5JkVTE+Ym0KGwRqt 9ugCzl8Dm9Jl/L9YRoj10CRe97uY5PB/aJJxZtxUGGS8LFq8Yt9OYQKkm1c76nJ/1b1zP4WTVTn2 4XFtLXbG3fPDcZVjFyPPxrGHAimEcXb1+t2HN2cvmFQsWTCdIna1YmfvLkbk6ksHrvJUuGsZwRS6 T3H3Uv4lIGi5A+mwjPSxJnIDnLKhBFiPeCxvjCQDTE+VXf8SApDKCYj0ed/+hHkeVvb3CRXoy4ik rXxDUBZ7OSI9fZvyENCXGmGFmYnGYKTVRN5mxmPIH79BaVoh9I34MZNACOZ0DhYszYxgEoAgKLj9 dGZTEUoQLujaZsLusR2duFPbiTvd2k7830Fn4PKawuCRRuvJuTEwolukMNSt4cmVAxznBvbY7gZz ibSWuTqLz1W0urTaCWDiFS+gPLEmOkf2jXh5KjW7wQWLtM9SmYpQNVBlwOYEk/i80Bl8E6kQjlkj qJ/ukCOfK+k44mMagwQiMXK3K4of1g+A+ih+1gvGwTFJ3qQnxcizQfH3ItXGEZIrHQm7q/ZQgd1T vC05sNdvH9WGj6OjTnffk8dN7a2PXBKkF5/+UqGvr9++uYS/+nLSiTIUC563hv7XKGcR8IkEuX1N 4E+X81mgciS0YBHLBUMZyTzMQx1rg5U+BwTjg+PuGQnyk0c0dtKIUNAuE0Y59e9TCKFAcXC6b5nC HouslvL+W0oh/gv7EIBa1OmGWAeVJpQ3I+GEgT3B/qeC8AH8GbSbqDjNj1BlgKsgpRp8Rt41aItE 9gW7ydz9CoVSwWdjAZIOPkNZ9oLxWyMENkISIEg02MuGRqZeIkg6MgtwMxYE5cs9pZrUwcx1N3+/ Ut2sj9QKgNF6wbN0m3/bTZ9uP/KAIcwA86oXZCFfMqHqioQ3UsIXVFLZ7OYHEWKaBleFX6RG5CSq RhZb1/vjWqQ6qp9WXRds7rOnhWp8Ofl3VB2HhGKri8pu7SQQtOsngdOj3vicJD9IAvnIXyL+hsNX q/cRK/wL0qC6+6KS5+iJbplDotVx5vHo7YeraxbLBC0GwkAAHkcgAKW4WoITKg2iAFTH0RwlHNpt d3Vi47HvQBbz1i2N7/P8Y+8Cx6JNVshubsY53R3KKJPETCw4tXBslhJVIvgAmJQo4/9fNGR8vUYh UqW0bQGE7ntNFrVfvwgbdtrBWWWLrBh5LgFUXRAB0D9/+p3BGlM+EywR4ZQraRPS/50QaR5u3mPd FD3X22mauTxzK62avv+wVkLB3qv+NDxuD7unDe8C1ScwS2q8KWfLoo0DsbmMY/KXLPV5Z61432Pf 5rdTnz/9jP6fCuMsgudxtSBXvAXpwFtD3gHwLuZr/DJA0Y/Hi0tVmbjN1XxRUjYAtxL2HVxtHHSO ziubVsXIc3G1wRU4W5HH0GVhQXfNtDnwbFNfsNbT3qK/bv8ANU/NbnZv2B2NfDtxM9cVI89GfwXv 3VVra23nLVrr9TtBba2Nxp39tucem1orRp6N1i7zZj6ISd7Mr1DfRmvnqe7mBh4Y35VFEBUk9M5K ZVAIMkBIZQmCYrwvRKDNC4baKDUSVNksfE5s3vAYCZHwab0XaavS3r92rzdU061ep0ReztI4s4S+ hKFVZ9wa8HW7/L3+Qf3nq/Z5N+idVpHbYuTZuO6FpXcpiTYgnuUjcBt6KWFoaTadbuILsyJkPhXt 2joK6raeodmD2qAwPj3sHvue3iYoFCPPRbPVnOOanvaKejWR+HuJok6lkLTUU4h0ht4GNRWI9TgX +zhUzKIvgQi2D54A5v0bre/oLyh8ExsUiJ5m8V6L3xSn9tX33+ghD+/y5lU5GRa+n1q8kw4It4rs ufq7HfwJAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29yZC90aGVtZS90aGVt ZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV 2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTx eUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7M RYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WN kFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcb rStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJY ogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPt SvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHN C0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LR F9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScj cb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46 XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S 6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6 nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byB OS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zERW+ vE64E7+DKRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV5cz2iUK9CHeyPHe5 COjbX5238CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKue0wZG6gpIzekabwl 7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVKuYTDohmupK3x0Pgr e9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6M7e6Ec0URYdbobI2 sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7Ses/7qG6clMfKnCJa DxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL0FHbazWXmx7ycdr2xnBO hsc4Ba9L3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMHUiHVFpaRDQ0zlYUASzQnK/9y E8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSulfKKIGETBERqxidjH4H4dqqBPQCVc d5iKoF/gbk5b20y5xTlLuvKNmMHZcczSCGflVqdonskWbgpSIYN5K4kHulXKbpQ7vyom5S9IlXIY /89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7AhoHUzsgWuB+F6YhqOCC2vwX5FD/tzlnaZi0 hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7LEmWETIRVRJXplbsETkkbKhr4Kre2z0UQaibapKVAYM7 GX/ue5ZBo1A3OeV8cypZsffaHPinOx+bzKCUW4dNQ5PbvxCxaA9mu6pdb5bne29ZET0xa7MaeVYA s9JW0MrS/jVFOOdWayvWnMbLzVw48OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11yPehtiL4eKGJQdhA VF+yjQfSBdIOjqBxsoM2mDQpa9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz2Tm5eJHGzizs2NqO LTQ1ePZkisLQOD/IGMeYz2TlL1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPktR7N04y8AAAD//wMA UEsDBBQABgAIAAAAIQBdbV+w8QMAAFEKAAARAAAAd29yZC9zZXR0aW5ncy54bWy0VluPmzgUfl9p /0PE82YCuUCGNlOFJOy2mmxXZfoDDDiJNb7JNmHSX7/HgEOjoaNqq33CnMvncz9+/+GF0dEZK00E X3nBne+NMC9ESfhx5X19SsdLb6QN4iWiguOVd8Ha+/Dw+2/v61hjY0BMjwCC65gVK+9kjIwnE12c MEP6TkjMgXkQiiEDv+o4YUg9V3JcCCaRITmhxFwmU98PvQ5GrLxK8biDGDNSKKHFwViVWBwOpMDd x2mon7m31dyKomKYm+bGicIUbBBcn4jUDo39VzRw8eRAzm85cWbUydWB/5Zk524tVHnV+BnzrIJU osBaQ4IYbd1liPArTDB/BXQN9R2EetLePbFQoB74zam3XNNX+gPZbrP4SHKFVJtmKABrBSvij0cu FMopFFUdzL0HqKhvQrBRHUusCkgSlKPvexPLAGfEITPIYGBriSlt6rOgGAFYHR8VYlBZK6+lNDol PqCKmieUZ0ZIEDojsDmadpDFCSlUGKwyiQpA2whulKBOrhR/C7OBKlUQxNaItmatOe0pa+sfNDhi 4EVL7Wp6L0psLasUeRWoHwbaKjRWQjwaH4YvEtCvipQYXKM4MxeKUzA+I9/wmpefKm0IdElT2b9g wVsGYG5v/gzd/XSROMXIVBCm/+myJhMpJXJPlBLqIy+hNn71solLok0nDL9Su8MXIYxLg+9vN4v5 rkuGFes5/i4Klus2SrecWejvktkgJ412i3SIE4aza2XeooXrcJnuhnSWyyi5jwY5SbTZTIc4axi1 STLI2URpNIiWzPxgO6iThGG6XAyhJfd+Eg1GJ1nP/OlgRDdTfxN23Xkbg006m/qDtm2XQRrcD1nw 48ylwSzcDWYhXS+i+8YfqA9rAlQFi+1g/0e5k221EWvbdINYrgga7e3oh4Zlca6eE8IdP8ew+vD3 nKzKHXM8bhmaIUpTmEWO0YSAxSXRcosPDSzdI3XscTsJNUiFuffpimXnKFZ/KlHJ9rZaIdm2kLsu mM87PMLNI2GOrqs8c1ocxvd3rIqXn8/KAk768NSxga3fjKJHxI+uUzAff82sKHQcVZl9GeA9khJG Lojkx2DlUXI8mcCODwN/JbwQmp/8OO1404YHf5bX/KDCegbS3cEKtEeQ6g49beZos54G+6+Vm/e0 haMtelroaPBCqeMTzDsFy+cZhro7WvpBUCpqXP7liCvvFakNgj4hiSGvdjdBeYm4IXTLSo/OMX6B zYdLYuDhJUnJ0ItdhNPQqnfSFF1EZW5kLc8KyxvqqEQGgXqTqhtlSB1s0ltb6rjEBYFyzC4s71fh H63hlGiTYQlb0wgFLjeL6l2D3L8FH/4FAAD//wMAUEsDBBQABgAIAAAAIQAC0tENlgEAANwEAAAU AAAAd29yZC93ZWJTZXR0aW5ncy54bWzsVMFOwzAMvSPxD1XuLO2AslXrkCYEQkIIwfiANE23iCSO kmxlfD1ey8bGOKwSR05xbL8X2y/J6Ppdq2gpnJdgcpL0YhIJw6GUZpaT1+nt2YBEPjBTMgVG5GQl PLken56M6qwWxYsIATN9hCzGZ5rnZB6CzSj1fC408z2wwmCwAqdZwK2bUc3c28KecdCWBVlIJcOK 9uM4JV807hgWqCrJxQ3whRYmNHjqhEJGMH4urd+w1cew1eBK64AL77EfrVo+zaTZ0iQXB0Racgce qtDDZmhbEV1TITyJG0srEmme3c8MOFYonGCdXJAxjq+US/+1RnUmy5wMh/FwMBhc9pt4AeXqRi4x tmQKpSF0nY3DexBV2HjjrfdZzua/uKdgD3MnEALoH36sZ1K69RnhG2NQdIKJ/iMneDXQsIxjE43N QQFqxRYB2jLUTmXdkMVeRd2wbrfzLlDaiNA03Zr7ciRpepmk51fp1b8eXW7BX+rR6tK8E7BBavkh bsFNHNReuOZBMKWgfnq8ww0m7/xJ408AAAD//wMAUEsDBBQABgAIAAAAIQDvXa3VFgoAAFxMAAAa AAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzUXNty2zgSfd+q/QcW3x3rZsl2jTJlO5OJq5KM J7JrnykKsrgmCS5JWfF8/TQaIAnx2hDpqdq8yASBPn3DachB+5dffwa+9crixOPh0h5/GNkWC12+ 8cLnpf30+Pns0raS1Ak3js9DtrTfWGL/+vHf//rlcJ2kbz5LLBAQJteHyF3auzSNrs/PE3fHAif5 EHhuzBO+TT+4PDjn263nsvMDjzfnk9F4hD9FMXdZkgDanRO+OomtxAVVaTxiIWBteRw4afKBx8/n gRO/7KMzkB45qbf2fC99A9mjeSaGL+19HF4rhc5yhcSSa6mQ+shWxBUranDlyk/c3QcsTBHxPGY+ 6MDDZOdFhRmnSgMTd5lKr21GvAZ+Nu8QjWcVvNxkSgw+xc4BQlEIrIirccZGLgp86QcR3yKqZYnj UZsxKiJCRK4DRYVjzEyTwPHCXMxprtGdC/uhT37/HvN9lKsTef2k3YcvuSyxLQ00G81x5+mmJUYC Klt3tXMiZluBe33/HPLYWfug0WE8s0RG2h+BKjbc/cS2zt5PE/EYP8TqUT3hx2cepol1uHYS1/Me gUJASuCBwC83YeLZ8IY5SXqTeE7ty52YVfvGTVJN2q238exzgZj8BTJfHX9pTybZyJ3Q4GjMd8Ln bIyFZ08rXZOlnQ+tQe7SduKz1Y0Qdo5mZp+audGR8fCEqkSOCzsPcJxtyoCEgMUEju+J6E4WwGjy 4cdeONfZp1yBoAAA08XCY8njwE3AVCvJ2PCWbb9y94VtVim8WNqIBYNP9w+xx2Og0aV9dSUwYXDF Au+Lt9kwUSDU2FO48zbsPzsWPiVsU4z/+RnpWUl0+T5MQf35ArPATza//XRZJGgSRIeOiPB3sQA4 DMKh4aBCe6/QRg6UUHHwfxnkWMawFmXHHFHSLNS/FQit3vcGmgiLdANQrpGu0/4iZv1FXPQXgcnb zxeL/lrAQaZvRGRuaFlJD2rKXZl8uh+mVy0pK1ZUsqhzRSVpOldUcqRzRSUlOldUMqBzRSXgnSsq 8e1cUQln6wrXQeIqZ9EUvUHa2I9e6kOd7GC6cU+qU6XGenBi5zl2op0lCmtZ7TayXO3XKU1VpNPT yXKVxlwcNzs8AtVZbN2TOfm3INo5iQen8i6gnq5/FEcf6/fYg+NrB9SFTL6KTXgwqS1hD77jsh33 Nyy2HtlPGVGD9d+5tZKnjE7leob1q/e8Sy04FYqS2wk2b3B6syek/K9egj5orebzBlO6hJNiOG/I y2bh39jG2weZawinkbnkc4MwlyBQxXYXzUSIqrur0woRAIoJslyYm4DyCfrL4mIuX8SYor8sRSfK J+gvC9eJ8jE/2uNrzDSf4NcqFml7LYz37h33ebzd+9ke6KSHhfEOziFoJhhv4lw+iSQWxjv4iD6t G9eFb26UPDWORcGjBijG4ZAouNnothgHpUR7YwOLjANUwpoYYPXjWgMgY9L9wV498Utg02KALJ2f NTu387TBA1CCSGfoP/c87T5DTxo4j4pyH8KvSxJm0dCmDTuPiqbySdY7gxj3K3wGQP0qoAFQv1Jo ANSQH81nnrwm0kH6F0cDLGNazqsYph2ZmRfGzJwDmZWAgeom4fzVsHubc6FaNwkoxgGq1k0CinF0 SrUsr5sErMHqJgGroWo0x0jnVBOjjOumDpSfBAgWDUPeBKBhyJsANAx5E4D6k3c3yHDkTcAy5oac U3XyJgDhFJOv+jmQTt4EIGNukGynfmeU1T2U0v7ldgDyJqAYB6hK3gQU4+g0kTcBC6eYZEIJK6c6 AtYw5E0AGoa8CUDDkDcBaBjyJgANQ94EoP7k3Q0yHHkTsIy5IedUnbwJQMb0kAPp5E0Awikm3FBL 3rjr3528CSjGAaqSNwHFODolQs0PqQQs4wCVsHLyJmDhFJNkUFiY3CZGDUPeBIuGIW8C0DDkTQAa hrwJQP3JuxtkOPImYBlzQ86pOnkTgIzpIQfSyZsAZMwNteSNm/HdyZuAYhygKnkTUIyjUyLUnOcI WMYBKmHl5E3AwnzpTd4EIJxyKpCJRcOQN8GiYcibADQMeROA+pN3N8hw5E3AMuaGnFN18iYAGdND DqSTNwHImBtqyRv3yLuTNwHFOEBV8iagGEenRKg5eROwjANUwsqpjoA1DHkTgDAxe5M3AQinnACE u8gkTMOQN8GiYcibANSfvLtBhiNvApYxN+ScqpM3AciYHnIgnbwJQMbcIO7Zwn1R8vXUcUMSUO8Z ZLcayICThiBRAZWBP9iWxdBVyLpvh/QEzCw0QGxID6qJt5y/WLSL3dOGBCFDeWvf43il+w1v6WiN CNNFSyfB4x931hfZAFNZhyl1fPMGuof0diFsTxKNQ6Bn+hZBy06U3SwX0qBBSPR1qRYg7Am9h4Yg 1dYjFos+H5iITVVqGP/fVqHCz4CIC6tQ7g6wXOiIaoFSF97zO0h43b0M3HArHhUpWjIyNdXt+OIM Jecd3dFs1TsVN8FbdMab4q0+snCKjGpVQWjOQpW6NISQrX3ZYgY/3IcbsPCgurNkMDc/HSkK3t8x 3//mYENayqPmqT7bpvLteIQVsCRqzdOUB83rY7wgjprUCYB00JWRj8KI5jwJ98Gaxeq6eWNKisqB nWjHKSnvujakAtXTzbodbZd8g3x5/Pb1IWaynTllm4peYoJ1NAM1XDvQcPeH6J+rbChoFnzJxsvi 72Aj9U8maBMXGYTIo9HtfP758kJKVX2MkPfY4Qmf2TyRLGInRBzaTK/Gc5VtDRPGl1PVi9kkYrKY XbbLmM7ns/YZs4vLUfuMi9lVh6bz2bhD08V00qHp5WTWoSk4rEPT8WgE7aGYG00uG4+urjp0HY+v YCu3S5mAuh1TpotZl7qz+QWqK7a1ypak3P2K/6uvel9BIGSPeKjvfVV9tvBx1EC8tO/4PvagWeY7 OwgJ2B9cGXUhKfWJ6AFXXFLP8neE/6TdWsewMjP5S+sYxjGwC/qb28jqqKi5+wS4EjtzyzW0dg+X C1uFJqxiq5e4orZQosFtzCEtJ5egZopAr/y/hinn7TseiD/6UJwwywFxwpBDV7XocQZ6Vwdf9DI5 HGRnH3+XRpBj/99AH/ntrQyh8n+RwxkX6zksx7pzuL6oKedge1qLX1LRvlbnEv14qOekJrfI7vfx kipkBSWZ0lDh38k/wBFlz5S9rt5jx2BfZtCwepFCa1L2cVprUsKX0f8yt3r+0/ZroqbUpWbF+BCS OKsRlZc1yavw3zt/1S5fSxvuEvjs3s3UiqTs1E1pSjg1pznnNJ8VPmn229AZpzsIvn4Wfwqkx6at z79bx/c5D2tJUb2TDb11adfEiJrQwnv/ECOqP1GSn8vgL3ycfEh7dHY8cLTzWTEgjmbqCT1TxKhP 4aKmetnB5TzXI9ec5LQjl4Y1dJqXD8WFe9V5uBgYxt9ANnhWSj7+DQAA//8DAFBLAwQUAAYACAAA ACEAGKwXkYIBAADoAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAjJJRT8IwEMffTfwOS9+3rkAQFxiJKE+SmIjR+GJqe0Bla5u2MOant9tg MOODb727//1692/H00OeBXswVig5QSSKUQCSKS7keoJelvNwhALrqOQ0UxImqASLpun11ZjphCkD T0ZpME6ADTxJ2oTpCdo4pxOMLdtATm3kFdIXV8rk1PnQrLGmbEvXgHtxPMQ5OMqpo7gChroloiOS sxapdyarAZxhyCAH6SwmEcFnrQOT2z8b6sqFMheu1H6n47iXbM6aYqs+WNEKi6KIin49hp+f4LfF 43O9aihk5RUDlI45S5xwGaRjfD76k919fgFzTboNfIEZoE6Z9MEIZq2SH3tSt57yleNbKAtluPXd nci3c7DMCO38OzbsTsKrM2rdwj/sSgC/K9PFzOy+a8yvQnWPgb2ofkRKbmtJG/u1ahebaYEH3pek cfFUee3P7pdzlPZiMggJCePRMh4mvWESx+/VQp3+yqcmkR9H+x+R3CSDQZd4AjTedP9m+gMAAP// AwBQSwMEFAAGAAgAAAAhAFgulsmZCQAAa0kAAA8AAAB3b3JkL3N0eWxlcy54bWzUXF1z27YSfb8z /Q8cvif6tGR7qnRsp7nxTJK6kT19pijIYkMSKknFcX99FwuQhEiCXJh0Z5oXmSS4Z7F7cBZysP75 lx9R6HxnSRrweOVO3o5dh8U+3wbx48p9uP/w5tx10syLt17IY7Zyn1nq/vLup//9/HSZZs8hSx0w EKeXkb9y91l2uByNUn/PIi99yw8shoc7nkReBpfJ4yjykm/HwxufRwcvCzZBGGTPo+l4vHCVmYRi he92gc/ec/8YsTjD90cJC8Eij9N9cEhza08Ua0882R4S7rM0hUlHobQXeUFcmJnMa4aiwE94ynfZ W5jMSHo0Eqbg9ckYf4pC14n8y9vHmCfeJoTgPU3m7juI3Jb779nOO4ZZKi6Tu0Rdqiv8+MDjLHWe Lr3UD4J7CCkYiAKw9fEqTgMXnjAvza7SwGt8uBejGp/4aaZZuw62gTsSiOnfYPO7F67c6TS/cyM8 OLkXevFjfo/Fbx7Wuicrt7i1Absr10verK+EsRFOM//Upns4mTxcoSsHz4dkAI63yxiQAjgicMJA cHC6BL7Ii69HEVfvmHEFggYATDcLl5WIA1eAOWtJYHjKdp+4/41t1xk8WLmIBTcfbu+SgCdA0pV7 cSEw4eaaRcHHYLtlYr2oew/xPtiyP/YsfkjZtrz/+wckv7Lo82OcgfuLJbIgTLe//vDZQdAWTMee yPAX8QIQB9Kh4aBDx6D0Rt6ooOLNv3LIicxhI8qeeWKFO+h/KxDO+tgbaCpmpE8A7Vr5OutvYt7f xFl/E0jefrFY9vcCdL1vRiQ3NFbSk5pxX5JPj8PsooWy4o0aizrfqJGm840aRzrfqFGi840aAzrf qCW8841afjvfqKWz9Q3fQ+GqsmiG0SAt7PsgC5l4v1WAJj2lTpUa585LvMfEO+wdUVirbreJ5fq4 yWiuopy+XCzXWcLjx86IQHUWS/fFmvxrdNh7aQC7pI7QT3uG/l7sepz/J8G2E+pMkq82J9yYNJaw u9Dz2Z6HW5Y49+yHzKjF+1+4s5a7jE7neqb1U/C4z5z1HktuJ9jCEHRzJKT9T0GKMWhdTAvDVLqM k3K4MPDSbPwz2wbHKA8NYTeykHpukeYKBLrYHqK5SFF9dXXOQiSAMgVZLuyngPYJ/sviYm9f5Jji vyxFL7RP8F8WrhfaR36059daad7Dl1aHtLyW1mv3hoc82R3DfA10ysPSegUXELQpWC/iwj5JJJbW K/hEPp0r34dvbhSeWuei1FELFOt0SBRcbPS5WCelInsTixlZJ6iCNbXA6qe1FkDWovuVfQ/E78Rs iwGqdLHX7FzOM0MEoASR9tC/H3nWvYeeGjSPinIbw69LUubQ0GaGlUdFU3yS9c4ix/0KnwVQvwpo AdSvFFoAGfhh3vMUNZEO0r84WmBZy3JRxZB2ZGVeWitzAWRXAgaqm4T9l2H1mrlQr5sEFOsE1esm AcU6O5VaVtRNAtZgdZOAZaga5hzpmmozKeu6qQMVOwHCjIYRbwLQMOJNABpGvAlA/cW7G2Q48SZg WWtDoam6eBOAcIjNV/0CSBdvApC1Nki1U78zyuseWmn/cjuAeBNQrBNUF28CinV2TOJNwMIhNkyo YBVSR8AaRrwJQMOINwFoGPEmAA0j3gSgYcSbANRfvLtBhhNvApa1NhSaqos3AchaHgogXbwJQDjE RhsaxRtX/auLNwHFOkF18SagWGenIqjFJpWAZZ2gClYh3gQsHGJDBoWF5LaZ1DDiTZjRMOJNABpG vAlAw4g3Aai/eHeDDCfeBCxrbSg0VRdvApC1PBRAungTgKy1oVG8cTG+ungTUKwTVBdvAop1diqC WugcAcs6QRWsQrwJWMiX3uJNAMIhLwWymdEw4k2Y0TDiTQAaRrwJQP3FuxtkOPEmYFlrQ6GpungT gKzloQDSxZsAZK0NjeKNa+TVxZuAYp2gungTUKyzUxHUQrwJWNYJqmAVUkfAGka8CUBIzN7iTQDC IS8AwlVkk6ZhxJswo2HEmwDUX7y7QYYTbwKWtTYUmqqLNwHIWh4KIF28CUDW2iDO2cJ5UfLx1ImB BNRzBvmpBjLg1JAkKqCa4Fe2Ywk0WbHu0yE9AfMZWiAa6EGd4jXn3xzawe6ZgSBkqGATBhyPdD/j KR2tEWG2bOkkuP/txvkoG2Bq7yGlTk/eQPeQ3i6E7UmicQj8zJ4P0LJzyE+WC2vQICT6ulQLELbI 3UJDkGrrES+LPh8YiE1V6jb+v61ChZ8BEV+sQ/l7wPKhI6oFSh14L84g4XH3KrDhVDw6UrZk5G6q 0/HlHkqOOzmj2ep3Jk6Ct/iMJ8VbY+TgEJnVuoPQnIUudXkIKduEssUMfriNtzBDaBLE/zWTydz+ 8KQpeH7DwvCzhw1pGT+Yh4Zsl8mnkzFWwIqpDc8yHpnfT/CAOHrSZADooDsjL8UkzDyJj9GGJdDh 1RLzL1xUDuxEO6WkPOtqoAI10mbfTpZLsUA+3n/+dJcw2SyasW3NLzHAORmBHm48aLj7TfTP1RYU NAt+y+9Xzd/AQupPJuiaFQxC5PH4erH4cH4mrao+RuA9dnjCZz5OkEVk5cBTaCqcLBTbDAMm5zPV i2kyMV3Oz9ttzBaLefuI+dn5uH3E2fyiw9PFfNLh6XI27fD0fDrv8BQC1uHpZDyG9lDkhilkk/HF RYevk8kFLOV2K1Nwt2PIbDnvcne+OEN3xbJWbEmr3a+oT6r3FQwCe8RFc++r6rOFj5MG4pV7w49J AM0yX9iTsID9wbW7PpBSH4gR8MUh9Zy/Y/wn5611DKtppn9rHcN4D+YF/c1tYnVS1PxjClqJnbnV Gtq4hquFrSYTTrnUK1rRWChxwm3KIWdOLkFmicCo/FfTVOj2DY9EE365w6wmxItjDl3VoscZ5F1t fDHK5HSQg336XRpBTuN/BX3k19cyhSr+JYdzLdY5LO91c7i5qKngYHtaS1wy0b7WFBJ9e6hzUrNb svt1oqQKWSlJtjJUxhfaCXGSenzlve74UjWiGplq1NVz7BjsqwwaVi9RaCVln6C1khK+jP7J/Pr+ T1uvqRrSRM3a5GMgcV4jag8byKvwX5u/apVv5BxuUvgcnG36VEyEU2PMnNNiVsbEHLehGacHCL5+ ln8KpMeibebftReGnMeNoqieyYbeJtqZFFEzWkbvX1JE9SdKin0Z/IWPF2/S7r09jzxtf1beEFsz dYWRKXPUp3BRhbUa4CrP9cyZSU7bcmlYQ9O8uikuw6v2w+WNYeINYoN7pfTdPwAAAP//AwBQSwME FAAGAAgAAAAhAFrCZ6ATAgAAtwYAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWy8lFFv2jAQx98n7TtE fi+xQ6AFNVQtK9Je9jCxD2CMQ6zFduQzpHz7nZ00lUrRYJMKUhT+Z/919+Pu7h9edJ0cpANlTUHY iJJEGmG3yuwK8mu9urkjCXhutry2RhbkKIE8LL5+uW/npTUeErxvYK5FQSrvm3magqik5jCyjTQY LK3T3ONPt0s1d7/3zY2wuuFebVSt/DHNKJ2S3sZd4mLLUgn5zYq9lsbH+6mTNTpaA5Vq4NWtvcSt tW7bOCskANas685Pc2UGG5afGGklnAVb+hEWk3YZpcEKrzMa33RNEi3m33fGOr6pkV3LcrLowSXt 3HCN4pLXauNUDDTcWJAMYwdeF4RmdEUn+AzfnI7Dk6TBQVTcgfTDQdrJJdeqPr6q0CqALtAoL6pX /cCdCgl1IVA7DOxhQwvyzCil2WpFOoUVJEfhcTkoGSbVfWb9mfGgYOdgYtEnHmGz6IMK+vS3Yp5p 1zonJNZKS0h+yDb5aTU3Z4hkdIokJsgjkBlfRcRF30jwUiKYePY41I+VLFG5vctZX/9VRDqfy4ks 7d4p6QKTMzRukcAs9kegkV9FQ9utdOaDBinVi9x+0B3nWIw/g8WaV/jvncHwhE0RBiS0Rf4pY5I9 v2+KKZ08vQeR/W1MGGVXNwXXuC/OkQhj0XEIY3Ldwvi38ThdGDQf2LyNR1wPuGb+Z2H0mwMWfwAA AP//AwBQSwMEFAAGAAgAAAAhANL6zm6JAQAA3AIAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASig AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJLLTsMwEEX3SPxDlD11Ukp5aGqECogFL6mh XVv2JLFwbMs2iP49E0JLEDuymrnjXF8fGy4/OpO9Y4ja2UVeToo8Qyud0rZZ5C/V7dFZnsUkrBLG WVzkW4z5JT88gOfgPIakMWZkYeMib1PyF4xF2WIn4oTGlia1C51I1IaGubrWEq+dfOvQJjYtijnD j4RWoTrye8N8cLx4T/81VU72+eK62noKzKHCzhuRkD/2ccxEudQB26tQuSRMpTvk8ynp+w6eRYOR nwMbCti4oCI/ns4KYEMNy1YEIRMx5OXZ7JQGIwWuvDdaikR8+YOWwUVXp+zpi0TWOwAbLwGis0L5 FnTacrIat3CvLYUpT46BDSXFC6IJwreRz0gdtbCSwuCSKPBamIjAfgRYus4Lu+U3QcsYnaXI30q/ x2t88ZW77nF9//pbHJ14o1O78kJSrGk5n5+Ozz6awYoYoaLD7Bx/BLijOwqm35a42QbVbs3fQU9z PTxWXs4mBX1f+HYaEdi/Iv4JAAD//wMAUEsBAi0AFAAGAAgAAAAhAOc0ba2NAQAAEQYAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABO AgAACwAAAAAAAAAAAAAAAADGAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEATkHa+zIBAAA8 BAAAHAAAAAAAAAAAAAAAAADqBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQA BgAIAAAAIQA7W9g+ADYAAO4gAgARAAAAAAAAAAAAAAAAAF4JAAB3b3JkL2RvY3VtZW50LnhtbFBL AQItABQABgAIAAAAIQC2X8ARyQcAAGEiAAARAAAAAAAAAAAAAAAAAI0/AAB3b3JkL2NvbW1lbnRz LnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAAAAAAAIVHAAB3b3JkL3Ro ZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAXW1fsPEDAABRCgAAEQAAAAAAAAAAAAAAAABg TgAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAAtLRDZYBAADcBAAAFAAAAAAAAAAA AAAAAACAUgAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA712t1RYKAABcTAAA GgAAAAAAAAAAAAAAAABIVAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAA ACEAGKwXkYIBAADoAgAAEQAAAAAAAAAAAAAAAACWXgAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAU AAYACAAAACEAWC6WyZkJAABrSQAADwAAAAAAAAAAAAAAAABPYQAAd29yZC9zdHlsZXMueG1sUEsB Ai0AFAAGAAgAAAAhAFrCZ6ATAgAAtwYAABIAAAAAAAAAAAAAAAAAFWsAAHdvcmQvZm9udFRhYmxl LnhtbFBLAQItABQABgAIAAAAIQDS+s5uiQEAANwCAAAQAAAAAAAAAAAAAAAAAFhtAABkb2NQcm9w cy9hcHAueG1sUEsFBgAAAAANAA0ASAMAABdwAAAAAA== --_004_087A34937E64E74E848732CFF8354B920985724AESESSMB101erics_-- From nobody Sat Nov 8 17:17: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 77DAF1A0075 for ; Sat, 8 Nov 2014 17:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ2R8ylaIeiw for ; Sat, 8 Nov 2014 17:17:00 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B5D1A0073 for ; Sat, 8 Nov 2014 17:16:59 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-41-545ec089149a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 94.7C.04231.980CE545; Sun, 9 Nov 2014 02:16:57 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.145]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Sun, 9 Nov 2014 02:16:56 +0100 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXWwkg Date: Sun, 9 Nov 2014 01:16:55 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> References: <545792B6.8030502@usdonovans.com> In-Reply-To: <545792B6.8030502@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/mixed; boundary="_002_087A34937E64E74E848732CFF8354B9209857284ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM+JvjW7ngbgQg7nP+S3m9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Mvo+1BU0fGat+HFrFWsD45F7rF2MnBwSAiYS 1y7vYIOwxSQu3FsPZHNxCAkcYZR4ePQllLOYUeL/ut3MIFVsAnYSl06/YAKxRQR8JY53nmYB sYUF1CWW7/zFChHXkOg7spoZwjaS2LZsLyOIzSKgIvHj3Hf2LkYODl6g3nvXrUHCQgK6Eu9u vQUr4RTQk7hxdRqYzQh00PdTa8BWMQuIS9x6Mp8J4lARiYcXT0MdLSrx8vE/qGeUJNYe3s4C UZ8pcWzqN7ATeAUEJU7OfMIygVFkFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha6AaLiC7k1Hi dMM9VoiEncS9L0ehEicZJc4c/AfVrSgxpfsh+wJGzlWMosWpxcW56UbGeqlFmcnFxfl5enmp JZsYgbF4cMtv3R2Mq187HmIU4GBU4uE1aI8NEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjG021+POXT8oqt/muOJBwH3uJXzBc4sktmi7uutwnHqR4fr8 d+DqePcZ19zWfZOp/XSWY9vV1btq+Gs3ro+XWf/913aeQ+8u7v+1b22W0vnfrSyJJ/67vVzl 023gzDaR9d6uLub2q6lFO6ar2unUTKh/8/zYigkbGZ6KhnsJ/b69+ZatW8OqTyZKLMUZiYZa zEXFiQCjs0TjpgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jAtRS-uqQW1POJTqK2NDO-faQiw Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 01:17:02 -0000 --_002_087A34937E64E74E848732CFF8354B9209857284ESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, all, See some comments included in attached doc. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 03 de noviembre de 2014 15:36 To: dime@ietf.org Subject: [Dime] Updates to DOIC -05 All, I have done another end-to-end read of the DOIC specification, focusing on = wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. Regards, Steve --_002_087A34937E64E74E848732CFF8354B9209857284ESESSMB101erics_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-dime-ovli-05 (prel)_MCruz.docx" Content-Description: draft-ietf-dime-ovli-05 (prel)_MCruz.docx Content-Disposition: attachment; filename="draft-ietf-dime-ovli-05 (prel)_MCruz.docx"; size=69673; creation-date="Sat, 08 Nov 2014 20:06:59 GMT"; modification-date="Sat, 08 Nov 2014 22:42:54 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDnNG2tjQEAABEGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1PwzAMhu9I/IcqV9Rm44AQWrcDjCNMYohzlrprRPOhOPv697jdVg20rYOxS6U08fs+dmL3Bktd RnPwqKxJWTfpsAiMtJky05S9j5/jexZhECYTpTWQshUgG/Svr3rjlQOMKNpgyooQ3APnKAvQAhPr wNBObr0WgZZ+yp2Qn2IK/LbTuePSmgAmxKHSYP3eE+RiVoZouKTfaxIPJbLocX2w8kqZcK5UUgQi 5XOT/XCJNw4JRdZnsFAObwiD8b0O1c5hg03cK5XGqwyikfDhRWjC4AvrM55ZOdOUQ3JcZg+nzXMl oYmv1Jy3EhCp5rpMmh0tlNnyH+TAsCoB/59irXui/YcKxTDPQdJlt9dDY1wlnawtdmLb3SAEKtIp Jt+fYNxWdNwotyIsYPJ2MYod8VYQaXX1/i5Qi61yK0JO3TkWkxJOuPRf3kcj3QoRaOQAr7/dszlq mWOW1Jwjbx3SCPN/SHs7o6romLregQ8Kmim1r8sbRxp/Z+cH1YDNINvjzeuB3v8CAAD//wMAUEsD BBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9h yH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99r eG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1 jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDP JZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD/ /wMAUEsDBBQABgAIAAAAIQBOQdr7MgEAADwEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwu cmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTzU6EMBSF9ya+A+leCqPO GDMwGzWZrWJcd8otEKElvdcf3t4OExxQBl2wIeltes7Xc+h681mV3jtYLIyOWOgHzAMtTVroLGLP ycPFDfOQhE5FaTRErAFkm/j8bP0IpSB3CPOiRs+paIxYTlTfco4yh0qgb2rQbkcZWwlyS5vxWshX kQFfBMGS274Giwea3jaNmN2ml8xLmto5/61tlCok3Bn5VoGmEQuOQORuhk5T2AwoYt3Ed5yMjyOs 5kQgFw0c/dslb7/hFMPiBENVSGvQKPKlqfghgf3NV8NwOVJTAr4UlN8rBZL6EfzcmuIIT3CMVP2P OlrnYxgHyCn75Zz2ymhKxK7s1fE9moK4nhPC1bb/W3t9dJMphKs5ET5g9/TrYfSGHQgfvPn4CwAA //8DAFBLAwQUAAYACAAAACEAHzWGi/DTAABHHg0AEQAAAHdvcmQvZG9jdW1lbnQueG1s7H1pc9tK ku33FzH/oYJf2o4QZZHabMdYE7xapv3ai0ZSd8e8Gx0dIFEU0QYBDBbJml//TlahQBS4iJRJFn2d t6MtiaQoAlm5nzz57//xfRyKB5lmQRx9aHX2D1pCRoPYD6L7D62/3l2137ZElnuR74VxJD+0nmTW +o+zf/s///743o8HxVhGucBbRNn7x2TwoTXK8+T9mzfZYCTHXrY/DgZpnMXDfH8Qj9/Ew2EwkG8e 49R/0z3oHKjvkjQeyCzD3zv3ogcva5VvN55+tziREf7WME7HXp7tx+n9m7GXfiuSNt498fKgH4RB /oT3PjgxbxN/aBVp9L78QO3qA9GvvNcfqPxifiOduooZf1f/5kV5B9RffJPKEJ8hjrJRkEwu46Xv hkscmY/0sOgiHsahed1j0jma+nvVJS8jg4vUe4QoJm849XYzboavf2kc6vtA8p1ItfmOnYNFF1NK hN6i+gzLfAT7b5pPMvaCqHqbl92a+s2FRvzI+f7PNC6S6uMkwY+928foW/VepJgrfLKDE6V59UvL VnqDKdW9HXmJbInx4P3H+yhOvX6IT/TYORJ0IltnMBb92H+ir4l4fA9j4998aB0cXPUOrg5hccqH LuTQK8J8+plreuji4uDqXU+9WXKdqve6zZ9Cid9+8MIPresQ0r6T3/PWG3oy1a9Jr+Ioz/AaLxsE uOXncZEGMhVf5CP93VEvyqYfHeB21F+IN3xTviO+qr9OX6eu5+Dt6Un3atb12M/8LNfTkM81TGMl hz+M0Fa9yMOjg8NLI+MdlCQOqpGNJbANKsXj+/zsIvDGModmfYYa5jLyooEUiBvE5Xf8ROFFJl5d fPx8+VpY//3fffGXOB0huIj2xKW/T5qWa31T/05rGQvMMk4vsWJ0iz9CSmkk8zY89DC3ZLLUD7+l secjimKB1V3ThtyOEVjkS5/i8bzI3otbFZenfibuUm/wba7UbvfFRRzFDx5r2M02TeLl9yRIJQT1 2XsSp3sCOc/xXCE1n/htX5x746Qvw5A1bDsaRpnn+yzxBgheEwhOpg+yddYUzOo/f4V2hpKl+BNL 8dO++Iy8JvJZij+tFKGG0b0Un7x+xlL8GaX4JX6Q4z5SjEPlS4/WL0WrHrGDud3MqsOq+dAvcZGc pesaV610hRxiuQinSuW/ojEQIssTHyM/GKjitjiPowf5RNn9+tWPhfZyoemwFKX4Yd4OZD5s+8FY tuOHMGgfHO/n3/P1i4sNyQ4Uoh2V+3r9LEdaw6dqZifDqjKYamy9vcGWbiVLdzcKMpElchCgg6z9 kC+HQSQz4Ym+l0mRxWFBzVeB7rCYcmDrt30swJUEiKghT+MQHYCv56/3RCqHMk1Rysxj4WXT8uKA Q3cZ3Rj3uVEipPfx/PUGWjQcSfy6kcSN/J8CZXJCEm2gLsMn65c9WXPN2N1Iim/ySRBoKBOtz3+9 vWvt6a/iy1f1/c3lf/31483lBT1+++fep0/VN/oVHFA4LiBCKl//+qmUD303kdz518+fL79caOF9 7v03REc4hNbX67uPX7/0PrVEEIkcESUL0bEQKwSpl0oKBfsSogEqAc23HMEhIkNfZoM06OMHyOzm 6lx0O5134nd8R9/8g0MRTj/XBOwjhAUAFQBWiHgoVML5WY7j9dsIjkg4ImkCDNRxawCyqOJR9MdB TqYQ1m9YhKEYxJGCvxO47jHIR/BjXIevMKmbhTjOjScBdn8INMIRpuO382tx+laFHOrbd+yk2Emt z0nNPYW2+UBhFDEVMpxvGOcQJtBSvg0mA/U1Df4Ul9E9yqgyxavW7+q4SLpSkfTOy76JqziFbX/1 8fLu6vW+EF/iHKHxyMtFDLml4p6GSDIxBqLQC7NY+AH6MEG/yNkNuHYD08qGBMYomkZZZ5AoVR9C SI3CzEGBKjgm6KpXsQ46TkkVGD4TCL6gcuVMle8hLyCEtUz3qbWuJg9Vpz17U0rwDTt5dvKOnLw6 iTUXj2m4wFd9UA9+4nswLsZka7LguxijDTfiupdrT0HlSPLgqHcVCayL9KklmoRAnuM7NLDjPvrZ qgbWfyod/ySEg2Hyoif2FI49RQ58Fdz5x5ycRRB5CdLAJA0gTSplFsAkVF69dCoIB1TjGwP2HK25 1kHM1yPr8UJSN8hrEKg4W8JUqjgbIXdEBegWRXVUfoF07zETku231q95XBLkkuAyJcHHACVAqabK BKBOtbEyDj85/Fxf+Hl2HidPaXA/yqn+AM4WNnmz+CoY5bk6f8aiIYTJqXs1eE3TskeCymCYbi5Q LqGgmUqXCciKiEwg8FE5AR5UN4rxzPoPKdcvV6pfmhRFeEU+ilMqdvXgsJQhodBXDdRuguHhl4if +CJ3IEjkATxAkom+6Vnf98c5rjZ3080uj3E8vg8x44yBE8WINUzbVzfEhoVTq3hJ6PSWtFhmKEXL sbzEDfTPn/lEhLqZ0P9IePkQXqP6r2TQqGc61XPVN79fexjr7vzjhf5/gXh37Qw/czONeJc3Ur/y tZd8ckYRdlmtn9XfGjfexgiIQi/LbyQIiDC3Qxr3Wyq9b4pqbxkuKZocqTS2/k011E/x/gtVeIEo d02Fm6JcXld/9YvkZGylZExBCquMTIMJ/yUHORW7axA1yqgnSfafMvFJ3nvMOOW6O3E9gRTeKFph RHUQnJLURck6zH1c11J6VQJEcipQSTkBh4SomUaZbAdA676m7pEcDkn3ULQnhaOWL1ry6/d2bCNX spFJ0Yek9Dw5EBI0E1ThKJCGXIeSRstT+RDIRxIcfjAWlZXPtfINAHAlTPwTxrsyks5TNS0knsDy bOqOVDdG7REoyYFiZ9e4eTwCOoEN0FewCq6kgnBqTbU7j30JmqFxQpzA4O4GpTcxjaDOP0zjsf1y MYblZTvqGAoTRIOwgNBug3ES6pbMb7cX4pP2giKHBKeG+W6hfcTXcbTPrrDOq76BGpzJORf13igs 0X02lQCIWgBKBpSGCYCAeUDTzVcGNC5y8eiloFTMgURnb+jaG1qDsiTM2brIOBHGiawRJ3JHmz4I XEz8PkzgMW+xybPNMg4aVwoaO4S7JUIpv9BBhNhf8X9CHHLU6Dhq7EKKdzIdB1EcxveIIhBn9Pp9 Srf1Hq1nZcpSrC3kcRQ4HkKKt4Z8jwhjVbFkFX0U4ph10bEuQpP2yapeB/f3T32MutHU8DWmggdB Ag//rCbiV8UpS3EHpEhWVTVbz73E0wsRRS+K4gJDJ2pb40JZshTdW1TSRbKqSooVBTcibD9QFZMb mcRpTgo6z8oK8Y51cQd08chIsdyBVqrjXLnZ8hSdA5biDkjxGFKsVVMuv2MtE3xiLx2MMDQ2yAvU xmzJ1X8SnQ5L0bEUSQ+rGBWVTYzZQmjZAqnVJUjfsxR3wS8eqRh1XmDTlNn0z6LTZV10rIuE/SM5 UrZxI9HXo0DmC7X8fpMj7yHAOO4zeslS3AVd1FKkbGMSj9pinNa/+iMsxd2RImUbvXsiIlpWB40k RYfrqK5bf6SJpIdVqqgVklq4AxAWkH191qJuAHnNPY2VehraL3aVX6wkSW01WptBxLTPVuHEJvDz LMUXSVH7xZdFN285Rt2JGLWrqnAvjW5YirvgFymygR/M4wGs6MpVOHAQsC461kWqvn2KswxUAvdx Csrr8XPRjIlNzVfsDGApOpYierxVZKMaxM9EpEZ2k68sxV3IF49VpvEyn0iyFF2uwLn3i8dlZPOS +JSl2CC/cIS7OYEy9fKS+1v8zQsLKa69IF2+qyG6XLtxr4sn2i+et2+LhPr60m9fSayhof5U72/X z/pJluIu+MUTXYE7N7Jr/w2NYbQylpGgtqhcgdsFXaR88et5++unGyW6Z7VvEp+yFHfDLwpxsk/9 fkjxFptFiWu5/aUY97E7g5RxCYmKLuNRd0EXKfOHFBHaBEC+PbUvilSPai8lR5bibvhFilMhRZ0y tu+eEiCnltNDbVFZF3dBF0+NFMuJm/a1xJqiKCfmtedjHNE94Qqc8wrcyf5bSHFWziiGoXcv0iJc iIkTXUb4u9ZF0sPLNEVmcQMCC9AgE1MCZn+XiWt0rMpSdO8XSQ8/9r70aGwWZKpSxzXLV27w613u L7rWRSHeqtoN+b+BUkI7G3z+J5aie10kKRJa4wsonlJ5r9YprmJPWRet6XZH1fB3EAMYZQo0iJ9e ZlVFdwMzU8w+mmi+6eQ2f8LMTElMfR16QXQHViAipy65qfHlCmi3DK9ZE0EFUavSX2eKVYuz/ejq 4LJ30PoZeI+X5LvG5Zmr0baovMQNnK1nPtH66My7L6UzXyDeXbNGz9zM1fX3V772BfTQjOGdgeFl OnP2tUi+P7TOwRUaoDuEBICc4iCzH5qxPmMtAQUr5QylzMX3cfg+S7AI90MrAQQCdDKydUazEeKd SravY+IZo72ddyMsIMjF52XLXxsJ8FmKK0uRku0LGanVq0MkbSAMGqCJkOdgnXm+BCYOGZLtvvD1 TgEIv8RRm3h6wwAsoGqG93n5lUVolmJrF6RIQInLyG+DhZm+VBWUj1lWPF8EE4cMrHctxc7BviLf TIN+AcDZCo0gU54WhwzJdi5FsCHcyCFWKwGu9AIZQo1ZijtgUTua1+JLnGK9fPAg60I1+rboK0tx FxpCkCIFqR+xvOVFcmQpupdiL0mwqy74LnokSR3OhHKYC8hUDAtF2kUbQLCtQC+AmbK64pDHI1z7 RcCVdIvd19yHSPuxC2QImQmvD0oERWjpmcHQWdkHS9G9LpIUyaBqipmK3GIJKLbxlS+X4oKWwK7V bux2iMzal7f/xGn3o3CpHb7b2AG6qD5nITydteTm3TbqzPV01QJADw2huwi8+yjOcliTpSDJfApJ xos3SW+r9bpAznNryFVM8BuM0YVMwvhJOZAGCm+BXRKHLx3T+nXs0E9xAs5xAm4wHhSkKobIqIai on3k36DL9sKnDLsAZ5wEPgF/EBtwgRPQUHxKDWAjzErIjHaMyHsC54JCjXYqESO35eaW7wSy/v84 sGu5AGnRljPVSDT/VIzAJspc5ivr/8+t/3D8OqOc6Lk4BxYkqwoBs6x+/WTwCfj5T4DKRmsnQI0l VonpR2ppzqkK0UkQhzyUeHCwy3EeaTmN8lvOeion3UrGfEZhJtYPY7umF2XEuIOlp8tZHHHIY5Pu K5AXik6gkiINMC9tKbS14LFJ11LsFfkIzfE/iZ7vA1WWrd5jFYcbGLjbNUB2s7qzfHrD6GMbNboY SErFSNp/UN9habmqtdx4Pl07MHzkJuiYWwK9G6GsZfU9hS+HQQSD6Im+h3HyzOxypGoIKuRjmQMc bTze+k/prnVhmjZwxwSIkpVihH918fX89R4mVgEaSrGTHQg+L5uWF0yMX6YyVO16kE8eKpwsRcdk HJDex/PX8AB3qCqm9To0aR2VGis19LBdbLLcHTtyWXiOhecH2aBADOmLIFKyGsRQQWLj8KlQDGEF 95EtVT8eFNRqYtk5lt3vN1fnpwcnb/8B3fuCURLIDzMkpHAxVheHseeDykFb2EoDtYMspR1kLEPH MmyELzFilyjOhadTO+GFAAk1zWoIXgelsCw9x9Kra2BPRJqZMR5O618qQyC8fDE0bLjkCQnCxyJ0 LEKKUWZCKGFUbyX65xX2UqEtPUHaJyBjMD5IzFyC9Ihl6FiGyu+RRoEzBVMHefgk+pLCF7g/RUkl /aY0z7U0I+GV+AgWomMhQqUgLqjjmLI6ygGnHF/pLHWwOrG96xcdV5u42tQc2rZOGUbr4zElQTde dC+x0S7NUSUNfOCTSxog/JjC9txskVDq7K6eazci/UahrAwwEW6asph1fWup2XI1bKV58qmkrS/z RymjSkLIDIgdU3m7TC9YUDbyB5Bc3OpYsdUxtxhtMmwEGpYm2ZYCg8lz7ARNNhy8PT3pXrXqVE8W 1Rjm05XNMcOVpamxqMZgA8YwXeMgitM/9xD+EA/IiL6ZfqZGBzL5mObN65+T6sjqU7m2anvicRQM RgKFf12aQixA1WLAX57oG/kd0TlFflxbdD8qU6ZVxsEoKRkoElX7FWKZ6h1iMCI3CtOmgz7zG5Yi sUvS7IPrZhZcBDFVTbTErJykiPvk9PDwH6RdWgVp7MDrgwwR1WMZPQRpHJGFAvHhCPPfKPyPuT/j Gi9itKkMH/xYVRgD4AL1yCGlWdVrmkEIq6DjtNjEFWVru6rc2/H8/vrlxDnwL5sDnxGk+E6mFESG 8f2Tsve9fj+VD4HaWrOBkucf57j9tNMxw7R9dfMTjOdatm4K0rItKPfU3VJTuWaQ3/qMy4euC87O rimIPcA0dTfomlcjrOZrn8ljzXIviw7XjYzWgXvmMw9ZPHjhh9Zm9X3XKsdLyn23fNFf4nQURzLa ExKAkhAhXfXf5fcEw+KZ+Ow9idM90T3oHFfPVd/8fk0L0Q6Zu51d2Zr2TuyaWkOwiwlAtjFUx9zt zN2O7swqfajVDRL3+Va5v4tK4nCPVm43aZw1kQAdh0iAG1kO56KjksqBDBKFWfOiCTQxlUkM1ALC gCJULTOU8D38WC5FtS6SDhz1/xLT/6NQ/MrKTGygg3ndhRx6eHv1crb+K8EBcNAIkl8yBGboqpj2 mJYcdTkJEGCXfu3jOGk3Nw8jSeTyovvusLNb7Wb1Ockvu2o3z2vw90xlR2jNyiCdQVj43N9y3d+C ovigJwbaCmQE1JnMR+hY5iEUxNaNtVgxy+jtQEmCdMXU2cxXNtW4KRYqZsr7K0TM1KML9uUsigkm tqFn6FvX7z754Dko+DW1C+fKhDZbBHbO80lUqulZJ+3xvS9DfEJConapnOwpsogPrc/nafG/9ICP ORQ8d9A5anc67YO3d93O+4N37w8O/p8OBGZeXvnghUTlD4Hfeefi6NyKG9aubLgM2ql5FtHlmR/o ewQG+pEdCxDGkkBMQTZWwCZw5ACZ1n/CDxRlm1gNg+nwTwWNW6rnKJSI7i0J4uI41KY9qms/Uov4 fktsjCUJO5SuY7wP3WV2s02ByvKQuNEIqBTeOC6QLWCgwsoeFlzcJE9oXhrp+2Gvc3x5Yem7c1iq +pzaHLixyWc+Nu0poKmIB3ruCLc/Hlp3mZV5+5hF+MQmiI3TAP9GOW4rhuSKTQmMX1cacGGy0PXb AEtwnHUiHlVd6O3uXnfjaGZ7fAr9EfxXRamms0dEQMXcevDZrFsHEe2np0zhaOlMoYNkoZkpzAkR thW/JTKloVGE1E21wwW6ShLOEN7T/dcBvooum5+Oo/ztR/mWDOq58vEPaYBVCrBz5Rmx89oVw6TH aBdo6h4wnz3X96E7YX6PvneeVp8R5JiSl8qkMTsNcq9tIBAWJsbeYBTIB12wmKs+J38A9ZntZ1Vn QdVvFmrMxJee/tCt2JovPUsligNRNg7yqRJULc6pfZ7SrtlZg/Kv287xrGMI2+XQz88+NKbsMkzj sarINAIxGGfrGtQllLHY2+XPT3fbsRhVxELw5ZTR99UVRpYV3wE5EH0K5tgS0OaAqbhtEvP5wRp8 Unkj3v3QjdgRl+yBzAuTkAtsB24dR4LbjwSrgUeCUEBHQZyHmXI1ygrtxMgrVhcT1YJmtEQ5f67C dg5+6KDWLKwLY7rXtESk3Yq4ZLMfbBlTckbjx75AV19BmCgIMQakTG1fZa8tubh1BmdcZ+Q6o5cN gmkw51rhBn/Gmsf2TVxQi7Fc5dDUgh93KVxxZLhBkwILFUdK0TPMk6DeSAQecIwlIVGj2iW+RfEj 6osBCEz79CtpmUN66z+qDCxdFViagK8sGBShl4oRjAkmhAIKU4VfVMR7CUpJkoj4IGkPC0aJVkfN frfJ/LAQ3VdmsOZ3TyAbQ6mZeFaEyjREGA+wWJy0L5Q+5rcQPVEUSxJXiAAV0TLuZAfKGKqDM43g XktCyN6bvXfTe381pPDYnaHWbgDSBNL4V1/Pb6eyKI4fp7g7y7z4QmMgy76OSZY3MecyKYV1OsuX GA5VURDMfkjj19xpIstU1nrNdVtlNhf1C2VEkQWZRjfhK622K8Y0sPMHJM8gCBx7+AH/R96UqbMP DsFBGvQZg0nFHuetpgmOLqNQpar1lEssuLrC1ZUtVFcqN6mNCvzjpxv2j3z0tnD04Mw+agZ8tVhX zXyWQCLj31S7Iij3oAF+bCXi8xHrna47yPoZ5Z/wt2m+Z33atSQ6XPtZtfZD3jSIClXLofKBbGxh sw/RZDJg6gjNaRA5Hw3QHxSnC5gm/LM7oSpV0jCAX58W4CBHjXP9eLrJdmAlO6D5IeA/vqD9vX6r zOUnLj81y08IbnoTnukJ7MI6fXUkVOdw+arH8bahUOReFiKeSsiCnvi0rhG/6hCxdobafyYKLPhU zsjUBDVCjVNsznO2kOfA+4RjRjAw8k9H6GsuUy9i6oATWhrB4JtlrNRMVU1U6pU3TTmHrhvoNDwj QgXXVNASwpUE5dh7iUdhH8Y+bCs+zJTkOIWq8MJMCdg6j8ELASjVF/lI6ctagZ/zUqh7GckUvXxK NiYVpTKkF+LV3QjY9jG4nmM1iZCrmoue+GP3tX33RZKgJe/ARVJp3PQ50ZWmrHifm01LO7DnwRjr qkTVwBgrTMufbB6MsZYuyrru0qYQJ8tfZLlC0xT9N4HLWddFvnSpwIwtoWvKoJ75RIjKz9azVODo pUsFFoh3187wMzeTjjQVEJc/2szhvSJRz9lHBf2SefsCLMo5oqep/2h18tSD9MAXeOVxH3EcMSWu P+fftcOKU6jK2Ws9lb/ERXLjcaXG413FzcxKxZxsm5+VhCmfSZJlnb46E1BnBSqgt9NdRwsQXUah ZZZyen7UPem2NoqSRppCtLmzaSnMDoGZxGDlb9ZKA3jEFYCG6LP8NE4SYtjkosUugLNT+S+p2Ion PXwzAArmpoY6DeIxrQG/mVqJcuIQhjhxPWKAOlm5voGGGwNvLDEkYF0Ex+XlqMeacksTYT7T2jkP A9p0AlyikYq4pdlhzKYae2COnRp+nEhP9FAG5fbcDsxxTEyFERXmwPOR8BLwqiQpVkhLIdMUMjZ0 dfY+6bkI1Kb1IATqQQdk9CeWV3WPQFUflE68MwcKm/wxEggFUjneAMCPs56Vsh5EoQNw2WQ48KZr SKX+TDkiL8xiNALUzhpbVBYabnliua6eAbTOHqlK9/Cwd/rWUpWtGfdX0Hay4FPNDYdQuNlRMmRU 8lo8jqQanue4wP1sYCkU9MiqDXW0gavacFCBdbJiOAwGFERg4NPzfbgYxePFQnQvRNPpFNlARl4a xIzVWbrVeVNvZf0SldVf4iI5kJoVSJ0dIn69jcNCzUHSRO5DIB/Xb8L5iPGcSnNOhfDBVe2Bjl4Y e741lwv+lAf55BE51itqIL4G/1J5VEEzAdqz9R9UNhOzzMScAF5M5KezLEWGr4L6kiSrkm/1fLlF ogJjsQgdh4uTPQBEVhZH2R5yZMXSu1dt4FVyrdaeKT2Nh0OJDKFclcxSdCxFE/GX2Eaq64KdJxxz 4P+ywJ/9wEp+YObAaVYkVITLhAL/ABlN8z2YhgR6WrTUY+QVWohAe9ETWxDHFsRy1bpeOsi1sCpZ 7ZXNPOoWD1QDCd5CUc6m+AaUYCxFx1L0qDeXQaUqmUHbUimGRQoIPErDwUPgw0mAny0WLc28RNL8 QlXyFoswdU/QBqmU28yUUPZbNM9v9zMmpXPj92vrnPpsS133ZgEA8kmrgH6oEluta5rlbGkYx1uH MA4YiDjC1EwqxjEsCMJJDUtRqZxl6Of2kZsfn5Tr5Oj0+OrIao657yOrD+q2j2zd0bWAYrjoxkW3 ZtGNPElNjynDL0lKwL6oYzhRlmiwVAB1AKykS6s6ACKJ9R9TTrVWSrUiKSmAg3UeFuEwCNVo46SI UzXVS9gdhXrqJSRfSrVYgI5D9EnQTZ5UjQvr6K6qidIugQB6SdlyX468cKggeHhU/wTSXpaiYynq JRCvLDnYcRBY37EKAtAiLH7uvHMZyD0lAXZVAKZRJBlwat54waeu8VA2PzNFb2+PD4+7lzsWvakP 6jR6e60mysm+fgq+yccgkyiHNFwtptGt+76WGI+d50rOs9l9qqXNz9tc3dNiGTq2vMva3K7amOqG mPYsr2yuDy++gtWd+tQKUPrbUe/yfLesrv6gO2F116+SnDpz6jydOlstkj8BZB6HstEhoeW2YI2X CSqAar5mqCJ585vrP6kcAKwUAJDIEKVdoaopv3vjJESgZgllfgzf7TiM4c0BwgaesBFH2p94Er9P fd6d9STqxrr0JHPwTbTj6DqNvz/pkTdN7YWKGek89desg8Ph/PbnGFUrAks1H9T8SFzcj6jUhXEE 9CuI+AtGOInR6tQTDHW8ITo0mdwAOIbN8Urm+BZVyhoKFMMK/RDTWv2g7Qcg9iY8mhfSPGOICkaJ TsO0EMRrDCLroON0TE8N6wk76ntOetN5/OilPkxlOfYt9MwxugyW0OqkEN3u0lT0hwcrkUJ0z7ud t3bhau0zeYbawRP3AUwSXaV5iL5Pz8pHaGAQ43hlbbC7PP3+rGtWXn0LF5djvVCcTfV/dm+s0Bw3 65Cxd3bjnS0hWKd+eXZHt6d+ashg9048sWxkwbgIcy+ScZHRQKbB7jWAQxTSNgrTG4iCuHzC5ZNm +aTeGGlYhXksNt1jdxn37JQwpey7Gb7UP34t/W5++DmO2jn4Sd9lHZ84qpajGgPGEuTZCr6qWuI1 A4ZvCUynuuXDNB5TjmedIHbu23fu6KRlCWVoD4AIDqvOsu6DKiy48jN1Fg7Bwgv8G4u4TlGHOBfe pEVVtrHXr10cEXBE0IwIaiMKfqzqdWa/gojkoxiDUAT+AKQiMcZR0vRJzzSQC84lT5q4xrgHkwXK aKjceDReQqOjKL+2kuD+/qnvDb61ytmvyWsVyA29lyAjp75+Q8MF2JUKsKZYMtE2MIIiw5Wpjrmg h72/XVP9HFpopFZV9F4ovsb2mjrhyq6J7/E9sBuAdL0pPfX5iKg2TeXuZPlqZY0qbDP+ngL461R/ PlVotHjG3QT2s5MokLRVKGWqR1TkhLAjXxRbW7l3HdvM9QipGCJDmOq4TV3T8bvTo6srCyazphrv 4mOwPGPcoaNjQBslyqCcR20BY3V1Ut7uvMFYRBtbjh6ouC3xUk3ma9dHp3SyXKbhJNGxXBnN4p3/ 81YbFOn/80p6eQHTQ/7thX5swaKQXyLf4YvcgaRu+eLXgp0+uxd2hYizEGY9eOGH1jBtX91QKVjH OOpreedTvEZtRdRllT/AyqZjXtlER5qC5LUc7V0zUryuaoH+biVa4HVVKy9LXV0jf/XYaNc86rOu cyuqN7cg8OpWo/3EyX73daPaNLdYYE/S2onI8r5jwUllIa5UTFTwP5ozF1bm9fW8jQd1HbEm58PX +5x38Wqyza8m62k4pqBDqKDEuqeEVkVVyKZR3XAsFDpqAjamxjZjDQi34tY5NJsUEAoISqknGECU QY668cfhNNyg4h8k/qL1mxp2Dis5B8gsUoRSlaq9QVG/Bu0HuWAOPdSUkbUZOqAZqfwP2poRC9Gx JgLq1g8iNYlBxrESZV2O0MbbYByEXho+qYYw6q7tqu7aZhk6lmG98N30hzMFWrpBTFMNwjjjrr17 h1hCY6BpdyMaOMYcK3lC5RY9DZQE20jVPVUNG7Kh4PNj9XOsfjWPR/EmOUGldXuiX+QKBeVhdFGB aSgcJTlW7XA/UKzrvH3RfUhK++wnPdAqQqk7QpVOaItKyvc4CgYjinFMXMqq6FgVyS5yDYIJ8r3N 1yBu6qybmaHYnDD+TQgcvcEgThV7MBB3SJm8+xSMj+0iiSM2GI4NRk1K4X2cYtfuGDFYD0LqA5NM m7iFZ55oTgnVBn7fLY8COp4ecqbw891vRweHv20C6Wb6BHNxQBSQNA+iw5HIM18Og0ZYW58oPzz4 oZttTWuUWIMLCUzCdmRgxsdVb8P8QHffmiVvgCBcFuuoqDqWXkQDW8xS6jxMtRS1Pn592PkhtdjW +c9nNwyzeKymzqzLg1a4tEN08msJAapjhDiklgOyOPVkGg+kryCH1NEEv4mv0gazwqF5MQlhJhOD b6I73sDNz7JN1vZSrlCn4ot8rCPH5ro1gNIrJ27qKn48KJRTp0nHYEglFg+D9tE9aN/GRZa3y0xu 4vT3WIiOQ7QIqGR0DEjhWqhW0k6bKiKrms/HryHiq4Lwv6KUbUkvRPUWlqFjGWLYKI3VukGaA6zk l3Guzrn6FnL1amXPIMYaH8U6psqwDx5mULFNIRvEyRSJpHEMbDwcG48KLFBtV+gjVizXC0ufVtiV pdiBlzXXGrH534EFaCiZZ+D96xONUY6ySpLTCHiTW67cMIy1dZhU1dyAtKvqIfBYBR2roN6NUa0i /KoX0OhHgQKBDiI1QrEMKVATgUXVpT43KV0jrubby6xAE6tUSzAYxkXoCz8WIy+lUqjqNBMClHXQ sQ6OPBDzeAIhzEDCgKIc0Sq3DGE1gWyJKhc62T95vQePSKSqlDXR00IXVVmKrvVQaRstfXoI4jSD gmnIuxKSXuwqv+egMg5AmztVtWAh7gbbUk3vMqviR1qJvEEXlwblImU9pq/QOmXQyoV0Kn667Gqg NlgFLArQwZUIrkRsoRJh9j6ToVB+GQzMOa0YQTKkkqIKGUae2wRttlnhSMyx6QCXEu1QJYtOUqrh /9oBbef0idperWTX8VfqRRlRXsYRPPrfR5pHPD8jOa40E81zbR9a53GBGRHdBUInbZDZD9UoBRY1 hrCJQAYP1NIuW3p1dYS/JgAnBGY4Ss2MkdFH1kDHGlg19qiOREuNyYSmcihT6sHiMbUiF49VDT8s eCFT207jgrkG3UdfZgLYpDgQFZnSTKrE1jyLxyBaesLWx29R/MiprOsI+jEIQ5T2dJbj04SwR3iJ PBgUGBVS6oZNPoDUwVz7BeoQsRJlAoomDJ4ouAdXdl0L8WJSbW//mWJRkGep3dQQpwblKPmFMfYN C9K7UPqgS8RuVVJLEjcns+7N6ZSJVHa1aTabYcwEHwN5ckzjOKZRy3jqQQqc3v8UUE8U5dWgyZSQ lT7iWW2HWYCOBajSQuUHSVJlkqgimLGXD0ZqnE+Kr2lwH0SVrVWFABXgUEbCLNjO64LlJKYOPdFs yT2A0ZFT1GSkQKD1jJGLh1w83GbxUFUOcQBV5Xq56mEYsn/YBf+Qqs2lqsAEeprZJcSySgjxTlWp WIiOhahUT+nd82XCWnw9KVOxBB1L8LkyoRJuWSesQnC7TsUydCzDmXVCsyO6Vuelvd4aNEF9GVN+ AvSieGn58BegXHbbl7d0a4p83ikdNA2D3adeMnppvL/g8PzhSY0XXPuuTbUtSei8W4fzL3E6AhtQ hJI7zazDYVX/XX5PAMzNxGdAcU/3RPegc1w9V33z+zXgveLkpVzl3Ju2G9HP9aZDL8tvsFwdIE2f 7vxvCDu+qZ1EObNZM5t1hXGoARoAF1mRRJ+VcjWlnDOcDhv591GAEWFK2639pzTCklE5UO00bHn+ v7wBgFwtqsxM8CPZnt7CaYU2JE2eB4cPXdNCLwJT6T1s86Wo6fQAi69Jikowev9RkSZxBjdJEysg bKPWthGoXnTL3Wrn3epAr6hSHeqccHWkjnvEvmR2FyPwuYJI5XcPHIoSL4zQrU4FMwbvwBxgNcmp J8ls1iGLzKS7PJnJ29mESgfHp53T4w0TKp29atp0h4Qls5lVlM2zPqV1ow9/jhs9+9rIUkO3rauD HyhlAHYlROGB/6F1ePRDVzmLlqWkjNrGKStZombfAj9Wl79TTFJn5D0Nkwr5VktA1vE7/iHBEPBm GxLIz15blzA5Y6lh87HOiJPdiKQMap8vApf8UUpw2Ok1Cc2PzmEnaJi2GXYmXgCmZmrXmuSBGKSa KQJK1WFMiHSCwiIQBU8kUgkwS3rZS4vVnP+tK/8rIsI+RnrlTT4Civx+JIpooJZH+6o7RGg7km85 ygkag0Ea9M0YSMAydJ08VLMAAwx9ZN6QWKVIuaBuWp5RHBkCMDUaovTPdP7KrJCNqePWH7LyPAWa nPL2hsIRbajq8w1nEYG9tGmzwIjuWtPG1EDwlSuFmw3Czg73OzAN18H9/VPfG3wjg3GdBtEgQNVh /UaCT5o60DjXt/kTKrHlHuHrEOjMOzAmECNkVQBcd2xn1Al/YHfCfdoUUpsQJqRqGoc6QLEgDzRc XBIS6DU/ikikjwRh/cd01zq5TYO4YxJEjBjcK3RxTNXmxBgTeDEasIkTyhpUTqfikdoeuxKlvAkC RZahni6udd4WjRLrfT3UNfAhQfCTEnOLGobzFee/mRkm4p5KQ/fsmpVVEjlZviTybnbp86p7fHF6 seHS5+xyVLAP1pqmXXFYEz0j3P5kXWnzk3EpZMulEEOdbS2Qq+8vA6o2E3FCZAkYOMQwIuGlgZ41 VpAl6Dj/wsLAMaRIQ2koMZJ6YbsJ0EUJUasiCD7Xz+Mr7CE6cZh9Eq/Oz6+mKqise1vWPTsK9MIQ Q/TocCupES2zrXWvMimF2eHd2T/cP+JBX/eDvr/fXJ2fnB4e/oNXbQc8c7aFmTMkmcDLIIeMYkFG YtLCr2UjJt+En6YdzmjKlkR37K0de+tUhoqKigKpskuhwE4qsKKBCb1zW1VNTYhVyZil51h6NWYx 7GDKMnQEN5Hxc3GRi4vyQyshYh4w27XOAHi9sQCsFaldBeuoYJPgiUHVOyxUGFlm22w4HBuOyXL2 em5NI3AI+9E2U7wilUkBhoo4KZSjUF210HtiJgrnTBTQLNInCyfCTUyO+rcQ9d9USCXauUIlOM1p yubfXj63o53BxeYfqPlHUPKZgJKtvwZL7FhvsLL+BjOoth9VEyxw5broCqAg0m6aTNJOnV7B8Zfj +MvmjZrb7EBG3rS0XpjFLD7H4tMJTQ1doYFmmShoV6iKyiY9RRVV2yaVozSO0rYQpX2Jcxh/Q5Fs aq4V0CCLw4L6qCDBRghHMxkK+TMMvgNfoukJ2dI4tjTUDx+EAS1/AHoL1T0N61I1WuXw6VEqv/sy l+lYAVz72HKoAUKjDSANGf6zEvynoovEkq331BNHyq7XQphnILxJdPZKAWTUsg8EeDxQ7HomACvU aoP6rddIhmglRJkiVdIq2c3x6no03tpEE5b1byX9U/1JFKMx6U3VTRq+wfaVULS0VW1rP9eC/UzC +Il2v++p+M30MdkDOvaA59r7fe79N1JY0i4RYOitHszojc1mfYARHLApZgsPy9CxDL3oqWoaG7kE ERZtq5aCcYTyux6XQ4zTw/I1TdBACGfaiWjJ0MLDni6Nhz3q7hwetkQEB2GQP1mXiMqhgsVSBZFp YFB72yINDCIyaqw0LUlZQVNQe9iitlfgVdhpjGVelEUN03gMB2N+qylNluKW4YzacXCphUst6yu1 YKqvC/ek0u9zL/H6ynDDXUUxhr0lhY/r13uG3zD8pgm/QVqjT2FVxCv5VLTrMgdToXBKTizNMYcw ef0nlHPSlXLSqlYngqGIEUSkpWwMBbWXjyjunZSFDFkOXrt+6f0S9uWPc5FMlBxMsbYsTQj7DHUz BjnP1kOUfPpSouQF4t21M/zMzTTgl+VT2F/52hfQiLB7neVemQZ7aasHDVTct6tr5IJTuWvWaCMX yao3S/Vmz/ZjKsBkI6pNjTLaYJIj46f6Zh1McTey6PUHtiy8lYRXr2KIVxfnvdeC4AcQXCZptQnA JKrGaSqcolYBuTS1+/VLke0Mlz9mlj/Oe5W9AfAOECZkx8TlMRvdjKfjCU59I4k025uV7E1lR6pm 7lB6eUGbaMp6h/S5fM/l+/WV7+fGLXewHMMgxXp7BaqbqsNVR7WOojenVBme9fs9tiarWRPwiE/8 AXrnMgVOZJ5LIOYgAgTR86VMWYKOUSIlDsTkDiXIHujIyPhtarMrPHNQ8cdrEYfgVWP5OZZf5ca9 PnIF6oVimvges8P5aGxv2aSUwqKcJDIhlp9j+Rkyp+PXRgVllKlwzMwQaKYXEHaFEuvp1OocovuK o3AKvMRwly3DXaqQeYKNnKWHZveDdnx1tDIl+6yDjnVQi6UGOVfr4OnRpGwK1yIWTo44OdpCcoS6 rirVjgvYfINEmODlFdMjPEOVI2ngHcVt/ps4ZZPi2KSQ+AwESGPiMS0GsrbaDiayKUrEtfr9Rwq1 eSuJc5YX6qpgZ6iXBjFGWDD9AMXKsmKMET8VllWy7el1QOpBo6VGsKyE7pXQ6JZ4DMCxhMVAPiY3 Z+RMhNkjuWHbjLG2gJyzBN1LsFI1RXqDJKm0kWhzEsuGMaJqL5eWsi5DqafQmGAZupfhbZFQ0mOJ whonervkOFH3/dEcev3u1cHF5abp9c+mCdhKGv3aWst3P3Qt1srCcrFJudZyG5doVlaWxs/8SJJL z+hfPKKWujjYuXLWbvLmlUVkKkeiPlLGV16I8WH/STEuYBGNdegIi8ODXdsd7EIshXXPGPCVYWiI WuyRbS0+mPKy1KXD4opaiSXo3oIvDp+4JsI1kS3URO4Q7DUsx7ItR2JY1fwRbE0cW5Oy4winHZsu cOnAnydoow7yBowNd/1T8cUm0Vy8XYv2y0Q5mo0ghRiqTMvWyz9lMzFhJD7WP8f6V9HGUu6cSXQU h5NaZVUamUaF0fo0/Mpa5HchQ1rbcto7PT08oHwpzbA55EIOvSLM6Zmrdakk8hW8feB/aB2pP0T8 AXH6ofX5PC3+l/6yj7b5h1b3oHPU7nTaB2/vuh2TZOr1lWvmQKAU5Bq5FK7ZXLeV86lnyhes+U8v 0mlbf1FIwTSkJep6vn7UWTLHrW6ldb010bu4Wjr3w5g2LVE6Yl0khDOV0B91f+hiLeGWEreP/0bv Ac4/rWKdDcJDXqauv3yRSvDdp/mgpJFq15wlGuv8Hf6QSLZ2/s7eW5cw83Qd/dCl7MbpOlMx2ZxT 9NKai60kxlbWfcS6hhTwwfH2ykccLy2N4wPFa7RRH/HSW7cRT7puMiC6OO3navd/+T2r5f23HMtu aMNsW4sy2B1ZgzlaYpm35dm1Zt2F7Zk3u6KPiyudZ2q01RLIRv1cfjZdHCCIHFCstAcH4w02olUx nKmuBGKBlCqUTVPNheItg+mq3GMGhM4SjqUry7aOOu/n6crh5dHbg8sNb2Y+2xPyQe1mjYv7EWEK xt6TaTWLMbgyqQoezTqILpXKgFIBgKCweQItVh2XdaWDP5m/cmHe5jqVRuKGvcySFgGjuIbxPJGN 4iLEOGkuUKwB5Q2dsHINJJVwNIsnV9RcMx43FrsNICaSHqmcKdeAXNwIboZ9ZIYpinpK4oTNBhpz NTGBKtL2ToonEszGBP061kjrqQJoCgXqnBKw5eN+kdB/p0zpQgUDa1ieesNhMEDXwi8Gin6UcIGD vEB3iWcxXKtfCQbh8WUqpZM1vLLqIzdWLmYStHo5ZV0l980VCnbKWiCht3e90DxkLUI2+7fVwCsM hR8PACDGfB4ZDbb1jp01IbxztH6w3gXimJ6dROLTwxOw9RlaUhRAVwt7yNAEKdcLXBt8iJA47mlu K44yak9ae0MykQC+D1h3rOLoVA5kkKhuZy0JYj10r4c6Mt63O3GqUGqq8stCalHj6UxvG5jl+C50 A3obpZ+y4DsnbaADOLck7MLfnd2SWRwWwEtNW8USqEPLrnQ9yLyE9ci9HoXxPZITDLB4AjNkeZw+ EbSjDIsnm2XVnqtxcD/CdjPtySq7yVJ0L0U15kJOawzweo7/6ziFeFM8/8ED4b2WKrzZA+EXas4M cpwas+A6wvaxNAhMID/N4wAzidEEKuRV1QVTCaIqXx8z5mmcyBSdKj2dxuxbnL6+3xKYmmrLD4GP +pWYi/ebDGMgHaIBjXLrPJoKEfsLx/6C7ApmHMu5qPbf5ABuX4GkaZ0X+oty7NGyJIguy+KBXv2l sH0bad1ZBafrRkV+Bwg11+IM+SJZknlL4742E1vQMaV3Xv64Hl0dXPY2C6TeWlW3vJbNNvHWtHDi 7UsXTiwQ2B/HvvwSF7mArJ8bKumMsSJeIcErJNIAWKTGxNnqXo9Vb2on0yCzH0KYgvuq9pAsmv6p sj81542iRK15aSV5dejl8fIDVcdzlgBvo/4+Z/aFUifr0nCfXCItMaSDihGR7VosrWXFHaXANAbq hLuOrruOdG6MumwAOPnHif7YOtumGM3MF1rnOxw5bIZBC4d2tQfZWAMIvTCLKwQ5HUtDWSceFZWK ekjN9zbtHI82bHm0wRgMIy7wCOppalToIh+xEBp1k8WjtAAITytKM0NFyyJ0XGo1VMATMfnBcCjT BiMdeI6giZqNrkhouFxPTjATXaMcXMak6y4rLYpySxo66ZuCuVpIgVYddqSFKJ0r0Y2D77QOhzSS JJk/wsZKxXPBKuhYBUuCVRhPY085AGOo7xZ6pWjo38EWaIAN7MVklziZiJIKx1iMcQzHEOCQWlvR 2Hg4Nh6Q4ZXedKasPkDYcZG342E7GwB/oYZ2iHrbzr6BrkGfO8PqjSG8Q8xCdC/EYJyEas+NpyZw fDkIqGqSIQ47J3yCmq1CBSv3vmHclgjXobBcPqGhEAsIu9n+2hy0K5RQkDCkwjx5/SAMcozog1od YTLNzfnxY5TlwHGPBX4qkvJ7xZOvCaDXr4NcctmBhr4bOqyzw/1DGA51vL6a8dpzMxctbhSesuRC znUpXf374wUUPnS/7KGbaxsxcKSwWeo41vY813dE74ntnlPuYU81KheVGNRK5Eg+UoyZiVdmu9vJ /uFrHYf4wQA1IcSVEzzwJnkY2MywmZm1xxu56ddPNyYTQv1LpphqpyPqAStaO5xmOEslwJPfWn8U xoZmJUNT0VqpIuUTMlg160PzH3toJWSY7JE0KxIV475MdVU6lNE9aD2pshmMuZPsvpNcToZoHaM6 w4MXBj70D/83k3W1iXIDDFDOhUufXPrcQunzDv2PHOZFEX1PjTBRwaUGFVIFNMNzsCdGcTbFEPjj mRM7ipUchZk2I6OCuko4LqcEMzYgbEC2YEB65XlTYQfFKWQVyNepOWRVmy1zIopkKgujABHG4XG0 6bjubi3hK3slSGKTJKR0FuX3NsKW+mSg7p2nWLmi6Tk2YGzYD6zkB/4+QjtEkaCYsXFKACkXMEpJ eYPFoKIFTK6/LI2yHjrWw0lWAMP5SJPlMKT17H2KbArpPBncdopu5/T2Qo7GtgwELNk4qFtJiILF 6lZLAgELx96SjJN210l7TZkgPRRZMmDDHkfBYKRcni3Qb1H8SDV9LB9DRzqT6YMCfrIZdWxGKdJU 0qClzzCiYy8fjAxQMw3ug6j9Z4pSUcRXHlJpKhGuQHzl+jKWoXMZQnAEvQJFDlWu6zJqRjYbiD65 scKNlWZj5aZeXlHBMzamEboYVZcyAJv4DEK7oE6fAL+kOYWpNONlbFcc25WpLPYCLj6IdJarJbyZ JZRsUdiiTFsUaugRzZumhaN6OxhpE+AdFbu8gsxJwOnGQUSvIi8YSbhDZV3Ylji2JROieKqzaPb4 MvMbS+RzWk5j75uW3f9n71ub20aSLf8KQh9u2zFiX0l+tu5aEWrL2nasXyFp+u7MxO4MRBRFbIMA Bw/T6ugfvyezqvAiKJMyyEJb6bh3LJH0jKCsysfJkydRy1tmuSa3hhIOXNd7LbpxGa+pnRKoOab3 SHGT7h3jaLCzBctwUUWNEZtWXVvwWtHtulGxSsG8CnD/TnUPQttnn30lJv9z0tbc19W6/jS2OqBu Fy/q2IuWpuOZ2dQfs7sscpDHf9d+ErcOUTEp0jGKeCNqW07YEmIjNnRsQ5RBWt6UwqBtCmnKP/nO sr9UaynxReXaSTzpMGY3GMisXCNCI5p7OvaZzTi2pzvDzoQQczrsaIlQGKC5JMmM61CYFeOpiXDI VtC6pQhnRcBxMbVnpQs59mFbms2hxBXfa7RULOjagj7tFKuc6WpoiYxWd6b9R8AHgVd8Pw958PLF 86PzvT/D4qfFceQjZV8cgw77am+Sjs4vSG/VCplZobilkTHziFuYbPzKT4SJkJ4ERX+6r6DoHeYd 2hn+yi/Tmpf+JlPO7ZFdudPsIT+7qGxtqLIl8qMiPyryo8cuVkutHHz9SJNKRD6sdztKLNwQM6q+ Bj5YLmAF9qprz/3+M1xhmG7EMMWORB5/ZUDn49vX5WQIz8JyI5zsa/HyauyVuXDYKEafEys6Ruqo xWiGC4nSDewmW0Cg0NCeDG0f3IVURf4t09kYICjvrhjQsQGpU1zSSxsO1VIbtCJh2aeqSMV+dJOk YT6diREdG5FpiegHw2uCOQq3yrPZFkIHtmOiXisU4g0RmnTfclwSmswotplLWQ3RE3nfmnaczGZF zOIQcvkcX74wBn0GnGASY/evMThhIhyzvXETy/RTeKUyQrmDEUqwDrHj2pLA9iGLhoPZvc8aL1PI R7etyRQTn+LYpzAhD/OSt5am15F1UbS3cV03V8v8Wuzn2H5ltqwvmInlhsXHQZwszGlbZVkm9BFH TMVU9ooRHRuRm6LLwirGmFGSgaqw/DalaZXIhRjRuRHJHsm4mNGtKiXWnj2GGT/CwhirWLZhBkYD b1s2hhQrOrYikKVy4xGXuSVqmCURuH2k6Nu/kYbWCm23tNfveUrfb8O+38rmA1Q36eyVcDR9i9HC SPmMudB7hoFK9aDhQ7XSgf5PqvQeNuo90GKkG6BiMFaJRPPMDPt9WrKDuZhFm5uvycI833UjJnQc EW5AZsMkU4WueKHmHpY3E/eQhu2TFL0iJNuRQr5WYjH4tJjQsQkbftRDCZvCT1ZaF41mBN3JLqlR MaJjI7IEte8FRVoOV/wOvX4CJ2wDSUdIsnYZB6tLOhWit/OZJ4IctI4ooAmbs3SURVTaxgkW2yB4 pjw5igGp/m+gpN0y2twebb7iVK0GbEPoFvss7QAsSD/YYqknK0sno1M7FI7zEPNe/Z9TSbo3Srqv fepLm/FXtDV/JfViDI2MzmzsQNeTOCSNSGGMiJkgMaDjUJ/lyRw52NfaEuVFbN4/CRTS/eyv+4lV PE+B4PLukzd6F7peD9W/l5B0RNKRrnSEz56Fn3XXJwtvWF2MaVgGsMYIHneMkDvbV3iPWf8HVfKR jfIRGKRMSdSXkGSbbqrRcv1Ww2LVRnVpNmA/4MoBK2k29NVsQNUDYg6Rc8oRedoHRbRbVDxoLpjz ifaXBlnoo6h3sJ2apUuusKJU/IzjtLmxe4cbyiFzBWG+RpOhA3DJeBOPWNCxBZeNZkobveqExJ2o Zl3+GC8LposqJnRswnIgpc6U69hc1r+hpHyQ8uHr5QOAd00sADDWPQ/AwmNcc7C4Y/8HVcqHjcoH NLhqUxheVsypYQmEc6L3xttGZqkBaF+vPio2dBwVrqG4jMBd3ipOtW3bkucZ6W1cyXNt09GvyKzB JdDjOfTPxISOTVirgGYFRPg1Y5Mza+jB2EXxq80oBnRsQL58NStyX2/qf9b0LF+jukQn8APNyqK5 b5590FdTDOjYgN3pyj7xsWAyrnX9CH29rik5FMBiP8f2M3kJIdhWDFV6dQJv9terW8mlvmgouPB0 M+djtZnnVpZtuR3iNBw7jWQ8LrADHko8us6B8yD2Bo3NcAC/Jhw618SyduyGjmiyQLNFjOjYiG0N JU6r6kXtXfFbrOfYeizvQT3LOoxZEmslhN8vhD8IuPZBPKTgmV145rcqz/7jk4/JqcOD+yrP3kEO eBCn8kE8pFy9zqv3NsbEWqzy0RlEKHOv4w+DYR2vex9Q+cyuMXVxdHD4tP/U60GcygfxkHL1uq7e SgjiLZFwUMRmfnq7z12DGhRdVrO1pgKhz+BzvqVd6iIi63rBxTRZqM8q3QdySXWrwRtoIL/dVqDJ NtMFqgDr/h2pXL+Nrp/pq2rwiHhULejPT9NbAEqRNieJyFKHne9g/7aT+PBgmToYJ3kGr34JdliE Bcs4Y2+++PgaKtPpeBrmaPsX6RZ2+8mRe7BHbmVKch7e4Kx5h14YRWA0YK7eUMOy6nT6tVOpiWGh D3U5lfbvFSWibRTRbIeq0fAGKvtZ3dLGUIFlBZY9OP/p9E+xWautN7a0QsuAeVtYoWX/p7Era6Wj 9KB0G828/92FlzRfu4RzJA2gBBVAqv+ZzMW4rt3+I8r/a7TWn/+4yf/LW/1xerv/uPcgUrMH8ZCS wWyUwcB1/mU0+r98M//S9KP47th7lMxpfs2PHnvH/V87MdamxvrDrsP+o8NYtZfEWK4jHozxx6VK AVh6p3+MRvpy/TgaAXnAn2O6dvre/QXf0B96T66YY54N7ECG4T8wGd2yfz4i6/yL7Hbs1e4fWa32 XmVPMaJ7I5LJ7B9Yhk1I3z8ejY5HsOopdHtz7w9803ivMq8Y0b0RmzfxkfcvOEmYkP5P+0/2oOQ/ G+/94b2OQjavGNG9EasrxUHwX7hw//znP38c/UDutPYH39Tf07ZHYvoXMeIAjGgymZ8l7bRgFenx f0oZDbNbyD+l7vfL4UZVmUjteukvmzeu/5slEIO0uNr6B0uHUL/wJg5GeTICi8P7iCIpSrBT4W0c 0JpDAA79H03BGjbFGozhDpFwrcZjbbG09Pd2gFqx4j2t2L6FFkfyTiHxai6d97f+r51EBIkIX4kI He7fO6Xz2vnGD/2fUXEq93QqR3eGBiedPLHlPW1JF647KKx8o/+b+CCihTzkAEIile9UvM9t8S4K t+MwXNKynZ7G2fKr46z5wf88IVeQajjkDg6PZ+mOx3X2bYPfOJ4mIUY0mOdYo9dJXQgR5oHgSxQp VvwJVBSimL+VyCCK2dnW/cnbuHQorJ1c5S8dnsNu+dX0XJD+Hx0+7v+YSvq5UfoJ9M+CgNcqXyhs dcqYM0Hr/wJvzH08aCqn3iPUGh0fEQs6bg6VJQOUAtBRD5EuBHbZKhF2jV42LdjW9qW5vOY/Ehs6 tqHVNDfXbQsspAdR8ojv7/L9J7S66dIsbvc+pclYYX/oNlb0ySEbQF09sLERWoqClGKsl3AUeRTG ZsAuTtIZWo2Qnr1WUKANkWP4WZaMQ5465k23HKpE99k9qcEu3pLIJAN1KwfqHoT7l4ccQIwT7NgQ 386TOMcy5uP+5IN7Uqw7FMU6iRQrI4UUap2FmijWbdrsshzgXgLCgwjtcvU6r97THw+Bkrz253YF ymkcJwUkRKBylvePj8pRG0AWOWSkRGsgZlqJbcWx9B6dvT6lpoxGT6Q2v1/GJR5xpUcknwjZF4B3 EL7/kKCv9LM5bOIShV+wfX7BKZRGzemjNZze+79eXqHDOY4K0+Jcvb8zpNUoUf/HVLxFl7dYqRpF O64UFgXajcASpCRI9QdWrTx2S47j9G9tv7G8ZNTjnpMfi9NwTIcwO2ExhYhl7qwjHSUZCEnRTZKG +XSGrARK4rRPqR4cTFzgxc5iQscm7NziS6aMvTC3cZw5xcpuaGbGMXV8ydhiQMcGrC5b/6YQ9EPQ j/ZI4lLE7kj1O0I2th3aDeL9n1PJ9TfK9bNiPk/SnP24fw0WD2GnVdTOYKlyR7FdKd0K7P3bUHyN +Jqv+ZrLXz7+9d1Z6UgaCQmtw9BCxrzjxKxvlvzEtbojskjjbzLBFART2AGmgIm7DwnFM7Mfx7oC wAZ4ye61CiOs0IGixy1FOPosVkrEGdWpSbyNkyo5ykY5Cox4DqIxpmRyWhDBU2tY/zHzb9FHA6Qw KWj1jN6mnREAkdN6qyQ2Vg2Ju5z0n6WIFTe1YoYtcmSfaz/DKCHdOKOhQ/vi2sUEG9GGC5g0lPjt On7jIpa7/3gyFHPnCW2NS7wYXtY2eRDmJ7ivMSzdsLhcQcf4EOzXuHT9G0QqN6ncliq3mHYWVisl DSKkNxoSvBBnC+i9225jWdJxUwBxHbNIfv8nVaL3RtE7VQQTEaWEm/rk3wn2ryXKCOFXeKXZ33mP Hl7u/7aFvYBiv43sp4sZk3lxiqy8shiyaGyAu8dm7ewESckuJfvOSnZSQ0ARZ1uLXgc2TYGB3udC z5xliRPuU8xAZeM0vEaFx94EVgqScaH7CpAnQXUQJCjJqWIgplGIEG+8E+qIawkVA6jyKGTH3oI6 /7hhOgeLAY0BEcPod6kTpJMCDvywsuU0417KNRzYNbw0w/xPfzxCvh149vtnEtQlqPcX1CFbcvjj ERzCRVkuCANdFDOhGJr2P/W8kkj61zkKnFSNVThHG0CTDhuM5n3mITYK2oBWg89Y5yScSPhyHL7K pKPNF+3AHZo17RwiSQpNIthdrOjeiquRP0k8JPHoL/FYGQvAOSeMoDXS4kHPNPfRUEYyvPqI0r/k Akg8iWNP0kKfNxspgxXFgI4N2OzxmKkBwvcqoo0EBAkIOwgIVxwNGrk/u5MPH69KAgNFjJUty31x Jo6dCUzz8d2Fd/rrJ4/0J+NbQ/YtcUmK7mkS0ScAPqsJyjoGo0vyipjQsQmD1J9ABA0NAtRrKNdB Iir7/1zjVXEBUmkMQdOlNGlc/+Z7ELwVecgBkHPWV706ePni+dH5nl21c6YmfhHlvHFnaOSHxXHk gxqyOP7sR6/2Juno/GKvtt7GKn4tifeYR+R9wP2qI37lJ1oc5z2JJh7dVzTxDvMO7aJ+5ZdpzdvL 0f7un/3sTCQWXydFGoLz90EtyL/dvRnrRCQWRWLRnpaOqLK+25Gr19xA99WrtxJWNcl6xeSx3P87 S2c0ht/549+MQEj/WfzQ0iKcTF7vZwPkUv5jDuQW8h/7P41EZ6URV0IclgbaRs0tT5R4d5qclwq0 6pquBeYVqFlN2nVHm1TgVYFXdwCv/syjfYZgTjgcyUkYQah1/Y0EBsfonInuej1kq/f2W5wsCJKj CVssLY0SHxsHDd46gfgyzUz7UZhvYZuphHddMdVy4LvCOwKDGZ8F+n2N2XYGUInDa6Z4yomdRjcE H8NM1jgXEq/ryO6Px0kawFoYZLcRPSuuM5LnJJGe9txcjrwtzGkV1zZEC4YGzNgM1ybX9LfsJt8t 0/JqRTPVFgrWAfHxTWIMeoB7zvM6+EbCvOMw3zlTddcAoJ7wLP+ZGNC1Aa24qmUuBFql8xqznWky 44ifKc2B7tB2E/s5tp9hIdpJubK/bXvhP2SraSg6eRMTOjZh6QwrzcTWZSxjIeXfHR8XEzo2oa6L GjXQwqcVffqNWsFEQjcFqCp2MBKom/lnYkTHRmRVClRFKmVOdx2aCFATJbHgn4J/7gD/PGdGImqc m4RglvIcQrouh3Jde56Jqae/KTUnZyNOxLETKfXTYQ3gmwuftqBHGJ2uA2iNQAEC46RIYbvUchMF NnMNm+XJwk8DG77r5uoGPI2SMBHAx1PQ2Eh6RO6iayuWF6+6lAFIQ/CpvjdXaZgASMJsVzgzSjGQ FQHgjfuIiS7rdcWhOnaoKHB19kXAH6IfcjP4yQw01n2yFiZ1Cd6mItcQ+o0FSRBOjOfYeJaQL5mz ZM47yJyvlnsJd2n8i75/yrQxOx7wKaXJALeEsq5RK8+M+nBGXVsAwK0gfrFUXpe0y70JZSBXesi7 7SHrFQ0miydRwBXLGko3we+H/owUeyRJdOzyW5LiHuCvQM2j5Jb1HrOxin3UaqTvT/G9pjjL+4Bp KldM6N6EiLxUhBll7tGvgLxgSBqw9iH+qNc1gNMZJWM/qpoeLAUt5nNvvnmCRRq3UqdJndZfncZS jk/gt09viGz4s5r6n8NkCwFXeIUDmEof2GTSmUnvPJ8Onxk3MmRmj3f6GWhAxRmtftJ1JBZ3WcxK opLjqARvwX2UGoGpYZPFMamv4T+DV3vPDmkI2C/yaQIQ4/3rtPidXgjQMX21d3Rw+HR0eDg6eHl1 dHT89Kfjg4O/7zWQDyqaj84Pzt6c6df7FRKwNGNSDFBB4xnwFh6CfpZARfZZjr7pWRooDv4r0ywM zhQ0FXbziHiOK4jknACUpye139LXQJv0K43ffePn5Xe299u36SkvjkFg4nXydhAVjbsgKtu0bTMJ MXzHErzso9l5bzgiTL1X0Vzc4bVaOR1cM2GJw2cKq6KpWERpKOWGlBv9lRsrjyEApjfoIScpyNBA B9UxAUlI+WbhzTSn/Z8alNAlMLAJP4OaGBiaet6NXZBEA8fJIGy4SIoo4J0vaylFEJFja2JvMkea svLOmnOksJ4tq3ShFeh1n36E2xbcYhFomurbJlGB8vULytbPG7DGRSOgm7z+YsiKbpTxUyqPvw08 kdofu/Es2835V0YFI+tts397FKdgGBkse8W+SUkvcUCHYEFdHKgQBkm9SAEuAPcr96AgwBxM1msl U6Yq8m9R2FlToy8xS4Jwgq3eEtcdx3XYCxMxqZoQRxrUvln4BZYyE4dcP9iGnxQL9wsLjSjyqUUP GQBuTOGBQsDcBof7xD55yD+VJe8QLh1aZr2mcOlS9+M70KV9Irq0Nndd30ndcbSH5qTWPNrrP7uI Y24ojim6tFPRpRVd2kHhAqvQYgwb0VzYHL2lMMsKWhrOQMFCC2yB5pYUkCYSuHgI0ACMWO2SJjvB emPoSmr0MVaKhjtpVThKzyyJPqPmnINkmtKL2PUSZlPTv84ZvzIo1jeXKUNLbhHahwzRwYpsObv8 XSCA+0EAcuw26lacYgKYGYvvT/+mkULdm1gtPkv9ixA+hGeHZfJ0AHNktt0kLkNcxm4oBiTbAi5f 7mN1NEbT9dJY7UcM7ZRG1/El9IW0oB71Jiy6LY0Ix40I5BpaigtuvEvpmHJ9nfBrm2ryyHiaJBnM zfMtYkP3NixHjDSbB/rjiecHUBnPQ5v916+gvX70MRhYLOjegqUgHs+GSfyW+L2b+G34IMa7G34A OYXa/IEKGgxyUp/h/rW4jlZfmVEFgAvnWOtAMxq7MWHTdeiIDYKBDtV+lIF0BuSHfD3zPzqqOgkA 7gOAGSHmGY3yhrVVD1Fp09Vc2mUgBnRvQFN7s1gXrt/Yj0mTgZS6CEE3YsbQUyX1NVMasbq/TcbE hu5tqMchQZJn0xVz0kBcURlJiiYpWn/xHUPjR5jM+2gXQ12wPrb3KU3GKsu20pUZGi+j3ZURAsb2 JkLptB3Wz9trs4jsktSW+49EctYGQFRcIuu51bz7GUKEAB/NlgDab9QsZDJv5odxjv+v3OKWj6l0 DDfqGD76+PryMeewZETIFlj5YNprqOVrZZ+ajDX1CINwmnR4R+ji03hhncqHJNjGsItEM4lmEFiZ g0Sl0s9q7wRdtNMqlPFGFTP5X4Ywgm0mSRQlC63bfUla7BYHWJZH+fbZEIllG8WySjhpPocmnE+b b44lEZaR3Gwchkv89o3523etG07Ie0yTLB/lt3Pqu1x6aLBgMpxW1yKUTb0zlWH3MJ/J0S/4IGH5 i2mIdwA0EsIoE52uFbwRAioTGgEGok4vCV99u2eX9EPSj3b6wT4ExXQ0W8uJIEOOsOW08iL9RzrJ PzbKP+A/2JFTGmmNaN2ItBqk1dBfq2GlNEh3EkK7oQLkIyQcUXIE536YUh/ztEqWR2+pz7mFcCeO ZCNHQvkhbCE+Q3zGTnxGLV5VlcsGTkMyD8e0B+q8cD4oXkNEyHZDWrwCGFpVy7r1V2a91otAp8qj UbS67GGJoIrXcOw1whjo1IwhKe8RgdtoARbYcVJ/PYP4KHJGPUIezuaRot02/G/Efo7tF6hxmAHj fiwgtySKO0gUAVBdqn8XCmOCXlzMrtH8egTNyVSNFZgDPEOsl9k+7t81PAjAVB5yAKhwL5zF78eS d6iCDQ3VWVMVbIlD9x0I3j0VwTu6t1a0WeRutjHBFvlZfoFONTYQBJ8wbfgzcKPfoKNO24HexlhI Gqt8dJb6kxydkKU/LIm79Cpe+ADKIScTtO1IMod70TW+n3gjSoxLTJVx1nxpzdUFSNevwhkYvRNP fZmHIKM8wtXlTH2SJjMaDv7Vj0KQfG9HZ0WqcQBae1pL6Pu/jkNLGtojK0vZgVuGPfwjITO6rtJL aYH15sauZKk50dzIyPQ5KxTPayk0S3EkNnSM08CGH99dkPGkMBagZldADa0lAChzeo1pMN5Hfhrd JClWTsyWUBvjYS7tsKy4jAFQEetiAuI3xG/sxm90uYtsjkbDJByjMTQvcg+raf1VLgRxTtIN9+kG Uo19TT3/4lPPbp8SyAsVFJjxS+LRJ5WOqYt3Q/MsUA5G4vguyUB1trFCbOjehr4N1+L8xfn35/zN +GVDqaIxks0uQWtXUAEp85e8h/xeqJxgHRvRXmn+ktR66Nh1DmDWaUWN0UvPjv5J4HIcuPyKTb7f HI9FygjkSn1G4gGSUXSLWQldoj6ualQxn2PzVRgBGYvumL6SPJEkfHRJRPpLRFbPsEAsppyfvS8L fXEMRXMwYcPg1d6zJ3vEiS3yaQJ9//ev0+J3egF1LEbwqOk4OjwcHby8Ojo6Pvzp+ODg73vU0yxX +/BWx6Mnz46O9Otbk3Tq/o3se22viCejHzBQkX3Ap9/0gI21N/ivJAr1mYp29dx4jiv1Je9+ejuP ZD50Qr8LvdMGr/B39xrGbT6eeeat7KTGj2mt9GxtKx0d8DHk3nrfSrSWJ1E74Y0DwGd/x2ccHZIO 4Klx7hsX+vnav8kBXmg60vWw2nhMWGf5er9Y+3HNwWn4r4Z1nV3vE84eVlzjhnFfftPT7sprrfJX pzBup0Xp3pFdNt0W/HVX1Rf5o+aqftrUBlt1Vdv71fVVoVe/uucHg/rV1dOE54eb/mgD9CMr0gRw XZgmUddd8b0bsF1ir2PSmX3wipCzwkfd9xBuJavYXlJQO8lH3/NxIR+9wtL1aPR8/dqhK/a6jkad kWhImV97OrDxAzcMsX6NM0BDlEOP3bmBG4uc1Af91hkAbBjngfjD1BaHjTTaUZHUHMD0ZABwG+n0 FnLCDSr/w11U/rUgv34pfaR/tD9TTggKtO5keiTLd0fI78WZ9VWHbSu56+Uh+7od23pIN6F0ZVWy PDPbfxCVczeAsdHhnTs73OHZ4Q45ecLi2IkU7hsaN9LzRDSBJOdOzt1Ozl3FXuikLLMWsyXEEum1 ZMT2f0IlTdqI+oUG4CpScgdKK4xYIaL0R0QxjNgn2KUFDT0w5A3r1XtPu4tU7JPeDeYry8VuDbps /65D0nlJ59va4P89RR+rvUnWzGmTRH1tQHifFgq8/+vlFeBBaDLMwlh54QQv9n9SJchtFOTAZaMU BNZSX0LaBnHj4dtYLTqWbgnXUkJcfyFuJTyFvOvcTIClihYdQSFCawngsGaYICZtAUqVyZPwFHuq Js2CrsEw2ICpdLTMtGy0WJpMpbODZ2dnz7dLwLTt4JQ8pf2Gvq4RDt3APCf8I+WW/dj4lW9Alxru r/wubN7Rrzyj3Ro4+hI2Hc8kwEeNk9m1WZ5klU6wnhK5eZ7Z70vRmrZUilhwbwBqBuVosVfOtWKc PKAtbVo5lIJM3YYiRsFK5o2Q6Ih1QEmC8vMCuxJJxEZSU0lNd5CaXhGfE7JJXVXTZ5VGiR9UO4qp wtUexAA4ND8qkdtx5J5CHZqxiUsYx8+xDDwfT+FEmr7+3YV4lPt5lAeBFMpDDgAOXZ86JHrR37Bq 9isK1iS0+7+SdJrEKt73VI5cGk2L8g+33Wnjin/rvdj3MNn6rHzPfvEPEu71Dp+JXjQd6c30ou84 2kNzUl85SJs/u8jyNjV4gU7eLcsritgbL9ju9VQO7Ubi4VLrbuzfVM9vOg76JxsnG9T4BLU6fN5a Vp+/RjmCGnOmfAhGoHVaL1KgZjMKeSeq3nUWym5U11hiiD54rYFKK+gquRApJO9XSEojf6NGvvYj vDV1c0fC/wxeRdApx+hUy5Noc5bKQ+JKxJXsAOV+q3Hr9YFuYKexZXiJC3HsQhoMO0K1jR2JqZen SChnYUYbOonnhaylmJPmmOEVlCQwsaJjK8Jo4u3F2+/O22etLarECm33xKjveYOcBMQ7ap4xC088 hWNP0Tac3Y6tOZKMHBCrt0wiyar6PViSJwvEhI5NyMLSTI+30Rhhe9lyEhAkIAwvIEQKWzo4GiBi IIj4EZJJcSmOXQqF7nZkALhALy87luWQwFr3YkTHRuSQkIUROMXQpg9v4iRFpQYTVqRUlAlaZrBh Vf6HHz5eeddCOHPdHNAhPQCzGKZDAj32MyWRXCL57iJ53VuU1NUVM37LoUCigOMoUFUHNypW0DBR aBjThGZV0tliHVvLWyRk8TTiaXbgadZiMYwZOsJ0VH2ZxgLbX8npiJtx7GYMr8Qs7a7tTCK2iSkd ykhid3rT2gCiO9BnkonY0LENqTb4mIY3YTz6hUgoK8wmQUGCwg6CAvjdH5JcHUMGH3VPlkQFj+77 WVbAf8DpY/ymfWIxy2dPLVqVC9UcMic2phAUwdo8x6QxrZLajRWttw/jcVQEmI29vmXDtVYjwshx kntjdIZu8CE/StB3kNBOevuGqu5uWHbuU5rF4gFAj2oDiRILJBbswIusR0+UCqHBx3ejMrJSmOfe FQIcTjSTEuFiCMIJtYTrgsxis612aSdxQeLCDuKC4ZqWp4/IiiSjA9kvzOl7n/0oDML81gsKI94M fOJ3lSbeo72DvceUXcaCOjhOL8mlNHJKLfVY47JUSDXUF64V8ZEU6XGrQNyMuJkduBkDRcBfAHPA QJ0pVWM1BnvFT0O015HdpMk8DQ0bGlp7kCrlMhenV3yMYx8DA4IFkd7ue/AgcDggQsCGCBvJbKag EAlMQk39zyGzVg2u1PBJYkH3FsyiZIGbhjmEIkV4BxwxKSLQxVJ/MgnH3oKIqTAmhQeQi8tmZqnT JjZ0b8O5SsNEwnYoYXsHYftqKbMMEnQOCGU28Rl+gpJLdh26iDDeQ7oHg4AbbOuAE6/SeKbCIy9f k0Z9FP6ofvT860zZ7QbvLsTlO3b5WoNiL05MX2fvsZRs9/P9D0L9RR7yT6WMd4eElljye7GkKKl0 Kan0pFr4/L6qhXL1zp8c7JmNGp9aJAm5evnef26RLWJl7dx0mEWHUHQI0xAiAh/Ugo656BC23B+z QLZC8zOLBZ/yYsF5kspmwddJIWfxeFCamKdoEdizydNPl798/Ou7M0/Tw5amn0zfAKokGvsTzMgx ZlR2boDzgb0BsSnBjO6HGUnptpQkQHB+JUMRXeKSUNRwIL/FyYL6xmlS3EzrEDNxVwBBy2anoW52 In5iyQ4z3YRqdgQ0AB//D3S60ezPJAQ4DgG4iVkxt3fw7OPb18TasLpT9nUO7mN0gcbTJMlYhZAn SGDMXCZCBzA2Yol7ocokhEsI30HLn7eKG6EDTudbUgcUsNvCRu9P/wb6F17GPGGCpvKtuH/H7h+8 7YJXvMNcmqqHEF3EhvRbUbt0nccryOepAn2vgDyAEbEQIzo2Ylm90drt2N6tZqbFpuM76c+Qi83n Ea1PJXlhSAOIBR1bUF+vUX47F8kpYeztYlq8Hb5boTpjf0HiRdbLV/tSs31m2+NN8RuO/UbLanqe BxlWQ/wZedZSJoZiHdUcjZd/lvrNdf32qEy4HlfXzWRcNtsCHZ9je6eiwxZKPgE0NwI0WTmF5pJU iiFIlvWcJhG0lpAjow+SqusEXGij2dRsmmzBeA+CEiYndMMTSsOfDUCvrmRu+Pk8u6VZ+pi+i5UK ePzHD/5fkeUS7h2He6rfOiet6Y3lRM3DfF0TbhdfI9jgDrBBNBVIRwbSALmPEZF9L9Sbqlr+ZxFm U9IXS/iTaTGujqu4GseuBiakpg9bh6aAwhg4YeliyklPLhN9jxTEkOjomUNOc8KZ1BWu6wrYkMe5 Elaa9CPUEDSGXcQE/UHSgQTpMZztRxnAeEIEYe72TZWLOIyL6FXOMpuCDmhatM0bZ8xtxaXLWypG dG9EXDQEOutKJRGTRGwHidgSQbNcOFIT/SndBCLBDWJFPmWxMcEHM7QihiAFZ8kdt+I1xGs48xrG Y3QCRVVyIkjRIFwG9Xy6/Ho2V+OQNHzmfgoiAKj46OZpuWgi8RCOBLE3VOJgBkjW6DhrRHI/BiDr 3yivyKCcZbfHvEuwya/DuhIeJDzsIDxsjO5poXlxLoOa3YIVa/5FIesHgDcNb/BXideWeF/JMPOm kPVbJCl60SrYlwjhOELAiMDZodb3daOFM7SnP8NodA+Z3y/Wc2+9dkckKUAaqNfmNbFTKQOxVcbo UFzQIPZ5g+fQzLvt587UxC+inD8ujIE+GQNUK7T5Z1gZlIxJmTcAXp1PxcM49jBko9JtgPF3m6Mv x4kYAdGoLcDi163Z2qcwB2BWA22hoJA7uOEdRN9gEUJ8N1UZ/BhNWeqlou2rp9XaLf/f0j7kBjq+ gdxEJ4gly4ngUIEstdVO3BlCdkYa53w5K63NLdzARtAUPSckCqBUvdr7FGGVxZX68j3rOa2cx1/q Exkhj07MlxbBdmz8EFfj2NU0N66w2ArF/44iHtrtMiZ8zzmjB+E+v5+HPHj54vnRuZUvvBhyObg4 jrCQ08ajSTo6v+gSXVuSAjSPuAUVwq/8RFB46Umc88V9xTnvMO/QzvBXfplW6XH91bkP+dnvEGWV CrOrwhQpT5HyFPnEY72GKr+gzdeXuZ/mCLdh8Grv+U9GxtfixkPgfaG7c7dKmt3LjsUqNLjF/G0r 3aTxBSnKHBdlsKGeo2D5M+WneqGilt6wnbj2YB4pbQUg6gSktCUmdG/C5pJBveGuCc0tGq7lTYwG SLdjoU7Uwc/PX7853atn7Jf5baRs7v+al+XlF2oCUR4MUBnfdA7MHmiwloe4mqqZerU3C+Mk/eU0 zkKqcTjGLb9Tk26ufk77X974QUnh+YRO3Jx+uG/qtg0t/6ZH+2Qezv79zQ8pyWZXsrkSZ8TRbPs6 ZqT/ptQc7alar4rah10oI/pV4hAdO8TaXmeiJPqtuT+eBoSPZAlXzLyoOCvQU+RRNOKlxkk8Ehs6 tqFVeLONQs5SfshqN1CLeAe0x5UELLj7aJrFFlIWKzq2YsXLQ18Y2WTbuaJ5rFMXWQR6T7hfAnxX gOftFEe8m8L0sT9gWNz72ax27t8vSDI5gE1LS50Hg8LW65hGjfJqr760w9YnS6+Os+ZLjXJltYg8 S9hRaKpRKUgkC5I19Oq/C5XxDnnOMAOadUGxZMROfRGzca1OYC008/MxyYCU86aUgzSLa6lHcfWW plFxn/jFIfc020X3wFxICa9qZ1EdRaS9rI3I+TASK5td1V0N+ZX+I50kHF0Jx0pEgXRL6qOOOcJB PgMa7kHaWGfEbFsWO4Hw8TXIyfx2+UExoeMiRkvPBKhU5hy8jeEqU1WyBFmeYDyVSLBkWokT7P9l FGIchs0Msu9Uk9TM6MStmrzF2Z0gtzQnE1W3nbPmPs8+slJRw3Kdb14qnmr3npVz1JWHiZIbzMQb RyS5p4xR72CM2uSe1SEsMxKDtkKMjeJcmuR5RHMDpXqwTlZlbwMFPrcQRKmWV68L4P6plsVuHKzi sKWD/pahCIIo8AnJOx0bD+4egt0pjSt6Kk2pk0VweRnIMxMwbOB4IYFBAsMuAoOubsY+Ldqbtjhe tx0C0LqXh1FOCDhQt048i2PP0qnRXXXN972Z8mM9CgjzNsy1OEbDzlByXhwQp8cvcgh+vtp7/zot fqcXAjisV3tHB4dPR4eHo4OXV0dHx09fHB8c/F0zivCRlWDhmcKo28HB0fnB2ZuzBgGpd+Aez0Hj dN3IDcTl6bHNZ07oa03NwSvcTuh8iO02Gk40XFSXyG+YphcUWuC9jeA98mdwb1hWFua0AiW8if0I dTaZitKoFiGhWlLUsByoeDER54jp++Lwmy7Vrm5PfrKkroNncHU1ui8xZ7eNX7RcEWIWwpf17k1X +FHQi6sCsqW+wZfEUnVqH+MiBEuicH80YiUJg+s6ktQ40iQizzbxsynEF6XWkFqjv1qD+TpPmK9j 0xsh7Hw7xV2SuY2SuSskbbQhTQ+/lP1ZeyJpTsaj3kme+tAhzAmnX/ipUBeFuriLjagajwdR3eC3 Ff+DZutuOdnllKql2aelUiQNdoy5aBFrLW5W6SexXhbUs/w4g0YmcJcsAxLPgkuGf0aKS8IGdN5J oQwYAkx8wWC+y2JOYUEFo3PweTA+knmnv36CGan0B2bGTC3+cMXTkivo+Aqyn5TCRQqX/gqXFcAT YA/PI9GyJm/TtGOZx4EVZyijR2HJFmt/GBCieAzHHoPgK1o81zAW765oZ1/k+ctuO4WGUX47R64W iw3d25DQ+EpAtmRR435WlspsRPfaK8zFgu4tyLU3ei1hHOjlkJp7RGZdkYtJnJc4v4M4T5jRslb1 6OO7Cy4IuJdhawdsOMWxBWoED4TYj/XlpKjrp7fiYRx7GJIJoCBR61XVVg2u43LEhI5NSOU3l94E j9HGYAO4lPl1E2KR8HC/8PAgBp2/n4e8Q4NzaM2hNfVHlyY0vwN52ZciL0vMnM1Ur+442kO7v2se bWEnbY2dJPKyIi8r8rLHqQPa8kqInPDxBrfi/enfsNkpSWiuIIHgV06DZnoYqdoSof8NfUBoga5p gU1pG8DfoM2TNuxNge3N2N9VzoegJiuJnsaAYSYls+OS2Y9gwADqFLqZUUq01YYFpUy+X5k8tOIK qWVDXHapinI7p4o+24cEY44j723sZQl2ANJ0WeY9Uj/e/OjZVUHgPpFKdQKRLOB1M0ht6ClWaguI M3HsTGBCQlDnPnRxr1W+UNAkquI7tUcb0SLbJxuyZW1kEBO6N6G2GBBU3K0gzMagt4Lzj45o03iP 2daVebk9N/OlkeE6I8MtpLz5mloZ0GtHlryUi5EIay3C80huik5UiOXbZFa5hkO5hpJ8SfK1gxb2 ch0O4UDvw8crFittF268kdn3mN3E/TaMwIrLcOwytM9HxuUHn1WahxlcOdgyHZymmucX9yLuZQfu xdZ27CxI+Lh2BKvzWh7WUv1smkAeWUSk3ItIwYAwWjTDfxJcy64/o5pAMyzsyvCVTDypzgdhQ6rO Dcccg7ZmgIVvW4K30qZ1ZwUuH6qISttCYrzjGI9rWLFfcftitfAmevjIuw6xeKuaTjIzSaNfoRAG lAXUKIn1Eut3EOuXSwm09FIFZRwzTY0g8asfhUGY347OCjNpTdQ9SFJhHwK5I3E0jh0NBYpwpjWN qurPSIBg+p30CMcRFMKKuTVrI6nbgq+RdspGQga/JAuFOnCf+rFovV68ef3x/fs3HyCppimyOhVo 9N79aOHf1rWs5Bo6voY22NMAeCkm1uQ8NHTDjtbWDXt2uCzGtzvdsLh9soanG2Y7UpVc2xZ82tBI iu0WsbARt8ZGXEmJuuIareGYtXxHmfo3nEFchedkPC5SXsbbvl4iI7RjwTvUZsRaI1zE5yqNhsF4 X2xn9pspQCpgs+kUmBQjSYlVrOg4/D7aO9h7bLbytBrd5ko29sZitK+RBEtPxHUr3PS02WEWcxIl hhwrsuIo8YmLQk5WorqgIjtARYDcncI/IAygy0FbF6b+ZxA0YkJXQ4OB5CGT3qJxEfFJRRDxA44h yP4lGDgOBrCg1UwfBRa2MmPdcCsWeUWcRySnco3NSV8YRS9vIV1y5xpesCJdPwrqoKdnAEfYTHb4 m9I0Yq+j7ZH5EwItoeZN+9x0FiCX0P0lbCViZK27szDtai29TUzo3oTkFOmmIcCRAw3jghvIiSYb EWAJFktLDbHA5yLyq2JA9wZsJy3kPknZpEpvtEOFCmKZbsPSaPmQ5gmlPmLFgVgRoa1/WwiuyYPs mGe/zG/BwV4cI3V8tfcpgnwoLZzZw/p4M42Dv3pexECgrYEthzTq+d+0Zo64Xw1ok1Ay3kUH18G9 KjWZ0E6zz5R7YdGOukEpRB+QuQLXYEopVYUoXC58RK0TJIsYeujKn2HuIFCZTpVThRCg9rkSKm3e v6eRrvBGXWEe0jHYJbG7SdmSZMPr9qTsjABpoNB1LerFNBxPJQHDljPXF5FSZ5YkNXcNWVaIWTq2 m88QEjItAjuXzFhZXm6i4/wLCIO5dgCPZkWUh3Ma1gIEmElCJpD0DiDpkiFkZ6tX5WYBF+tVmOc8 DUId4kMc+5AMkEhEWCU0UuYJ0Ewz76mjuqZ0V3KWM4UlnUi2swJxXKBo52E8QJGDJajYowYwGjlX mSVzGu3NeL8Qy1jGCjGCuwqcp5Ucfmkwu07FCOZC5ZPh8nn6vjWcYmNT7pP1yXnPlsl5n+qJp6nr z/Sm3J9ePH9y9sLhplxknvHdu3Jru02fftOvgbJv87wOwA2s323ZN7U/Re0H2yK2szjOT9r8z64f wf5UjVOz3Z+rm9Cmz0V+Qr82vT3ZIdXzxILR8LjnuLnqiw+OO0AK9JCwcgldebyYqRR+uWFmoUHu ngapw59mSVCXaBLeYMUSWDtU10bhDF0icr6YJJ1iEiGE8ciMCJMay9hCg+FBgNrykANA7nvxN9+P Je9Q+R0a/Lumyu+S9Np3IGD9kwhY287b+vf3jqM9tPu75tFe/9mN3KBNVc/UxAcMSnn0+dCuNR5q ANKJImAtAtYiYD0sAevGhl4UlGOG6mj9K9co+x6GcGPaCsioa/npKeYPjPSuVJqOUfRrkikFjVT3 TFl/wFaRREsESbFqfRiGQ/82G1q0b0c8Ceu7h0CuphjcD5JxMSNoys8yfKFXgVOvP9Vb4L0MhxSd 4ywp0rFiTASAdDQb6XaCtAiG0CLwvRs0e0gMGZZh1WO9pgwMG9v5Z+oUzx4QJU5/0rSEsv3+/Y1k 2BvxpthcjDVyHGcaFUQvvUmBBuxvcbKIVHADSfIJ3cyK86yFUvSrYkPHcR5ONITT5DuIBgDpFNVl CJEBkIQmFK8xkHBThFldw5ykkfGq2NCxDRuhzZukyQyUYhMB6VKyb+WXm45VKFVCqdoBpQrThW8w 5JKkP2S8zOKYiB06USPfcgtWLVpZCPBZAb5AzMHCv0ZXEjsTUv8m9efTLZxUifUbxXoY8WoBMY4o V2mMLc2faf4ARiziABKZZL8QX+j1zaORl93GY/Qc4/B3/VIykSjhOErwkO+/CxWjIIqL2TVoVtwb 9vM8Da8LHkJDUmYqJOQCbyco7GtXUxZTOWfHwYaUn02J+Ub0IvT7F4btGKkJxrYT3nARBOA+Gqlz mgT+ksO5Eqeu/0soEM0AWuNLndOdLK06efrjE7iJT6BfJuMk8t7oY3YdRhAxlZN2wU27xv24aDDP pMeHzOGDWhD1cZy92nsNsC40L2EU1IKtYPd1s+goJanjCkhC8hTnMEsiHc2MZgW7P2xrQtuBl6aF WMRFGtF56k8m4bj/kyqp5UapZUXG96ObJIV5ZhjcIgvpXMTo6oPXpsnErO9dxJiHTWJIJue3Etak jt1BHcuz2oGahDF1wLSCYZlaNbxIQ3722frU7pfLDHcKIm9Onzx7cr5dKnt+soSnO+Qkr3D4+nde 0/b33tNGpmus5COzICsG+7VhCenQ7b5DR2A/BD2buxaQKHLnrm48NPIKqlJQtYyT2ayIwzF4zGI/ x0CBWY7FXVOyJcdbvU9DIq1E2h1EWkrry8jqYajW+Hc+iliKoeko8B2kiXX28e1r77U/97dVeEo6 v1E6f4qOIbJzpfkZ6NrTRErdVh+bWrNIpjg4KJiTXA3ZV2KA4xhgNDFqmZWGFstbCcqNFvTs3m4m 6+kocd8JDLciV/YoByNRFPaXNj9mQdYagUoCugT0HQT0t7mXTZMiwsZ0OPmEFMeZPPSPi/PXz188 efJ/ygLuf6ZJMcfbtPqqdDYSDhy7kpkaT/04zGZoGZI4lq3mIG+ZLADW8dCpnRtuQSSm4hMbOrah Jldm3gyx2QcbAwpn3C3kDn6WJ0mgafksfDMPb25ur/3xb7iKoGT4sZjPsfnUF83B0yJnAEqknwud GIneO4jeVI7D/QcR4d6giNQwvLuXq+ogD5qQeA/H3oOIdpiVSMYhENZAL12yuh9eVwOuRNazuRqH k1AFYkPHNsTMFcGxZVZspl50acdvmYspWokSF453EBeaDdFWw94sLtYKrOMEK/hIjY8X9xiXonMY cSuO3Qq3UGtOJFOoEPJwDC62HtxpGVazRqcJCDRThWVMLE0uVnRsRYoMFeBXpmsaWfcaN06HdtZQ xKUkYS+vqZ4mTfPdN82bHrLWcvWu9eoXY+Bz3Ygd/Yp9AOirACYTCFeKwB0E+6umgym5lXMUhmVF MdecPOg6XI+475DEtC1sIg7GeTeIloaMb3W3PCSBR+rP6uEcsmVjsRtF9hkXiUmRe9cYOfhN5jzd N/QIj134aUBsqTlMpwkPJU9HT9MjCbjgbTKjq9u54j4K1uwUCpnAWxnCct2TpShOwb10kHQVb/VL Zd5N3ZQSb6N/EaJuImqcYDCu7VdjpHNlS8ubyJ6rbl0Jo5kGvCRr90vWGmM0n1queAATWL2UTPKQ fypL3iFTOTTK4JoylUtzhH9+BdajA1FgJedEiMb6TuqOoz00J7Xm0V7/2UWBtTmK+dXpTFFgFQXW rsHdzd2OXL0Nr95K7u+ZEUg0PeKQJqODgpQ/2mO1pv2TjSECgkaArJR1j9TRHg9G5qwcUqgHKPxx mmQZ+LPxyMxo8SAq7WiRlr+0/HfR8v8A92FZJt6jtYlgj+FYSL6TtlxLq9h1qxi4cOY94lEQbhq3 8OLHJWiVqhuQTqHVZhhjb08/nAJHPpX5LNc45IJETBCsvbMQy41homaLX8tncAeO4zs3+xHeK4PK LXR8C9mC5kJdKuVdoqEPSrf3suznkC4+tFkDb54mYxVg0ZdEeYnyPUb5k2dw5u8opTy1wjv9u4Wh 4UWoShtbawQY2j3ZiZVAMuPwrJY/laqqimclOz2iA1pS1Ps/oEPD6tsHdAmUdztVXGp0SSvzfq1M OW8pq/41Jf4Qiw4RjUgb4nOoFv1fc4lDA2iuDsyXXVHAIfmYJj/agGs6IBlZGc7KS/l8G5z6P6bi Hbq8w0qcu8wLoExutSPNXHM5uAa3Qobu+CjLj4kNHVfCRHcjKAN6g7lP6uSYO7EXzCOtEsI3Zizv Z0bgStCDwkWU+MKLc41HVfpbXkP/iaEL5O82yQeaAdzRYh1PEfP7v34S6SXSq1d7czPctHdihKJ1 IWnDBNyK7nnyicxpq5ytSPEllaKgbNLu3Sqy9H9UJdpvFO1ZwmRWZJhJwG6/Yk7tJHgURAUI0VTQ gd4axx+2WpaU5YmrkYJ1R4NSLVfDSUwW3pBCsRbdwX4uyM+HN9Mc2Q/PdFCDlDfjRVjdIZ7GcU5a 5p8dVQPqCeiZwaYQtWTno/vaxMUwnicR+zm2n9kpjemMucIGWEy6YRElemmFbrKZ3rc/g1JpznPu ehcEUoA41/WimNCxCc16Dg8TUthIqW8apWXGtHihsmeg5tgPa+lSvDACVhUTOjZh6UW1h5QETBKw HSRgms5UhWPSntb5Vq5ubsnbs4YlcyevMVXJQtVRchOOjaax+A3HfqNy8bXoDbvZqI6N7xkCOlXs CN+P7LgsQoIJ7GM/E80515ggXTTmJj+mCl2H7vpuaS7QaYdoO8LbsCH30Pk9JIRFwraE7R2E7XO9 txxb/MZqnhd+5EXqs4q0gJwOzz42nHIFUHcjY6MrLt7CsbeAVgwUYhGEfdrPwsrg4jrEdezAdRBz 6DSumsa63CSILlVjhV3lOJOAV8l31ERwGw5jcRyoCKOuYfBq78XzNVf2PTk+fLq8sq9ryeuZiki0 4uD5wc8v3mx3kx+e4woasSc2i9KoMj2sfYe+1uPgeOXkfzS2Fb74pkff1TPmJx9fXzbsh0fifYX4 e06PNLfbdelHOm+0hGUL7+J444nlu7bwor9Kd01hJoUGUXy6b6jJijn2DODLR9B/o8qNZhm6SwEJ ExImdhAmjhAmGk6j4fRfru/5ngzV6Xfz5E75qdfx/j990+9gd96flKdblkzrDt/EWftSIyJTdOAJ EPx1jpXhGT619cPX+GFtrHLDhj0hCYCSQWchNfhvYDUqZY9t4BqCSUl3jsbS0iLmtcdJ8/d+33B7 1siHrJ3ONOOGQ3Zf1Bgce/zXU1r38mDT0w2Kev+HhH5lZuTGPrf780kh3FsurhvHtp4nvjzc9HfJ v0r7wLvzFKu2WteOxdE3PUrDdub5mqd7qw4Hz8HZPqdQ9hsyWy3B394lbeTV3yDLV7PGk02tsdVL et9f3cU2XFnf4aryRLXf/9NNf/+Niz2M29CdBsHBPSFuB92OFTel4eKefdNvYncubklRgwthR8nF EjxbsveJVAsAF1rThN5i6UAJUGi4phFrHsi9S21AbNybrQaMfOXloAyAUz40Vv8/e9+i3LaVbPsr KFWdE+ce0SPJtmxrblyl6DHWxJZUkpzUuampFAhskhiDAAcP0Url4+/q3nuDAF8WFVIbsVpVx44o eY6oRr9Wr15tjvua6nCbIN1KhNhO85onC+YAMgLEbKB8/BoQg4l4dieAysMAlXXVM5vK1GsJi0/i Ta6rfdyUJR2l55/SbJAmKtn2FC22oByqPk6+jIDQ5t5H/857ve3t7ey+qr5m/+PXS+LR7u0+VFN3 icDjk3gqn8SbFNebt9QkKrkrz5xsfypZD9mCbh03ugTbOvy1kIZWdTyNlrM+DHqzAgPgVVuHQe9e 3hfpWGHoP+fdPh7S8aJhMIQFl0gHQUnL0A66elbRy/OBYamZDpv2AKffjLTLDtplzSf8T6ly2vu6 SMAQGkG0wA8GGq6y7EKv8D+rhFVgFH3RICNiQ8ekQ+pMMLsEXpWrGIpy2PTIwPVKh15SDrugo3RV MVaw3C5TwHZ3dmDmM33YVn+jmLAFJjTGgiVp/ZlcL+Fp5AR0nCz71XZC4L38fWLDFtiwTiUAvg+c v0p/BU5IFrRnte2lRBIbR9jJqoVeuLCYsAUm1CckkzQbgn6fgdBNS3KV8QRVfhiqLIDIXEDk1XMi 5E22Nc/TUHk/qoF/G6XZ+sOBYG8iCzVPFgry+YMUCwIo6WnbrbE3zIVlNcHmjDWjGbH+J1Xixbx4 sXBuPakMqQJhxXy0A34YYpoB5ejaXgh2y8KI6YwoNP31MBn/YkyfVuFvU3fIQxVEOcimUmdInbFx RrbnEYl8JuxT61ng+jZpCxCegP0V6lOaIvQiCTg7jnBEWqqSM4EGdN6ODJZaeI7NWxd90jJP214E Aa8kiEuIQEoiIADf7VEBnE+/+HDl4WARKXggb4/SBAhBpfMBd2zIdU4EZPeev5B0IenisdIFBGdC xkQQayYPrdYoaPYP+oiaxS89X9oExzGmBhtPOgajFwRTXllxwM7lRDEQAUmii0SXR4guNzxKrgMQ 3sfD//UCDELAuNNQuS1kak8ynt+87OboewGuS4hxHGKmNhpywJvcZIQp5Yw8NXZsWJnlrAFMQAd4 KKQA96XolA3RCuqMX50ToQpV6k9R2eCG99EWyE0k0YmgEUBqHTC62iQFVoGUkXErjOYW3ZTNG5Eg nq4bXStqPMeO1+8vPn04JklLDCNqoLVuK+z6FRKJpHnHaZ6MN50mMFCYuN6tH0chL83Vs4bYzbHd JGtL1t5Q1sb5yhdMZjDKlMJlEDbzI7OZb5CValyGukQqFNCnmAzjQTQhMVc4u2QoxxmK1LA1B28O d5J4zigMZWi+1r0wIdtkc84xLyTbMJ6lVVUJ08LzaMYgQEXwiZ/kY/SeZnDnjcH11ehldZ5VYozj GGNHUtWxBBjw2t7S65yCqF3SGjjPYvVQvXnNjIddYkXHVgShHio65uSYnjXyVZN5pHsiRGjAgfec VCjWc2y92gRn0VkTmTvK3PER5o5YnztPC3XAAaIZ6LnenNyknJDe0OgeamQ5x33cGYVF6fweufOD DXV4r6eEMEUST9LC65c+Fh0LRXWYPqCBkmwc4WBuF8uuMhJwPRKA9fxunsZlMX2hsnmT8sqHkTOm LlYmpfrMl7l/C0zYqK/qR0eR30lw2SxHQmzaeN5Umy8lmeOSjIKo3VKV2ktqr0eovfQCAkTW76iR qyaK86A/sINMheZjOmz3qiVoOA4aFaplGcD1Cuzjp+sbbSuo7enbKCysn6UFHcqCxWXL9WFx5kms 8sqbbMG+8v2l53bevN7fOyXJcN6NarMq2/ggBqsYPyl4Kj9s9bLO6dUWVPTxXvkuih2vzEiUmre4 gU2vr/xE0Dx+tx7l0r2HKpcuMW/bHPUrv0xr3rU82t/8e1+iWCuTw2zO5FB0TkXnNIswAz5X43lZ 5f5hR1zvh62jtKx+mUjYQd58qZa1l90FCCHHhaokhez3MpyqwqgYKB6zYiXUeJS0mY7bzIlmWpek DEERLyYzXbsMMEjzAi0lkEY/HgqC9bDOUnL6TOBeFlggpNkkIgQpqD8ehOM84N4UayC4adFw4Kt+ rxcFtY0U7PXLYrTr6QXYPhjjWoNVMKTZOymiIWNVJbQbyaD6sju9hKXFQGUJTJhJinBtxKuTo4uP H0/Oj0+OKTXQaJeud6oQw/obmK3ppnUZA+OVkuQdJ/mJRDgcK1fZLQ6v4koa1k+3tez0F384ihU+ iTJket4T24JUdVdtWb6liKi6dkO4Xqz8TIsXV6F0ojtnsqL9CsSKElK97CoMeCSIurYe7IRGqU/J DYb0k7uqZNGqj3/LcB4ZSkRBFMJy5koyOaLKEGavkSljfwMzHSlKVypKJ3UJjVZpXd8H2SnwaQkG hPQp35yUOaZwLROSIJd06DgdUq05yhS0gEs0FHDLOMXo21grL/hO+aS1qJbcpfGVxvcRqBv2gkSD hV9RLvV+DNVuHsnaIQJVSnY17EZCjOMQQ5I7iCt3VXix5Rhij84Sza7JKjTE6Ti+E+s5th70O2Ee e0eCCjMqrmucWQuR2uRhrCsZQjLEY2QIKMxCRLjs93FaCo+eJd9PITFoJiZPsWjL0+aEpdA0rh1u gHSCSSTzXZYB3FMs7QlF2GvEf0zm0iHdt7kiub7rws8KvIso/GHrzRsagrbpXaFt3dv5L4+vmOWK oIll7+UEX17wTkir7XB/7+Xx7lbdOtfFXYwFE00uOjK/FtXDIjDgYvPLaMhmAZ4c4jADYOY0e3+Y 5BGRqHiIPvuVxsDT/s7t/3jjByXruvrFvyuTIorNrLVS35Ke0j2+QwhqoVDyZWqIuoCUtgiCq+oG hOyFLi+FgxQOj1A4YBEFcc/rpzjBxXAxnsmuuYpEJQWQSUY7tK4CDQD8bhRHBdqYXtXJNLKTUG4u dSpopJ0mk8amnJlXH0i5gRUnqH8xyPx8QLCyFsRgFZehCiPqWtCyIOfxVZpehruVmJj/l5jPcXMJ 81WQInkcCqbJ53pgnhOuA6QAX7AUHJ7lIK/A0mJB9xbEMajgM3J91w8+w1g80qki5MQ9Ja9LXl9f Xn+3T/IIRZFFXdro/tmPS+Vd+pjZrz8ktI19bztqKjgo5Urh8fiFx82AYCdcrgLdtzqao3Wc0ICn fL2Emp5cDaEKEQUYrmmm3nHkQz5QyfzadZd6YYedZ1CeD8ACgiHnBhTvGUS68u9h5V6UoJflekQu KTu/ZhWmQUlgoBQWUlisr7BYKMl4yAIjTPc00cKojpvPAmo3EfoztCnccKJnsTMxqoKLLI3XX5sI aWkl0tJQ0amfKB96dcl49JfI5jaeEONs6H8mHAGXHpC+Q79IM5DUUjGf426zEuVlqi6hAnV/pHor M1MKJhdyjTYCjxDrEJzgxYCODYjZ05AJ1/Ed+rczHt5qcIdvUUYTiJVetbVy3cpiQscmxIXQqJ9g 0ZEAO10Te4N0PJPrQMYysRZ80DT7jA6IgDzRUXNeONdiptTOUjuvr3YGKLeLsL5Q6Xr9sVuguRao 97SJdmPGugsfQQZz0I6Fyrv58Xj3exr1EjJ3N1LeP7K0HGmywvqfVGnUVmrUaDMPmyLFOPVGJVpq bJUgspzSTh5rs/pJkpZgOpFAMs0DvyMS4IgmhLY1EBM6LhSPL86OcI0VirsErQI17SuUjX4MO+JE GAhxbEhCRvwI681U8Ovr8yP+BxovFys6tqLxKoRFtmfPHq4w4wy74kw+CMPewIiN2Cv2c2y/xqUR 1srE0jpwyrik5Up4pcIc5G7Saht1GrtKI8IRzts1HUd1ciNYi+kv5He5dG8P696eRNcgb7IFrdFa qBlPwpLSH83rj9akx/rioXqsS8QBn8RT+STepLjeXNc7wzWfLFFF5xjbrgWApZkPrsxmXsUL5xj8 D7tQ59zb2X25/hboSTyVT+JNiuvNc72FHBy4VgNdqJrbg4MfvP+Oi7/zPc33yodU0AEDvN5/94u/ r98DxW6r2m1emNSv/Uo2NZbs/AxKLdRVN1CviMnWZbL/4/3KfrYBIz2JoP8k3qS420ruZoDzqTCY l92OuRBd5oBrebdKD754XtKA5CXLOYbaJ6MSMEiZv0YTMIJrMenSS4ykhUTzZt/rxX6/042KHEKj KmYkfjyIgoFY0bEVWbEDhvEmI+Y0gSCzHnyR9Hvgj+wu+IzJydpiQscmfJbjDC9mzDxH3n++972Z TOIALKmj2FWs2bITsVaM59h4kV7HIvIHHVJOE6wWa25AzycBdas9Vp1nnFzMrhbxQrGicyvCaLQi Waffa6kuZulAMX39NpLCugUjLzdsQFBP9xDlHymky4P2ZB+0hdjk/A6OujfaH64op/sNyuknaNJg mSLcf4lyU7KW653wiozoe7AINQHUptkWjfo2QzsNJ01AhEqFOzpqxtef0wRHWQlHqfEQcXYVmiAw ze8qS71nO+x4EBUiZrFUH9HDqFPyOK70OFJSqJ1yssABxQycc5qWlKhWkA/WH0ekZJGSBfKvIxMA t97RLPXD1W/HJ6eHnz7c/Hb44R8XCJJfdpofu9/Lo3hFErynDQe6aqgmQ9Ww9dfIp0Wj3LRpC6tn PI2/6HMAAA2o6GKsQBX2/A9POpj5TJoMClqOGh6qIUPrf1Al2a2U7GDDWXDuWZzmEE/y436aRcVg KBjQwYgEs0c2aEhwCaJoRg925evekJcHBvRCY0B0DmYjWH4jCVyS6QxDlk2qZehGDWn2yxjbbTfq S2E02TcjVSdSgG8PG/L4j6hBbIAf88w10Z69BtpTWzBmRSi79yiZq+5G5lpE9ogmjBIazGsNwERh qzj3WfCJrHSr7gD7TORNzG00rLTWXhULOrYg7RNrdW/MDKkobMpFmwEwxgPWTasrYuoLDvgGUSG3 pprZzIEbGviVD0k2XVLVLoE2r4WxCBFdCiXRdxhehFUbNYkDK/pQYgDR4j8ltDnhhvgbd5SHJf4o 6YRrHydfuxBIJOlOr8y1UBv5a6BwiFlmIK7NNxHgH6ksgJH8vt3srxB1CrCIpVcsyd+5IfEUmnGN 0eBpopvkQ8f5sJbpJoQaJhh6JKJICQ+cxEnVA9QlU7G6hVi1EVARhWPn+ZBOYOcknjJFaNuvCG04 vWy1q41P2vqGRd7UBtTwBRRbCRRDfQLfIuPkEH73fP3fhxPDdc5CeBxSo+UIV6qX5pqtxFLHsXTA +2SmhRikKGRAAkYVGg/ZrrVQiwI2wM4obtZATphU/nFtD7R9OjgkVnRsRY6PWdSPks57siEVLODc /A22vNAvX7FJ6fW6P4rhHBsOlG1/lJcx4Bmo31TRkc5Swn6znT18D1eIoI+jF2a6wsd33VKAdW+I 3FiM8RE6SafPShkJD1iYOOuToF02YDaJetGu+J7sijdYDfVrw4+IxeulcPsnL/XDcNeMJwWqc16y sIas9WdT00cHSJ81kv7bmqqOComZWmcmllu4UuZedueyAvlEdME54NN0KLYULhtGmGzddY5LnBUi MGgDsguC6ayE6dTNJGIYf47K9CQYNfImW0C+XosWp0TKeZFyTTKVLzeQ2sT1xPUeh3vphlH/TmQq D7FEO0MgDvLmS397R0A+N8lrJcs+ifgiWW9e1luINZ6nOEnP6iURST1Njyy8scLuHwbDlu82hK5J NIqZU2Pm9zK4dz20wLwQw4o49vhoxsC/xbpm1OvBdBhmAJGsw1w0M2RyVGP9QGzo2oZESAPr8HOS jhNtoNy7fn/x6cOxhysoeRTDlpAXCqM88DNDMW3QS8WErk1IR31pdI8zNfC7ifHitN+XNf5c1vgP 1jc8xALZSx3Bp8dNCPDr54FI6diC1tRN17awdLzRzOo5z19zsexFY7FsIiO0ATaFFP8rFf9nkHQt c5DmLZ+Tqnzsf5ISDc5CZHHqQz0Ir2VprHmCeZBFXT7Gtv4YI8ZbyXhWNPQl1OTWbwwJ+BLwpzVY TsEN5gK3h3O2NN/FvLe480YpOIwUMm4jNd62PON5aYHa0/U/qhI3Voob6CZZoB30frpHnHRuU+Kr AtLBqU10lLzmFoDlD04479dgSc4wmmBkMZ9jinGVlzU1NQc6UIyVgmY77k9X0jMQpgFZnJpRXuWw /0is59p6QVBmgOUCu6dYuVaiyYJghLOMNC2jRthvJOyVPDaJsJwq5nNsvvm+hj7cZjtPm1FL5hWI pgUXy4i0sGBH7OfYfiFcylQuHjYycOMd5y6ewxcpeE65IjmixxcWqn8l9nNsv/n+x/qUSUob/Khk 4HB0+CJFmOXPpDmSpY214q6vNO46y3YV5FUw/vEaMf6vIa9zn8Am9vpyLvb6Yk8ymeNMRrPCidoF lEiGURxHuQLaGuq9ewzpmU3vFRGW8QGvUDcnjRymiG1Y/dLdNzIBTUFM7wYbNayIXg7yr3lJbRzO MgNOIeWgEW9GCJLifIOF/KkXZdivN9uWRI1hGobv9aHvZGgY5HpztvrwzRuoLAXLXAnLJOcLlT62 xaSmCvaCxeanRzjlK+iGe8+o7/u790oyoeNMaHIe6QQZWW0mFy60HjV6I5KGx9BBFLxakQwn8VOP f5ouaeSdYF9rUy+0C4Icbtlzhb7mnL7WRXXpvdl/OYmOey+9QVpmEEVnZun5xQ2D0bjvC2ueJTBc FFbGlEjqOJJqP2I0zELPGPKB102VzsKEyAxvBFUxn2Pz2aRGrSHyGx0QNaeYm/G0q0iPhma4GyhA hfchvI9p3scJlvrT7LscbIFCHVDHi50Q1NEkKj5Cm0Sc9DJn9UeMTIy2MQ0ueRPBTySyOI4s5Qj6 uF4cDaGkCgstTAecQLaR4u+AQuHboE+udVgDMaJzuAIsAAsYhnRqCN5nubQvhAEoywVrHDxguWAf BT5KxqnNsfVHcqk3pN6YrjcI1Zt99pqDrVeNwdYJEHgFzSHuS/HP1/+cCjC7EjDLlYQdWhGuHiq9 OpCjojBnT+wsC80OiWzSogErEiPyiAndK+ZNbsHWcIUoweUabBpjEVX1SDBazr8Ku2Z97JqFjIcd zzsEFIlZXWPwWoUQxrv4TEsOwDLGvBWq9XfUg5qrLgIvu4aXoURHnHTdUJJYgaE0TOIMcR/4MJal z5ZKwouEl0cIL3g2T6C/AJAEf3jHuAIVJaxgOdHfB941akwdbWRBIw4qTyEBpgUBRpeduI4YDHC2 nmzZKETN8YTqpoKJQHLPqyWkKrihOSSjwUdaPcbhUdqC0S2hURz6OzG853rqJi5BPQmIQt5kC3CY +8t+7rx5vb93umUPcx9rDhTf524bUjE+iH3MK8cHCMU/bPWyzukV3ZeeVribEbcwb3ED0v5f+Yno PPdPaTZIE5Vse6qAshYgierj5MsIW0S599G/815ve3s7u6+qr9n/+PWSRBX2Xj1UJHSJedvmqF/5 Za4uYPiU37u50P5XcOuv+m/t2vzm7j2IpOhAJEUj9G3najwvq9w/o4rrNUVoEYOW6NIiRy7E6pAE Zzm6VbfcLYvZxmykYEIcxk4KCIrI8MYxXQQG9PM8DSJepmWKLjVb6MYSvT2tBUQAroKErXuz6na2 br3FhO5NuCr60Wi9xYDuDbgI/RDWp2Dij4OJ30wDqHVkfHKC1rCUp3IAZXkJI+7DyDwEfGK7KQhc koDtvduwZIxCTJIAxRDGZqWXu8wYDX3cC6czSeAQ1Ioo0OPRs2O7o1JdjnjPJ+jNdF8SgPsEMCcv N8eiUwY1KcEaVEzo3oQNnwKUEijoE4SNZC2ZgmdKkik2MDCzWP8y1G+XGHoQPIyH+JP4vJrGWynW eELRu8fQ81GGJsuQW6HoLUG9pRJ9e7jlKL6gF6JKtI5AVDwu2kXt1gRB7LChUbqMD6IE2wcHUfjD 1pu3RJ3wy2KQ4uj5x6Os/J1eCAF4/7CFif7Lzu5uZ+fNzd6Lgxd7Bzs7/0+/a9sbEs9i78XO0dvX bn4bjfeFhxJvjK1if75H7F3f2aNHFmaY/tlG9JON7E/GDJUGhaEpYGK/r82EFpsNbTSYYa44D+JA 3rzGSG3VeY4Y0X3Nb9u2MAXZiAaqTGuFknSuMtxmAbyKPSro9GPZgV/hqar5RzIikBGBjAgyyNFe Ti3StYDl2b58YXM3hxBDkpcRwXxGUfusJyMCKlcE+HHbmDViyBSibAbEFlH2GnCm1JrtqTUXbk5N GVRGBAfYZD2gAqPZv7rzwYZPyYhg6wi6lUIMbtVTSvjdHF0XoHcquY1IP442/fS9q1z1ypgXxvOo KHnYLBu2rjdsIe0H5T+fxjy4ooSlriQNoX6vFJ0sSI3mQhj1evg2OglpT8hWox8xoWsT0nxnjoWo h8Dh3xxDu1N8h/riD0ex0mrODWs/y7+Xgs1xwTaM+oOC3Y68rhhkaVHgfGdlVgifGBwwJ4Y+9i3g m14+UkHUiwKDH4oVHVvxmd536UVIepBzJMx+/nBLC3Yai37PchPWvGJEx0bUIDykOKHOOcAoLNbG 9JM7C9Oj9+WEGQ8FlBdQfn2gPDQ6XyNbcz0dlnzUsnOpsgDxnnbP5Rad3KJ7zFt0V2r+Q9hU7XzT UO2cyBdLHnOcx4jFEVYSnZo/UMUSg/YVmd+j+pFzHn0LbX/S3q50da67OlMPavgE5+bKAL1bkA5H vjkhzqKrpP4Ou2Vj3Bn0xoY5kNAplxtZ1XKu774kkzOyEpGiGbV7k5Nnz+I0x20eP+6nGeTrhhJG HYdR02PDD3nkBWTTdt2MYMLT3qdjBVhMIyskjIzTCtQ8ZIoOuhDgKUZ0bMReWeBkJxilYIOypGzl XzmuxfdI6xGpD+fjiyjIcUGSzvQYx0zUWMzn2HyVtaTfln57ff32wqUJ1E7NdbqFrRDSQVcVY4WT Sb+rLPWe7Wg0D3MviRqOo8agTEKqlZ/t7uzQKdKf/bhEwdXH8IMON6PnSTx8iY/rRf0kxffqurmy vZjQsQnJPLi3jSUP7lBJYty2rPA8ZGiUWXZYEiKT4/4vV9N6XQ3jzPVbsLHp0EIqKvHm/vR+hrzJ FpCK72/JJfqaIh074QyB3jVnE/Araqfrk47dF+nY1Um9Sx7ttgWprzxIq7930a9cUb9SpGNFOlYY ou3iMTOfEMU6mjE0XbTqCKxUeXHq46ITRlSB8nMNg4+yNFA53SC+AxNqbKVQ8g2APm2ripAbWFDb 5oiWbSQ18JBGR0aji6rZ0txR2JoJMnnhd0Fhw18FkNckXH8rJlbMpkWyl8m5DHxaOtYkQ+KMatvV ab9EKuQja+SCttGuQHPxQ9czYfJDHGn0y7ioMCo247JBI/xxB7jWLwNglDC5uKFjTOsrtpqjs16R 7nWk3RYTOjYhRc6mH1LYxDR/AyGybV3udKlCJcufxhslk8/L5OCDvkHkPiyKLMKNBaUnGN6lH2Ve L/b7XlbGagNMLXnkWoD+tqwFgFbXAz7+p2M//keSluOk9QDz4Z/8QYQmDjZ/iAX/mhbkLEHWFwu6 buAe5oMcRfUf4oPt9UGKlJ53be4pNUz9B332x8dP1zfig23wwUlJfe4PVWWqI9p9x8pmjw8Um3L7 5m6EF7XxvPMLsaBzWj3sNSksbYH51b8lirZK3OYP4GDX5YhkxVXYOQUnDwztHHsrPx5Dd/zL8y/a K/+RpeUIJD760FHU+1kqmSkFxM0dY11IkYU5xAetGNF8YtE0Uta+jp588OLDFTtX/Q/44J744Dsq tts8lhUfrAmC/ZV98Fr9p1RJoDrn5bALlgR9wAdf1HzQLlbvv5Q82DKZPsmD30IexHZIFOJUdee4 zHizU/sg3K2qRa0PvkBylFq0Vd2E+OC34INXfGWqoxEXzoKcB1/VfPAkKYcKDkotofig+KBw5Ffk yC/r6KkfrFZdjf995S/jg/guQbZbgGzDHHXJsMp46Cbe1KKoVDLmukD7MBmpZL6FSsbg2Z2fMQ0E 1Zo/4IP7c3xQOvp2LazAVm3zwSdByHsSb1KIrvOIrgtr0sO8kjA0+ltQVI4wsicBjy4WxzwsjRVp kMber1enR/uvX7z4l9bh+tjpRoWwZRyzZXJV8FEBWjfyvT4unCckYwt9SWyNxeoWglusZA5BZSLQ Bxp4o7VAnCMYiPkcmw9yk9BEC70xlAhZ/Q7nKeuGYlGWKAniEkKjvIgE48oOhGh0PZJGV5UKqg0p OnqRIRvgOcy96/cXnz4cQ0tz7N+RThep2xb8MMsiHG5ku4YrOEV7QaxY0RaHaBKPBTNNtFFfopyT R2XlWugh8SdJD47Tg3+bRjh04Qefx36GTX4SJy6ibhRjjIYUn0NtDetLDTNBgQc5BW545Sd9dV34 GRyS77e/3dn6G59aczDdfXeBjT7WUN72+Dk00q3IeRAiiO8ab0EW3i4zNtQpYm0Oaz1CsMeyJVNy 54YCXfAfXxxRTcmToXr0H/i3pBEne8/tCPfoCJoFYjMinFC1OT8eUMLae7H349GLLX78zFN4XdxB ZWJ8gGOlNAnRwUXxubJAmZDSeFJvBpAA/mFrGEHx8f1hkkdb+NesmzP7FUQkywGb/Jz2f7zxg9K3 8Tf/+WVYAUKe7Prlu9dImCdZhnb5SuWjNAHCQUsJsuQrPdUjpFnWCPG944uzI63lk6l/Y4ABSaYJ 6mbuUnhhibSaVgchbRI+O5JiyXFZzopbtGuGfjeG+SC+RKhNlo6yiLSYFMcXLFvo+BIgviDq3Aw2 cfTlSeQyeZMtSNhracuehCVlBjVvBvXupzQbQLY/2fYUQmaMkFh9nHwZRbSc9tG/815ve3s7u6Ak Tn38ekk3+vZeP1TkdwmR7Uk8lU/iTYrrzXW9M1yqzhJVdI5xj66Yciz+lEvSeV84B/TPOzNwypfr Lz2fxFP5JN6kuN4811vIvAiJYgGMTE/kMa8f+tBGIMpF6KX6fDU6iq5v0H5zT9I0h+v3Q7HeStbL yyBQKsQBFLpulikIyGm7+ZOT8h6GNYMmFis1NFBcOjJ8WR+PAuflF6ELQsqrhEOfyvO40vN4OC0S rYElej4XQ0uALexcXwKKY0wJvAosR0aI/IZUQYeCyXZnhx9Pbk6uOjcXF50fP13/7xS6ZK4r0klM saFjG/qYyEPsaHLrmaSPLJw7RGtrsgbld8kT9Lj++Vme5ImV8sRZD0/e1D2Bz0k6zj0ikPLza07B YaLv5fUHeBzhOBzEsyXMOA4zS6LIdpUvfvt0fvjjh5Pfbi5+O7r4ePlhOm+IFR1b0aR5kCaJkwcw 9ApNxB0VbPrKPAoCziagXZR85wP4KNRYcMAFk8GMCzvJ+K4pN2kQlFlGyjIeGnRbTEvPJ2SCRyAT AK09RdaOElwAwhPInQBlbVtx+lmGfRA0EVgB4ZdJCpACB8+viQSclpLNXYcQWBFdniImNkOBnfdp XvAOD4ymccCpem0Y9QcF1rY0fii8yxZY0LZ8uLsGJJfoIDENXGBQcGMrTi37HX9rkJZxqNvBPO+V sTCgnS9LwA/tfbxGEAUKwyYjjJfLM/oqTnclOR32QievyzVpjNzvu8CEieqz08XYj8CyBLhZs6kP tbZF1dAeXfzGqJq2YleiaQuiKW+R8TokgmmAiZgU1FJQ/yUKas8XXMUxroIkMLeaHqWjUi8vUefj RSBdp+NkUpxFIZbmaK+Oym6xonsrziZuGnIZkHpOTWbbXs7kYkD3BgRgSXdUkcijgnZXCXrAQgPZ 1QwW6oDEBnK8zIZWmg1R5DTT5tnpga2P9Yq/FGcyufy/YO009j5ndDJ553Pm1SBvvtRYAS0W8uXw dB7i4SOehKe++MMRllLRHvA2OaWFPklPcKee66MnWi+Fea15GpfUq0tWcJ8VYLORyqBXpPMBAdMp TInxCQ2m68fStaZRAojFWBQJRCzo3oIBDjEnBU8scVUhRyHNbgeRERiQ1hlp5kArjaYAgGnZC4sB pMSKWKzYCqSsy52OiZs2n+eBSvwsSg2oiZgKKXCg06TtU9mW+ydpdFsAlC0u1+B6teXT9UdN2Who wUYmCjBLnW7wqevqHeuv0N7RyfSzw/NDCCdA3COkYwGorURBQTDa9WG0eMh28ZiRlCWtz8vDJQ/X +h6uhT3muRprYUMrh8VFEjqWfKSCqFfJp6LSjaGdhzoXhZO9R7xPz2scrz/XCoy1EoxVxQyQMOIU ircwUy9Lhww8fndYEr5fGFNue/R5mkW/cw7bBnUjFAM6bjEPA9BjYCLAxc8ODw+/9y79TCtS599x RmDBJvQjffhgdrcB4Fiq26dc3e4hkFMmMA9YJNUHFjZ5KbPhF7LDaVQNm3A2OrIHItw345TUUGvP nUeYWoI9Y6SwMkGnNTeHScJynbBmaghvaQ6TzHUwssCFxJUgimYiyFonZ5MGZQ+scdL5JXCeIs3W xa3K4tQPCcphWXdzVsnTZ5W2bCwSgWbXaK8+AsEUCozMogS74n5MZJion5Dcd26KFloXg32JKQPM 3g8pdUSJpl1IonCcKGzgx8qfteR1A1m4wp1yCKGF3ijFsZY7vrnzam9v/1+w7rUScrJrL6yHUhpP E5dp1hcJFdLsNelQ/0yeb7Qbl1NT0xZ0qGsRMPh23uTOm9f7e6ck9t56NZ/xQYzzGPhJWdS+l3VO r0jJHgbNSPWeDGvU7+270QM28xY3MGD7yk80PijWpJ/55qH6mUvM27Zn+Cu/TGve+/vvU37vS3RT ZTIxbzLxTtQ26erHTFO7BBZb3SOXPJVti0Z4c42scv+ws+RNiuvNc72Fk91J4b6/EAO5UrSP4N3c jdQE+NDX7LAtJM2z4+Z5ts+ymEcBi01BHgsabDGiYyMuBjjWbxrJAy3okR1xFN8yYAZxJtroFJ6i CC0+9kFFuvbjDVUw8JMoH/Jl7nyybExKMHo/yep7A6G3C6y0TbH+aCgF40oFY4jlcLCLlD9kuSxQ AEmPt6fGGMJXgj7GYlyHsEVDWm+F4bsyMHMN1asv5Ht9mrNYXT54GFX4Zl8pxKAlKLDb4vd6dMSL DYfZS8myPhtglYkHruSBHEGNFXnVc5QWxNzkfaS87NKmGe2TD7FkHtE26FCByhlC1gGrhEWBo8nb EkUdl/ug03oD7ALSNKwyHxkNs2k+Rc57gscqgVU7aa9zrbLbCGKaz47T6++NFcWIjo14C0dLsw0E RGnQnmyDthCoqxhJNleTbj6W/gsfQ/Uoob1xpup7fhfqpRxYihRsibSPRC7kfecyiloPufCgSVuU OhdP6mVcIBun2Wf05pzc6+bcxG1UKbhWKriqBI2aGN1ODorZLR2uPddW81LoNvjIBHSq6g64eD6g TE6+CQUHydKOs3QY5UGc5iUY4zUp8knLk4JB7huiMhHMfGhBEwaRev5tGoEkKCMO58ETJbFHtDKI ZY0UxOhIPRjkTRXHEaQYSGQelDNADH7WpxOq3OTkUpjJdsoj7MZWoFeYImxA7hhPZhCXuFnYU0j1 EJygRxMSyreQBPAAlnWKtIO/JDE4TgwU9OsbrxRQ+jwXgbEK9HYQb9imyIJM3tMqmH6MsYmt0pDs xYaObRj4lBooLYAWruU2tPIZodJzIc4uijaF+wGQz+qI+Rybzw//7UNZqdCjBEnYkrDXl7DfvWWl lEsLjqO1xtSq8D6KbArT0GXBcOMLhjdA96vykIqKNEhjlIe3aXxLZeHkWEaOVxmzIxyP+lQ7QZUU 5TpFYVKDmyYYb+eQV+XRKVACW0VoyUe6bIOrNZjR4Lu4PFRUlbAcJH9NrOjYisY2DNBhxDZSMNQ2 HA75IMq30Qfc8ZfyAQkL0AlaGoFrB2Xu6zP1vL+B8kSA2JWA2JujS+rHro9uLr+nriypNWk0SR2q PIfescZhEV3JHYENJYwPDdNM9kRdk0+ox86GKowgpqrggXRil04XTNLkIelVUxCtEqfmhFGfd/Ph WqgLrk14TFYgNzy7xPIA4+QTIKUKrZQQa7DXFIQi+dBxPiTzzMO7qPRE4OxB0q+qcThZ0riLmXwk oDD0P0sode2Hdmalp/4hdBhzUpv1urgLFiLpaW4RCh3PXPChqVYN88Q3CZ3W+WSLyhbuA7nMjP07 JYQiUVU7WB8MtpBQ9Atd0eXrIAgL6HoMLBFSW0S3KDC4okoMra2nmAiMoSsIEIN01OnedfCXJHHH SbzIyrzwhkjLMYMOuplF+1qVzhqCoGJNN8D6UJglO8C0YkPHNtTneZjboDLm8unrueiNuqDx4UDY kIysTa3PieiDPuB3SxU2JX3D2+RYrFu/tv/CKOqPgOuOsghqylxcVZLJ2Ka2FZlmZNJhRYM7MVqY okbbAKQk3GHhDqsftjh9A4/eeof7YNdgpNCUvEFjYMx6fg8YgKyKxM8sYskQjjPEdHcAMX2GyDiX Y6KJgo3iCTioA38E6DMNo94dvXbHXEbe+hEjOjZiVZEZiHob5TaRxIiiggJ7ahFP0oIQIR6hA8R4 mqZd+L9cYVTix97Yv+OGTzNoAR0No/6ACbVqOEI6SDECHcUpqlLgFhJUHAeVKmogs7NIcbVWj3bw MGny2tHUZ5rdjlEnWzVKaFNUrOjYirPhn5B5fQ56shd0BlyeYJm6GfFpOdK7+Ou34pPoI+RNtqBZ ur/s2xK1ybYxKe6ptDmjAvQNCKm+FSHV1WUblzzabQtS93y07+/Woua4iiQoKR6fEY0GxUHnGLP6 AgjPzAcflp55FS+co2ocdlHa7+3svpSy4UH3m9rmkXA1EVJ1XMaTuI6Zp2pArjas6flRzFuAmBZg hEoTAzhgg8Cxfk9sW0U0/ZDOlD4mDWxAQ97+v0boXDjI4cMizEmcUTijrf4hTipi3pbAfHYWR5ff ibXBs1eRaXBOpdGgFfjcNLmIlY+xKS/zsy7WEEvjfT55yqdrAXvleQlMC5Qp9NT4B8wyFS90HEXt 6nQFbVm1G6zHVBi6XcegAbnet67WZTaAnEsczejqZ/0MyLI4ekMoFW0vYYWiiSUD0xqAks+c71iF fdbjIP4bZuaQIwT8bJaexAudeyFswlc1WcYGEGOJbRgf9slHoJiS9g3PDkBbUZhkYfla0ak1s399 /f7i04djMaJjI+KCTxQSLUUXoqhNeYuNaADEM5o/eeTsaQrUWOQNXHO8YSvtfCBrW+fjjQuM+7W+ gQmZMFkElh9CLNHHSNqV+d/ihI6dcKqO2UB5IlhEC0YYLetlD708GkaxD4yBpbAst5vrsRQlVwaR uglfEcGlqq2pDeKMIaHDceggBRs2GErjGsl0OqJ43ikCv/riUxUG5MkyvVGbiQkdm5CaGzD04qG3 ZQz0HFJFW4Z/QQaeQ/6Cs4asZYQsTqWbWNGxFX3WlyLZwTT7jnrbhkExhdmiqtn6pQrRHYGtwWFW o0pUk4kVHVvRLERqPIl2nIzkQ8+Pc9pr6irIdQCd4G6pcldjXbGea+uBnxinPo62bze20fgsBfU7 bDZ2Tbho4I/8wCr1gePIOIXY0LENo4JMA4FFZLdYG0xLO8wgFTaWItbSgAV/BQrbh6GY0LEJe1k6 RIlJa0yU1EoerSCCYro5jkBNNLMU+jpnSoYLo25EspmIsOSHYkPHNmwARNbD0ELAOGM/440EXbey 6wFR0pWMVYE4lb7C+aRz0u3NrI54dRfVyC84B1bQ3BSvGJqJGzp2Q9zgCjEFw0U0nQo5pqKPyMt8 BFq+IIWyAvQIK0DYEpna9SGdLYr/jRskNDyqOlybM2jYkOfgxUgscRxLUHcFVj3A3D6YhgVrdg7S Mg7pyljdxmJDxzbUIgH2SlDVAWECGKJjImEn+FsRDQHbezgCZ5F9VG0QgvgSDcuhmNCxCbVMDmvj kXfhFGMOHgzJm1fmtHQmPu/XUyrs4hxj7RxukYoVHVsRzMFMi6dh4o4TmuZW1yhTt1Fa4rMMw/V+ yvwJDrZSqkmptr5SDbL1e5gg6NOfJN5wbU5/HurMvv74IAwCYRBMK8ZUfICZzEX6n/rqis/TLSpL ApCtSURAU5LyFEWKoETOUSLAshNeh70nwGfUYEL1BTejMU4h3ZgopZklE3dJU4yWzBVg3vVHGqFS r0SlLkh0g+oMfWiYTUelP53wzmGx0zKDpTISNt8G44c0niq/pS2IeJhKc94CN2RVFXQEJLmMrmDE wDoyuwHWzV0QKP41OjsMrK01xRMd9wTwpjj6TDQBZDvw3TFDQZBMkfTsVRe4G2ZgOEjJkdTOnMWC OcR8LzP3Oo160vzx0/WNd35xAxXbhPq4auo126HzHKVxGVZKGuexdMJdLaF4BGFUxNQ8LbNAybVX Uc1eo2o2uvAXiOTnOBJ5xMclfaB453I5Ti7HeeM1PmYLt9G1OHtVPuhOu2KETzXlWMErSA2UdmF5 rVkY/K2oOagB13XHOMJ/8pVauh58iFeTDn8aUVyh7zGccFrOi5ISBkwZT5HK33HlX+EmxG+DpTD8 DrEMS7IBaOaIkgqDXul1Z9qB9fbeeL9enR693tl/81AdLNFDWlEPaWEYNasUDGlpOetJoU+uluEc Z57GJdtzNoICQonFAx17oAVBTCiF1wF4xhHvNPvM2rU4Akhn/7LISrMQR5wUsWV5pgV99xBb6AHP TXUmpBqlCw5DHKdjNG/EaQDk7PnhLTIhjmHwATLShDCEf3E/x+5nw2SlLUw26yu6OwPhaPgYz8oj ICk+/tAHVIFt0r2ZKFAyG3/YbPxJzGTlTbZg8Hx/mc4lEqVtG+zdU6J0Zm3/r6+++2LnoV3HEvO2 zVHvad61PNrf/HuXbnPFblPUdweHSR6t8lsjT7zM3lExPyJ9zxFQ1AdDyW3zSLwpUd913KWcacau D8Y10WC0GK/tIVnyjKCeqofZbiLrOQAF2S52Pt3V3AqtJehB9wzidX2zuUg0C2zFMTMNcg23QPR4 QN+L0xQqOWlPcALHHmiBcoO96fOkYDtpkIDUI8MoJ+VrLPQDPSdhQkLPtRnTRPbCXWsNah6FF6bw LULpaOGBd1eIY2hZFtpcWo+BmIkW5uF1M/FBxz442Quf5DeyEOynT35lik5+wRcDsy4I9m8AI2vg Vezn2H42hmovM8QmnmOArx2gRKnsFkPfryAO8IXByW2NIzZ0bEPaj8CAA+zQkk4nUiXKKn4pqNzD 6HfWSGYmd14Gg1qVs+2N6Ryj2M+x/WauPyR0G5PJGFR9siPmWuFc5VgOxDySXu5FWY6cGfsbmXm0 DV+dbnlngFS3tzzeY7YIo7HKG9Ux92sKq9JHfNCxD2ZqiN6d/Yoacw6XcDLQ7ScrE6hjiIQzaRNl 1PiwUaPElnlLWSAAv0R5dZKEHcAS9Ne1gjgD6Zid4XKMytcfJATXbME4tGWZ7AalBWqKz1RHYl8T z2IHf6EaMc9iT/kFIJYcGiC0uAkecA+q30zNCKNeLwogYLD+J1VCxryQsZCFiACCUtHvxlE+MNfD UDVW6LTVBGG1NnMLB+gY45tEFBb7OS5H/PDfKOsNUZua7sPkzgNkkkzK/yFREMFeG/lgCdO9uAhn cqBcSuo8KTxRTqm4hjen3Q1m5H0eb4g1suqmnyYJg8hW2Zx1L2lLHkpLIrHk2ormdGYwUFiBpyM3 02bVYRPNAmzIptPziBwypsm2RFLHkTSAQjcrGvjwONyjgrLZrerog5oEfuJmHC9RaHUKGjCQvtkI sz+sxYAzLGHUtQPG0L7yggEOiLEuFpO6KZQaQj4dtvVxJwEFKYXVUOFO9TBKIDXYQzsvR1Ldz9gr tzM5r+52JBoSBGpEtSoKULieDqShGsXpHXnmJtaspZtYqZvQVYuREaEQWS3IVLnQcvZZ7qCPEOtN /BIWlTToOA36RhEfjSHILDSRHQ8iTIN0rekTZcKIG+A7QhwmoQmEta5Yz7H1TL+uC0sM7eBRHCjR EzYthwBKivqV5bA7SuyXDUCHEkJXCqEVtFJ1ebqOWb9rCaYrmO60tuLNfEwXSbsXhbrRoTGDoTzS kGuo0CuhFgM64SfSA7nugaqCizFAywBg6G+KeKwDPmlzeLeRGlM5vf4YI8F/peBPxTFDt7AVu5Q2 EppYkMj9UKut82Iy/LTeHVXVmpjQcQW2pFoG1WO24IIke4VLcE/UFTd0HUQZYqhcaqYB8ksw6LLo d60RYA7A2QKaRjAsByGe6NgT2ZuILc5+hzRnu1RjKoqj5l4cq1PNs6oY0bERowIO1RAThiF1bcP2 NXQslJ7T5tVFqRjQsQE1uX/gA+jrKkXKVDR8RujEcTHNmOP+1lxgJGDXXvqD4nDkDwmlFyO6NqKh EEwiJlenwOQXRs4ZdxQOpHAg13eKZCGh6ZAXMfU1Ku6i8JCO6bBv0tec6+OzjyceKXTRfKKfpeWI TqTnRRne4RUJNY5DTa2rxR4txnzU9sJScxiGYivHtvr1rHP8PFJFrxPi+FtH7akO2J8dmPBfXsX+ RM6weRylHABGUOXtF4X14rrVxYyIl4ToBDZUX6F2d+tHMTXA22Yvk9i7RN7FHZ2IhkkzhFFxQ8du CMIucXGbAyOOnVXHa6fuozIb4TQEEUWvlB8qkGFybAPGcr7etSNiLxO9LERhSSJ0MFkSWyQNW+mF IDPiamqGnliGt66NaBOdZWAjWGqKtXf48yXtY/IBTsO/tni+H9uvFqkkRNcmVF9wNZoKTkObt7NN 0Ceq/Ydp8ALR9Ky+AyMZ0XFGrHaQ0NmphKoZBFXiwqCSAY/Qy6L8sx6w8aY7+2gU6P13BFNJh865 oLhnG5MOT4SBaJ9XGyecA91GEIEXpSpTfUtcmOsT/8DrlbRzJg7o2AGrRDinbZ9InXl8uGCmSKWL FOu34JOgO8mbbAGnS5QkjYKmPq63RLy3bfSge4r3zixifwPazLuizUx+u5oS7JJHu22R+J6P9lpi V9vcuh2SQKLNLNrMGUHo52q89TcWnBZtZsd9ipk2ggWdqV5Jd/Cw+AtYnKEAvUVDizNddZfy1Sbl 5QH4miR5IiujLTjhFKZBSbufQi4Rcsn6yCXvdneAMR3REb6oW9LKuMARV3Qn/bRR1TYPmdqzCceq 50PZib9dCsGZbD8+KBZyl2j7qpfS+TmCM0cqHWHVnUe39BiCM5mXXYg1sd6EhzTl59ugUqiwCxUu Tlbrf0zFgitZEDryQZnntBiH2R+VCFDu1CnqYP3GaXjjJXlcTdv0WwHC5Alc6QlMIQyZRYH3MfhY ZtkGFjK/nYduCXrTtofunujNDDBZiwfca+IbTlHWgBL7GJfiGxFv5mdzCprCTd7jKj10KW/yYJD2 VBI9lPu75DFqm6/c8zG6Pwi45L1/Ky7k8jFdWCni8f0UI8wPvF8i9eDF7SXWkyfX9DMtKKvu6bWt CrDLntx/QjKi808/+A+kqr0bXM8C36qRKtYSf+QJbusTrPLOyfVvEFkMk3geEP7XeJAbT6yzH3nR 7xIwwzskiY9+FvneUVb+7v3oZ0Uag+Lf+MGfgKst+hXRW1/buLfd1c7XfgVtfHyXZRA81sgZ3jGw sod2uH/Z2udrtlyLR8vjfM8rws3abJFtloG+iNLnUebfetd+nD70III8zTtLfgXyND/m03xd5tDo uAb2PSiBqzw5WGVREFi93jDonUzWDGkGv4ggb952r/FoqOTd3eXNxh42PXBrW8a2wgpYJytg9zk9 Xuc4tgF+EARtrpQ8aCMbnYQfEERRMzjhV7My5XFZqfjr1enR3u7u23953o+EntAZyevn297WT+qO JE1wbZ4UM0ooLKA7wjdjeTGFdGRIu20P7fslCc0YdXkSWti4epOPq9pBkQ+4BxrnW9vej0eX3u7L bTKcR2beJvgGEP/u27evheAmqWx9qWzhI0oR5tXe3j4izDkwFoWF9Zvnng/u6/vn3mF8i1txONKB Zdqtf5QgIMU4n6Jjzi9aYgnf+kB4UcLMBsLM2eH5IfEYJ5zm3MOtUL5OazKEiTt7+zrukPFFhKBB pHJAnJgkCqSAO28P4IYkAEkAj5UA3u68QgL4iDVsEEyPUWBqvH3b+yf++8cy6/oJ+Kb0CWWGX557 P+EnGyApmFNbkgLqREy38eMGymzeJYbsaZDG3s9QfCJy6suDyWtkw8O4D3WTYjDcAGTSNvQVOByb xOJxM8Mvt6S5Wuy/HqkgwqFk3kb6/+xd/VMb15L9V27xyya1yE8G29jUMxUCxiGJYwp4b6vWldoa zVxJE0Yz2vlAsH/9nr4f8yEhGZGR7ti0q2ILIWLJfbtv9+nTp3FRU2HwGs4J3yuwt26vjzmF9n2t a8SJeXuR3Y7+id8Yedgak5PqgjcH+/u4Fs68v7A4KtkV/0b8P05vbvCQroLfk2I0juV9dTF8fCH+ O0l5tWmTl+/2OtgplVl+9gAT2YvBBBcy8a747OfJAJA74ssexxdOO9tLO6k/swcI/TwGTskgOt3d fJXhKt/mUMKXkzvcYurX/seLi12BuuXD9dW5uL4SL/feiT3892+c01cv+oiKx8WIlgUjFO5zKHxa KHwW+SR/SMWlRDy7yu8xtTo7vPWi9zsXEbZxX2NlOvF8Td3VvrvbSq6VcMqW/KYs+c3SvoZp7+yy 8/T3o9+SdJzE1AiS2PAZIXkrf324m4Yp+j8EUR/s0h35uvyeffDlAsLUYn+P1cXWD1IrjnbXglST Brv0aLcSoBlPfGggnNXF1qbarO+RK5rUXfNIfLgGys2uR7M+7eeeK/lay/fjtA/bc1h8KCwuZbrY BAV/VgoAu6C57Ioq5SFcW0HY4iMeUaPstxfiAn1R755JEh0iSVSoNvZsCEWoI55LQcLxh+LKxw6A NEyg/A8L1qh3IN2xH3anVR2k3jDvPbhPrNfvix9oaR8RW7EJYIS6I/uRrdchH7yS01xOTN+IwdLw aWAp3+Jr3eJfLk5ODJr/AJi/D0xiX4H5aGQSmn8qfT6iTJ3Ybr8J1IlX/T5Rqn/xbrzI00nmJw+y J/TF7yrjzLCOlkC2X3sX+PoKS2zwrU8m6fx1A60nDjRrBZpauVARXaq08ySVQZj3lGQsaHbH02nU pG3RCeB0pUPpStnY7b/egHcxGtSBJhLAHksR1Jto3BI71WzNwR5N7zURhl/RXwHRmqL9p0SP19Cl QMUqhm+us6TgyNGhyLFzEgFNsLRc7J9TC5TFZVKovZFYDVBy7AhrwMhUBvGlTPKO3Q4Z0RjtX5lM Y4/WXsPZsCAS6JAXTSzVGs7aqBn67/iq4LK2PTrkUnCaroqD/pu3uCqMjvOu+KDnMH9+IU68yXQg owjEtTLSfL6VaZR4gd5akESMa3YH12wizmqKg4y7CyWJW4YjGI7YLhxx9ZKmOOjXA4gZ6K8Hewox e7cAmPEsAGO6LarGHwEkwXbg8E4c00RAlpEacCSHudIw0XucRVafgNvAbCLX6Vyny/c7U7QTZXor d44QFmkLz4CGo7IkQkmHSoFEdag4WNhUHSQ4s3GSY0kP8i/QIznvcl3jTROs3xmAgU4qSD7MmCG6 HIu4UK1JFOelVT0KLrQKA2Jxas889iolMWz4VEnZFewwRtvXQttXXgOqVgcHQE+0EymAq3Kuytur yo+OlczfcYCOjgoIAppHQ+B9whtARo3WTSLSb04vgXMSzkkWcxJskmskwyKQmY/1lEhAkji6FxMs 1dBSXJ7IwgltDoxwFapMhpFn11lJGS+QjJwV6O4DcS5DCNKUGCuGhRcE2PFYZLT8kdJNWDgcxdw3 cK6fUKaMGGSUEFNDSTCR/tiLw2wCg1LBEMtZ3aIxtnKS9uaAVTddu14qR2GWI8cPxAwKR4I08WC0 Kynxn5LCy8SbFy9VVvm2LPVSLdAZqJczmO4YTIf9phln+Zzlt5rlkxLJ8YjSeds9a9/ROZnnZP4R yfwQS6IBVRGXpGzpAhyfJiFO5w8Km0wFUEg/CnFef2z/nDJAtRZAZZFgiiAik1MvBTIgqvRwhhkx SunLNAK5IPhBpJdMqT3bz3FCgdw9gDFGAoAwlVoEFNNjiBXA4Urrtm+n7+c+WKFO0LVg0lQn+Np+ ngXaqPmkGxCwedwbo8U2x42jWHuLtHajf3rw84fTHadv8MU+YuEfqII/pCkuKtxiozjJcqCmGMls vPnHT6KvOGJd86PHWbJVxYGuedm84kDtkGr6dQf8aCnjrnFCF975VojjR4Qjoa+FDqYXiZmXiYkX IF1ICBgUnoKYHnIuekVWYOJEtSYaH+Txrsa9y7bWL1A6IVUMBKlgmsQNg8wOQ6D0+D14v/Pu5Q4e eUU+TtL3O59oSS89ESCTfL8DMaVXvZcve/2313v7h/vvDvv9/9YBfgNR3nouXTQLJBu8YforsezD vu+9J71v/DS0x4PLxiiGefJUQiuu3z/TIW2jnxCfg/Tojnyyi/2CHkMdRD+j/voH3+1G31h+hPpP QcboM6J7g4eh2dyEFNWrslIVGriIoAOzlbi89M5IpZfV2EGp/MusVjFFxQQaBSgoGLd8Gm7ZtRTP Rkn8qTAt+pMiwt/SoecP2QF8kC3ZuJtXlF1dqzmaZddS3cGFhH5bpcjCO6IUq5r+/DuSmvssqbl+ JF5xtLsWiR95tFuJXV1za3yohnjhgv9uJfFjSU2W1ExDs3u8tmh8/bDD6Mqa6Eo1HIR5V8g2TaPk XhFvm8ssG9hKK5Gwa7fAfCRs5UNyuF+r2fsHinwCWJNUCTyoHuECTMal4DJw7/JUDr0iymsIn0HX LuYwnA6Ugm4yjaUQE8bRTguFBRKsPIPQvoICgTxFk14KRgFYjcQxUCIjHljFqrGNJyGTaYkk7QdJ jh9rxQ8YMZY5DSpB5UdxUMmYhtSTycighnbK0NhTBJAFEoN7EFPZgo6RXlhQRf1dEeYCkxip9JMJ 8hHi6yuHDMoMJRMQGyb8HoOE+oeA6gO+Zxu6t2GARimN+ab4w3qdaZ7iboeZpDj9fH5SjYhOoRqN 0d9E2xR8IbaieysumgmXnXoyhJITmP422nLj5WmNF77e17rer8HYiJLRvRiHAVEKQdmVqacnS9qP F1ygcpUwTyjXohXI/uUdRp2IQ3QXEpmAWANqFFRBJzP1JSUvQ/BTKHMBsygT9vi2f1Q5jqwVR2DF X1QEAeJ1PUaWSWOhYexHBVhgSslCzMakVUF3nSYqT5IAQpTK1Mwpd00Hgf0+p+EojHu/gPhKFTgm siEugllRxQMhIZJrmG4gx94t5ZWGJtJIOdkL3SeYcD3S9JlBYlEUqPHSLE8STI+OJeWZ+O7YI+kq sucxpvILf7yr80/UDmw/9/Yrx7VLeSYQaGlhjLZeZtYBcXnA5UGb86RWzu4EceFSj49T3pWRJKta dx/7UhxDYOo+C7l9wGevvbO3tH2g0sjM4Mt+EufYxk1RkAYTM7Rk1Mgb5Sn6UD6YkWzgqHJhsFZh AMOV8QM1mzbf/xbYvazjSyCHmCtVPZ9SOJovNw4w2wgwJHED9UvSm0Ivkk8dn7r2Tl1FAjpFStVk /iihntqapUycA3YdYQzfqmdRWc3VmPtqDLAI/boyYrrtm4QRcUbE5xHxRuJrhDcAqCYQbwOegyCB R2bYLvdugOugaQM03PeTAvoPhPS0f045610r66U22nw8rzrzyl6W4SSAx9l9eywTxlsK2txScKrF gKsDJrD+CxLjdv9X+3GC7zO+zxbvM4mMN4qSmWIYYJM9pMDqx5CgmwfDIcAdlv913Rq0lM78fqr2 Eaj0JAgziL4pNVn0lEi/GRS0BLRPv1D9+iE4JEmq2/jtRxnORtbKRqYRuNcq6QikH5LRjDwLCLoE yJW+h/wSeyTye0JYof6hd1EAvmMLOi5FK8k3uyovlTTSwQkjJ4wtJoxLezFGbFq8hdY0LmtC6t8c 7GMXm4bvEednoCfnpCM58fwxEH0d+hWDC0FmlnAIcRxC1PWtemZVOYCRDgi30oXQi4hiQItk7RO0 RQrKXbUXbwAg54t8rYucGFig9U+89F6APAcqpKS+/AADOlLxe7AJTDxoaBr8wFXPXujYC6NwKPMQ O5sRRa+M650HfI3zNb6Na/wMxM3l8V0TAatTSTEDwt6Ka52HHDtcF+ITkF5C2o1UDs1q4B8rk+IR njaW3cA1zageo3oPoXonmMQI8x6623maYGK0ShZNYVDyel71+2/+pICCsQB5hx3wOK/JkNMRx+mI V2E/S+8FjidP48U8i6D5/XzIFepqXatSH6mutiAH8h0IB75i4cD1FbxWHO2u+e8jjzYrSV1A8hsO fobUizTZWyQuntMIODRfeqfYHJxrAlzzdzX013xKf/UHls+oVeWkAN9+cte1w7oRfbNn8SG7dqPO W3Lh6tyKZufS9ss5NNwaOH1VaAHCpxZuHVekr5sojte+L7IF10LuDURTdtqxlT3OtM4GdJleyBfK isbIVCeT9EHoh3l0z7ZzXCTjOpyEMXqbaIcN8QX4SyvMqZpoeuFN5YRsQ8c2hEdhOx6xp2FFMFqE RJu6Aj8MospQx9OgDr4M1roMqA1Dl/S0SLEvC1QJJaaBI1qx6uYb87ULX0Aqk+OJ43gyLFJYMIXF bkGaI5ibhltBgnmw+37Yvr24TOCWzHxL5ooIWJrIU4sXfPj4UmsPHlpaowIBIuEQJeZMOsEkIaUp gfMnEhJEtxIqRehjR3qabRxOwR5vP0hyXrJWXgITqrQ4oavNCH7tf7y4KJu5Vy/3G03e+X6uYKDB NUkENlQ83AWn+wLj/QkJb6XCl8QRtLmr+ocUoYn8uQltH3bCdZ3QaqJYXifNS4W0251MhKCqZaDp CwRRzbqGJ06gj0MaOZJHpjrghNZ2VBPQ6Lb0izzEtVcD/pj1yazPFht3SzOzi0wWQdKz4HKNpZVx bcC1wXZqg+NaRQrwC+LOQaKUSlEE3AssKZrrWh3/+4JwWq4JHANdyCf9BIrbulKbmx8q1YF1KWeo 4kA2MywzsC1LNqF7Ew6KnKj8QlV21jA9ZVUFXsLTJqoUJ+Vn8sSyUWm55mxF91akvhWAlcw2Dh4q 0U/uGhX6l5M7Q7tmA7o3YMV8Rxk3XZqWcRuSs7ItZGXXiPOVsMBQgLyXRolHS/mUtoCYFFgFQBJj 6kqgztbc/c8xxXFMUW3HhjLcLq1FMX1kdbULZN5Y9hbeidMXexxZOLK0F1mO6ERhj0RV2olrChKf bSA5VyQ23eNpP1ZwC5xb4PMt8IZ2pg2DC+KZlEhPwjwc4Whi6Zm9+No/otz7WKv3oRMPXFu0Obaq QbUolap2GiQpAEQQISP+lC5aKUNhGzpOScBlqyHM+nqw+cd+mZk86JI2GWUbOrbhrYfdsQVt21OE DkNqMzukUA146UjmgJHUOlq45E2czOCCSk9frQ5jCzq2oL3SEEtVg5gTf07820v8l7YaASkAZa5o zNB7yDIoggJAQMeHgOUMDXBoY98rEn4tB8P3OGg4Dhpl+mWjBw0iIapD5aOAzBiZj75Dy+FnSXqj sKKMeCnEfWb77bimnVizIejXUmZacQOVuKlemIVa/b5e84CQIr1cafYyA9O5BW23zaRYMCSVqtDM qZm2bM1pG6thwZhYfcoROYg6DqKqQVfdgKZHN5H5GGtYrZyaiaiJknAMhIqkiLXY3Mr2c2y/bAqN bOylDoRiylLnHItVIhrx0dusU6xkoQha+SqWr8ByeHkJWbAVHVvRxMZ6YeoNoDmGTEWhDCqbmewK RNfQGphU7GHVv2jlZDxiEzo2oS9TojOXfoZIekaXYelkeo/8bmWy8qViFkYRG9CxAYusQKlwr7ZD 2OlrCpyAB9MEMsaoAytbyjSFcc3eAbVnQhmbjejYiGW2qUcQlnobZoSozSwK7I1QlWIdBGYrOrYi +ZIhH0FupHHhjTDBTE5Ja+SC0NcsQF3QmyqSrefYeibTJDMRBlO6JAHwoQJmDLgG1S4CZqgkHBQZ emhwSDJlyiIyrrEZb0S5DFjUmKxs36GeBRWCP2QH+B6svLg55cXfknScxDLeFeiuehEKnvLXh7tp iORYfMImr4NdAX3F1+X37IMvF95Iiv3XT5VINRp3UJNMsWn28lQOPSjOvwcoesaux66X7/xDSY5u 5vxTXDH/Z3sAL1I6e1tRXjxi0dNjrPt7v3OSFGkIIPMPOduBHfys+RROwLxUZisXwrOIL0wG1Oeq dohmh/lSLgGrGZmQ2IqH8eFb6/Ahp/oZO9bkMIzBE9aQViqpsJ7XLbJCD4SeQAsOkGcJQ7df57EV 17Ui0REfVsQhair4SYQ5I81Vyjj0Wst5hKmJ28I23E4GtvQagCeqxgB2GKMnCzRrNRuiJyTEx5RI r8XJ2ITuTXilucLN/t0xJHlz0VOgJnwtIIDT2poemyau78VsQvcm9McJxGqVBxKJTFnN0pIaLDJ4 KG0QN9RxxRXXRCa2onsrUgPBWg1W0S7GiDSzw7fADr9YqnjAQlQshbYNKTQkk9QKXy69odep6EqP WuI0wIwwmaSBTFV6wjsrtwTJrioILPVyvoQLQN2kbfYo6wZgaULsNMSWB/tqpC4zLw3wTc4nO2DE hSyEUktNvzSM21J6xMrT+kmgJEiQxHAu6T6XtDn+ogoJHFNN4uudK5YEiGEijIGx5dxbrq5Cq0kp Vvgto7oN40JqJ0m1pApg2Fix4AdSgDEmOYJ2IIJOEiQqQ+82STW3vZrkAse90maUXookBkR3Tcy0 Ft5A0cfw9LrwtIqSRNeTvkcCjcqkisM3ho6TF8GkwT2+K2PopcaShDHqFECOpe5jqSVdDlFYYMiL ILJ63FSTz4nvF+nDgZbdsAOR9NJO/ZB3TUz6qRtDFDYx+gVHpKV/yvvUuJ6huRvrsyO6d0QETIqN De9bcvdB/Wk0Jo5dBhFqqftKA64pOuCJ0CDAPLoMNhAWmWTUARJjxzYr2xWtAy9DFKjNLDEizYj0 lhDpz1Yu0+qfKdEHs66jt3gya7q8hLxw6uE+9WhI8KosRNVwKlGEAlLi07BrgLHkfAxWUa70A4op gGje1dSBnMNuzqL8ntZrZdRD0L2FrPDHu8qghoxieSq2qcDe5977qr5Ondpg6V+WRkT1eWldHVbZ eO6NV8u5TFWW0xx51QuK5cz6ZNXKg3wAwS18+XUgfJaSKcBJUHyXi8ZsiEQkPQezNggUk7rcbA6/ JMYf+6B7H7SWMg5oezwIl1EyQ+cAeh0DbxBGYY5VXUPA0XRTarNT1ZSxDbtgQyNcVAZLw6gtjatl rCpU0yQ6ih1fsA07EEm1YxFzBV6W3cc+XC2fUfOn3vQx22CJxwJ1X0Ws3sQqUW7mrdvMO64twghk Fo5imWrOA/RSSUKO+ElgsFS5zSQM7HXJMbQLMbRcYA+NW9sYsMU97c6GH1KXT5rbjybDwvjWi8IA BT7H0A7EUDKOvdkoQOphBBrxoqTFfsePIPbXAwSD1MaHvDFuRe44MAm+PRI8diPto/C5NGMw1xUl QJxEgAQhMaq1ttqP+9zn4j7X/F6k81jr89HAnTmTvPub41178W4VXf9YaQsqfUg6f6Yg1cP0pEWo 10trFgZd11pL2dat7QdIrmzWrWyQSKnFklU7JAqHMg+x2QOVai3l6oUQytbLnQAFhrE1KhvRfXVT U6iocaQ47eVrYAvXwJXuqvbOSU9Fr13kPGRqpc4WRfYuG+pn9nWsyVcPox1I81vRZuKCrQOWdENM PGpH8/MNa34+7RZn13u+rsean6z5abVOa5qUdKWTEm0rVztDDetCDce2R9NT0ou6VKhBRgQ26O9E dsQVAASPlW9LKnkV0Cexa3gQhRm2wII7VBIwTdNNiQJIcXxyWRpOCWwCIwpjBojqlU26GZHtVXK7 kMb5cnl28uZgf/9PgvAwQW42xhDEVxFnF72SEaSn5Z58N6x1N5xUfQIGk0x+wnnKP1G3OwmW12o9 qAcFDh+zgxmRg6C5QTSTKfZMmivP5jC44mw7S09v8bBxF/KVWuuRqEITL8YGlcCKbGQe2lu1JCbF nB5x2XPTuUSqw3u1OsL4Ih9EFqlakfsfLy7ExcmJ8FJ/HOZY5wp6l/iCZ/5UKt/4wvopZ53us04M ACGKxjkkhdGhLFkCpePVB4RMWEV2CiN6MCwtGGUjujfifCQtshzcdbNreXVEbd98DOo+W1B3KToB sBejaaZwYArc4d9qPXPlulblCmhFUeBwAm1hYMsBhbSUXyitMMjAaSEjlX+aE9trP0qyEdc14jnG kklZkSBoEuODpQi6BDg2TeVtmBSZtSTKhHmLswHdZym2jVDJ0tKMD7wtoWQlkBGUTVPYFF9rTiOV fGTz3GYybEX3VtSmUSIdgnT51GCPNa1WYSwBGNNzuLouew5sQfcWrNo+K3sORBunrM1UfTa48qQW S3NtQ5rrQq8rmasZWBiOT982Th+KBnMA58OfAr/qUFnZWiAQO4CiaZJTbso3nfubTuUq1EewdRxq iAH0HVTfqGpoQtZbDz0ZW/dSGZFiHJvQvQnDGDnlBFkmZv0hBZDrqSbTazCup9NMYNLyLszyrOwa sf3c26/WPzBiHDr91AyXKdpDqPhqC54aAtIb4LYw7rIu7qKWJJi1FSTiAD5S/fqrDbMRAENSD5mB ZVQGx07o3gnNvWbK8ePzy13x6fgSLhiIK/xZZjD1Fq6tEk/u2ILuLfjl5O7PukC2SmEMQzAjl5w2 tztak24ggnJ/79n29yCr8gpB5NLKqtxPpSj1s89pW6NWVdmAFBOfumd76pZ2la+VEpjedO2TrA9a d1B4i3PI++jeEDThSIfxTkAPCE2EW7CUaqcUbSS+2xzfbV9ZGlrtvcvHaZLnEew6DNMs17kMm8+x +YZJBJFaKgsweKKEM03mUdtJn8oRFr/Sa4wN6SFmHCD+dgt3ZZjFNYsTq5tGBSwRQTEmU+svalU7 GrNWS1ORrCmAygkFWWVQxjldW6+katqVvgonSxMa0PNBmAizCdnQT8OBvhTzMZwvSPyCrMhxtKn1 ceRmpAGlnE+cTeQoJK2/LGR6YMnnOVgRqPiixPciMU2QdN/v8kXo+CIs4ggaOyIDoqnEJWnrsoVQ LCuiFlW5LuepvS3oPp3XKP0WEmLlST56Wzh66KA/dPowrxeLigEI4p9aaC4AKeE2y8sl2pRr8qXm +FKDDSfezVzlVlbsu8Jceqp5PgvVDFhAECDyzAEPBrkuDGC9Wsahujxhqko3dAywD7uWP3I6wnfC Fu4ES8NZVLFgXt8TeX3Poi/CH7IDzR9W5NqY0kVLOpQHrEP5tGv8WcQXZr49xHw7Yh1K1qFkHcrU apw3hM8dNUNQuK6oFND7wI5ilLNTsE3RwRKTBNRvtfGd5oMZNHIPGtX5wUAalswRCvEJlqOuZbmV mAftOwAaPVCdK7ppfj8FuEeNLc36UCjf3OQMe5977zPTSwrwgyZshhb/VRj72HwKvtwEAzQiGaht xaDDoY9Mz1rqAJvPvfloyonYGyBpqFW1QWFMlyc5WiRxMRloAoBt6EHVBLegVk1gA7o3oHUmxEei SeX3u3XiW9k+Meveh94trkiEVUWjY/u5t9/D6YqKkXA1pXxhlUWpNWbdEGH2XKnTsA3d29AbICgi bjZ5UiHojeRstU3hlrCjzFi2x/KEjejeiJSZqNvQSxFDwSYIwRcmmsAKL1T8AssqYCO6N+JDxI5V rAJuRT8Nw2Z49yF4d+nsUE3PfkU0Ya4cH8Yt8CIAeB6XU5VK8K4xSB/LmRgAU0O2aSW06Wo0T1Gh SFqIfNm5v+yI6Z0mhZqNQeqZFUhDMZ+I8nxFkCkFD6FUw0Z0b8RMkvDkLiqCqe4wZLUWQ5R4Roe0 uScd1d8x6P+FP+ZZjA5g2IiPoKPa0txALSgLqilS1TUaqlco9XulLatsyj7o3geN5QR6DpIVJ5/I DeSSYK2S4OJhCRWuAbgG2E4NcK0lDghUrroElFJOHz6ZCuvKvRvavcOIZTdWWsUZBulTrVeIGSYw U6hwM7hlmY8MQ6yxgs3K5iv6P5x2uE87jMyd6huUxpqFmJjXewe0I9piDjn/pZZCMtKG0BVlK7q3 ovTSiCh9xmilUSfhaExD9vNVgDcaodDLsH4A3BbmkKXvuxBKS/dTeFji+wVG1jBauGBWbhhwfraF /Oz8wWUIXBzw4dvC4UOD4LrceJvPkDcSLkLshgZZpdyAlBF6qYTxdGbCWYn7rARX1ySMcYNV69yV Ai+1cjCWDV4mCocFk5Z23MA1x/jQWvgQnJA0TtUEfZJiCyrkk5MpFXv01cS7F/44SQA7q7pOqxXa UoGJ7V1oChgPrLP2hJJtalQARJBOyRdhx1Hq+XJY8J7bTtQEVQg17VTcc4o5K/xIenGvmFpCe8WB z5Ii9XFX/iBfjDiGdsALjelEluMu/FFFUVCgQ+qqSkEbAbUCZRCEtPQDbL9GisOZjPtMxqaWwL/O iL1O8dTyG6yL0r4W+zp1N2KzoxlkYBO6N6F1wokXeyOV0ZAyNmlQwm7kiAtDDDA2ShDSNPSw4oNt 6N6GGHYNINmrNrJoMkojUtbcr8Q9UTiSwhpZeMImdG9CRY4G6KyUlVdIrWnnQzNJQ9helNHOXLag ewvWZ0kiiQ4CTSxUPcCMTAtvS0WWYA+duRENfMPtok5UFWoCD2knXXl6nJkZR8w4anHL6NFxkY+B Ef2HOA4C6jRKXpDztLbBsxBq4g/5vajdsSXZkvnOPzYoo0SijCRL2Io44/dzXPtvD97sne1YUatT DVpQtnnWtabX7DDyUMPPDm+96P3OMO2dXdKJgUFTa1ijO2k/jZboMh9xA2frK+9odpi3pFf59ql6 lSvM27Uz/JV/zPX99zl/9tPT/tm742/Crb/qv+azbMB/7V9NjgrWkkxjmfdOU2+Yo4O98Ov08/nJ wpP0xB+oh5XU0F7/5av2oaauOar9V1vfI1ecymfxIbt2o85bEjdp8+rciustVR74NSniUPyWpOMk ho7lDxKNziT9sX0PY7usRe/5OcVor588tS+y4l7umiEemZN0zG8aDrLw3pymwxdJenPjIY+/8fJC 7D31tnwGR8ilmZZG5F9klIXxTQg6w/kfvX7/5dt+47BRSkB52tReI6qQbNztZokkWzB8v3MCxpVV 1Ma/2Pix+uJfCUtIZ5da8CyM4X1PlUBZYbWGkS/m2lUOwK2v/Butn7yu+Ozfy7XVyZjzAYTv6FD8 RcngizjJpt7kpxE992IjKchzPsff/WdfUYB2zYe/Wpt10lkb2cBC6rmVcvLoKge7RJwmcXKLDZpc NYKh0IVdFZ8xIBAxE8s1r/zg1Zu++C8vTYGoXHjpzczj/aOubXKWhpmf7IprLLfPhDh43d9/amX8 Pd1wW7kullZK/4pDWs97RcMXzEJ6Ggvpm0uq3B45U+pkaaCTl5+KzDzK/kaxsyIkdC3hn096H48n PfcPyZ62XgsD2c+JN5kOJMtJOdew4cqgEwUaVwagB7rBLJYmoVwZPEjpc5umcWXwyCbfiqSM85W1 8hVTGQxk/BNaIHlaTLggSDE8eLm0wbzi7H0/Vc8z6Em6DfWr+xkuWzBHv0M4AkO02Ay8kX5+1wL0 I/v5C/mbSxstTetQ8cQjKX7H8r3GCXs83vEMPL+Tltt/+49XfZEW0PcoxEcZQ9QsEr9LdLZSn01p Zqy+DSc8z7L73u8y631KCqiDSK+4EycykHfinRDv9g7ePbUHw77piNuGqOo/tcO8wmhdyxcfeRXy ZaIqBPdDgEvTgAsabDgU/7m///LV6713b/ZeH/Ad8k3dIaYuj1Qu/gKbspCL/0S/j+TfKNA5Fj04 ufic4zB/djNS8Myo5Wx3tnvAZ16Ps6vRIt0Qml7l95HE2VBiEBcRROHBntuMhMg28232d/Z39vca 6P+dj46xv7O/s79/u/4+12bWYNOrs/6H4/6DNexiW83obHU7t+kUot+SqNa7pqjW7HCQJDcTjMSA 8p/mCEth8H7n3T6ZMfYm8v3O/3xMfvb8Gy1TZ1/8AbttypdqOTLFjsmkn1+Uciq1eWgT7wzlr3lU rvBD9NJa62s6uvo//Mjs/c7Lvb1X6lCN8fj1WzxWennT0SeP/p48meL5l/uv1LkjIXN6WV+9/0GS 58mk+nYkh7XvjqWHJS7vdw767+hnh0kCKaTyy1GRqy/NX+cnEaSaDzGG6+Of5KD/Vr+LIPE/plhN gVwZrZSLMPfxLvffqB8CEK3/NZRY2yAJ7tUD/EgxkXF+9P8CAAAA//8DAFBLAwQUAAYACAAAACEA B2eV32kHAACiIgAAEQAAAHdvcmQvY29tbWVudHMueG1s1FndbuO4Fb4v0HcgfNUCcWzLdn6MiQeO 7RQGmp3dJIsCvaMl2mYjkSpJ2eO9mgfZ3u6DzZP0O5TkJI7W1c6uZ1IggCNRPDo8f985n969/5jE bC2MlVpdNTqn7QYTKtSRVMurxo8PN82LBrOOq4jHWomrxlbYxvvhn//0bjMIdZII5SyDCGUHmzS8 aqycSwetlg1XIuH2NJGh0VYv3CkebunFQoaitdEmagXtTtv/lxodCmvxvjFXa24bhbjktTSdCoV3 LbRJuLOn2ixbCTePWdqE9JQ7OZexdFvIbp+VYvRVIzNqUCjU3ClEWwa5QsVPucO8OkXFe/OdEx1m ZAL/xpYRMXTQyq5k+nSML5WGI65KldaHDrFO4vK5TdrpvXrf7sh1fDAxfANXPAl8Ja7CGFG+KYlz O5B/n7y6L7HTPnSYwiMkYqdDHRVevrPUJOFS7cR8mWmeGxcZ8Xvi+29GZ+lOnVT+Pmkz9biTRYn5 GzRrn/nMe340+5sEvErd+xVPRYMl4WC2VNrweQyNNp0eo4hsDJ+KBdsMZHTVQJXZDHjmVhrZdjs2 2U90I+IO21AZes1Op9m+eAg6g3Z/0G7/k1alkk7yGJrmG0hqivsoXdEdRLbbF+dnwQ096m9NxIJn sXu24nd8b/zPvdvGAo+ueXzVGOeV7EF8dI3W8F0LgvPH/LOm+L9qy51YCIOCKYp9xbNcKe18McAD ucRcFL3bDT9/+jnUyhkds7lwGyEUm0ieCCcMUzoS9vOnXz5/+g8p4rw62ExKfbUju+HDSlqGP5yD cbbUOmIbvmVOM/ExNSjYTLoTZuRy5d5/Sz1v+XYuBt9SAziTRxGZRNgnN2pgaqx5xEpH43ctthyh wqTKIQxYUfr/Vx0OtwOpCGTI+cW/lA3Iok79LLqonUXTSXDZ9ZL3s6hY8UH4FrJoxjY6iyMGrEm1 rRMExzqbz+g7EWUh4T/8y9xKMGc4NTzMwnmUOHTPiFQbB4T1ec7mWySXERz7ilvVaX8oCrq1o6DT rh0F3VGnP51U1dJi5c1EAdLvQTMerqRYP9mcz4EllDXV9txDjmOd1g1niqGVQVmH/zMr2L8y61gk FlKJiI2uRw/T2+l3DxXl65DHO0F9l9eHz2MZ4Y+Hz5ljCbBoTpUUkAk4crAmt4AmZBJDRGBiMeT6 E7qgCixVJnDNMMjQLaEiXJ1W2P2rRcadSFeGIyTE6fK0BoAdyz2+ds2eIZIvV0VhelGs+FxnDrBv 2Q7crHSZb3Oq0+xgEGNEq9kDBt3adavd6Ux6XvI+ehUrb6Zu/ZAJS2gxYJFmG0F9AhpZVAquGF8S ZJTdVxzrDeIbFWRy9+F7Dxj/ps1VfddBi2OUr2vx+mXjrHfev+lVIUWx8mYsPkrmcpnpzNbI+2Od Cojg0BCIxKId4I7dj26nRVNQ1jSff3+J5SN1C000Ecom0qHC/ZVCIMFII1OMLi+6hsojHYyFy/qx cFY7+y763X4wrYqFYuXNxMLDNpUhj+NtVRLtYcCxTuWGE00jw4fZGC2BDY0Eon34+x1D9gvjyyrz E8KKxwumFygUG2UdHJ/kU2KV7oecHtQfu4P6A0Nw3RtNx1VOL1bejNPvMWKjzvppqgL6D5qu/qzV 7dXOl/8b0xEnO7ApD8HPoN2ywqxFYwjCFmh0B9rTN2M8D2UiMN6zF/YFIwPk2RE1wTjoXEwbFBdu eC9pJEa/4btiUDw0QFnG0zRGhtJlM8Zs/TLW9wSOrns3k/NcYLWqbLbw2jWFInIqOmEhlJeOmsgS eamHpOaQeNxt3ixuGVjvpTAv345AeU3F9C/PezeV7FOx8oVp4Ib/EGwFIsERIxNJG2Zgy31dAIsg TtgcTRmxNDYzILRWAmMmrJ0DxMqfCQcM44w2VSHfwbDvU17XIuq64OpqEnWF/8uQeEbUPYuMgoFL q1i3r0bUlU0ay3tfHxlVsXDIhmd1oTYYdIPaNmxfn42no6qqW6x8Ybj98dOaZxJTbvjS8HRFuZ0h HAX3M3EiqkJyD4CPdVY/+jwqvSmaMSJoPozv8QHMGQlkLnicstNCSajy/ddUNhIhZgTqAyMRY+r1 nFKpMtWsb6lgdeUde47uEByc9/vnl/lXAjfc6oyFMTdysUUxQ4e8wVxPjqFRH3O8VlVHPJR/F3XH nu4gqD/2jM6C3qSSJi1W3kz+fbfDBsIRcGQFhtBI6RlJbrUi+hFwkoMMvolkdfLyWDZwwxFoGoAz sTwEbQDpoh8AdlP0o3N/IiF0GGbGf4RB24CNJe+KFlpUDkZ7GXu8Y8zInuqR0FiJfIQnEpCzBMid t/kFP0yfkBjNfAM6tyEqGQUIzPaSPizItYiR3b+8yKK8CzkU+Zd1+/3uoFs/8oNucD32pPM+xVKs vMnIpyJO3ZDvop4aIrYwOmE6M2VW/EqTtBcyx7IB6IFFCTtKbMqop7J3knfXgE+d0jWPT3z+3jbn iBi78mW2SBYrXA1YPd4haDDwHegiFiBkoScKeflVBB9Z/1cJfwpqO/wvAAAA//8DAFBLAwQUAAYA CAAAACEAMN1DKagGAACkGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRv Yyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdS ksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9 KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYox TTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNS wUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDv g6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fw jc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2K tRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/ RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6L L5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc 9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8 WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMn mmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhl XE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQ ohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/gykbY2JKDRR1p1bHNPm7 ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi/K44 e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFnMjBw cKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2cnzUK Mkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw8iqc +TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuLk8rs GgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37U5PZ ZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9JAXZ0 XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ryjZjB 2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuMdKa0 PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ6DuF WD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH32hz4 pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK0v41RTjnVmsr1pzGy81c OPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H0gXSDo6gcbKDNpg0KWva rHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2ZIrC0Dg/yBjHmM9k5S9Z fHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQUAAYACAAAACEAgEkJEXwE AAAPDQAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFfbbuM2EH0v0H8w9FzH1N1W4yx07e4i6RZ19gMo ibaJiKRAUXG8X9+hLvGmYYJFF30yNWfuM+SMrz88sWbxSGRHBd9a9hWyFoRXoqb8sLW+3hfLtbXo FOY1bgQnW+tMOuvDza+/XJ+ijigFbN0CVPAuYtXWOirVRqtVVx0Jw92VaAkHcC8kwwo+5WHFsHzo 22UlWIsVLWlD1XnlIBRYkxqxtXrJo0nFktFKik7slRaJxH5PKzL9zBLyR+yOkpmoeka4GiyuJGnA B8G7I227WRv7r9ogxOOs5PG9IB5ZM/OdbPQe5xTuScj6WeJH3NMCrRQV6TooEGvGcBmm/FmN7b1S 9JzqK0j1arS90qpA3EbD6eJ517ySN1R7rOItLSWWY5mhAbQXrIo+HbiQuGygqU62Z91AR30Tgi1O UUtkBUWCdkTIWmmgJnvcN+oelzslWmB5xGA/dCa4OmKJK0XkrsUVRJwKrqRoZr5a/ClUCh0nISGj wrH/tOrxtBt7GSQ4ZuDRSJ36807UxAKol/RV0G8mTQsMXkJsQwxmQwLunqQ1gdAaslPnhhTg/I5+ IzGvP/edotDxQ5f+hAfvOUC4tvwFbur9uSUFwaqHNP1PxoZKFA1t76iUQn7iNdT5Z42t5iLqcsJD Vnfz4W8h1FwGhOLEDvOpGJrtgiDbzrxgzNK/ED+0Q9+IBCgJcyOyDgOnMCIx8jKznSRI89gok4VJ npkQx0XpJjQjTpK6ZsSNw7URSbw4T41I6thrY6ROgTKzby6y88QxaXNj239DJvfWyGjHC4M4Tkza vALl8fQKvKycvwm9wliFwAv9wtgHQY6yN2QK298YZULPiVNjRkPfD9+QicPQNXodpp4TGPO29l3f MWZnndgFMlZuEwZuZuyQTeIh15hRQHLPN+V6k4ZBZvQgDhwvs00yb9+5OPEKs2+JE2a5sXvTjbP2 jHbSzLMDY0Yz5GfmO5dlqNgY71zuesnG6EEeu75r7Ko8czau0bfCgcoZa1o4fhYa73bhQn2MuS5i VJh7p0jhFRv6AF7E6R1kkV5L/pI31+NJD5cFGwdTilkpKV7c6cUFRhSLSvmQUD7jJYHFjXyP7Ppy BpfLEegYbpoCpu8MDEVgUU27NiP7QW1zh+XhonfikEYqTPrPz7r0FkDkH1L07WjtJHE7Do3ZnO15 kz7K1S1lM73ry90sxWH5+A7qef3lUWqFq0t6TpGCnXUYvreYH+bZQPjy606zwoxp5E7vteQOty0s GcBSHuyt1dDDUdl6YCr4qmG/HT7KgzNhzoDBl8aGD1zpyIB7OmiG8Qhc0+FCc2eae6HB9jbyeRea P9P8Cy2YabBfn6IjTHjZUP4Aa8x81PS9aBpxIvXHmbi1XpHGJHRH3BKoq97GYMyKaCBM61m3eIzI E+xtpKYK/ja0tGb4Sa9xzjD0Ju4Gn0WvXvBqTZq5fUFd1FhhEB9K9UIYSgf/P176orfEikI77s6s vCx/v42ON7RTO9LCnqiEhJCH1ez3QfPln8zNPwAAAP//AwBQSwMEFAAGAAgAAAAhABegFk4CAQAA rAEAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbIzQwUoDMRAG4LvgOyy5t9mVIrJ0tyBS8SKC+gBp dnYbzGTCTGqsT2/aqiBeesskmY+Zf7n6QF+9A4uj0KlmXqsKgqXBhalTry/r2Y2qJJkwGE8BOrUH Uav+8mKZ2wybZ0ip/JSqKEFatJ3aphRbrcVuAY3MKUIojyMxmlRKnjQaftvFmSWMJrmN8y7t9VVd X6tvhs9RaBydhTuyO4SQjv2awReRgmxdlB8tn6Nl4iEyWRAp+6A/eWhc+GWaxT8InWUSGtO8LKNP E+kDVdqb+nhCryq07cMUiM3GlwRzs1B9iY9icug+YU18y5QFWB+ujfeUnx7vS6H/ZNx/AQAA//8D AFBLAwQUAAYACAAAACEAcgflDoUJAAB6SQAAGgAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1s zFzbbuM2EH0v0H8Q9J71JandDeotsk7TDbBtt+sEfaZlOlYjiaokx5t+fYdDiaJ1sYaWAvTJ0YVz 5nqGcTj56edvYeC88CT1RbRwJ+/GrsMjT2z86GnhPj7cXfzoOmnGog0LRMQX7itP3Z8/fP/dT4fr NHsNeOqAgCi9PsTewt1lWXw9GqXejocsfRf6XiJSsc3eeSIcie3W9/joIJLNaDqejPGnOBEeT1NA W7LohaVuLi6sSxMxjwBrK5KQZek7kTyNQpY87+MLkB6zzF/7gZ+9guzxrBAjFu4+ia5zhS60QnLJ tVIo/yhWJDUrGnDVylvh7UMeZYg4SngAOogo3flxaca50sDEXaHSyykjXsKgeO8QT65qeNpkSgxu E3aAUJQCa+IanLFRi8JA+UHGt4xqVeJkfMqYPCJShNaBosIxZqFJyPxIiznPNaZzoR765PevidjH Wp3Y7yftPnrWsmRZWmg2nmHlmaalVgJqpbvasZi7Tuhd3z9FImHrADQ6TK4cmZHuB6CKjfBu+Zbt gyyVl8mXJL/Mr/DjTkRZ6hyuWer5/gNQCEgJfRD46SZKfReecJZmN6nPGh/u5FuNT7w0M6R99De+ O5KI6b8g84UFC3c6Le4spQZH9wIWPRX3eHTxuDI1Wbj61hrkLlyWXKxupLARmll8GubGR8bDFaoS Mw8qD3DYNuNAQsBiEifwZXSnc2A0dfF1L53L9pnIQVAAgJli4bLiceAmYKqVYmx4yrefhffMN6sM HixcxIKbj/dfEl8kQKML9/17iQk3Vzz0P/mbDZcNIr/3GO38Df9rx6PHlG/K+3/eIT3nEj2xjzJQ fzbHLAjSzS/fPB5LmgTREZMR/l0uAA6DcBg4qNDeL7VRNyqoePOfAnKiYtiIsuNMtjQH9T8JhFbv ewNNpUWmASjXStfL/iKu+ov4ob8ITN5+vpj31wI2Mn0jonLDyEp6UDPhqeQz/XD5/kTKyhW1LOpc UUuazhW1HOlcUUuJzhW1DOhcUQt454pafDtX1MJ5coXHkLiqWXSJ3iAV9oOfBdAnO5hu0pPq8lbj fGEJe0pYvHNkY62qfYosV/t1RlMV6fR8slxliZDbzQ6PQHeWpXs2J/8SxjuW+rAr7wLq6foHufVx fk182L52QP2gkq9mE25MGlvYl4B5fCeCDU+cB/5NRdRi/e/CWaldRqdyPcP62X/aZQ7sCmXL7QSb tTi93RNK/mc/RR+c7OazFlO6hJNiOGvJy3bhv/GNvw8L1xB2IzPF5xZhrkCgiqdddCVDVK+uTitk ACgmqHZhbwLKJ+ivmou9fBljiv6qFZ0pn6C/alxnysf8OB1fa6a5ha9VHFJ5za1rdykCkWz3QVED nfQwt65gDUEzwbqItXwSScytK/iIPp0bz4Pf3Ch5ah2LkkctUKzDoVCw2Oi2WAelQnsTC4usA1TB mlpg9eNaCyBr0v3KX3z5JbBtM0CW1nvNznK+bPEAtCDSHvrPvci699DTFs6jotxH8HVJyh0a2mVL 5VHR8nxS/c4ixv0anwVQvw5oAdSvFVoAteRH+55H90Q6SP/maIFlTcu6i2HakZl5bs3MGsiuBQzU Nwn7r5bqbc+Fet8koFgHqN43CSjW0an0Mt03CViD9U0CVkvXaI+Ryak2Rln3TRNI7wQIFg1D3gSg YcibADQMeROA+pN3N8hw5E3AsuYGzakmeROA8BWbX/U1kEneBCBrblBsl39nVPQ9lHL6l9sByJuA Yh2gOnkTUKyj00beBCx8xSYTKlia6ghYw5A3AWgY8iYADUPeBKBhyJsANAx5E4D6k3c3yHDkTcCy 5gbNqSZ5E4Cs6UEDmeRNAMJXbLihkbyx6t+cvAko1gGqkzcBxTo6FULVm1QClnWAKliavAlY+IpN MuRYmNw2Rg1D3gSLhiFvAtAw5E0AGoa8CUD9ybsbZDjyJmBZc4PmVJO8CUDW9KCBTPImAFlzQyN5 YzG+OXkTUKwDVCdvAop1dCqEqnmOgGUdoAqWJm8CFuZLb/ImAOEr5wLZWDQMeRMsGoa8CUDDkDcB qD95d4MMR94ELGtu0JxqkjcByJoeNJBJ3gQga25oJG+skTcnbwKKdYDq5E1AsY5OhVA1eROwrANU wdJUR8AahrwJQJiYvcmbAISvnAGEVWQTpmHIm2DRMORNAOpP3t0gw5E3AcuaGzSnmuRNALKmBw1k kjcByJob5DlbOC9KPp46aUkC6jmD4lQDGXDaEiQqYG7gV77lCUwV8u7TIT0BCwstEFvSg2riRyGe HdrB7suWBCFD+evAF3ik+xVP6RiDCJfzE5MED38snU9qAKa2DlPq+OQNTA+Z40I4niQHh0DP7DWG kZ24OFkupcGAkJzrykeAcCb0HgaC8rEeuVjO+cCLOFSV38a/2+ao8DMg4sI6lLcDLA8mok5A5Qfe 9RkkPO5eBW45FY+KlCMZhZr56fhyD6XeOzqjeVLvTJ4EP6EznhQ/6SMHX1FRrSsIw1moUpeGELJ1 oEbM4If7aAMWHvLpLBXMzTemRMHzJQ+C3xgOpGUibn814NtMPZ2MsQNWRK1FlomwfX2CB8RRkyYB kA6mMupSGtGeJ9E+XPMkP27empKyc+Ak2nFKqrOuLalA9XS7bkflogsEjvP7EZ7jr6YqPlFH/FGn NYMRuz/kxFythGA88Lm4rwUuoWa68uZ4E4YwMAIuswMxxuPb2/Hd+xslpm1GEf/2mk8oXumL5gnF fBoSPo7GPBfuEkamRSAnvw/XOMJp3FIpXk5pFmX5rzGliffA+TBTeipBjojE26eQnzgNWeWtYy+2 h8YpvVyJTyMdoSWN0eqKVHtY0OL/h0N1Vi9FKEfiy/5b9SCLIgEzp3ICNNHbgqY0b3djHzY89ub4 x/lseqcikHuznAmezNSD1Mg2da8725pLPndOY9EbfsnkcE+TS8zmaeaSIbfMyrfxUo0KbMu/9O90 XPevutftX2o1Vz1Tzcb8OZJt34o2sJRh5AhYJGUfp51MStiq/829enc08jLNX2lKzZrxESRx0U1q DxuSN8d/6/zNq3ytbFim8Dl4tpmmtCVc/k57zhk+K33S7rehM850EGzOyxbco2ib8+8jCwIhmndC +TP7vZAhtPQeuR47N0dm36gxYv4PHPR+CP7/wdmbowe2EyEztkblDQ/+aUd+hclcxqhP46ISa9XB 1Tw3I9ee5O093sx0A2voNK9uRkv35lvR8sYw/gaywb1S+uE/AAAA//8DAFBLAwQUAAYACAAAACEA NQh7rU0BAAB4AgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAjJJRS8MwFIXfBf9DyXubtCs6QtuBkz05EJwovoXkbgs2aUiydfPXm3Zb7dAH H2/OyXfPvUkxO6g62oN1stElShOCItC8EVJvSvS6WsRTFDnPtGB1o6FER3BoVt3eFNxQ3lh4to0B 6yW4KJC0o9yUaOu9oRg7vgXFXBIcOojrxirmQ2k32DD+yTaAM0LusALPBPMMd8DYDER0Rgo+IM3O 1j1AcAw1KNDe4TRJ8Y/Xg1Xuzwu9MnIq6Y8mzHSOO2YLfhIH98HJwdi2bdJO+hghf4rfl08v/aix 1N2uOKCqEJxyC8w3tlrO7e6rwKOTbns1c34ZFr2WIB6OF9NvofNa2Mvuhao8L/C4Dm36qU69QEQh Jz1NdVHeJvPH1QJVGUnzOE1jMl1lhJJ7SshHF+rqfpf7dKDO0f5JzGieXRMvgKpPfP1Xqm8AAAD/ /wMAUEsDBBQABgAIAAAAIQDzekrQCAkAAIlGAAAPAAAAd29yZC9zdHlsZXMueG1szFxdc9u2En2/ M/0PHL4n+rBrNZ4qHceubzyTpmlkz32GKMjiDUnoElQc99ffxYICIZIgFyY90yeZILkH2D17FrKx /vW3H2kSfOe5jEW2DGdvp2HAs0hs4uxxGT7c3775JQxkwbINS0TGl+Ezl+Fv73/6169Pl7J4TrgM wEAmL9NoGe6KYn85mchox1Mm34o9z+DmVuQpK+Ayf5ykLP922L+JRLpnRbyOk7h4nsyn04uwNJNT rIjtNo74jYgOKc8KfH+S8wQsikzu4r08WnuiWHsS+Wafi4hLCYtOE20vZXFmzMzOG4bSOMqFFNvi LSxmomc0Uabg9dkUf0qTMEijy7vHTORsnYDznmbn4Xvw3EZEN3zLDkkh1WX+JS8vyyv8uBVZIYOn SyajOL4Hl4KBNAZbH68yGYdwhzNZXMmYtd7cqada70SysKx9iDdxOFGI8m+w+Z0ly3A+P45cqxmc jCUsezyO8ezNw8qeyTI0Q2uwuwxZ/mZ1pYxNcJnHT2u5+5PFwxVOZc8iCAbgsG3BgRTAEYWTxIqD 8wXwRV98PSi/skMhShA0AGC2WbiseRy4AsxZaQLDXb79JKJvfLMq4MYyRCwYfLj7ksciB5Iuw3fv FCYMrngaf4w3G67ypRx7yHbxhv9nx7MHyTfV+F+3SP7SYiQOWQHTv1ggCxK5+f1HxPeKtmA6YyrC n9ULQBwIh4WDEzrE1Wz0QA0VB/93hJzpGLai7DhTGR7g/DuBcNWHwUBztSJ7AWjXa65nw02cDzfx 83ATSN5hvlgMnwXo+tCIaG5YrKQHtRCRJp/th7N3HZRVbzRY1PtGgzS9bzQ40vtGgxK9bzQY0PtG I+C9bzTi2/tGI5ydb0QMhavOojP0Bimx7+Mi4er9TgGaDZS6stQEX1jOHnO23wWqsNan3SWWq8O6 oE0V5fTlYrkqcpE99noEqrNK3Rdr8u/pfsdkDLukHtfPB7r+Xu16gn/n8aYX6mdNvsaacGPSWsK+ JCziO5FseB7c8x86oh7vfxbBSu8yeic3MKyf4sddEax2WHJ7wS4cTnd7Qtv/FEv0QWcyXTiW0mec FMMLBy/dxv/gm/iQHl1D2I1caD33CHMNAqfY7aJzFaJmdvWuQgWAsgRdLvyXgPYJ89fFxd++ijFl /roUvdA+Yf66cL3QPvKjO77eSnMDX1oDUnotvHP3WiQi3x6SYw70ysPCO4MNBG0J3kls7JNEYuGd wSfyGVxFEXxzo/DUOxaVjnqgeIdDo2Cy0dfiHZSa7M08VuQdoBrW3ANrmNZ6AHmL7lf+PVa/E/Mt BqjSZq/Zm85nDg9ACSLtof86iKJ/Dz13aB4V5S6DX5dIHtDQzhyZR0Ur+aTrnUeMhxU+D6BhFdAD aFgp9ABy8MO95zE1kQ4yvDh6YHnLsqliSDuyMi+8ldkA+ZWAkeomYf/lyF43F5p1k4DiHaBm3SSg eEenVstM3SRgjVY3CViOquGOka2pPovyrps2kNkJEFY0jngTgMYRbwLQOOJNABou3v0g44k3Actb G4ym2uJNAMJHfL7qGyBbvAlA3tqg1a78ndGx7qGV7i+3I4g3AcU7QE3xJqB4R8cl3gQsfMSHCTUs I3UErHHEmwA0jngTgMYRbwLQOOJNABpHvAlAw8W7H2Q88SZgeWuD0VRbvAlA3vJggGzxJgDhIz7a 0CremPWvLt4EFO8ANcWbgOIdnZqgmk0qAcs7QDUsI94ELHzEhwwlFpLbZ1HjiDdhReOINwFoHPEm AI0j3gSg4eLdDzKeeBOwvLXBaKot3gQgb3kwQLZ4E4C8taFVvDEZX128CSjeAWqKNwHFOzo1QTU6 R8DyDlANy4g3AQv5Mli8CUD4yEuBfFY0jngTVjSOeBOAxhFvAtBw8e4HGU+8CVje2mA01RZvApC3 PBggW7wJQN7a0CremCOvLt4EFO8ANcWbgOIdnZqgGvEmYHkHqIZlpI6ANY54E4CQmIPFmwCEj7wA CLPIJ0zjiDdhReOINwFouHj3g4wn3gQsb20wmmqLNwHIWx4MkC3eBCBvbVDnbOG8KPl46sxBAuo5 g+OpBjLg3BEkKmC5wK98y3NosuL9p0MGAh5X6IHooAd1iR+E+BbQDnafOQhChorXSSzwSPczntKx GhHOFh2dBPd/XgcfdQNM4z2k1OnJG+gestuFsD1JNQ7BPIvnPbTs7I8ny5U1aBBSfV1lCxC2yN1B Q1DZ1qNeVn0+8CA2VZXD+HfbEhV+BkR8sQkV7QArgo6oDqjywLs5g4TH3evAjlPxOJGqJeM4zfJ0 fLWH0s+dnNHsnHehToJ3zBlPinf6KMBHdFSbE4TmLJxS3wwhZOtEt5jBD3fZBlYITYL4VzMdzM0P pk3B/WueJH8wbEgrxN79aMK3hb47m2IFrJlai6IQqfv9HA+I40zaDAAd7MnoS7UIN0+yQ7rmOXR4 dfj8s1CVAzvRTimpz7o6qED1tHtuJ+liEgSO88cZnuOvUxXv6CP+OKc1gxa7P1XHXCOFoD3w23Hc GLyGnOnjzekmDGGgI1axAzGm05ub6e27K23G1aOILCo7FM/NRXuHYtkNCR8nbZ7L8BpaWEXCpAoc tnBaQ5riVZfmMS3/tro0cQycDz2lXQQ5EZLoIIGf2A1Z161TL7pDE1RersWnVY5wJa3R6ouUOyy4 4n+GQw2rr0WqWpSr+lv3IMsyAT2nqgM0N9uCNpq73ThEDU+9Of1lcTG/1REovVn1BM8u9A1psU2P 9bOtPeVL57QmveWXQjX3tLnELp42lyy7FStfx0sNKfBN/8q/0GxV5reVzTjW719qNtc9U2djeR/F dmhGW1h6YeQIeJByiNM6SQlb9f/yqFkdLV7K8pE2ajYWnwGJj9WkcbOFvCX+a/O3zPK1XsO1hM/R 2WYvxUW48hk35yyfVT5x+21sxtkOgs15VYIHJG07/z6wJBGifSdU3vPfC1lGK++R87F3c2TXjYYi lv/AweyH4P8fvHhzdM92ImXW1qgaiOQyLK9KGT2m25DCRRXWuoPrPLcj5ya5u8bbTLewxqZ5fTNa ubfcilYD4/gbxAb3SvL9/wEAAP//AwBQSwMEFAAGAAgAAAAhADEBs7AsAgAAwAcAABIAAAB3b3Jk L2ZvbnRUYWJsZS54bWy8VF1v2jAUfZ+0/xD5vcQOgRbUULWsSHvZw9T9AGMcYs0fkW1I+fe7jtNU grEGJhWkCM61j+49OffcP7wqmey5dcLoApERRgnXzGyE3hbo18vq5g4lzlO9odJoXqADd+hh8fXL fTMvjfYugfvazRUrUOV9PU9TxyquqBuZmmsolsYq6uGv3aaK2t+7+oYZVVMv1kIKf0gzjKeoo7FD WExZCsa/GbZTXPv2fmq5BEajXSVq98bWDGFrjN3U1jDuHMysZORTVOiehuQnREowa5wp/QiGSWNH aaCC6wS3v5REiWLz71ttLF1L0K4hOVp0wiXNXFMF4JJKsbaiLdRUG8cJ1PZUFghneIUn8AzfHI/D E6WBgVXUOu77gzjCJVVCHt5Q1wjnYqEWnlVv+J5aERqKJSe2UNi5NS7QM8EYZ6sViggpUA7A47JH MmgqfmbdmXGPgHOgsZanPUJmLQ8gwNPdavtMo3VOlHgRirvkB2+Sn0ZRfUaRDE9BiQnoEZQZX6SI bXlbBYcqAo1nj/38MMkSkNu7nHTzX6RI5BmuyBIMbSR1Z6R4AilmV5pDmQ23+i/uKMUr3wy1xuqz rEEreHX/kCFsR/BE/ik7kj0fO2KKJ0/Hjsg+2hGCyeWO2FnBbdiSM2rcghLRFGE/QJH4LgclxsWm OLcd42Mt8Eda4Cu0oAqC85wrQj5ET4S8uCw5r8uJ0+TEee+T95xocxLy9n+Ss4tQt/gDAAD//wMA UEsDBBQABgAIAAAAIQD8lDod9AEAAPEDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTy27bMBC8F+g/CLrHtPyIH1gzCJwWObSNASvJmaFW NlGJJEjGiPv1XUqxQ7c91afd2cVwPDuCm7e2yQ7ovDJ6lReDYZ6hlqZSerfKH8uvV/M880HoSjRG 4yo/os9v+OdPsHHGogsKfUYU2q/yfQh2yZiXe2yFH9BY06Q2rhWBWrdjpq6VxDsjX1vUgY2Gw2uG bwF1hdWVPRPmPePyEP6XtDIy6vNP5dGSYA4ltrYRAfmPKKcZVCa0wM4olCaIplQt8mI6pcG5hY3Y oefjBbC+gmfjKs+L8Ww+B9Y3sN4LJ2QgG/lsPl2MgSUI3FrbKCkCWcy/K+mMN3XIHjozssgALF0B MmiL8tWpcORDYGkL35QmOdfTCbC+JIFO7JywexI1JzjpYStFg2tygtei8QjsA4B7FPHKG6FINRzC 8oAyGJd59YvuPMqzF+Ex+rfKD8IpoQP5GNf6pqsb64PjpQoNcdOs77syXUtrNeFFt0DF5WIk6DXQ 4FJd94J/qOm/hX+ILVKxnYZeaiInKc9v/MG6Nq0V+si/OCW9N5qO+I5E13/6R1uau5ihdy8vwSQD zyrst1ZIOtRiVCxmaRqSGWwpNVjReU+MHwDck/Guic9SkvQOq9PO34OYr6f+C+bFZDCkXxeoE0aR OH9a/DcAAAD//wMAUEsBAi0AFAAGAAgAAAAhAOc0ba2NAQAAEQYAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAA AAAAAADGAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEATkHa+zIBAAA8BAAAHAAAAAAAAAAA AAAAAADqBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQAfNYaL 8NMAAEceDQARAAAAAAAAAAAAAAAAAF4JAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAA IQAHZ5XfaQcAAKIiAAARAAAAAAAAAAAAAAAAAH3dAAB3b3JkL2NvbW1lbnRzLnhtbFBLAQItABQA BgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAAAAAAABXlAAB3b3JkL3RoZW1lL3RoZW1lMS54 bWxQSwECLQAUAAYACAAAACEAgEkJEXwEAAAPDQAAEQAAAAAAAAAAAAAAAADw6wAAd29yZC9zZXR0 aW5ncy54bWxQSwECLQAUAAYACAAAACEAF6AWTgIBAACsAQAAFAAAAAAAAAAAAAAAAACb8AAAd29y ZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAcgflDoUJAAB6SQAAGgAAAAAAAAAAAAAA AADP8QAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAAACEANQh7rU0BAAB4 AgAAEQAAAAAAAAAAAAAAAACM+wAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA83pK 0AgJAACJRgAADwAAAAAAAAAAAAAAAAAQ/gAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAh ADEBs7AsAgAAwAcAABIAAAAAAAAAAAAAAAAARQcBAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQA BgAIAAAAIQD8lDod9AEAAPEDAAAQAAAAAAAAAAAAAAAAAKEJAQBkb2NQcm9wcy9hcHAueG1sUEsF BgAAAAANAA0ASAMAAMsMAQAAAA== --_002_087A34937E64E74E848732CFF8354B9209857284ESESSMB101erics_-- From nobody Sun Nov 9 16:27: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 58B981A87C1 for ; Sun, 9 Nov 2014 16:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 49MHNtbUG-8Z for ; Sun, 9 Nov 2014 16:27:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D449A1A87AE for ; Sun, 9 Nov 2014 16:27:09 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 092A1324305; Mon, 10 Nov 2014 01:27:08 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E122027C06A; Mon, 10 Nov 2014 01:27:07 +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.0210.002; Mon, 10 Nov 2014 01:27:07 +0100 From: To: "dime@ietf.org" Thread-Topic: meeting Slides Thread-Index: Ac/8fD2vQ/9+q+jTS72y/0fVco7m4g== Date: Mon, 10 Nov 2014 00:27:06 +0000 Message-ID: <3217_1415579227_5460065B_3217_7145_1_6B7134B31289DC4FAF731D844122B36E8B84E9@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.2] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E8B84E9PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.9.121228 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XSl_MHLmOKh8epiRlsF87yYs6dw Cc: "dime-chairs@tools.ietf.org" Subject: [Dime] meeting Slides X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 00:27:12 -0000 --_000_6B7134B31289DC4FAF731D844122B36E8B84E9PEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please provide ASAP your slides that will be presented during the dime sess= ion. Don't forget that these slides are not only used as a support for the prese= ntation during the meeting. They are also useful for people outside the mee= ting room, either in parallel sessions or not present at all. Regards, Lionel & Jouni ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E8B84E9PEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please provide ASAP your slides= that will be presented during the dime session.

Don't forget that these slides = are not only used as a support for the presentation during the meeting. The= y are also useful for people outside the meeting room, either in parallel s= essions or not present at all.

 

Regards,

 

Lionel & Jouni

 

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E8B84E9PEXCVZYM13corpora_-- From nobody Mon Nov 10 00:06: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 D2A401A8963 for ; Mon, 10 Nov 2014 00:06:49 -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 HHQJdptRQZzF for ; Mon, 10 Nov 2014 00:06:49 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB651A8957 for ; Mon, 10 Nov 2014 00:06:49 -0800 (PST) Received: from dhcp-8d15.meeting.ietf.org ([31.133.141.21]:52028) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xnjzk-0001GN-DS for dime@ietf.org; Mon, 10 Nov 2014 00:06:48 -0800 Message-ID: <5460720C.9080802@usdonovans.com> Date: Sun, 09 Nov 2014 22:06:36 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------050709040102040705020408" 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/M9swylMcUuX5qbZMtD0hofJmv0o Subject: [Dime] Updated Agent Overload Draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 08:06:50 -0000 This is a multi-part message in MIME format. --------------050709040102040705020408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I have submitted an updated version of the Agent Overload draft, making it consistent with draft-ietf-dime-ovli-04.txt. The new version can be found here: http://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload/ Regards, Steve --------------050709040102040705020408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I have submitted an updated version of the Agent Overload draft, making it consistent with draft-ietf-dime-ovli-04.txt.

The new version can be found here:  http://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload/

Regards,

Steve


--------------050709040102040705020408-- From nobody Mon Nov 10 00:07: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 34FFE1A8957 for ; Mon, 10 Nov 2014 00:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZuCE_g8YkTZm for ; Mon, 10 Nov 2014 00:07:33 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA771A894A for ; Mon, 10 Nov 2014 00:07:33 -0800 (PST) Received: from dhcp-8d15.meeting.ietf.org ([31.133.141.21]:52031) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xnk0a-0002AN-97 for dime@ietf.org; Mon, 10 Nov 2014 00:07:33 -0800 Message-ID: <54607242.6030003@usdonovans.com> Date: Sun, 09 Nov 2014 22:07:30 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x3og-zyms9_oJ45mzlqhllAQ97w Subject: [Dime] Update Rate Control draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 08:07:34 -0000 All, I have submitted an updated version of the Rate Control abatement algorithm draft, making it consistent with draft-ietf-dime-ovli-04.txt. The new version can be found here: http://datatracker.ietf.org/doc/draft-donovan-dime-doc-rate-control/ Regards, Steve From nobody Mon Nov 10 07:34: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 C80461A90B4 for ; Mon, 10 Nov 2014 07:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 6nxT_1c-yLFe for ; Mon, 10 Nov 2014 07:34:42 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F781A90B1 for ; Mon, 10 Nov 2014 07:34:40 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAAFYbPv022442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2014 15:34:37 GMT 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 sAAFYadQ015269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 16:34:36 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.88]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 16:34:35 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zS149M3XUUPk28UQPOO8ZJK5xXdZWAgAKSXaA= Date: Mon, 10 Nov 2014 15:34:34 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209857284@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.104] Content-Type: multipart/mixed; boundary="_002_5BCBA1FC2B7F0B4C9D935572D900066815228896DEMUMBX014nsnin_" 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: 103786 X-purgate-ID: 151667::1415633677-0000437E-2D0DC27F/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/92JikMN825fZ0WEhfqTPgm-YPOo Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 15:34:46 -0000 --_002_5BCBA1FC2B7F0B4C9D935572D900066815228896DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sreve, MCruz, all, please find more comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Sunday, November 09, 2014 2:17 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Steve, all, See some comments included in attached doc. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 03 de noviembre de 2014 15:36 To: dime@ietf.org Subject: [Dime] Updates to DOIC -05 All, I have done another end-to-end read of the DOIC specification, focusing on = wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. Regards, Steve --_002_5BCBA1FC2B7F0B4C9D935572D900066815228896DEMUMBX014nsnin_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-dime-ovli-05 (prel)_MCruz_UW.docx" Content-Description: draft-ietf-dime-ovli-05 (prel)_MCruz_UW.docx Content-Disposition: attachment; filename="draft-ietf-dime-ovli-05 (prel)_MCruz_UW.docx"; size=74661; creation-date="Mon, 10 Nov 2014 15:32:24 GMT"; modification-date="Mon, 10 Nov 2014 15:32:25 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 AIPVpkeA3wAAkUUNABEAAAB3b3JkL2RvY3VtZW50LnhtbOxda2/bWJL9vsD+hwt9mQSwHD0SJzEm HiiSjfZOYntldwO7jcaCIq8sTiiSy4cd7a/fU5e8FEm9bclkkspg2pJsy6TOrfepqr//4/vUEQ8y CG3P/dRoH7caQrqmZ9nu/afG73cXzQ8NEUaGaxmO58pPjZkMG/84+/d/+/vjqeWZ8VS6kcBbuOHp A747iSL/9M2b0JzIqREee7508c2xF0yNCE+D+zdTI/gW+03Tm/pGZI9sx45mbzqt1kkjfRvvUyMO 3NP0LZpT2wy80BtH9Cun3nhsmzL9on8j2ObvJr85SC9Z/cU3gXRwDZ4bTmw/1O82feq74RYn+k0e 1t3Ew9TRP/fob/PXrMB4BB5TJ7nsRy+w/MAzZRji1UHyzewd2611fzv9AOktst/Y5hKKf1NfydSw 3ext6HSU8M/AOwZ4b5K//Ybean4j+CzOcJZGnjWjr754PMVZtIafGq3WRa910cWBTF8ayLERO9Hi d27opcGgdfGxp97MvwnUe91GM0fitx8M51PjxsHF3snvUeMNfTNIfia48NwoxM8YoWnbnxp9Lw5s GYgr+Uh/d9Jzw8VXzbD4g3jDN+k74qv66/R14X5aH96fdC6W3U/xOz/K/ZTwuYEgZjj8NKDtepPd t63uuca4hkjioGpsCoAdUCgeT6OzgW1MZQTJ+goxjKRruKYUMCvi/DuekfUJxavB5dfz16Lw7z+O xT+9YALb4x6Jc+uYJC1K5E39d1HKGLBnazH6iC+BUuDKqAkDM44KmGz15HPgGRbUPgOWN00HMjsa MNeSFrlrURyeilvltgVWKO4Cw/y2ErXbYzHwXO/BYAkbvqRKPP/u24EEUF+NmXh/JDqt9ruVIJW/ 8flY9I2pP5KOwxL2MhJGAcpp6BsmHF0fwMngQTbOysDs/vwa0ulIRvEHRvHLsfjqBXBnGMUfFkWI oXsvxRdjFDKKPyKKV96DnI4QYnSVLX27fxQL+YgaxnZLsw67xkO/xE1ylJ7kuHKpK8QQ23k4WSh/ jbyxgyhPXLqWbapUquh77oOcUXS/f/Fj0J4OWuKWIpOMTLoto3HTsqey6T04drP17jj6Hu0fLlYk NUhEV5Tu643CCGENn6qllYxClkFnY/PlDdZ0O2m6u4kditCXpo3yYGKHLDm2XRkKQ4yMUIrQc2Iq 9QnUIsWCAdu/7mMAdwIQXkMUeA4qANf910cikGMZBEhlRp4wwkW82OFIqozVKPeVXiLQu+y/PkCJ hj2JX9eTGMr/jZEmJ6LJAfIyfLJ+2ZO1Uo3dTaT4JmeCiCqhaHz9/faucZR8FVfX6vHw/D9/vxye D+j12996X75kD5KfYIei4gQiULn+/UuKDz2aI9e//vr1/GqQgPe191+AjngIjeubu8vrq96XhrBd EcGjZBArBjEjGBqBJFdwJAENWAkovkVwDuEZWjI0A3uEJ8BseNEXnXb7o/gTj+jBX+yKcPi5J2If MSxAqACxQnhjoQLOr3Lq7V9HsEfCHkmZYKCOW4mQRRmPeDS1I1KF0H7j2HGE6bmKbE3kukc7msCO cR4+46QeluK40p8EV/vBThiOUB2f+zfi/QflcqiHH9lIsZHan5FaeQqL6gOJUfhUiHC+oYVAaEdL 2TaoDOTXEvKnOHfvkUaVAX5q/6aOk6Q7JUnvjPCbuPAC6PZXl+d3F6+PhbjyIrjGEyMSHnALxH3g xX4opmAUGk7oCctGHcYexRGbgarNwKKwIYDRgpawrEMgStkHB6iRm2nGyIKjwSr7KZbBikNSRYYP BZwviFza7WQZiAuIYS2DYyqtqz43VWkP36QIvmEjz0a+IiOvTmLOxKMbzrZUHdSAnfhuT+Mp6ZrQ /i6mKMNNOO9VtaWgdCRZcOS7Yh/aRVpUEvUdMM/xCAVsb4R6tsqBjWap4Z+7cFBMhjtjS1GxpYjA r4I5v4zIWNiu4SMM9AMbaFIqMwYnIbPqqVGBO6AK3+i/Zm+tahlENzeiHsMhcQNepq38bAlVqfxs uNwuJaAb5NVR+gXo3qMnJDxu7F/yOCXIKcFtUoKPNlKAUnWVCVCdcm1l7H6y+7k/9/Os7/mzwL6f RJR/wEAOVnnL5lUwy3P3+RnrmhDmp+6V+Zq6Zd8KSoOhuzlGuoScZkpd+phlQ8MEbAuZE/BBk0Ix vrP/Q8r5y53ylzpEEUYcTbyAkl09GCylSMj1VQ21h5jw8Ev4T3yTNXASuQEPlGQa37TR9v08x7U4 u2lY5zaOx1MHPc5oOFETscZB82JI07BwatVcEjq96Vgs3ZSS4Jje4gHq5xuuiFg38/E/ElbegdXI /qUTNPKRTva97MGfNwbautt/PdH+r4G3bmd4w4ep4d1eSf3K957Ok9OCUGex3ii/udl4BxtA5Bhh NJQYQIS+HZK4z4E0vqlRe9vMkqLOkUxi8w+ypn7y958owmugrJsIl6HcXlZ/9ZvkYGynYExRCrOI LCET/kuaESW7cxQ1iqjnQfbfQvFF3hs8carq6sTNnFI4VENs4dUBOIXUIJ1xy3XcqlF6lRJEIkpQ STknhzjImbqhbNpg676m6pEcj0n2kLQngaOSL0ry+7d2rCN30pF+PAJSST85GBLUE5TxKBCG3DiS WssD+WDLRwIOT7RGZeGrWvhMEFyJEz9De1dI6MyybiExw5RnnXekvDFyj2BJmmoWeMKbxysYJ3CA 8RUsgjuJIIxaWez6niUxZmjq00xgzO7GSG+aNII8/zjwpsUfF1NoXtajFVNhbNd0YoB2a099JynJ fL4diC+JFRQREFxo5ruF9NG8jrfHbArzc9UPkIPTMee62hu5JUmdTQUAIueAkgKlZgIwYB5QdLOU AvXiSDwaAUYqRmCiszWs2hoWGmUJzOWyyDwR5onskSdyZ4ywgAOuM8334QEeqxabbCyWsdO4k9PY Jt4tDZSy4sSJEMc7/k+ILnuNFXuNHaB4J4Op7XqOdw8vAn5GbzSicDvZ2rQRU0Yxt5CnIsexCxRv 9fA9GhirkiW7yKMQ71gWK5ZFSNIxadUb+/5+NkKrG3UN36Ar2LR9WPiNkohfFe8ZxRqgSFpVFVv7 hm8k6/dEz3W9GE0napnfWiwZxeo1KskiaVWFYjaCGx62ZauMyVD6XhCRgK7SskJ8ZFmsgSy+1Sim O9BScVyJWxFP0W4xijVA8R1QzGVTzr9jLRNsYi8wJ2gaM6MYubEicvlnot1mFCtGkeQw81GR2USb LUAL16CWR5AeM4p1sItvlY+6yrEpY7b4XLQ7LIsVyyJx/whHijaGEnU9cmSuqOT3WU6MBxvtuBvk klGsgywmKFK0MfdHizAuyl/+FUaxPihStNG7p0FE28qgRlK0OY9ademPJJHkMAsVE4GkEm66Qn6z Rj0A85prGjvVNBK72FF2MUOSymq0NoMG027MwolD8OcZxSehmNjFp3k3H9hHrYWP2lFZuKd6N4xi HewieTawg5FnQovunIXDDAKWxYplkbJvX7wwxCiBey/AyOvpJm9G+6b6K3YGMIoVo4gab+bZqALx hhhfYzf/yijWIV58pyKNp9lEwlJ0OANXvV18l3o2T/FPGcXS8IuKeDcnEKZelM7+Fn8YTizFjWEH 21c1RIdzN9XL4kliF/vN29inur60mhcSa2ioPtX742ajnWQU62AXT5IMXF9j1/wDhWGUMrZBMNGo nIGrgyxSvHjdb15/GSroNkrf3D9lFOthF4U4OaZ6P1C8xWZRmrXcvIqnI+zOIGHcAlHRYT5qHWSR In+gCNfGBvNt1hzEQdKqvRWOjGI97CL5qUAxCRmbdzMfzKnt5DDRqCyLdZDF9xrFtOOmeSOxpsiN aPLaZh9HdE44A1d5Bu7k+ANQXBYzirFj3IsgdtZy4kSHGf5VyyLJ4XkQILIYYoAFxiDTpAT0/m7j 1yS+KqNYvV0kObzsXfWobRbDVGXi12yfucGvd7i+WLUsCvFB5W7I/plKCIvR4OZnjGL1skgoElvj CiOeAnmv1inuok9ZFgvd7RVlwz8CBkyUiVEgnj1Nq4rOAXqmePqon8yb9m+jGXpm0sHUN45hu3eY CkTDqdPZ1PhyAbZbiJ/Z04AKGq1Kf51HrBZmtr+9aJ33Wo0fYe7xlvOucXv6bhJdlN7iAc7Whiva 3zjzzlPHma+Bt27aaMOHubv8/sr3vmY8NHN4l3B4eZw521oE358afcwKtVEdQgBARtEMiy8tWZ+x F4eChXKJUEbi+9Q5DX0swv3U8EGBwDgZ2Tij3gjxUQXbNx7NGaO9nXcTLCCIxNdt018HcfAZxZ1R pGB7IF21enWMoA0Dg0wUEaIIU2c2p8BElynZ1Se+PioC4ZXnNmlOr2NjCqjq4d2MX5qEZhQbdUCR iBLnrtXEFGb6kmVQLsMw3pwEE10m1leNYrt1rIZvBvYoBuFsh0KQTk+LLlOyK0cR0xCGcozVSqAr PQFDiDGjWAON2k7mWlx5AdbL2w8yD6qWt3VfGcU6FISAIjmpl1je8iQcGcXqUez5PnbV2d9Fj5BM 3BlHjiMBTMU4VkO7aAMIthUkC2AWtK7ocntE1XYRdKWkxG4lsw8R9mMXyBiYCWOEkQhqoKWhG0OX RR+MYvWySCiSQk1GzGTDLbagYmtb+XQU15QE6pa7KZZDZNg8v/0fnHbLdbba4fsSO0DX5ecKDM/K SnKrPjaqzPWSrAWIHgmFbmAb964XRtAmW1GS+RQSxus3Sb9U6XUNzitzyJlP8BnKaCB9x5spA1Ji 4a3RS6L71DatX0cP/RAnoI8TMER7kB0oHyKkHIry9hF/Y1y24cxC7AJcchL4BPwkOmCAE1ASfAoN oCP0SsiQdozIeyLn0vZV7FSiidwFM7d9JZDl//nEru0cpHVbzlQhUf8nmwisvcxtvrL8/9jyD8Of RJRzORd9cEHCLBGwTOvnTwafgB//BKhoNHcCVFtiFpheUklzRVaIToLoclNiq1VnP4+knFr5C8Z6 ISZ9kYj5jNxMrB/Gdk3DDWniDpaebqdxRJfbJqvPQA7UOIEMRWpg3lpTJNqC2yarRrEXRxMUx/8m epYFVlm4e41VdA/QcFc3QnY5u7N9eMPs4yJrdD2RlJKRtP8gv8OyYKr28sHz6apB81E1TsfKFOjd BGmtQt1TWHJsu1CIhhgZaCcP9S5HyoYgQz6VEcjR2uLt/5TWrQpT1oE1AxApKzUR/tXguv/6CB2r IA0F2MkOBp8RLuIFFWOloQxlux7kzECGk1GseBgH0Lvsv4YFuENWMcjnoUnqKNWYiaGB7WLz5e7Y kcvgVQyeZYdmDB/SErarsDI9iCBN47AoUQyw7Hu3iKrlmTGVmhi7irH7c3jRf986+fAXZO8KrSTA Dz0kJHAeVhc7nmFhlEOiYTMJTAxkirYdMoYVY1hyXzz4Lq4XCSMJ7YThgCRUVqsO5joogWX0KkYv L4E94SaTGb3xovwF0gHDyxJjPQ2XLCFR+BjCiiEkH2UphRJK9Vaifp5xLxXb0hAkfQIYY+KDRM8l hh4xhhVjqOweSRRmpqDrIHJmYiTJfYH5UyOppFVGs5+g6Qoj5UcwiBWDCJECXBDHKUV1FAMuGL7U WCbO6lz37h86zjbVIttkelMKNIaGey+xNS6IkIm0LXCA01E7eBpAvod1GNpUOITovF9x6e3qLv3s Lh+KlwKBUh4t9T/hjeqsWeH+9pLS5WTZTu3mCzHdSEaPUroZQggcaHimMoZhsn9BqdBnEL24ErJj JWRlrloH4PBDCpJU1BToW05VXFlPUOND68P7k85FIz8JqjCJDO3rSl3q3stU1RQmkUEHTDGOYmq7 XvBbD94RjQmZ0IPF7+SmhcwvU795/jopzUxXlVd681spa2u6lS4SF4NBvW5FXae+ldIQrpdhV+QV 9JF4nNjmRKDEkSTh4PVQXhxEnxk9kN8Rh5CPy1nU6puC0gBS20qFkiZdUV1DcbMpsyPMCTkz0NKJ e6t/o6AT2Lomcxb3PUNxHZlWlQt9vVyTYouT993uXyRdiQhSg4UxwthH5Mml+2AHnkvKFiMeJ+h0 R4ljypWoqpkxWppST8jyVC7VBgMyaa6M4ABnP1P2p1gEK04AaBcpLeJnNYpiaHK8f5w42q9FtF+J y0Xk6TsZkD/sePczpe97o1EgH2y1n+cAyd2f57j9sH1A46B5MfwBGpELum6BvPNSpPWFT0v1H+uR BYVr3N51XXN26iYgxVathU+D7nm30dx875R1UKnbgRwbsRNRCHfBuKefyk0poq3APPOZBxYPhvOp cVh5r1sSfEvc62WL/ukFE8+V7pGQoM44cOmyf+fffbTFh+KrMRPvj0Sn1X6XfS978OcNrX7r8pR6 NmV72rBRN7EGsOtHnbxMgptmEASujJoDDL6KMvnLPaBiVe7p/OEV8jVq8S1E+KlzS9aUs+rme5QB I8mkEouvHadFj6lYBtc/V2cH6yA3WX/Ry5fJ8rSGTnXcgJV1SwhgIcArFvnyV9+t7urRlpz2IqOs EkhT2r6i6BnunIkZSN8DgQS+AMINqpshj2/gaboDtnCTexG2+p/DKhJu6w4adSCkAxFDlFZ0jSxB jiAjgkMx/1s8jvOac/kwkrY8H3Q+dtv1qjmr6yQ1qIr6WmfXgM9UkIdVn3JZYdGnXMfKvrrOKj/l s57OlolEUYVQP6YTW1wzrLpmCANnYbg1klEYZUHV3miCKnDkQN8UVc1ejMIv4Way5QvUAqYCf2r1 tNG5bujp4b8F7csHL80VF8yitpX5+IYP3k4HD6qvVzhpj6eWdPDBEsf6LaXoDTVq5FPjaz+I/49e sNDF9KlBIXiz3W62Ptx12qetj6et1n8nfpVGZRlUA4lsKtL8/fbgbb/ghhUYiguMS8VOXHh1zWoz dRu0kfXMpdvDPakn9Bh+VvJKzfytqSRimB1OFVkME5bA9hvN8ISCFu36YqwB7FNMzbrqe+RKuPcF BPeiK1iMdhWjAgZFbzkfIr+rLkReHncljPEtr/6kblevgn3E79T4LIUx9WIEjWgjKgSRa25uHi6W b00FMr32u/OaUZTVdSZqrHjK5rdSPmN1jcnUdepbqSITcWZhVabiTwvPTBoHcZK8ceHAsD59eSou 3JIyN5MjMWuofKdC/Lg54V9/S74qF/6+bsYGp3Kg8wT7VxEFXGtA/yDFrDlN+uuzy0/1P41V2KHl nhmOG/7NUwNltwa+D1Uv8uFBuVBju2hOULHch61juTbCuXIst8IZ2nvQtiJD4suAmsIR9JTFDjdY VRh3hgCMPv8kBFOFifLVPb9cy/LyzDhsns34+CwJWJPN6C5GCXsXDJ3AQH0sGc2FyYabCp10GvXv 0ePKEx9nRLSnMC2rhPD0KWTDXoR3s87EGObElg9JSqmgwtT5SQ1Iu/UTyM/yT0EVf1SKba3IzI1p u/2sz+LFrOlZIJEIccOpHS2kCaEPdKY2dz36pYK6Uxb2pYPAwkGE9qrQ0i8/NTrFNA68qco+lVwx qOfCPahb0MLU2f4AdV7aHaO0koORWCn5+eICYweyxvjkGKzw0zAZC8PImzp0X+2vza1yu/usT6Jw TtPDO0iKDC9plg0M7EMP8Br1gRPM3iDIiy/Z0I3oKWv1pTQ3pBTDMTFNQTVxQz7R7I315DQvJZla i6LLapHdvhrWfnGRJe9urWQelXXRMuV/AD2/jS45o8Z7S4B7oXh75IhoDZKGt6/C1wVcqjUHZ8tT kfk01jwXnyaxnsPZTelUqXarYWZIhRbZCQwqH0ijPnMSCVXpZbX7wmr3N6ygbQ69mArY6ZqZsvQ+ HxPOllbQEajNDL6mfz0zIwVH7ACGRP/pdQNcYO8pvRCiAwy5Uhq5A4OeTkMrZerEN9d7RG7UxnDl Ef1KkMa/xv6PKufwds3h+ZjzaJuxYwRiAmWCnj6b3GthxdlQUB9pMElDQoG0geXHNAhLTWtokvph EKvPKmEF+ZFAGIk0OU1GEipCEo5nGo6SPkda6LiE10feNyGueBvKE2dWU7GuW50+XWy3IN1P1/Mc j7Z2bf7aumjDtpebZL2/k96/1gsrsNdHrQQCbQ4LLV5d928Xoj8+gQszj5cmv9IXh4dgSOdyeO+2 z+F1VTYTtHiEZ3uukmnhxTvr+66JVzrMivTE3i2UjNEERP3QWPIxE1MDT/B/xE2hOvuY+mkG9ogZ vlShqLxMNqcIhuSqZDmqdMHO8qwQm8kgB56Wy0Poo19EnWRmMlEqsI9fhmwff1ZuZN0s2WWynUMt /VYN2ikJah0JLZ8Yz7dCtMuU+8qttZ0ulwQlvJBBKBLtC/dQIUn1jAJnOApBdFS4Wg5eXpqrQDxN tWfPdmOVhKK8hyyttiweonmFqF0+Qjk6Rj7wr7ysklwoThfqKrXysQunf+XHXNY29DG32yct3Fa9 PuZCh08VBuCMcqqYm5JviWF3l4uJmmOwb097XU0nGesDg3wFAkdB0Pdi5riMyGVEdLOrahJKgI0z ZcpFbxlxqHD6Cmy+HZor3r00m4/s9VpqUEq6STrLC/eIX62QdXmGKlAoYqyhVsZIZ4cTliUnWzji NULTtheGQjxhVMQKNitUAayPM2Uuyz5KflwN26kahsO3NZfF0ivDidSiyunEmiir8ufXzBjCXSFU hGNFMiKGkZ2OqUiZSWzD2Ia9iA3TyVkOodS+CUr8FBkoRbYNF6lAtbuSj1TUXztia7XfBOu1NIS6 l64MwOqgYGOeUUpdeiFe3U3QnTHFnH5P9dJEKufCNO4shHvJzAswJCTQ2UQMWao16Io3+AmKF8Zl x60NWLEnbZmG2VcmKkfL2aHj/eTwtBzO10GM57StdJPzsqNQNz/7qQthliyr3hPla8MV0XKy/SyE efvUhTBr4N2XpO/LGGz4MEluKYG4F/mt29HGTansqL5JPNUS+YJshDNeikLr5xdyeWu8Tw3YXk5l 3SSyfCr3cpMsejtlb+6yGfD7T6TxeeOq47KqYzYXCQQMPV6kcPryA3k6Owzk+bBYdSyYt9TmpVHK +/7bzkmnwIrZk9+mFVs2mGr5aBW9+mXpeDsEOPWZ5U1D4KzA830aI8tJizrQ9AP5L6mmos9r+LoV GPPHSuK0ipvaaVc3fPRsbnqEiTxZuiaG2lxtYyrRLlK4CXYOKqF79h2bFlSB6KlREbfURY4uZa0P 9LFTbbBz9EQPaVAuz9Wgo2euKjRUmAgQTYThYzKQH9jUfyiDABjroYthQfRWcU0XtAeVHEA2Hbw9 KVjVyim9yYWSVa6K0kszIS9dgU0dgZwegODHUc9OUQ+S/iamMYU48LpqSKn+UBkiwwk9FALUbqwi VHk2XGf72XadpBu0cPZIVDrdbu/9h4Ko7N0BXVW8egVpJw2+UNyokAq33EsGRumEk8eJVGMUCsqJ /YJK/IIUFNTIssWitOkvi+cysk4Yj8e2SU4EWn8Ny4KJUZPoGMQatPpqtmloStcIbI+5OluXOgvD Bn6JTNcvcZPsSC1zpM668F9vPSdWHbHUm/1gy8f9q3A+YpwxLmeMiR+c5R6ysQD5Dm1M0nmQM4PG pL0aXF/2X2MSV3pUMXAEA/D2f1BZTSxTEysc+NJ8Yrh/tLteOfXpuLQM3yQKo5nFyS6UjIzFEFbs Ls63WdDYOs8NjxAjqznTR9mmb4VrtqbQ8QyMOB6PJSKEdMM9o1gxiiVuI+V1MafJmbLj/zTHn+3A TnZgKVs6jH1KwoWCbDfNraf+HnRDgj0tGuo1sgoNeKA9d8YapGINUjDVSb7UjBKwMqz+XwAAAAD/ /+x9a3PbSJLtX0How7YdI7qpt60dK4KtR7TjdtsOSd19Zyf29kIEKGINAhwANK2J/vH3ZFYVgAIf FmWQxW6lY7fHImVbYFbl4+TJk7telPTjSRAl914/jsKkyHe9PMw+hxl+4yfB37+fnhZn9N+M/zs+ +/v0dOzhyzwKrt/udLtXve7VQXfHvPQxoxcvLrpXb3rlixfhwJ/EBX/7wWH34NK887H2zfw3f8Q/ g3/gpniIQ/yVn/347c7H2I+S2/BLsfM9vZmp78muUvy0+B4/70fR253zdJJFYea9D6f0tw97ST77 aj+3vxF/IT0a/Y3437H+m+c+yxr/aXzE3pdRfJqP/X74dmechWyCnTPP8/x7Msorz7v48O7cS9Ig zD0/C73BJCuGeNwg+hwFYQA7Fqm3cx2O06wga76n79wRE9aPoyMTwip+vzLKqx3P63lZaSmyKb78 1yTMcZ5TXL049QPPv/OLcATje3cPcguNR3FkwjxM2Ef6iffBGEjdNe/Fh5+uX3qWhaan/XREprv2 k/vwpvCzAi4lCt7u7B9oH+bAxZzBQaRJ6KWZN0rhQTJzKtmpLHmAyyRY9OOT+z4+PDm6OtypW8Zy 3+f6swgHYRYm/VB/Apb7vh3iqL/dGUVJmv1Inrt04bPv1Hx29UGbv9z6QVXUgn938Wm/sj5Rii70 CX1T6LQi7RaGzlYeUvIDlcNYx3xxfkCRREcXDiT4fe5Nxikc1U/XKofzxmE2SLMRkqUhYgr8l0d/ Ik04k2j/mIoFV7JgEoaUwME7DybxIIo95HW16F9mBipT51SPv4Xsi7ywJwZ0nBxUSTffwJH/oLO7 KpnDdYwouZsm3l049OPBLoVhvKq+8tKBWNGxFVMup15Ydqjyi5lE7tBlIvcwjvp+HD/A0ecF/P9o yU9dy96aPzNlb6+PDo72L7cse+Mf1Gn29lKV2vCvP0WfwmmUh4BDGqEWF9363CX9WQ8yswwe0alN 5WmrsvnrPtfjOy82dOx5H+1zj7bC5waI4qt43eZPTV53/4fD3uX5lnld/kG3wuu2fyWldNbgtkDr 1N1gaL3nXUT+KCxQD1Pi/l3uZSm6Dj7K4gpt96Ic2HoQjoEAEhibDjiTN3+y/ZMq1fNK1TOZDFna Fcqp8Is/GsdI1CyjLMnhjx3GE3OAvOswbuSR9k9cy9+bP+/WRhL+QV1GkgXtNDQ0vY9Z+uXB63Fb zaNaHVgY3Xnqr1kHR9L5zafz3IrY9YBRJsC40sn9kKAu2Aj9iiQtPDjhcYpWJ/lkBsHKa4QOTR6u AXMXd7ySO74BShlWcTVM/LsYHeu7qBNEWciosx97/ngcA8FgDHoXqDQaQ+WfkTvouBy7UfQPr49m J/U9gXro3nSRTv0sgKs0adO5oYxYRpueBmFsGnEn1MnzJ7jM6MT/fJ5N/k0vBOhDoBva3Tvs7O11 uq9v9/dOD7qn3e5/qZpobsNOv3gRghOCEup8f++1DVxZLUWb6IE/uzIjhJ+DeCdnvncfwSXRU+LR +CX6fcasEbxCnb0I7RTd5H39Tc+8qYcrzmCUPLRMh4fCc3Ard64J6k3e1j/tRU0uc9yaP+m3N1TF ua/k3Ck6W0awTv2bP8mpz61H2MoTz643GoEy5ydhOsmB9OsslTBoQ/HibhOltA1geg1ZkMAnAp80 mYn1xoh1pez6tU5/Ak9UUTi3JrhkVH0vAwyq8nvmh18QqJ2Tn9QPqvITR+QnoDFjrrOZvlovsxu+ yhtk6YgqOesE4WeX4E5U543lWB6RhPIxVWifQwI5TWdZ9UGZC85xxgo+YjyQ4C3Gu5MEecZ4VYtK t7Hbv12SEUhG0MwIaiMKQcp4HVDWMEOt7yXh1BuFeY54kBPVre9n2YPqslAILkKZNCmnZhz5kCgh kiiDcmioXPvEh9pV8OvOOLq/f7jz+592lM1q38vUC/ReopxGHNp3NFKjr1SjG7Ckum13DwDLMVDE Eyh0D3u/fiT8HLfQWK1E9J5ovsYM2DaPe01Pwd0ApUvVIR+z8yFR+zRyd7D3eAzjoEIr19MnoQTe /HwMNLofU4v9vLgGJAy8PvgIV/4DuIef+JNchN15FXpMSAUm20BNz0MiLr+nCTXqrVMnIPTyyZhy Sw9OaLYXVytjqOo6ujw+eXNBtuIxRJWB6RfX4D2Xn5n9rT8zNMKpM/ikfcqibYwtHEupHR63J+Xg z3BSFrTOPaRwPKfASd7YzxRzxgZTa580XdMrK3ZvQaFkhUKa5Tv//Ua5nTD4/Sr0iwkcFMXHJ8bB JWPPz6JekofcgqLw8eBZ9/XJ8f5VGUa3O22Lkach4LMiwCDrXF0TlKxyJP5f/clndlKgH3EtScHS n4hi7v9JsyEmbhMQWkAxipHzlL8uv4zBh8i9n4E+n+x66IQfle+Vv/kn5Vje0X8/0RstMe+2XdTp 6dIPk440JdmtHO2//LMviUJWQP4zpGr6WdZwf43roIv6LgEJOAmLzkXmD4ry/tV+w1lP7evyt+8h 2DC6A4WYyCxPvKhLDLZth9V8aqvfyOf+kHL1VsKxXtwotqB3/Gr/ZQOtKglpTUjBnsS1a5PHx44l J1WMuJIRmT5Ic+rQsKmBkB/OO3hR4ZA1Ox+8fCUOVDS12pHzWjY02lN0TlLIUFRk1ZNCw6MEwoFU +vHIY3ZVRVamxrhwFQja2UhethCKajY5YBS/4J5iRJBygUrr3WCWrqAh5pz1j9p3NRIcVgoOsFnC glTlVfse0H9tNADihIWmO3KfwMzggQ1JTQLI3gzFiI5vIoTO7qKEm8bkHEtT1u2I23gTjaLYz+IH bigDd+2UuGtHbOjYhnXguxkP5xpUh0FMY/XjNJeuv/uAqKk1uGm3QxpYxhwsRUIOiz5zwJiDaXqs jGaQDwU6KdfP8fWrRTzKNykI8q3b9e4mBbOofIw+MhmH0lEaWS2b5kE0YFXFQqzo2IqNtmiZodQD IZcTyqPS5ZsOo/6QchyTl4oRt8CIgkGIrndLkuLLMIjrumpnbiQ65+lY+f1+mrH6MBh7KJn8+wxM jA5pfIrDcOwwKrUxP75Ps6gYjpCD9WCkUr27fKM5ZVQNDB8cPp4YdFTRDk2nm9LPNz9AVv8HS1Bq U7MjlJA0D6LDIeKzIBxEjbS2PpF+cPRNH7Y17aEtoCfSN2EDM37OvQ3zBX361ix6gwThEqwjUHUU +gntJBCVU+fIqXVR6+PbB8ffdC0c+6A8HfHUmvV4uBUu/RCd/IonSZgJMQ6p5YAqjt/M0n4YMOWQ OprgAwVcNpgVEM2HkZHIDY9ElkHc4CpB2p/wSg6alIwGBLH4HgFgkI0bTfKiYwCWMujvihEdp2gJ iMroGNCF2wFaSTtxTKrmlc3no5cw8dWE+L+etq2WJyK8RWzo2IYYVsrSYAJlKZpfKu2XS60utfoG avVy5U8/xbSS2pxBVc9nHzOsEKLL++l4RoTSBAZxHo6dR0kWYL0cstsdckW9xSkMaAWehmL7ft5c iyTufwsWqAEyz1NSEoQMUoGlaOOCRsib2nRKzd3DUCEmXZW2IC3ZsO6fVfFY0nS/xBmh8b9F4TCk SshWqNvr3u4dnR6ezAdfusfd3smapeiKs44XoYQg3dLy9HpwSIiMMYkU69QTNUSZ1fSIOjnTX9c1 UQ1+svTqHvVBvHb4QSxgBVl2dlz6fY785o8jxduGize1z4XvS47k/oPSi1WvgnkEv49yHJcJZXeT 9adihFjQceBeHKPzCVy1DgVQ3UwnceAFqTf0M4LfuRVLrGOxoGMLDn2ISfkUpfohgjYgsB0lX+gV D2OE2TJSHb86fmmEgKlSp7cRyQnIFyu6ZtvybaNFZZ+jNCNfqsYs2EhqGTE0ciG/HUHqGe8yA6lE ysSI26EQVrt3uYUyMzBdgl56+bdSi2CGmC6UpHnjnuVXJSxMIhL0S9CvDaBfPc3BJ0fBcRmq4QVX nFSKohAv2YgUuU3SZrsVycQcZ2LQ/6K9v+TRyUo1zmknCkoL0u/4/SLzk1wtCUZE/22otO+LM7Lj SnP4Mks5s4egn9sv1WQslhHGsD0jjD4TjQJhgNrI9euIeE2kYai34n2lC05Ta+hPmvsoN9DxDSyb yeQyaRE3udCM9tZT35/dKK4eXitTZywlIlfbydKJ6GO6z77M1LkpcWAqcqU5tF1wFc27eA2mpTfs +/gpSadSyrouZadRHFP7h8NhQFPpPnF0iqg/wXgaXzeI9YDGiVgZTIBDpGzKMaR6MOzEFCNBdl0b 8aLq8HR+pFwUgm28Tx3mVEQwtl+cYke2R/cuDgPoKGEfMF1LMjcurMRDx/FwxkWyX226TU5Ua2lM jVgt9HfnbFJeIFVPUqowqIabZozM9xGQvfLDcgkdX8IqDpKldJHIGQyEwPtDHiENvQ9ZdB8lpa/l yoMTHKpIRLnd+TXU078q9SRKgI++CWqKmo1mKkYBDwU83CR4yMgh10mkq0N8la+ih3Es8WEj8eEp su4qVpAui4KeYNT54KLGD5EZzOBXYt6NmHexNj9fSu4lfR1ArGXeFYAlFnRswa8BiGxcjSCWybmN YIkNHdtwLoJoNp7XEGDaUq/oFGWfBsAUSBmTpwKLSxSit03M7JEK0bUNBNak7noFhBdQUr0m+bgx l+tUnJxGE+8zfzx8aiWw5PBsm2rxIw8PmpuPpOkuefa/ysVxejjbUc4/fqpyvnSt7RY15iGWd61F QX3YAwFylU+NnM1qOw2WnMptc7hEEzEPZ/6XQvC4rlnS2BpnxWvzfRfhwMcadOr+2tuEZHkBfa7L CCO/DSOMpRMvxNrZS2NTOcGBvIdzxw/+1+8DitnB99X4I/ku00iemlguOarbFh+bR3XLMkgl4YgZ lZqlCGhRenOTbJximx6LAkIkkFrbxqBqs7Z0q513qyO1KY071Myro+u4W9+3jXrcKsIRbdMR6Uxc 027Km4I61phcDN7uHLyhrUdujujZFY5d+MWHtmiIh0nQUc9ESduKWo6qzHLCWU27NQ9TNel52H28 yM+iEc+jk72TozULjZ29sO4DXLRDIZ/5xT37ZeunrM8WH66wSNblBz3/2Wj+EXfberrKBlAd097o cIXVp3Oe0ro6OuHTUmrdDZwyrZ42/yMIUn78rVJYO6MIbxSGKP5bBrKO3wqbRucYhrLtTVigOHtp PUJ1xhpAmU4nnbhXugy8JxvJVTENQ+p33YP2kDR/9EdCR5Iar1IlLytwxn4EBXOi3poCh5TVmmUM QPM4JdY80XWRLCsJBSiu+rlUN66T40lC/MxErYIqhmC63w+9SdLnpeyBjUzbWfElTL0gJyb3dXR5 eH7es9KUm+IB9bDeIHquE2zi3xOzV6fVlmbq7TAchW93RlGSZj8SvEPJE+M8s+9YQxwmezd/ufWD Ur3pKoWfH+toZJd4l3SL9FAvRFT6WXQHEhEPBEVyU1zflHIqpI/xn9wfkKYduTA4NXVrkjQx8oM8 JERCMTSszePYFMSQPUjIctzqBT5TZJgrIASnceFI64Cv22CeDKHtCuFDvj3bEMx4C5Z1O4JyDl7t wTV8jO7vH+78/idyGB+zKOlHwHbadxJy0p7tSVuUcXDKYWZTSxkzDPI0KC5EFFVau0qPFRo/kJS5 QxnW/jGVzkTmvQ+nlApTkvq1/hJyxOieeeYp9R3GxpkgitGoVTqm2owrZ85Hals0NV99HfKtYsOV bKi2hVH/KIAFoY5MGj48FhnwxpG5N3TXRgYt4GmFTRZv5msIXu0fXZxcWJWbVZXNoAcrd94XYgrR K+gXNf2KQ+T5jCY4qmXJzZ/s21NAuS0r3RYj3G+tr6xvTwSLGooLY1IIxugpRzNIV6elFxQLOq6/ CJmBFTGACEkTHpDCbiUMd2OXEvs7goXIyucp/CH6nZiC816cn1/N4NRy9zYs52lngX4cQ04BXAe2 GonC27fuRR6G3k0IPRSkInuvDl4dysi3ewWNf15fnR+fHBz890uBM2T6cAPTh8C1wZxCDZmkvDmi IkrUqhEzUoE43fczKPqbpFeiteNonYWxD+UjTqQYyYZSM9reKrGiARmyV6RQ07LQNDYW6zm2Xk1j Dhvg8hzkpHVU/AIuCriILu2YJJqgcbhz5pFAcZ3KXMobluSZkkALxSCg3vGE00hdbYvjcOw4biZj akVjx229tuZJc6h3aaG10qWAqUbqJBwouKsW+w+iSeJckwQ3i+6TxcaRrF+y/g1k/dclH4yUUEmi IojQPYK+kXIs3H3nRFLcv2rybBHd0vOWu3/oEk8hzmgSSvH+aorQDY9gYXe39P4UyEtN4nKWCaQy BbqCjomym2bU/jWBqiNChi8kJddUM1tBbGGzAxV509P6cZ5K+uw4fVYFDaazzOYORTTLvQltKuas rOopclZtu1TJ0iRL20CW9j5FRsYRgeqE8rCajYZ5Gk+4exOkSOFo8oWZP4PoC/A+JT4mnsaxp6FO aR9bBrAGBEsoge4pJjmn1ryEgF4l+D0IizADjx6mu8OOVUUQGq6BaSiEhpUIDaVwKNatnVJPHFdR LQgx78B4VXb2ggkyLNyIBE9Gy10nalimV8M5d16iGPIwHaBLpNJaWuder94z2fjOOpqwcv9Wun+3 1J8EGI15etbRhB4jkIrY21FetaPi3A785zhOH0gRYJfzN+lxRduxVe9cRb+fe/9ACUu1rhcV1c4d 4jWrffFmkYQxHLgpZh+TZDHOs5iHagGwtkuUREXELQUTCMMvaigROU4Pe4OVDAYxnGk7pmVDiw97 9GjBhcP9rePDakZwFEfFg/WIZlC7lTkkiRkrxQxkZFQwNT2JRtCYag9f1PEn+C5st9ZjE4MsHSGT M3+qaU2hM26YzqgCh0AtArW0BrUsUXE/O3i1j8DFhfm5P/bv2KUjkCUphu0x5Z6sAXUXYo4Qc5rE HBQ86hSW8J7uyaqgZg4m83O0bprSIUQCLTHLcaJconheNPBSpBeZtg1rRNBmtWJIGXEFGJmGO763 fes9C//y13lIkcyelQd+9OjiVwTMMdF41o5k9slTJbOXmHfbzvBXPkwqalfTLH7Ozy5yZjMDySKV 3vLA9uo3csmp3DZvhIcTqXTHma2pRriBDYCtX9XI+Kq+Ywnz3Y0quv3EVgDRlQDROorhvbg4771E BxRKWrRikJbcgGbC6KfBPr0aAnJpUP32rSh+RuCPufDHeQ9byjW5aULi/aiOSeVjPu8Zb6cVg30t hbT4m5X8TelHSs7aIPSLCQjNZsAgbCiXttImE38i/mSePxlEGYjzTLebweHKo1rn15tTyo6n/bgn 3mQ1b0ID7WU8gNhUmIFBsigk0Og7UYXofW1TsaDj4kEzREztoOn34E0mJm6TCA0znaNSv1+ZOIbi mtjPsf3KMO7foVagXqjnx/eYKi6GI3vfKpUUlhglyQyJ/Rzbz8g8Hb00VzBMck7HzHSB0oCBlFcc +oiVtLqIhMDSJJ6hNQkRZsNEGN0ipJkAM6807x6a3Rsq8FlThSj25Q46voPKLDUyumWR6WltZ9Bx nRH5S5xF/aH3WxQOQ3o9gAd+u7Pf3Tvs7O119rq3e0enR91ZYuSy1UHH3d7J5Xr1Q81aIA7e5gt6 ZGx2wH/xypZteGhUBrX0UShoQkFrjYJWLBwIhygP4+ajCQKwoYVUYw0syIkwXRasih9JSXTwfZpZ 3qQVNEWq1JWqVDKf4WMpijyG+qCpV1tIRj6FTWyKWWRj76jukeUxzsV4YL4cS379LEoxaYQhFVys PJ+MkHVxjlzatsdbY9SL5pYaw8oldJxkkRVN42AaQQoLW7ICDNjOSZyJQEl2w1Ig420xGSAWdG/B 8qqxNlHlI9FzJjEU40R5k6vHVlaYIL+FLpHY0L0NdafOMoU19XVSr3F+Ps8m/54tbrqvb/f3Tw8X bEHYv+peXK57C8LZrE6e3nZQq9def9OzLCnUNvGIpjbTzs98SZZzXqqdzcgbakSfsGGAVTq/8mNM eQcPvCPHjxLr0EkqrPXLWiacLdwQghCMXwAQMYcdxjFN25HLVrO/9BX34Rq4o0qLy3fEgu49+PL0 STARwUQ2gIncznqOx/Z/sf8C0AgpIYo3cexNdPsXQTs1LXkdwL+uo0ft/DU4GwG3VgK36B6SrdD5 hXbHYE5E/y6fS9Aj88n9c3z/SnVfSsTyEO3dQYVVltDILEWPttzhj7Riv4swpu06J72Tk4Mu1UtZ DoGai3DgT+KC3rlq60qigtHbxA/fPLIw2zNFJvY64idrOVWmEmQLRYQbGfkUZA57s1+9Xj9im5Fi Rpq93VlSr5cfpdXeq5meX99wTULnfpDSQiwqQJrneaagP9pb9dxYD7ukoNfHf62fga7g5/eZiNhB z6+/6Yx+777Mh3JQyCsBLdNY52//m0yysfN3dmo9Aj7d2dN18E2Psh2n64xzsgWniBweHfGxcfPs 3y129vXXH8P84XqMsP6Oj/TX6jE2/ueUVxnfFA+A/Kenn32EnI8xEKHb8EtBO3tx1tX3VDHi6PHr WDXLYq0x4qkf3Voi6foCYe3zf7z814osF+e+FjDY7VJfC9egM5Uji/KzNLzO+xQ2595mRHC0e8vM bbXude3GtX2WaJ5/FhwgviIoxbSuCLMmNr2Yheh4bQ5vt0AkbLrqJzmtP9nNc2Go+akIocRL+IyW caxU4LGto725vDi6KweXh6+7aybAFWe7XviZV+imk/shcQpG/oNpNXsjSJpSEyMhqNx61ipncGGr M8MQBgGC0uaK520g++YPK7dmDTXjsvZKo3DD+uyQ9jUDXMOspJcP00mM2d7CA1gD/SE6YeaalWKr gqhZmaPOCtcQoxa6vsb+vT7MRNajK2fgmq/wvUXuy07/HRhxjKtIS1aJSzTGoFJ0V+caqXvKBE2P SZ0zBhZXWq/fHBiw9IzzBiog4VZk/mAQ9dG1CCZqUzrxAvvFBN0lGYxx7UM1GURmyQlKfyTGIuUK KtXl8lMLYzYqFnslDw2n1jJksyadR0ngKIK0DwIxhiXJaYivd+zrYb28wPAUtvDAHLODrCh8engD vj5HS4oS6HKvEjmaKJsp06Ty2XDlAxP6CdbqcCjOqT1prXfJvTHo+6B1p5xHZ2E/jMbc7awVQXIP 3d9DlRm/sjtx9RHIo8dSaoHx7K00+7gJ6Ee3RRbEETqA+ju2pP12Q25xMAFfatYraqIO7SRTeJD5 FrlH7u9RnN6jOMEAi+9hhqxIsweidui0uFoAzOvIRtH9EEvoVCQr/aZY0b0VecyFgtYIrcoC/6/y FBKx8YPPPrYPKKsimn0m/kItmMGONOgvVnRvRdhPiWrATWI0gYC8El0wSBChfHdQgc/ScZihU6Wm 00QKTcrX0w2RqQlb/hwFwK+8hXy/ahgD5RDQzQqPltka55Az+RXMOF4pPcXOr2EfYZ9J0rR1Df3F cOTTTiuYLs/TvtrQxtw+/Mn240RbhJy2Wy/EoyGqTyt8GnnILdCVFEtqzrRi2BxedS976yVSr+tO 4jlstpB+ljWzhdrZ/vH6qds/lhjsr+NfnsVDLtmc0NYMw8auXo0+u77269k7YqIkYdG5QD+1AIo7 84tlcWZexQvvUUSN7sBjIcUzyV+e1Ob76/gXuXorrtJZgEF7VfXHc94AJWrNS+uaWdTLxw9UHS3Y 1bwJ/H2BxhqVTtajIaV0SV/GUAIQI1I+tiRzNeIOKDBLwTpZQ9EmUSrz3odTmgjBEdBxb8GhQQii c2PAkjUQJ8U7b0F1OVOTbCQxWuidb3HksKYHLZw+MOIoHykCoR/nackgp2NpJOu8KVaNqgadmu9t +jmhKmyYqmAchjEXdATVNDUQuiRAPotGXbUFlrYx4W2WNMup8QPjigkdN3Vml/UG0WAQZg1FOugc 4SYqNTrLZvXM6dian36UpvPrWV4DcfwuL47O1y97Rp0qdK1ifzb/mBloPbbGpZ/6bNbgmMaHLpRo wCYe2TAyJmMS2P7TqFbT0WtL8tD+tA1EVx+/bStxxIeNvz4K3u4cW3Pdjzo7Sg5wrVO4W5YNaDHF MDBtn8Vuxpotf9TH6dTNzKx2cViPLUjGaJ3Q4s/bmh7fyOe9g5tjL8VWk+2xD2qIHnoPws7FZaO8 OXsxHdIiAdPNVeN9i9OUIJ0meQF+5agkC7F030tIrkIpJCIhoGmyUPTHW/Gf4/iJ9SQ/PIB2SyyX HDrMVWAt/E96DWCW0oyNSp6sJRcvFMuC/myRTv2MRuLgHRc/ByVdmqmR+yNkzxH9Z+4/VFvb4OHf 0V+icv/w0zVtPyVqDjI8XqI5GZcfW/3nW3TUa77QGoV/1GGaI426JXEUdBgshY3RnmYrjKIvtP+P DEdGKaaoY0LWkqK7ZYIv/b6mRoKvnkPdUjsBlgzAn/sELHCnIOFPeAifroteCrnkCLiJxErdpKjR c7/9HArMIzBPczklwMVbeENF44XHDEL0yUYRNJrISWrBPeMzRynKzwjXxlqEa6Umz8RhNugDbqE6 2PBK+TG1eRJp0aTopINO3gfLk0eDacGHjfGDw4sR/Rzb1tAOlUFu56w6GDEajWNebegX1JIJwn5E vZkcaM85sSB5ght9MkoQE17rggsrTRoaPbVSzvWyeBZmFWRBYhkQs9q/i+KogBAQFrigaqDp/FoV gK/KFJ1pB2rNRPuOVCL+s434ZwevDuA4+Hh9MOor5ynI1+xcrnlqA5WqHLonEVrawiH/WjSrhb4R Y82M2fBxPPfHxj/2kiSdYLyIZtR3vc2eUzHhShwESMfkXhJOKcfMvRdmoe/xq4OXNDlmQD1rNmyd ak8S255tbFvoZqiURW0KSNRUQkAAwwzaOXREfUyk1KTIFFiLGGn/qfYDojialRxNKZ5JCETxgAqW J4oJyd4FYSHH/HBIE6nJhFi5CqKPw+QeLQHCdgGhiwkd8xbK+VN1xwhngBRyhGYHNTzM/H5Nt8bQ Dzm4CMNNtJQ2MYyKDhC5F14nMjMoTYBLjZDMAJpRU9r1hmkuI+/uxdcoJlBQD6hBHFObmF8RByIO ZAMOpKfPG6cdlKeQV6BYx2on9ZqIMpnSwzBzwAQ8SVUcpyrWql/dKwGXcjyOoz7j8B2kLaa4pd8p 9kCGxW5KBGwNzkYKhpUKht+GaIcoBowWp6ECkGoBcympbig5M7zjkw1MoV9Do3IPHd/DqiqA45yS fg0cab1655uH10wSRuU8OdxOhm7n7I7kb6dLyC1c6RZqzS/qVhKgsvy61YpAdDqx0iuXot11Ol27 TLAeQJYcubVibFL+Yhv0U5JOCdPHilN0pPMwI/LhnQhSuzYiWYqtAQ1ScqIjv+gPEefo9Q9ZdB8l nR8pSyVOMUVINqzmjuolqRIKHYdCNhxRryDER8h13UbNzGYN2ac0VqSx0qQJXtfhFa6OsJeV+NVA XXQCVsUMYrsApx+Dv6Q2FxA048+wzyVDW8tAaOznxTUPeIbBR8w0/AAjfeJZpcXz5TP17QWCf5So +lfZHgFDfI3AahuA1UpqEg/7KAFIKOKPwYTk7TZMptM0ZR61QXxMQgRK9juSvTjOXqpFNZRfqu01 uiYchaj0lJ1G/idlO6rotTEV7TWSQOG6iGgQkctITo2WIBwjuJDiN+Wlpj1vYDQkAdSBkUvo+BLe hXS77sMEVGSAY7h/PdWdUPbZZV+JSdfCB5NiV9Xx6ruxVQoVvRjQsQFL07FmR+b32V1OCtDK/638 JLwromI6yfoo77WofqnwQViO2NCxDVEgKXl1CoOmXaSGAch3lp2nWrOJLypXVeJJt2OqgyHOyjUi NKLtp2Kf3sxnur0j7GyKMMHDjpZZCWg7STLjOpnJJ/2hjnDIVtDUpQhnlpDgYirPSheyD156n6Z2 NDCqcFSxoGsL+rTTtHKmi0EnMmLdmbYfAZ8FNvrXecju65Pj/SvSK8loSnAdQkJtDfBMT+vyKYOs c3Vdl0+huWraJjCjRqAfcQ0zj1/5ibAf/KwdQfM3TxU0X2LebTvDX/kwjXkfPz7/nJ9dNJhX1GAW +XNbr4q1dxEVlmzhXf1GLjmV2+aN8HCsOdzqQwpfaiW+1AeaYSJaIgGmhNYxL9Fg4ZqyUfU18I3l Anhgr6r23G0/wxUrrmRF7GjmwVgGdD68Oy9nRnhKllvkZF+Dl1cDscySw0ZT+j6xomOkTu2Y68eT AG1EWnqZ5FMIJGtClCb0g9WQhbH/wEQ3zcrRd1cM6NiA5DtL4qnlUA21QVHgyj5VRTf24/s0g57k SIzo2IjMe0M/GF4TnFK4VZ7aNhA6dRs14mqHQrzRlv7wViMEzaRtBgpwq0I2IxGcU2zTl9Ieyjem 7aej0SShORtpOLoGWaME9BmwhUl5zL/DSIWOcMwDx00s75ywwIQFthEWWE3xON+FYBoOJg95jZFN Q3x5RskD3TbMbNeYYhLQHQd0JuRhkvLB0PTmZF0U7U1cV83VMr8W+zm2X5ktK5BCx3LN4uMgThbm tK2yLBP6iCMGSS+UvWJEx0bkpuis5Io2ZpzmoCrMvk3Tl5X8hRjRuRHJHml/QkJ5lfjaEdYVeB9g YQxczNowB6MhoVJKG1Ks6NiKQJbKjYtc5paoYZ7G4PaR1m/7RpLmg8xzNee5oMdJZ6+Eo+lLTIvG oc+YC72nGahUD2o+VCMdaP+kSu9hpd4DLWa8ByoGYzW6SOT3ackf63U2zKbIwjzftQbxXzHhSia8 B5kNkuEVuuJFaii7vJm4hzSGn2boFSHZjkPkayUWg++WW+g4qFt+lDT8M1y4SgXDakbQnSRmcCk7 oy+uGNGxEVmc2veCSVYOV/wbSv4ETpgGkoqQZO3SoVaXdChEb+cbNAhyUAqjgCZMzjKnLKLSNkmx 8gbBM+PJUQxItX8DJe2WtLuZdt9yqlYDtiGBi33aNdIPtmirycrSyajUDoXjOAK23f45lYxtpYzt zqe+tB5/RVvzV9I1xtBI58LEDnQ9jUxg04gYoBUDOg71eZGOkYN9rS1RXkT7/kmgkO5ne91PLOk5 BILLW1EuvxQhKVzw4qj2vYSkI5KOzEtH+OwZ+Fl1ffLonnXHmIalAWuM4HHHCLmzeWVNB1XykZXy ERikTEnCLxHJNt1Xo+XqLctiYLUScBjlI2k2YCbwLerWK8s52ssE/wyzg1vODETVA2KO2mCpR+SJ 8ke0W1JgHhiPgvaXAlnoW1HvYHM3S5fcYnlp+wFR/MxqfiZherzqG3FDWS0ShPloKVhZ6cwBXMDe AmwmFnRc+MwaTZc2agkKiTsRujn7bbxGmC6qmNCxCcuBlDpTbradIEWqxPX2itSl2/bs8gHAuwoQ AMbmzwOw8Bj/Id55LB7FsUdBg6s2heHlkzE1LIFwDtRGedPILDUAzevVt4oNN2LDp+j63kGlGSG9 vG+chJuGZrnMBpf1Slm78ytybrAM1OAO/TEx7kaMu1iaWdfuVBuNJhDuV1xOzrmxUtEslycrzzej GNCxAfny1azIHb+h/1kRt8wibPhhP1B8LZoI56kIZVMxoGMDzk9kdompBZNxFezH6PjNm59DaSz2 c2w/nbGofVL/mqCLLnQPAT5PN1AgXVvaLjmNtHM+hkhtVpQ38m8Do4nTcOw00n5/gr3x0OhRFRDa LMTrIGI1B3BM1XBMJ8pZM3ZDYTSdog0jRnRsxKa6EqdV9XJ3WfwW6zm2Hgt/UDezDnCWlFvBOJ+G cVqtzo/U/azJhmwBRYIk6UjMdGwar09p0D6Lh5QG5rwG5rdq0v6TdmZ5e92natI+dxVIuXpb4ETd SEOJyqyozILSM+OVRWX2TW9nDQLthvYFJfaFPdp3RM9BEZv72cMudw1qUHRZzdaaCoQ+g+n5jvav i7yslR2zZDJc6xVW82IkdxMI0jCdhp/DbBdzolS3qhE3HtVvthVq2FIFWEsNW69uHNhP91UVeEQM qwb052fZAwClWLVoSV6Weu98B9u3naRmzzc1O3h1BK9+A95YjKXMOGOXX3z8HvrTWX8YFWj7T7I1 UDTlyD3bI7cwJbmK7nHWvD0vimMwGjBxr0ljeXU6/dqpVJSxyIfuXJi17xUFRplJ2JcllKZDZTW8 gcp+Dh9ol6jAsgLLdq9Q7xj49iIc+FiMyCiuXLWVrpp3HfrxyPu/3ld/3cA5kjpQCh5Ypv6YTMy4 rt3+Iy7+s/OoX/9xX/ynt/jb6e32496zSM2exUOKW13NrXre3zqd/8c3828zrvXUe5GOSYrTj196 p+1fOzHWqsb6wyzK/mOOsWovibFcRzwY44+bMANg6fX+6HTU5XrV6QB5wK9Tunbq3v0NX9Avek+u mGOMEnYgw/AvmIxu2e8vyDr/Q3Y79Wr3j6xWe6+ypxjRvRHJZOYXLMMmpK9fdjqnHVi1B0XfwvsD X1jvVeYVI7o3on0TX3j/AycJE9L/Kf/JHpT8p/XeH955HLF5xYjujVhdKQ6C/4ML9/vvv7/qfEfu tPYLX9TfU7ZHYvo3MeIWGFFnMj9I2mmIBobI4YZetLChgBtVZSK166V+a9+49m+WQAzS4moKq80c QvXCZRJ0irQDFof3AUVSnGLbwrskoAWIABzaP5qCNayKNWjD7SHhWozHmmJp5n/XA9SKFZ9oxeYt NDiS14P4q7503j/av3YSESQifCUizHH/Xo/O69w3vmv/jIpTeaJT2V8aGpx08sSWT7QlXbj5QWHh G+3fxGcRLeQhtyAkUvn+zaOV4mxWdDaG7nhaZ99a/Mb+MI0wosE8xxq9TupCqJR8zBojyg5I/BQm Fv8KwjhCMf8gkUG0tPN+FL3dOU8n5RgcaJArDwUuo9++SzzjUFhVucpf5ngOs/9X0XNB+n+x97L9 YyoRYU5EeIpaI3BBAw/ehcU0xCaonNkUtDIw8Prc4YMOc+a9QBUy51vEto7bRmUxAQ0B9Noj7HMJ zIJWovJqjW1ayq3sy+qcerTB4z8kNnRsQ6ODrq/bGvhJz6IYkqgwJyoUZ7Tu6UYve/c+Zmk/xM7R daz1k0O2BRX3ljXKaZEKUoo+dRu9dFLEUaJH75I0G6EJCVHauxDatBFyDD/P037E88i8HdcISUuA chygzLIuiUwyardw1O5ZuH95yC2IcYIqf8xY3Kd9WZiWtOz2RMtOIsXCSCGF2txC7V0CtYkkLDoX mT8o5sH/rMA07433gGJHdxiC2u/uHbafLkvUk6hX7Hy/RkE5tzxvYCR7QEnO/bFZjtJLknQCcRHo nxVyn6TNtv42m4WUKHXEXGm0LTiW3ouL8x41ZRR6IrX50zIuSUbmJiPkEcknQhAG4B0k8d+n6Cv9 oA+buERxiet3iT1okOrTR6s7vZ9/ublFh5O3QputNpXyqCV8GdHSlLj9YyreYp63WDgnl4X/wr7A wjNbhCVISZDawBasGcfR+0fTb8yuH/W45+Qn4jQcd5v0tljuGA7Yz8dpDkJSfJ9mUTEcISuBxjht WqoHBx0XeBm0mNCxCecuhiVTJl5UmDjObOPQbHVmLjJ1fMnYYkDHBqwuW/umeBZooiSKKyWKMxF7 Tqo/J2RjD6LZLd7+ORUTrmTCfDIep1nBfty/A4uHsNMqauewVLm92CybbgT29m0ovmYLOhdbxklr +pqbHz/88tNF6UishIQWZSiJY+69DUKfthZIfuJa9xFZpPY3uWAKgilsAFNA2/19SvFMb84xrgCw AV4yG6+iGMt1oPXxwCua8QaWTSQ51alpso6TKjnKSjkKjHgFojGmZApaHcHzbFgMMvIf0EcDpDCY kHtXe7ZzAiB48VWaaKtGxF1O289SxIqrWjHHfjmyz52fY8iQbpxW16FNcs0Az0Y04QImjSR+u47f uIjlVkCeGcVEeppjcC31EnhZ0+RBmB/gviawtGVxuYKO8SHYz7p07RtEKjep3JqSVr2Ethkuafkm +RQkSNNtLEs6bgogrmMWyW//pEr0Xil6ZyHBREQp4aY++XeC/WuJMkL4LV6x+zs/o4dX+J/WsDFQ 7LeS/VQxozMvTpFDryyGDBob4O6xWed2gqRkl5J9YyU7qSH4BR9GBTfPYtMUGMgHcaGnz7LECfcp ZhDm/Sy6Q4XH3gRWCtL+RPUVIE+C6iBIUZJTxUBMowghXnsn1BF3Eiq2oMqjkJ14U+r844apHCxJ 2UwY/S4VhFRSwIEfVjacZtxLuYZbdg1v9DD/4at9j4RLzNdHEtQlqLcX1HkkZx8O4bosF4SBLlqa f0cvuf2p54X85V/GKHCysB9G48JLFenQYjTvMg/RKmgDWho+Yp2TaCDhayPh6ynad2U60mSSzkEk 7Gp3DAZAiPYRToTYdyP2LRbeUCrbFmKCkpJIStJeSrLwDIKNTsewMeziQQO18NFqRpq8+IjSn+TS SDyJY0/SwKVXGzaDFcWAjg0Iok2t+6PnCQj5qyg4EhAkIGwgINxyNLCqAnYn7z/cltQGihgLE5dd cSaOnQlM8+Gna6/360ePlCmTB00DLhFLiu5ZGtN3AJYOByj4GKYuaS1iQscmDEhGiccOUK+hkAe9 qGQGcI1XxYWcEGqA03QpdRrXvvmeBaNFHnILaDuPF0jsvj453r/awc6IDMLx1xfhwJ/EBS1Audo2 WsT0NPZBGpmefvbjtzuDrHN1TZJUeFZe0LJQQUo/4hrEq77yE2GpRktyivtPlVNcYt5tu6hf+TCN eVs52n/5Z7+4EPHFxk6cfm6vyam5DrqoIr7Yw+oQ+yOCr13yqa1+I5ecym27kXg4K6o83u0secht i6jNh8Qzm0RgG5ag6WS94viYqYClpTNaxj/5/U/UrcP3tZ/FixFXYosuhDgMQbSJmhsGKTHyFG0v Eyu6JnKBkwXSlk3IntMmFXhV4NUNwKs/8NCfpp4TDkdCE8rfL4ZUG/5GAoNjdE5Hd7VSstF7+5Sk U4Lk4P9n8NYBZJlpmtqPo2ING1AlvK8U3hEY9GAt0O87TL0zgFrTZStneaxuCL4NYjD9Qui9riO7 3++nWYBpLIy4m4ieT+5yEu4k+R6rpwowvYAfjQpa0rUOOQMpA7cAPd6yMvB2QTPVFArGAfHxTROM gICVzpM8+ELCvOMwP0cJzGRiKA2vlJ5S51cMFaDNil6qjhflHxMDujagkV2F2Vh5O1D6nXeY+szS EUf8PFTs6NnJOgnwrgO8ZiGaGbqyv2164d/li2smdRnlCrq+grP3qnEZy1hI+XfpOyvxRTGhYxOq usiqgaZ+AnaKeqNWMJEEzgRUFTMyCdRN/zExomMjsl4FqqIwY053HZoIUBOlieCfgn9uAP+8YkYi apz7lGRUynMIUbsCmnbNeSamnn4KwzE5G3Eijp1IqawOawDfnPq0Hz1G/VMH0KxAAe2DwSSD7TLD TZSs2nVWXaRTPwtM+K6baz7gqTWGiQDeH4LGxlRTuYuO72J58apLGUwy8qm+Nw6zKAWQBBpBNNIa MoR+Kh3zpPS6YkTHRkSBq7IvAv4Q/ZCbwU/moLHukrUwqUvwNhW5mtCvLUjDQmI8x8YzhHzJnCVz 3kDmfDvbS1im/i/K/xnT5reJFThv1MrToz6cUSNIl1rP1AriF0tNdimBaLhDk1TXMBNhOKXgVC+c l5eBXPrgx+ZW8bSN1fm+tui35vu2eTjHmJ140h+3z2mo5Q06iye5wAVrHEo3we9H/oi0fCRJdOwv GmLjHuCvIBzH6QMrQeb9MPFRq5HyP8X3mhat7ldGiZjQvQkReakIm235ez4mb9UiB3A647Tvx1XT g0WixXzuzTdOsWLjQeo0qdPaq9NY5PEAfrt3T2TDH8Kh/zlK1xBwrezqYyMD3gLKHaVNkhOCeLhB bccLnd55Ph0+PW6kK0ePt/1paCBMcloKpepIrPSyotH0lBS+8N/g7c7xCQ3S+5NimGZvd36Js6g/ 9H6LwmFIrwdozr3d2e/uHXb29jp73du949Pu3mm3+187VpFNp/Py4uj88kK9rtPpTX0yZh7Lekqc Tzym9WNaJQq/s7Yf9MyghM2fSe7MWvRQn6KmCc/NPa0amcyylnVPXtfvyc/n2eTfsxek+/p2f//0 8M38C7J/1b1Y+wU5CwPrGapbEISxufNvvulZrFuEv5JUOC5C6Ft0u5t4RDzHLQSLztAgoSc1X9Lv UcSrV1zd+vnwkakfck0Whvaiv9gjn3Tr1hGP3I9mR/yHqw7+k1yCmc1GLzuIS+ZC87aIf16Lf16M rHLawvnMilPzRA0SGVLLG683p5nv3YB01UxYtqbyEHvVCT+hAYn2L5lUR1tQAm7Z1BVO4iVoFWmG +QAA5uEpYauogkbR/bCgZbkKp1OoEOA6P4fAHkjLagSUXVD7B1WGc1cazoUNp+kkDnhB0qPEU2g0 a236h2K9Va1n6l6FPQRqN64f47YFD9iam2XqtklUYPFC6aO2ld4vTE600r3l2euV/cneyvXW/vwC XxAw+pBZg6xeb5nLPwTNUTfUFqzDlYQeeqbbkNCrciyMYJDMi0PgZCyjABkTJoKzaDSZMgtj/wGl tCmt0eUepUE0iEKh+7tmLIFThrG8LBzQoMYSuGl/Zfd36ND9ndGx4+P53cwR03B/BXSeHLTxbNaF tPHO7mV3H1LEay27DcDpo475otBd8xK72+3EPMFh5/n6xWH3sA3bUP60CSMsgK8qHSHrOREFXbae GI4xlCLBXp7GfngWAJM85BagaPAWj2w6LJFG3zag4pHS6DMI4l9A+f5AlO/pSBO1opWjvW1O6pFH +/HPLvLbq2i4i/I9apCVG+Cr38glp3LbbiQeTpTv3dOt5zbfMM6MXaLpGK36KM8nWEDMPXt0eVjC E0T6dIKJN+m+WTDDWhGFBcUsWm/4dacJzUrxENbrQ7laNXOSMCT5iJRaqZhWT+PPgP7GGGPJ6EVs k4vyoWZlFRz7V8oAlvibbUtum/5mJot1O6sIKxZDWC5I+xMaNxII4GkQgBy7lZq/Pchj80zEz71/ LMGbj1bG/U7m480bwf3OIGUX+/0ZDapZrPm4jeeygoA7rJmbOKxU/2eAmqklsHhnC3EOIgQq0ESU MngTqn0k+CLxacUqbWFH3lBELENYLfmVh1L2Dhz6iAUP2ni8TF/n65V6FuRU7GKPFkjaEEQQdi4u 63slqUR+MR3SKI9RWVWtd9MUMGoTYfB9qSelNyFMxnkBss4IGV5dIuylN0U3GFr6uZdOk7nXjZie 3lP/WY4cL2cyFZdtlJkf5tsdhRTOW4C3b1+2TuKYOOmFn/ShhRnxFjidS1WyMHRnoeKq2qoU8sxl tvyMoI5rG+lb4Oa5albOshwqgfO05JH1oIK2qeIj94dpmsPcrCIgNnQPX5VCDoogji1PqecHnzHH EBkEpH4FzfWjb8N1FAu6t6Cdskj8FtijPd2HZd5fU4wV+mEIkF/hukLjkwl64jqoHnIOmNqug2yH fkWhR4f8OMccA9Bv8vUKG5m1rgQA91a8UruZeNCaVHT5hjW15QEEUfo8szFODOjegBoaYklkXL++ n5DyHekhUxdRgxnYWkEa17o04h1qJhkTG7q3oRKdwdwlm24yJhhpQWUkKZqkaO2laJDm2ocw1weU bHHqB941I5jexyzth3m+ls60AHrPFtDj07ZXP2/nWOudpbF3Qztt2o9Ectae7VlbWHz+ALn3Cmwk 6XC7kMm9kR8lBf6/cotrPqbCmliJNfHiw/nNS85hCTGGIFm5GqtcEiJbqzEWK5PybU3K68C1OHTx abw2HYz3abCOaV6JZhLNoC06BpE0zD6HO2foo/WqUMZ7K7WYVBnCCLYZpHGcTtV2pBvaeGVwgFnh w2/v10ssWymWVfK04zGUt33aL3oqibDErryt2LUwEU7JewzTvOgUD2OiA954gH8hNjQAtwKhbOhd hHkRJXwmOz/iGwnL1xwphTDO6AmI/1iLFORTpHoRHCrjarUvGiyZEbv9dptJYiKJSTMxYe8CTk88 epR7Qe4cj+r+pf0YKJnJSpkJ/Ac1kXJKMI0RjRuRJoRU1+01IRZmKPPTE4xpRQEyFdLMCjzNwR77 UUYdzl6VRnfeUQd0DeFOHMlKjoQyR9hCfIb4jI34jFq8qmqaFZyGZB6OCRHUk+F8ULyGKN5imGsD XuMWMGlVLaumYJn1Gi8CiU6PBnXrGtsltipew7HXiBLgViMGq7wXBHujOTjBjsn66zmU7pEzIhgQ NW40jkMa9uc/I/ZzbL8g7Ec50O+XAn9LorgBlw+A6ib81yTEAKGXTEZ3aIu9gNx2FvZDcAp4+B0T 8h9+un7Zvmv4/+xda2/a2Bb9K1Y/tRKpEvqYJNKNlBsatZq+lGbu1dV8cuAAvmNsdGyXMr9+1j4P 42MMBQoct9mVRk1J2sHsc9Z+rb32oyiY8kO2oCq8l+HWX8eSLAf6A5vhXAmFoTy5vatLKPyeynGa iKQTYOg6jEH1LH+9+TaNwFwIPoTz4LdOgA2pr8rv2S/+/IyBsODsJcuB0r3dTg6UxVa2FFu5epfk QiYiP+nJcJjbM1j9XcmCV1+wX38E5VCFDLTol+ODnegav45X4au35dVb2fFBUH4fTcDoHQaC/MU8 eDoQUsXjQ5lOSETnP2EcYWXd/KRXSJ3tk4hOJWzf/3Xkhs9WDR+AJNVfdPakJI6ooJYbu5KlpkRz IyPTz9lNOGrTmWYpnrANPVdjYEOkvmQ8Tn+5HHOscgztXULp5foB02BUmQ2u41EqoaI2WarNGIT5 YodlGTJaIAlRFRNg3GDcOA5uNMFFNkU7YRj10f6ZFnkwCPNwFYTAz3G44T/cQKjR0dTzbyF15joU QN6JQYEZvzQ5+Sxkn3p1qA8RP53g/32aoZFnfQXb0L8NQ+uuGfwZ/PcH/mb80lGqcEayFSRo7QpK IHn+8pKJQ8chDtH8ZVX0OagPYFbJQ87oZWBH/9hxeXZc4YIz3nHHYxEyonIlviLwAJUonmMiQqeo zxY5KpvPs/kWNQIyFt0xfSXV3BGzzjkQ2V8gsrJvgUUuFujnRC/cdEDFAQ9nn8N5dTfKhxtZ/E0v II/FoB01HU/Ozk5Oz++73cuzi+ZFDrfdF6+63cNu2l6xF6vjLrNBM3t5+cvFDz3gmq0vx3hus+Nl xXkADpFhVyyC2ZWS0xOxUnTRZsVhUDFeTwzDIs7Vd/bVp8Ibxz8fDf715Px0Yyt1T9UxVKs25C10 vbL9RWCWDdGyPQQNhaeVF/r8bONPsoUXmgbpqm7Vecym633e3fhxzcFR+/vsqW7H9b5S0cOKa1xF 6/MXP/S0lWvtZYvhNYzbaNHDQdW+yB8VqHq5rQ0OClWH++gOgPLOgrm1wcZxUL5iVWdH3CZvrYU4 siJMANdF0SSquithMALbJQka5pkVBq9wOSswatdDeHeIqOJwQUHluDhr0H6147ImqHS80ea5Q5Pv 9e2NGj1RmyK/+gyg84YdQ2ye47TQEOVoY3Ns4MciV9Vxvk3G/BzjPBI8lI1htJfQMqiNWQaPecxv dtlPJ8RruguTkYDmtcxNnn1xaiYpdhLj6nmoDFxsns92z45RGVgEARdb5J76rf1MMSMo0rrTGZBs 35qQYC9gt6887VDBn33I6sV6g3RWl6/0tcIojQVEFds4z3TXVGqoxr9vbk5fd3uUW1K97TP9C5XV Sy0Y8cMbq0L7l3weC7zbryHKhTcGb8RQSJp01ZtwXWMgCZmgqDyJklS+vU6yiJ5VLdBd/g5SZnzi Ui+MtJ+5/cfx16hmWGKZflvmg9MjIk7u6n701WfYc/kQy31XpmDLY8D7jxicA9fCE2Qv0Y9ck1vH tC18SD/x6rpzZydZAjvJwidvp0EyPnlbjecA8dQsrh6eonErPnd87o6jN235oUEjP1sJT1v2LzF8 S/rv/k8og8ZWoIF5sFUM7IaSNNN/mXWzP9aNof++gJoEZAExDmAovpCSwKImkYQk4YNh0nKLncMN 3j90cDjfjqzXZpZOBu8pjfwvbT+ur801Q+lKbW4xDd2hLckf/vhyj1ooBCiQd4sgGuLF/Z9UdnJb OTkQ9ygEgTag+BbR6otRgD8mYtawYYyJpezi9ufiVpYJEHfdmnE3KWirE+QwtHACDmuGcWkSUqBQ mZBEjexLlOMcJFFERFub24Ko1F2mlTpIa+DXNB96p696vdeHZZuixH8vvuVXkp7P/oG+RqVRv7K6 kH9Yv6DfUq6ro/S/qnQjtuAltfcjX9do8FNZu8poXQiOvnPYuZSpa/NuiX9JnkeV95de7WfuS061 f3UJHRiFVsCD2RRlZV2wixOxOVjARualVOhZRELwtNCFYQu6LSXTXTmyBcs5asj2Wc0NeBtaSafF UMnJVG3IyhuKf++4xMM6mbVBggjzguQVMUbPoSmHpkcITe+JvAqNqKas6auQcRoO4BcAISpGRYar EcQUcGhbKXvuKpXAA+6PIXiNbJdG1/JxmGPzed4fA0RcrH9/x4iyG6I8ikohP2QLyqGb5z0sgf0z SGC/YglsOtLbSWCvOdptA6nvaKlv/+ysQezWLlCdXF/OYPnvrYtAez2VbbuReDgVge/1IbkBt1UD jlodoVrEVh02RzqCHHMiwgTCGm6SAumek0itedXr2yJe9+rQ0z3klBH64JUGKm3VW2ijcCK5WyLJ OLIDjqhFsNsDid4fy0jivStRQxJtzlJmiaGEoeQIVe53um69eaEbtVPsFtUMLy5wey5wOww7qmob OxJTL5cIKCdRRktHieeFqKWYksCa4RWUJDC2omcrwmiM9oz2x0P7rLYYllih9Z4Y9T1HiElAvKPm mWLhMVJ4Roq64ezCb82RVO1NvWHKai4pb61NqxvTbELPJiRigKbHW28Mt71sOXYI7BDa5xBigZUk yhvAY8CJhDGCSYYUz5BC+F73DCgu0MvLwEIv6+/BuethM+YqyZrsiYe6spqYyqIYnGII8UcjqJUg U4MJF6RUpAlaU9GxqvqLHz/dBw9MOPPdHNAufYCtXDAdAuh+mAn25OzJj+fJq2hRUldXzPgtuwJ2 5Z5d+SI7GIlESKrWhcp6ZV+gXA+HFe01EjIjDSPNEZBmIxZDX5WOMB1V3Rwyw6pbAh2GGc8wY3gl ZnStsiCK2CYmdSg9iV1gTtNsRHegn0mHbEPPNqTc4JOMRlFy8pZIKCvMxk6BncIRnAKGZD+mubiE 5j/yniyNCzUWFWZZAfwA6GP8pn5iMctnTy1alTOh5t7LIXMiKtLAIas27nfZ0Dq1UFjRon2U9ONi gNnYh7kyXG0PJIycpHnQR2dohB8K4xRqIuza/deRYMJpSGGWEg9A9ahS5GNfwL7gCL5AJwg4efFk DT2RMwSHj+9FZSQOs/xOkOiOGHzG7vl/w2h/qb1Rq+Uwds4d1IHg5OGuDZIKlVDsTt1Tzh54MObi +rD6VqsxxbBQy5ID0RhJYAeCYJjgD6D1H0FnYR4MCpREFZ9xGPwtZBo8fXL65BnFnQnXI1pQjwDE L1rKSyyXRQ0bugwPgphK4ts0gu/hwJQD0yMEpqZIAbxANQIcdpPEJqIPXksoIzTeEd3IdCojw5OG zh1ETFUCjNPLGOMZY2BA8CPkvBMAQYD6oEjAhnAbag+MqlaIcfg1UnxWU3FyMIkt6N+CWZzOcNMw oVBIuHcUKoZFDCKZDIfDqB/MiJ+EnITcA2jHZZuzVHBjG/q34VTIKGW3HbHbPoLbvlcsuGpkOUjR U6D6s/HPwAkKLhV06CTCoAf3FVpRbrBNBRV4lcYzGR6hfEU09Wn0XDwPwoeMFrqRuiqSQYZ8z5Cv 1SmeJKnp+Dx5xinbbtj/KHRh+CF/Ks28NeJabMlfxZKssdKksXL1eyrHaSKSTiBy0BgwYVH+UmsE EWh+COfBb52ge3r2qvye/eJPapsFZ6931TPkq3f74rTF24eZhXSwhQusUMgKhTKCvMBHMaPF3bhq DiOCr97hrt7L593nZ89fqpWD01TyzsGbtOCzeCnbtHPw2pDHqJSn5qK+vP30x/teoIljS3NRpm8A vRJd++OakeeaUdm5KbdkcM1ot5oRp25LQcJ3WOwlocg6NwUgfyXpjPrGMi1G42qJWdHhbk5451Nb dz7RnEjJDjPdhMVUCWgAIf5Dddpp9mfsAjy7AFRJsmJq72Dv07sbYm1Y+RH7urqbfXSB+uM0zZQ+ oZotgTFznhX1rWkBG1riXiQyduHswo/Q8lf7xo0EggrnayII5LDrkkcfrv8HVilexqRhiqbynOHf M/yDt12o5e8wl6bqwUUXiSH9LqhderZQKVtMpQB9r4BwgJG3YCN6NmKZvdFC7sTeLTfSKkVJsnCC WGw6jWmxKhH1IRrAFvRsQX29TvL5lMWomLF36cF911x1pvAiEbMS5RebVLOOYtvjm4wbnnGjZjU9 z4MIy5GFRpy1FIkhWUc2R4TNr5y/+c7fnpYB17PFdTMRl422QMdXvr1R6+EAKR8XNLcqaCpNFZpL EhJDkErwc5zGUGFCjIw+iBQPKbjQRs3JFeo4gPEeBSWMT+iWJ5SEap2CnjqmRuPc8PPV7JZm6WP6 LhFioMZ/wsH/iyxnd+/Z3VNNpXHSmr5h0/FFoBZgvs4ttzPWcG3wCMkFCtKkMANpgDzEiEgniPQO qxr+zKJsTMpjqfpJWfQXx5WhxjPUwITU9FHWoSmgKEGdsISYctJTpYlhQNpiCHT0zKEKc6IJ5xW+ 8wrYUI1zpUqDMoyRQ9AYdpFQ6Q+SDiRVj+HsMM5QjKeKIMxdv6l8EdtxEYMFWGZj0AFNi9a9ccbc Vna6vKVsRP9GxEWDo7NQyoEYB2JHCMSWCJrlKpLKaqsSJuAJRvAV+XhCZB6uD2ZoRbRBCs6SO+aM Gowa3lBjXaFoEZxwpagVkEE9nyZcz6aiH5GGzzSUIAKAio9unhaSJhIP1ZEg9oZMHMwAjho9R40I 7vsoyNL4apFBwtsugX2fYsdfg3XZPbB7OIJ72Lq6pyXoGVxaNbsFK1bwRSDqRwFvHI3wW1mvLet9 JcMsGEPWb5ZK9KLFoMMewrOHgBFRZ4da3/eNFk3Qnv4Ko9E9VPx+tp5/69U7ImkB0kA1N6+InXIa yKtm5O3xVs3cq2RgJWOAcoU6/wzLhNI+KfMOUK/Ox4wwnhGGbFTCBip68xx9ORWIUSEauQVY/Lo1 W/kpzAGYpUEHSCiYtbMlawd9g1kE8V0psiJWO+T0utH61dNq7Zb/b2kffAM930DVRKcSS5YTwWFR ZKmIparOEKIz0jhXl3OhtXmAG8jkwBboxXnZJbR6u8dSn8gIeTTWfGlFbMPGD4Yaz1ADT17ZuKLE Vsj/NyTx0G7nMeEd54weBXz+Og95ev7b6+6tlS+864lhiDCKlkDeegtF/wEAAP//7H0LbxtXkvVf aQjYHedbMUNJtuxo1gIUPcbC2JIhyQl2g8Wi2X1J9rrZzemHaQXz479Tde/tBx+yKJO8TFQeIHYk eaJWdb1OnTq1402OgvztzmlaZpHKvCs12fnr8X9OjmI/GeBzX/z47U4/61zc0If/OjnKPmb8+5h+ x7/ia7I8Cm8+Zm93ut3um9eH+xc7/BnzBRdpUuT4Kj8Poqj9H8JHhydJPvvR5b+jyVFx/I80G6aJ SnY9VXh+/KNX/zr/Oo4ylXsf/Hvv9a633917VX/S/Om3j/5AeXuv/4ces9APqx+VHmdsH5Qe8+Kk e3HQpZ/d7LPbD56pvl/GxeyXf6QPnZ11L3464R+U+UmOb4v7WOFv84/8Y+xHyZ36Wmhr8E8d/7XN /DDx/PxN0e/y7MbIs4Y077wx5Ty7H7zsHpzb12QL7P5N/228lit+5ex/mlzrMilUlqiic5b5/WLG EfGBs+vL03kf967SL2rUQ6CCC798oqM+YLCWX2+hwR7vkc/9Ibff9YJ0NFJJcYNEq24LPysQQaLw 7c5Pr0zMtxFFp9aNuKb3dRQf5WM/UG93xkiYKvuido61J172vWKovEyN06yIUB0kaai8z0k6yfEJ v+DPXp/eengo1BK5FyXmL/gBff3qvXX7bTxVHjm3IZks9/xMeYnyM09RWeQXUcqWsuZq2TfwEy9U QQRTF6mYsFm4rS9DPuSGoYpVAWPAFa2z3f/YMgwq+kZoOU/CRYGFSpruz4en57oQtc/TKkRPzf+V 6qtMJYEysalViN4N1QgBYxQlafaOCnoqebiyn/1Mo4uov0/7f976RqliWKb+lownxaZpXxvF5kJX wqs5ncs+fLq98z4rNfYQ9Crn8iZRMfR8D31ZFEbFvReWJmam/ZbfraQ4k5xWgRCPseLvKku9Fzvd nR+8fprBSmOVRWnopShWopHy4hSFikrScjBE/sKf8hLJj8sVP7lHCZN0xIaOkxpXISqEN+pCkQvL v+QNDwzwqQJf4aN2wZflwFXYwnBh9INZnPqhWNGxFYM0QXSkUrKq+1uFZJSjjqTSJWxXKyuJms+i b5fUMC81HL/8cR//87wbGz6uqC/9WQ39L1GarT4uyLvmALG2tQBFi7mTB7et9a9DlXBqamQwL1dJ qBPWP0uVF15UeFxhhgiCGZol5UUEqfjF6t9RCRXzQsXCXiBT2kIjvwiGBJDAmMCsvnCLLekqvJHh x3cNL230wvBj4TtYwavTryLK3updJNjHwnTNUENxRaKI4wrYH4/je8/voVUhYN8rqGvhP2l8FZ0L 2xa1CoEPc75QTLgFJozQaIZqzMnbGK42lR8P0gx40MjLizTDV5pmB2iR5AnJE99JcnlMnrgAzIUs 4L1PcxQqVbCpX8xQ9VFbmjcTXXc+xvimHwU859lFVaokzDgOM7cKGR2x5RWDlmTN2pBxOogCj3IJ ApHEFIkpG4gppvasX8K6dNFoqxnmZ2lRxDT6J3gdb63tm/xE8NcWp8+OUltj0qeTHx+TFxhLIJM0 +wKEf+plB1yO2tZB/ytDEQRR4CskIThOCAj3WTrOIrQOnsoymmQRXF4l8twkDJs4XktikMSwicSg wYbAz83QlKJ+PRmfHYnrWV7u4Q0e0rROIovjyDJrIuTuemq+642Un1BK55l4y1yTIwzsLCXnkDg9 flkMUxD9P5xm5e/0gRAB6+0OcXE7e3ud7pu7/f2jl6+Put3/1jsA+JIGQ77N0DlTWC3odvcvumfn Z+tYGaizJp6DuPTzsTfA8vTY5muO6c+ad4SPzFlx2Mig4VhXV80Bass0+B4fycxv/8xvmlsJMiRY akhA8QzhLY6CqADOl0eDxI/RZ5OpqIwyNbElJHjVQLxlOXB8E1qHYabv6+9yqk15T3G823oEvHx4 BleuMd+JyQpSxrruQeoG0s/zNKByFuRTos+Rk1SeUX8ZNyE99h+NWEnB4NqGCFtFlsYU2fp+PgRM Jb2G9Bor6zViPy9ukC7BJg9p4fJnABafeeO0YCbPATN5bOEjVB4p82jLeIM42h1lKrCI9VpMNbm1 byQvPdFUpcj8aDAsCMGf+Jkg9dgBF5bIhlgioLAbZLdmhtDW3T2XwVxsTa3p3b67/vT+bLqMl+Cy 4eASJUFc0iodw2id6/c33skvH4lE4McxgPh8gtXmkcpzZEZsVaZ2wqI3LMV8jsE0qo2hy2DNd1uO KS2osHMBpg8WS3K2JqZh+AosxDKdkL+4ZnCJDR3bkOOktDSSrVfW0izAlfXW/IkN4ToaIESYQS0z PDQppxNVPDI7UbdMZCQKiRiOIwYMOWss2h6sozoAYKq+KPJXc3hKDZ3ifoxaTZBJ16gWbKhrLi1P cV95I+0T1pbKbUb3elxLm0+KegW1dhuZfC2A9zmYcu+NKUyETUNETo0Ym1J6fi0meV7y/Aby/B3a OeoNkAVAfdDcuOvTqr3jKYftHajRixKgRkjxxAFNVED9XnYved5xhCEBAYom9XiqJlU/LuSICR2b kMAUbr0JHovzFJ7GgEtVX7chFkkPT0sPz2IF+s/zkEaV1ZKxtpkD9IyFZ9+I8CzR2qy+sAjPGu6k TNVWNVUT4dlHy20TCdZ6ov39cR75AOH0z5NRH3hIYdUuxaolfLzFrfhw8l9eMExT2jhIIQVW4AvM mlLNINR/h75ACIOugbmpjbM+6dyQauyg9DMfmEi1OYKerKKAGgNGubTMjltmP4YBw2qYUYm3NdYI pU1+WpssqWCpVACM/yrFAmTHu0y8PIV6J+2d5d4L9ePgR29i1lfBfSL9ahz68IDXjSDCofdbaSwg wcRxMDFjtrEPyn9PFRMFtaI6v9N4tJUt8l2yIVvWZgYxoXsTaosBQYVvhVEegN6KWRsmom3j/cBo eW1eHs+NfBlkuK7I4IVUN/dolIGTQqiSZ2qxaaEAWm7LMImC5h1vtIkbbosbSvElxdcGRtizfTiJ 4V9d37GM6XTjxlNu32N2E8/bED8kZDgOGTrmkxBtCFH0IsoRyhHW53CapLf7bixTersn9XYcLIhz 13gF6/e1elkrXbRhCuFkkZfaCvodjBaPYDqCazn059QTaIaFVhAhbZjOfCaedOdbYUPiN9UytMZU 7G0pPpW1rTsq4XzoImrVC8nxjnM8WruaigbvS9TE6+vlI68XgX1YbyeZnaTOL9AOA8oCapS0EtJK OGklMNLLFDRzzDY1ksQv5phW58we0yLqHsSqcCmBwpEEGseBhhJFNNJqR3X3Z8RBsP1OSoVBDO2w cmzN2irq1hBrpORequR+l04U+sBdmsdi9Hpzfnr94cP5FcTWNEVWlwKt2bsfT/z7psqVuKFjN7TJ nhbAK5mxNuehpSj25tGKYq/2ZmX6qETdhB5fcTwzqts+RTE7kaqF3NYQ04QSJcekpm9t33GP1grM Wr6jKv1bwSCp03MaBGXGZ3olcDsO3OjNiLVGuIjPXRppfbAU3tzqN1eAVMBm0yUw7ZCRRqtY0bEV +bKsudczNeg2Ltm6KIvVvlYRLDMR16NwM9PmgFmOSa4YQq3mZKwBuySrCyqyAVQEyN0J4gPSAKYc WBSGPjruC4Iny5LpeheYT1YHfhyUMb+pSCJ+yDkE1b8kA8fJABa0auqd6ga8WetGWLHIK/I8Mjm1 a2xO+oNR9PImMiXfBh0Jcj9K6qCn5wBH2Ex2+ZvKNGKvY+yR+30CLaHzTZfedBUgTrgRJ3xAJfYh gZCpEo3s+HB9poOwJb6JcTdi3Af1sihckg8i9VFojZKSR8uppiERlAl+y5ROYomviyniigHdG3C6 nKHASpondeGjQy30EatCHJYOI1ZDoaJIrLglVpT7g7moGh9toDf6lXZ7rBIbxXteJSD8jO/XIXTw FEv1+3QH7QtVZTjOowZokugLZOPANcxSiVghC1dHItEFhekkgVK68kds0lwX0ZlCClC73CNVJZtE fcdRn33OoJrE+ybNSxJBbNqTqjOCqoFPN1WqJ8Mo4BsvYkTHRmwZoDUZ/qk5Gf4UZ2SxXyM1VPTx 9h23ve7d3uHR/sH8AfH5afdwf80H2xa0CIybtR7R7S2qY+pUWBtW6dCGojbCUiO7ic8LrChs6Yc7 4zW1o00/j4jyb1iUH1CPiXJA8UZlXERj2pqLEOFkNiCzgQ3UvxVVyy65m9HUTCkcMjZSV1VcFkMx RWKI47ybA4GKCTSGWM04BaxsFm91EaW59bWu6Ejhjip6m7xEEpaZgPOZQIieEndqceoOUwGUuFVT ohvRER96Yj3RRCFH8HiHy+JqmUIm/a5bUEIV0WjmcD5P+1srKDaPGe91u81i+MFrxq9ezVbBH3EC uXpco6p5pq8Z//T68ODstcNrxig9k4fvGdf3Z/e6e9/1c6Cfgnlgqy3a+tHwiVhSj1vLBTfcSJ6y cGa/i8Y3tubvYZqKO+9bsN/VBn8284dk+sUojunHpk9cO2TdHlv0HzH3Ar6rvvpYNwAqhKEdrl+B IIEP5ipDZG6ZmTRCZXt3LR41/60B7UEnQE1YobFcPxrg2hXEfKizjaMRxnIUfrHUO8RSSATjkRmR KDV4tIaJzrPgTctDbgE5fCXx5s9jSdESj97unKZlFmFb+kpNqIB6tKruN9TNJ0fF8T/SbAhtu2TX A8zux0iO1a/zr+OIbgx+8O+917vefnfvVfU5+4ff6Kayt/eTaImT3y6nXPzAq71t/vuNF2n5ZxdB 4xmvDvL2h3CkHD9XVsUmR72EtG2WqKJzlvn9wvpf8/ez68vT5r9Xf75C6TvqIX7AhV+uvrjdtpfV /tRW+lY+i4eUjWedY9uut7BNMcIm+lgyGsqAwTq6xMs9ClLqF4AjONDIuGv11UMfOllaBXn1zigm XMqEPVKMBW9XT01ZCsJ2kTQMASu0Hn4YSsnqbSaxZQv6LqTarQHOkLnvhtBQCNOgHBE05ec5/mAC DSDXDGIZYKJ5OV5SzI5z9AeBYkwEkHQ86uiBggwJKtR8vbDswgxBKJXvDTDuIV1qWIYFqPXFOFCa 7OyfqFA5r4EQB1F/pRkK5burjzeSI5bKEWwuxho5jzNvjfSL+yVGsJ+TdBKrEE2wucNpYWajWaM/ KjZ0PC9HEAWWoT0LGAepzzYVIVEBkJopxMexATIoo7wpJ08q1fio2NCxDVupzetn6ajOgOSUHFv5 w+3AKqQqIVVtgFSFou0cW0Vp9pec74ocEbVDF2oUW+6Br2KUhQSfl2AMJEza9HtIF94Yh4sGmT8e ruFNlVy/VK6nynsCXZSYwDYsyX9BXUZnKcokBH5G9ovwB7093+l4+X0SYOaYRL/rD6V9yRKOswQs mKt/lipBQ5SUBHvSyg4Ql6LIol7JW38oykyHhFrgso/GvuGaciOsJhs5aptgQ6rPhsR9I34R5v0T w3eMFcBvEOJ60LIIQ4ynjOo8rV5/LRBciVW3eicUiObZQjTHL388QJj4CAJmGqSxd65fs14UR8Ua NgHlTXu2b9pCGAmFZGt5vcjwHuZprLOZkQ/h8IfDWRg78P26CDfRSK67wLywHwWrj4lSWi5VWtZ0 fD8epBnMM8LqFllI1yLmxAEQQ00nZqn1MsECcppAvbq4l7QmfewG+lhejg9VP0poAqbFJKvSqhVF mvuee919oib5JTZNQFd/mOP+ZpbjThTq85ODVwcX6yWzF8czgLpDUvKCiK9/6I07C94Huo6Fmpft grIYg4WWKYjrICzlzbKU0ZrQ/Zn23QtUijy6axoPo7qS2hS0LUE6GpVJFIDILPZzjBSYQ2U8NiVb csLVt00k1Uqq3UCqpbq+Sq0e9mpNfOdXEQdKNB8FsYNUyJjed+qP/XV1nlLPL1XPn2BkiPJcaYIG EEYa9jdtdd3W/UU1xclBwZwUasi+kgMc5wAji9GorDS2WHklODdaXHX+pTk5FdhYTXWEFsMypIvC 8dLWxyyO22BQSUKXhL6BhH5ZePkwLWNcr0eQT0n9ndlDv91cnB6+Pjj4n6qB+3uWlmN8ms6QVcFG 0oHjdDBSwdBPonyEmSHJkdluDoKi6QRoHW+d2sXhKYzEdHxiw43Y8CmKzZp3mXsjZG0fRA2ozfEg kYf7eZGmoWbssyrOOBoM7nt+8BlOCraGn4hhN2LYBVJsGAmrr5qepxXQAKHIqBciMpLXN5DXqVFH YghjgsTBHmmgew+fwNXpHwwiiR6Oowdx8LBGkQYRsNdQn8aquNrzZnMV5p6PVRD1IxWKDR3bEOtY BNRW9bJZiNFNH3/KOKYIKUpe2JiQeNUHTM3yzXlpLc8apDiUSFJ9fF7JhBRdw0hYcRxWeLjaCCK5 QodQRAFo2n2OKlOG1YTSYQpuzVDhZBbLxIsVHVuRMkMNBVblmsbcvZbH6dTOAotwStL88trCajJO X5uM3gLKg4fReDNCNoaxXk+f4TEGvtAj2s4vuM2AiQsANAF3pQncUBPYCDAV7XKMxrDqKMaargfJ h16HJxJpQjfd+hJgnG8V0AGX4F7P0SPSfqTJrd7bIVu2zu9RZh9xk5iWhdfDNsJnWQF1P+ojPHbi ZyHxqMYwnaZCVAwevWgPH71RdM68c3c/VjxhwR3NUqESuJT9LNeSCJTFKblXAZJc8V5/qKq7ac5S 4W30NyL0TUSaEwzGtf0aZHXubOmQFtlzkddVMJpusEIp1p5WrD2LvSB5yC1Yfnp88/uAguW2kQkf qWA5owJlHnEN1KZvfEcrE2fd74o46/JSkA+82tsWpL7xIi3/7CLO2lZixV6TiLNe4Dp2ThteeRB9 hyQ13kaWtF3pW7ltHrmWh9y2jDr9kDOp04SRNaRO+59GjlwIJ58Z7UQzI44SLE2HJYmCTG/cmvFP HkAfBIMAOe/rHqmjEx+MzFmlpEivVvhBluY5mLVJx2xv8Y4qnW+Rkb+M/FeVnB6KK1cIH5Zl4r14 NBHsBwQWUvYkXFJGxa5HxcCFc+8FL4nw0HgKL/6hAq0yNQDpFDJuhjF2eXJ1Ahz5RDa3XOOQE9I3 QbL2ziJcPoaJ2iN+razBEzjO7zzsR3qvDSpe6NgL2YLGoW6V8m4x0Ael23tTzXNIMh+yraE3ztJA hbgBJllesvwKs/zxKwTz91RSnlhNntWHBelOtwDU3rLulDVCchPwrMw/taqqzmcVOz2mF7SiqK/+ BRVkIePTao88+1LJd8ko82mjTHnf5r1vyEV7yEakGvElUpPVu7nkIclD6u3O2FCed45J7JoSDt2N a/OjDbimE5IRnOGqvFLWt8lp9a+pRId50WEhzl3VBRAtt7KSZq+5WlxDWCFDz/lSFiYTGzruhInu RlAGlAgLn4TLsXdiHYwOPYWEb4yiBJ2wWYGrQA9KF3HqCy/ONR5VK3N5LWUohi5Qv9siHzYE7mix jpfI+at3P8n0kunnZXrdSNo0gbCiZ578RhZ0cM52pPgjtaKgbPq4UVZnltW/qpLtl8r2LGEyKnPs JODsXzmmcZLOCpCoqaEDfVCOv9iqXFKVJ6FGGtYV8XceGpFSrTkVariIyaMBlTBadAfHK6FMHw2G Baof3umgASnqn0LFuOohkcZxTVrVn3O6BvQTUDqDTSF3ySWpnmsTF8NEnlTs59h+5tw0tjPGCsdh semGG5WYpZV6yGZm3/4IGqYF77nrMxEoAZJC94tiQscmNJc7PGxI4Vil9jQqy4xp8YHanqEa43Ss pUvxLQlYVUzo2IRVFNURUgowKcA2UIBpOlOdjkmVWtdbhRrcU7RndUvmTvZQcLGEdZwOosCoHUvc 2EjceIqIZR38G3kdFrX5Hmfic6R66uWR2F/YRVokC5PyAz8XNTrXaCG5ILOWf7CIbvsgNbfudHh0 OvfbhCIeuhEPXbxfIAkdy0CiP7q6jaiHEJULfewc94cDNS5KP/Zi9UXFWlpOJ24fZ1G5N2jdtTda 5BItHEcLqMhAOxZJ2KebLqwmLr2A9AIb6AWIU3SS1ONknbcIvMtUoHDgHO8kgFeKHQ153FbAmByF Kkagi8K3O3vdg0fe+Ts42ns5e+fvI44DVsWXySBnKqYPdg+7P78+X+/5PzzIHeRjj20ZpQFnelr7 Gfpzdmw+QruLGMpXz/7yu559Uw9ZHF+f3rYsiGfiK4f4Xc4EwqbZireZH8rdYFmRtynsq9CSik8e h66sHOMGAf74Atpw1LvRnsP8ZkAShSSKDSSKfSSKVtBoh/1Xjw99B9sa9ueT6E74sR8V/w+/64ew ufhPN3ynbJmZZHvT+C7sh1pJ2cm+fuubtdnKzc7GMQkEVPw6C6shggOvURnHbEPCIxCVVOloaS0r E76XnLZ/7k9NuO2SyNrpTPNxyIIXqyLO4L2vypvXy77e2JhYfTKln5mRH7YP7v4FpSzuzXbYrfe2 XSu+WfaHyT9L+8QNL12vQy68h918MX76rmdpWc88YPsFX+sj4kG45uc6yv4LGa5R5q/PT1fFxWyY Y6+7rDnW6qdP/dndrCOcrbqyr4NR0wB7yxqg5dvb4Q/ziyEEuQOif5B/LPCVVpjb2/+uH8XmwtyM 6gY3xI5KjBmgtmL4E/EWUC70qAnHxWGCCqnQwE0r4TwTz8tsUmw5zlpzxuK5D5UBXPhhxGpOA5sa cZfA3Uqo2M712mcN5gAzAsisoYb8FiCD2Xh2L8DK04CVVZU068rVKwmLz+IhV9VErsuSjtLzP9Js mCYq2fUULb+gHqp+nX8dA6nNvQ/+vfd619vv7r2qPmf/8NtH4tru7z1Vd/cB/dVn8VY+i4cU15u3 +HR8mWDVNVFF5wx89MJ6VPN3XldvfsD++Qql8qiHGQuc8uXq6+Rn8VY+i4cU15vnegvxgJYrtYZC e0twAV5t61DomGPFo7COJcb/cx53c1jHQctkKIddYh2EJj2Ed9BttIqEng8NY8302LQtOP0w0jA7 aJg1t/CfpcppO+w6AVtoDGkDPxhqwCqwdiv8zyphrRhFnzTYiNjQMQGRiiTMMIFY5divDdDWeBl4 X+nIS0oumnqqmChYbo/pYHvdLsx8qc/f6i8UE26BCY2xYElakibXS3goWcOO9UpgYz8E3stfJzbc Ahs2KQVA+IH0V+mvwBZIQdtYu15KdLFJhM2tRuiFC4sJt8CE+tBkkmYjUPEzkLtpla4ynuDKT8OV pS+b15dBF5KoefVO51UaKu9nNfS/RGm2+nAgEICIR80Tj4LI/jDFsgBKelIdam0Xc2FZzbA5Y80o S6z+TZV4MS9eLMRx6sqQKhDW1Uc74Ich5hnQl27siGDPLIyY1ohC018No/EPxvbZKs7B1LXyUAVR DtKp1BlSZ2xgMYDI5DNhn1rPAje6SWeA8ARsslCf0paqF+FAXpDeBtpSlZwJNKAjeGSw1MJzbN6m NJQWg9r1Ish8JUFcQipSEgEB+G6PGuLI+vX7Gw9njUjNA3l7nCZACCrND7hjS9Szlpnd//FA0oWk i02lC4jPhIyJINbUL63WK2j3D/rUmsUvPV/aBMcxpgEb1x2D0Q6CKW+shGDnY60riIAk0UWiywai yx2PkpsAhPfh5L+8AIMQcO40VG4LmcabjPc3L3s5+l6A6xJiHIeYqZ2GHPAmNxlhSjkjT40dW1Zm 0WsAE1ALHgkpwH0pOmVDtII641dHR6hClfpT9DZ4T2eDehscSXQiaAWQRgeMrjZJgVUgZWTcCqO5 RTdl80YkiKfrRtdKH8+x4+2760/vz0jeEsOIBmit2wq7gIVEImnecZon402nCQwUatf74sdRyGtz zawhdnNsN8nakrXXlLVBZjhgMoNRqRQug7CZN8xmvkNWanAZmnKp0EmfYjJMhlFNYq5wdslQjjMU KWNrDt4c7iTxnFEYytCc9qBJSGkl+9BCtsmWORLOXahWWCVMC++jGYMAFcG/+Ek+Qe9pBnfeBFxf jV5WR1wlxjiOMXYkVR1OgAFv7cW9zgWI2iUtgvMsVg/V2zfPeNglVnRsxfZZhQ+fbu/07ZN5pHsi RGjAgfecVCjWc2y9xgRn0YkTmTvK3HEDc0esz12lhTriANEO9Fxv1pcra9IbGt0TjSznuKK7K9HE cTSBDXV4b/Z8YYoknqSFNyh9LDoWiuowfUwDJdkkwlndHpZdZSTgeiQA6/m9PI3LYvqOZfty5Y0P I2dMXaxMSvWZL3P/LTBhq75qniZFfifhZbMciZMLxvOm2nwJolsQRO2WqtReUnttoPZiLKW6WFlN FOdBf2AHmQrNx3TY7lVL0HAcNCpUyzKAmxWYbsrJVtDb01dSWGA/Sws6mjXwZMs1elqceRarvPKQ W7Cv/PgRQ/fN68P9CxIN592obdaAnxzFYBXjOwVP5e1OP+tc3OxASR/Pmtmxytw7FeYR1yBQ/Y3v CKrHx6vRLt1/qnbpA+bdNkf9xg9z+enZc372BzRrZXKYzZkcitLp8CTJo7c7p2mZRZiFXqkJZYUg b39oTsB9fLJ54K3ctmg0nVVW8pDievNcb6FCRgg5LlQlKYS/H8KpKoyKgeIJKx9CjUdJm+m4zaw1 03okZQiKeFHPdO0ywDDNC7SUQBr9eCQI1tM6SwksSwUWCGm2iQhBCuqPB+E4D7g3xRoIblo0HEJy fr8fBY2NFOz1y2K06+kF2D4Y41qDVTCk2TspohFjVSW0G8mg+so7fQhLiwE07WHCTFKEayPenJ9e f/hwfnV2fkapgUa7dMVThRjW38FsbTdtyhgYr5Qk7zjJ1xLhcKxcZV9wgBV30rB+uqtlp7/6o3EM LLkfZcj0vCe2A6nqntqxfEsRUXXthnC9WPmZFi+uQmmtO2eyov0MxIoSUr3sKQx4JIi6th7shEZp QMkNhvST+6pk0aqPf80wzIESURCFsJy5lkyOqDKE2Vtkythfg3KpFKVLFaV1XYIMeE/r+j7IToFP SzAgpE/5Zl3mmMK1TEiCXNKh43RIteY4U9ACLtFQwC3jFKNvY6284HvldWtRLblL4yuN7waoG/aC BG6BVIrBXkW51PsxVLt5JGuHCFQp2TWwGwkxjkMMSe4grtxX4cWWY4g9Oku0uyar0BCnk/herOfY etDvhHnsHQkqzKi4bnBmLURqk4exrmQIyRCbyBBQmIWIcDkY4LQUXj1Lvp9CYtBM1G+xaMvTzryl 0GyDvPAUS7u+heK14j/Gu+mI7tvckFzfbeFnBZ4iCt/u7O29Im7NNj0W+tb97r95fMYsV4RNPPQw 5/j0okchtbaTw/2XZ3s7TVLQbXEfY8VE04tOzQ9G9bEKDMDY/DRawlkAKEc4zQCgOc3e0fScBuY8 Rp/9TGNuXv/U7f95+zul0bOrH/1xmRRRbMatlQCXtJXuIR4CUQuFqi9TI5QGJLZFKFxVOiBqL/R6 qR2kdthA7YCVMAQ+b5DiChcjxngne+YwElUVACcZ8NDSCjQD8HtRHBXoZPpVM9NKUMK6MYzWVt5p M7Jszpn56APULTBTF7JuYMUa+C+GmZ8PCVnWmhgs5DJSYUSNC7oWJD0+TNPPcLoSQ/N/E/M57i9h vgpVJI9DyVT/u56Z5wTtACzAJywLh8c5yCuwtFjQvQVxDyr4jFzf84PPMBZPdaoIWbun5HXJ66vL 68eHpJBQFFnUo6XuX/y4VN5HH2P71YcEoftuwZbQNnX3XDsS8oTjVWD8VndztJQTOvCUD5hQ05Or EYQhogDzNU3WO4t8KAgqGWG77lKv7bzzEuLzAYhAMOTcgOK9gE5X/gOs3I8S9LJcj8gx5Q0dtIr9 vLhh+ocKP/oD9TOg3M+M9i3uCsI0KAkplJJDSo7VlRwLm9ATVh9hLqiJI0aS3PxbQI0okkKGBoZb UXQzdmBG9XGRpfHqqxZhNC3FaBopugMU5SOvqSePzhN53sYToqON/M+EMOAMBBJ76BdpBgZbKuZz 3IdWir3M4yW8oOmPVIllZoDBzEOyastJxYCODYix1IjZ2PE9OrtLnuxq2IcPVUY1+EoftVV008pi QscmxPnQaJBgC5KgPF0te8N0MpPrwNQysRZk0TT7jN6IID4RWdtQSb24cG7ETKmdpXZeXe0MuG4P YX2hDPbqY7eAdgLage8yxhQJe15q59gMfBe+ggzzoB0LlXf389neDzQEJszufqy8v2dpOdY0htW/ qdKoLdWosTlRYkxSb1yipcbKCSLLBS3ssXCrnyRpCRIUqSfTpPAvxBAc0+zQtgZiQseF4tn15SlO tUKOl0BX4KkDhbLRj2FH3A8DWY4NSciIH2H3mQp+fZp+zH9BI+liRcdWNF6FsMj27NurFmbQYfef yQdh2DsYsRV7xX6O7dc6Q8JCmthoB04Zl7R5Ca9UmJDc1622ka6xezaiKuG8XdNxVCc3grWYGEN+ l0v39rTu7Vl0DfKQW9AarYQt+iwsKf3RvP5oRWKtB08Va33u8ojielsQRN2QwkR+VeRXK9nZxq4c pXQr7k07cWNsO7BQOe3wXbQCxk1r8dJ+3TYLmtOin324ucrlJiE0lxQ3uwjSQheq5vbo6K3373Hx Nz62+U750BE6YoDX+/dB8TcBIRyDEEDlF//6jRAjY8nOLyDbQnp1DfWKFJjzCsyFdLfF9vL+n/cb +9kajNQKnx8pojYCzhaUItLPmWQnmU2v1a9qxdEA51NhMC97HXM+uswB1/LWlR588bykBclLlmsG Cy5j8LJusDqpRyVgkDJ/jSZgBNdi0qXXG0koiebNvteP/UGnFxU5VEhVzEj8ZBgFQ7GiYyuymgcM 49Uj5jSBWrMefJEufOCP7Zb4jMnJ2mJCxyZ8keNGL2bMPEc+/HH/BzOZxHVYEk6xS1qzZSdirRjP sfEivagFZgcLPaUJlo41N6Dvk7q6FSarbjfW57SrFb1QrOjcijDaNP1e63gxSwdy6qu30bPoHqSP ndfHgnq6jyi/oZAuL9oW9OIo7i2k2upGHWGT8zs46t5os7iinB62KKefoFaDZYrw8CXKTclaLbjH QQdXkRF9DxahJoDaNNuiUd9maKdh3QREpHZOHR0146vPaRLu54X7hbBlg4eIm6xQC4FpfldZ6r3o suMZorhUH088GC2v41KvIyWFxp0nCxxQzMCtp2mxiWoF+Wj1cURKFilZpjdlIKn/v2fnFyef3t/9 78n7v18jSH7ttn/t/SCv4o1M9oNo9g7v0vSQb0g8/qpvBQA0oKKLsQJV2NtAPOlg5jNpMiioPGp4 qIEMrf5FlWS3VLLDyHgWnHsRpzlklfx4kGZRMRwJBnQ0FtrQWgZzwIAONAZEt2LWguVLFSVV1HQV ZYAf88610Z79FtrTWDBmRSi79yiZy/m0ggbzWh0wUdgqzn0WfCIrfVH3gH1qeRNzOA0rrY2PigU3 YsGnyATSprFWBPcxPEQ/3paYrpdWrQNXx8fUV9z9DaJCTlS1eXjugFm+PxklTWdVjQOi7SNjLE9E B0ZJKB6GFzFW1/C6D40GUDD+WUK1E26I33F+eVTiHyVdfh3gUmwP0okk6umVuZZwI38NFO43y3TE tflq0f6xygIYCUKtJnxWWDsFWAxhb1jGv3NHsio0/Zqg9dMUOMmUG8mUi9W/YB2b6WqqDVMPPZJX pIQHtmIdYoHHZCpWXyBwbaRVRBXZeT6ky9k5yapMUd0OK6obLjZbvWvjk9bqLP+m1qCgL3DZUnAZ 6hP4Fhknh1i85+s/n9SG61yG8DikRsservQwzRFciaWOY+mQN81MDhymKGRAD0YVGo/Yro1Qiy4k UBlQa5g8pMsAONEHQj8dKRIrOrYix8csGkRJ5x3ZkAoWsHH+Clte6w/fsEnp401/FMM5NhzI3P44 L2MAN9DFqaIjXRCF/WY7e/geLhfRmQFepekJU991SwE+PmImUbyxMuMjdJKCnxU5Eobw0+SNpA5b qg7D2NIk6kVb5PuyRb4NDNv2SjKv+8Nwt4wnBapzVY56KhNTba+pmqiQ6DJkU+vtDmD1tkexEMON Mje2Ox8rkE/kGJwDPnMshWuIESZb952zEgeHCAxagyCD1BLL1hKVpUQm4/u0kZ4F10YecgsIRStR dZFIOS9SrkjA8uUaUpu4nrhescNHRtdUelupQDebqiJgufSGgjXYShLCs4gvkvXmZb2F66lXKc7Y s65JxCvD5kw4eKY8svAmCluBGAybRWSQo+IiGsfMqTHzexncux5aYF6IYUUce3xOY+h/wSJn1O/D dBhmAJFswlw0M2RyFKZRBmXGh8SGrm1IhDSwDj8n6STRBsq923fXn96febiPkkcxbImpVBjlgZ8Z immLXiomdG1COvdLo3scsIHf1caL08FA5IVyWfA/Wully5c6gk+PmxDNV88DkdJxC1pTN13bwtLx TjOr57x/7ZWzg9bKWS0wtAY2hRT/SxX/lxB7LXOQ5i2fk6p89RUEmH69XkYfy9JY8wTzIIt6fKZt 9TFGjLeU8ayc6EvozK3eGBLwJeBP7xVfgBvMBW4fh25pvot5b3HvjVNwGClkfInUZNfyjOelBWpP V/+qStxYKm6gm2TpdtD76VJx0vmSEl8VkA6OcKKj5DW3ACx/cMJ5vwZLcobRBCOL+RxTjFNcR41T PzTU1BzoQDFRCmruuExdidJAsgZkcWpGeZXD/iWxnmvrBUGZAZYL7J5i5VqJJguCEc7sY1pGjbDf SNgreWwSYTlVzOfYfPN9DX24zXaeNqMW0ysQTQsulhFpYcGO2M+x/UK4lKlcPGxk4Po7DmH8CF+k 4DnliuSIHt9eqP6W2M+x/eb7HytXJilt8KOSgcPRSYwUYZb/TZojWdpYKe76SuOus2xXQV4F45+s EOP/FvI69w1sY68v52KvB/uSyRxnMpoV1moXUCIZRXEc5Qpoa6j37jGkZza9V0RYxge8Qt2cNHKY Im7DPpFeDEUmoCmI6d1go5YV0ctBGDYvqY3z+wSnkHLQmDcjBElxvsFC/tSPMuzX1zwY1gVCtzaA vpOhYZDr4Qtsh2e3+pDs11BZCpa5FJZJzhcqfYaLSU0V7AWLzU+PcMpXUBT3XlDf9zfvlWRCx5nQ 5DzSCTKC20wuXGg9avTGdDUDQwdR8NqKZFjHTz3+abukkXeCfa1NvdAuCDLrjT1X6GvO6Ws9VJfe m8OX3W4rKE6OIsgE4Z/h2529vcMd/NEvi2GKdeFPcYYLsd6vkRoq+ngI+OXtzn5372Vnb6+z173b Ozw62Dvqdv97h49g2fNYtGj86qdX54cX+uMfM/706k/jHiPUtx4GRHo8TeubcV9Omly0/9IbpmUG cXrm8V5d3zH0jzvL8J3LBG4ShZXrTD+VaLj/5zo03J8i8KvjGaOSdgSAYSv49VRxLixMmGmP5CaG dVyQ2OKCWnTUGXTi1RzLbue1niJdIJqlr6EREP6N8G+m+TfnEFdIs7/kYG0U6oiQB+zmoJ8h2fcx 2lXaDShzVuHE6MpoTNMAmTdC/EQii+PIUo6hU+zF0QiKtrDQwnTACWQXyf8eaCC+DDrxWg83ECM6 h43AxrDAbcgicYlnOc0HwsSUJY8VDoBwP+gQpT9KxqkNvtVHcqk3pN6YrjcIXZ1999oDxletAeM5 JiEK2k/cseKvr/49FYB8KYCcKwk7PMTIAmi5XuEAoENlBZUgdqaIZofETmnVm5WhEXnEhO4l8epr vQ1cIUpwQQgb31gIVn0S7pYDvcJyWh3LaSHzpOt5JwApMTNtDcCrEMJ4F5/LyQFlxph743rAPfWg 5rqOwPyuYX7IAdJugG4oSTTCUEvqOEMcFD5QZmnMpZLwIuFlA+EF7+Y5dDAAklBhcoZrXFHCSqL1 HQTgXePW9NdGFsBgoFQVEmC2IMDoshP3K4OhqthsZcViM0csqtsWJgLJXbUtIbfBDc1BHw0+0go4 TsPSNpJuCY3y09+IaT/XU9dxketZQBTykFuAwzxeba/75vXh/gVRHzLivp9pLho1jRfbhlRMjmIf 88rJEYLz251+1rm4Ia1JPCuLTdIzGxqGfRpNjDCPyJSJ1fI0vvEdTY6KFYm1vnqqWOsD5t02R/3G D9OadyWv9p/+2c/Ouhc/nfwh3Pqb/mueZQ3+a//T5KiXJBeQqKJzloHqjgJi5hfvps98FB+4AnrA h1KIN7Z6xHjbXlb7UyNPpHhKv5NxxjbscvZofddtkqf9umayaX35xynQ8g+VUcX13u6cggUYoQm+ UhOKQUHe/lAja8P1FmJ1cK1ZrnTVLfdKjf63JgRjhf8qDpQnBYRdVu+K21YSTbvilgmswYB+nqdB xEvNTJWmZgvdWKK32LWQC8BVkOF1b1bdMNett5jQMeMHJiSTtZzsG+hHq/UWA7o34CL0Q1ifgolv BhO/mw4hTWS8PgVsWMpTOYACkIQR92FkXg6obTcFgUsSsF2O++0c5HDP3j+YgcAlCUgScJQETkCt iAI9Hr08szsq1dHxd8oP0c3pwCIJwH0CmJOX243BlEFNSrAGFRO6N2HLpwClBAo6EWErWUum0JDm yqBNAY2WYvzuEUMPwpPxCP8kPq+m8dYsX6Ho8Qv68NBzI0OTh5Bboeg9gHqvdHQi8WWp+IJeiOCI JgJR8bhoF7XXEGaxw4ZW6dKWk3hNAw4rJ/HhNCt/pw+0dSS6b+72D44O9ufrSOwfdE9/er1mHYkF rtp6MLyVDqUlju31KYszTH9v3z9kFE9Z1lMI+2/N1JYd6IgR3Rf9tm8LU3BZaaLKvFaIxOUqgxg/ 8FUsUuFgArYd+CM88TF/SeAhgYccwUPNDF3jzDIjqNvT7Rv329zNIcTMiWvbyYzAggqGhyozAqYd C98LLwJc5+3OxxhrCne4YEfMZkNsxm8r1pWz7ef2xY+ZQfEUpGyiv4WUvRaeKbXm9tSaC1enpgwq M4KjbMuyQMunZEbQIrM2mKs2iNLv301/FmRiKWSC0sQcYRfAdyr5EpGAHPEc9OGxXPXLmDfG86go edosK7abWbF9ivYoVP8gCujTBAiHrrDvlaQhDhQoRVclUiPHEEb9Pr6Mrnbaa4LVVEiMuxnjLubt 0+hnjoWIhorKNsc87wJfob76o3GstOB2y9ov8h+klHNcyo2iwbBgtyOvK4ZZWhS4sFqZFZooBiHM ibyPVQz4ppePVRD1o8Agi2JFx1Z8oVdh+hHSYQ8qNgvnXlrL01j0B08rB+NgZy5yFM71OjU8D41c CHcOYZlYG9NP7i2Aj66YE2Y8Erhe4PrVwfWQ73xt5TvDku+Odj6qLEC89wfKk3OBci5wk+cCb9T8 l7At6PmmJehZKxtLMeK4GKGiIqzUOzWzoIolBgcssHxP9SPnPPoSWgyllV7p6lx3daY41MAKLgKW AXq3IB2NfXPlnfVYSRgedssmOAXpTQynIKH7L3eyxeW8lGTMbEEQ9Wkbg8TOqN2rr9K9iNMcB338 eJBmULYbSRh1HEZNjw0/5GEYME/bdTO2CU97l04UYDGNrJBmMq4uUPOQKbr1QlCoGNGxEftlgauq IJtCGYHVZiv/ynfp0BJkIJH6Rj50LIIcRz7pgo9xzERNxHyOzVdZS/pt6bdX128vIGlrwnqLWrWw FUI66KlionBN6XeVpd6LrkbzMBGTqOE4agzLJKRa+cVet0vXYn/xYyCs3gDDD7qtjZ4n8fApvrsX DZIUX6vr5mrLUkzo2IRkHpxExzlR7lBJfdy2rPA8ZGiUWXZYEiKT40QzV9N6kw3jzNVb8Fkop8lD /qE08B6QHd02pssjZUdnqJJ/AlXZQ1GVXZ7E9cCrvW1B6pGvthDYDBt/xSxrUZUFsXV4kuRRW/0T H93UavS2eSRcrbW2L663Ntdb2EsznxDFOpoxNF20BAmsVHlx6uPYE0ZUgfJzDYOPszRQOZ0nvgcT amJVUvI1gD7bVhVNv6gz5Y9bfQnMkqqe2Gt1ZDS6qJotzR2FrZkgkxd+DxQ2/FYAeU3C1bdiYsWM JZ8bLPmH9J2HPq0ja5IhcUa17Zq0XyIV8v01ckHbaFegufih65kw+SHuN/plXNT+SGZ8aNAIf+wC 1/p1CIwSXytu6BjT+oat5kiwV6R7HWl3xYSOTUgu1/ZDM81fQ4iUmnoLoDg39Rj4oG8QuU+KIotw fkHpCYb30Y8yrx/7Ay8rY7UGppa8cs/2lVvYxrGo8dL/+I+O/fUfkrQcJ62ljcd/4V9EaOJg8y+x 4B/TgpwlyJhiQdcN3NN8kKOo/of44Pb6IEVKz7s1p5Zapv4X/du/Pny6vRMf3AYfrEvqK3+kKlOd 0u47pEr7fLvYlNt392N8UBvPu7oWCzqn1cNedWFpC8xv/i5RVN8c3pIDKf8CDnZbjklxXIWdC3Dy wNDOwb38+QyS5F9//Kq98u9ZWo5B4qNfOop6v0glM3Wwk4ecwChWP1F/qB8UH3zczU2aOm+nACH5 4PX7G+1pjX/CB/fFB4+p2G7xB9zAgOKDM4SWJ9Ncts+CnAcVtD+SQHWuSj5sTa4IHzxo+KBdrD58 KXlwywT8JA/+GfIgtkOiEFesO2dlxpud2gfhblUtan3wAMlRatGt6ibEB/8MPnjDB6g6GnEx9Sjy 4KuGD54n5UjBQaklFB8UHzTESFsSALsjdhT1xxdCD1yKHgh/o1q0WnU1/veN34wP0l+W2YT72QTM 0ZQMq4yHKPqmEUWlktlaTEYqmT9AJfMUpWUKkYivBunu/II5IUjY/AveeTjHO6XX3zqx/m3zzmdB 1XsWDynV6lLV6kleiRsaZS7cGI0wzCdpjx5WyjyskxVpkMbebzcXp4evDw7+Ryt0fej0okJqVce1 aq4KPjdAi0i+N8BZ9IQEbqE8iX2yWH2BFBdrnENqmYTyAg3J0cIgDhUMxXyOzQchSqilhd4EGoWs i4eTlk1DsVxLlARxCQlS3jSDcWU7QtS7NqTeVaWCaneKzmFkyAZ4D3Pv9t31p/dnUNmc+Pek4EW6 twW/zLIil7knl3CK9oJYsdYtTtQkHktpmmijvkY5J4/Kyo3QQ7JQkh4cpwf/SxrhBIYffJ74GXb8 Sba4iHpRjAEbUnwOHTYsNrXMBJUK5BS44Y2fDNRt4WdwyKMofLuzt/fGnGe0KO8GKWzH11j2Y3nl XY9fRKPqiqQHjYL4vvUMoi+xeX0J7GEyW3duLNAV/9n1KRWVPDRqhv+h/4Xk42Ql2jUlW8d7tATt CrEdEs6p3FwQEChl7R/s/3x6sNO843pb3EOBwtx6PTXhRfEps0CZmNLiTN4NIQ/8dmcUQQ3yHUnp 7OBvM9lo9jMt1QUbu+z/efs7JR4Zs8m+/3KhYCHPdjfz+DVy5nmWoWO+Ufk4TQBy0MaCbABLW7WB tooFRHzv7PryVAv9ZOr/MMOAXlMNvJmjFV5YIrGm1bVIm4YvT6VcclyZsxwXLaKh5Y1hPigzEXCT peMsIqEmxfEFmxg6vgSIL4g6d8N1XIR5FrlMHnILEvZKGrNnYUkZQ80bQx3/I82G0PRPdj2FkBkj JFa/zr+OI9pc++Dfe693vf3uHviKU79++0gH/PZfP1UB+AGW27N4K5/FQ4rrzXW9S5yxzhJVdM5w rK6Yciz+Vy5J533iCug/L9TAKV+uvvR8Fm/ls3hIcb15rrdw8TAklgVAMj2Ux8h+5EM4gVgXoZfq 29boKHq+AfzNsUnTHK7eD8V6S1kvL4NAqRDXUej0WaagLqft5tf35j3Ma4ZtNFZqaKC4dIG4NX36 /+xda3PbRrL9Kyh92aRK9MpS4lddu4qWrERJbKskZbfudaW2QGBIYg0CXDxEa3/9Pd0zAwJ8WVRA DmJ1qrK2ZO2u5J5+nT59GkAvf1IWDzbKzG/SJe4vKkhrYIne53poCbCFHe1LQHGMKYFagc3JCJHf 8CroijDZ7qL//t3Nu6vezcePvbe/X//vArpkTi/SvUyxoWMb+hjKQwlpfgiadJEsnDtBa2uyBuV3 yRP0XP/8LE/qlq3qloshXt7CsYHPSTrLPeKQ8vs1d+Iw0/fy+gOeRbgcB2VtCTOOw8yGKHJY5Yt/ /f6h//a3d/+6+fiv04/vL39bzBtiRcdWNGkevEmi5QEMvUITcUcFmz5Bj4KAswndUOUjIMBH0zLD dRdMBjMu7CTjuybdpEFQZhnJznho0G0xLT2fkAn2QCYAWnuOrB0lOA+EF8idAGVtW3H6WYaVEDQR 2ALhT5NOIAUOnl8TDzgtJZu7DiGwIro8RWRshgJ7P6d5wWs8MJrGARfqtUk0GhfY3NL4oTAvO2BB 2/LhKBuQXKKDxDRwgUHBjq1Ytex3/KVBWsahbgfzfFjGwoHugiCuPZ7XCKJAYdhkhPFyeUZ/irte SU5Xv9DJ63JNGiP3Ky8IpYkasdPFWJHAvgS4WcupD7W2RdXQHn38F6Nq2ooDiaYdiKa8SMYbkQim ASZiUlBLQf2XKKg9X3AVx7gKksDKanqaTku9vkSdjxeBdJ3OknlxFoXYm6PVOiq7xYrurbicuGnI ZUDqFTWZbXs5k4sB3RsQgCUdWUUijwpaXyXoAQsNZFczWKgDEjvI8TIb2mo2RJHTTJuXpwe2PtZb /lKcyeTyf8DaaSx+/nmF+U0MF7zOPh4f8SQ89cWfTLGVivaA98kpLYxIfYI79VxfRNGSKcxrzdO4 pF5dsoL7rACbTVUGySKdDwiYTmFKjE9oMF2/pK5ljRJALMaiSCBiQfcWDOIIvsYTS5xcyFFIs9tB ZwQGpHVGmjnQSqMpAGBa9sJiDDWxIhYrdgIpG3CnY+Kmzed5oBI/i1IDaiKmQicc6DTJ+1S25f5J Gt39AGUPVEldX8jBKWtrqe3HU9l16MCuJkozS6puMK3rwh7t125v6NL6Rf9DH5IK0P0I6cYAqi7R VhD0tj30Fo/sKZ4Z6VzSYr08Lnlc7T2utdtaH9RMqx5aqSwun9DL5FMVRMNKWxU1cAxhPVTAKKns GeNn9F7juP1cKwDXVgBXFTNAz4hTyOHCTMMsnTAk+bd+Sch/YUx56NHHaRb9l3PYIUgdoRjQcfPZ D0CcgYkAJH/X7/e/9y79TMtV53/jjMBSTuhURvDB7G4HkLJUt4+5uj1GIKdMYB5YJNUHVjkJzThv +IVsdxrBwyVEPMibn2roHxZrq4+bWUpKqbV35xHalmADGSmsTNBprcxhkrBcJ6ylGsLbmMMkc72a WuBC4koQRc1wgb+ara82b5qpzRuUY/DJSQOYYHuKNAcfb1UWp35IUA5rvpubS56+uXRgY5GIN+8H B16fHPSFCCZXYJgWJdgi92OiyUSjhLTAc1O00CIZ7EscGqD5fkipI0o0IUMSheNEYQM/lgGtJa8b yMIVzptDIi30pikuudzxQZ4fj4+f/QHrXiuhLbv2wnoopcE1sZyWfZFQIc1rkw71z+T5RrtxuTBP 7UCH2oq0wbfzQx69eP7s+Jx04Duv8zN7FeN2Br5TpMvXB8Osd35FIvcwaEZ3Gciw5j6D/Wn0gM38 iDsYsH3lO0J915Ky5ouHKmtuMG/X3vBX/jKtee/vv4/5Z9+gqCqTiVWTiTeiw0kHQZaa2g2w2PYe ueFVdi0a4YdrZJX7h50NP6S43irXW4utzgv3Z2sxkCtFmwrezd1UzYEPfeoOe0TSPDtunpf7LIt5 FLDYAuSxpsEWIzo24nqAo33TSB7oQI/siKP4kgEzyDbRrqfwFEWCkVv29smwawsOugPkTVQw9pMo n/DZ7ny+hkwaMXpzySp/A6G3q620Z9F+NJSCcauCMcTaONhFyp+wkBYogKTUO1QzDOErqR9jMa5D 2KIhLb7C8AMZmLmG6tUX8r0RzVmsYh88jCp8s8kUYtASFNh68YdDOu/FhsPspWTBnx2wysQDt/JA jqDGirwEOk0LYm7yplJeDmgHjTbNJ1g/j2hPdKJA5Qwh+IAlw6LAReVDiaKOy33Qab0xtgRpGlaZ j4yG2TTfKecNwjOVwKq9dNi7VtltBJnN787S6++NFcWIjo14C0dLsx0ERGnQHm2DtrZurhhJNleT oj7kAAofQ/UooY1ypup7/gC6phxYihRsiXSERC7kfecCi1opufCgVluUOhfP62XcJpul2Wf05pzc 6+bcxdVUKbi2KriqBI2aGN1ODorZLZ20/aCt5qVQdPCRCeiI1R1w8XxMmZx8E9oOkqUdZ+kwyoM4 zUswxmsi5fOWJwWD3DdEZSKY+VCJJgwi9fzbNAJJUEYczoMnSmKPaGWQ0ZoqyNSRrjDImyqOI4g0 kPw8KGeAGPxsRMdVucnJpTCT7ZQ97MZWoFeYImxACBkvM4hLXDMcKqR6CE7Q04S48i0kATyAZb0i 7eEXSQyOEwMF/frGKwWUEc9FYKwCvR3EGw4psiCTD7U+ph9jbGKrNCR7saFjGwY+pQZKC6CFa7kN rYlGqPRKiHOAok3hsgCEtXpiPsfm88N/+9BcKvQoQRK2JOz2Evabl6yUcmnBcbTWmFoV3nuRTWEa uiwY7nzB8AboflUeUlGRBmmM8vA2jW+pLJyf0cjxWcbsCMejPtVOUCVFuU5RmNTg2gnG2zmEV3l0 CpTAVhFaDJJu3uCeDWY0+CouDxVVJSwUyX8mVnRsRWMbBugwYpsqGOoQDod8EOWH6APu+I/yMQkL 0HFaGoFrB2Xu63fqyWgH5YkAsSuA2IdoPt6cXlKndn16c/k99WtJrX2jGetE5Tk0kjVCi7hLjgrU KGHkaJJmskHqmpZC3Xc2UWEEAVYF36SzvHTuYJ5A+6RxTeG1SqmaLUYd4M1v10JqcG3CM7ICueHF JdYKGEGfQyxV0KVUWQPEFsAVyZSOMyWZZxUSRkUpAucQYn9V9cNplAZhzPEjaYWJ/1lCqWs/tNMs zQcIodCYkw6tN8AtsRBJT7OOUAJ55uoPzbtqaCi+SIi2zmdeVLZwh8gFaOzfKaEaid7aq/YAsrVU o3/S5V2+KIKwgH7IABYhNUx0vwIjLarE0PR6iinCGMeCGjFOp73BXQ+/SBJ3nMSLrMwLb4K0HDMc odtcNLZV6azBCSrWdGusj4tZGgRMKzZ0bEN90odZDypjlp++uIveaACCH46KTcjI2tT6BIk+AgTm t1RhC6I4vGeOlbs9Ljr5UyC+0yyCzjIXV5WYMvasbUWmuZp0jNEgUowjpqjRdgA2CatYWMXq9QGn byDVB29wU+waXBWanzcIDoxmr+4BA9BYkfiZXywZwnGGWOwOILPPEBnncsw6UbBRPAE7dexPAX2m YTS8o8/dMcuR94HEiI6NWFVkBqI+RLlN9DEir6DAXljRk7QgFIk9dIAYXNMcDP/mCqMSP/Zm/h03 fJpbC+hoEo3GTLVVkynSQYrh6DROUZUCt5Cg4jioVFEDmZ3li6uFe7SD/aTJeEdTn2neO4agbNUo oR1SsaJjKy6Hf0Lm9Qnp+cbQBXB5gmXqZsSH5VRv6bdvxUfRR8gP2YFm6f6CcBt0KLvGsbinBueS PtA3ILH6UiRWtxd03PC0uxak7vm07+/WovO4jVgoaSFfEI0GxUHvDLP6AgjP0j98jHrps/jEB1SN kwFK++Ojpz9I2fCgy05d80i4mkisOi7jSXbHzFM1IFcb1gz9KOb9QEwLMEKliQEcsEHgaN8Tu1YR LT7SpdLHpIEdqMvb/+tNZ4L45AhzEpe0z2jff4Jji5i3JTCfncXRtXhibfDsVQQcnFNpNGgFpjdN LmLlY2zKa/6smDXBOvmIj6HyUVvAXnleAtMCZQo9Nf4LzDIVL3QcRe1SdQVtWR0cLM5UGLpd1KAB ud7ErhZpdoCcSxzN6B5o/UDIpjh6QygV7TVhuaKJJQPTGoOSz5zvWIUjVuog/htm5hAqBPxs1qHE C517IWzC9zZZ4AYQY4k9GR/2yaegmJIqDs8OQFtRmGRhLVvRETazmX3988fffzsTIzo2Im77RCHR UnQhitqU99uIBkA8o9WTR86epkCNRfjANccbttLOB7K2dT7euMC4XysfmJAJk0Vg+SHEEn2MRF+Z /y1O6NgJF+qYHZQngkV0YITRsV627+XRJIp9YAwskmW53VyPpSi5MsjXzfmKCC5VbU1tEGcMCR2O Qwdp27DBUBrXSKaLEcXzzhH41RefqjAgT5bpjdpMTOjYhNTcgKEXT7wDY6AnEDE6MPwLMvAK8hec NWSVI2RxKt3Eio6t6LPyFAkSptnfqLdtGBRTmAOqmq1fqhDdEdgaHGY1qkQ1mVjRsRXNQqTGk2jH yYhBDP04p72mgYKQB9AJ7pYqdzXWFeu5th74iXHq45z7YWMbjQ9WUL/DZmPXhIsG/tQPrIYfOI6M U4gNHdswKsg0kF5Edou1wbS0wxJSYWMpYi0NWPBLoLB9GIoJHZtwmKUTlJi0xkRJreTRCiIoppuz CNREM0uhP+dMyXBhNIhIUBMRlvxQbOjYhg2AyHoYWggYZ+ZnvJGg61Z2PSBKupKxKhDn0lc4n3TO u72l1RGv7qIa+QXnwEqdm+IVQzNxQ8duiOtcIaZguJWmUyHHVPQReZlPQcsXpFBWgPawAoQtkYVd H9LZovjfuE5Cw6Oqw7U5g4YNeQ5ejMQSx7EEdVdg1QPMVYRFWLBm5yAt45Duj9VtLDZ0bEMtEmDv B1UdECaAITomEnaCvxXRBLC9h/NwFtlH1QYhiC/RpJyICR2bUMvksDYeeReONObgwZDweWVOS2fi w39DpcIBDjXWDuUWqVjRsRXBHMy0eBom7jiuaa54TTN1G6UlPsowXB+lzJ/gYCulmpRq7ZVqELQ/ xgRBHwUl8YZrcxS0rzN7+/FBGATCIFhUjKn4AEuZi/Q/9T0Wn6dbVJYEIFuTiICmJOUpihRBiZyj RIBl57wOe2mAD6zBhOoLrkljnEK6MVFKM0sm7pKmGC2ZK8C87UcaoVJvRaUuSHSD6gx9gphNR6U/ HffOYbHzMoOlMhI2PwTjhzSeKr+lLYh4kkpz3gE3ZFUVdAQkuYyuYMrAOjK7AdbNxRAo/jU6Owys rTXFEx33BPCmOPpMNAFkO/DdMUNBkEyR9Oy9F7gbZmA4VcmR1M6cxYI5xHwvM/c6jXrS/P736xvv w8cbqNgm1MdVU6/lDp3nKI2bsVLSOI+lc+5qCcUjCKMipuZpmQVK7sCKanaLqtnowk8QyT/gfOQp n530geJ9kJtyclPOm7X4zL4izl6VD7rTrhjhC005VvAKUgOlXVheaxYGfydqDmrAdd0xi/Bbvl9L d4X7+GzS4w8jiiv0NYYTTst5UVLCgCnjKVL5O678K9yE+G2wFIbfIZZhSTYAzRxRUmHQK73uTDuw 3vEL79PV+enzo2cvHqqDJXpIW+ohrQ2jZpWCIS0tZz0v9MnVMhzqzNO4ZHsuR1BAKLF4oGMPtCCI CaXwOgDPOO+dZp9ZuxZHAOnsXxZZaRbiiJMitizPdKDvnmALPeC5qc6EVKMMwGGI43SG5o04DYCc PT+8RSbEMQw+QEaaEIbwL+7n2P1smKy0hclmI0V3ZyAcDR/jWXkEJMXHf+jTqsA26d5MFCiZjT9s Nv4oZrLyQ3Zg8Hx/mc4NEqVdG+zdU6J0aW3/r6++e3L00K5jg3m75qj3NG8rT/ub/9ml29yy2xT1 3XE/yaNt/tbIEy+zN1TMT0nfcwoU9cFQctc8Ej+UqO867lIuNGPXB+OaaDBajNf2kCx5RlBP1cMc NpH1HICCbBc7n+5qboXWEvSgewbxupHZXCSaBbbimJkGuYZbIHo8oB/GaQqVnHQoOIFjD7RAucHe 9HlSsJ00SEDqkWGUk/I1FvqBnpMwIaHn2oxpInvhrrUGNY/CC1P4FqF0tPDAuyvEMbQsC20urcdA zEQL8/C6mfigYx+c74XP8xtZCPbTJ78yRSe/4IuBWRcE+zeAkTXwKvZzbD8bQ7WXGWITzzHA1w5Q olR2i6HvVxAH+KPByW2NIzZ0bEPaj8CAA+zQkk4nUiXKKn4pqNyT6L+skcxM7rwMxrUq59Cb0TlG sZ9j+y1df0joNiaTMaj6ZEfMtcK5yrEciHkkfXoYZTlyZuzvZObRNXx1seVdAlLd3vL4GbNFGI1V 3qiOuV9TWJU+4oOOfTBTE/Tu7FfUmHO4hJOBbj9fmUAdQySceZsoo8aHjRoltqxaygIB+AeUV++S sAdYgn65VhBnIB2zC1yOUXn7QUJwzQ6MQzuWyW5QWqCm+Ex1JPY18RZ7+AXViHmLQ+UXgFhyaIDQ 4iZ4wEOofjM1I4yGwyiAgEH7L1VCxqqQsZaFiACCUtEfxFE+NtfDUDVW6LTVBGG1NnMLB+gY45tE FBb7OS5H/PDfKOsNUZua7n5y5wEySebl/4QoiGCvTX2whOleXIQzOVAuJXWeFJ4op1Rcw5uL7gYz 8j6PN8EaWXXTT5OEQWSrbM66l7QlD6UlkVhybUVzOjMYK6zA05GbRbPqsIlmATZk0+l5RA4Z0+RQ IqnjSBpAoZsVDXx4HO5RQdnsVvX0QU0CP3EzjpcotDoFDRhI32yK2R/WYsAZljDq2gFjaF95wRgH xFgXi0ndFEoNIZ8O2/q4k4CClMJqqHCnehIlkBocop2XI6nuZ+yV25mcV3c7Eg0JAjWlWhUFKFxP B9JQTeP0jjxzF2vW0k1s1U3oqsXIiFCIrBZkqlxoOfssdzBCiPXmfgmLShp0nAZ9o4iPxhBkFprI zsYRpkG61vSJMmHEDfAVIQ6T0ATCWles59h6pl/XhSWGdvAoDpToCZuWQwAlRf3KctgdJfbLDqBD CaFbhdAKWqm6PF3HtO9agukKpruorXizGtNF0h5GoW50aMxgKI805Joo9EqoxYBO+In0QK57oKrg YgzQMgAY+lsgHuuAT9oc3m2kZlROtx9jJPhvFfypOGboFrZil9JGQhMLErkfarV1XkyGn9a7o6pa ExPupQKL/by4wrQLrKjwEq72FuDR57/T+kixdtSyoY4GCWS5FINYe4VYcLc0EAd1HV4ZfKicbak1 8ktw67Lov1o9wJyGs6U1DWdYKEJ8dC8+ut4T2ZuIR85+hwRo+1djKoqw5pIc61atsqoY0bERowIO 1ZAZhiF11cP2NUQtFKWL5tXlqhjQsQE17X/sAwIcKEWaVTSWRujE2THNpePO19xmJMjX3gCEFnHk Twi/FyO6NqIhF8wjJtetQOvXRs4ldxR2pLAj2ztSsrb+7vOKpr5Txf0VHumMTv4mI83GPrt4/84j 7S6aXIyytJzS8fS8KMM7fEZCjeNQU+t3sWGLASA1xLDUCu6h2MqxrT5d9M6eRKoY9kKcheupY9UD L7QHE/7hVbxQ5Aybx1HKAXoEid7+ofBhXLe6mB7x+hAdx4YeLHTwbv0opgb40GxsEq+XaL24sBPR mGmJSipu6NgNQeUllm5zlMSxs+p47Tx+WmZTHI0gCumV8gFsIfNhTzCWw/auHREbm+hlIRdL4qHj +frYOtHYSkkEmRH3VDP0xDLWdW1Em+gsNxvBUpOvvf4/LmlTk09zGma2Rfr92P5pkUpCdG1C9QX3 pKngNIR6O/UEsaLajFgELxBNL+rbMZIRHWfEajsJnZ1KqJpBUCWWDCoZMAy9LMo/69Eb78Czj0aB 3oxHMJV06Jwliku3MSn0RBiVjnjpcc5G0G0EUXtRqjIJuMTtuRExE7xhSdto4oCOHbBKhCva9rkI mscnDZaKVLpV0b4FHwURSn7IDrC9RGPSaGvqs3sbZH27Rhy6p6zv0or2N6Da/FRUm8lvt9OI3fC0 uxaJ7/m0W4ldXXPrbogFiWqzqDZnBKF/ULMDsAgXX6W4HgVf5NZz8GMxtN3HlUMzbQQ/OlPDki7k YSUYsDhDAXq/hlZqBuou5XtOyssD8DVJDEWWSTtw3ClMg5K2QoVcIuSS9sglb54eAWM6pfN80aCk ZXKBI67ogvp5o6ptnji1BxXO1NCH5hN/uRSCS9l+0+4A7WUNUzpMR3DmVKVTLMHz6JaeITiTeTmA jBMrUXhIU35+CCqFCgfQ5+Jk1f4zFQtuZUEozAdlntPKHGZ/VCJA01OnqFftG6fhjZfkcTXV028F CJMXuNULTCEZmUWB9z54X2bZDlY1v51HtwG96dqjuyd6swRM1uIBXwjab3fViHhL35tT0BRu8jPu 1UOx8iYPxulQJdFDub8bnlHXfOWez+j+SMSGn/1bcSGXz3Qtyx3P9/cYYX7s/TNSD17p3mA9ebmm n+lAWXVPr+1UgN30cn+BmETvFz/4D0SsvRvc1QLfqpEqWok/8oK7+oJV3nt3/S/IL4ZJvAoI/2s8 5MaLdfYtr/u7BMzwBknivZ9Fvnealf/13vpZkcag+De+8Ufgauv+iuhHb23c2+1q52t/BV18vpsy CJ41coZ3BqzsoR3uX7b2+ZotW/Foec73vC/crM3W2WYT6Iso/SHK/Fvv2o/Th55KkNd8tOGvQF7z Pl/zdZlDo+Ma2Pe4BK7y6GCVdUFg+3rDoHcyWTOkGfxFBHnz6nuNR0Ml79OnvNk4xKYHrnDL2FZY AW2yAp4+oef1AWc4wA+CoM2Vkoc2tdFJ+AFBFDWDE/5qtqY8bioVP12dnx4/ffryD897S+gJHZi8 fnLoHfyq7kjSBHfoSTGjhMICuiN8MZYXU4hKhrTb9tC+X5LQklE3JqGHiEZ683+uakdIfsMN0Tg/ OPTenl56T384JJN69AAOCdgB+P/05cvnQn2TJNdekluLulDs+fH4+BlizwegLwqr7DdPPB+s2J+f eP34FvflcNgDa7YHP5WgJsU4uaKj0T+1+BK+9IHAowSg7QLQekXMeZTxLvof+sRwnLOdcw/3Rfmi rckdJu4cP9Nxh4wv8gQNipUDSkXNhO9x5O8YsIckAEkA+0oAL49+RAJ4jwVtUE/PUHpqJP7Q+wW/ f1tmAz8BE5U+oMzwzyfer/jOxkgK5jyXpIA6RdNt/LiBZpt3ifF7GqSx9w9oQRFt9YdX88+RDfvx CLonxXiyAzCla7gsEDo2iUXqlsZibul0tdh/PVVBhOPKvKeERE2NwY9wTvheiVt3x0fYYGjf17pG qVi0F9mNNsgEk9jfBh31Bc+en5wgLZz7/8axqfTQ+wfifz/7/Bm/pVTwW1qOxom6myeGn554/5dm cg61ydh3mw4OKs2Wtz4AJJsYTHAhEx96H4MiHQCMR3w5lvgiZWd7ZSdNbo4Brl8kQDAFXqfcLals z8vgn06/IIvxPyc/XV4eeuhb3t1cX3g3197T45feMf79B97pD0+OEBX75YgODCMUnkgofFgofBT1 pPyQzLJEPLsu7rDPOnt168evDy5jXPC+wZl1YgCbvgu/tKz9YDu5VsKpWPIvZcm/LCFsmPXOrzpP jH/za5qN04QGQQpXQWMUb9U/775MowzzH4Konx9Sjvyx+jP7m090Uc87ORbdse2D1Ian3bUg1STI rn3arQRowRNXrYqL7tjWJJztPXLDkLprHokfroFyi+vtX3dsw+Wc9mF7CYurwuJapostUPDrXBvg EDSXQ29e8hCuzRC29xN+R4OyX594l5iL+ndCkugQSWKOauMCh8eEOuK5lCQp/8q7DnAdIItS3ASA BWvUO5DuxA+7M6oOM39Y9FZeGusdHXnf0Tk/orziRsAIfUf+vVivQz54raaFmpi5kYCl0cPAUsni W2XxT5enpwbNXwHmnwCTOGEwH4NMQvPPVCBPVKgTrQPQX1vn+OHoiCjVP/uf/djXReZ7H4Io9MFv XHHmOFRLINsvvUt8fI3zNvij96bo/GUHoycJNFsFmlq7MCe6zMvO00yFUdFjMVnQ7PrTadykbdEL kHKlQ+VKNdg9+nEH3iVoUAeGSB0jdvJuzfNj2utrIgy/YL4CojVF+/epXq+hpEDNKpZvbvK0lMjR ochxcBoDTbC0XFym49PK3lVa8kVJHA2oOHaENWBlKocsU67k+m6HjGiM9nuussSng9hwNpyOBDrk xxNLtYazNnqGo5eSKqStbY8OuRacplTx/OjZC6QKo/B86L3Te5hvn3in/mQ6UHEM4loVaT7eqixO /VDfM0hjwTW7g2s2EWfe4iDjHkJj4lbgCIEj9gtHXD+lLQ76ZwViBvrr82NGzF4uAWayCyCYbovX ut4AJMHd4OiL16eNgDwnneBYDQtWN9EXnr28vgG3g91E6dOlT1evD6YYJ6rsVh28QVik+zwDWo7K 0xgtHToFktuh5mDphnWY4s0maYHzPai/QI+Uust1jzdNcZhnAAY66SMFMGOO6NL3kpJHk2jOK6v6 FFzoBCFk5PgCPS4upQls+FCx2Q3sMEHbt0LbN6YB7tXBAdAb7UQKkK5cuvL2uvI3fRYA7IeY6HBA 8KB5NATe5/kDCKzRIUpE+t3pJUhN8lhrkoeIyt3Q9blGmeyFKg9w0hKlSZrEd94Ehzi0SJfv5dGE rg3GSJJc4wgm7bpeqSIJypTzEnN/YNFVcEEBk+AsseeHIe5CljkdjKRCFBaORolMFJwrK1TFJFYc FWTW0CxMVDD2kyifwKDUSiRqVrdogkuepNc5EKVO166XqVGUF6j+Q28G7SNWy4PRrpXCvyySl3vP njzlevNF1QRmWroz5C8XmN0xzA77TXOp/6X+b7X+J42S/ogKfTtXa9/Rpcx/rGX+eunWFcX8EIel AWIRy6Qa9gI2n6YRXud3jFpmHvDJII7wXr9v/50KdLUVdGUxYoogXq6mfgbMwJuXhzNsj1FJX5UR qAXBHCIlZSrtxX6OCwrU7iGMMfIAFVOrRRAy/R4yBnC4yrrt2+nbyQcbdAu6FkyaugVfu+mzRCg1 P+kOpG3u943RMZx+4ynWvkU61XF09vztu7MDp9/gkxPEwg/ogt9lGRIVstgoSfMCeCqWNRvf/P13 1Dc8sa750f0s2aoWQde8bFGLoPZILzN+pi+ePzs+d/pM13LxGi906Tvfi1bwG8KRMPHCbNOPvZmf exM/RLmQEjDo+QwxrXIu+oq8xC4KDy0aP8j9XU2mmm0dZqByQnEMBN1gmiYNg8xeRUDp8Z/h6wPc fjnAb/2yGKfwj/d02Zc+EaKUfH0AnaUfek+f9o5e3ByfvDp5+ero6P+06+wgzFvXpUyzxL/Bd0z/ l7gDYr/x46MHfeP4r0OXPLzS0aD54s4UdOSOjs51UNvpj4gfhLTq3gRkGfsB/T57Yz7D//crv9ud fmPFG3SADBpjBon5DX4bmXtPKFL9eV3KwUHaCHowe4nMa7NGpvy8xhzK1L/N2RXTVkygX4CWQpDL hyGXXSvybJjEr4xq0a8UEf6URr38kB1ACMWSjdy8ofHqWtfRbLzWahIulfT7auqXviOqseaboX9G bvNE5Da3j8QbnnbXIvE9n3Yrsatrbo0fqiFsuOS/eyn8RG5T5DazyFwsr50n3z7sNLvdqzM19Mu4 qLW8pt28XGhqOlAbOXK9anEIu7CQdJrG6R2TcpuHLhvoSiuRsGtZYDEStvJDSrjfatz7AU0+Qaxp xuIPPCVcwsmkFVwH7km4Q3TfeGh8PVkEq2pnJWOBBCzPIMLPUCCQp3jSy8ApAK+RWAYsQOKDV8yj bXwSEpqWStJ+kJT4sVX8gBETVdASExSAmIVKxjS0nlzFBjW0G4jGnl4IySBvcAdqqljQMdILC3LU P/SiwsMuRqaCdIJ6hBj77JBhVaHkHoSICb/HkqH+LwHVB3wvNnRvwxCjUloBzvCL9TozPkVuh5mU d/bx4nS+PjqFojTWglNtUzCGxIrurbhsJiQ7/mQElSdw/W20lcHLwwYvkt63Su834GzE6ejOG0ch kQpB2lWZr3dL2o8X0qA+WlBk7SBaC1qg+ldfsOxELKIvEZEJiDXAy6AMncz4QypehmCoUOUCblHu 2efb/lOVOLJVHIEVf+YIAsSLlwRoMTRKgrgED4xVLrzZmHQsKNdpqvIkDSFSyaYWVrlrOgjs9zGL RlHS+xnUV+rAsZMN4RFsizIPhERKbmC6gRr7t1RXGppIo+QUL3RfYKLBI72fGeQXvRI9XpYXaYr9 0bGiOhN/OvZJ1ors2cdefhmMD3X9id5B7OfeftXCdiXdBAotHZPR1svNqSBpD6Q9aHOj1ErdnSIu XOkFcqq7cpJrBbY38ZNAeX2IT93lkYwP5O219/bWNgZ619Tgy0GaFLjUTVGQVhNzTKB56Y3qFP0o V1YkO3iq0hhs1RjAcFX8QM+mzfefEneZdXwJ1RCbpTzzqUSlJblJgNlHgCGRGyhjkuIUZpHy6uTV tffq5urBZyipmswfluqpnWDKvQvAriMs4lv9LGqrpRtz340BFqF/ro3QbvsmEURcEPFlfWdSTLTr WFp6I0eegnwb8BwECfzOLNsV/mfgOhjaAA0PgrSEAgQhPe2/U6l6V1S9D5HDpAHbYqSfz+zZkpb7 5AGps1f6REJMbhu0edvgTEsIzx+Yh6NhECa3V8PajyCS6STTLWc6hVo4jtMZcw9ySEUEjWdIoM7K cAjYR6SBXQ8NLdmzuJvyFQNG7MIohyAcK82ijCFtZ5DTUhBCg5In+UOwS9JMD/jbjzJSp6yoU9ZT tKcxWNlcdIQqiMhoRroF1F2C6irfQ+WJ6xPFHWGvUAbRFywA7IkFHTepczk4e2AvU7TsIQWjFIwt FoxrpzRGiNp7AR1qJGvC8J89P8EFNw3sI87PQFwuSGNy4gdjYP069DO3C0FmlkoIcRxCOH3zNG3e DmDZA6KulBB6MZEP6Pys/QTdnoKqV+2LdwCdSyLfKpETNwuE/4mf3Xmg1YEkqWhiP8DqjmLmD+6H eSsNTSshSPXihY69MI6Gqohw6RlR9Nq43kUoaVzS+D7S+Dkonevju6YIzl8lxQyIfjMLu4gkdrhu xCegw0R0N6lap9UjAZxTSkb4tLHsDtK0oHqC6q1C9U6xoxEVPcy9iyzFLum8WDSNQcX4+eHo6Nkf FFCwMKC+4HI83ms6lHLEcTniz7GftXlB4snDGDOPImh+Oz/kBt21rnWp99RdW9JF+gYkBX8QScHt tb02PO2u+e89n7ZoTF1CDBwOfo7Si/TaW6Q0XtByONRgeme4N1xoalzzP3kdsPkp/dEHHKbhA+ck Dt9+cde1x7oT5bNH8UN2LaMuWnIpde5FzXPt+OUC6m4NnH7eaAHCpxFuHVekj5sojt++L4oFt0Lu DURTTdpxyz3JtQIHFJueqCdsRWNk6pNJFCEKoiK+E9s5bpKRDidRgtkmxmFDfAD+0gZz8hBNH8OZ O6HY0LEN4VG4nEe8algRjBZPYUw9Bz8MoipQx8OgDkkGWyUDGsNQkp6WGW5pgSrBMht4onNW3eJg vpbwPYhoSjxxHE+GZQYLZrDYLUhzBHPT2itIMCun76/at5e0CTKSWRzJXBMBSxN5avFCHp8ktfbg obU9KhAgkhRhmWdSECZxKU0JXHyRECe6VdAvwhw71ntu42gK9nj7QVLqkq3qEpiQy+KUUpuRAjv5 6fKyGuZePz1pDHkX57meAA2uSSKwIfNwl5zuE4z3B8S9WZ8vTWKods/7H9KKJvLnLlR/xAm3dUKr lmJ5nbQvFdHddzIRgqoWiKYPEEQ16xqeOIFyDqnnKFmZ6oATWttRT0BL3Sooiwhprwb8CetTWJ8t Du7WVmaXuSrDtGfB5RpLK5feQHqD/fQG/VpHCvALss9hyhqmaALuPJwvWpha9f9xSTit9ASOgS7U k0EKLW7dqS3sD1W6wbqVM1RxIJs5zhzYkaWY0L0JB2VBVH6POztrmB5blcFLeNqEW3HShCZPrAaV lmsuVnRvRZpbsbqzGRysatFPvzQ69E+nXwztWgzo3oBz5jvauOnaskzGkFKV7aEqu0GcnwsLDD2Q 97I49elcH2sLeJMSRwJIfIxTAk22FvK/xBTHMYXHjg3NuEM6mGLmyJzaPVTeOAMXffHOnhxLZJHI 0l5keUMvChcm5q2dd0NB4qMNJBdMYtMznvZjhYzAH+sI/CGSjA2heRsglwQ3qcSeREU0wqPFoTSb Ett/vDIV2WoqoksSJDS6NjvvTrVcFfdBDfoUoCPIkxGzSrezVLuIDR0XK2C51bBnnThsZXJS1Swr XdKWqWJDxza89XFvtqQLfUz1MHQ3c3cKfYKfjVQBgIlP2MIlPyfpDC7IGvx8bkws6NiCNqUhlvLo WFoCaQnaawnWDiEBNgB/nhOcoQSR59AKBbSAWRBBzjlG41DNvmN6fq0Gw59J0HAcNKryy0YPWlFC VIf+RwkBMjIf/QkdlJ+l2WdGkXJirBArWux34JqQYs2GoF8rmeksDvTjpvrIFrr4u3rPA6qK8gtW 8xVupnML2jmcKbFgSGpVoaZTM201tNM25jXChPh+7IgSRB0HUR7dzTOgmd5NVDHG6VYrtGYiasri jqHHkRSxFtdexX6O7ZdPoZ6NW9ahxxxamqnjGEtMyz/6AnaWguMH1GjuqzjYAsvhyyvIQqzo2Iom NtYbU38ANTJUKowycDUzOfQQXSNrYNK3h1X/Tdd6kpGY0LEJA5UR0bnyM0TSc0qGlZPp2/OHc5NV X+rNojgWAzo2YJmXaBXu+G6E3cumwAl4MEshcIw+cG5LlWUwrrlIwBco2NhiRMdGrKpNvZyw1tuw PUQDaK/ERQnuFOsgsFjRsRXJlwwtCUIkjYQ3wm4zOSWdngujQPMDdUNvukixnmPrmUqTzEQYTOWS BMBHDMwYcA16XgTMUEs4KHPM0OCQZMpM5GVcYzP+iGoZ8Kuxc9m+Qz0KkoT8kB1ggogm4+40GX9N s3GaqOTQw3TVj9HwVP+8+zKNUBx773Hj6/mhB+XFH6s/s7/5dOmPlHfy40PFU436HXQmM1ynvTpT Qx9a9K8Bip6L64nrFQd/ZzHS3bx/iivmf9k+wMuM3t5eNBnfiBxqH4cAXx+cpmUWAcj8oGYHsEOQ Nz+FF7AootlKQngU8UXIgPpd1R7R7NX6e5aic2RCYiseJo9vq8eHmuotrq+pYZSAJ6whrUxRY72o aGQlIAg9gUocIM8Khm6/zxMrbmtFoiOu1sohair4SYQ5o8xlzRz6Wst5hKmJ2yI23E8FtpZSBk/k wQCuG2MmCzRrMxui5ynIkrF8r8XJxITuTXitucLN+V0fYr2F12NQE74WEsBpbU2/N0PcwE/EhO5N GIxTyNiyBxKJjK1maUkNFhk8lG6LG+o4c8U1kUms6N6KNECwVoNVtIsJIi3s8D2wwy/XaiGIRJWI pO1DJA3FJI3C14ty6EMrutOjkTitNiNMplmoMi5P5JrlniDZTQ2BpV4utnAhqJt05x5t3QAsTcig Rrj/YL8apcvMz0L8odSTHTDiUhVCpaWmXxrGbSVKYoVrgzRkcRIUMVJLuq8lbY2/rE8Cx+RNfH2N xZIAsUyENTCxnHvL1fVpNSnFSsLl1LdhXYivlczPVwEMGzMLfqA8MMaURNAORNBJikJl6N+mmea2 zze5wHGfqzYqP0MRA6K7JmZaC++g6RN4elt4mqMk0fVU4JN0I5uUOXxjKDz5MUwa3uFPVQIl1USR MEadAiix1H0staTLIRoLLHkRRFaPm7z5nAZBma0OtOKGHYikV3brh7xrYspPPRiisInVLzginQNk 7+N1PUNzN9YXR3TviAiYFBsb3rcm90H9aTQmjl0OeWql50oD6Sk64InQIMA+ugp3EBaFZNQBEmPH bi7b460DP0cUqO0sCSItiPSeEOmPVkjT6p+x6IM55NFbfpk1xV5CXqT0cF96NMR5uQrhHo4LRSgg pQEtu4ZYSy7GYBUVrB9QTgFEyxWnDtQc9qYW1fd0eCunGYKeLeRlMD5kgxoyiuWp2KGCeJ9775vP derUBkv/sjQi6s8r6+qwKsbbi/EeIuSLSW2tGjP9WkEb5vMpUaJm1lvnQz4ICxAQI2mxA4G1ElMB goK2vDpOZoMnYuwFOLdhyBzr6ho6PJa4gOKde/HO9RsY8EFrKeOAdvqDQBqnM8wUoOQx8AdRHBU4 7zUEUE05VJud+qlcbNgFGxpJoypYGq5tZVwtcDXHO00JxLz5UmzYgUiqHYs4LfCy/C4J4GrFjMZC 9XGQuSBLDBfo/jLlehfnR2XMt+2Yr187nhGqPBolKtNsCCipkrgcMZfAbZnXNpMotOlSYmgXYmh1 9B7qt3ZkYNt+urcNP6T5nzLZj3bGouTWj6MQrb/E0A7EUDKOzWwUIPWaAi1/UdFi/ySIIQPYAziD 0iaA8DGyoswihB7fHj0e95RO0PhcmQWZmzlZwDtFp5xDfFSrcLUf92UCJhMw9fpgiphGxeHBG3R4 F4lW7qNVPPMm5V64xLv24t0mIn+fVQdZOZLen2lI9Zo9qRTqk9San0HpWqss2761/QApnc22nQ0K KT5GOR+UxNFQFRFufqBTrZVcvQgS2vrsE6DAKLFGFSO6725q2hU19pSUvZIG9pAGrvW8tXdBSiv6 IKPUIVMrgrYsv3fV0EWzXydqffUw2oEyvxXVJmnYOmBJN5TFN+2ogT4TNdCHZXFxvcfreqIGKmqg VgW1plZJKZ00altJ7QI1bAs19O2MpseijLpVqEFGBDboP4nt8isACFk435eI8iagT+EK8SCOctyH BXeoomaaoRvGITcwXv/0qjIcS28CI4oSAYjqnU22G/ntTUK8GBJ8ujo/ffb85OQPgvCwW25uyRDE N6fULnulIEgPqz0lN2yVG07ncwIBk0x9InXK/6BvdxIskcqgy+Hj3wBbhTmRg6DGQTSTKS5QmpRn axikODvO0ntdsobchXqlNnokqtDET3BbJbTyG7mP8VatiMEsPSMue2Emlyh15OJWRxhf5IOoInkU efLT5aV3eXoK5wzGUYFDr6B3eZ/wmT9Y/xsfWD+VqtN91YkFIETRpIDYMCaUFUugcrz6gpAJq6hO KfbCsHR6VIzo3oiLkbTMC3DXzRXmzRG1ffMJqPtoQd216ATAXqymmcZBKHCv/tToWTrXrTpXQCtM gcMLtI2BbQcYaak+YBUxCMRpiSOuP82L7bUfJcWI2xrxAmvJpLlIEDTJ9MFSBF0CHJtm6jZKy9xa Em3CosXFgO6rFDtGmAvW0o4PvC2lYiVUMTRPM9gUH5ON9W4d2bywlYxY0b0VtWlYvsMjxT5e7LGm 1fqMFQBjZg7XN9XMQSzo3oLzsc/GmQPRxqlqM12fDa6yqSWiXfsQ7brUh0wWegaRjJPXt4/Xh6bB PMDF8MfgVx0qq0YLBGKH0DpNC6pNJdO5z3Rcq9AcwfZx6CEG0HfgudF8oAnBb730ZGzdy1RMWnJi QvcmjBLUlBNUmdj1hxRAobeazKzBuJ4uM4FJqy9RXuTV1Ejs595+tfmBEePQ5admuEwxHkLHVzv9 1JCW3gG3RXCXbXEXPp9gDlqQiAP4SPX0V1tmIwCGpB5yA8twBSdO6N4JTV4z7Xj/4urQe9+/gguG 3jV+rSqY+gjXdomnX8SC7i346fTLHw2xRiphDEMwJ5ecNu8+WpPuIILKfO/Rzvcgq/IDgsiVlVW5 myqvUta+oDuOWlVlB1JM8uoe7atbO1W+wZTABDqo8kHWB6M7KLwlBeR99GwImnCkw/jFgx4Qhgi3 YCnVXinGSJLbHOe2r5wTnV/EK8ZZWhQx7DqMsrzQtYyYz7H5hmkMkVpqC7B4wsKZ1iGL6lJepkY4 CUtfY2xIv8WOA8TfbuGuArO4ZnHiqNOohCViKMbkfBij1rVjMGu1NJlkTQFUTSjIskEF53RtvYqq aY/9Mk6WpbSgF4AwEeUTsmGQRQOdFIsxnC9Mg5KsKHG0qfXxxs1KA1q5gDibqFFIWn9dyPTBki8K iKCi44vTwI+9aYqi++5QEqHjRFgmMTR2vByIJotL0j1mC6FYVkQtqkpfLlt7e9B9uqhR+i0kJMqT 8vT28PQWZE/t68O+XuLNGYAg/vGpcw+QErLZvGmgWlOSmuOkBhtO/M8LnVvVsR96Junx8HwW8Q5Y SBAg6syBLAa5bgxgvVrFwUhZlHHrhokBLmXX6kcpRyQn7CEnWBrOsoqF8PoeyOt7FHMR+SE7MPwR Ra6dKV20pEP5XHQoH5bGH0V8EebbKubbG9GhFB1K0aHMrMZ5Q/jc0TAEjeuGTgGzD9woRjs7pRM7 uGgyScGF41vwtB8soJF70KjODwbSsGaP0PPew3I0tayuEsuifQdAoxXdOW/MFHdTgHs02NKsD0b5 FjZnxPvce5/ZXmLAD5qwOUb811ES4PIp+HITLNB46YCvFYMOhzkyfdZSB8R87s1HW07E3gBJg0/V hqUxXZEWGJEk5WSgCQDVSIWzoFZNEAO6N6B1JsRHokkVd4d14ls1PjHn3of+LVIkwirT6MR+7u23 ulzhGAlREla+sMqiNBqzbogwe8HqNGJD9zb0BwiKiJtNnlQEeiM5W+1SuCXssBmr8ViRihHdG5Eq E86GfoYYCi5LBL4w0QQ2eCHzCyyrQIzo3oiriB2bWAUyin4Yhi3w7ip4d+3uUE3PfkM0Ea6cPMY9 8CIAeParrUoWvGss0idq5g2AqaHatBLalBrNp6hRJC1ESXbukx0xvbO05N0YlJ55iTL0PyWB1BuC TCV4CKUaMaJ7I2rhyUN0BFM9YchrI4Y49Y0OafNOOrq/Puj/ZTCWXYwOYNiIj6Cj2tbcQC1oC+Zb pDw1GvJXsPo9a8uyTcUH3fugsZyHmYMSxckHcgOlJdiqJbhcLaEiPYD0APvpAW60xAGByvMpAZWU 09Uvk7Guwv9Mt3cEsezGSaskxyJ9pvUKscMEZgo1bga3rOqRYYQzVrBZNXzF/EfKDvdlh5G547lB ZaxZhI15fXdAO6Jt5lDzX2kpJCNtCFEusaJ7Kyo/i4nSZ4xWGXUSjca0ZL/YBfijERq9HOcHwG0R Dln2uguhtHI/xsPSICixsobVwiWzysBA6rM91GcXK48hSHMgj6+1xwcJu+IKenV0BecSt1DfQkLr 89+JhF2snWNhdHBT3cItZqgoCTEh3kODxlLdRsoJ1wQkTTrZFFmlXnFfryCpTaIEuW1+6J21eWnI g4VtMDbxJJZMWtlxBwlQkKOtkCM4Iamf8m59muE+KoSV0ym1gfTRxL/zgnGaApDmjk/rGNomQijv XRgXGA+s8/k8FnRq9AZEnc7IF2HHUeYHaljKBdxOdAvzEGoGrchzzKmFMKzyk145tVT3OTs+T8ss QK78Tj0ZSQztgBca03l5gVz4PUdRkKMjmrcqj24Fam3KMIzoHAh4gI0SRyoZ95WMLS2BjJ0Tr53i qWU+WBelSy726zg3oto1Kw5iQvcmtE448RO0ICQRSprZpE4Ju5EjLq03wNhoQUjt0MfxD7Ghexti DTaEmC/fatE0lUakrLlfhYiicSTBZrLwREzo3oRMmwYczZrLG0TYtPNhzKTBbT/O6ZquWNC9Betb JrHCbIF2GebTwZxMC2/LvDzFhTqTEQ18I4OkTnQVvJuHspNSnl50Fi6ScJFavD/6pl8WY2BEf/P6 YUgzSCWncx42UHgUEk7yQ34rOnhiSbFkccCzvWw3soIk10j/y63INn47z/XoxfNnx+cHVu7qTIMW VG2ed23oNXsV++jhZ69u/fj1wTDrnV/Ri4FB+clYA+ND+9No8S7zI+5AvOsr3xHm1C0pWb54qJLl BvN27Q1/5S/Tmvf+/vuYf/azs6Pzl/2/hFt/1X/Nz7ID/7X/1+So4DOpLFFF7yzzhwUm2Ev/nH28 OF36JH3iA/phFiE6Pnr6Q/tQU9cc1f6tkSdKRj05qrysoRVpc1CXM+qiJZdS515cby2X65e0TCLv 1zQbpwkULr9TGHSm2ffte1jXKp2O2+VthqXfIH3oXGRDXu6aIe5Zk3TMbxoOsvS9OS2HL9Ps82cf dfxnvyi944dmy0fwhFyaaW1E/n/2rqYnYSCI/pWNVwULBUpJJEQUJalKROO5wAYrZUt2qR//3imW QyEtpQq7tnMj3GB2d96b92bmlrrCYTMH7Az9+5KmVZpa5LAFkCDAaYt19lsRyQiACddLYgSdi5Mu OK7Ws7bhH3tNO3l8x7OU5I/uOQxu3+TvoxYJ8mBDrpJQ3NrxH+0PXvHEyjmx12D4dlvkLQCDZeaJ hT3vTIPvygeBIEU+x7n/7XkqiygJECJ5ZQt6HoVOtodLcJeQK49577BbE1kjOBQilYnDFtJiseMD NAi46MSS7Ss3ag2NvNicQ0VlYPPZh42bSWXHpMcdMfbOyBOsvReEGHVNz8qM85ThjpIuYt+rZ+YE i3uHQfMFupCyuZBUq+cpXlgNqY7gkx/w0vFF+En8guwkPAmqAf7N+KSvJxX9R+JN26tD+RLQT9ee L0YUB01Jn26DzEAJgobMAOyBcmoWsSAUmUHoBl0LSipUMpAZpBT5EkAZ4pW98ErIDEaUdUACWXJ/ joSAQ/PgY6zAnHD28sN6CqBJhnGUVLRO1jNkSjBtCwZHQBMt7Aw+iJ6v2gOdUs/fwm8yYxQL64Dx sCklFqzli5yw9PWOAtx8iZHLMnlQb57XNMJ9mPzhkxvKYNyZSywKmhcfY5BDr/j/uJ59Ib5KFhWl O8+HuSHU9j9Jl07oJzEJMauGmVWdwVsrx0PUg/d2nFV7TgiaakgyZZLENLPiDvLbA2MBwiBoeWiR U12v1OpVs1GtG0rmkG8AAAD//+xYwY6bMBD9FYvzNmtCsklQiZo2sIdqK5T0VlWVAw6xYmxknCXp 13dsYJcol57SHswB2+Mxnnk29sxTy49NqBIpdI2akNQZY5H3RZ4Uowp9o40H0sNK1LfSrL5WfDRf 4kQUMOKV8Mjbqw/JxgPxI8yQwkRQVqaEJuiomuWbVEUexng+exonnu3pFO5jURNqdC55WFcko5FX KVpT9Uq9JUIoLgnjIeJMCspHpVRE5J/Mu6CjTJbGG9361npmrK96v4xXyQonATYA3rraC9d0T05c 36qnRrRe42Sxsrh0wFVbfeEURluEU06Y+E7P2qDcgQzFfbDrV9OUzvdukW8X8nqLu3XPN27Pu//9 6mh0Z5075+0N0t797o5z93vkudjGxXUuprVhvYvn75WZulzG5bA2WR9k333K1lIVkwTHq/ekfpjL BBMcxH26b2PapBX937ENZK7XLv5LNmb5VaoDEC7iAVGNCB8BEdM/8bliQNCgF3JBswc0xv6073or f6SkoChY/LyiZ5pwJ+WxJOq41URpcJflkeePfbNagpRA/fx6lp9JdmyJlF47FvlAt2WyLNdR00yn b7D95WbZwiCjOsC3Kra/YYbGGDOe2G11gPp0DnVL6VTFCzHzaFmB3A8mxmLFigN8yZ/iwDR3UmtZ vndzuh/0HijJKbBsM7wwynsp9aBZnLRtdtNlkhsasKPDZnjeWpHL7FkxgwVngqZMZ2Bl8GQHwZHZ omFZsJ3ML7YCQ04lFXr5BwAA//8DAFBLAwQUAAYACAAAACEAU99jMLoKAACrMAAAEQAAAHdvcmQv Y29tbWVudHMueG1s7FjNbuM2EL4X6DsQuvSysSVnnWSF2ME2zgI5pFh4HQTojRbHFrsSKZAjy+4p D9Je+2B5kg4l+S9WDadYOE2xgAFZpGY45Hzf/PDyap4mbAbGSq16XtDyPQYq0kKqac+7H306ufCY Ra4ET7SCnrcA6131f/zhsggjnaag0DJSoWw4o9kYMQvbbRvFkHLb0hkompxok3KkVzNtp9x8zbMT ks04yrFMJC7aHd8/82o1uuflRoW1ipNURkZbPUEnEurJREZQP5YS5pB1K8mBjnJnc7li20BCNmhl Y5nZpbb032qjLcZLJbN9m5ilyfK7IjtkNWF4Qf5Ik8rsQhuRGR2BtTQ6qCZXGgN/39r1AToVK4lD TNhec2lJyqVaqXHoeOb/lfNa5Lx2tXbbqVpvhM6iv8YSK0IpCIYe/eE5xpp8e3dt8t/dgOBIS3T8 4P1JEJz4F6NOEPrd0Pd/dbNSSZQ8sUsBpzWjcUK2GPY83z+9PvcHA/dpOTSACc8T3JgpJT6b8vEF FwnQpzOe9LzrCugjmKPX7l+2SXH1Wfmtqf83iQxhAob4BLVc/S1XSmMJPfqg0lipcmtj/+nxj0gr NDphY8ACQLGB5CkgGKa0APv0+NfT45/OECzNIWFn1NG2jP1RLC2jH+2DcTbVWrCCLxhqBvPMEDKZ xHfMyGmMV69p5x1fjCF8TQvImVwIdyRg127UFHITzQVbOpqeM1hwggqTqgqYFJmW/v9Hh5PbiVou pDnn138dG4hFFMrXLLpPjIxi9iAhhl0yBf4o6Iadzi6Z7h+8o8Hq2zPplgmtfkJmgcgcc3SQLYxW U1ZIjBnGwDSBVCqeMCR6NwBl3wmfbp7w/jh1sXu0lcCbPt1C54lglIwybV+dZkMQeeTyOTGodC0a 7uoF8r5CF5qcuw1k2iDlzTKSsvGCwpcBTnL1UHNg3YeCziYKDuLZ6S4YvvNsFb52IxkVh+tItpdn gb97tG+eZ5RCRprxKJYwA7ZENR9TPeQifzNij1T9YP9WUQwVVJoQw3IL7LfcIhMwkQoE+/jzx9HN 3c0voxdG1u6mxw/i1Ptdx3/n1B5Onb/4hKnafl5qv/UTpvLaFdWJ/Eq82iwGXJNCGaHVANujEevG ZhBRS5NQXU22OZOYZ4D4r2wq0WUszxU0VDpOctcKMm7rHLeRz5iQVGtSl76MG6gLboRlnGr3uO4o qjqexigXolk0bXtfBgy2wLQ/QP8fG7ZbZCl1P2NXuxOeqAFCin3kDZiTJxjFb7pCMS5Qv3MvruaX Kgd6Jy8INwRK0FvTuR8NbkPIYsMpgENr2nrtlul2owcqy7e6UNsq3vhY51TSE7ZX7ZSVmJeNdXNS 3AvirSrjoJxzflhEDIIzv6LI85uH7ZnP7jKiHirbgv/CZcQ3aKGeQXh708ONi5juh+7N2aeq4Xz5 3tHdIIY24xFdExEHLZgZeP2Huu/jim1Fc7oHcoeMfa95GObN47x5mHhekpxm/wYAAP//3Fjbbhs3 EP2VwT61gNXs6pZ4EclQdQEMNLAqOzXQN2p3pCXCJbck17LylA9pfy5f0iF3hUrORlEK1DXkB1vm fc4czjlUbIdvX21iPXxb/7LDwDV80QyPuYhNwRIcBIVGg/oBgyEkKi+YxhSsgsBYpm1wdTCf1ir8 FjQyR0nrbuL6I2xing6CdhTQJ1baTOlB8G6sy4+uIWWWtmqHUbcVRa3wzV07itudOAx/d71ccsuZ MLsJbtmC2rXh6WIQhGFn/DqcTNxQ3zTBFSuF3evxM+Y+8OLWbgXS0AcmBsG4OugdPtrglT96UQ2r QKo/N01Z4Ao1ygTreboay6RUllmuJA2oVtzH+9cSjeuMIVWwQYJUUhCogUlga4IMuAFaAZgQalNB PVnczIGBxj/c5O9GvHM64r0zRHyUL/m6VKX5qYGqz8QjO7y2YBBzAzZjFm5H76aUz0JpCznbwhKp l3L/g+AfkDpaVjNpcm4tpj+625YTnXlBtNXIEsvlmjiSYmNIdAe/fvu6p3Ohf4ZcuNsWPKGbtW26 RM/GhYlCA5Ob6zFQChPNKfs3vyyAbj9qXzlASaJExsQK1IoKxUYaS4nPq6Q3nf1o0nunJ/3NGSb9 luWuznpBaigBR6Hrnwxdp3uG0I2dKsECRVWjWMVaV3qu4JaT9sFySyReeYEm0pJ2saIQdMecxrUE GnMF1ys/rYWSLQWmF5DQqty6ordTP9I5Bp8//andTp8//UVquAWh5Bp1E9uf7abeI2SM7E5GgaXc JKUxFBedfKU0XsCytF6rTanJUGRoMxJyEnVXpDMfEwWYiNJNalKfY9TrhKdTLzpD6u2MErClIpg9 M5q4cBTDy30M3wvNkwzuOWbo2g89ZxTeRb242+CA3t8HXxjO3rQ7Ho/cKk8NZ93zAgzn7nDOBvcu e9P+zMdhhyZTpUgdS9O4oSA+uV1PQp2TbQ/DUdjuXnoz8ZX4683ne4P3IKm9sp4paQ0NZSbh3Jnx UnPUDtZsRL74nxYy0ptYMPI9tW9PsTWZ7jtv4sHOudd7L6qj/tx+3RtNfej/wbb0eGp+LM2UBnxk OZm2C9JzBPo/p6oBE056ZJ3jd3a/NoQHaSBSHYawx6l/F0KiBG1fQzebhfTjsNvE5a7RkKcU/inz DZzda5GeLkofP/L/hLp7VbnXkykLb669y3IOGx+5cZJjN4hO09b8gf4WjGtnsSor7mw1k/5i7Hns C2DGa5H7S89Wg7vMFcwYOA7DS8vczbhlCkz4iicw+m1uXmweS/lBku+tDmkzrcp1BqVMMqoBmH6v mF4eiOm3haAfRw1OuEkIpuOw32785qHu2at6J33z8DcAAAD//9xWTW/TQBD9KyOfG+okBFqrCUIO SD2UorYnbtvdcbzKZtfaj5hw6g+BKz+sv6QzjlOEFKAH1Ei9bJxZz2T27Xtv0hZ+dkbL5+3HddwY hLZYCzPNSrdaoY1XWKFHKzE7np0dP74rrHVRRO0svdDvdKUo3QetrqZZnk9OJx/efMw4HmdtvQEd INa0KDQYUb3jgnFbtlubbpXbX+a0/pGKajXNTicZPYkUa+en2UXp0zcOKBFxmo3y4evBcDjIT25G o2I8KvL8C+9qq6MWJuwSuGxD8ccux+XbfD7nV7vQHCuRTOT++50uYwtRsw+iG/wae3SaHklO+Z+o cr04u2HsGuHFwoumZjSTlQaFh+hgha/2wPlMZ42z+7vvS+tavmARaUG4LK+BCOQ1BtC2C3kUMmq7 uL/7se/un7NZhVIrZOC2ZPyt5c2hGyxdMgo2LoE0wutqAy3D2grGFwnOSMiS+PahSJr6o4KGw6dK aFyMJi9QQp9chJA8uRxCLdYISgeZQkC1I2hwlhgKlSNVsd7IDNNhpfXeKtARVmIDZLpwiyCaxmgp bsmticDCGHBr9MYJBU7K5DvDDiAoMXpRVVqCJ5MMB3WIc8bTLhl5i4y3gxToLLBydB8LtOipz0DE 5nEDRi+x4HN7VEmShzTeLTyGoNdoSKA/97jd36l/8sTpMS7GL536bMR1x3liuHQ0RVIgO4HKuxW4 5HeyoNhhOVPtRofFdkd7Nr4jmF+elzwCXcPfhTnqBHwxuCXKhLrzz14tAeNBD1EKy6T3WBmUEahP svJ+Ikb67/AvE//F6jB7AAAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9 G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIh KU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5ak D8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdi oEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFw sGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7K nMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6t HdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzw OsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3s z8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI 7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmi FZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklC FNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjI CswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7L prGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp 6Ig0CxA9MxEVvrxOuBO/gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM 9olCvQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntM GRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmE w6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3 uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP +6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1 l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0N M5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnY x+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6U O78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8 F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9 FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tv WRE9MWuzGnlWALPSVtDK0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3 obYi+HihiUHYQFRfso0H0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5 uXiRxs4s7Njaji00NXj2ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUez dOMvAAAA//8DAFBLAwQUAAYACAAAACEAfUa5iyUEAADdCwAAEQAAAHdvcmQvc2V0dGluZ3MueG1s nFZLk9s2DL53pv/Bo3MdUxQlWm68GT2bdnbbTpxeeqMl2tasJGoo2t7try/0YLzbYDOZnkTiAz6C AETg/Yenpl5cpO4r1W4d9x1xFrItVFm1x63z1+d8uXYWvRFtKWrVyq3zLHvnw92PP7y/bnppDKj1 C6Bo+43aOmfdbvriJBvRL5uq0KpXB7MsVLNRh0NVyPnjzBZ665yM6Tar1Wz0TnWyBbaD0o0w/Tul j6vJMlXFuZGtWVFCgpWWtTDgcH+qut6yNf+XDY46WZLLty5xaWqrd3XJtzTn616VLr9YfI97g0Gn VSH7HiLb1NN1G1G1lqavv4dniud9tddCP78guYO0XSp5XcBHAFM7BLp2VoP8H6UakHdSFxBoqAWX TIDRonj8JC/VUCP9qFvKgzjX5rPY74zqLBuns8XpuTvJdkzR31A1FmfUnxiLkwBOI/WuEwVcNFGt 0aq2eqX6XZlENZ2GOMwWsBNmPBtKtewHh4fFJ6WMNSMkil2escliQG8Icd2UBSjic5fPfv3HJiAR z1CbgMRvIGse0By1iQhLcQ/iIMki1CblcZaiSEYofo7rBsTlmA31SBK+gdA48XAbL+JrFIlZlCUo klB3jcaN5iTF7+MRN4spxuZFrv+GTcJJikbHy9iaoB4wHkRRjJ3DcpJFc/2+rgM/9LMAzakfcpbj SMaSBM0pcPEQ9Tpg3M/R6g0ykuLnBLnrh6gNZzRK0Mxx3+dv2ESce2gMeMJogOZn7Xs+RWO9jt2c oBUS8sBL0UoMY0Y8ND+AZMzHMhcmPEhRD6KAstTFbN5+KaKY5bhvMeVphv4lSUjXDD0nSRn8j5gH KfFT/D1IU5KHaO1kHotD1IMs8nwPrcQsIQFF6y1LaeihXmepn+D/XE4h22gd5NRPOXpO7kFO0fzk EcnxessTeK/H2llNDz28+M1m6NR/arvKoWssmqmRJaLZ60osHoZeDm2i2ez1Y1y1Ft9LmCnkS2R3 3ltwuZyAHnphnUNnsgC08Qkpq75L5WEkrh+EPt6Yx+Q2G41KoU/+9oVtaKtS/6LVuZtYr1p0v7Yl iO2BLmMzX9Wa+6qx8v6831mrFlr6C+jcln9c9EC4ugXoujEwhckhQveiPdo+WMql/VGKWu+GSU0+ iK6DFgwq+6O7derqeDKuA1sDu1Lox3GzP9IZoyMGuwEbN6IYbgba82JQmJagNS9uMs/KvJuMWRm7 yXwr82+ywMqCQQZThtR11T7CRGSXg/yg6lpdZfnRCrfOV6IhXjDBnkQnIa/DLAMFpibBPNz0i8tG PsEgJMvKwBDcVWUjnrYOJf6Yo1m7Fs/qbF7pDkyDcvdKuiiFETBWjal6ZQyp+8qX66aURQUFuXtu 9rfR6KfJ8brqzU52MEUZpeHK4zD388h8m8vv/gUAAP//AwBQSwMEFAAGAAgAAAAhACytU43iAAAA VQEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAnJDBasMwDIbvg76D0d11knZtU+KU1Zmh17HCrq7jJIbYDrYzNsbefQ47 dcedxCchfT+qTh9mRO/KB+0shXydAVJWulbbnsL1leMDoBCFbcXorKJgHZzq1UPVhmMrogjReXWJ yqDU0KleGgpfzf6w35xZgTeccbzNG4bL/HGHn8rnkp05KwuefQNKapvOBApDjNORkCAHZURYu0nZ NOycNyIm9D1xXaelapycjbKRFFm2I3JOevNmRqiXPL/bL6oL97hEm73+r+Wmb6N2vRfT8Amkrsgf 1cJ3r6h/AAAA//8DAFBLAwQUAAYACAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVs cy9pdGVtMS54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwYoC MQwG4LvgO5Tcnc54EJHpeFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiM jnofRwM/5+/VFhSLjb2dKaKBJzLsu+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2SgHKyUMo86 WXe1I+p1XW90/m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4 t5qq3Au6a/XHf90LAAD//wMAUEsDBBQABgAIAAAAIQAuBYrEBQkAAP1GAAAPAAAAd29yZC9zdHls ZXMueG1szFzfb9s2EH4fsP9B0HsXx2ntpag7pE6zFui6tk6wZ1qmY62y6Ily2+yv3/FI0bQkWsdI AfaUiJLuu5/f0QnPr377sc2ib7yQqchn8fkvozjieSJWaX4/i+9ub579GkeyZPmKZSLns/iBy/i3 1z//9Or7S1k+ZFxGICCXL4tZvCnL3cuzM5ls+JbJX8SO53BvLYotK+GyuD8T63Wa8GuR7Lc8L8/G o9HkrOAZKwFcbtKdjI207xRp30Wx2hUi4VKCtttMy9uyNI9fg3orkVzzNdtnpVSXxafCXJor/HEj 8lJG318ymaTpLSgOJm7TXBTvrnKZxnCHM1leyZS13tyop1rvJLJ0pL1JV2l8phDlvyDzG8tm8Xhc rcyVBkdrGcvvqzWeP7tbuJrMYru0BLmzmBXPFldK2BmaWf10zN0dGQ9XqMqOJeA4wGHrkkMAIR4K J0tVoMfTSXXxZZ/BAtuXwoCgAABzxcJlzeMQV4jyQmcJ3OXrDyL5yleLEm7MYsSCxbv3n4pUFGn5 MIsvLxUmLC74Nn2XrlZcJaVZu8s36Yr/teH5neSrw/rnG0wxIzER+7wE9SdTzIJMrt7+SPhOpRiI zpmK8Ef1QqbESgcHFdqnB230Qg0VF/+pIM91DFtRNpypMopQ/5NAaPW+N9BYWeQagHKDdL3oL+J5 fxEv+ovA5O3ni2l/LYA8+0ZE54aTlfSgliLRyef64eLyRMqqNxpZ1PlGI2k632jkSOcbjZTofKOR AZ1vNALe+UYjvp1vNMJ58o2EIXHVs+gCvUEq7Nu0zLh6/yQBnfekOtNqok+sYPcF220i1Vjrap8i y8V+WdJURTp9PFkuykLk950ege6sSvfRnPx2u9swmcKOpsP1456uv2XLjEe/F+mqE+qFTr6GTbgx aW1hnzKW8I3IVryIbvkPHdGA9z+KaKF3GZ3K9Qzrh/R+U0aLDbbcTrCJx+l+T2j5H1KJPjhZTBOP KV3CSTGcePLSL/wPvkr328o1hN3IRPN5QJhrEKjiaRc9VyFqVlenFSoAFBN0uwg3AeUT9NfNJVy+ ijFFf92KHimfoL9uXI+Uj/lxOr7BTHPNiq8RqbymwbU7F5ko1vusqoFOepgGV7CFoJkQXMRWPokk psEVfESf0VWSwCc3Sp4Gx+LAowEoweHQKFhsdFuCg1KjvfMAi4IDVMMaB2D149oAoGDS/cK/peoP T6HNAFna7jU7y/nC4wFoQaQ99Oe9KLv30GMP51FR3ufw5xLJIxrahafyqGgmn3S/C4hxv8YXANSv AwYA9WuFAUCe/PDveWxPpIP0b44BWMG0bLsYph2ZmafBzGyBwlrAQH2TsP/yVK8/F5p9k4ASHKBm 3ySgBEen1sts3yRgDdY3CVieruGPkcupIUYF900XyO4ECBYNQ94EoGHImwA0DHkTgPqTdzfIcORN wArmBsupLnkTgPCRkI/6FsglbwJQMDdotjN/M6r6Hko5/eF2APImoAQHqEneBJTg6PjIm4CFj4Rk Qg3LUh0BaxjyJgANQ94EoGHImwA0DHkTgIYhbwJQf/LuBhmOvAlYwdxgOdUlbwJQMD1YIJe8CUD4 SAg3tJI3Vv2TkzcBJThATfImoARHp0aodpNKwAoOUA3LkjcBCx8JSQaDhckdYtQw5E2waBjyJgAN Q94EoGHImwDUn7y7QYYjbwJWMDdYTnXJmwAUTA8WyCVvAlAwN7SSNxbjk5M3ASU4QE3yJqAER6dG qJbnCFjBAaphWfImYGG+9CZvAhA+8ligEIuGIW+CRcOQNwFoGPImAPUn726Q4cibgBXMDZZTXfIm AAXTgwVyyZsAFMwNreSNNfLk5E1ACQ5Qk7wJKMHRqRGqJW8CVnCAaliW6ghYw5A3AQgTszd5E4Dw kUcAYRWFhGkY8iZYNAx5E4D6k3c3yHDkTcAK5gbLqS55E4CC6cECueRNAArmBnXOFs6Lko+nnnuS gHrOoDrVQAYce4JEBTQGfuFrXsAkE+8+HdITsLIwANGTHlQT3wjxNaId7L7wJAgZKl1mqcAj3Q94 SscZRLiYnpgkuP1zHr3TAzCN9zCljk/ewPSQOy6E40lqcAj0LB92MLKzq06WK2kwIKTmuswIEM6h vYeBIDPWo15Wcz7wIA5VmWX8v61Bxd9h5m1VPTMavXg7mV5emwEnFNlUItmAFgnMSp1QwhyFt6eT 8CB8XSXPeXlU6zCsUSlnzs0fdlf6uaPTm7AEPvToXaoz4id0xjPkJ70X4SM63k0FYWwLVerS0J63 wqfLZaYH0eCX97kKBYz94f/WdMhXP5gWC/fnPMv+YDi2Voqd/9GMr0t993yEfbImainKUmz97xd4 jBw1aRMALnaV0ZfKCL/v8/12yQuYAzvh/49C9RecVztOXH0iVofbVh5oj3lN9bpft6OismUEh/7T HE/719MW7+hBANRpyWAQ7081V9coNBgi/FqtW4FzqJ+uHDreqiHMcaFeX49uLq+0GN8kI2aRmWN8 bi/a5xjNzCT8OBoGncVzGEoVGZMqcDjo6SyhXs4sZ1Wi/zqznLgGzofJ01MJckQqyV5Cfi4U9dXZ 7diL/tBEBy/X4tNKTWhJa7S6IuUPC1r8/3Cozeq52Kqh40OXrnuQ5bmAyVQ1J1rYzUNbmvvd2IcZ j705+nU6Gd/oCBhvHrLtfKJvSCfb9Fp3trWXvHFOa9E7finVCFCbS9wW6+aSI/eQlU/jpQYVhJb/ wb8wkmXq26lmXOv2L7Wa656pZ6O5j2Tbt6IdLG0YOQIBSdnHaSeTEjb0f/Ok2R2dvJTmkbbUbBif QxJXnalxsyV5Df5T56+p8qW2YS7h5+DZ5priSzjzjD/nHJ8dfOL329AZ5zoINryHr1PoUbTt+feG ZZkQ7Tshcy98L+QIPXiPXI+dmyO3bzQY0XzNg90PwbckPHpzdMs2YsucrdFhIZGz2FwZGq3KrU/j ohJr3cH1PHcj509yf493M93BGjrN65vRg3vNVvSw8DT+bq8JO7FTd6u9gSGHL+qAr+7AX8m5fdxr LubT0TV+HMevGVFwsv59JSGJDFxqPhxXv8nX/wEAAP//AwBQSwMEFAAGAAgAAAAhAEHl+SxQAQAA fgIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJySUUvDMBSF3wX/Q8l7m6ZTkdJm4GRPDgQ3Jr6F5G4NNmlIsnXz15u2W93QJx9zz7lfzr1J MT2oOtqDdbLRJSJJiiLQvBFSb0u0Ws7jRxQ5z7RgdaOhREdwaEpvbwpuct5YeLWNAesluCiQtMu5 KVHlvckxdrwCxVwSHDqIm8Yq5sPRbrFh/JNtAWdp+oAVeCaYZ7gDxmYkohNS8BFpdrbuAYJjqEGB 9g6ThOAfrwer3J8NvXLhVNIfTZjpFPeSLfggju6Dk6OxbduknfQxQn6C3xcvb/2osdTdrjggWgie cwvMN5YuZnb3VeCLSre9mjm/CIveSBBPR7qqreRVtJZQQYF/612Lhb3sHopmvWM8hsv62YYbQUQh bT7MdlbWk9nzco5olpK7mJCYpEtyn0+yPE0/umhX/V36oaBOAf9NPANon/j6x9BvAAAA//8DAFBL AwQUAAYACAAAACEAhdp+sJgAAADoAAAAEwAoAGN1c3RvbVhtbC9pdGVtMS54bWwgoiQAKKAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArI+9CsIwFEZ3wXcIeYCmODiEtlBQJxEhi4NL kt40gfyU5Bbs2xtEfALH73xw4HSKi7RmDYUI8KARJoGbh54+x/vYPMSVkg+4yVBhZeTiDFpynhy6 FCl5BR8LVz21iAtnrGgLQZYmLRDrZ1IOEuvMM0vGOA2npNcAEdmhbY9MOeVdmrNc7PaV/UU1dOyX Nux3bwAAAP//AwBQSwMEFAAGAAgAAAAhABGuoaIvAgAAPQgAABIAAAB3b3JkL2ZvbnRUYWJsZS54 bWy0lcFuozAQhu8r9R2Q7y2GkLSJSqqWLcc9rLIP4BATLGEbeUho3n7HmLBVEzYh2iUSEjMwGX/+ 5/fzy4csvT03ILSKSfBAicdVpjdCbWPya5XePxEPaqY2rNSKx+TAgbws7749N4tcqxo8/F7BwsSk qOtq4fuQFVwyeNAVV5jLtZGsxkez9XWei4x/19lOclX7IaUz3/CS1fjfUIgKSFetuaZao82mMjrj ANisLF09yYQiy647r1koJrHrhJVibUSbqJjSwAPM7VkZExrSlE7xbn8Rndg78W2FrGAGeN2/SF04 Z1KUh2MUGgHgEpWos+IY3zMj2LrkLgVii4kdrGlM3ileYZoSFwliEmHgNekjITblrqB7Z9JHcHuw sbZO+0owb+tgBOt0X7V9+m5/TkishOTg/eCN91NL5lCdEgnpDElMkYclMxlFxLR1W4IjiISv/fpx JQku5fEpOq7/D5H5ZSKuzvVEEhSfLhkMiOMNUcxvFIfUG27UGXXk4oNvzkgjwHWfSCM9J40rQIyW Bitw6/6CwU6H1UT0/2cEQYTvXxUxo9O3bv97RYSXQAQ0GK+InRHc2CkZoPGIJJwo7HwgEbeXVznG aFFYTZybjslXFvQSC3ozi0EO0T/hoHS9Mju+OlT81DgGhqVzuyOFz/7nnLXXCG1dE9132EeRTOes n+tgL0M+mjCJB8rQtFjfdLNifXTciXKbf57aBo36+RlD4vKJ0iGB5W8AAAD//wMAUEsDBBQABgAI AAAAIQAKtqAlxAAAABEBAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyMj8FKBDEMhu/CvsOQ+25H DyLDziwsst5EUB+gdjI7hTYpSbTq01vRizePf/7w8f37w3tO3RuKRqYRLnc9dEiB50jnEZ6fTtsb 6NQ8zT4x4QgfqHCYNhf7OlR8eUSz9qldo5AOMsJqVgbnNKyYve64ILVuYcneWpSz42WJAW85vGYk c1d9f+0Ek7dmoGssCr+0+h9aZZmLcEDVJpLTDy/7SDA1Ry4Wc/zEE8tRuCqK+z77lLg+3N+14P4M mb4AAAD//wMAUEsDBBQABgAIAAAAIQCjBSkN7wEAAOoDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTwW7bMAy9D9g/GL43cpI2SwJFxZBu 6GFbA8Rtz5xMJ8JkSZDUoNnXj7Ibx+l2mk/kI/309Ejx29dGZwf0QVmzysejIs/QSFsps1vlj+XX q3mehQimAm0NrvIjhvxWfPzAN9469FFhyIjChFW+j9EtGQtyjw2EEZUNVWrrG4iU+h2zda0k3ln5 0qCJbFIUM4avEU2F1ZXrCfOOcXmI/0taWZn0hafy6Eiw4CU2TkNE8SPJ0Zz1AC9tBF2qBkVBcJ/w DewwiGsCu4g/W18FMZ58uhlz1iV8vQcPMpJ/Yl5Mp1POBgj/7JxWEiJ5K74r6W2wdcweWheyxMDZ sIWTM1uUL17FYxIzTPk3ZUjObLbgrAtJoIedB7cnUfObJLPP+VaCxjVZIGrQATk7A/weIY13A4pU 80NcHlBG67OgftOAJ3n2EwIm41b5AbwCE8nA1NYlbaxdiF6UKmriplqXt+GwbRira0G+US8Fl40J 7DRQ4VJde0J4qOlu8R9ix0OxrYZO6kDOIOzPeMe6to0DcxRfvJIhWENDfEOS67/CoyvtXVqeNy8v wcEOPKu43zqQNKjFZL6gUZ23YVDjW9oarGi8J8YzwO/JeK/TsfSv2WF16vm7kPbrqXu6tJajgr52 oU4YrUT/psQfAAAA//8DAFBLAwQUAAYACAAAACEAcgflDoUJAAB6SQAAGgAAAHdvcmQvc3R5bGVz V2l0aEVmZmVjdHMueG1szFzbbuM2EH0v0H8Q9J71JandDeotsk7TDbBtt+sEfaZlOlYjiaokx5t+ fYdDiaJ1sYaWAvTJ0YVz5nqGcTj56edvYeC88CT1RbRwJ+/GrsMjT2z86GnhPj7cXfzoOmnGog0L RMQX7itP3Z8/fP/dT4frNHsNeOqAgCi9PsTewt1lWXw9GqXejocsfRf6XiJSsc3eeSIcie3W9/jo IJLNaDqejPGnOBEeT1NAW7LohaVuLi6sSxMxjwBrK5KQZek7kTyNQpY87+MLkB6zzF/7gZ+9guzx rBAjFu4+ia5zhS60QnLJtVIo/yhWJDUrGnDVylvh7UMeZYg4SngAOogo3flxaca50sDEXaHSyykj XsKgeO8QT65qeNpkSgxuE3aAUJQCa+IanLFRi8JA+UHGt4xqVeJkfMqYPCJShNaBosIxZqFJyPxI iznPNaZzoR765PevidjHWp3Y7yftPnrWsmRZWmg2nmHlmaalVgJqpbvasZi7Tuhd3z9FImHrADQ6 TK4cmZHuB6CKjfBu+ZbtgyyVl8mXJL/Mr/DjTkRZ6hyuWer5/gNQCEgJfRD46SZKfReecJZmN6nP Gh/u5FuNT7w0M6R99De+O5KI6b8g84UFC3c6Le4spQZH9wIWPRX3eHTxuDI1Wbj61hrkLlyWXKxu pLARmll8GubGR8bDFaoSMw8qD3DYNuNAQsBiEifwZXSnc2A0dfF1L53L9pnIQVAAgJli4bLiceAm YKqVYmx4yrefhffMN6sMHixcxIKbj/dfEl8kQKML9/17iQk3Vzz0P/mbDZcNIr/3GO38Df9rx6PH lG/K+3/eIT3nEj2xjzJQfzbHLAjSzS/fPB5LmgTREZMR/l0uAA6DcBg4qNDeL7VRNyqoePOfAnKi YtiIsuNMtjQH9T8JhFbvewNNpUWmASjXStfL/iKu+ov4ob8ITN5+vpj31wI2Mn0jonLDyEp6UDPh qeQz/XD5/kTKyhW1LOpcUUuazhW1HOlcUUuJzhW1DOhcUQt454pafDtX1MJ5coXHkLiqWXSJ3iAV 9oOfBdAnO5hu0pPq8lbjfGEJe0pYvHNkY62qfYosV/t1RlMV6fR8slxliZDbzQ6PQHeWpXs2J/8S xjuW+rAr7wLq6foHufVxfk182L52QP2gkq9mE25MGlvYl4B5fCeCDU+cB/5NRdRi/e/CWaldRqdy PcP62X/aZQ7sCmXL7QSbtTi93RNK/mc/RR+c7OazFlO6hJNiOGvJy3bhv/GNvw8L1xB2IzPF5xZh rkCgiqdddCVDVK+uTitkACgmqHZhbwLKJ+ivmou9fBljiv6qFZ0pn6C/alxnysf8OB1fa6a5ha9V HFJ5za1rdykCkWz3QVEDnfQwt65gDUEzwbqItXwSScytK/iIPp0bz4Pf3Ch5ah2LkkctUKzDoVCw 2Oi2WAelQnsTC4usA1TBmlpg9eNaCyBr0v3KX3z5JbBtM0CW1nvNznK+bPEAtCDSHvrPvci699DT Fs6jotxH8HVJyh0a2mVL5VHR8nxS/c4ixv0anwVQvw5oAdSvFVoAteRH+55H90Q6SP/maIFlTcu6 i2HakZl5bs3MGsiuBQzUNwn7r5bqbc+Fet8koFgHqN43CSjW0an0Mt03CViD9U0CVkvXaI+Ryak2 Rln3TRNI7wQIFg1D3gSgYcibADQMeROA+pN3N8hw5E3AsuYGzakmeROA8BWbX/U1kEneBCBrblBs l39nVPQ9lHL6l9sByJuAYh2gOnkTUKyj00beBCx8xSYTKlia6ghYw5A3AWgY8iYADUPeBKBhyJsA NAx5E4D6k3c3yHDkTcCy5gbNqSZ5E4Cs6UEDmeRNAMJXbLihkbyx6t+cvAko1gGqkzcBxTo6FULV m1QClnWAKliavAlY+IpNMuRYmNw2Rg1D3gSLhiFvAtAw5E0AGoa8CUD9ybsbZDjyJmBZc4PmVJO8 CUDW9KCBTPImAFlzQyN5YzG+OXkTUKwDVCdvAop1dCqEqnmOgGUdoAqWJm8CFuZLb/ImAOEr5wLZ WDQMeRMsGoa8CUDDkDcBqD95d4MMR94ELGtu0JxqkjcByJoeNJBJ3gQga25oJG+skTcnbwKKdYDq 5E1AsY5OhVA1eROwrANUwdJUR8AahrwJQJiYvcmbAISvnAGEVWQTpmHIm2DRMORNAOpP3t0gw5E3 AcuaGzSnmuRNALKmBw1kkjcByJob5DlbOC9KPp46aUkC6jmD4lQDGXDaEiQqYG7gV77lCUwV8u7T IT0BCwstEFvSg2riRyGeHdrB7suWBCFD+evAF3ik+xVP6RiDCJfzE5MED38snU9qAKa2DlPq+OQN TA+Z40I4niQHh0DP7DWGkZ24OFkupcGAkJzrykeAcCb0HgaC8rEeuVjO+cCLOFSV38a/2+ao8DMg 4sI6lLcDLA8mok5A5Qfe9RkkPO5eBW45FY+KlCMZhZr56fhyD6XeOzqjeVLvTJ4EP6EznhQ/6SMH X1FRrSsIw1moUpeGELJ1oEbM4If7aAMWHvLpLBXMzTemRMHzJQ+C3xgOpGUibn814NtMPZ2MsQNW RK1FlomwfX2CB8RRkyYBkA6mMupSGtGeJ9E+XPMkP27empKyc+Ak2nFKqrOuLalA9XS7bkflogsE jvP7EZ7jr6YqPlFH/FGnNYMRuz/kxFythGA88Lm4rwUuoWa68uZ4E4YwMAIuswMxxuPb2/Hd+xsl pm1GEf/2mk8oXumL5gnFfBoSPo7GPBfuEkamRSAnvw/XOMJp3FIpXk5pFmX5rzGliffA+TBTeipB jojE26eQnzgNWeWtYy+2h8YpvVyJTyMdoSWN0eqKVHtY0OL/h0N1Vi9FKEfiy/5b9SCLIgEzp3IC NNHbgqY0b3djHzY89ub4x/lseqcikHuznAmezNSD1Mg2da8725pLPndOY9EbfsnkcE+TS8zmaeaS IbfMyrfxUo0KbMu/9O90XPevutftX2o1Vz1Tzcb8OZJt34o2sJRh5AhYJGUfp51MStiq/829enc0 8jLNX2lKzZrxESRx0U1qDxuSN8d/6/zNq3ytbFim8Dl4tpmmtCVc/k57zhk+K33S7rehM850EGzO yxbco2ib8+8jCwIhmndC+TP7vZAhtPQeuR47N0dm36gxYv4PHPR+CP7/wdmbowe2EyEztkblDQ/+ aUd+hclcxqhP46ISa9XB1Tw3I9ee5O093sx0A2voNK9uRkv35lvR8sYw/gaywb1S+uE/AAAA//8D AFBLAQItABQABgAIAAAAIQA/i3ZBogEAAJUGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAA2wMAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhANg4TOFFAQAAygQAABwAAAAAAAAAAAAAAAAA/wYAAHdv cmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAg9WmR4DfAACRRQ0AEQAA AAAAAAAAAAAAAACGCQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAU99jMLoKAACr MAAAEQAAAAAAAAAAAAAAAAA16QAAd29yZC9jb21tZW50cy54bWxQSwECLQAUAAYACAAAACEAMN1D KagGAACkGwAAFQAAAAAAAAAAAAAAAAAe9AAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAG AAgAAAAhAH1GuYslBAAA3QsAABEAAAAAAAAAAAAAAAAA+foAAHdvcmQvc2V0dGluZ3MueG1sUEsB Ai0AFAAGAAgAAAAhACytU43iAAAAVQEAABgAAAAAAAAAAAAAAAAATf8AAGN1c3RvbVhtbC9pdGVt UHJvcHMxLnhtbFBLAQItABQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAAAI0AAQBj dXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEALgWKxAUJAAD9RgAA DwAAAAAAAAAAAAAAAACTAgEAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAEHl+SxQAQAA fgIAABEAAAAAAAAAAAAAAAAAxQsBAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAIXa frCYAAAA6AAAABMAAAAAAAAAAAAAAAAATA4BAGN1c3RvbVhtbC9pdGVtMS54bWxQSwECLQAUAAYA CAAAACEAEa6hoi8CAAA9CAAAEgAAAAAAAAAAAAAAAAA9DwEAd29yZC9mb250VGFibGUueG1sUEsB Ai0AFAAGAAgAAAAhAAq2oCXEAAAAEQEAABQAAAAAAAAAAAAAAAAAnBEBAHdvcmQvd2ViU2V0dGlu Z3MueG1sUEsBAi0AFAAGAAgAAAAhAKMFKQ3vAQAA6gMAABAAAAAAAAAAAAAAAAAAkhIBAGRvY1By b3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEAcgflDoUJAAB6SQAAGgAAAAAAAAAAAAAAAAC3FQEA d29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwUGAAAAABAAEAAbBAAAdB8BAAAA --_002_5BCBA1FC2B7F0B4C9D935572D900066815228896DEMUMBX014nsnin_-- From nobody Mon Nov 10 08:49: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 D28FC1A014C for ; Mon, 10 Nov 2014 08:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 E2Spzdf0j1II for ; Mon, 10 Nov 2014 08:49:23 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069301A0107 for ; Mon, 10 Nov 2014 08:49:23 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C977C22C319; Mon, 10 Nov 2014 17:49:20 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AA45B4C078; Mon, 10 Nov 2014 17:49: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.0210.002; Mon, 10 Nov 2014 17:49:20 +0100 From: To: Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXWwkggAKcgQCAACWnCQ== Date: Mon, 10 Nov 2014 16:49:19 +0000 Message-ID: <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> 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.11.10.92722 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2hO6yBVqXwu_bmh7sTxWCp_cbbA Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:49:25 -0000 Hi Ulrich and Mar=EDa Cruz, Please stop commenting through attached documents, requested several times = and explained again yesterday by Ben. Some people may not be able to read a= t all the attached documents and it makes impossible parsing mechanism in t= he mailing list and in the archives. Please write your comments directly in the email. Thank you. lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Wiehe, Ulrich (NSN - DE/Munich) a =E9crit ---- Sreve, MCruz, all, please find more comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Sunday, November 09, 2014 2:17 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Steve, all, See some comments included in attached doc. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 03 de noviembre de 2014 15:36 To: dime@ietf.org Subject: [Dime] Updates to DOIC -05 All, I have done another end-to-end read of the DOIC specification, focusing on = wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. 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. From nobody Mon Nov 10 12:50: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 0960E1ACED0 for ; Mon, 10 Nov 2014 12:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LWgKZP95YHmO for ; Mon, 10 Nov 2014 12:50:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F4B1ACED6 for ; Mon, 10 Nov 2014 12:50:28 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BB1D22AC43F; Mon, 10 Nov 2014 21:50:26 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id A088AC80A7; Mon, 10 Nov 2014 21:50: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.0210.002; Mon, 10 Nov 2014 21:50:26 +0100 From: To: Ben Campbell , Benoit Claise Thread-Topic: [Dime] DOIC Requirements Analysis Thread-Index: AQHP942+5MemNaFQ60ajFIEs818+c5xULsqAgACWKQCAAI2CAIAFAYlQ Date: Mon, 10 Nov 2014 20:50:25 +0000 Message-ID: <17925_1415652626_54612512_17925_6196_1_6B7134B31289DC4FAF731D844122B36E8C179F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> <545C7EA8.6070706@cisco.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.4] 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.11.10.175720 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/W-8HTZu5ar_xauuUC3SbgeOdiNQ Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 20:50:36 -0000 Hi Ben, Please see below. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: vendredi 7 novembre 2014 17:38 =C0=A0: Benoit Claise Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC Requirements Analysis Hi Benoit,=20 I will remove that. I had mixed emotions about putting it in, since I don't know if we want the= detailed sections to stay in the RFC. But the way the summary is currently= structured, it just mentions requirements by number and depends on the det= ailed section for, well, details. So my personal inclination is to have all= of Appendix E stay in the RFC. Otherwise, we would probably need to add mo= re detail to the summary. [LM] I think that an exhaustive comparison of the DOIC solution compared to= RFC7068 requirements is not deemed required e.g. Req 1 partially compliant= , etc. This could be done in generic way IMHO. For instance, a specific section in the annex could say: Compared to the set of requirements listed in RFC7068, it has been decided= to defer for=20 future works the following aspects: - load indication conveyance in Diameter messages - specific handling of overloaded Diameter agent The solution defined in this document slightly deviates by design from som= e other requirements, mainly due to the decision to: - piggyback DOIC information over existing Diameter applications - limit the scope of the overload report to the application advertised in = the application command and to the host/realm contained in the Origin-Host/= Origin-Realm AVPs.=20 Further extensions of the overload report might remove these restrictions = in the future. With such kind of wording, it is not required to refer to explicit requirem= ent numbers used in RFC7068. And I think that we provide enough information= to make people understand that the solution is not 100% compliant with the= RFC7068 but it was done consciously, which is in fine the most important p= oint for the IESG/IETF. Does anyone else have thoughts on this? Thanks! Ben. > On Nov 7, 2014, at 2:11 AM, Benoit Claise wrote: >=20 > Hi Ben, >=20 > I believe that the E1, at least, must be part of draft. I'm referring to > [RFC EDITOR: Please remove this section prior to publication as an > RFC.] >=20 > For E2, up to the WG to decide. >=20 >=20 > Regards, Benoit >>=20 >>> On Nov 3, 2014, at 11:43 AM, Benoit Claise wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for your detailed analysis. >>> While this is good, what is required is the justification of why some r= equirements are not met with DOIC and why have you decided to postpone some= RFC 7068 requirements? Then you can list those requirements. >>>=20 >>=20 >> Hi Benoit, >>=20 >> Here's an updated version with a "summary" section at the front. Hopeful= ly this captures what you are looking for.=20 >>=20 >> I've put this in version 05 in a branch in GitHub. If no one objects in = the next few days, I will send a pull request to merge it into the main bra= nch. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> ---------------------- >>=20 >> Appendix E. Requirements Analysis >>=20 >> [RFC EDITOR: Please remove this section prior to publication as an >> RFC.] >>=20 >> This section analyzes the mechanism described in this document >> against the set of requirements detailed in [RFC7068]. >>=20 >> E.1. Requirements Summary >>=20 >> This section summarizes areas where DOIC partially complies or does >> not comply with certain requirements. Please see Appendix E.2 for >> the text of each requirement. >>=20 >> The following requirements have been deferred for future work, due to >> schedule constraints (3GPP CT4 needs to reference basic overload >> control for release 12): >>=20 >> o Requirements 1 (partial), 12 (partial), 23, and 24 - DOIC does not >> currently support conveyance of load information when not >> otherwise overloaded. >>=20 >> o Requirements 1 (partial), and 31 (partial) - DOIC does not >> currently allow the reporting of an overloaded agent. (DIME has a >> separate milestone for agent overload.) >>=20 >> The following requirements could not be met due to certain working >> group decisions: >>=20 >> o Requirements 6 (partial), 16 (partial), 28 (partial), 29 (partial) >> and 34 (partial). - The working group elected not to add a way to >> determine that non-supporting node exists between two DOIC >> supporting nodes. >>=20 >> o Requirements 8 (partial), 9, 10 (partial), 19 (partial), and 34 >> (partial) - The application and server or realm to which an OLR >> applies is determined by the Application-Id and Origin-Realm AVPs >> of the enclosing answer. If a node that doesn't understand DOIC >> modifies certain AVPs in the enclosing answer, the OLR will become >> invalid, without a way for downstream nodes to detect it. It is >> currently not possible to construct an OLR that refers to an >> application, server, or realm different from that of the answer >> that carries it. >>=20 >> o Requirement 13: While the requirement discourages sending OLRs in >> every response, the working group decided that not doing that >> would be less reliable, and require more stateful behavior. (Note >> that the document allows reporting nodes to avoid sending OLRs in >> every response if the node has some other way of determining that >> all relevant reacting nodes receive the report.) >>=20 >> o The working group believes that DOIC is compliant with requirement >> 27 (no new vulnerabilities). However, this may warrant an early >> review from a security expert. >>=20 >> E.2. Detailed Requirements >>=20 >> E.2.1. General >>=20 >> REQ 1: The solution MUST provide a communication method for Diameter >> nodes to exchange load and overload information. >>=20 >> *Partially Compliant*. The mechanism uses new AVPs >> piggybacked on existing Diameter messages to exchange >> overload information. It does not currently support "load" >> information or the ability to report overload of an agent. >> These have been left for future extensions. >>=20 >>=20 >>=20 >> REQ 2: The solution MUST allow Diameter nodes to support overload >> control regardless of which Diameter applications they >> support. Diameter clients and agents must be able to use the >> received load and overload information to support graceful >> behavior during an overload condition. Graceful behavior >> under overload conditions is best described by REQ 3. >>=20 >> *Compliant*. The DOIC AVPs can be used in any application >> that allows the extension of AVPs. >>=20 >>=20 >>=20 >> REQ 3: The solution MUST limit the impact of overload on the overall >> useful throughput of a Diameter server, even when the >> incoming load on the network is far in excess of its >> capacity. The overall useful throughput under load is the >> ultimate measure of the value of a solution. >>=20 >> *Compliant*. DOIC provides information that nodes can use to >> reduce the impact of overload. >>=20 >>=20 >>=20 >> REQ 4: Diameter allows requests to be sent from either side of a >> connection, and either side of a connection may have need to >> provide its overload status. The solution MUST allow each >> side of a connection to independently inform the other of its >> overload status. >>=20 >> *Compliant*. DOIC AVPs can be included regardless of >> transaction "direction" >>=20 >>=20 >>=20 >> REQ 5: Diameter allows nodes to determine their peers via dynamic >> discovery or manual configuration. The solution MUST work >> consistently without regard to how peers are determined. >>=20 >> *Compliant*. DOIC contains no assumptions about how peers are >> discovered. [Note: This may require further study] >>=20 >>=20 >>=20 >> REQ 6: The solution designers SHOULD seek to minimize the amount of >> new configuration required in order to work. For example, it >> is better to allow peers to advertise or negotiate support >> for the solution, rather than to require that this knowledge >> to be configured at each node. >>=20 >> *Partially Compliant*. Most DOIC parameters are advertised >> using the DOIC capability announcement mechanism. However, >> there are some situations where configuration is required. >> For example, a DOIC node detect the fact that a peer may not >> support DOIC when nodes on the other side of the non- >> supporting node do support DOIC without configuration. >>=20 >>=20 >>=20 >> E.2.2. Performance >>=20 >> REQ 7: The solution and any associated default algorithm(s) MUST >> ensure that the system remains stable. At some point after >> an overload condition has ended, the solution MUST enable >> capacity to stabilize and become equal to what it would be in >> the absence of an overload condition. Note that this also >> requires that the solution MUST allow nodes to shed load >> without introducing non-converging oscillations during or >> after an overload condition. >>=20 >> *Compliant*. The specification offers guidance that >> implementations should apply hysteresis when recovering from >> overload, and avoid sudden ramp ups in offered load when >> recovering. >>=20 >>=20 >>=20 >> REQ 8: Supporting nodes MUST be able to distinguish current overload >> information from stale information. >>=20 >> *Partially Compliant*. DOIC overload reports are "soft >> state", that is they expire after an indicated period. DOIC >> nodes may also send reports that end existing overload >> conditions. DOIC requires reporting nodes to ensure that all >> relevant reacting nodes receive overload reports. >>=20 >> However, since DOIC does not allow reports to send OLRs in >> watchdog messages, if an overload condition results in zero >> offered load, the reporting node cannot update the condition >> until the expiration of the original OLR. >>=20 >>=20 >>=20 >> REQ 9: The solution MUST function across fully loaded as well as >> quiescent transport connections. This is partially derived >> from the requirement for stability in REQ 7. >>=20 >> *Not Compliant*. DOIC does not allow OLRs to be sent over >> quiescent transport connections. This is due to the fact >> that OLRs cannot be sent outside of the application to which >> they apply. >>=20 >>=20 >>=20 >> REQ 10: Consumers of overload information MUST be able to determine >> when the overload condition improves or ends. >>=20 >> *Partially Compliant*. (See response to previous two >> requirements.) >>=20 >>=20 >>=20 >> REQ 11: The solution MUST be able to operate in networks of different >> sizes. >>=20 >> *Compliant*. DOIC makes no assumptions about the size of the >> network. DOIC can operate purely between clients and >> servers, or across agents. >>=20 >>=20 >>=20 >> REQ 12: When a single network node fails, goes into overload, or >> suffers from reduced processing capacity, the solution MUST >> make it possible to limit the impact of the affected node on >> other nodes in the network. This helps to prevent a small- >> scale failure from becoming a widespread outage. >>=20 >> *Partially Compliant*. DOIC allows overload reports for an >> entire realm, where abated traffic will not be redirected >> towards another server. But in situations where nodes choose >> to divert traffic to other nodes, DOIC offers no way of >> knowing whether the new recipients can handle the traffic if >> they have not already indicated overload. This may be >> mitigated with the use of a future "load" extension, or with >> the use of proprietary dynamic load-balancing mechanisms. >>=20 >>=20 >>=20 >> REQ 13: The solution MUST NOT introduce substantial additional work >> for a node in an overloaded state. For example, a >> requirement for an overloaded node to send overload >> information every time it received a new request would >> introduce substantial work. >>=20 >> *Not Compliant*. DOIC does in fact encourage an overloaded >> node to send an OLR in every response. The working group >> that other mechanisms to ensure that every relevant node >> receives an OLR would create even more work. [Note: This >> needs discussion.] >>=20 >>=20 >>=20 >> REQ 14: Some scenarios that result in overload involve a rapid >> increase of traffic with little time between normal levels >> and levels that induce overload. The solution SHOULD provide >> for rapid feedback when traffic levels increase. >>=20 >> *Compliant*. The piggyback mechanism allows OLRs to be sent >> at the same rate as application traffic. >>=20 >>=20 >>=20 >> REQ 15: The solution MUST NOT interfere with the congestion control >> mechanisms of underlying transport protocols. For example, a >> solution that opened additional TCP connections when the >> network is congested would reduce the effectiveness of the >> underlying congestion control mechanisms. >>=20 >> *Compliant*. DOIC does not require or recommend changes in >> the handling of transport protocols or connections. >>=20 >>=20 >>=20 >> E.2.3. Heterogeneous Support for Solution >>=20 >> 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. >>=20 >> *Partially Compliant*. DOIC works with most mixed-deployment >> scenarios. However, it cannot work across a non-supporting >> proxy that modifies Origin-Host AVPs in answer messages. >> DOIC will have limited impact in networks where the nodes >> that perform server selections do not support the mechanism. >>=20 >>=20 >>=20 >> REQ 17: In a mixed environment with nodes that support the solution >> and nodes that do not, the solution MUST NOT result in >> materially less useful throughput during overload as would >> have resulted if the solution were not present. It SHOULD >> result in less severe overload in this environment. >>=20 >> *Compliant*. In most mixed-support deployment, DOIC will >> offer at least some value, and will not make things worse. >>=20 >>=20 >>=20 >> 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. >>=20 >> *Compliant*. DOIC provides mechanisms to abate load from non- >> supporting sources. Furthermore, it recommends that >> reporting nodes will still need to be able to apply whatever >> protections they would ordinarily apply if DOIC were not in >> use. >>=20 >>=20 >>=20 >> REQ 19: It MUST be possible to use the solution between nodes in >> different realms and in different administrative domains. >>=20 >> *Partially Compliant*. DOIC allows sending OLRs across >> administrative domains, and potentially to nodes in other >> realms. However, an OLR cannot indicate overload for realms >> other than the one in the Origin-Realm AVP of the containing >> answer. >>=20 >>=20 >>=20 >> REQ 20: Any explicit overload indication MUST be clearly >> distinguishable from other errors reported via Diameter. >>=20 >> *Compliant*. DOIC sends explicit overload indication in >> overload reports. It does not depend on error result codes. >> [Note: I don't think the resuse of too-busy and unable-to- >> comply for throttled requests impacts this requirement. Do >> others agree?] >>=20 >>=20 >>=20 >> REQ 21: In cases where a network node fails, is so overloaded that it >> cannot process messages, or cannot communicate due to a >> network failure, it may not be able to provide explicit >> indications of the nature of the failure or its levels of >> overload. The solution MUST result in at least as much >> useful throughput as would have resulted if the solution were >> not in place. >>=20 >> *Compliant*. DOIC overload reports have the primary effect of >> suppressing message retries in overload conditions. DOIC >> recommends that messages never be silently dropped if at all >> possible. >>=20 >>=20 >>=20 >> E.2.4. Granular Control >>=20 >> REQ 22: The solution MUST provide a way for a node to throttle the >> amount of traffic it receives from a peer node. This >> throttling SHOULD be graded so that it can be applied >> gradually as offered load increases. Overload is not a >> binary state; there may be degrees of overload. >>=20 >> *Compliant*. The "loss" algorithm expresses a percentage >> reduction. >>=20 >>=20 >>=20 >> REQ 23: The solution MUST provide sufficient information to enable a >> load-balancing node to divert messages that are rejected or >> otherwise throttled by an overloaded upstream node to other >> upstream nodes that are the most likely to have sufficient >> capacity to process them. >>=20 >> *Not Compliant*. DOIC provides no built in mechanism to >> determine the best place to divert messages that would >> otherwise be throttled. This can be accomplished with a >> future "load" extension, or with proprietary load balancing >> mechanisms. >>=20 >>=20 >>=20 >> REQ 24: The solution MUST provide a mechanism for indicating load >> levels, even when not in an overload condition, to assist >> nodes in making decisions to prevent overload conditions from >> occurring. >>=20 >> *Not Compliant*. "Load" information has been left for a >> future extension. >>=20 >>=20 >>=20 >> E.2.5. Priority and Policy >>=20 >> REQ 25: The base specification for the solution SHOULD offer general >> guidance on which message types might be desirable to send or >> process over others during times of overload, based on >> application-specific considerations. For example, it may be >> more beneficial to process messages for existing sessions >> ahead of new sessions. Some networks may have a requirement >> to give priority to requests associated with emergency >> sessions. Any normative or otherwise detailed definition of >> the relative priorities of message types during an overload >> condition will be the responsibility of the application >> specification. >>=20 >> *Compliant*. The specification offers guidance on how >> requests might be prioritized for different types of >> applications. >>=20 >>=20 >>=20 >> REQ 26: The solution MUST NOT prevent a node from prioritizing >> requests based on any local policy, so that certain requests >> are given preferential treatment, given additional >> retransmission, not throttled, or processed ahead of others. >>=20 >> *Compliant*. Nothing in the specification prevents >> application-specific, implementation-specific, or local >> policies. >>=20 >>=20 >>=20 >> E.2.6. Security >>=20 >> REQ 27: The solution MUST NOT provide new vulnerabilities to >> malicious attack or increase the severity of any existing >> vulnerabilities. This includes vulnerabilities to DoS and >> DDoS attacks as well as replay and man-in-the-middle attacks. >> Note that the Diameter base specification [RFC6733] lacks >> end-to-end security and this must be considered (see the >> Security Considerations in [RFC7068]). Note that this >> requirement was expressed at a high level so as to not >> preclude any particular solution. Is is expected that the >> solution will address this in more detail. >>=20 >> *Compliant*. The working group is not aware of any such >> vulnerabilities. [This may need further analysis.] >>=20 >>=20 >>=20 >> REQ 28: The solution MUST NOT depend on being deployed in >> environments where all Diameter nodes are completely trusted. >> It SHOULD operate as effectively as possible in environments >> where other nodes are malicious; this includes preventing >> malicious nodes from obtaining more than a fair share of >> service. Note that this does not imply any responsibility on >> the solution to detect, or take countermeasures against, >> malicious nodes. >>=20 >> *Partially Compliant*. Since all Diameter security is >> currently at the transport layer, nodes must trust immediate >> peers to enforce trust policies. However, there are >> situations where a DOIC node cannot determine if an immediate >> peer supports DOIC. The authors recommend an expert security >> review. >>=20 >>=20 >>=20 >> REQ 29: It MUST be possible for a supporting node to make >> authorization decisions about what information will be sent >> to peer nodes based on the identity of those nodes. This >> allows a domain administrator who considers the load of their >> nodes to be sensitive information to restrict access to that >> information. Of course, in such cases, there is no >> expectation that the solution itself will help prevent >> overload from that peer node. >>=20 >> *Partially Compliant*. (See response to previous >> requirement.) >>=20 >>=20 >>=20 >> REQ 30: The solution MUST NOT interfere with any Diameter-compliant >> method that a node may use to protect itself from overload >> from non-supporting nodes or from denial-of-service attacks. >>=20 >> *Compliant*. The specification recommends that any such >> protection mechanism needed without DOIC should continue to >> be employed with DOIC. >>=20 >>=20 >>=20 >> E.2.7. Flexibility and Extensibility >>=20 >> 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. >>=20 >> *Partially Compliant*. All DOIC overload reports are scoped >> to the specific application and realm. Inside that scope, >> overload can be reported at the specific server or whole >> realm scope. As currently specified, DOIC cannot indicate >> local overload for an agent. At the time of this writing, >> the DIME working group has plans to work on an agent-overload >> extension. >>=20 >> DOIC allows new "scopes" through the use of extended report >> types. >>=20 >>=20 >>=20 >> REQ 32: The solution MUST provide a method for extending the >> information communicated and the algorithms used for overload >> control. >>=20 >> *Compliant*. DOIC allows new report types and abatement >> algorithms to be created. These may be indicated using the >> OC-Supported-Features AVP. >>=20 >>=20 >>=20 >> REQ 33: The solution MUST provide a default algorithm that is >> mandatory to implement. >>=20 >> *Compliant*. The "loss" algorithm is mandatory to implement. >>=20 >>=20 >>=20 >> REQ 34: The solution SHOULD provide a method for exchanging overload >> and load information between elements that are connected by >> intermediaries that do not support the solution. >>=20 >> *Partially Compliant*. DOIC information can traverse non- >> supporting agents, as long as those agents do not modify >> certain AVPs. (e.g., Origin-Host). DOIC does not provide a >> way for supporting nodes to detect such modification. >>=20 >>=20 >=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 Tue Nov 11 01:19: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 625B11A8894 for ; Tue, 11 Nov 2014 01:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlEbiVthgOxw for ; Tue, 11 Nov 2014 01:18:59 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EE51A1BDF for ; Tue, 11 Nov 2014 01:18:58 -0800 (PST) Received: from [10.10.1.7] (50.97.94.13-static.reverse.softlayer.com [50.97.94.13]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAB9Ip9i003974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 03:18:57 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 50.97.94.13-static.reverse.softlayer.com [50.97.94.13] claimed to be [10.10.1.7] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell Date: Mon, 10 Nov 2014 23:18:51 -1000 X-Mao-Original-Outgoing-Id: 437390330.983878-36ba350428b1dd961151502d48a549ef Content-Transfer-Encoding: quoted-printable Message-Id: <2B851603-2DAF-4333-BD95-CFB9081B9529@nostrum.com> To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/00-yrLNDnBJ_WPzGoGBBx27YtWg Subject: [Dime] DOIC 05 Issues X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 09:19:04 -0000 Hi, I've done a new review of version 05 (not 04) of the DOIC draft, as it = was in the GitHub a of Saturday morning. I have some editorial comments = I think can be dealt with offline, but I think the following comments = probably need some group discussion. Thanks! Ben. -------------------------------------- -- section 3, and other places: We are inconsistent on what we mean by abatement, especially in terms of = abating across a set or stream of messages, vs applying abatement to a = message. I think we want the idea of applying abatement, or an abatement = "treatment" to a message or a set of messages means that we have made = that message or set of messages a _candidate_ for throttling or = diversion, based on the abatement algorithm. That's not the same thing = as saying that a message was rejected or diverted. We have places in the draft where we use it this way, but other places = (e.g. in the "loss" definition", where we say that we apply an abatement = treatment when we actually reject or divert. So I think if we say, for example, if we apply abatement using the loss = algorithm and a 20% reduction, to a set, we mean that set has 20% of the = messages rejected or diverted. If we say we apply it to a single = message, we mean that message has a 20% chance of being rejected... -- section 3.2: We say the first node in the path that supports DOIC inserts OC-S-F. We = have enough cases where insertion (or modification) may occur elsewhere = that I think we'd be better off saying "A node that supports DOIC = inserts..." without worrying about where it is in the path. The description of how a node indicates support for "loss" is not = completely consistent with section 5. In general, I think this section tries to over specify when and why an = agent might insert, modify, or remove OC-S-F. We've discussed that any = agent doing these things can probably be considered a proxy, and we = can't really control when a proxy might do these things. The 5th paragraph describes the way the reporting node selects the = algorithm as being the "one exception" from having nodes indicate = everything they support. I think there may be other exceptions in future = extensions--such things should be left to the extension definitions. -- 3.3, third paragraph from end: "The method used for that abatement is = dependent on the abatement algorithm"=20 I think the algorithm decides how many requests are abated, not _how_ = they are abated. We could think of the algorithm as a selection = mechanism. -- 3.4, last paragraph: Why do we assume all extensions must be announced? What if we had an = extension that added some new AVP that is safe to ignore, would we have = to have a feature bit for it? -- 4.1.1, 5th paragraph: Do we expect the feature sets to differ between applications, or do we = envision supporting some feature for some transactions but not others in = the _same_ application? -- 4.1.2, 2nd paragraph: The text only requires the reacting node to include OC-S-F if the = reacting node included it. Didn't we decide to always require the = reporting node to explicitly indicate the selected algorithm? -- 4.1.2, paragraph 4: "subsequent answer messages" We say the reporting node acts "accordingly for the subsequent answer = messages it initiates". This is really per-transaction, right? Do we = have a rule that prevents a reactor from changing its support between = transactions? Does the reporter care about anything except what came in = this transaction? Do we need guidance about changing algorithms when not overloaded? -- 4.1.3, paragraph 1: The text implies that agents SHOULD act on behalf of non supporting = nodes. I think that's entirely an implementation and deployment choice. = I suggest we change this to MAY. -- 4.2.1.3, paragraph 6: "...MUST determine if the OLR is a = retransmission or an update ..." That doesn't sound right. The sequence number was supposed to be an = optimization to allow the reactor to ignore certain reports. There's no = reason it couldn't do this by simply treating each report as if it were = an update. If that's not true, then we've broken something. -- 4.2.1.4, paragraph 3: Is there any reason not to just always start the sequence number at 1 = (or 0)? -- ... paragraph 4: " the new sequence number MUST be greater than any = sequence number in an active (unexpired) overload report previously sent = by the reporting node" Any report? Or just any matching report? I.e. What if there are reports = of different types? How does this work if the reporting node is an agent = in some cases and a server in others? -- 4.2.2, last paragraph: Can we elaborate on what it means to end abatement in a "controlled = fashion"? -- 4.2.3, 2nd paragraph The text says you SHOULD keep resending an OLR in response to requests = that match the related OCS. I'm afraid people will read that to limit = sending OLRs to requests that match the report-type. -- ..., paragraph 9: " RECOMMENDED that the reporting node always = explicitly indicates the end of a overload condition" I still disagree with this. We want to make the reporter end the = overload condition in a timely manner. Why do we care how, as long as = it's timely? -- 6.5, first paragraph: The default duration should be a value we think we be very common. 5s = seems a bit short. -- 6.6, definition of "host report" This does not include the "node has some other local knowledge of the = server selection" case that I thought had been discussed. (I thought we = were going to have this section refer to the definition of host-routed = and realm-routed requests, rather than restate things? ) -- 6.7, last paragraph: "The default value of the = OC-Reduction-Percentage AVP is 0. When the OC-Reduction-Percentage AVP = is not present in the overload report, the default value applies" This is inconsistent with the definition of the loss algorithm, which = says the AVPS must always be included. Some other algorithm might make = it optional, and two such algorithms might have different details, so I = suggest we leave this up to algorithm definitions, and don't mention it = here. -- 6.8, last paragraph, last sentence: I thought we agreed to remove all guidance for use of the M-Bit, and = just refer to 6733 rules. -- 8.2: We probably need a bit more detail about what goes into the registry, = especially for the 2nd one. I assume we don't mean for the verbose = description of report types, for example, to go in. It would help to = list the information elements that we expect to actually show in the = registries. From nobody Tue Nov 11 04:46: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 442EB1A89F2 for ; Tue, 11 Nov 2014 04:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 AiI7g3Zl_cif for ; Tue, 11 Nov 2014 04:46:39 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82871A802F for ; Tue, 11 Nov 2014 04:46:38 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sABCkaFR014754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 12:46:36 GMT 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 sABCkYdr031362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 13:46:35 +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.195.1; Tue, 11 Nov 2014 13:46:34 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.88]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 13:46:34 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "Maria Cruz Bartolome" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zS149M3XUUPk28UQPOO8ZJK5xXdZWAgAKSXaCAAAR7gIABTKMw Date: Tue, 11 Nov 2014 12:46:33 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> In-Reply-To: <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.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: 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: 7248 X-purgate-ID: 151667::1415709996-0000437E-56692550/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7ctGo03Q2ivq0mX-hK7e4dx2RaQ Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 12:46:42 -0000 Lionel, I am very sorry. Some of my comments are immediate reactions to MCruz's comments. I do not r= epeat those here (assuming that people who can read MCruz's comments can al= so read my reaction, while people who cannot will not be able to understand= my reaction anyway as it would be out of context). Please find other comments below. Ulrich Section 3, 4th paragraph from end, 2nd sentence: Existing text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or via other agents. Proposed text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or - if agent overload control is supported (Section A.2) - via = other agents. Section 3, last paragraph, 3rd sentence from end: Existing text: For example, one or more Diameter agents that do not support DOIC may exist= between a given pair of reporting and reacting nodes, as long as those age= nts pass unknown AVPs through unchanged. Proposed text: For example, one or more Diameter agents that do or do not s= upport DOIC may exist between a given pair of reporting and reacting nodes,= as long as those agents pass OC-specific AVPs or unknown AVPs through unch= anged. Section 3.2, 3rd paragraph last sentence: Existing text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= es in the path of the request.=20 Proposed text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= e in the path of the request. Section 3.2, 2nd paragraph from end, 2nd sentence: Existing text: In this case, the agent updates the OC-Supported-Feature AVP= to reflect the mixture of the two sets of supported features. Proposed text: In this case, the agent can replace the OC-Supported-Feature= s AVP (which indicates the features supported by the downstream reacting no= de) with its own OC-Supported-Feature AVP (which indicates the features sup= ported by the agent). By doing so, the agent takes the role of a reporting = node (reporting towards the downstream reacting node) and at the same time = takes the role of a reacting node (reacting on OLRs received from upstream = reporting nodes).=20 Section 4.1.3, 1st paragraph, 1st sentence: Existing text: Diameter agents that support DOIC SHOULD ensure that all mes= sages have the OC-Supporting-Features AVP. Proposed text: Diameter agents that support DOIC SHOULD ensure that all req= uest messages have the OC-Supported-Features AVP. Section 4.1.3, 1st paragraph, 2nd sentence: Existing text: If a message handled by the DOIC agent does not include the = OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. Proposed text: If a request message handled by the DOIC agent does not incl= ude the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP= .=20 Section 4.1.3, 3rd paragraph, 1st sentence: Existing text: If the message already has the OC-Supported-Features AVP the= n the agent either leaves it unchanged in the relayed message or modifies i= t to reflect a mixed set of DOIC features. Proposed text: If the request message already has the OC-Supported-Features= AVP then the agent either leaves it unchanged in the relayed message or mo= difies it to reflect the agent's set of supported DOIC features. Section 4.1.3, 5th paragraph, 1st sentence: Existing text: An agent MAY modify the OC-Supported-Features AVP carried in= answer messages. Proposed text: An agent MAY replace the OC-Supported-Features AVP carried i= n answer messages (which indicates the features supported/selected by the u= pstream reporting node) with its own OC-Supported-Feature AVP (which indica= tes the features supported/selected by the agent). Section 4.2.3, 13th paragraph, 2nd sentence: Existing text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the OLR applies. Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the sent OLR applies. Section 6.5, 1st paragraph, 5th sentence Existing text: Validity duration with values above 86400 (i.e.; 24 hours) M= UST NOT be used. Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours= ) MUST NOT be used. =20 -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Monday, November 10, 2014 5:49 PM To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org; Wiehe, Ulrich (NSN = - DE/Munich) Subject: Re: [Dime] Updates to DOIC -05 Hi Ulrich and Mar=EDa Cruz, Please stop commenting through attached documents, requested several times = and explained again yesterday by Ben. Some people may not be able to read a= t all the attached documents and it makes impossible parsing mechanism in t= he mailing list and in the archives. Please write your comments directly in the email. Thank you. lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Wiehe, Ulrich (NSN - DE/Munich) a =E9crit ---- Sreve, MCruz, all, please find more comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Sunday, November 09, 2014 2:17 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Steve, all, See some comments included in attached doc. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 03 de noviembre de 2014 15:36 To: dime@ietf.org Subject: [Dime] Updates to DOIC -05 All, I have done another end-to-end read of the DOIC specification, focusing on = wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. 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. From nobody Tue Nov 11 05: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 84F7F1A89F5 for ; Tue, 11 Nov 2014 05:24:25 -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 YoeiHsVLzpIH for ; Tue, 11 Nov 2014 05:24:24 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C998B1A9140 for ; Tue, 11 Nov 2014 05:24:23 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi2so1599438wib.7 for ; Tue, 11 Nov 2014 05:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0HGC3MvduQYBlzF9FkSChHHpWCGrpnWtaolpGMhRlyw=; b=OdOcF1jDWtJT0lPNWBgGfDk30sQwjqSj9p/6vkJkAtOLhwXoDFUClwBUWYaTPSsB/e N7JrWleCPxNgP0g4ZOKMFq5RC5YtCMI4NhWNUo0uf685AkozFbg/bngWW3MvllNpLVMM T9nnjKiadCw53U5Rs9rR22KN58yzaKUr3ML7imYZn/StNWYqQKPBqT4B69etDSdmQXn8 VQlpKcU+lmF2RMb1VUOdImI95E+jB4CEaG0d/C69BUOsouLB2+KhW9QBUeSx5Ap6L9r3 K0Mph8vLXAJw7bSG9OINIByjj1E441hRKsWoJgDuGgV3alb0/qXKurT4qNjyw4xIG+vl UU/A== X-Received: by 10.180.82.4 with SMTP id e4mr40060269wiy.42.1415712262576; Tue, 11 Nov 2014 05:24:22 -0800 (PST) Received: from ?IPv6:2001:67c:370:136:f909:46ed:d2b:f4f5? (t2001067c03700136f90946ed0d2bf4f5.hotel-wireless.v6.meeting.ietf.org. [2001:67c:370:136:f909:46ed:d2b:f4f5]) by mx.google.com with ESMTPSA id fi9sm17498677wib.6.2014.11.11.05.24.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 05:24:21 -0800 (PST) Message-ID: <54620E00.6070601@gmail.com> Date: Tue, 11 Nov 2014 15:24:16 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> In-Reply-To: <545792B6.8030502@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5Qhu7jyCJKgcYPVZUzXkkAaRIoc Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 13:24:25 -0000 Steve, Thanks for the updated version. There are few long standing editorials e.g. in Sections 4.2.1.1., 4.2.1.3 that should be corrected. In Section 4.2.1.1: OLD: A host-type OCS entry is identified by the pair of Application-Id and Host-Id. NEW: A host-type OCS entry is identified by the pair of application-id and node's DiameterIdentity. OLD: A realm-type OCS entry is identified by the pair of Application-Id and Realm-Id. NEW: A realm-type OCS entry is identified by the pair of application-id and realm. In Section 4.2.1.3. OLD: For a host report-type this means it matches the app-id and host-id in an existing host OCS entry. NEW: For a host report-type this means it matches the application-id and host's DiameterIdentity in an existing host OCS entry. OLD: For a realm report-type this means it matches the app-id and realm-id in an existing realm OCS entry. NEW: For a realm report-type this means it matches the application-id and the realm in an existing realm OCS entry. OLD: For a host report-type this means it creates on OCS entry with the app-id of the application-id in the received message and host-id of the Origin-Host in the received message. NEW: For a host report-type this means it creates on OCS entry with the application-id in the received message and DiameterIdentity of the Origin-Host in the received message. OLD: For a realm report-type this means it creates on OCS entry with the app-id of the application-id in the received message and realm-id of the Origin-Realm in the received message. NEW: For a realm report-type this means it creates on OCS entry with the application-id in the received message and realm of the Origin-Realm in the received message. Actually.. when we talk about the "realm" in the context of Origin-Realm, tchnically we should still be talk about DiameterIdentity. However, I am ok just saying "realm" here. - Jouni 11/3/2014 4:35 PM, Steve Donovan kirjoitti: > All, > > I have done another end-to-end read of the DOIC specification, focusing > on wording, consistency and removing any remaining redundancy in the > document. > > I have pushed the changes into github. > > I have attached the diff to this email. > > Regards, > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Nov 11 07:11: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 BBA1E1A8A96 for ; Tue, 11 Nov 2014 07:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-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 7AXVtsX36tmE for ; Tue, 11 Nov 2014 07:11:13 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D5E1A8A8A for ; Tue, 11 Nov 2014 07:11:10 -0800 (PST) Received: from dhcp-893f.meeting.ietf.org ([31.133.137.63]:53497) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XoD63-000C2J-EY; Tue, 11 Nov 2014 07:11:09 -0800 Message-ID: <54622707.3040308@usdonovans.com> Date: Tue, 11 Nov 2014 05:11:03 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/evQQthtLrcc1HBSzbi9Bnssx4PY Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 15:11:18 -0000 Maria Cruz, Would it be possible for you to break out the comments that you think need group discussion, especially those that Ulrich commented on in the word document he sent? Then we can work through the list of issues known issues in the issue tracker and in editor notes in the document plus new issues sent by you, Ulrich, Jouni and Ben. Thanks, Steve On 11/8/14, 3:16 PM, Maria Cruz Bartolome wrote: > Steve, all, > > See some comments included in attached doc. > Best regards > /MCruz > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: lunes, 03 de noviembre de 2014 15:36 > To: dime@ietf.org > Subject: [Dime] Updates to DOIC -05 > > All, > > I have done another end-to-end read of the DOIC specification, focusing on wording, consistency and removing any remaining redundancy in the document. > > I have pushed the changes into github. > > I have attached the diff to this email. > > Regards, > > Steve From nobody Tue Nov 11 08:58: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 14C6D1A1A8E for ; Tue, 11 Nov 2014 08:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGUUvn6gB2CO for ; Tue, 11 Nov 2014 08:58:42 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1601A1A76 for ; Tue, 11 Nov 2014 08:58:40 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-04-5462403e8b48 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 65.62.24955.E3042645; Tue, 11 Nov 2014 17:58:38 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.145]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Tue, 11 Nov 2014 17:58:38 +0100 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXWwkggAQoRICAACYT4A== Date: Tue, 11 Nov 2014 16:58:37 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92098580CC@ESESSMB101.ericsson.se> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> <54622707.3040308@usdonovans.com> In-Reply-To: <54622707.3040308@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja6dQ1KIQdN7A4u5vSvYLDY08Tgw eSxZ8pPJY9XbPtYApigum5TUnMyy1CJ9uwSujJ3HlrAUXHKv+DXzDGMDY4t5FyMHh4SAicSU zdVdjJxAppjEhXvr2boYuTiEBI4wSiycdo0RwlnCKLGnoZUFpIpNwE7i0ukXTCC2iICvxPHO 02BxYQF1ieU7f7FCxDUk+o6sZoawnST+TfsDVs8ioCpxb8VSsHpekN6Gm8wQC6YySpxvX8EG kuAU0JPYdvgFO4jNCHTS91NrwJqZBcQlbj2ZzwRxqoDEkj3nmSFsUYmXj/+xQthKEo1LnrBC 1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqR sV5qUWZycXF+nl5easkmRmCcHNzyW3UH4+U3jocYBTgYlXh4N1QnhgixJpYVV+YeYpTmYFES 5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbavwdW1sSz7JeqE/v6dR9H9KZDnyPD X2w4HfRBn8vy80eN5Dl2ZUtK1Hcsl3PYsZi/TW/Ws8xHEVMcnb2b5ZkmmlbG6+cKZVc2JbPI /eLYUXj61ifT8h1epT80KpWSNP4tYzOL13xdke9W2TiNt0nz4KYgwYiZXlZP4jf9M3mYdMXZ LuyzlhJLcUaioRZzUXEiAFFat6t0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gIR0OBCXZAVkJyMOL7hNxM0vqk8 Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:58:45 -0000 Steve, all, See below the comments that may require some group discussion: Ch 2: Now: Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Proposal: Diversion Abatement of traffic sent to a reporting node performed by a reacting= n. The abatement is achieved by diverting (?) traffic from the reporting node to a less o= verloaded Diameter node that is able to process the request, based on received = overload report(s). ?: any better word to avoid using "diverting" when we are defining "diversi= on"? Ch 2: Now: Overload Report (OLR) Information sent by a reporting node indicating the start, continuation or end of an occurrence of overload control. Proposed: Overload Report (OLR) Information sent by a reporting node about its overload situation. Ch2 Now Reacting Node A Diameter node that receives and acts upon an overload report. Proposed: Reacting Node A Diameter node that acts upon an overload report. Ch2: Now Throttling Abatement of traffic sent to a reporting node by dropping or rejecting Diameter requests. Throttling can include a Diameter Client or Diameter Server dropping requests, or a Diameter Agent rejecting requests with appropriate error responses. In extreme cases reporting nodes can also throttle requests when the requested reductions in traffic does not sufficiently address the overload scenario. Proposed: Throttling Abatement of traffic by dropping or rejecting Diameter requests. Throttling can include a Diameter Client or Diameter Server dropping requests, or a Diameter Agent rejecting requests with appropriate error responses (?). In extreme cases reporting nodes can also throttle (or drop) requests when the requested reductions in traffic does not sufficiently address the overload scenario. ?: Question: do we consider an agent is not allowed to DROP a request? Ch3 Now: A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes . Proposed: A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to a reacting node. Ch3. Question: A reacting node acts upon OLRs, and performs whatever actions are needed to fulfil the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream ??) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream?? ) nodes. "Typically"? is any other possibility? Ch3: modification and question Now: A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Relay and Proxy Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, a given Diameter nodes can simultaneously act as a reporting node and a reacting node Proposed: A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Relay (?) and Proxy Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, those Diameter nodes can simultaneously act as a reporting node and a reacting node. Can a Relay be a DOIC node? Since by definition is application-less? If DOI= C-enabled, can it be considered a "relay" any longer? We had this discussion before, but not sure whether we reached a conclusion= . Ch3 Now: Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. Proposed: Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm may defines the meaning of some of the parameters of an OLR and the procedures required for overloa= d abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. 4.2.1.2. Overload Control State for Reporting Nodes Now: A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the pair of Application-Id and Abatement Algorithm. The OCS entry for a given pair of Application and Abatement Algorithm MAY include the information (the actual information stored is an implementation decision): o Report type o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) Proposed: A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the pair of Application-Id,=20 Abatement Algorithm and Report Type and MAY include the following inform= ation (the actual information stored is an implementation decision): o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) 4.2.1.4 =20 Question on following paragraph: If the reporting node knows that the OCS entries in the reacting nodes are near expiration then the reporting node can decide to delete the OCS entry. This paragraph is unclear to me. "knows that the OCS entries in the reacting"? "decide to delete the OCS entry"? Could you clarify what was the intention? 5.3 Now: It is suggested that the reacting node decrease the amount of traffic given abatement treatment by 20% each second until the reduction is completely removed and no traffic is given abatement treatment. Proposed: It is suggested that the reacting node decrease progressively the amount= of traffic given abatement treatment until the reduction is completely removed and no traffic is given abatement treatment. Justification: Not sure we have discussed the reasoning for this value. And it may not be applicable to all overload occurrences and traffic rates. 6.8 Remove: Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. And refer 6733 RFC. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: martes, 11 de noviembre de 2014 16:11 To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Maria Cruz, Would it be possible for you to break out the comments that you think need = group discussion, especially those that Ulrich commented on in the word doc= ument he sent? Then we can work through the list of issues known issues in the issue track= er and in editor notes in the document plus new issues sent by you, Ulrich,= Jouni and Ben. Thanks, Steve On 11/8/14, 3:16 PM, Maria Cruz Bartolome wrote: > Steve, all, > > See some comments included in attached doc. > Best regards > /MCruz > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: lunes, 03 de noviembre de 2014 15:36 > To: dime@ietf.org > Subject: [Dime] Updates to DOIC -05 > > All, > > I have done another end-to-end read of the DOIC specification, focusing o= n wording, consistency and removing any remaining redundancy in the documen= t. > > I have pushed the changes into github. > > I have attached the diff to this email. > > Regards, > > Steve From nobody Tue Nov 11 10:01: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 616641A0137 for ; Tue, 11 Nov 2014 10:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 O7B0wxzM6tiv for ; Tue, 11 Nov 2014 10:01:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E111A8739 for ; Tue, 11 Nov 2014 09:59:57 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id EAAD92AC2C4; Tue, 11 Nov 2014 18:59:55 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id CB8BC384066; Tue, 11 Nov 2014 18:59:55 +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.0210.002; Tue, 11 Nov 2014 18:59:55 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "Maria Cruz Bartolome" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zS149M3XUUPk28UQPOO8ZJK5xXdZWAgAKSXaCAAAR7gIABTKMwgABqDwA= Date: Tue, 11 Nov 2014 17:59:55 +0000 Message-ID: <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@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.6] 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.11.11.110919 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wLQtk9n3tnFk_C5h-N32E0rSjIU Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:01:31 -0000 Thank you, Ulrich. Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mardi 11 novembre 2014 13:47 =C0=A0: MORAND Lionel IMT/OLN; Maria Cruz Bartolome; Steve Donovan; dime@ie= tf.org Objet=A0: RE: [Dime] Updates to DOIC -05 Lionel, I am very sorry. Some of my comments are immediate reactions to MCruz's comments. I do not r= epeat those here (assuming that people who can read MCruz's comments can al= so read my reaction, while people who cannot will not be able to understand= my reaction anyway as it would be out of context). Please find other comments below. Ulrich Section 3, 4th paragraph from end, 2nd sentence: Existing text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or via other agents. Proposed text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or - if agent overload control is supported (Section A.2) - via = other agents. Section 3, last paragraph, 3rd sentence from end: Existing text: For example, one or more Diameter agents that do not support DOIC may exist= between a given pair of reporting and reacting nodes, as long as those age= nts pass unknown AVPs through unchanged. Proposed text: For example, one or more Diameter agents that do or do not s= upport DOIC may exist between a given pair of reporting and reacting nodes,= as long as those agents pass OC-specific AVPs or unknown AVPs through unch= anged. Section 3.2, 3rd paragraph last sentence: Existing text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= es in the path of the request.=20 Proposed text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= e in the path of the request. Section 3.2, 2nd paragraph from end, 2nd sentence: Existing text: In this case, the agent updates the OC-Supported-Feature AVP= to reflect the mixture of the two sets of supported features. Proposed text: In this case, the agent can replace the OC-Supported-Feature= s AVP (which indicates the features supported by the downstream reacting no= de) with its own OC-Supported-Feature AVP (which indicates the features sup= ported by the agent). By doing so, the agent takes the role of a reporting = node (reporting towards the downstream reacting node) and at the same time = takes the role of a reacting node (reacting on OLRs received from upstream = reporting nodes).=20 Section 4.1.3, 1st paragraph, 1st sentence: Existing text: Diameter agents that support DOIC SHOULD ensure that all mes= sages have the OC-Supporting-Features AVP. Proposed text: Diameter agents that support DOIC SHOULD ensure that all req= uest messages have the OC-Supported-Features AVP. Section 4.1.3, 1st paragraph, 2nd sentence: Existing text: If a message handled by the DOIC agent does not include the = OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. Proposed text: If a request message handled by the DOIC agent does not incl= ude the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP= .=20 Section 4.1.3, 3rd paragraph, 1st sentence: Existing text: If the message already has the OC-Supported-Features AVP the= n the agent either leaves it unchanged in the relayed message or modifies i= t to reflect a mixed set of DOIC features. Proposed text: If the request message already has the OC-Supported-Features= AVP then the agent either leaves it unchanged in the relayed message or mo= difies it to reflect the agent's set of supported DOIC features. Section 4.1.3, 5th paragraph, 1st sentence: Existing text: An agent MAY modify the OC-Supported-Features AVP carried in= answer messages. Proposed text: An agent MAY replace the OC-Supported-Features AVP carried i= n answer messages (which indicates the features supported/selected by the u= pstream reporting node) with its own OC-Supported-Feature AVP (which indica= tes the features supported/selected by the agent). Section 4.2.3, 13th paragraph, 2nd sentence: Existing text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the OLR applies. Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the sent OLR applies. Section 6.5, 1st paragraph, 5th sentence Existing text: Validity duration w= ith values above 86400 (i.e.; 24 hours) MUST NOT be used. Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours= ) MUST NOT be used.=20=20=20=20 -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Monday, November 10, 2014 5:49 PM To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org; Wiehe, Ulrich (NSN = - DE/Munich) Subject: Re: [Dime] Updates to DOIC -05 Hi Ulrich and Mar=EDa Cruz, Please stop commenting through attached documents, requested several times = and explained again yesterday by Ben. Some people may not be able to read a= t all the attached documents and it makes impossible parsing mechanism in t= he mailing list and in the archives. Please write your comments directly in the email. Thank you. lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Wiehe, Ulrich (NSN - DE/Munich) a =E9crit ---- Sreve, MCruz, all, please find more comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Sunday, November 09, 2014 2:17 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Steve, all, See some comments included in attached doc. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 03 de noviembre de 2014 15:36 To: dime@ietf.org Subject: [Dime] Updates to DOIC -05 All, I have done another end-to-end read of the DOIC specification, focusing on = wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. 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. 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. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Nov 11 10: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 0DC421A03A4 for ; Tue, 11 Nov 2014 10:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 angcojpzj8Gg for ; Tue, 11 Nov 2014 10:39:09 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38951A03A0 for ; Tue, 11 Nov 2014 10:39:08 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 9BD3E2AC205; Tue, 11 Nov 2014 19:39:07 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 76C2615805A; Tue, 11 Nov 2014 19:39: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.0210.002; Tue, 11 Nov 2014 19:39:07 +0100 From: To: Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP/cG1149M3XUUPk28UQPOO8ZJK5xblTGAgAAsrpA= Date: Tue, 11 Nov 2014 18:39:05 +0000 Message-ID: <24888_1415731147_546257CB_24888_7954_1_6B7134B31289DC4FAF731D844122B36E8C872A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> <54622707.3040308@usdonovans.com> <087A34937E64E74E848732CFF8354B92098580CC@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92098580CC@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.2] 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.11.11.110919 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-TuLc2tqT896jvP2zQvO-VotxKU Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:39:12 -0000 Thank you, Maria Cruz All, Please see below. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 11 novembre 2014 17:59 =C0 : Steve Donovan; dime@ietf.org Objet : Re: [Dime] Updates to DOIC -05 Steve, all, See below the comments that may require some group discussion: Ch 2: Now: Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Proposal: Diversion Abatement of traffic sent to a reporting node performed by a reacting= n. The abatement is achieved by diverting (?) traffic from the reporting node to a less o= verloaded Diameter node that is able to process the request, based on received = overload report(s). ?: any better word to avoid using "diverting" when we are defining "diversi= on"? [LM] Diversion by definition is not an abatement method. In the context of = Diameter, it is forcing the request traffic toward an alternative peer. One= of the reasons for this diversion can be overload of the primary selected = peer (identified in the Desination-host or selected by the forwarding node)= . But it is only of the reasons. If it required to restrict the definition = in this document, we could define a "an Abatement by diversion". Ch 2: Now: Overload Report (OLR) Information sent by a reporting node indicating the start, continuation or end of an occurrence of overload control. Proposed: Overload Report (OLR) Information sent by a reporting node about its overload situation. [LM] ok Ch2 Now Reacting Node A Diameter node that receives and acts upon an overload report. Proposed: Reacting Node A Diameter node that acts upon an overload report. [LM] ok Ch2: Now Throttling Abatement of traffic sent to a reporting node by dropping or rejecting Diameter requests. Throttling can include a Diameter Client or Diameter Server dropping requests, or a Diameter Agent rejecting requests with appropriate error responses. In extreme cases reporting nodes can also throttle requests when the requested reductions in traffic does not sufficiently address the overload scenario. Proposed: Throttling Abatement of traffic by dropping or rejecting Diameter requests. Throttling can include a Diameter Client or Diameter Server dropping requests, or a Diameter Agent rejecting requests with appropriate error responses (?). In extreme cases reporting nodes can also throttle (or drop) requests when the requested reductions in traffic does not sufficiently address the overload scenario. ?: Question: do we consider an agent is not allowed to DROP a request? [LM] Again, throttling is not link to abatement. Throttling refers to a lim= it of the number of messages sent or forwarded by a Diameter node. But this= limit can be set based on operator policy and not due to overload. See if = only a definition of throttling is required or a definition of "abatement b= y throttling". Ch3 Now: A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes . Proposed: A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to a reacting node. [LM] ok Ch3. Question: A reacting node acts upon OLRs, and performs whatever actions are needed to fulfil the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream ??) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream?? ) nodes. "Typically"? is any other possibility? [LM] I would propose to just remove "typically upstream/downstream". Ch3: modification and question Now: A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Relay and Proxy Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, a given Diameter nodes can simultaneously act as a reporting node and a reacting node Proposed: A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Relay (?) and Proxy Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, those Diameter nodes can simultaneously act as a reporting node and a reacting node. Can a Relay be a DOIC node? Since by definition is application-less? If DOI= C-enabled, can it be considered a "relay" any longer? We had this discussion before, but not sure whether we reached a conclusion. [LM] and the conclusion is that a Diameter Relay "by definition i.e. RFC673= 3" is application-agnostic and not able to act on received OLR. If you want= to get rid of the discussion, we can say "diameter agents" here, without f= urther distinction Ch3 Now: Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. Proposed: Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm may defines the meaning of some of the parameters of an OLR and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. [LM] ok 4.2.1.2. Overload Control State for Reporting Nodes Now: A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the pair of Application-Id and Abatement Algorithm. The OCS entry for a given pair of Application and Abatement Algorithm MAY include the information (the actual information stored is an implementation decision): o Report type o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) Proposed: A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the pair of Application-Id,=20 Abatement Algorithm and Report Type and MAY include the following inform= ation (the actual information stored is an implementation decision): o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) [LM] ok 4.2.1.4=20=20 Question on following paragraph: If the reporting node knows that the OCS entries in the reacting nodes are near expiration then the reporting node can decide to delete the OCS entry. This paragraph is unclear to me. "knows that the OCS entries in the reacting"? "decide to delete the OCS entry"? Could you clarify what was the intention? 5.3 Now: It is suggested that the reacting node decrease the amount of traffic given abatement treatment by 20% each second until the reduction is completely removed and no traffic is given abatement treatment. Proposed: It is suggested that the reacting node decrease progressively the amount= of traffic given abatement treatment until the reduction is completely removed and no traffic is given abatement treatment. Justification: Not sure we have discussed the reasoning for this value. And it may not be applicable to all overload occurrences and traffic rates. [LM] agree 6.8 Remove: Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. And refer 6733 RFC. [LM] as decided in the interim meeting. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: martes, 11 de noviembre de 2014 16:11 To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Maria Cruz, Would it be possible for you to break out the comments that you think need = group discussion, especially those that Ulrich commented on in the word doc= ument he sent? Then we can work through the list of issues known issues in the issue track= er and in editor notes in the document plus new issues sent by you, Ulrich,= Jouni and Ben. Thanks, Steve On 11/8/14, 3:16 PM, Maria Cruz Bartolome wrote: > Steve, all, > > See some comments included in attached doc. > Best regards > /MCruz > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: lunes, 03 de noviembre de 2014 15:36 > To: dime@ietf.org > Subject: [Dime] Updates to DOIC -05 > > All, > > I have done another end-to-end read of the DOIC specification, focusing o= n wording, consistency and removing any remaining redundancy in the documen= t. > > I have pushed the changes into github. > > I have attached the diff to this email. > > Regards, > > Steve _______________________________________________ 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 Tue Nov 11 11:04: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 6EBAA1A6FB1 for ; Tue, 11 Nov 2014 11:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCVD0ZDzyGOD for ; Tue, 11 Nov 2014 11:04:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB8B1A6F80 for ; Tue, 11 Nov 2014 11:04:24 -0800 (PST) Received: from dhcp-bbaf.meeting.ietf.org (dhcp-bbaf.meeting.ietf.org [31.133.187.175]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sABJ4FoK057500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 13:04:17 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <087A34937E64E74E848732CFF8354B920985724A@ESESSMB101.ericsson.se> Date: Tue, 11 Nov 2014 09:04:09 -1000 X-Mao-Original-Outgoing-Id: 437425448.968136-b3b880b04193750f146339e93e4c5b90 Content-Transfer-Encoding: quoted-printable Message-Id: <4C8FAB4B-4111-4588-A2A7-D4135B30EAA0@nostrum.com> References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> <545C7EA8.6070706@cisco.com> <087A34937E64E74E848732CFF8354B920985724A@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oc5vSJlA2o1Nvj2fSMuwTgpgcTk Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 19:04:26 -0000 >=20 > On Nov 8, 2014, at 3:16 PM, Maria Cruz Bartolome = wrote: >=20 > Dear Ben, > =20 > See my comments inserted in attached doc. > Thanks > /MCruz [...] Hi, responding to comments in text: Req 2: > "Since =E2=80=9Cload=E2=80=9D is not covered, at least it should be = partly compliant because of this reason." I agree, will fix. Req 5: > "Further study? What for?" I don't think we've thought through dynamic discovery use cases. I don't = envision a problem here; I just think we need to think it through. Req 6: > "Being a SHOULD, in my opinion DOIC is compliant." I disagree. The fact that it is a SHOULD doesn't give us a free pass. It = means that if we don't comply, we need to be able to document why. The = difference is, we are less likely to have people complain about not = complying with a SHOULD. > "Configuration is only required to cover pure implementation specific = issues. I don't agree that knowing whether a peer supports the mechanism is a = pure implementation issue. I think it's a security issue. I also don't = believe needing to know that certain agents may have damaged OLRs is a = pure implementation issue. (Both because we also have requirements to = work with and across non-supporting nodes.) > without configuration=E2=80=9D >=20 > I do not understand what do you refer to. >=20 > Could you explain that? The only way a node can tell that there's a non-supporting peer in the = path is to have an administrator tell it. Req 8: > [reports should be] Reporting nodes? Yes, that's correct. Req 10: > The consumer is able to determine when the overload condition = improves or ends, but when the next request comes. I agree about your = description of =E2=80=9Cstale=E2=80=9D overload info. > But then, compliance degree may be subject to interpretation. >=20 > I would say this is compliant. I listed a valid use case where the consumer cannot tell when the = overload condition changes, except to wait for the expiration of the = OLR. Thus, I still consider this "partially compliant". Req 12: > I think DOIC is compliant. >=20 > The solution MUST limit the impact of an overloaded node in the = network. >=20 > =20 >=20 > I do not think we need load conveyance support to be compliant to this = requirement. The point of the requirement is to avoid cascaded overload, where = overload at one node induces overload at others. The whole point in = requiring "load" in the first place was to help achieve this. I think = "partially compliant" is generous. Req 17: > But=E2=80=A6 we have mechanism to keep DOIC node throughput,included = anything related to this issue in the draft. I'm not sure where we disagree. Do you think that we _aren't_ compliant = on Req 17? Req 18: > See comment on 17 See response on 17 ;-) Req 20: (in response to the note) > I agree Thanks. Do others also agree? Req 23: > Partly Compliant >=20 > DOIC Overload information can be used already by proprietary = load-balancing implementations. >=20 > Load information will be a plus to this. The point of the requirement is to be make selections among _non_ = overloaded nodes in a way least likely to cause further problems. Thus, = I think the lack of "load" makes us non-compliant. (It's not like we = don't plan to do load) Req 28: (Recommendation for security review) > Is it independent for End-to-end sec draft? In my personal opinion, the end-to-end work is no where near far enough = along that we can depend on it in any way. Req 30: > Is it independent for End-to-end sec draft? >=20 > This may be misinterpreted as =E2=80=9Cdouble=E2=80=9D throttling in = some cases. I agree we need to be careful about that in the main text. Do you = disagree that we are compliant with the requirement? > =20 > =20 From nobody Tue Nov 11 18:12: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 7422D1A882E for ; Tue, 11 Nov 2014 18:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Sqgqnpkzt022 for ; Tue, 11 Nov 2014 18:12:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2353A1A88CA for ; Tue, 11 Nov 2014 18:12:49 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 5511119024D; Wed, 12 Nov 2014 03:12:47 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 28893158099; Wed, 12 Nov 2014 03:12: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.0210.002; Wed, 12 Nov 2014 03:12:39 +0100 From: To: MORAND Lionel IMT/OLN , "Wiehe, Ulrich (NSN - DE/Munich)" , Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zS149M3XUUPk28UQPOO8ZJK5xXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAIOgoA== Date: Wed, 12 Nov 2014 02:12:38 +0000 Message-ID: <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@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.6] 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.11.12.11820 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Mmxq57LcOaLL99Ly4F0Smh3OQyA Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 02:12:54 -0000 Please see below. Forgot to attached my comments :) Regards, Lionel ------ Thank you, Ulrich. Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: mardi 11 novembre 2014 13:47 =C0=A0: MORAND Lionel IMT/OLN; Maria C= ruz Bartolome; Steve Donovan; dime@ietf.org Objet=A0: RE: [Dime] Updates to= DOIC -05 Lionel, I am very sorry. Some of my comments are immediate reactions to MCruz's comments. I do not r= epeat those here (assuming that people who can read MCruz's comments can al= so read my reaction, while people who cannot will not be able to understand= my reaction anyway as it would be out of context). Please find other comments below. Ulrich Section 3, 4th paragraph from end, 2nd sentence: Existing text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or via other agents. Proposed text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or - if agent overload control is supported (Section A.2) - via = other agents. [LM] Not sure to understand the need for support of Agent overload for that= ... Section 3, last paragraph, 3rd sentence from end: Existing text: For example, one or more Diameter agents that do not support DOIC may exist= between a given pair of reporting and reacting nodes, as long as those age= nts pass unknown AVPs through unchanged. Proposed text: For example, one or more Diameter agents that do or do not s= upport DOIC may exist between a given pair of reporting and reacting nodes,= as long as those agents pass OC-specific AVPs or unknown AVPs through unch= anged. [LM] but actually, "OC-Specific AVPs" are unknown for a non-supporting agen= t. Section 3.2, 3rd paragraph last sentence: Existing text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= es in the path of the request.=20 Proposed text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= e in the path of the request. [LM] I may be too tired, but I cannot see the proposed change. Section 3.2, 2nd paragraph from end, 2nd sentence: Existing text: In this case, the agent updates the OC-Supported-Feature AVP= to reflect the mixture of the two sets of supported features. Proposed text: In this case, the agent can replace the OC-Supported-Feature= s AVP (which indicates the features supported by the downstream reacting no= de) with its own OC-Supported-Feature AVP (which indicates the features sup= ported by the agent). By doing so, the agent takes the role of a reporting = node (reporting towards the downstream reacting node) and at the same time = takes the role of a reacting node (reacting on OLRs received from upstream = reporting nodes).=20 [LM] will be discussed in a separate mail. Section 4.1.3, 1st paragraph, 1st sentence: Existing text: Diameter agents that support DOIC SHOULD ensure that all mes= sages have the OC-Supporting-Features AVP. Proposed text: Diameter agents that support DOIC SHOULD ensure that all req= uest messages have the OC-Supported-Features AVP. [LM] ok Section 4.1.3, 1st paragraph, 2nd sentence: Existing text: If a message handled by the DOIC agent does not include the = OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. Proposed text: If a request message handled by the DOIC agent does not incl= ude the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP= .=20 [LM] ok Section 4.1.3, 3rd paragraph, 1st sentence: Existing text: If the message already has the OC-Supported-Features AVP the= n the agent either leaves it unchanged in the relayed message or modifies i= t to reflect a mixed set of DOIC features. Proposed text: If the request message already has the OC-Supported-Features= AVP then the agent either leaves it unchanged in the relayed message or mo= difies it to reflect the agent's set of supported DOIC features. [LM] ok Section 4.1.3, 5th paragraph, 1st sentence: Existing text: An agent MAY modify the OC-Supported-Features AVP carried in= answer messages. Proposed text: An agent MAY replace the OC-Supported-Features AVP carried i= n answer messages (which indicates the features supported/selected by the u= pstream reporting node) with its own OC-Supported-Feature AVP (which indica= tes the features supported/selected by the agent). [LM] discussed in a separate mail. Section 4.2.3, 13th paragraph, 2nd sentence: Existing text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the OLR applies. Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the sent OLR applies. [LM] I would say that the reporting node will not remember the previously s= ent OLR, but will take care that there is an active OCS. Section 6.5, 1st paragraph, 5th sentence Existing text: Validity duration w= ith values above 86400 (i.e.; 24 hours) MUST NOT be used. Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours= ) MUST NOT be used.=20=20=20=20 -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Monday, November 10, 2014 5:49 PM To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org; Wiehe, Ulrich (NSN = - DE/Munich) Subject: Re: [Dime] Updates to DOIC -05 Hi Ulrich and Mar=EDa Cruz, Please stop commenting through attached documents, requested several times = and explained again yesterday by Ben. Some people may not be able to read a= t all the attached documents and it makes impossible parsing mechanism in t= he mailing list and in the archives. Please write your comments directly in the email. Thank you. lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Wiehe, Ulrich (NSN - DE/Munich) a =E9crit ---- Sreve, MCruz, all, please find more comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Sunday, November 09, 2014 2:17 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Steve, all, See some comments included in attached doc. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 03 de noviembre de 2014 15:36 To: dime@ietf.org Subject: [Dime] Updates to DOIC -05 All, I have done another end-to-end read of the DOIC specification, focusing on = wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. 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. 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 Wed Nov 12 05:00: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 361111A89A5 for ; Wed, 12 Nov 2014 05:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 MLK3kzH1WI2F for ; Wed, 12 Nov 2014 05:00:16 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0CF1A6FA8 for ; Wed, 12 Nov 2014 05:00:15 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sACD0CW6025439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Nov 2014 13:00:12 GMT 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 sACD0AZE012576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 14:00:10 +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.195.1; Wed, 12 Nov 2014 14:00:09 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.88]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 14:00:09 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "Maria Cruz Bartolome" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zS149M3XUUPk28UQPOO8ZJK5xXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAIOgoIAAsQaA Date: Wed, 12 Nov 2014 13:00:09 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> In-Reply-To: <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.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: 11194 X-purgate-ID: 151667::1415797212-0000437E-F249359E/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6OxgyjZWvikncHgxposJb29xVMI Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 13:00:20 -0000 Lionel, please see inline. Best regards Ulrich -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Wednesday, November 12, 2014 3:13 AM To: MORAND Lionel IMT/OLN; Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bart= olome; Steve Donovan; dime@ietf.org Subject: RE: [Dime] Updates to DOIC -05 Please see below. Forgot to attached my comments :) Regards, Lionel ------ Thank you, Ulrich. Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: mardi 11 novembre 2014 13:47 =C0=A0: MORAND Lionel IMT/OLN; Maria C= ruz Bartolome; Steve Donovan; dime@ietf.org Objet=A0: RE: [Dime] Updates to= DOIC -05 Lionel, I am very sorry. Some of my comments are immediate reactions to MCruz's comments. I do not r= epeat those here (assuming that people who can read MCruz's comments can al= so read my reaction, while people who cannot will not be able to understand= my reaction anyway as it would be out of context). Please find other comments below. Ulrich Section 3, 4th paragraph from end, 2nd sentence: Existing text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or via other agents. Proposed text: For example, a single Diameter node may be overloaded, in wh= ich case reacting nodes may reasonably attempt to send requests to other de= stinations or - if agent overload control is supported (Section A.2) - via = other agents. [LM] Not sure to understand the need for support of Agent overload for that= ... [Ulrich] In the absence of agent overload control it is always the server o= r realm that is overloaded and then it is not reasonable to attempt sending= requests via other agents to the same overloaded server or realm. Section 3, last paragraph, 3rd sentence from end: Existing text: For example, one or more Diameter agents that do not support DOIC may exist= between a given pair of reporting and reacting nodes, as long as those age= nts pass unknown AVPs through unchanged. Proposed text: For example, one or more Diameter agents that do or do not s= upport DOIC may exist between a given pair of reporting and reacting nodes,= as long as those agents pass OC-specific AVPs or unknown AVPs through unch= anged. [LM] but actually, "OC-Specific AVPs" are unknown for a non-supporting agen= t. [Ulrich] yes, but the exist text does not cover the case where a DOIC suppo= rting agent exists between a given pair of reporting and reacting nodes, wh= ich passes OC-specific AVPs (although not unknown) through unchanged. Section 3.2, 3rd paragraph last sentence: Existing text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= es in the path of the request.=20 Proposed text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= e in the path of the request. [LM] I may be too tired, but I cannot see the proposed change. [Ulrich] That's why I like revision marking in word documents. Try again. Section 3.2, 2nd paragraph from end, 2nd sentence: Existing text: In this case, the agent updates the OC-Supported-Feature AVP= to reflect the mixture of the two sets of supported features. Proposed text: In this case, the agent can replace the OC-Supported-Feature= s AVP (which indicates the features supported by the downstream reacting no= de) with its own OC-Supported-Feature AVP (which indicates the features sup= ported by the agent). By doing so, the agent takes the role of a reporting = node (reporting towards the downstream reacting node) and at the same time = takes the role of a reacting node (reacting on OLRs received from upstream = reporting nodes).=20 [LM] will be discussed in a separate mail. Section 4.1.3, 1st paragraph, 1st sentence: Existing text: Diameter agents that support DOIC SHOULD ensure that all mes= sages have the OC-Supporting-Features AVP. Proposed text: Diameter agents that support DOIC SHOULD ensure that all req= uest messages have the OC-Supported-Features AVP. [LM] ok Section 4.1.3, 1st paragraph, 2nd sentence: Existing text: If a message handled by the DOIC agent does not include the = OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. Proposed text: If a request message handled by the DOIC agent does not incl= ude the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP= .=20 [LM] ok Section 4.1.3, 3rd paragraph, 1st sentence: Existing text: If the message already has the OC-Supported-Features AVP the= n the agent either leaves it unchanged in the relayed message or modifies i= t to reflect a mixed set of DOIC features. Proposed text: If the request message already has the OC-Supported-Features= AVP then the agent either leaves it unchanged in the relayed message or mo= difies it to reflect the agent's set of supported DOIC features. [LM] ok Section 4.1.3, 5th paragraph, 1st sentence: Existing text: An agent MAY modify the OC-Supported-Features AVP carried in= answer messages. Proposed text: An agent MAY replace the OC-Supported-Features AVP carried i= n answer messages (which indicates the features supported/selected by the u= pstream reporting node) with its own OC-Supported-Feature AVP (which indica= tes the features supported/selected by the agent). [LM] discussed in a separate mail. Section 4.2.3, 13th paragraph, 2nd sentence: Existing text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the OLR applies. Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to= the set of messages to which the sent OLR applies. [LM] I would say that the reporting node will not remember the previously s= ent OLR, but will take care that there is an active OCS. Section 6.5, 1st paragraph, 5th sentence Existing text: Validity duration w= ith values above 86400 (i.e.; 24 hours) MUST NOT be used. Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours= ) MUST NOT be used. =20 -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Monday, November 10, 2014 5:49 PM To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org; Wiehe, Ulrich (NSN = - DE/Munich) Subject: Re: [Dime] Updates to DOIC -05 Hi Ulrich and Mar=EDa Cruz, Please stop commenting through attached documents, requested several times = and explained again yesterday by Ben. Some people may not be able to read a= t all the attached documents and it makes impossible parsing mechanism in t= he mailing list and in the archives. Please write your comments directly in the email. Thank you. lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Wiehe, Ulrich (NSN - DE/Munich) a =E9crit ---- Sreve, MCruz, all, please find more comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Sunday, November 09, 2014 2:17 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Steve, all, See some comments included in attached doc. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 03 de noviembre de 2014 15:36 To: dime@ietf.org Subject: [Dime] Updates to DOIC -05 All, I have done another end-to-end read of the DOIC specification, focusing on = wording, consistency and removing any remaining redundancy in the document. I have pushed the changes into github. I have attached the diff to this email. 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. 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 Wed Nov 12 06:31: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 F2AA01A901F for ; Wed, 12 Nov 2014 06:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 M2N7g6I6Gov3 for ; Wed, 12 Nov 2014 06:31:55 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238BF1A8A4C for ; Wed, 12 Nov 2014 06:31:54 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sACEVqCh017741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Nov 2014 14:31:52 GMT 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 sACEVqOB010629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 15:31:52 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.88]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 15:31:51 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zS149M3XUUPk28UQPOO8ZJK5xXdZWAgAQNuICAAB4OgIABZh7Q Date: Wed, 12 Nov 2014 14:31:51 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815228EA8@DEMUMBX014.nsn-intra.net> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> <54622707.3040308@usdonovans.com> <087A34937E64E74E848732CFF8354B92098580CC@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92098580CC@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.104] 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: 9893 X-purgate-ID: 151667::1415802712-00001FC1-A1A2F25E/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/u9Z_r96IP8TtG96oniF5BLWU3ZE Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 14:31:59 -0000 Maria Cruz, please see below. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, November 11, 2014 5:59 PM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Steve, all, See below the comments that may require some group discussion: Ch 2: Now: Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Proposal: Diversion Abatement of traffic sent to a reporting node performed by a reacting= n. The abatement is achieved by diverting (?) traffic from the reporting node to a less o= verloaded Diameter node that is able to process the request, based on received = overload report(s). ?: any better word to avoid using "diverting" when we are defining "diversi= on"? Ch 2: Now: Overload Report (OLR) Information sent by a reporting node indicating the start, continuation or end of an occurrence of overload control. Proposed: Overload Report (OLR) Information sent by a reporting node about its overload situation. [Ulrich] I better like the old text as it covers also cases where an agent = reports realm-overload. Ch2 Now Reacting Node A Diameter node that receives and acts upon an overload report. Proposed: Reacting Node A Diameter node that acts upon an overload report. [Ulrich] What is wrong with the existing text? Ch2: Now Throttling Abatement of traffic sent to a reporting node by dropping or rejecting Diameter requests. Throttling can include a Diameter Client or Diameter Server dropping requests, or a Diameter Agent rejecting requests with appropriate error responses. In extreme cases reporting nodes can also throttle requests when the requested reductions in traffic does not sufficiently address the overload scenario. Proposed: Throttling Abatement of traffic by dropping or rejecting Diameter requests. Throttling can include a Diameter Client or Diameter Server dropping requests, or a Diameter Agent rejecting requests with appropriate error responses (?). In extreme cases reporting nodes can also throttle (or drop) requests when the requested reductions in traffic does not sufficiently address the overload scenario. ?: Question: do we consider an agent is not allowed to DROP a request? [Ulrich] yes Ch3 Now: A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes . Proposed: A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to a reacting node. [Ulrich] What is wrong with the existing text? Ch3. Question: A reacting node acts upon OLRs, and performs whatever actions are needed to fulfil the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream ??) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream?? ) nodes. "Typically"? is any other possibility? Ch3: modification and question Now: A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Relay and Proxy Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, a given Diameter nodes can simultaneously act as a reporting node and a reacting node Proposed: A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Relay (?) and Proxy Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, those Diameter nodes can simultaneously act as a reporting node and a reacting node. Can a Relay be a DOIC node? Since by definition is application-less? If DOI= C-enabled, can it be considered a "relay" any longer? We had this discussion before, but not sure whether we reached a conclusion= . Ch3 Now: Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. Proposed: Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm may defines the meaning of some of the parameters of an OLR and the procedures required for overloa= d abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. [Ulrich] What is wrong with the existing text? 4.2.1.2. Overload Control State for Reporting Nodes Now: A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the pair of Application-Id and Abatement Algorithm. The OCS entry for a given pair of Application and Abatement Algorithm MAY include the information (the actual information stored is an implementation decision): o Report type o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) Proposed: A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the pair of Application-Id,=20 Abatement Algorithm and Report Type and MAY include the following inform= ation (the actual information stored is an implementation decision): o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) [Ulrich] ok, but then it is no longer a pair but a triplet 4.2.1.4 =20 Question on following paragraph: If the reporting node knows that the OCS entries in the reacting nodes are near expiration then the reporting node can decide to delete the OCS entry. This paragraph is unclear to me. "knows that the OCS entries in the reacting"? "decide to delete the OCS entry"? Could you clarify what was the intention? 5.3 Now: It is suggested that the reacting node decrease the amount of traffic given abatement treatment by 20% each second until the reduction is completely removed and no traffic is given abatement treatment. Proposed: It is suggested that the reacting node decrease progressively the amount= of traffic given abatement treatment until the reduction is completely removed and no traffic is given abatement treatment. Justification: Not sure we have discussed the reasoning for this value. And it may not be applicable to all overload occurrences and traffic rates. 6.8 Remove: Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. And refer 6733 RFC. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: martes, 11 de noviembre de 2014 16:11 To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 Maria Cruz, Would it be possible for you to break out the comments that you think need = group discussion, especially those that Ulrich commented on in the word doc= ument he sent? Then we can work through the list of issues known issues in the issue track= er and in editor notes in the document plus new issues sent by you, Ulrich,= Jouni and Ben. Thanks, Steve On 11/8/14, 3:16 PM, Maria Cruz Bartolome wrote: > Steve, all, > > See some comments included in attached doc. > Best regards > /MCruz > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: lunes, 03 de noviembre de 2014 15:36 > To: dime@ietf.org > Subject: [Dime] Updates to DOIC -05 > > All, > > I have done another end-to-end read of the DOIC specification, focusing o= n wording, consistency and removing any remaining redundancy in the documen= t. > > I have pushed the changes into github. > > I have attached the diff to this email. > > Regards, > > Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Nov 12 06:47: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 C97221A0103 for ; Wed, 12 Nov 2014 06:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX1e4SRjmYd4 for ; Wed, 12 Nov 2014 06:47:23 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7C91A008F for ; Wed, 12 Nov 2014 06:47:23 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 09:47:21 -0500 From: Dave Dolson To: "dime@ietf.org" Thread-Topic: inconsistency in draft-ietf-dime-ovli-05.txt Thread-Index: Ac/+h5JM21e3ky2fSZeUD+LO5B4kNA== Date: Wed, 12 Nov 2014 14:47:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830ADB896wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VgD6pJ0we3nSJh24PXAj5wDDT9Y Subject: [Dime] inconsistency in draft-ietf-dime-ovli-05.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, 12 Nov 2014 14:47:26 -0000 --_000_E8355113905631478EFF04F5AA706E9830ADB896wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reading the recent revision, https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-di= me-ovli-05.txt Note that 86400ms is only about 86s, not 24h. (I suspect the 86400 number l= ingers from when this duration was defined in seconds?) Having noted that, I think 86s is a much more reasonable upper limit than 2= 4h. Let's say a node is told to reduce by 100%, with a timeout of 24h, and the = system goes idle. A team of support engineers goes into investigation mode,= cannot find the problem, and 24h later the problem mysteriously fixes itse= lf... unless the box is rebooted first. 6.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is of type Unsigned32 and indicates in milliseconds the validity time of the overload report. The number of milliseconds is measured after reception of the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. The default value for the OC-Validity-Duration AVP is 5000 (i.e.; 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration values are treated as if the OC-Validity-Duration AVP were not present and result in the default value being used. David Dolson Senior Software Architect Sandvine --_000_E8355113905631478EFF04F5AA706E9830ADB896wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reading the recent revision,

https://github.com/jounikor/draft-docdt-dime-ovli/bl= ob/master/draft-ietf-dime-ovli-05.txt

 

Note that 86400ms is only about 86s, not 24h. (I sus= pect the 86400 number lingers from when this duration was defined in second= s?)

 

Having noted that, I think 86s is a much more reason= able upper limit than 24h.

Let’s say a node is told to reduce by 100%, wi= th a timeout of 24h, and the system goes idle. A team of support engineers = goes into investigation mode, cannot find the problem, and 24h later the pr= oblem mysteriously fixes itself… unless the box is rebooted first.

 

6.5. OC-Validity-Duration AVP

The OC-Validity-Duration AVP (AVP code TBD4) is of type Un= signed32

and indicates in milliseconds = the validity time of the overload

report. The number of milliseconds is measured after recep= tion of

the first OC-OLR AVP with a given value of OC-Sequence-Num= ber AVP.

The default value for the OC-Validity-Duration AVP is 5000= (i.e.; 5

seconds). When the OC-Validity-Duration AVP is not present= in the

OC-OLR AVP, the default value applies. Validity duration w= ith values

above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid dur= ation

values are treated as if the OC-Validity-Duration AVP were= not

present and result in the default value being used.

 

 

David Dolson

Senior Software Architect

Sandvine

 

--_000_E8355113905631478EFF04F5AA706E9830ADB896wtlexchp2sandvi_-- From nobody Wed Nov 12 10:32: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 3F9B41ACD58 for ; Wed, 12 Nov 2014 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-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 Z4WzIgqYodRD for ; Wed, 12 Nov 2014 10:32:41 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC481A0171 for ; Wed, 12 Nov 2014 10:32:31 -0800 (PST) Received: from dhcp-a69d.meeting.ietf.org ([31.133.166.157]:53035) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XociS-0002pT-Kn; Wed, 12 Nov 2014 10:32:29 -0800 Message-ID: <5463A7BB.9020804@usdonovans.com> Date: Wed, 12 Nov 2014 08:32:27 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , Maria Cruz Bartolome , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KhVM4WURpBouyTlZPdfIlGcqshk Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:32:42 -0000 The suggestion is from "reacting nodes" to "reacting node". I disagree with this change, as there can be more than one reacting node for a single report. I would agree to change it to "reacting node(s)". Steve Section 3.2, 3rd paragraph last sentence: Existing text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. Proposed text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting node in the path of the request. [LM] I may be too tired, but I cannot see the proposed change. [Ulrich] That's why I like revision marking in word documents. Try again. From nobody Wed Nov 12 11:06: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 B29521ACEF8 for ; Wed, 12 Nov 2014 11:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_24=0.6, 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 CI_E8QaAHyRi for ; Wed, 12 Nov 2014 11:05:38 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FCF1ACEE2 for ; Wed, 12 Nov 2014 11:05:19 -0800 (PST) Received: from dhcp-a69d.meeting.ietf.org ([31.133.166.157]:53336) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XodE8-0002ay-Ak for dime@ietf.org; Wed, 12 Nov 2014 11:05:18 -0800 Message-ID: <5463AF67.5010009@usdonovans.com> Date: Wed, 12 Nov 2014 09:05:11 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------030901000904020405040502" 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/TMlX5MZ22zQAxmM2e30gLEHo9RQ Subject: [Dime] -05 of DOIC specification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 19:05:56 -0000 This is a multi-part message in MIME format. --------------030901000904020405040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, Here's the txt version of DOIC -05 for use in review. Regards, Steve --------------030901000904020405040502 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-dime-ovli-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-dime-ovli-05.txt" Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Internet-Draft Broadcom Intended status: Standards Track S. Donovan, Ed. Expires: May 7, 2015 B. Campbell Oracle L. Morand Orange Labs November 3, 2014 Diameter Overload Indication Conveyance draft-ietf-dime-ovli-05.txt Abstract This specification defines a base solution for Diameter Overload Control (DOC), referred to as Diameter Overload Indication Conveyance (DOIC). Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 7, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Korhonen, et al. Expires May 7, 2015 [Page 1] Internet-Draft DOIC November 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 14 4.2.1. Overload Control State . . . . . . . . . . . . . . . 14 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 18 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 18 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 20 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 Korhonen, et al. Expires May 7, 2015 [Page 2] Internet-Draft DOIC November 2014 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Issues left for future specifications . . . . . . . 33 A.1. Additional traffic abatement algorithms . . . . . . . . . 33 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33 A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 33 Appendix B. Deployment Considerations . . . . . . . . . . . . . 34 Appendix C. Requirements Conformance Analysis . . . . . . . . . 34 Appendix D. Considerations for Applications Integrating the DOIC Solution . . . . . . . . . . . . . . . . . . . . . . 34 D.1. Application Classification . . . . . . . . . . . . . . . 34 D.2. Application Type Overload Implications . . . . . . . . . 35 D.3. Request Transaction Classification . . . . . . . . . . . 36 D.4. Request Type Overload Implications . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction This specification defines a base solution for Diameter Overload Control (DOC), referred to as Diameter Overload Indication Conveyance (DOIC). The requirements for the solution are described and discussed in the corresponding design requirements document [RFC7068]. Note that the overload control solution defined in this specification does not address all the requirements listed in [RFC7068]. A number of overload control related features are left for future specifications. See Appendix A for a list of extensions that are currently being considered. See Appendix C for an analysis of conformance to the requirements specified in [RFC7068]. The solution defined in this specification addresses Diameter overload control between Diameter nodes that support the DOIC solution. The solution, which is designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. 2. Terminology and Abbreviations Abatement Korhonen, et al. Expires May 7, 2015 [Page 3] Internet-Draft DOIC November 2014 Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling. Abatement Algorithm An mechanism requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Host-Routed Request The set of requests that a reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. Overload Control State (OCS) Reporting and reacting node internally maintained state describing occurrences of overload control. Overload Report (OLR) Information sent by a reporting node indicating the start, continuation or end of an occurrence of overload control. Reacting Node A Diameter node that acts upon an overload report. Realm-Routed Request The set of requests that a reacting node does not know the host that will service the request. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Korhonen, et al. Expires May 7, 2015 [Page 4] Internet-Draft DOIC November 2014 Throttling Abatement of traffic sent to a reporting node by dropping or rejecting Diameter requests. Throttling can include a Diameter Client or Diameter Server dropping requests, or a Diameter Agent rejecting requests with appropriate error responses. In extreme cases reporting nodes can also throttle requests when the requested reductions in traffic does not sufficiently address the overload scenario. 3. Solution Overview The Diameter Overload Information Conveyance (DOIC) solution allows Diameter nodes to request other Diameter nodes to perform overload abatement actions, that is, actions to reduce the load offered to the overloaded node or realm. A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes. A reacting node acts upon OLRs, and performs whatever actions are needed to fulfil the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream) nodes. A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Relay and Proxy Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, a given Diameter node can simultaneously act as a reporting node and a reacting node. Likewise, a relay or proxy agent may act as a reacting node from the perspective of upstream nodes, and a reporting node from the perspective of downstream nodes. DOIC nodes do not generate new messages to carry DOIC related information. Rather, they "piggyback" DOIC information over existing Diameter messages by inserting new AVPs into existing Diameter requests and responses. Nodes indicate support for DOIC, and any needed DOIC parameters by inserting an OC_Supported_Features AVP Korhonen, et al. Expires May 7, 2015 [Page 5] Internet-Draft DOIC November 2014 (Section 6.2) into existing requests and responses. Reporting nodes send OLRs by inserting OC-OLR AVPs (Section 6.3). A given OLR applies to the Diameter realm and application of the Diameter message that carries it. If a reporting node supports more than one realm and/or application, it reports independently for each combination of realm and application. Similarly, the OC-Supported- Features AVP applies to the realm and application of the enclosing message. This implies that a node may support DOIC for one application and/or realm, but not another, and may indicate different DOIC parameters for each application and realm for which it supports DOIC. Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. Overload conditions may vary in scope. For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send requests to other destinations or via other agents. On the other hand, an entire Diameter realm may be overloaded, in which case such attempts would do harm. DOIC OLRs have a concept of "report type" (Section 6.6), where the type defines such behaviors. Report types are extensible. This document defines report types for overload of a specific server, and for overload of an entire realm. A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of requests that are not host-routed as defined in the previous paragraph. Korhonen, et al. Expires May 7, 2015 [Page 6] Internet-Draft DOIC November 2014 While a reporting node sends OLRs to "adjacent" reacting nodes, nodes that are "adjacent" for DOIC purposes may not be adjacent from a Diameter, or transport, perspective. For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unchanged. The report types described in this document can safely pass through non-supporting agents. This may not be true for report types defined in future specifications. 3.1. Piggybacking Principle The overload control AVPs defined in this specification have been designed to be piggybacked on top of existing application messages. This is made possible by adding overload control AVPs, the OC-OLR AVP and the OC-Supported-Features AVP, as optional AVPs into existing commands when the corresponding Command Code Format (CCF) specification allows adding new optional AVPs (see Section 1.3.4 of [RFC6733]). There is no new Diameter application defined to carry overload related AVPs. The DOIC AVPs are carried in existing Diameter application messages. Reacting nodes indicate support for DOIC by including the OC- Supported-Features AVP in all request messages originated or relayed by the reacting node. Reporting nodes indicate support for DOIC by including the OC- Supported-Features AVP in all answer messages originated or relayed by the reporting node that are in response to a request that contained the OC-Supported-Features AVP. Reporting nodes also include overload reports using the OC-OLR AVP in answer messages. Note that the overload control solution does not have fixed server and client roles. The DOIC node role is determined based on the message type: whether the message is a request (i.e. sent by a "reacting node") or an answer (i.e. send by a "reporting node"). Therefore, in a typical "client-server" deployment, the Diameter Client MAY report its overload condition to the Diameter Server for any Diameter Server initiated message exchange. An example of such is the Diameter Server requesting a re-authentication from a Diameter Client. 3.2. DOIC Capability Announcement The DOIC solution supports the ability for Diameter nodes to determine if other nodes in the path of a request support the Korhonen, et al. Expires May 7, 2015 [Page 7] Internet-Draft DOIC November 2014 solution. This capability is referred to as DOIC Capability Announcement (DCA) and is separate from Diameter Capability Exchange. The DCA solution uses the OC-Supported-Features AVPs to indicate the Diameter overload features supported. The first node in the path of a Diameter request that supports the DOIC solution inserts the OC-Supported-Feature AVP in the request message. This includes an indication that it supports the loss overload abatement algorithm defined in this specification (see Section 5). This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. DOIC must support deployments where Diameter Clients and/or Diameter Servers do not support the DOIC solution. In this scenario, it is assumed that Diameter Agents that support the DOIC solution will handle overload abatement for the non supporting Diameter nodes. In this case the DOIC agent will insert the OC- Supporting-Features AVP in requests that do not already contain one, telling the reporting node that there is a DOIC node that will handle overload abatement. The reporting node inserts the OC-Supported-Feature AVP in all answer messages to requests that contained the OC-Supported-Feature AVP. The contents of the reporting node's OC-Supported-Feature AVP indicate the set of Diameter overload features supported by the reporting node with one exception. The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested. Note that the loss algorithm defined in this document is a stateless abatement algorithm. As a result it does not require any actions by reacting nodes prior to the receipt of an overload report. Stateful abatement algorithms that base the abatement logic on a history of request messages sent might require reacting nodes to maintain state in advance of receiving an overload report to ensure that the overload reports can be properly handled. The individual features supported by the DOIC nodes are indicated in the OC-Feature-Vector AVP. Any semantics associated with the Korhonen, et al. Expires May 7, 2015 [Page 8] Internet-Draft DOIC November 2014 features will be defined in extension specifications that introduce the features. The DCA mechanism must also support the scenario where the set of features supported by the sender of a request and by agents in the path of a request differ. In this case, the agent updates the OC- Supported-Feature AVP to reflect the mixture of the two sets of supported features. The logic to determine the content of the modified OC-Supported- Feature AVP is out-of-scope for this specification and is left to implementation decisions. Care must be taken not to introduce interoperability issues for downstream or upstream DOIC nodes. 3.3. DOIC Overload Condition Reporting As with DOIC Capability Announcement, Overload Condition Reporting uses new AVPs (Section 6.3) to indicate an overload condition. The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs. Two types of overload reports are defined in this document, host reports and realm reports. A report of type host is sent to indicate the overload of a specific Diameter node for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. Realm reports apply to realm-routed requests for a specific realm as indicated in the Destination-Realm AVP. Reporting nodes are responsible for determining the need for a reduction of traffic. The method for making this determination is implementation specific and depend on the type of overload report being generated. A host report, for instance, will generally be generated by tracking utilization of resources required by the host to handle transactions for the Diameter application. A realm report will generally impact the traffic sent to multiple hosts and, as such, will typically require tracking the capacity of the servers able to handle realm-routed requests for the application. Korhonen, et al. Expires May 7, 2015 [Page 9] Internet-Draft DOIC November 2014 Once a reporting node determines the need for a reduction in traffic, it uses the DOIC defined AVPs to report on the condition. These AVPs are included in answer messages sent or relayed by the reporting node. The reporting node indicates the overload abatement algorithm that is to be used to handle the traffic reduction in the OC- Supported-Features AVP. The OC-OLR AVP is used to communicate information about the requested reduction. Reacting nodes, upon receipt of an overload report, are responsible for applying the abatement algorithm to traffic impacted by the overload report. The method used for that abatement is dependent on the abatement algorithm. The loss abatement algorithm is defined in this document (Section 5). Other abatement algorithms can be defined in extensions to the DOIC solutions. As the conditions that lead to the generation of the overload report change the reporting node can send new overload reports requesting greater reduction if the condition gets worse or less reduction if the condition improves. The reporting node sends an overload report with a duration of zero to indicate that the overload condition has ended and use of the abatement algorithm is no longer needed. The reacting node also determines when the overload report expires based on the OC-Validity-Duration AVP in the overload report and stops applying the abatement algorithm when the report expires. 3.4. DOIC Extensibility The DOIC solution is designed to be extensible. This extensibility is based on existing Diameter based extensibility mechanisms. There are multiple categories of extensions that are expected. This includes the definition of new overload abatement algorithms, the definition of new report types and the definition of new scopes of messages impacted by an overload report. The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes to communicate supported features. The specific features supported by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC extensions must define new values for the OC-Feature-Vector AVP. DOIC extensions also have the ability to add new AVPs to the OC- Supported-Features AVP, if additional information about the new feature is required. Reporting nodes use the OC-OLR AVP to communicate overload occurrences. This AVP can also be extended to add new AVPs allowing a reporting nodes to communicate additional information about handling an overload condition. Korhonen, et al. Expires May 7, 2015 [Page 10] Internet-Draft DOIC November 2014 If necessary, new extensions can also define new AVPs. It is, however, recommended that DOIC extensions use the OC-Supported- Features AVP and OC-OLR AVP to carry all DOIC related AVPs. 3.5. Simplified Example Architecture Figure 1 illustrates the simplified architecture for Diameter overload information conveyance. Realm X Same or other Realms <--------------------------------------> <----------------------> +--^-----+ : (optional) : |Diameter| : : |Server A|--+ .--. : +---^----+ : .--. +--------+ | _( `. : |Diameter| : _( `. +---^----+ +--( )--:-| Agent |-:--( )--|Diameter| +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Server B| : : +---^----+ : : End-to-end Overload Indication 1) <-----------------------------------------------> Diameter Application Y Overload Indication A Overload Indication A' 2) <----------------------> <----------------------> Diameter Application Y Diameter Application Y Figure 1: Simplified architecture choices for overload indication delivery In Figure 1, the Diameter overload indication can be conveyed (1) end-to-end between servers and clients or (2) between servers and Diameter agent inside the realm and then between the Diameter agent and the clients. 4. Solution Procedures This section outlines the normative behavior associated with the DOIC solution. Korhonen, et al. Expires May 7, 2015 [Page 11] Internet-Draft DOIC November 2014 4.1. Capability Announcement This section defines DOIC Capability Announcement (DCA) behavior. 4.1.1. Reacting Node Behavior A reacting node MUST include the OC-Supported-Features AVP in all request messages. A reacting node MAY include the OC-Feature-Vector AVP with an indication of the loss algorithm. If a reacting node includes the OC-Feature-Vector AVP then it MUST indicate support for the loss algorithm. A reacting node MUST include the OC-Feature-Vector AVP to indicate support for abatement algorithms in addition to the loss algorithm. A reacting node SHOULD indicate support for all other DOIC features it supports. Not all DOIC features will necessarily apply to all transactions. For instance, there may be a future extension that only applies to session based applications. A reacting node that supports this extension can choose to not include it for non session based applications. An OC-Supported-Features AVP in answer messages indicates there is a reporting node for the transaction. The reacting node MAY take action based on the features indicated in the OC-Feature-Vector AVP. Note that the loss abatement algorithm is the only feature described in this document and it does not require action to be taken when there is no active overload report. This behavior is described in Section 4.2 and Section 5. 4.1.2. Reporting Node Behavior Upon receipt of a request message, a reporting node determines if there is a reacting node for the transaction based on the presence of the OC-Supported-Features AVP. If the request message contains an OC-Supported-Features AVP then the reporting node MUST include the OC-Supported-Features AVP in the answer message for that transaction. The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR AVP or any other overload control AVPs defined in extension drafts in response messages for transactions where the request Korhonen, et al. Expires May 7, 2015 [Page 12] Internet-Draft DOIC November 2014 message does not include the OC-Supported-Features AVP. Lack of the OC-Supported-Features AVP in the request message indicates that there is no reacting node for the transaction. Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates. The reporting node MUST indicate support for one and only one abatement algorithm in the OC-Feature-Vector AVP. The abatement algorithm included MUST be from the set of abatement algorithms contained in the request message's OC-Supported-Features AVP. The abatement algorithm included MUST indicate the abatement algorithm the reporting node wants the reacting node to use when the reporting node enters an overload condition. For an ongoing overload state, a reacting node MUST keep the algorithm that was selected by the reporting node in further requests towards the reporting node. The reporting node SHOULD NOT change the selected algorithm during a period of time that it is in an overload condition and, as a result, is sending OC-OLR AVPs in answer messages. The reporting node SHOULD indicate support for other DOIC features defined in extension drafts that it supports and that apply to the transaction. Note that not all DOIC features will apply to all Diameter applications or deployment scenarios. The features included in the OC-Feature-Vector AVP are based on local reporting node policy. 4.1.3. Agent Behavior Diameter agents that support DOIC SHOULD ensure that all messages have the OC-Supporting-Features AVP. If a message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. Editor's note: There might be local policy reasons why the agent would not include the OC-Supported-Features AVP in request messages that do not already carry the AVP. If the message already has the OC-Supported-Features AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect a mixed set of DOIC features. Korhonen, et al. Expires May 7, 2015 [Page 13] Internet-Draft DOIC November 2014 Editor's note: There is an open issue on the wording around agent behavior in this case that needs to be resolved prior to finishing this document. An agent MAY modify the OC-Supported-Features AVP carried in answer messages. For instance, if the agent supports a superset of the features reported by the reacting node then the agent might choose, based on local policy, to advertise that superset of features to the reporting node. If the agent modifies the OC-Supported-Features AVP sent to the reporting node then it might also need to modify the OC-Supported- Features AVP sent to a reacting node in the subsequent answer message, as it cannot send an indication of support for features that are not supported by the reacting node. 4.2. Overload Report Processing 4.2.1. Overload Control State Both reacting and reporting nodes maintain Overload Control State (OCS) for active overload conditions. 4.2.1.1. Overload Control State for Reacting Nodes A reacting node SHOULD maintain the following OCS per supported Diameter application: o A host-type OCS entry for each Destination-Host to which it sends host-type requests and o A realm-type OCS entry for each Destination-Realm to which it sends realm-type requests. A host-type OCS entry is identified by the pair of Application-Id and Host-Id. A realm-type OCS entry is identified by the pair of Application-Id and Realm-Id. The host-type and realm-type OCS entries MAY include the following information (the actual information stored is an implementation decision): o Sequence number (as received in OC-OLR) Korhonen, et al. Expires May 7, 2015 [Page 14] Internet-Draft DOIC November 2014 o Time of expiry (derived from OC-Validity-Duration AVP received in the OC-OLR AVP and time of reception of the message carrying OC- OLR AVP) o Selected Abatement Algorithm (as received in the OC-Supported- Features AVP) o Abatement Algorithm specific input data (as received in the OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss abatement algorithm) 4.2.1.2. Overload Control State for Reporting Nodes A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the pair of Application-Id and Abatement Algorithm. The OCS entry for a given pair of Application and Abatement Algorithm MAY include the information (the actual information stored is an implementation decision): o Report type o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) 4.2.1.3. Reacting Node Maintenance of Overload Control State When a reacting node receives an OC-OLR AVP, it MUST determine if it is for an existing or new overload condition. For the remainder of this section the term OLR referres to the combination of the contents of the received OC-OLR AVP and the abatement algorithm indicated in the received OC-Supported- Features AVP. The OLR is for an existing overload condition if the reacting node has an OCS that matches the received OLR. Korhonen, et al. Expires May 7, 2015 [Page 15] Internet-Draft DOIC November 2014 For a host report-type this means it matches the app-id and host-id in an existing host OCS entry. For a realm report-type this means it matches the app-id and realm-id in an existing realm OCS entry. If the OLR is for an existing overload condition then it MUST determine if the OLR is a retransmission or an update to the existing OLR. If the sequence number for the received OLR is greater than the sequence number stored in the matching OCS entry then the reacting node MUST update the matching OCS entry. If the sequence number for the received OLR is less than or equal to the sequence number in the matching OCS entry then the reacting node MUST silently ignore the received OLR. The matching OCS MUST NOT be updated in this case. If the received OLR is for a new overload condition then the reacting node MUST generate a new OCS entry for the overload condition. For a host report-type this means it creates on OCS entry with the app-id of the application-id in the received message and host-id of the Origin-Host in the received message. Note: This solution assumes that the Origin-Host AVP in the answer message included by the reporting node is not changed along the path to the reacting node. For a realm report-type this means it creates on OCS entry with the app-id of the application-id in the received message and realm-id of the Origin-Realm in the received message. If the received OLR contains a validity duration of zero ("0") then the reacting node MUST update the OCS entry as being expired. Note that it is not necessarily appropriate to delete the OCS entry, as there is recommended behavior that the reacting node slowly returns to full traffic when ending an overload abatement period. The reacting node does not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). Korhonen, et al. Expires May 7, 2015 [Page 16] Internet-Draft DOIC November 2014 4.2.1.4. Reporting Node Maintenance of Overload Control State A reporting node SHOULD create a new OCS entry when entering an overload condition. If the reporting node knows through absence of the OC-Supported- Features AVP in received messages that there are no reacting nodes supporting DOIC then the reporting node can choose to not create OCS entries. When generating a new OCS entry the sequence number MAY be set to any value if there is no unexpired overload report for previous overload conditions sent to any reacting node for the same application and report-type. When generating sequence numbers for new overload conditions, the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. The reporting node MUST update an OCS entry when it needs to adjust the validity duration of the overload condition at reacting nodes. For instance, if the reporting node wishes to instruct reacting nodes to continue overload abatement for a longer period of time that originally communicated. This also applies if the reporting node wishes to shorten the period of time that overload abatement is to continue. A reporting node MUST NOT update the abatement algorithm in an active OCS entry. A reporting node MUST update an OCS entry when it wishes to adjust any abatement algorithm specific parameters, including the reduction percentage used for the Loss abatement algorithm. For instance, if the reporting node wishes to change the reduction percentage either higher, if the overload condition has worsened, or lower, if the overload condition has improved, then the reporting node would update the appropriate OCS entry. The reporting node MUST update the sequence number associated with the OCS entry anytime the contents of the OCS entry are changed. This will result in a new sequence number being sent to reacting nodes, instructing the reacting nodes to process the OC-OLR AVP. A reporting node SHOULD update an OCS entry with a validity duration of zero ("0") when the overload condition ends. Korhonen, et al. Expires May 7, 2015 [Page 17] Internet-Draft DOIC November 2014 If the reporting node knows that the OCS entries in the reacting nodes are near expiration then the reporting node can decide to delete the OCS entry. The reporting node MUST keep an OCS entry with a validity duration of zero ("0") for a period of time long enough to ensure that any non- expired reacting node's OCS entry created as a result of the overload condition in the reporting node is deleted. 4.2.2. Reacting Node Behavior When a reacting node sends a request it MUST determine if that request matches an active OCS. If the request matches and active OCS then the reacting node MUST apply abatement treatment on the request. The abatement treatment applied depends on the abatement algorithm stored in the OCS. For the Loss abatement algorithm defined in this specification, see Section 5 for the abatement logic applied. If the abatement treatment results in throttling of the request and if the reacting node is an agent then the agent MUST send an appropriate error as defined in section Section 7. In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that it the reporting node has explicitly signaled the end of the overload condition then abatement associated with the overload abatement MUST be ended in a controlled fashion. 4.2.3. Reporting Node Behavior The operation on the reporting node is straight forward. If there is an active OCS entry then the reporting node SHOULD include the OC-OLR AVP in all answer messages to requests that contain the OC-Supported-Features AVP and that match the active OCS entry. A request matches if the application-id in the request matches the application-id in any active OCS entry and if the report-type in the OCS entry matches a report-type supported by the reporting node as indicated in the OC-Supported-Features AVP. The contents of the OC-OLR AVP MUST contain all information necessary for the abatement algorithm indicated in the OC-Supported-Features AVP that is also included in the answer message. Korhonen, et al. Expires May 7, 2015 [Page 18] Internet-Draft DOIC November 2014 A reporting node MAY choose to not resend an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node. Note - In some cases (e.g. when there are one or more agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report. A reporting node MUST NOT send overload reports of a type that has not been advertised as supported by the reacting node. Note that a reacting node advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types must be explicitly indicated by new feature bits in the OC-Feature-Vector AVP. A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. The reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD ensure that all reacting nodes receive the updated overload report. All OLRs sent have an expiration time calculated by adding the validity-duration contained in the OLR to the time the message was sent. Transit time for the OLR can be safely ignored. The reporting node can ensure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload condition have expired. When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. That is, the same candidate set of messages SHOULD NOT be throttled multiple times. However, when the reporting node sends and OLR downstream, it MAY still be responsible to apply other abatement methods such as diversion. The reporting node might also need to throttle requests for reasons other then overload. For example, an agent or server might have a configured rate limit for each client, and throttle Korhonen, et al. Expires May 7, 2015 [Page 19] Internet-Draft DOIC November 2014 requests that exceed that limit, even if such requests had already been candidates for throttling by downstream nodes. This document assumes that there is a single source for realm-reports for a given realm, or that if multiple nodes can send realm reports, that each such node has full knowledge of the overload state of the entire realm. A reacting node cannot distinguish between receiving realm-reports from a single node, or from multiple nodes. Editor's Note: There is not yet consensus on the above paragraph. Two alternatives are under consideration -- synchronization of sequence numbers and attribution of reports. If no consensus is reached then it will be left to be addressed as an extension. 4.3. Protocol Extensibility The overload control solution can be extended, e.g. with new traffic abatement algorithms, new report types or other new functionality. When defining a new extension a new feature bit MUST be defined for the OC-Feature-Vector. This feature bit is used to communicate support for the new feature. The extension MAY define new AVPs for use in DOIC Capability Announcement and for use in DOIC Overload reporting. These new AVPs SHOULD be defined to be extensions to the OC-Supported-Features and OC-OLR AVPs defined in this document. It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing application. The handling of feature bits in the OC-Feature-Vector AVP that are not associated with overload abatement algorithms MUST be specified by the extensions that define the features. When defining new report type values, the corresponding specification MUST define the semantics of the new report types and how they affect the OC-OLR AVP handling. The specification MUST also reserve a corresponding new feature bit in the OC-Feature-Vector AVP. The OC-OLR AVP can be expanded with optional sub-AVPs only if a legacy DOIC implementation can safely ignore them without breaking backward compatibility for the given OC-Report-Type AVP value. If the new sub-AVPs imply new semantics for handling the indicated report type, then a new OC-Report-Type AVP value MUST be defined. Korhonen, et al. Expires May 7, 2015 [Page 20] Internet-Draft DOIC November 2014 Documents that introduce new report types MUST describe any limitations on their use across non-supporting agents. New features (feature bits in the OC-Feature-Vector AVP) and report types (in the OC-Report-Type AVP) MUST be registered with IANA. As with any Diameter specification, new AVPs MUST also be registered with IANA. See Section 8 for the required procedures. 5. Loss Algorithm This section documents the Diameter overload loss abatement algorithm. 5.1. Overview The DOIC specification supports the ability for multiple overload abatement algorithms to be specified. The abatement algorithm used for any instance of overload is determined by the Diameter Overload Capability Announcement process documented in Section 4.1. The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes use a strategy of applying abatement logic to the requested percentage of request messages sent (or handled in the case of agents) by the reacting node that are impacted by the overload report. From a conceptual level, the logic at the reacting node could be outlined as follows. 1. An overload report is received and the associated overload state is either saved or updated (if required) by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request, as indicated by the corresponding OCS entry. Korhonen, et al. Expires May 7, 2015 [Page 21] Internet-Draft DOIC November 2014 4. The reacting node determines if abatement should be applied to the request. One approach that could be taken for each request is to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. 5.2. Reporting Node Behavior The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. When a reporting node that has selected the loss abatement algorithm determines the need to request a reduction in traffic, it includes an OC-OLR AVP in response messages as described in Section 4.2.3. When sending the OC-OLR AVP, the reporting node MUST indicate a percentage reduction in the OC-Reduction-Percentage AVP. The reporting node MAY change the reduction percentage in subsequent overload reports. When doing so the reporting node must conform to overload report handing specified in Section 4.2.3. When the reporting node determines it no longer needs a reduction in traffic the reporting node SHOULD send an overload report indicating the overload report is no longer valid, as specified in Section 4.2.3. 5.3. Reacting Node Behavior The method a reacting node uses to determine which request messages are given abatement treatment is an implementation decision. When receiving an OC-OLR in an answer message where the algorithm indicated in the OC-Supported-Features AVP is the loss algorithm, the reacting node MUST apply abatement treatment to the requested percentage of request messages sent. Note: the loss algorithm is a stateless algorithm. As a result, the reacting node does not guarantee that there will be an absolute reduction in traffic sent. Rather, it guarantees that the requested percentage of new requests will be given abatement treatment. When applying overload abatement treatment for the load abatement algorithm, the reacting node MUST abate, either by throttling or Korhonen, et al. Expires May 7, 2015 [Page 22] Internet-Draft DOIC November 2014 diversion, the requested percentage of requests that would have otherwise been sent to the reporting host or realm. If reacting node comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The reacting node sending the traffic should be conservative and, for example, first send "probe" messages to learn the overload condition of the overloaded node before converging to any traffic amount/rate decided by the sender. Similar concerns apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. If the reacting node does not receive an OLR in messages sent to the formerly overloaded node then the reacting node SHOULD slowly increase the rate of traffic sent to the overloaded node. It is suggested that the reacting node decrease the amount of traffic given abatement treatment by 20% each second until the reduction is completely removed and no traffic is given abatement treatment. The goal of this behavior is to reduce the probability of overload condition thrashing where an immediate transition from 100% reduction to 0% reduction results in the reporting node moving quickly back into an overload condition. 6. Attribute Value Pairs This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. It is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. 6.1. OC-Supported-Features AVP The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and serves two purposes. First, it announces a node's support for the DOIC solution in general. Second, it contains the description of the supported DOIC features of the sending node. The OC-Supported- Features AVP MUST be included in every Diameter request message a DOIC supporting node sends. Korhonen, et al. Expires May 7, 2015 [Page 23] Internet-Draft DOIC November 2014 OC-Supported-Features ::= < AVP Header: TBD1 > [ OC-Feature-Vector ] * [ AVP ] The OC-Feature-Vector sub-AVP is used to announce the DOIC features supported by the DOIC node, in the form of a flag-bits field in which each bit announces one feature or capability supported by the node (see Section 6.2). The absence of the OC-Feature-Vector AVP indicates that only the default traffic abatement algorithm described in this specification is supported. 6.2. OC-Feature-Vector AVP The OC-Feature-Vector AVP (AVP code TBD6) is of type Unsigned64 and contains a 64 bit flags field of announced capabilities of a DOIC node. The value of zero (0) is reserved. The following capabilities are defined in this document: OLR_DEFAULT_ALGO (0x0000000000000001) When this flag is set by the DOIC node it means that the default traffic abatement (loss) algorithm is supported. 6.3. OC-OLR AVP The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the information necessary to convey an overload report on an overload condition at the reporting node. The OC-OLR AVP does not explicitly contain all information needed by the reacting node to decide whether a subsequent request must undergo abatement using the received reduction percentage. The value of the OC-Report-Type AVP within the OC-OLR AVP indicates which implicit information is relevant for this decision (see Section 6.6). The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The host or realm the OC-OLR AVP concerns is determined from the Origin-Host AVP and/or Origin-Realm AVP found in the encapsulating Diameter command. The OC-OLR AVP is intended to be sent only by a reporting node. OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ] Korhonen, et al. Expires May 7, 2015 [Page 24] Internet-Draft DOIC November 2014 Note that if a Diameter command were to contain multiple OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs with unknown values SHOULD be silently discarded by reacting nodes and the event SHOULD be logged. 6.4. OC-Sequence-Number AVP The OC-Sequence-Number AVP (AVP code TBD3) is of type Unsigned64. Its usage in the context of overload control is described in Section 4.2. From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. The sequence number is only required to be unique between two DOIC nodes. Sequence numbers are treated in a uni- directional manner, i.e. two sequence numbers on each direction between two DOIC nodes are not related or correlated. 6.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is of type Unsigned32 and indicates in milliseconds the validity time of the overload report. The number of milliseconds is measured after reception of the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. The default value for the OC-Validity-Duration AVP is 5000 (i.e.; 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration values are treated as if the OC-Validity-Duration AVP were not present and result in the default value being used. Editor's note: There is an open discussion on whether to have an upper limit on the OC-Validity-Duration value, beyond that which can be indicated by an Unsigned32. 6.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is of type Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: Either 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; or the Destination-Host is Korhonen, et al. Expires May 7, 2015 [Page 25] Internet-Draft DOIC November 2014 not present in the request but the value of the peer identity associated with the connection used to send the request matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. 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. 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: The Destination-Host AVP is absent in the requestand the value of the peer identity associated with the connection used to send the request does not match a server that could serve the request. 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. 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. The OC-Report-Type AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different overload contexts. For example, the reacting node(s) might need to throttle differently requests sent to a specific server (identified by the Destination-Host AVP in the request) and requests that can be handled by any server in a realm. 6.7. OC-Reduction-Percentage AVP The OC-Reduction-Percentage AVP (AVP code TBD8) is of type Unsigned32 and describes the percentage of the traffic that the sender is requested to reduce, compared to what it otherwise would send. The OC-Reduction-Percentage AVP applies to the default (loss) algorithm specified in this specification. However, the AVP can be reused for future abatement algorithms, if its semantics fit into the new algorithm. The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored. The value of 100 means that all traffic is to be throttled, i.e. the reporting Korhonen, et al. Expires May 7, 2015 [Page 26] Internet-Draft DOIC November 2014 node is under a severe load and ceases to process any new messages. The value of 0 means that the reporting node is in a stable state and has no need for the reacting node to apply any traffic abatement. The default value of the OC-Reduction-Percentage AVP is 0. When the OC-Reduction-Percentage AVP is not present in the overload report, the default value applies. 6.8. Attribute Value Pair flag rules +---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------+----+----+ |OC-Supported-Features TBD1 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-OLR TBD2 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number TBD3 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration TBD4 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type TBD5 x.x Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage TBD8 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector TBD6 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. 7. Error Response Codes When a DOIC node rejects a Diameter request due to overload, the DOIC node MUST select an appropriate error response code. This Korhonen, et al. Expires May 7, 2015 [Page 27] Internet-Draft DOIC November 2014 determination is made based on the probability of the request succeeding if retried on a different path. A reporting node rejecting a Diameter request due to an overload condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can assume that the same request may succeed on a different path. If a reporting node knows or assumes that the same request will not succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response SHOULD be used. Retrying would consume valuable resources during an occurrence of overload. For instance, if the request arrived at the reporting node without a Destination-Host AVP then the reporting node might determine that there is an alternative Diameter node that could successfully process the request and that retrying the transaction would not negatively impact the reporting node. DIAMETER_TOO_BUSY would be sent in this case. For instance, if the request arrived at the reporting node with a Destination-Host AVP populated with its own Diameter identity then the reporting node can assume that retrying the request would result in it coming to the same reporting node. DIAMETER_UNABLE_TO_COMPLY would be sent in this case. A second example is when an agent that supports the DOIC solution is performing the role of a reacting node for a non supporting client. Requests that are rejected as a result of DOIC throttling by the agent in this scenario would generally be rejected with a DIAMETER_UNABLE_TO_COMPLY response code. 8. IANA Considerations 8.1. AVP codes New AVPs defined by this specification are listed in Section 6. All AVP codes allocated from the 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP Codes registry. 8.2. New registries Two new registries are needed under the 'Authentication, Authorization, and Accounting (AAA) Parameters' registry. Section 6.2 defines a new "Overload Control Feature Vector" registry including the initial assignments. New values can be added into the registry using the Specification Required policy [RFC5226]. See Section 6.2 for the initial assignment in the registry. Korhonen, et al. Expires May 7, 2015 [Page 28] Internet-Draft DOIC November 2014 Section 6.6 defines a new "Overload Report Type" registry with its initial assignments. New types can be added using the Specification Required policy [RFC5226]. 9. Security Considerations This mechanism gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly affect this reduction. This exchange is potentially subject to multiple methods of attack, and has the potential to be used as a Denial-of-Service (DoS) attack vector. Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid its use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. 9.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is,they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively hop-by-hop trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer. Agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream Korhonen, et al. Expires May 7, 2015 [Page 29] Internet-Draft DOIC November 2014 of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct a response. Therefore, implementations SHOULD validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report. A similar attack involves an otherwise authorized Diameter node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from a peer that applies to a realm not handled by that peer is suspect. An attacker might use the information in an overload report to assist in certain attacks. For example, an attacker could use information about current overload conditions to time a DoS attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. 9.2. Denial of Service Attacks Diameter overload reports can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS tacks. Furthermore, since Diameter is almost always used in support of other protocols, a DoS attack on Diameter is likely to impact those protocols as well. Therefore, Diameter nodes MUST NOT honor or forward overload reports from unauthorized or otherwise untrusted sources. 9.3. Non-Compliant Nodes When a Diameter node sends an overload report, it cannot assume that all nodes will comply. A non-compliant node might continue to send requests with no reduction in load. Requirement 28 [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are necessarily trusted, and that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service. Korhonen, et al. Expires May 7, 2015 [Page 30] Internet-Draft DOIC November 2014 In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might reject a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. 9.4. End-to End-Security Issues The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. At the time of this writing, the DIME working group is studying requirements for adding end-to-end security [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, when they become available, might make it easier to establish trust in non-adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism encourages Diameter agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will Korhonen, et al. Expires May 7, 2015 [Page 31] Internet-Draft DOIC November 2014 require careful consideration, and are beyond the scope of this document. 10. Contributors The following people contributed substantial ideas, feedback, and discussion to this document: o Eric McMurry o Hannes Tschofenig o Ulrich Wiehe o Jean-Jacques Trottin o Maria Cruz Bartolome o Martin Dolly o Nirav Salot o Susan Shishufeng 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 11.2. Informative References [Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013. Korhonen, et al. Expires May 7, 2015 [Page 32] Internet-Draft DOIC November 2014 [I-D.ietf-dime-e2e-sec-req] Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, "Diameter AVP Level Security: Scenarios and Requirements", draft-ietf-dime-e2e-sec-req-00 (work in progress), September 2013. [PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, November 2013. [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. Appendix A. Issues left for future specifications The base solution for the overload control does not cover all possible use cases. A number of solution aspects were intentionally left for future specification and protocol work. A.1. Additional traffic abatement algorithms This specification describes only means for a simple loss based algorithm. Future algorithms can be added using the designed solution extension mechanism. The new algorithms need to be registered with IANA. See Sections 6.1 and 8 for the required IANA steps. A.2. Agent Overload This specification focuses on Diameter endpoint (server or client) overload. A separate extension will be required to outline the handling of the case of agent overload. A.3. New Error Diagnostic AVP The proposal was made to add a new Error Diagnostic AVP to supplement the error responces to be able to indicate that overload was the reason for the rejection of the message. Korhonen, et al. Expires May 7, 2015 [Page 33] Internet-Draft DOIC November 2014 Appendix B. Deployment Considerations Non supporting agents Due to the way that realm-routed requests are handled in Diameter networks, with the server selection for the request done by an agent, it is recommended that deployments enable all agents that do server selection to support the DOIC solution prior to enabling the DOIC solution in the Diameter network. Topology hiding interactions There exist proxies that implement what is referred to as Topology Hiding. This can include cases where the agent modifies the Origin-Host in answer messages. The behavior of the DOIC solution is not well understood when this happens. As such, the DOIC solution does not address this scenario. Appendix C. Requirements Conformance Analysis This section contains the result of an analysis of the DOIC solutions conformance to the requirements defined in [RFC7068]. To be completed. Appendix D. Considerations for Applications Integrating the DOIC Solution This section outlines considerations to be taken into account when integrating the DOIC solution into Diameter applications. D.1. Application Classification The following is a classification of Diameter applications and request types. This discussion is meant to document factors that play into decisions made by the Diameter identity responsible for handling overload reports. Section 8.1 of [RFC6733] defines two state machines that imply two types of applications, session-less and session-based applications. The primary difference between these types of applications is the lifetime of Session-Ids. For session-based applications, the Session-Id is used to tie multiple requests into a single session. The Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application. Korhonen, et al. Expires May 7, 2015 [Page 34] Internet-Draft DOIC November 2014 In session-less applications, the lifetime of the Session-Id is a single Diameter transaction, i.e. the session is implicitly terminated after a single Diameter transaction and a new Session-Id is generated for each Diameter request. For the purposes of this discussion, session-less applications are further divided into two types of applications: Stateless applications: Requests within a stateless application have no relationship to each other. The 3GPP defined S13 application is an example of a stateless application [S13], where only a Diameter command is defined between a client and a server and no state is maintained between two consecutive transactions. Pseudo-session applications: Applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use other session-related information in the Diameter requests for this purpose. The 3GPP defined Cx application [Cx] is an example of a pseudo-session application. The handling of overload reports must take the type of application into consideration, as discussed in Appendix D.2. D.2. Application Type Overload Implications This section discusses considerations for mitigating overload reported by a Diameter entity. This discussion focuses on the type of application. Appendix D.3 discusses considerations for handling various request types when the target server is known to be in an overloaded state. These discussions assume that the strategy for mitigating the reported overload is to reduce the overall workload sent to the overloaded entity. The concept of applying overload treatment to requests targeted for an overloaded Diameter entity is inherent to this discussion. The method used to reduce offered load is not specified here but could include routing requests to another Diameter entity known to be able to handle them, or it could mean rejecting certain requests. For a Diameter agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests will depend upon the application. For example, it could mean giving an indication to the entity requesting the Diameter service that the network is busy and to try again later. Korhonen, et al. Expires May 7, 2015 [Page 35] Internet-Draft DOIC November 2014 Stateless applications: By definition there is no relationship between individual requests in a stateless application. As a result, when a request is sent or relayed to an overloaded Diameter entity - either a Diameter Server or a Diameter Agent - the sending or relaying entity can choose to apply the overload treatment to any request targeted for the overloaded entity. Pseudo-session applications: For pseudo-session applications, there is an implied ordering of requests. As a result, decisions about which requests towards an overloaded entity to reject could take the command code of the request into consideration. This generally means that transactions later in the sequence of transactions should be given more favorable treatment than messages earlier in the sequence. This is because more work has already been done by the Diameter network for those transactions that occur later in the sequence. Rejecting them could result in increasing the load on the network as the transactions earlier in the sequence might also need to be repeated. Session-based applications: Overload handling for session-based applications must take into consideration the work load associated with setting up and maintaining a session. As such, the entity sending requests towards an overloaded Diameter entity for a session-based application might tend to reject new session requests prior to rejecting intra-session requests. In addition, session ending requests might be given a lower probability of being rejected as rejecting session ending requests could result in session status being out of sync between the Diameter clients and servers. Application designers that would decide to reject mid-session requests will need to consider whether the rejection invalidates the session and any resulting session clean-up procedures. D.3. Request Transaction Classification Independent Request: An independent request is not correlated to any other requests and, as such, the lifetime of the session-id is constrained to an individual transaction. Session-Initiating Request: Korhonen, et al. Expires May 7, 2015 [Page 36] Internet-Draft DOIC November 2014 A session-initiating request is the initial message that establishes a Diameter session. The ACR message defined in [RFC6733] is an example of a session-initiating request. Correlated Session-Initiating Request: There are cases when multiple session-initiated requests must be correlated and managed by the same Diameter server. It is notably the case in the 3GPP PCC architecture [PCC], where multiple apparently independent Diameter application sessions are actually correlated and must be handled by the same Diameter server. Intra-Session Request: An intra session request is a request that uses the same Session- Id than the one used in a previous request. An intra session request generally needs to be delivered to the server that handled the session creating request for the session. The STR message defined in [RFC6733] is an example of an intra-session requests. Pseudo-Session Requests: Pseudo-session requests are independent requests and do not use the same Session-Id but are correlated by other session-related information contained in the request. There exists Diameter applications that define an expected ordering of transactions. This sequencing of independent transactions results in a pseudo session. The AIR, MAR and SAR requests in the 3GPP defined Cx [Cx] application are examples of pseudo-session requests. D.4. Request Type Overload Implications The request classes identified in Appendix D.3 have implications on decisions about which requests should be throttled first. 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. The exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. Independent requests: Independent requests can generally be given equal treatment when making throttling decisions, unless otherwise indicated by application requirements or local policy. Session-initiating requests: Korhonen, et al. Expires May 7, 2015 [Page 37] Internet-Draft DOIC November 2014 Session-initiating requests often represent more work than independent or intra-session requests. Moreover, session- initiating requests are typically followed by other session- related requests. Since the main objective of the overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. In the absence of local policies or application specific requirements to the contrary, Individual session-initiating requests can be given equal treatment when making throttling decisions. Correlated session-initiating requests: A Request that results in a new binding, where the binding is used for routing of subsequent session-initiating requests to the same server, represents more work load than other requests. As such, these requests might be throttled more frequently than other request types. Pseudo-session requests: Throttling decisions for pseudo-session requests can take into consideration where individual requests fit into the overall sequence of requests within the pseudo session. Requests that are earlier in the sequence might be throttled more aggressively than requests that occur later in the sequence. Intra-session requests: There are two types of intra-sessions requests, requests that terminate a session and the remainder of intra-session requests. Implementors and operators may choose to throttle session- terminating requests less aggressively in order to gracefully terminate sessions, allow clean-up of the related resources (e.g. session state) and avoid the need for additional intra-session requests. Favoring session-termination requests may reduce the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making throttling decisions. There might also be application level considerations whether some request types are favored over others. Authors' Addresses Korhonen, et al. Expires May 7, 2015 [Page 38] Internet-Draft DOIC November 2014 Jouni Korhonen (editor) Broadcom Porkkalankatu 24 Helsinki FIN-00180 Finland Email: jouni.nospam@gmail.com Steve Donovan (editor) Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: srdonovan@usdonovans.com Ben Campbell Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: ben@nostrum.com Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33145296257 Email: lionel.morand@orange.com Korhonen, et al. Expires May 7, 2015 [Page 39] --------------030901000904020405040502-- From nobody Wed Nov 12 11:42: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 D56741A212A for ; Wed, 12 Nov 2014 11:42: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 Ud54L1fp7OeJ for ; Wed, 12 Nov 2014 11:42:21 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5261A1AC2 for ; Wed, 12 Nov 2014 11:42:20 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so14908257wgh.11 for ; Wed, 12 Nov 2014 11:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VkS1CuVw+ehytq6gTShQsiyIkSkX4yXVYmtKQBQA5/g=; b=VIO2o6R1FzaES45W+Mgt1r2DKs/zD62k2Y6N1wTjvaFekrvrI2iaciDi6JFqKPgVQF VimVFFzuBsDtzz+/AtNwnXlJbhd7mQaJN6q/EeglDDN07FNj+LFzAPNowW3Ra5kt7foF psxkZmw29X3iZFxSD2DVmSF4DKNmwI7PFzVF1TFGkU1b7NdoZrZJc6rWNpu+Wz9BaqLQ T9Nshfo6eRLM0YF5UCHe3cycuTIj69O3FXPeqxbWcSLyX3C9rJJuL91cCgl2QuDMdHII bfSdTx5QXc1phd7ih4bIWj6pSwnksNv67atjlNJpkGZ2gQ1YVD/xKfHPoN26/jKyoykl IAZg== X-Received: by 10.194.157.137 with SMTP id wm9mr67440575wjb.5.1415821339652; Wed, 12 Nov 2014 11:42:19 -0800 (PST) Received: from ?IPv6:2001:67c:370:176:941:d755:8aa3:dd99? (t2001067c037001760941d7558aa3dd99.wireless-a.v6.meeting.ietf.org. [2001:67c:370:176:941:d755:8aa3:dd99]) by mx.google.com with ESMTPSA id q9sm22835116wix.6.2014.11.12.11.42.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 11:42:19 -0800 (PST) Message-ID: <5463B816.9040005@gmail.com> Date: Wed, 12 Nov 2014 21:42:14 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "dime@ietf.org" References: <5463AF67.5010009@usdonovans.com> In-Reply-To: <5463AF67.5010009@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LxCOFaXF43ovrTLCtKd-_bmV4hc Subject: Re: [Dime] -05 of DOIC specification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 19:42:23 -0000 Hi These are not reflected: http://www.ietf.org/mail-archive/web/dime/current/msg08001.html - Jouni 11/12/2014 9:05 PM, Steve Donovan kirjoitti: > All, > > Here's the txt version of DOIC -05 for use in review. > > Regards, > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Nov 12 15: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 C99A01A1B51 for ; Wed, 12 Nov 2014 15:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-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 wM0lK-DA1oJn for ; Wed, 12 Nov 2014 15:36:37 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5431A1B62 for ; Wed, 12 Nov 2014 15:36:36 -0800 (PST) Received: from dhcp-8fa7.meeting.ietf.org ([31.133.143.167]:54110) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XohSg-000CRy-Se; Wed, 12 Nov 2014 15:36:35 -0800 Message-ID: <5463EEFE.9050005@usdonovans.com> Date: Wed, 12 Nov 2014 13:36:30 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jouni Korhonen , "dime@ietf.org" References: <5463AF67.5010009@usdonovans.com> <5463B816.9040005@gmail.com> In-Reply-To: <5463B816.9040005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iPNDpxrpGPZfqKWn42OOU3Og0qA Subject: Re: [Dime] -05 of DOIC specification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 23:36:38 -0000 Jouni, This is the version from before this week. I sent it to for people in this mornings meeting to have a current copy to work from. Your comments, along with those from the other reviews, will be reflected in the next version. Steve On 11/12/14, 9:42 AM, Jouni Korhonen wrote: > Hi > > These are not reflected: > http://www.ietf.org/mail-archive/web/dime/current/msg08001.html > > - Jouni > > 11/12/2014 9:05 PM, Steve Donovan kirjoitti: >> All, >> >> Here's the txt version of DOIC -05 for use in review. >> >> Regards, >> >> Steve >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Wed Nov 12 16:05: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 5CC5B1A0069 for ; Wed, 12 Nov 2014 16:01: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 WNSFkjkougIl for ; Wed, 12 Nov 2014 16:01:36 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9B21A0065 for ; Wed, 12 Nov 2014 16:01:36 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id 10so10061630lbg.7 for ; Wed, 12 Nov 2014 16:01: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=rX/AhdOjYY2e+FJd98EK/k4/vNiNCSFLuxj6CquJsHA=; b=z5KfspIuHgZMBcW6Iqz9sDOJvDK8av7fkGsVaHUzVS7IHCqkp2y9ga1ppihKZrq04A xpyuyGDcvWacXR5nHhDFSiFGeLN7XWGvLWQdmXpj+QI039W3gLGp0XoELSxFARfzxvMv cyEjIMXIbKTV4qjLi7wJves5W7+rebOBFu5VSZWA6PxTMeyUbRKCQ/BAW2ZhztccMQBH LH+LHAutA3VnKR8VMX6QP0k/7zR7JW3O5nQ9iH+eMFEldDSDk8OAJIzxil1sQ68rLQKy A9obZTE07w/PyViWK6gccuDfhVNOtHp+4roIFMNgfDDhkr5mk0yiiBmlSmNjLzjtNAyX ap1w== X-Received: by 10.112.54.229 with SMTP id m5mr45106512lbp.11.1415836894675; Wed, 12 Nov 2014 16:01:34 -0800 (PST) Received: from [85.156.36.44] (85-156-36-44.elisa-mobile.fi. [85.156.36.44]) by mx.google.com with ESMTPSA id ee6sm7042368lad.45.2014.11.12.16.01.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 16:01:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jouni X-Mailer: iPhone Mail (12B411) In-Reply-To: <5463EEFE.9050005@usdonovans.com> Date: Wed, 12 Nov 2014 14:01:26 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5463AF67.5010009@usdonovans.com> <5463B816.9040005@gmail.com> <5463EEFE.9050005@usdonovans.com> To: Steve Donovan Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_A5Cj0J5tQU3nM7ExaEpdpRvvnc Cc: "dime@ietf.org" Subject: Re: [Dime] -05 of DOIC specification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 00:01:41 -0000 Ack! --=20 Jouni Korhonen Broadcom (Sent from my mobile..) > Steve Donovan kirjoitti 12.11.2014 kello 13.36:= >=20 > Jouni, >=20 > This is the version from before this week. I sent it to for people in thi= s mornings meeting to have a current copy to work from. >=20 > Your comments, along with those from the other reviews, will be reflected i= n the next version. >=20 > Steve >=20 >> On 11/12/14, 9:42 AM, Jouni Korhonen wrote: >> Hi >>=20 >> These are not reflected: >> http://www.ietf.org/mail-archive/web/dime/current/msg08001.html >>=20 >> - Jouni >>=20 >> 11/12/2014 9:05 PM, Steve Donovan kirjoitti: >>> All, >>>=20 >>> Here's the txt version of DOIC -05 for use in review. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 From nobody Wed Nov 12 18:15: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 24AC01A1ACF for ; Wed, 12 Nov 2014 18:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xk2GPpPhT6Vx for ; Wed, 12 Nov 2014 18:15:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D621A1AB9 for ; Wed, 12 Nov 2014 18:15:50 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id B6ED71908FD for ; Thu, 13 Nov 2014 03:15:48 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 9E0FF38404E for ; Thu, 13 Nov 2014 03:15:48 +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.0210.002; Thu, 13 Nov 2014 03:15:48 +0100 From: To: "dime@ietf.org" Thread-Topic: proposal for section 6.6 Thread-Index: Ac/+5aGQG3TGou3mR0mbCmnpmK+jow== Date: Thu, 13 Nov 2014 02:15:48 +0000 Message-ID: <1271_1415844948_54641454_1271_10931_1_6B7134B31289DC4FAF731D844122B36E8D4919@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.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E8D4919PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.65124 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BMfi_OyNzeX0zyPeYFNdfmpU4SY Subject: [Dime] proposal for section 6.6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 02:15:53 -0000 --_000_6B7134B31289DC4FAF731D844122B36E8D4919PEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following the discussion of this morning, here my proposal for the section = defining the OC-Report-Type. The value "HOST_REPORT" and "REALM_REPORT" can be reused when appropriate i= n other part of the document e.g. instead of saying "report of type host" e= tc. I take also into account the conclusion about removing repeated text about = host-routed and realm-routed. Regards, Lionel **************** 6.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The value of the AVP describes what the overload report concerns. The following values are defined in this this specification: HOST_REPORT 0 The overload report is for a host. The overload treatment should apply to host-routed requests . REALM_REPORT 1 The overload report is for a realm. The overload treatment should apply to realm-routed requests. ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E8D4919PEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following the discussion of thi= s morning, here my proposal for the section defining the OC-Report-Type.

The value "HOST_REPORT&quo= t; and "REALM_REPORT" can be reused when appropriate in other par= t of the document e.g. instead of saying "report of type host" et= c.

 

I take also into account the co= nclusion about removing repeated text about host-routed and realm-routed.

 

Regards,

 

Lionel

 

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

6.6.  OC-Report-Type AVP

 

  The OC-Report-Type AVP (= AVP code TBD5) is type of Enumerated.  The

   value of the AVP d= escribes what the overload report concerns.  The

   following values a= re defined in this this specification:

 

   HOST_REPORT 0=

      =

     &= nbsp;The overload report is for a  host.  The overload treatment = should

      = apply to host-routed requests .

 

   REALM_REPORT 1

      =

     &= nbsp;The overload report is for a realm.  The overload treatment shoul= d

      = apply to realm-routed requests.

 

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E8D4919PEXCVZYM13corpora_-- From nobody Wed Nov 12 18:48: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 995141A1AF2 for ; Wed, 12 Nov 2014 18:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 D93pvFXQY2KT for ; Wed, 12 Nov 2014 18:48:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849BF1A1B2E for ; Wed, 12 Nov 2014 18:48:26 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id C219D190890 for ; Thu, 13 Nov 2014 03:48:24 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id A870C3840AE for ; Thu, 13 Nov 2014 03:48: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.0210.002; Thu, 13 Nov 2014 03:48:24 +0100 From: To: "dime@ietf.org" Thread-Topic: Proposed modification for section 3 Thread-Index: Ac/+6+YGPSr5BsS2Sdi4xeSCaeGHgw== Date: Thu, 13 Nov 2014 02:48:23 +0000 Message-ID: <1271_1415846904_54641BF8_1271_11614_1_6B7134B31289DC4FAF731D844122B36E8D4B83@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.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E8D4B83PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.65124 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s1phPvuoUf1ACGyq5Au6Rv8ifC4 Subject: [Dime] Proposed modification for section 3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 02:48:35 -0000 --_000_6B7134B31289DC4FAF731D844122B36E8D4B83PEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable According to the proposed modification of the definition of the Report-Type= AVP (see proposal for section 6.6), it would be easier to use the values d= efined for Report-type and make the link with host/realm-routed. Moreover, host-routed and realm-routed is defined at the beginning of the s= pec, so no need to repeat. Finally, I propose to avoid the use of "server" when not required. let me know if it is acceptable. Regards, Lionel ******************* OLD: A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of requests that are not host-routed as defined in the previous paragraph. NEW: A report of type "HOST_REPORT" is sent to indicate the overload of a spe= cific host, identified by the Origin-Host AVP of the message containing the OL= R, for the application-id indicated in the transaction. When receiving an O= LR of type "HOST_REPORT", a reacting node applies overload abatement to host-r= outed requests (see definition in section 2) sent for this application to a sp= ecific host that matches the Origin-Host AVP to which applies the received OLR. A report of type "REALM_REPORT" is sent to indicate the overload of a realm for the application-id. The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR. When receiving an OLR of type "REALM_REPORT", a reacting node applies overload abatement to realm-routed requests (see definition in section 2) sent for this application. ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E8D4B83PEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

According to the proposed modif= ication of the definition of the Report-Type AVP (see proposal for section = 6.6), it would be easier to use the values defined for Report-type and make= the link with host/realm-routed.

Moreover, host-routed and realm= -routed is defined at the beginning of the spec, so no need to repeat.=

Finally, I propose to avoid the= use of "server" when not required.

 

let me know if it is acceptable= .

 

Regards,

 

Lionel

 

*******************<= /span>

OLD:

 

   A report of type h= ost is sent to indicate the overload of a specific

   server for the app= lication-id indicated in the transaction.  When

   receiving an OLR o= f type host, a reacting node applies overload

   abatement to what = is referred to in this document as host-routed

   requests.  Th= is is the set of requests that the reacting node knows

   will be served by = a particular host, either due to the presence of a

   Destination-Host A= VP, or by some other local knowledge on the part of

   the reacting node.=   The reacting node applies overload abatement on

   those host-routed = requests which the reacting node knows will be

   served by the serv= er that matches the Origin-Host AVP of the received

   message that conta= ined the received OLR of type host.

 

   A report type of r= ealm is sent to indicate the overload of all

   servers in a realm= for the application-id.  When receiving an OLR of

   type realm, a reac= ting node applies overload abatement to what is

   referred to in thi= s document as realm-routed requests.  This is the

   set of requests th= at are not host-routed as defined in the previous

   paragraph.<= o:p>

 

NEW:

 

   A report of type &= quot;HOST_REPORT" is sent to indicate the overload of a specific<= /o:p>

   host, identified b= y the Origin-Host AVP of the message containing the OLR,<= /p>

   for the applicatio= n-id indicated in the transaction. When receiving an OLR of

   type "HOST_RE= PORT", a reacting node applies overload abatement to host-routed

   requests (see= definition in section 2) sent for this application to a specific host that

   matches the O= rigin-Host AVP to which applies the received OLR.

 

   A report of type &= quot;REALM_REPORT" is sent to indicate the overload of

   a realm for t= he application-id. The overloaded realm is identified by the

   Destination-R= ealm AVP of the message containing the OLR.

   When receiving an = OLR of type "REALM_REPORT", a reacting node applies

   overload abat= ement to realm-routed requests (see definition in section 2)

   sent for this appl= ication.

 

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E8D4B83PEXCVZYM13corpora_-- From nobody Thu Nov 13 00:48: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 E1AF11A2130 for ; Thu, 13 Nov 2014 00:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 d7dBkmzaN7hB for ; Thu, 13 Nov 2014 00:48:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3681A6FB5 for ; Thu, 13 Nov 2014 00:48:35 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAD8mWQh026266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 08:48:32 GMT 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 sAD8mRtL009233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 09:48:27 +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.195.1; Thu, 13 Nov 2014 09:48:26 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.88]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 09:48:26 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "ext lionel.morand@orange.com" , Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zS149M3XUUPk28UQPOO8ZJK5xXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAIOgoIAAsQaAgABWIoCAAOhEkA== Date: Thu, 13 Nov 2014 08:48:26 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815228FEB@DEMUMBX014.nsn-intra.net> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5463A7BB.9020804@usdonovans.com> In-Reply-To: <5463A7BB.9020804@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: 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: 3080 X-purgate-ID: 151667::1415868512-0000437E-F39DD550/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/D3pcFfU5SZIUBb8-eclBQY0n_Xk Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 08:48:38 -0000 Steve, I strongly disagree. In the path of a request there are allways as many reacting nodes as report= ing nodes. Examples are: 1. one reporting node, one reacting node +---+ +---+ +---+ | C |-------| A |------| S | +---+ +---+ +---+ C is reacting node (reacting on host-type OLRs received from S), A (no matter whether or not it supports DOIC) is neither reacting node nor = reporting node, S is reporting node C and S must have at least one commonly supported algorithm. 2. one reporting node, one reacting node +---+ +---+ +---+ | C |-------| A |------| S | +---+ +---+ +---+ C is neither reacting node nor reporting node, A is reacting node (on behalf of C), S is reporting node A and S must have at least one commonly supported algorithm. 3. two reporting nodes, two reacting nodes +---+ +---+ +---+ | C |-------| A |------| S | +---+ +---+ +---+ C is reacting node (reacting on realm-type OLRs received from A), A is reporting node (reporting realm-type OLRs to C) and reacting node (rea= cting on host-type OLRs received from S)=20 S is reporting node C and A must have at least one commonly supported algorithm, and A and S mu= st have at least one commonly supported algorithm. No need for C, A, and S = to have at least one commonly supported algorithm. What we DO NOT have is: 4. one reporting node, two reacting nodes +---+ +---+ +---+ | C |-------| A |------| S | +---+ +---+ +---+ C is reacting node, A is reacting node but not reporting node,=20 S is reporting node If we had this then yes=20 There would be the need for C, A, and S to have at least one commonly suppo= rted algorithm, and There would be the need to modify the algorithm negotiation mechanism: e.g.= when C supports loss, A supports loss and rate, S supports loss and rate, = then A would not be allowed to advertize rate and loss to S but only loss.= =20 Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, November 12, 2014 7:32 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; Maria Cr= uz Bartolome; dime@ietf.org Subject: Re: [Dime] Updates to DOIC -05 The suggestion is from "reacting nodes" to "reacting node". I disagree with this change, as there can be more than one reacting node=20 for a single report. I would agree to change it to "reacting node(s)". Steve Section 3.2, 3rd paragraph last sentence: Existing text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= es in the path of the request. Proposed text: This ensures that there is at least one commonly supported o= verload abatement algorithm between the reporting node and the reacting nod= e in the path of the request. [LM] I may be too tired, but I cannot see the proposed change. [Ulrich] That's why I like revision marking in word documents. Try again. From nobody Thu Nov 13 08:53: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 0333C1A8AAB for ; Thu, 13 Nov 2014 08:53:52 -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 cEDclEzdSulA for ; Thu, 13 Nov 2014 08:53:51 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3471A8AAF for ; Thu, 13 Nov 2014 08:53:50 -0800 (PST) Received: from dhcp-8e0e.meeting.ietf.org ([31.133.142.14]:65119) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XoxeT-0001ls-Lb; Thu, 13 Nov 2014 08:53:47 -0800 Message-ID: <5464E219.7070304@usdonovans.com> Date: Thu, 13 Nov 2014 06:53:45 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , Maria Cruz Bartolome , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5463A7BB.9020804@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815228FEB@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815228FEB@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YF7rJLsyF0KAoDqKbUwZQqlb6qs Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:53:52 -0000 Ulrich, The basic scenario, when there are agents between Diameter Clients and Diameter Servers, for handling of host reports requires two separate Diameter nodes to act on the host report. The client in your first case is responsible for applying abatement treatment to host routed requests. The agent is responsible for applying abatement treatment to realm routed requests. As such, there can be more than one reacting node for a single overload report. Steve On 11/12/14, 10:48 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I strongly disagree. > > In the path of a request there are allways as many reacting nodes as reporting nodes. > > Examples are: > 1. one reporting node, one reacting node > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is reacting node (reacting on host-type OLRs received from S), > A (no matter whether or not it supports DOIC) is neither reacting node nor reporting node, > S is reporting node > C and S must have at least one commonly supported algorithm. > > 2. one reporting node, one reacting node > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is neither reacting node nor reporting node, > A is reacting node (on behalf of C), > S is reporting node > A and S must have at least one commonly supported algorithm. > > 3. two reporting nodes, two reacting nodes > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is reacting node (reacting on realm-type OLRs received from A), > A is reporting node (reporting realm-type OLRs to C) and reacting node (reacting on host-type OLRs received from S) > S is reporting node > C and A must have at least one commonly supported algorithm, and A and S must have at least one commonly supported algorithm. No need for C, A, and S to have at least one commonly supported algorithm. > > What we DO NOT have is: > 4. one reporting node, two reacting nodes > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is reacting node, > A is reacting node but not reporting node, > S is reporting node > If we had this then yes > There would be the need for C, A, and S to have at least one commonly supported algorithm, and > There would be the need to modify the algorithm negotiation mechanism: e.g. when C supports loss, A supports loss and rate, S supports loss and rate, then A would not be allowed to advertize rate and loss to S but only loss. > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, November 12, 2014 7:32 PM > To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Updates to DOIC -05 > > The suggestion is from "reacting nodes" to "reacting node". > > I disagree with this change, as there can be more than one reacting node > for a single report. > > I would agree to change it to "reacting node(s)". > > Steve > > > Section 3.2, 3rd paragraph last sentence: > Existing text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. > Proposed text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting node in the path of the request. > > [LM] I may be too tired, but I cannot see the proposed change. > [Ulrich] That's why I like revision marking in word documents. Try again. > > > > From nobody Thu Nov 13 10:18: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 CA25F1A90C4 for ; Thu, 13 Nov 2014 10:18:49 -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 j8cSrDbyBm7Z for ; Thu, 13 Nov 2014 10:18:48 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519991A90CD for ; Thu, 13 Nov 2014 10:18:47 -0800 (PST) Received: from dhcp-a69d.meeting.ietf.org ([31.133.166.157]:65511) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xoyyi-0004R4-Ex for dime@ietf.org; Thu, 13 Nov 2014 10:18:46 -0800 Message-ID: <5464F603.6010205@usdonovans.com> Date: Thu, 13 Nov 2014 08:18:43 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <1271_1415844948_54641454_1271_10931_1_6B7134B31289DC4FAF731D844122B36E8D4919@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <1271_1415844948_54641454_1271_10931_1_6B7134B31289DC4FAF731D844122B36E8D4919@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------030802070700060802040603" 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/B1LSsZmXhA5VwNB7qkcgytyczWQ Subject: Re: [Dime] proposal for section 6.6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:18:50 -0000 This is a multi-part message in MIME format. --------------030802070700060802040603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Agreed with one modification. Instead of saying "The overload treatment should apply...", I changed it to "Overload abatement treatment applies to...". Steve On 11/12/14, 4:15 PM, lionel.morand@orange.com wrote: > > Following the discussion of this morning, here my proposal for the > section defining the OC-Report-Type. > > The value "HOST_REPORT" and "REALM_REPORT" can be reused when > appropriate in other part of the document e.g. instead of saying > "report of type host" etc. > > I take also into account the conclusion about removing repeated text > about host-routed and realm-routed. > > Regards, > > Lionel > > **************** > > 6.6. OC-Report-Type AVP > > The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The > > value of the AVP describes what the overload report concerns. The > > following values are defined in this this specification: > > HOST_REPORT 0 > > The overload report is for a host. The overload treatment should > > apply to host-routed requests . > > REALM_REPORT 1 > > The overload report is for a realm. The overload treatment should > > apply to realm-routed requests. > > _________________________________________________________________________________________________________________________ > > 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 --------------030802070700060802040603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed with one modification.  Instead of saying "The overload treatment should apply...", I changed it to "Overload abatement treatment applies to...".

Steve

On 11/12/14, 4:15 PM, lionel.morand@orange.com wrote:

Following the discussion of this morning, here my proposal for the section defining the OC-Report-Type.

The value "HOST_REPORT" and "REALM_REPORT" can be reused when appropriate in other part of the document e.g. instead of saying "report of type host" etc.

 

I take also into account the conclusion about removing repeated text about host-routed and realm-routed.

 

Regards,

 

Lionel

 

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

6.6.  OC-Report-Type AVP

 

  The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated.  The

   value of the AVP describes what the overload report concerns.  The

   following values are defined in this this specification:

 

   HOST_REPORT 0

     

      The overload report is for a  host.  The overload treatment should

      apply to host-routed requests .

 

   REALM_REPORT 1

     

      The overload report is for a realm.  The overload treatment should

      apply to realm-routed requests.

 

_________________________________________________________________________________________________________________________

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

--------------030802070700060802040603-- From nobody Thu Nov 13 10:32: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 1BF401A90E5 for ; Thu, 13 Nov 2014 10:32:35 -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 LOPhLXcKaMKB for ; Thu, 13 Nov 2014 10:32:33 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FF31A90C5 for ; Thu, 13 Nov 2014 10:32:33 -0800 (PST) Received: from dhcp-a69d.meeting.ietf.org ([31.133.166.157]:49305) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XozC1-0009Tm-4h for dime@ietf.org; Thu, 13 Nov 2014 10:32:32 -0800 Message-ID: <5464F93C.3080907@usdonovans.com> Date: Thu, 13 Nov 2014 08:32:28 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <1271_1415846904_54641BF8_1271_11614_1_6B7134B31289DC4FAF731D844122B36E8D4B83@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <1271_1415846904_54641BF8_1271_11614_1_6B7134B31289DC4FAF731D844122B36E8D4B83@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------090405020200010201000109" 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/Wem9Xj2-1IA9PB1FhCgC4u2I-HU Subject: Re: [Dime] Proposed modification for section 3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:32:35 -0000 This is a multi-part message in MIME format. --------------090405020200010201000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Agreed. Changed with some wordsmithing: A report of type "HOST_REPORT" is sent to indicate the overload of a specific host, identified by the Origin-Host AVP of the message containing the OLR, for the application-id indicated in the transaction. When receiving an OLR of type "HOST_REPORT", a reacting node applies overload abatement treatment to host-routed requests (see definition in Section 2) sent for this application to the overloaded host. A report of type "REALM_REPORT" is sent to indicate the overload of a realm for the application-id indicated in the transaction. The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR. When receiving an OLR of type "REALM_REPORT", a reacting node applies overload abatement treatment to realm-routed requests (see definition in Section 2) sent for this application to the overloaded realm. Steve On 11/12/14, 4:48 PM, lionel.morand@orange.com wrote: > > According to the proposed modification of the definition of the > Report-Type AVP (see proposal for section 6.6), it would be easier to > use the values defined for Report-type and make the link with > host/realm-routed. > > Moreover, host-routed and realm-routed is defined at the beginning of > the spec, so no need to repeat. > > Finally, I propose to avoid the use of "server" when not required. > > let me know if it is acceptable. > > Regards, > > Lionel > > ******************* > > OLD: > > A report of type host is sent to indicate the overload of a specific > > server for the application-id indicated in the transaction. When > > receiving an OLR of type host, a reacting node applies overload > > abatement to what is referred to in this document as host-routed > > requests. This is the set of requests that the reacting node knows > > will be served by a particular host, either due to the presence of a > > Destination-Host AVP, or by some other local knowledge on the part of > > the reacting node. The reacting node applies overload abatement on > > those host-routed requests which the reacting node knows will be > > served by the server that matches the Origin-Host AVP of the received > > message that contained the received OLR of type host. > > A report type of realm is sent to indicate the overload of all > > servers in a realm for the application-id. When receiving an OLR of > > type realm, a reacting node applies overload abatement to what is > > referred to in this document as realm-routed requests. This is the > > set of requests that are not host-routed as defined in the previous > > paragraph. > > NEW: > > A report of type "HOST_REPORT" is sent to indicate the overload of > a specific > > host, identified by the Origin-Host AVP of the message containing > the OLR, > > for the application-id indicated in the transaction. When receiving > an OLR of > > type "HOST_REPORT", a reacting node applies overload abatement to > host-routed > > requests (see definition in section 2) sent for this application to > a specific host that > > matches the Origin-Host AVP to which applies the received OLR. > > A report of type "REALM_REPORT" is sent to indicate the overload of > > a realm for the application-id. The overloaded realm is identified > by the > > Destination-Realm AVP of the message containing the OLR. > > When receiving an OLR of type "REALM_REPORT", a reacting node applies > > overload abatement to realm-routed requests (see definition in > section 2) > > sent for this application. > > _________________________________________________________________________________________________________________________ > > 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 --------------090405020200010201000109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed.

Changed with some wordsmithing:

   A report of type "HOST_REPORT" is sent to indicate the overload of a
   specific host, identified by the Origin-Host AVP of the message
   containing the OLR, for the application-id indicated in the
   transaction.  When receiving an OLR of type "HOST_REPORT", a reacting
   node applies overload abatement treatment to host-routed requests
   (see definition in Section 2) sent for this application to the
   overloaded host.

   A report of type "REALM_REPORT" is sent to indicate the overload of a
   realm for the application-id indicated in the transaction.  The
   overloaded realm is identified by the Destination-Realm AVP of the
   message containing the OLR.  When receiving an OLR of type
   "REALM_REPORT", a reacting node applies overload abatement treatment
   to realm-routed requests (see definition in Section 2) sent for this
   application to the overloaded realm.
Steve

On 11/12/14, 4:48 PM, lionel.morand@orange.com wrote:

According to the proposed modification of the definition of the Report-Type AVP (see proposal for section 6.6), it would be easier to use the values defined for Report-type and make the link with host/realm-routed.

Moreover, host-routed and realm-routed is defined at the beginning of the spec, so no need to repeat.

Finally, I propose to avoid the use of "server" when not required.

 

let me know if it is acceptable.

 

Regards,

 

Lionel

 

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

OLD:

 

   A report of type host is sent to indicate the overload of a specific

   server for the application-id indicated in the transaction.  When

   receiving an OLR of type host, a reacting node applies overload

   abatement to what is referred to in this document as host-routed

   requests.  This is the set of requests that the reacting node knows

   will be served by a particular host, either due to the presence of a

   Destination-Host AVP, or by some other local knowledge on the part of

   the reacting node.  The reacting node applies overload abatement on

   those host-routed requests which the reacting node knows will be

   served by the server that matches the Origin-Host AVP of the received

   message that contained the received OLR of type host.

 

   A report type of realm is sent to indicate the overload of all

   servers in a realm for the application-id.  When receiving an OLR of

   type realm, a reacting node applies overload abatement to what is

   referred to in this document as realm-routed requests.  This is the

   set of requests that are not host-routed as defined in the previous

   paragraph.

 

NEW:

 

   A report of type "HOST_REPORT" is sent to indicate the overload of a specific

   host, identified by the Origin-Host AVP of the message containing the OLR,

   for the application-id indicated in the transaction. When receiving an OLR of

   type "HOST_REPORT", a reacting node applies overload abatement to host-routed

   requests (see definition in section 2) sent for this application to a specific host that

   matches the Origin-Host AVP to which applies the received OLR.

 

   A report of type "REALM_REPORT" is sent to indicate the overload of

   a realm for the application-id. The overloaded realm is identified by the

   Destination-Realm AVP of the message containing the OLR.

   When receiving an OLR of type "REALM_REPORT", a reacting node applies

   overload abatement to realm-routed requests (see definition in section 2)

   sent for this application.

 

_________________________________________________________________________________________________________________________

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

--------------090405020200010201000109-- From nobody Thu Nov 13 10:43: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 A5B9B1A9164 for ; Thu, 13 Nov 2014 10:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 U5w2gS1ZEmh4 for ; Thu, 13 Nov 2014 10:43:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4BD1A923A for ; Thu, 13 Nov 2014 10:42:58 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A40BB3B471C; Thu, 13 Nov 2014 19:42:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8706B238095; Thu, 13 Nov 2014 19:42: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.0210.002; Thu, 13 Nov 2014 19:42:56 +0100 From: To: "dime@ietf.org" , Steve Donovan Thread-Topic: [Dime] proposal for section 6.6 Thread-Index: Ac/+5aGQG3TGou3mR0mbCmnpmK+jowAgD5SAAALw4KU= Date: Thu, 13 Nov 2014 18:42:55 +0000 Message-ID: <2200_1415904176_5464FBB0_2200_11785_1_ocheo4w473bh7m99bukoqvso.1415904163936@email.android.com> References: <1271_1415844948_54641454_1271_10931_1_6B7134B31289DC4FAF731D844122B36E8D4919@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5464F603.6010205@usdonovans.com> In-Reply-To: <5464F603.6010205@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_ocheo4w473bh7m99bukoqvso1415904163936emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.13.145420 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pkMTu25tIrjw96AmERtvRVVeXUI Subject: Re: [Dime] proposal for section 6.6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:43:18 -0000 --_000_ocheo4w473bh7m99bukoqvso1415904163936emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Steve Donovan a =E9crit ---- Agreed with one modification. Instead of saying "The overload treatment sh= ould apply...", I changed it to "Overload abatement treatment applies to...= ". Steve On 11/12/14, 4:15 PM, lionel.morand@orange.com wrote: Following the discussion of this morning, here my proposal for the section = defining the OC-Report-Type. The value "HOST_REPORT" and "REALM_REPORT" can be reused when appropriate i= n other part of the document e.g. instead of saying "report of type host" e= tc. I take also into account the conclusion about removing repeated text about = host-routed and realm-routed. Regards, Lionel **************** 6.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The value of the AVP describes what the overload report concerns. The following values are defined in this this specification: HOST_REPORT 0 The overload report is for a host. The overload treatment should apply to host-routed requests . REALM_REPORT 1 The overload report is for a realm. The overload treatment should apply to realm-routed requests. ___________________________________________________________________________= ______________________________________________ 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_ocheo4w473bh7m99bukoqvso1415904163936emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Ok

Envoy=E9 depuis mon Sony Xperia SP d'Orange

---- Steve Donovan a =E9crit ----
Agreed with one modification.  Instead of saying "The overlo= ad treatment should apply...", I changed it to "Overload abatemen= t treatment applies to...".

Steve

On 11/12/14, 4:15 PM, lionel.morand@orange.com wrote:

Following the discussion of thi= s morning, here my proposal for the section defining the OC-Report-Type.

The value "HOST_REPORT&quo= t; and "REALM_REPORT" can be reused when appropriate in other par= t of the document e.g. instead of saying "report of type host" et= c.

 

I take also into account the co= nclusion about removing repeated text about host-routed and realm-routed.

 

Regards,

 

Lionel

 

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

6.6.  OC-Report-Type AVP

 

  The OC-Report-Type AVP (= AVP code TBD5) is type of Enumerated.  The

   value of the AVP d= escribes what the overload report concerns.  The

   following values a= re defined in this this specification:

 

   HOST_REPORT 0

      =

     &= nbsp;The overload report is for a  host.  The overload treatment = should

      = apply to host-routed requests .

 

   REALM_REPORT 1

      =

     &= nbsp;The overload report is for a realm.  The overload treatment shoul= d

      = apply to realm-routed requests.

 

______________________________________________________________________=
___________________________________________________

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@ie=
tf.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_ocheo4w473bh7m99bukoqvso1415904163936emailandroidcom_-- From nobody Thu Nov 13 10:43: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 E686F1A9218 for ; Thu, 13 Nov 2014 10:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jA4IcOeLw4Ye for ; Thu, 13 Nov 2014 10:43:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F021A912A for ; Thu, 13 Nov 2014 10:43:51 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 695E62AC9B4; Thu, 13 Nov 2014 19:43:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 4CC65C805F; Thu, 13 Nov 2014 19:43: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.0210.002; Thu, 13 Nov 2014 19:43:49 +0100 From: To: "dime@ietf.org" , Steve Donovan Thread-Topic: [Dime] Proposed modification for section 3 Thread-Index: Ac/+6+YGPSr5BsS2Sdi4xeSCaeGHgwAe+WYAAAJ93mU= Date: Thu, 13 Nov 2014 18:43:48 +0000 Message-ID: <18064_1415904229_5464FBE5_18064_10007_1_hr0i1mgws2p40r11ehurphr9.1415904210868@email.android.com> References: <1271_1415846904_54641BF8_1271_11614_1_6B7134B31289DC4FAF731D844122B36E8D4B83@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5464F93C.3080907@usdonovans.com> In-Reply-To: <5464F93C.3080907@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_hr0i1mgws2p40r11ehurphr91415904210868emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.13.163622 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zImqth_21U9TlT_b7_hwLJlJQRg Subject: Re: [Dime] Proposed modification for section 3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:43:56 -0000 --_000_hr0i1mgws2p40r11ehurphr91415904210868emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Steve Donovan a =E9crit ---- Agreed. Changed with some wordsmithing: A report of type "HOST_REPORT" is sent to indicate the overload of a specific host, identified by the Origin-Host AVP of the message containing the OLR, for the application-id indicated in the transaction. When receiving an OLR of type "HOST_REPORT", a reacting node applies overload abatement treatment to host-routed requests (see definition in Section 2) sent for this application to the overloaded host. A report of type "REALM_REPORT" is sent to indicate the overload of a realm for the application-id indicated in the transaction. The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR. When receiving an OLR of type "REALM_REPORT", a reacting node applies overload abatement treatment to realm-routed requests (see definition in Section 2) sent for this application to the overloaded realm. Steve On 11/12/14, 4:48 PM, lionel.morand@orange.com wrote: According to the proposed modification of the definition of the Report-Type= AVP (see proposal for section 6.6), it would be easier to use the values d= efined for Report-type and make the link with host/realm-routed. Moreover, host-routed and realm-routed is defined at the beginning of the s= pec, so no need to repeat. Finally, I propose to avoid the use of "server" when not required. let me know if it is acceptable. Regards, Lionel ******************* OLD: A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of requests that are not host-routed as defined in the previous paragraph. NEW: A report of type "HOST_REPORT" is sent to indicate the overload of a spe= cific host, identified by the Origin-Host AVP of the message containing the OL= R, for the application-id indicated in the transaction. When receiving an O= LR of type "HOST_REPORT", a reacting node applies overload abatement to host-r= outed requests (see definition in section 2) sent for this application to a sp= ecific host that matches the Origin-Host AVP to which applies the received OLR. A report of type "REALM_REPORT" is sent to indicate the overload of a realm for the application-id. The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR. When receiving an OLR of type "REALM_REPORT", a reacting node applies overload abatement to realm-routed requests (see definition in section 2) sent for this application. ___________________________________________________________________________= ______________________________________________ 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_hr0i1mgws2p40r11ehurphr91415904210868emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Ok

Envoy=E9 depuis mon Sony Xperia SP d'Orange

---- Steve Donovan a =E9crit ----
Agreed.

Changed with some wordsmithing:

   A report of type "HOST_REPORT" is sent to indicate the ov=
erload of a
   specific host, identified by the Origin-Host AVP of the message
   containing the OLR, for the application-id indicated in the
   transaction.  When receiving an OLR of type "HOST_REPORT", a r=
eacting
   node applies overload abatement treatment to host-routed requests
   (see definition in Section 2) sent for this application to the
   overloaded host.

   A report of type "REALM_REPORT" is sent to indicate the overlo=
ad of a
   realm for the application-id indicated in the transaction.  The
   overloaded realm is identified by the Destination-Realm AVP of the
   message containing the OLR.  When receiving an OLR of type
   "REALM_REPORT", a reacting node applies overload abatement tre=
atment
   to realm-routed requests (see definition in Section 2) sent for this
   application to the overloaded realm.
Steve

On 11/12/14, 4:48 PM, lionel.morand@orange.com wrote:

According to the proposed modif= ication of the definition of the Report-Type AVP (see proposal for section = 6.6), it would be easier to use the values defined for Report-type and make= the link with host/realm-routed.

Moreover, host-routed and realm= -routed is defined at the beginning of the spec, so no need to repeat.

Finally, I propose to avoid the= use of "server" when not required.

 

let me know if it is acceptable= .

 

Regards,

 

Lionel

 

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

OLD:

 

   A report of type h= ost is sent to indicate the overload of a specific

   server for the app= lication-id indicated in the transaction.  When

   receiving an OLR o= f type host, a reacting node applies overload

   abatement to what = is referred to in this document as host-routed

   requests.  Th= is is the set of requests that the reacting node knows

   will be served by = a particular host, either due to the presence of a

   Destination-Host A= VP, or by some other local knowledge on the part of

   the reacting node.=   The reacting node applies overload abatement on

   those host-routed = requests which the reacting node knows will be

   served by the serv= er that matches the Origin-Host AVP of the received

   message that conta= ined the received OLR of type host.

 

   A report type of r= ealm is sent to indicate the overload of all

   servers in a realm= for the application-id.  When receiving an OLR of

   type realm, a reac= ting node applies overload abatement to what is

   referred to in thi= s document as realm-routed requests.  This is the

   set of requests th= at are not host-routed as defined in the previous

   paragraph.<= /p>

 

NEW:

 

   A report of type &= quot;HOST_REPORT" is sent to indicate the overload of a specific

   host, identified b= y the Origin-Host AVP of the message containing the OLR,

   for the applicatio= n-id indicated in the transaction. When receiving an OLR of

   type "HOST_RE= PORT", a reacting node applies overload abatement to host-routed

   requests (see= definition in section 2) sent for this application to a specific host that

   matches the O= rigin-Host AVP to which applies the received OLR.

 

   A report of type &= quot;REALM_REPORT" is sent to indicate the overload of

   a realm for t= he application-id. The overloaded realm is identified by the

   Destination-R= ealm AVP of the message containing the OLR.

   When receiving an = OLR of type "REALM_REPORT", a reacting node applies

   overload abat= ement to realm-routed requests (see definition in section 2)

   sent for this appl= ication.

 

______________________________________________________________________=
___________________________________________________

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@ie=
tf.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_hr0i1mgws2p40r11ehurphr91415904210868emailandroidcom_-- From nobody Thu Nov 13 10:49: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 AE9B51A924C for ; Thu, 13 Nov 2014 10:49:47 -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 5qP8AdmY7oPu for ; Thu, 13 Nov 2014 10:49:45 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553B01A9218 for ; Thu, 13 Nov 2014 10:49:45 -0800 (PST) Received: from dhcp-a69d.meeting.ietf.org ([31.133.166.157]:49669) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XozSc-0006LZ-V9; Thu, 13 Nov 2014 10:49:42 -0800 Message-ID: <5464FD42.8080709@usdonovans.com> Date: Thu, 13 Nov 2014 08:49:38 -1000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , Maria Cruz Bartolome , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AeLqEB5emk-oOfs31yFylyQgLAA Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:49:47 -0000 Ulrich, Please see inline. Steve On 11/12/14, 3:00 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Lionel, > > please see inline. > > Best regards > Ulrich > > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Wednesday, November 12, 2014 3:13 AM > To: MORAND Lionel IMT/OLN; Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > Subject: RE: [Dime] Updates to DOIC -05 > > Please see below. > Forgot to attached my comments :) > Regards, > Lionel > ------ > > Thank you, Ulrich. > > Lionel > > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 11 novembre 2014 13:47 À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; Steve Donovan; dime@ietf.org Objet : RE: [Dime] Updates to DOIC -05 > > Lionel, > I am very sorry. > > Some of my comments are immediate reactions to MCruz's comments. I do not repeat those here (assuming that people who can read MCruz's comments can also read my reaction, while people who cannot will not be able to understand my reaction anyway as it would be out of context). > Please find other comments below. > > Ulrich > > > Section 3, 4th paragraph from end, 2nd sentence: > Existing text: For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send requests to other destinations or via other agents. > Proposed text: For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send requests to other destinations or - if agent overload control is supported (Section A.2) - via other agents. > > [LM] Not sure to understand the need for support of Agent overload for that... > [Ulrich] In the absence of agent overload control it is always the server or realm that is overloaded and then it is not reasonable to attempt sending requests via other agents to the same overloaded server or realm. SRD> Agent overload isn't yet defined so we can't refer to it in this document. I also perfectly ok, in fact, it is expected behavior, for a reacting node for a host report to send realm routed requests to a different agent as the reacting node does not know which host will end up handling the request. > > Section 3, last paragraph, 3rd sentence from end: > Existing text: > For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unchanged. > Proposed text: For example, one or more Diameter agents that do or do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass OC-specific AVPs or unknown AVPs through unchanged. > > [LM] but actually, "OC-Specific AVPs" are unknown for a non-supporting agent. > [Ulrich] yes, but the exist text does not cover the case where a DOIC supporting agent exists between a given pair of reporting and reacting nodes, which passes OC-specific AVPs (although not unknown) through unchanged. SRD> I disagree with the change. We have already identified cases where a DOIC agent can change the OC-specific AVPs. > > Section 3.2, 3rd paragraph last sentence: > Existing text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. > Proposed text: This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting node in the path of the request. > > [LM] I may be too tired, but I cannot see the proposed change. > [Ulrich] That's why I like revision marking in word documents. Try again. SRD> This is addressed in a separate email. > > Section 3.2, 2nd paragraph from end, 2nd sentence: > Existing text: In this case, the agent updates the OC-Supported-Feature AVP to reflect the mixture of the two sets of supported features. > Proposed text: In this case, the agent can replace the OC-Supported-Features AVP (which indicates the features supported by the downstream reacting node) with its own OC-Supported-Feature AVP (which indicates the features supported by the agent). By doing so, the agent takes the role of a reporting node (reporting towards the downstream reacting node) and at the same time takes the role of a reacting node (reacting on OLRs received from upstream reporting nodes). > > [LM] will be discussed in a separate mail. SRD> We discussed this is the working group meeting this week. The text will be updated to indicate that agents can modify the OC-Supported-Features AVP and, if it does so, needs to make sure that doing so doesn't break anything. The actual text will be better but this is the basic concept. > > Section 4.1.3, 1st paragraph, 1st sentence: > Existing text: Diameter agents that support DOIC SHOULD ensure that all messages have the OC-Supporting-Features AVP. > Proposed text: Diameter agents that support DOIC SHOULD ensure that all request messages have the OC-Supported-Features AVP. > > [LM] ok SRD> I disagree with the change. Diameter agents can also become reporting node in the case that a server doesn't support DOIC. In this case the agent will insert OC-Supported-Features in answer messages in the same way that a reporting node does. The text needs to capture the point that the agent must not include the OC-Supported-Features AVP in answer messages for transactions where the request did not contain the OC-Supported-Features AVP. > > Section 4.1.3, 1st paragraph, 2nd sentence: > Existing text: If a message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. > Proposed text: If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. > > [LM] ok SRD> I disagree with the change for the same reason as the previous comment. > > Section 4.1.3, 3rd paragraph, 1st sentence: > Existing text: If the message already has the OC-Supported-Features AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect a mixed set of DOIC features. > Proposed text: If the request message already has the OC-Supported-Features AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect the agent's set of supported DOIC features. > > [LM] ok SRD> I disagree with the change. See comment earlier based on discussions in the working group meeting. > > Section 4.1.3, 5th paragraph, 1st sentence: > Existing text: An agent MAY modify the OC-Supported-Features AVP carried in answer messages. > Proposed text: An agent MAY replace the OC-Supported-Features AVP carried in answer messages (which indicates the features supported/selected by the upstream reporting node) with its own OC-Supported-Feature AVP (which indicates the features supported/selected by the agent). > > [LM] discussed in a separate mail. SRD> See above. > > Section 4.2.3, 13th paragraph, 2nd sentence: > Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. > Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies. > > [LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS. SRD> I'm ok with Ulrich's change. > > Section 6.5, 1st paragraph, 5th sentence Existing text: Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. > Proposed text: Validity duration with values above 86400000 (i.e.; 24 hours) MUST NOT be used. SRD> We agreed in the working group meeting that we will not have an upper limit, so the sentence with this bug will be removed from the document. > > > > > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Monday, November 10, 2014 5:49 PM > To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org; Wiehe, Ulrich (NSN - DE/Munich) > Subject: Re: [Dime] Updates to DOIC -05 > > Hi Ulrich and María Cruz, > > Please stop commenting through attached documents, requested several times and explained again yesterday by Ben. Some people may not be able to read at all the attached documents and it makes impossible parsing mechanism in the mailing list and in the archives. > > Please write your comments directly in the email. > > Thank you. > > lionel > > Envoyé depuis mon Sony Xperia SP d'Orange > > ---- Wiehe, Ulrich (NSN - DE/Munich) a écrit ---- > > > Sreve, MCruz, all, > > please find more comments attached. > > Best regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome > Sent: Sunday, November 09, 2014 2:17 AM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Updates to DOIC -05 > > Steve, all, > > See some comments included in attached doc. > Best regards > /MCruz > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: lunes, 03 de noviembre de 2014 15:36 > To: dime@ietf.org > Subject: [Dime] Updates to DOIC -05 > > All, > > I have done another end-to-end read of the DOIC specification, focusing on wording, consistency and removing any remaining redundancy in the document. > > I have pushed the changes into github. > > I have attached the diff to this email. > > Regards, > > Steve > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Thu Nov 13 16: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 D56531A0027 for ; Thu, 13 Nov 2014 16:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jGPQJkk_T7CK for ; Thu, 13 Nov 2014 16:05:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145B71A001C for ; Thu, 13 Nov 2014 16:05:25 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 414D73B47DB; Fri, 14 Nov 2014 01:05:23 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 220103840EB; Fri, 14 Nov 2014 01:05:23 +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.0210.002; Fri, 14 Nov 2014 01:05:22 +0100 From: To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP/3KTkNV3pmVYOkizkr7WDwwqBZxfPVTw Date: Fri, 14 Nov 2014 00:05:22 +0000 Message-ID: <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> In-Reply-To: <5464FD42.8080709@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.6] 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.10.23.30920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cuZGYwUE1ld3RXxvduh2E7oOfGs Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 00:05:30 -0000 > Section 4.2.3, 13th paragraph, 2nd sentence: > Existing text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the OLR applies. > Proposed text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the sent OLR applies. > > [LM] I would say that the reporting node will not remember the previously= sent OLR, but will take care that there is an active OCS. SRD> I'm ok with Ulrich's change. [LM] and this is incorrect but not fundamental. The reporting node does not= have to "remember" a previously sent OLR. What it will do is to refer to e= xisting OCS to know that throttling should not be applied. An OCS is a cons= equence of an sent OLR but it is not an OLR itself. But not fundamental her= e. Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: jeudi 13 novembre 2014 19:50 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich); MORAND Lionel IMT/OLN; Maria Cruz = Bartolome; dime@ietf.org Objet=A0: Re: [Dime] Updates to DOIC -05 Ulrich, Please see inline. Steve On 11/12/14, 3:00 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Lionel, > > please see inline. > > Best regards > Ulrich > > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Wednesday, November 12, 2014 3:13 AM > To: MORAND Lionel IMT/OLN; Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz=20 > Bartolome; Steve Donovan; dime@ietf.org > Subject: RE: [Dime] Updates to DOIC -05 > > Please see below. > Forgot to attached my comments :) > Regards, > Lionel > ------ > > Thank you, Ulrich. > > Lionel > > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : mardi 11 novembre 2014 13:47 =C0 : MORAND Lionel IMT/OLN; Mari= a=20 > Cruz Bartolome; Steve Donovan; dime@ietf.org Objet : RE: [Dime]=20 > Updates to DOIC -05 > > Lionel, > I am very sorry. > > Some of my comments are immediate reactions to MCruz's comments. I do not= repeat those here (assuming that people who can read MCruz's comments can = also read my reaction, while people who cannot will not be able to understa= nd my reaction anyway as it would be out of context). > Please find other comments below. > > Ulrich > > > Section 3, 4th paragraph from end, 2nd sentence: > Existing text: For example, a single Diameter node may be overloaded, in = which case reacting nodes may reasonably attempt to send requests to other = destinations or via other agents. > Proposed text: For example, a single Diameter node may be overloaded, in = which case reacting nodes may reasonably attempt to send requests to other = destinations or - if agent overload control is supported (Section A.2) - vi= a other agents. > > [LM] Not sure to understand the need for support of Agent overload for th= at... > [Ulrich] In the absence of agent overload control it is always the server= or realm that is overloaded and then it is not reasonable to attempt sendi= ng requests via other agents to the same overloaded server or realm. SRD> Agent overload isn't yet defined so we can't refer to it in this document. I also perfectly ok, in fact, it is expected behavior, for a rea= cting node for a host report to send realm routed requests to a different a= gent as the reacting node does not know which host will end up handling the= request. > > Section 3, last paragraph, 3rd sentence from end: > Existing text: > For example, one or more Diameter agents that do not support DOIC may exi= st between a given pair of reporting and reacting nodes, as long as those a= gents pass unknown AVPs through unchanged. > Proposed text: For example, one or more Diameter agents that do or do not= support DOIC may exist between a given pair of reporting and reacting node= s, as long as those agents pass OC-specific AVPs or unknown AVPs through un= changed. > > [LM] but actually, "OC-Specific AVPs" are unknown for a non-supporting ag= ent. > [Ulrich] yes, but the exist text does not cover the case where a DOIC sup= porting agent exists between a given pair of reporting and reacting nodes, = which passes OC-specific AVPs (although not unknown) through unchanged. SRD> I disagree with the change. We have already identified cases where a DOIC agent can change the OC-specific AVPs. > > Section 3.2, 3rd paragraph last sentence: > Existing text: This ensures that there is at least one commonly supported= overload abatement algorithm between the reporting node and the reacting n= odes in the path of the request. > Proposed text: This ensures that there is at least one commonly supported= overload abatement algorithm between the reporting node and the reacting n= ode in the path of the request. > > [LM] I may be too tired, but I cannot see the proposed change. > [Ulrich] That's why I like revision marking in word documents. Try again. SRD> This is addressed in a separate email. > > Section 3.2, 2nd paragraph from end, 2nd sentence: > Existing text: In this case, the agent updates the OC-Supported-Feature A= VP to reflect the mixture of the two sets of supported features. > Proposed text: In this case, the agent can replace the OC-Supported-Featu= res AVP (which indicates the features supported by the downstream reacting = node) with its own OC-Supported-Feature AVP (which indicates the features s= upported by the agent). By doing so, the agent takes the role of a reportin= g node (reporting towards the downstream reacting node) and at the same tim= e takes the role of a reacting node (reacting on OLRs received from upstrea= m reporting nodes). > > [LM] will be discussed in a separate mail. SRD> We discussed this is the working group meeting this week. The text will be updated to indicate that agents can modify the OC-Supported-Feature= s AVP and, if it does so, needs to make sure that doing so doesn't break an= ything. The actual text will be better but this is the basic concept. > > Section 4.1.3, 1st paragraph, 1st sentence: > Existing text: Diameter agents that support DOIC SHOULD ensure that all m= essages have the OC-Supporting-Features AVP. > Proposed text: Diameter agents that support DOIC SHOULD ensure that all r= equest messages have the OC-Supported-Features AVP. > > [LM] ok SRD> I disagree with the change. Diameter agents can also become reporting node in the case that a server doesn't support DOIC. In this cas= e the agent will insert OC-Supported-Features in answer messages in the sam= e way that a reporting node does. The text needs to capture the point that= the agent must not include the OC-Supported-Features AVP in answer message= s for transactions where the request did not contain the OC-Supported-Featu= res AVP. > > Section 4.1.3, 1st paragraph, 2nd sentence: > Existing text: If a message handled by the DOIC agent does not include th= e OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. > Proposed text: If a request message handled by the DOIC agent does not in= clude the OC-Supported-Features AVP then the DOIC agent SHOULD insert the A= VP. > > [LM] ok SRD> I disagree with the change for the same reason as the previous comment. > > Section 4.1.3, 3rd paragraph, 1st sentence: > Existing text: If the message already has the OC-Supported-Features AVP t= hen the agent either leaves it unchanged in the relayed message or modifies= it to reflect a mixed set of DOIC features. > Proposed text: If the request message already has the OC-Supported-Featur= es AVP then the agent either leaves it unchanged in the relayed message or = modifies it to reflect the agent's set of supported DOIC features. > > [LM] ok SRD> I disagree with the change. See comment earlier based on discussions in the working group meeting. > > Section 4.1.3, 5th paragraph, 1st sentence: > Existing text: An agent MAY modify the OC-Supported-Features AVP carried = in answer messages. > Proposed text: An agent MAY replace the OC-Supported-Features AVP carried= in answer messages (which indicates the features supported/selected by the= upstream reporting node) with its own OC-Supported-Feature AVP (which indi= cates the features supported/selected by the agent). > > [LM] discussed in a separate mail. SRD> See above. > > Section 4.2.3, 13th paragraph, 2nd sentence: > Existing text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the OLR applies. > Proposed text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the sent OLR applies. > > [LM] I would say that the reporting node will not remember the previously= sent OLR, but will take care that there is an active OCS. SRD> I'm ok with Ulrich's change. > > Section 6.5, 1st paragraph, 5th sentence Existing text: Validity duration= with values above 86400 (i.e.; 24 hours) MUST NOT be used. > Proposed text: Validity duration with values above 86400000 (i.e.; 24 hou= rs) MUST NOT be used. SRD> We agreed in the working group meeting that we will not have an upper limit, so the sentence with this bug will be removed from the documen= t. > > > > > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Monday, November 10, 2014 5:49 PM > To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org; Wiehe, Ulrich=20 > (NSN - DE/Munich) > Subject: Re: [Dime] Updates to DOIC -05 > > Hi Ulrich and Mar=EDa Cruz, > > Please stop commenting through attached documents, requested several time= s and explained again yesterday by Ben. Some people may not be able to read= at all the attached documents and it makes impossible parsing mechanism in= the mailing list and in the archives. > > Please write your comments directly in the email. > > Thank you. > > lionel > > Envoy=E9 depuis mon Sony Xperia SP d'Orange > > ---- Wiehe, Ulrich (NSN - DE/Munich) a =E9crit ---- > > > Sreve, MCruz, all, > > please find more comments attached. > > Best regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz=20 > Bartolome > Sent: Sunday, November 09, 2014 2:17 AM > To: Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Updates to DOIC -05 > > Steve, all, > > See some comments included in attached doc. > Best regards > /MCruz > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: lunes, 03 de noviembre de 2014 15:36 > To: dime@ietf.org > Subject: [Dime] Updates to DOIC -05 > > All, > > I have done another end-to-end read of the DOIC specification, focusing o= n wording, consistency and removing any remaining redundancy in the documen= t. > > I have pushed the changes into github. > > I have attached the diff to this email. > > Regards, > > Steve > > ______________________________________________________________________ > ___________________________________________________ > > 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. > > > ______________________________________________________________________ > ___________________________________________________ > > 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 > > ______________________________________________________________________ > ___________________________________________________ > > 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. > > 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. > > ___________________________________________________________________________= ______________________________________________ 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 Thu Nov 13 16:07: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 D0BCC1A0009 for ; Thu, 13 Nov 2014 16:07:12 -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 8KFlqDkPpMQB for ; Thu, 13 Nov 2014 16:07:01 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023E81A0052 for ; Thu, 13 Nov 2014 16:07:01 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so17934751wgh.25 for ; Thu, 13 Nov 2014 16:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QRYYX2+5oJACkoXOn4+A93MfA91FBjI8UNHnTxfAgwA=; b=pk+JGC1JeBMrHCjXkn9Q7n+LlLR/S/GVWUqCsAYZIauF4YPttdcjDGv9EHbSVyResJ LMlLS3IDWABGwoy541aSfoNYlaqe5kgARLisotwW5PUzgr0+g0iLAN1i+zhoV1yw5bBk JmFG3KmGmRY2x/goey0uB24o3yGAlq/VARITL4cyD7sjDujVRKWIoXXqdyioqBV7gL3U JNIW6mL/9H2/f9Z4CDyw/zoG+HjfHfoBUgJjXul3tm2SZXOR7gDyZr6iHXfCNa8SZnek fjIpZB3GEhUod1arUMvmRS6x4L/mUywTg5QbM1QoiQvAfBzPsGn7PGe5gJ5oLWZ3qtEC KaFg== X-Received: by 10.194.93.168 with SMTP id cv8mr8873496wjb.114.1415923619283; Thu, 13 Nov 2014 16:06:59 -0800 (PST) Received: from [10.16.11.226] ([216.31.219.19]) by mx.google.com with ESMTPSA id mc10sm505740wic.24.2014.11.13.16.06.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 16:06:58 -0800 (PST) Message-ID: <5465479F.5080001@gmail.com> Date: Fri, 14 Nov 2014 02:06:55 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , Maria Cruz Bartolome , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> In-Reply-To: <5464FD42.8080709@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/S8Uih7mOIRoKGB9c3du1UkjgKy4 Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 00:07:13 -0000 Inline.. 11/13/2014 8:49 PM, Steve Donovan kirjoitti: > Ulrich, > > Please see inline. > > Steve > > On 11/12/14, 3:00 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Lionel, >> >> please see inline. >> >> Best regards >> Ulrich >> >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: Wednesday, November 12, 2014 3:13 AM >> To: MORAND Lionel IMT/OLN; Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz >> Bartolome; Steve Donovan; dime@ietf.org >> Subject: RE: [Dime] Updates to DOIC -05 >> >> Please see below. >> Forgot to attached my comments :) >> Regards, >> Lionel >> ------ >> >> Thank you, Ulrich. >> >> Lionel >> >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >> Envoyé : mardi 11 novembre 2014 13:47 À : MORAND Lionel IMT/OLN; Maria >> Cruz Bartolome; Steve Donovan; dime@ietf.org Objet : RE: [Dime] >> Updates to DOIC -05 >> >> Lionel, >> I am very sorry. >> >> Some of my comments are immediate reactions to MCruz's comments. I do >> not repeat those here (assuming that people who can read MCruz's >> comments can also read my reaction, while people who cannot will not >> be able to understand my reaction anyway as it would be out of context). >> Please find other comments below. >> >> Ulrich >> >> >> Section 3, 4th paragraph from end, 2nd sentence: >> Existing text: For example, a single Diameter node may be overloaded, >> in which case reacting nodes may reasonably attempt to send requests >> to other destinations or via other agents. >> Proposed text: For example, a single Diameter node may be overloaded, >> in which case reacting nodes may reasonably attempt to send requests >> to other destinations or - if agent overload control is supported >> (Section A.2) - via other agents. >> >> [LM] Not sure to understand the need for support of Agent overload for >> that... >> [Ulrich] In the absence of agent overload control it is always the >> server or realm that is overloaded and then it is not reasonable to >> attempt sending requests via other agents to the same overloaded >> server or realm. > SRD> Agent overload isn't yet defined so we can't refer to it in this > document. I also perfectly ok, in fact, it is expected behavior, for a > reacting node for a host report to send realm routed requests to a > different agent as the reacting node does not know which host will end > up handling the request. >> >> Section 3, last paragraph, 3rd sentence from end: >> Existing text: >> For example, one or more Diameter agents that do not support DOIC may >> exist between a given pair of reporting and reacting nodes, as long as >> those agents pass unknown AVPs through unchanged. >> Proposed text: For example, one or more Diameter agents that do or do >> not support DOIC may exist between a given pair of reporting and >> reacting nodes, as long as those agents pass OC-specific AVPs or >> unknown AVPs through unchanged. >> >> [LM] but actually, "OC-Specific AVPs" are unknown for a non-supporting >> agent. >> [Ulrich] yes, but the exist text does not cover the case where a DOIC >> supporting agent exists between a given pair of reporting and reacting >> nodes, which passes OC-specific AVPs (although not unknown) through >> unchanged. > SRD> I disagree with the change. We have already identified cases where > a DOIC agent can change the OC-specific AVPs. [JiK] Agree with Steve here. And since an agent that may fiddle with non-routing AVPs is typically (or actually) a proxy, it can do whatever it see best as long as stuff does not break. >> >> Section 3.2, 3rd paragraph last sentence: >> Existing text: This ensures that there is at least one commonly >> supported overload abatement algorithm between the reporting node and >> the reacting nodes in the path of the request. >> Proposed text: This ensures that there is at least one commonly >> supported overload abatement algorithm between the reporting node and >> the reacting node in the path of the request. >> >> [LM] I may be too tired, but I cannot see the proposed change. >> [Ulrich] That's why I like revision marking in word documents. Try again. [JiK] ;-) > SRD> This is addressed in a separate email. [JiK] I see no reason to change the text. I do kind of agree what Ulrich says (in the separate mail), however, all those funny combinations are manageable by a proxy agent if it so wished (since it can manipulate more of less anything that goes through it). But still I see no reason to change the text. >> Section 3.2, 2nd paragraph from end, 2nd sentence: >> Existing text: In this case, the agent updates the >> OC-Supported-Feature AVP to reflect the mixture of the two sets of >> supported features. >> Proposed text: In this case, the agent can replace the >> OC-Supported-Features AVP (which indicates the features supported by >> the downstream reacting node) with its own OC-Supported-Feature AVP >> (which indicates the features supported by the agent). By doing so, >> the agent takes the role of a reporting node (reporting towards the >> downstream reacting node) and at the same time takes the role of a >> reacting node (reacting on OLRs received from upstream reporting nodes). >> >> [LM] will be discussed in a separate mail. > SRD> We discussed this is the working group meeting this week. The text > will be updated to indicate that agents can modify the > OC-Supported-Features AVP and, if it does so, needs to make sure that > doing so doesn't break anything. The actual text will be better but > this is the basic concept. >> >> Section 4.1.3, 1st paragraph, 1st sentence: >> Existing text: Diameter agents that support DOIC SHOULD ensure that >> all messages have the OC-Supporting-Features AVP. >> Proposed text: Diameter agents that support DOIC SHOULD ensure that >> all request messages have the OC-Supported-Features AVP. >> >> [LM] ok > SRD> I disagree with the change. Diameter agents can also become > reporting node in the case that a server doesn't support DOIC. In this > case the agent will insert OC-Supported-Features in answer messages in > the same way that a reporting node does. The text needs to capture the > point that the agent must not include the OC-Supported-Features AVP in > answer messages for transactions where the request did not contain the > OC-Supported-Features AVP. [JiK] Agree with Steve here. >> >> Section 4.1.3, 1st paragraph, 2nd sentence: >> Existing text: If a message handled by the DOIC agent does not include >> the OC-Supported-Features AVP then the DOIC agent SHOULD insert the AVP. >> Proposed text: If a request message handled by the DOIC agent does not >> include the OC-Supported-Features AVP then the DOIC agent SHOULD >> insert the AVP. >> >> [LM] ok > SRD> I disagree with the change for the same reason as the previous > comment. [JiK] Agree with Steve here. >> >> Section 4.1.3, 3rd paragraph, 1st sentence: >> Existing text: If the message already has the OC-Supported-Features >> AVP then the agent either leaves it unchanged in the relayed message >> or modifies it to reflect a mixed set of DOIC features. >> Proposed text: If the request message already has the >> OC-Supported-Features AVP then the agent either leaves it unchanged in >> the relayed message or modifies it to reflect the agent's set of >> supported DOIC features. >> >> [LM] ok > SRD> I disagree with the change. See comment earlier based on > discussions in the working group meeting. [JiK] Agree with Steve again.. >> >> Section 4.1.3, 5th paragraph, 1st sentence: >> Existing text: An agent MAY modify the OC-Supported-Features AVP >> carried in answer messages. >> Proposed text: An agent MAY replace the OC-Supported-Features AVP >> carried in answer messages (which indicates the features >> supported/selected by the upstream reporting node) with its own >> OC-Supported-Feature AVP (which indicates the features >> supported/selected by the agent). >> >> [LM] discussed in a separate mail. > SRD> See above. >> >> Section 4.2.3, 13th paragraph, 2nd sentence: >> Existing text: Therefore, the reporting node SHOULD NOT apply >> throttling to the set of messages to which the OLR applies. >> Proposed text: Therefore, the reporting node SHOULD NOT apply >> throttling to the set of messages to which the sent OLR applies. >> >> [LM] I would say that the reporting node will not remember the >> previously sent OLR, but will take care that there is an active OCS. > SRD> I'm ok with Ulrich's change. >> >> Section 6.5, 1st paragraph, 5th sentence Existing text: Validity >> duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. >> Proposed text: Validity duration with values above 86400000 (i.e.; 24 >> hours) MUST NOT be used. > SRD> We agreed in the working group meeting that we will not have an > upper limit, so the sentence with this bug will be removed from the > document. - Jouni >> >> >> >> >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: Monday, November 10, 2014 5:49 PM >> To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org; Wiehe, Ulrich >> (NSN - DE/Munich) >> Subject: Re: [Dime] Updates to DOIC -05 >> >> Hi Ulrich and María Cruz, >> >> Please stop commenting through attached documents, requested several >> times and explained again yesterday by Ben. Some people may not be >> able to read at all the attached documents and it makes impossible >> parsing mechanism in the mailing list and in the archives. >> >> Please write your comments directly in the email. >> >> Thank you. >> >> lionel >> >> Envoyé depuis mon Sony Xperia SP d'Orange >> >> ---- Wiehe, Ulrich (NSN - DE/Munich) a écrit ---- >> >> >> Sreve, MCruz, all, >> >> please find more comments attached. >> >> Best regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz >> Bartolome >> Sent: Sunday, November 09, 2014 2:17 AM >> To: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] Updates to DOIC -05 >> >> Steve, all, >> >> See some comments included in attached doc. >> Best regards >> /MCruz >> >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: lunes, 03 de noviembre de 2014 15:36 >> To: dime@ietf.org >> Subject: [Dime] Updates to DOIC -05 >> >> All, >> >> I have done another end-to-end read of the DOIC specification, >> focusing on wording, consistency and removing any remaining redundancy >> in the document. >> >> I have pushed the changes into github. >> >> I have attached the diff to this email. >> >> Regards, >> >> Steve >> >> _________________________________________________________________________________________________________________________ >> >> >> 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 From nobody Thu Nov 13 17: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 A35131A00B8 for ; Thu, 13 Nov 2014 17:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kFgd-x_bH5WL for ; Thu, 13 Nov 2014 17:36:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBA21A1AB9 for ; Thu, 13 Nov 2014 17:36:33 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BF4F22AC090; Fri, 14 Nov 2014 02:36:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id A3AE5384078; Fri, 14 Nov 2014 02:36:31 +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.0210.002; Fri, 14 Nov 2014 02:36:31 +0100 From: To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP/qcGkNV3pmVYOkizkr7WDwwqBZxeLxsAgACHmYCAAKIKAA== Date: Fri, 14 Nov 2014 01:36:30 +0000 Message-ID: <9939_1415928991_54655C9F_9939_2813_1_6B7134B31289DC4FAF731D844122B36E8DC3AF@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5463A7BB.9020804@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815228FEB@DEMUMBX014.nsn-intra.net> <5464E219.7070304@usdonovans.com> In-Reply-To: <5464E219.7070304@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.6] 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.11.14.2720 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3e48BStSqvkUjzlWS46bTeZ0Vbs Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 01:36:39 -0000 Initially, I had the same issue with one or multiple reacting nodes. But after further discussions and based on the example given below, I agree= with Steve's proposal i.e. "reacting node(s)". -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: jeudi 13 novembre 2014 17:54 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich); MORAND Lionel IMT/OLN; Maria Cruz = Bartolome; dime@ietf.org Objet=A0: Re: [Dime] Updates to DOIC -05 Ulrich, The basic scenario, when there are agents between Diameter Clients and Diam= eter Servers, for handling of host reports requires two separate Diameter n= odes to act on the host report. The client in your first case is responsible for applying abatement treatme= nt to host routed requests. The agent is responsible for applying abatement treatment to realm routed r= equests. As such, there can be more than one reacting node for a single overload rep= ort. Steve On 11/12/14, 10:48 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I strongly disagree. > > In the path of a request there are allways as many reacting nodes as repo= rting nodes. > > Examples are: > 1. one reporting node, one reacting node > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is reacting node (reacting on host-type OLRs received from S), A (no=20 > matter whether or not it supports DOIC) is neither reacting node nor=20 > reporting node, S is reporting node C and S must have at least one=20 > commonly supported algorithm. > > 2. one reporting node, one reacting node > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is neither reacting node nor reporting node, A is reacting node (on=20 > behalf of C), S is reporting node A and S must have at least one=20 > commonly supported algorithm. > > 3. two reporting nodes, two reacting nodes > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is reacting node (reacting on realm-type OLRs received from A), A is=20 > reporting node (reporting realm-type OLRs to C) and reacting node=20 > (reacting on host-type OLRs received from S) S is reporting node C and=20 > A must have at least one commonly supported algorithm, and A and S must h= ave at least one commonly supported algorithm. No need for C, A, and S to h= ave at least one commonly supported algorithm. > > What we DO NOT have is: > 4. one reporting node, two reacting nodes > +---+ +---+ +---+ > | C |-------| A |------| S | > +---+ +---+ +---+ > C is reacting node, > A is reacting node but not reporting node, S is reporting node If we=20 > had this then yes There would be the need for C, A, and S to have at=20 > least one commonly supported algorithm, and There would be the need to=20 > modify the algorithm negotiation mechanism: e.g. when C supports loss, A = supports loss and rate, S supports loss and rate, then A would not be allow= ed to advertize rate and loss to S but only loss. > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, November 12, 2014 7:32 PM > To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com;=20 > Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Updates to DOIC -05 > > The suggestion is from "reacting nodes" to "reacting node". > > I disagree with this change, as there can be more than one reacting=20 > node for a single report. > > I would agree to change it to "reacting node(s)". > > Steve > > > Section 3.2, 3rd paragraph last sentence: > Existing text: This ensures that there is at least one commonly supported= overload abatement algorithm between the reporting node and the reacting n= odes in the path of the request. > Proposed text: This ensures that there is at least one commonly supported= overload abatement algorithm between the reporting node and the reacting n= ode in the path of the request. > > [LM] I may be too tired, but I cannot see the proposed change. > [Ulrich] That's why I like revision marking in word documents. Try again. > > > > ___________________________________________________________________________= ______________________________________________ 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 Nov 14 15:50: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 4A55D1ACD2D; Fri, 14 Nov 2014 15:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Op7hYh4tQ4; Fri, 14 Nov 2014 15:49:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 456A21AD030; Fri, 14 Nov 2014 15:49:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 89B89181D18; Fri, 14 Nov 2014 15:48:55 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141114234855.89B89181D18@rfc-editor.org> Date: Fri, 14 Nov 2014 15:48:55 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_58htImQnQSgpwDED0xyvt0Mq3o Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] BCP 193, RFC 7423 on Diameter Applications Design Guidelines X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 23:50:05 -0000 A new Request for Comments is now available in online RFC libraries. BCP 193 RFC 7423 Title: Diameter Applications Design Guidelines Author: L. Morand, Ed., V. Fajardo, H. Tschofenig Status: Best Current Practice Stream: IETF Date: November 2014 Mailbox: lionel.morand@orange.com, vf0213@gmail.com, Hannes.Tschofenig@gmx.net Pages: 29 Characters: 67829 See Also: BCP 193 I-D Tag: draft-ietf-dime-app-design-guide-28.txt URL: https://www.rfc-editor.org/rfc/rfc7423.txt The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions. This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Nov 14 17:58: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 815631A0023 for ; Fri, 14 Nov 2014 17:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, 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 5611qePy7JAS for ; Fri, 14 Nov 2014 17:58:08 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDD51A014C for ; Fri, 14 Nov 2014 17:58:08 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id et14so3859606pad.3 for ; Fri, 14 Nov 2014 17:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JugzCDMfTV/YMzwxlA1bPbBxESpMC4kBpjyn3iWmnj0=; b=afDsLu4+/HaO9FQUaHJt2hU0vbzWSrFinnUMjQ4fkcC7oUguWLFU8FRDRxLr6ONJ2N HxIJPqGvoa9htToao98A2B2bqfDQ081aTrskyV4SrJ1YKsBbQaQC4Vun5InBiA8v3tGF 9Uo3wFo4xMUDJUo8KvwHBh7RIxrkYMZvtFyrUmxWf0j087cKt7IoE28zU5qFQb6glsZb FacyGsweiwgda7EEN30Y87fMMtnervYMRog5W/9uhLucMu2oLJFMhgVNHeynGs5gJYcf +4RwyT10RCZ8O2QGF4SHmv9T7j400Ogycyit9P8DZzRjL6DJy8REcUlQR1f0w8BWGMs+ Ls1A== X-Received: by 10.67.4.167 with SMTP id cf7mr14177097pad.52.1416016687146; Fri, 14 Nov 2014 17:58:07 -0800 (PST) Received: from [10.16.11.206] ([216.31.219.19]) by mx.google.com with ESMTPSA id s7sm28692828pdi.72.2014.11.14.17.58.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 17:58:06 -0800 (PST) Message-ID: <5466B330.3060606@gmail.com> Date: Sat, 15 Nov 2014 03:58:08 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: dime@ietf.org References: <20141114234855.89B89181D18@rfc-editor.org> In-Reply-To: <20141114234855.89B89181D18@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/scsY9r-Z8cO7E2nPTg3u13NczKo Subject: Re: [Dime] BCP 193, RFC 7423 on Diameter Applications Design Guidelines X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 01:58:09 -0000 Congratulations to the authors (finally) completing this important work! - Jouni 11/15/2014 1:48 AM, rfc-editor@rfc-editor.org kirjoitti: > A new Request for Comments is now available in online RFC libraries. > > BCP 193 > RFC 7423 > > Title: Diameter Applications Design Guidelines > Author: L. Morand, Ed., > V. Fajardo, > H. Tschofenig > Status: Best Current Practice > Stream: IETF > Date: November 2014 > Mailbox: lionel.morand@orange.com, > vf0213@gmail.com, > Hannes.Tschofenig@gmx.net > Pages: 29 > Characters: 67829 > See Also: BCP 193 > > I-D Tag: draft-ietf-dime-app-design-guide-28.txt > > URL: https://www.rfc-editor.org/rfc/rfc7423.txt > > The Diameter base protocol provides facilities for protocol > extensibility enabling the definition of new Diameter applications or > modification of existing applications. This document is a companion > document to the Diameter base protocol that further explains and > clarifies the rules to extend Diameter. Furthermore, this document > provides guidelines to Diameter application designers reusing/ > defining Diameter applications or creating generic Diameter > extensions. > > This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. > > > BCP: This document specifies an Internet Best Current Practices for the > Internet Community, and requests discussion and suggestions for > improvements. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Nov 14 18:12: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 B46D11A0545 for ; Fri, 14 Nov 2014 18:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZBIJBzocDAJw for ; Fri, 14 Nov 2014 18:12:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F3E1A024C for ; Fri, 14 Nov 2014 18:12:09 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CE5E522CDE8; Sat, 15 Nov 2014 03:12:07 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B27214C075; Sat, 15 Nov 2014 03:12:07 +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.0210.002; Sat, 15 Nov 2014 03:12:07 +0100 From: To: "dime@ietf.org" Thread-Topic: [Dime] BCP 193, RFC 7423 on Diameter Applications Design Guidelines Thread-Index: AQHQAGXyeC3z5Au+b0mMVd9Z6Y4Bbpxg7tCg Date: Sat, 15 Nov 2014 02:12:06 +0000 Message-ID: <4767_1416017527_5466B677_4767_8436_1_6B7134B31289DC4FAF731D844122B36E8E672D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20141114234855.89B89181D18@rfc-editor.org> In-Reply-To: <20141114234855.89B89181D18@rfc-editor.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.6] 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.11.14.125119 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lNE73jk6DTFG1w2WClOHdRSi5wo Cc: Hannes Tschofenig Subject: Re: [Dime] BCP 193, RFC 7423 on Diameter Applications Design Guidelines X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 02:12:12 -0000 Many Thanks to all the Dime working group (chairs, authors, AD, reviewers) = for the great work accomplished since the creation of the Diameter extensib= ility design team... in Feb 2008. I really think that this document will be helpful for the design of new app= lications/Diameter extensions, as it was the case for 3GPP in their recent = Diameter related protocol activities. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de rfc-editor@rfc-edi= tor.org Envoy=E9=A0: samedi 15 novembre 2014 00:49 =C0=A0: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc=A0: drafts-update-ref@iana.org; dime@ietf.org; rfc-editor@rfc-editor.org Objet=A0: [Dime] BCP 193, RFC 7423 on Diameter Applications Design Guidelin= es A new Request for Comments is now available in online RFC libraries. BCP 193=20=20=20=20=20=20=20=20 RFC 7423 Title: Diameter Applications Design Guidelines=20 Author: L. Morand, Ed., V. Fajardo, H. Tschofenig Status: Best Current Practice Stream: IETF Date: November 2014 Mailbox: lionel.morand@orange.com,=20 vf0213@gmail.com,=20 Hannes.Tschofenig@gmx.net Pages: 29 Characters: 67829 See Also: BCP 193 I-D Tag: draft-ietf-dime-app-design-guide-28.txt URL: https://www.rfc-editor.org/rfc/rfc7423.txt The Diameter base protocol provides facilities for protocol extensibility e= nabling the definition of new Diameter applications or modification of exis= ting applications. This document is a companion document to the Diameter b= ase protocol that further explains and clarifies the rules to extend Diamet= er. Furthermore, this document provides guidelines to Diameter application= designers reusing/ defining Diameter applications or creating generic Diam= eter extensions. This document is a product of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Int= ernet Community, and requests discussion and suggestions for improvements. = Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For dow= nloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ 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 Sun Nov 16 23:37: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 3148C1A0263 for ; Sun, 16 Nov 2014 23:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYxRKgEccLkq for ; Sun, 16 Nov 2014 23:37:11 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AF91A01A5 for ; Sun, 16 Nov 2014 23:37:10 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-00-5469a5a32698 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A5.63.04081.3A5A9645; Mon, 17 Nov 2014 08:37:08 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.211]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Mon, 17 Nov 2014 08:37:07 +0100 From: Maria Cruz Bartolome To: Ben Campbell Thread-Topic: [Dime] DOIC Requirements Analysis Thread-Index: AQHP+hdkYaHIAJGIfEKORBGRlKAhiZxUv+AAgAJDs/CABLwFgIAITmaw Date: Mon, 17 Nov 2014 07:37:07 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209863A4D@ESESSMB101.ericsson.se> References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> <545C7EA8.6070706@cisco.com> <087A34937E64E74E848732CFF8354B920985724A@ESESSMB101.ericsson.se> <4C8FAB4B-4111-4588-A2A7-D4135B30EAA0@nostrum.com> In-Reply-To: <4C8FAB4B-4111-4588-A2A7-D4135B30EAA0@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje6SpZkhBmu7uCyOPpawmN95mt1i bu8KNgdmjym/N7J6LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZ+1ctYyqYpVvRt2MLcwNj i04XIyeHhICJxKOX25ggbDGJC/fWs3UxcnEICRxhlOiauQbKWcIo8ejhH7AqNgE7iUunX4DZ IgJKEs+bt7KA2MwC3hJb2/rYQGxhAT2JF/vOsEPU6EvcuLuYGcJ2k3jUuxYsziKgKrHh6gQw m1fAV2Ll2ulQy1YxSXRcPwzWwClgL3H75m+woYxA530/tYYJYpm4xK0n86HOFpBYsuc8M4Qt KvHy8T9WCFtJYsX2S4xdjBxA9ZoS63fpQ7QqSkzpfgi1V1Di5MwnLBMYxWYhmToLoWMWko5Z SDoWMLKsYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMqINbfhvsYHz53PEQowAHoxIP74c5 mSFCrIllxZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExs4w1Nd02 R4fpX/IGX5s90d+vHHdgF1zJKPBiB6f7ud7UX1+26zrUf/i4YZ7jwhMXTzq6O2+vahf0Ss7e ulNjS6OiR0CvWpD3ZJPbbX7ZX3pFXp/y2/1iQZ2bWdB3v/k3K2xzDhv7LGbw2bXodTXXOlvL ibvMhD5ZpsTk8M6Zw8vjYZcdG6TEUpyRaKjFXFScCADMOui6iQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HjxItSZ9aiuquVZbyDjep3XfjZc Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 07:37:13 -0000 QmVuLCBhbGwsDQoNCklmIHdlIGZpbmFsbHkga2VlcCBSZXEgYW5hbHlzaXMgYXMgYSBzZXBhcmF0 ZSBpbmZvcm1hdGl2ZSBkcmFmdCwgSSB3b3VsZCBsaWtlIHRoYXQgeW91IGNvdWxkIGluY29ycG9y YXRlIGNvbW1lbnRzIEkgc2VudCwgYXMgbG9uZyBhcyB0aGV5IGFyZSBhZ3JlZWFibGUgYnkgeW91 Lg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0gDQpTZW50OiBtYXJ0ZXMs IDExIGRlIG5vdmllbWJyZSBkZSAyMDE0IDIwOjA0DQpUbzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWUN CkNjOiBCZW5vaXQgQ2xhaXNlOyBkaW1lQGlldGYub3JnIGxpc3QNClN1YmplY3Q6IFJlOiBbRGlt ZV0gRE9JQyBSZXF1aXJlbWVudHMgQW5hbHlzaXMNCg0KPiANCj4gT24gTm92IDgsIDIwMTQsIGF0 IDM6MTYgUE0sIE1hcmlhIENydXogQmFydG9sb21lIDxtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmlj c3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gRGVhciBCZW4sDQo+ICANCj4gU2VlIG15IGNvbW1lbnRz IGluc2VydGVkIGluIGF0dGFjaGVkIGRvYy4NCj4gVGhhbmtzDQo+IC9NQ3J1eg0KDQpbLi4uXQ0K DQpIaSwgcmVzcG9uZGluZyB0byBjb21tZW50cyBpbiB0ZXh0Og0KDQpSZXEgMjoNCg0KPiAiU2lu Y2Ug4oCcbG9hZOKAnSBpcyBub3QgY292ZXJlZCwgYXQgbGVhc3QgaXQgc2hvdWxkIGJlIHBhcnRs eSBjb21wbGlhbnQgYmVjYXVzZSBvZiB0aGlzIHJlYXNvbi4iDQoNCg0KSSBhZ3JlZSwgd2lsbCBm aXguDQoNClJlcSA1Og0KDQo+ICJGdXJ0aGVyIHN0dWR5PyBXaGF0IGZvcj8iDQoNCkkgZG9uJ3Qg dGhpbmsgd2UndmUgdGhvdWdodCB0aHJvdWdoIGR5bmFtaWMgZGlzY292ZXJ5IHVzZSBjYXNlcy4g SSBkb24ndCBlbnZpc2lvbiBhIHByb2JsZW0gaGVyZTsgSSBqdXN0IHRoaW5rIHdlIG5lZWQgdG8g dGhpbmsgaXQgdGhyb3VnaC4NCg0KUmVxIDY6DQoNCj4gIkJlaW5nIGEgU0hPVUxELCBpbiBteSBv cGluaW9uIERPSUMgaXMgY29tcGxpYW50LiINCg0KDQpJIGRpc2FncmVlLiBUaGUgZmFjdCB0aGF0 IGl0IGlzIGEgU0hPVUxEIGRvZXNuJ3QgZ2l2ZSB1cyBhIGZyZWUgcGFzcy4gSXQgbWVhbnMgdGhh dCBpZiB3ZSBkb24ndCBjb21wbHksIHdlIG5lZWQgdG8gYmUgYWJsZSB0byBkb2N1bWVudCB3aHku IFRoZSBkaWZmZXJlbmNlIGlzLCB3ZSBhcmUgbGVzcyBsaWtlbHkgdG8gaGF2ZSBwZW9wbGUgY29t cGxhaW4gYWJvdXQgbm90IGNvbXBseWluZyB3aXRoIGEgU0hPVUxELg0KDQoNCj4gIkNvbmZpZ3Vy YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBjb3ZlciBwdXJlIGltcGxlbWVudGF0aW9uIHNwZWNp ZmljIGlzc3Vlcy4NCg0KSSBkb24ndCBhZ3JlZSB0aGF0IGtub3dpbmcgd2hldGhlciBhIHBlZXIg c3VwcG9ydHMgdGhlIG1lY2hhbmlzbSBpcyBhIHB1cmUgaW1wbGVtZW50YXRpb24gaXNzdWUuIEkg dGhpbmsgaXQncyBhIHNlY3VyaXR5IGlzc3VlLiBJIGFsc28gZG9uJ3QgYmVsaWV2ZSBuZWVkaW5n IHRvIGtub3cgdGhhdCBjZXJ0YWluIGFnZW50cyBtYXkgaGF2ZSBkYW1hZ2VkIE9MUnMgaXMgYSBw dXJlIGltcGxlbWVudGF0aW9uIGlzc3VlLiAoQm90aCBiZWNhdXNlIHdlIGFsc28gaGF2ZSByZXF1 aXJlbWVudHMgdG8gd29yayB3aXRoIGFuZCBhY3Jvc3Mgbm9uLXN1cHBvcnRpbmcgbm9kZXMuKQ0K DQo+IHdpdGhvdXQgY29uZmlndXJhdGlvbuKAnQ0KPiANCj4gSSBkbyBub3QgdW5kZXJzdGFuZCB3 aGF0IGRvIHlvdSByZWZlciB0by4NCj4gDQo+IENvdWxkIHlvdSBleHBsYWluIHRoYXQ/DQoNClRo ZSBvbmx5IHdheSBhIG5vZGUgY2FuIHRlbGwgdGhhdCB0aGVyZSdzIGEgbm9uLXN1cHBvcnRpbmcg cGVlciBpbiB0aGUgcGF0aCBpcyB0byBoYXZlIGFuIGFkbWluaXN0cmF0b3IgdGVsbCBpdC4NCg0K DQpSZXEgODoNCg0KPiBbcmVwb3J0cyBzaG91bGQgYmVdIFJlcG9ydGluZyBub2Rlcz8NCg0KDQpZ ZXMsIHRoYXQncyBjb3JyZWN0Lg0KDQpSZXEgMTA6DQoNCj4gIFRoZSBjb25zdW1lciBpcyBhYmxl IHRvIGRldGVybWluZSB3aGVuIHRoZSBvdmVybG9hZCBjb25kaXRpb24gaW1wcm92ZXMgb3IgZW5k cywgYnV0IHdoZW4gdGhlIG5leHQgcmVxdWVzdCBjb21lcy4gSSBhZ3JlZSBhYm91dCB5b3VyIGRl c2NyaXB0aW9uIG9mIOKAnHN0YWxl4oCdIG92ZXJsb2FkIGluZm8uDQo+IEJ1dCB0aGVuLCBjb21w bGlhbmNlIGRlZ3JlZSBtYXkgYmUgc3ViamVjdCB0byBpbnRlcnByZXRhdGlvbi4NCj4gDQo+IEkg d291bGQgc2F5IHRoaXMgaXMgY29tcGxpYW50Lg0KDQpJIGxpc3RlZCBhIHZhbGlkIHVzZSBjYXNl IHdoZXJlIHRoZSBjb25zdW1lciBjYW5ub3QgdGVsbCB3aGVuIHRoZSBvdmVybG9hZCBjb25kaXRp b24gY2hhbmdlcywgZXhjZXB0IHRvIHdhaXQgZm9yIHRoZSBleHBpcmF0aW9uIG9mIHRoZSBPTFIu IFRodXMsIEkgc3RpbGwgY29uc2lkZXIgdGhpcyAicGFydGlhbGx5IGNvbXBsaWFudCIuDQoNCg0K UmVxIDEyOg0KDQo+IEkgdGhpbmsgRE9JQyBpcyBjb21wbGlhbnQuDQo+IA0KPiBUaGUgc29sdXRp b24gTVVTVCBsaW1pdCB0aGUgaW1wYWN0IG9mIGFuIG92ZXJsb2FkZWQgbm9kZSBpbiB0aGUgbmV0 d29yay4NCj4gDQo+ICANCj4gDQo+IEkgZG8gbm90IHRoaW5rIHdlIG5lZWQgbG9hZCBjb252ZXlh bmNlIHN1cHBvcnQgdG8gYmUgY29tcGxpYW50IHRvIHRoaXMgcmVxdWlyZW1lbnQuDQoNClRoZSBw b2ludCBvZiB0aGUgcmVxdWlyZW1lbnQgaXMgdG8gYXZvaWQgY2FzY2FkZWQgb3ZlcmxvYWQsIHdo ZXJlIG92ZXJsb2FkIGF0IG9uZSBub2RlIGluZHVjZXMgb3ZlcmxvYWQgYXQgb3RoZXJzLiBUaGUg d2hvbGUgcG9pbnQgaW4gcmVxdWlyaW5nICJsb2FkIiBpbiB0aGUgZmlyc3QgcGxhY2Ugd2FzIHRv IGhlbHAgYWNoaWV2ZSB0aGlzLiBJIHRoaW5rICJwYXJ0aWFsbHkgY29tcGxpYW50IiBpcyBnZW5l cm91cy4NCg0KUmVxIDE3Og0KDQo+IEJ1dOKApiB3ZSBoYXZlIG1lY2hhbmlzbSB0byBrZWVwIERP SUMgbm9kZSB0aHJvdWdocHV0LGluY2x1ZGVkIGFueXRoaW5nIHJlbGF0ZWQgdG8gdGhpcyBpc3N1 ZSBpbiB0aGUgZHJhZnQuDQoNCkknbSBub3Qgc3VyZSB3aGVyZSB3ZSBkaXNhZ3JlZS4gRG8geW91 IHRoaW5rIHRoYXQgd2UgX2FyZW4ndF8gY29tcGxpYW50IG9uIFJlcSAxNz8NCg0KUmVxIDE4Og0K DQo+IFNlZSBjb21tZW50IG9uIDE3DQoNClNlZSByZXNwb25zZSBvbiAxNyA7LSkNCg0KUmVxIDIw OiAoaW4gcmVzcG9uc2UgdG8gdGhlIG5vdGUpDQoNCj4gSSBhZ3JlZQ0KDQpUaGFua3MuIERvIG90 aGVycyBhbHNvIGFncmVlPw0KDQpSZXEgMjM6DQoNCj4gUGFydGx5IENvbXBsaWFudA0KPiANCj4g RE9JQyBPdmVybG9hZCBpbmZvcm1hdGlvbiBjYW4gYmUgdXNlZCBhbHJlYWR5IGJ5IHByb3ByaWV0 YXJ5IGxvYWQtYmFsYW5jaW5nIGltcGxlbWVudGF0aW9ucy4NCj4gDQo+IExvYWQgaW5mb3JtYXRp b24gd2lsbCBiZSBhIHBsdXMgdG8gdGhpcy4NCg0KVGhlIHBvaW50IG9mIHRoZSByZXF1aXJlbWVu dCBpcyB0byBiZSBtYWtlIHNlbGVjdGlvbnMgYW1vbmcgX25vbl8gb3ZlcmxvYWRlZCBub2RlcyBp biBhIHdheSBsZWFzdCBsaWtlbHkgdG8gY2F1c2UgZnVydGhlciBwcm9ibGVtcy4gVGh1cywgSSB0 aGluayB0aGUgbGFjayBvZiAibG9hZCIgbWFrZXMgdXMgbm9uLWNvbXBsaWFudC4gKEl0J3Mgbm90 IGxpa2Ugd2UgZG9uJ3QgcGxhbiB0byBkbyBsb2FkKQ0KDQpSZXEgMjg6IChSZWNvbW1lbmRhdGlv biBmb3Igc2VjdXJpdHkgcmV2aWV3KQ0KDQo+IElzIGl0IGluZGVwZW5kZW50IGZvciBFbmQtdG8t ZW5kIHNlYyBkcmFmdD8NCg0KSW4gbXkgcGVyc29uYWwgb3BpbmlvbiwgdGhlIGVuZC10by1lbmQg d29yayBpcyBubyB3aGVyZSBuZWFyIGZhciBlbm91Z2ggYWxvbmcgdGhhdCB3ZSBjYW4gZGVwZW5k IG9uIGl0IGluIGFueSB3YXkuDQoNClJlcSAzMDoNCg0KPiBJcyBpdCBpbmRlcGVuZGVudCBmb3Ig RW5kLXRvLWVuZCBzZWMgZHJhZnQ/DQo+IA0KPiBUaGlzIG1heSBiZSBtaXNpbnRlcnByZXRlZCBh cyDigJxkb3VibGXigJ0gdGhyb3R0bGluZyBpbiBzb21lIGNhc2VzLg0KDQpJIGFncmVlIHdlIG5l ZWQgdG8gYmUgY2FyZWZ1bCBhYm91dCB0aGF0IGluIHRoZSBtYWluIHRleHQuIERvIHlvdSBkaXNh Z3JlZSB0aGF0IHdlIGFyZSBjb21wbGlhbnQgd2l0aCB0aGUgcmVxdWlyZW1lbnQ/DQoNCj4gIA0K PiAgDQoNCg== From nobody Sun Nov 16 23:37: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 1B6DC1A026E for ; Sun, 16 Nov 2014 23:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85JNKChWlWXJ for ; Sun, 16 Nov 2014 23:37:14 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8BE1A0252 for ; Sun, 16 Nov 2014 23:37:12 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-bf-5469a5a6f30c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4B.5E.24955.6A5A9645; Mon, 17 Nov 2014 08:37:11 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.211]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Mon, 17 Nov 2014 08:37:10 +0100 From: Maria Cruz Bartolome To: Jouni Korhonen , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAHkGAIAAtOqAgAHz+gCAAFimgIAE3DUg Date: Mon, 17 Nov 2014 07:37:10 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209863A5B@ESESSMB101.ericsson.se> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <5465479F.5080001@gmail.com> In-Reply-To: <5465479F.5080001@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvje7ypZkhBg0rOC3m9q5gs9i/roHJ 4vb2TIsNTTwW696uYHJg9dg56y67x5IlP5k8fq6/yu7R8uwkm8eqt32sAaxRXDYpqTmZZalF +nYJXBm/ZuQU/OGtaNw3j7WBcTF3FyMnh4SAicS/j1OYIWwxiQv31rN1MXJxCAkcYZT40dIP 5SxhlNh6Yh8LSBWbgJ3EpdMvmEASIgIfGSU6OqYwgiSEBdQllu/8xQpiiwhoSPQdWc0MYedJ 3Fu8ggnEZhFQlZja+xQszivgK7Fy8WsmiA2PWCW6V2wE28ApoClx5vdusCJGoJu+n1oD1sws IC5x68l8JohbBSSW7DkPdbeoxMvH/1ghbCWJFdsvMULU60gs2P2JDcLWlli28DXUYkGJkzOf sExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgjB3c8lt1 B+PlN46HGAU4GJV4eD/MyQwRYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2M5kFBTB88l3jdvm+xXY51rXt6aNmet7+FMx8XcKgeuLjN55lE/slj3uVLG6/v Mfd9tn393aKJc1rVO3iEfm4xbvFLli+wYH17YvZOxw3XRJbe5eCoW7Z5ReYewcq3Hz44R21o fNcT/Md+/S3fHlXj99KzprD32FYlXelfO2+Oofnfv9PnFWgmKbEUZyQaajEXFScCALDELjaS AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QuuaMbtrlu4E4vWYisLXMsuUNaw Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 07:37:17 -0000 >> >> Section 3, 4th paragraph from end, 2nd sentence: >> Existing text: For example, a single Diameter node may be overloaded,=20 >> in which case reacting nodes may reasonably attempt to send requests=20 >> to other destinations or via other agents. >> Proposed text: For example, a single Diameter node may be overloaded,=20 >> in which case reacting nodes may reasonably attempt to send requests=20 >> to other destinations or - if agent overload control is supported=20 >> (Section A.2) - via other agents. >> >> [LM] Not sure to understand the need for support of Agent overload=20 >> for that... >> [Ulrich] In the absence of agent overload control it is always the=20 >> server or realm that is overloaded and then it is not reasonable to=20 >> attempt sending requests via other agents to the same overloaded=20 >> server or realm. > SRD> Agent overload isn't yet defined so we can't refer to it in this > document. I also perfectly ok, in fact, it is expected behavior, for=20 > a reacting node for a host report to send realm routed requests to a=20 > different agent as the reacting node does not know which host will end=20 > up handling the request. [MCruz] My proposal is to remove "or via other agents". Although it is true= a request may use different intermediate agents, the reacting node does no= t choose that as per DOIC functionality.=20 Then: Existing text:=20 For example, a single Diameter node may be overloaded,=20 in which case reacting nodes may reasonably attempt to send requests to oth= er destinations or via other agents. New text:=20 For example, a single Diameter node may be overloaded,=20 in which case reacting nodes may reasonably attempt to send requests to oth= er destinations. Best regards /MCruz From nobody Sun Nov 16 23:37: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 6808C1A0275 for ; Sun, 16 Nov 2014 23:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_cdqedVDs1z for ; Sun, 16 Nov 2014 23:37:11 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADFF1A0210 for ; Sun, 16 Nov 2014 23:37:11 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-07-5469a5a54886 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.63.04081.5A5A9645; Mon, 17 Nov 2014 08:37:10 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.211]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Mon, 17 Nov 2014 08:37:09 +0100 From: Maria Cruz Bartolome To: "lionel.morand@orange.com" , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAHkGAIAAtOqAgAHz+gCAAFg3AIAE29nA Date: Mon, 17 Nov 2014 07:37:08 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvje6ypZkhBt8cLeb2rmCzuL0902JD E4/FurcrmBxYPJYs+cnk8XP9VXaPlmcn2TxWve1jDWCJ4rJJSc3JLEst0rdL4Mp4u30tU0Eb R8XSpz3sDYwb2LoYOTgkBEwkXu3L6mLkBDLFJC7cWw8U5uIQEjjCKLFl8jZWCGcJo8SO5m9M IFVsAnYSl06/YAJJiAgcYpT4+XkVO0hCWEBdYvnOX6wgtoiAhkTfkdXMEHaexLllp1hAtrEI qEo0TeAFCfMK+EpM3nqFGWLBPjaJezf/MoI4nALNjBL3HjewgVQxAt30/dQasM3MAuISt57M Z4K4VUBiyZ7zzBC2qMTLx/9YIWwliRXbLzFC1OtILNj9iQ3C1pZYtvA1M8RmQYmTM5+wTGAU nYVk7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmA0Hdzy22AH48vn jocYBTgYlXh4P8zJDBFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYwzcjhcmZ5VpNs2H7Qu+Li1oz15FUt6ucL/Q9d/iVVemLJgzqLj7mmbKnJKylbzztkb Z1nkebpQWNrpeNaGlVterrsSavNxv9IL3ZU/J2856tNf9axSdrUgW++JoLqjcwJjautcL3n6 7jwQssXOs1PwQNMdhbgJDrLJ9ziFN1p2SbB7P9v1dJoSS3FGoqEWc1FxIgCFS4ofhwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2ra23_m5B6XkHsfHAfCEqDA14AI Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 07:37:19 -0000 > Section 4.2.3, 13th paragraph, 2nd sentence: > Existing text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the OLR applies. > Proposed text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the sent OLR applies. > > [LM] I would say that the reporting node will not remember the previously= sent OLR, but will take care that there is an active OCS. SRD> I'm ok with Ulrich's change. [LM] and this is incorrect but not fundamental. The reporting node does not= have to "remember" a previously sent OLR. What it will do is to refer to e= xisting OCS to know that throttling should not be applied. An OCS is a cons= equence of an sent OLR but it is not an OLR itself. But not fundamental her= e. [MCruz] I am ok with Ulrich's change. It does not mean that the reporting n= ode needs to "remember" a previously sent OLR, though. The change only prop= oses to "identify" which OLR we refer to. Best regards /MCruz From nobody Sun Nov 16 23:39: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 8C0F81A01A5 for ; Sun, 16 Nov 2014 23:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrovWV3p7-qA for ; Sun, 16 Nov 2014 23:39:49 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667AC1A01E5 for ; Sun, 16 Nov 2014 23:39:49 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-1b-5469a6425147 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.33.04076.246A9645; Mon, 17 Nov 2014 08:39:47 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.211]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Mon, 17 Nov 2014 08:39:45 +0100 From: Maria Cruz Bartolome To: Jouni Korhonen , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAHkGAIAAtOqAgAHz+gCAAFimgIAE3cqA Date: Mon, 17 Nov 2014 07:39:45 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209863A74@ESESSMB101.ericsson.se> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <5465479F.5080001@gmail.com> In-Reply-To: <5465479F.5080001@gmail.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+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rtd5WWaIwcb9vBZze1ewWexf18Bk cXt7psWGJh6LdW9XMDmweuycdZfdY8mSn0weP9dfZfdoeXaSzWPV2z7WANYoLpuU1JzMstQi fbsEroy29bfZCnpEKz4uXc3WwPhQoIuRk0NCwERi9btORghbTOLCvfVsXYxcHEICRxglll1e ww7hLGGUuPXuJxNIFZuAncSl0y+YQBIiAh8ZJTo6poC1CwuoSyzf+YsVxBYR0JDoO7KaGcLO k/jf2cgCYrMIqEoc3n6QDcTmFfCVuHccZt0jVonuFRvBijgFNCXO/N4N1swIdNP3U2vANjML iEvcejKfCeJWAYkle84zQ9iiEi8f/2OFsJUkFt3+DFWvI7Fg9yc2CFtbYtnC18wQiwUlTs58 wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBUXZwy2+r HYwHnzseYhTgYFTi4f0wJzNEiDWxrLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwhpVzcDR4Rd5+LmX9Y2bY3aiVmUI7OxKZuQ6V7svasuSO9I81oj9vBYdN8v5f vibRNmPz05lsv/ITdfeur763zt1yYoln8oPJrZfyv8ju42e4mbUj0Pr/te7dwoV7qgwdt5d+ c8pZZ5XwaHXniqqXXqW8zY21P7+bTZ3gcU3d5L5uFzdngPoTJZbijERDLeai4kQAjSAHDpMC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sdtHWFPALhtb4eBxVWIckgvLHko Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 07:39:51 -0000 >> >> Section 3, last paragraph, 3rd sentence from end: >> Existing text: >> For example, one or more Diameter agents that do not support DOIC may=20 >> exist between a given pair of reporting and reacting nodes, as long=20 >> as those agents pass unknown AVPs through unchanged. >> Proposed text: For example, one or more Diameter agents that do or do=20 >> not support DOIC may exist between a given pair of reporting and=20 >> reacting nodes, as long as those agents pass OC-specific AVPs or=20 >> unknown AVPs through unchanged. >> >> [LM] but actually, "OC-Specific AVPs" are unknown for a=20 >> non-supporting agent. >> [Ulrich] yes, but the exist text does not cover the case where a DOIC=20 >> supporting agent exists between a given pair of reporting and=20 >> reacting nodes, which passes OC-specific AVPs (although not unknown)=20 >> through unchanged. > SRD> I disagree with the change. We have already identified cases=20 > SRD> where > a DOIC agent can change the OC-specific AVPs. [JiK] Agree with Steve here. And since an agent that may fiddle with non-ro= uting AVPs is typically (or actually) a proxy, it can do whatever it see be= st as long as stuff does not break. I think we are losing a bit of context here. Existing paragraph: While a reporting node sends OLRs to "adjacent" reacting nodes, nodes that are "adjacent" for DOIC purposes may not be adjacent from a Diameter, or transport, perspective. For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unchanged. The report types described in this document can safely pass through non-supporting agents. This may not be true for report types defined in future specifications. The example is trying to explain that DOIC works even if there are (DOIC or= non-DOIC) agents between a reporting and a reacting node (i.e. they are n= ot "adjacent" nodes). As it is now, a reader may wrongly infer than only non-DOIC agents may exis= t in between a reporting and reacting node.=20 But in my opinion, the example should cover both cases. Focusing just on the offending part, existing: For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unchanged. =20 Proposal: For example, one or more Diameter agents, that may or not support DOIC, may exist between a given pair of reporting and reacting nodes. Non supporting DOIC agents passes unknown AVPs through unchanged. =20 From nobody Mon Nov 17 00:35: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 642C61A19E5 for ; Mon, 17 Nov 2014 00:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZVJOFXb4MM5O for ; Mon, 17 Nov 2014 00:35:03 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27BE1A044D for ; Mon, 17 Nov 2014 00:35:02 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BC1822DC121; Mon, 17 Nov 2014 09:35:00 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 98D794C077; Mon, 17 Nov 2014 09:35:00 +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.0210.002; Mon, 17 Nov 2014 09:35:00 +0100 From: To: Jouni Korhonen , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , Maria Cruz Bartolome Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAHkGAIAAtOqAgAHz+gCAAFimgIAE3DUggAB5ges= Date: Mon, 17 Nov 2014 08:34:59 +0000 Message-ID: <801_1416213300_5469B334_801_932_1_s71ptfi381xhojcncfb8va7h.1416213290108@email.android.com> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <5465479F.5080001@gmail.com>, <087A34937E64E74E848732CFF8354B9209863A5B@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209863A5B@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: 2014.10.23.30920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mdS7cLuy7Cib5QADpCemdL0x4D8 Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 08:35:06 -0000 If the proposal is accepted (I'm OK with), please remove "reasonably" :) Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Maria Cruz Bartolome a =E9crit ---- >> >> Section 3, 4th paragraph from end, 2nd sentence: >> Existing text: For example, a single Diameter node may be overloaded, >> in which case reacting nodes may reasonably attempt to send requests >> to other destinations or via other agents. >> Proposed text: For example, a single Diameter node may be overloaded, >> in which case reacting nodes may reasonably attempt to send requests >> to other destinations or - if agent overload control is supported >> (Section A.2) - via other agents. >> >> [LM] Not sure to understand the need for support of Agent overload >> for that... >> [Ulrich] In the absence of agent overload control it is always the >> server or realm that is overloaded and then it is not reasonable to >> attempt sending requests via other agents to the same overloaded >> server or realm. > SRD> Agent overload isn't yet defined so we can't refer to it in this > document. I also perfectly ok, in fact, it is expected behavior, for > a reacting node for a host report to send realm routed requests to a > different agent as the reacting node does not know which host will end > up handling the request. [MCruz] My proposal is to remove "or via other agents". Although it is true= a request may use different intermediate agents, the reacting node does no= t choose that as per DOIC functionality. Then: Existing text: For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send requests to oth= er destinations or via other agents. New text: For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send requests to oth= er destinations. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ 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 Nov 17 00:38: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 3E0671A19F3 for ; Mon, 17 Nov 2014 00:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 28t_o-kDiMi5 for ; Mon, 17 Nov 2014 00:38:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB8D1A19ED for ; Mon, 17 Nov 2014 00:38:27 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id A7C8F374156; Mon, 17 Nov 2014 09:38:25 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 89B7A3840B1; Mon, 17 Nov 2014 09:38: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.0210.002; Mon, 17 Nov 2014 09:38:25 +0100 From: To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , "Maria Cruz Bartolome" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAHkGAIAAtOqAgAHz+gCAAFg3AIAE29nAgAB7QIA= Date: Mon, 17 Nov 2014 08:38:24 +0000 Message-ID: <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209863A54@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: 2014.11.17.80327 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qYQrqn24PrSGMe2gMB9BIUZqSNc Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 08:38:29 -0000 I can live with the text proposed by Ulrich. But what is wrong with: " Therefore, the reporting node SHOULD NOT apply throttling to the set of m= essages to which an active OCS applies." ? Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Maria Cruz Bartolome a =E9crit ---- > Section 4.2.3, 13th paragraph, 2nd sentence: > Existing text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the OLR applies. > Proposed text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the sent OLR applies. > > [LM] I would say that the reporting node will not remember the previously= sent OLR, but will take care that there is an active OCS. SRD> I'm ok with Ulrich's change. [LM] and this is incorrect but not fundamental. The reporting node does not= have to "remember" a previously sent OLR. What it will do is to refer to e= xisting OCS to know that throttling should not be applied. An OCS is a cons= equence of an sent OLR but it is not an OLR itself. But not fundamental her= e. [MCruz] I am ok with Ulrich's change. It does not mean that the reporting n= ode needs to "remember" a previously sent OLR, though. The change only prop= oses to "identify" which OLR we refer to. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ 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 Nov 17 12:22: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 C59B51A8AB9 for ; Mon, 17 Nov 2014 12:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsZ9ftAeoQ4F for ; Mon, 17 Nov 2014 12:21:55 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05E61A9008 for ; Mon, 17 Nov 2014 12:21:50 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-3c-546a58dc1574 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D5.AB.04081.CD85A645; Mon, 17 Nov 2014 21:21:48 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.211]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Mon, 17 Nov 2014 21:21:48 +0100 From: Maria Cruz Bartolome To: "lionel.morand@orange.com" , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAHkGAIAAtOqAgAHz+gCAAFg3AIAE29nAgAB7QICAAMQGAA== Date: Mon, 17 Nov 2014 20:21:47 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209867DB8@ESESSMB101.ericsson.se> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> In-Reply-To: <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@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.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje6diKwQg/2zVC3m9q5gs7i9PdNi QxOPxbq3K5gcWDyWLPnJ5PFz/VV2j5ZnJ9k8Vr3tYw1gieKySUnNySxLLdK3S+DK+PphOUvB LLGK3Td/MzcwNgl1MXJySAiYSBz+9oQFwhaTuHBvPVsXIxeHkMARRolNP+ezQDhLGCWmtJ5l AqliE7CTuHT6BRNIQkTgEKPEz8+r2EESwgLqEst3/mIFsUUENCT6jqxmhrDrJP59PgW2gkVA VeLgnjdgcV4BX4m/h58wgthCAk/YJS52a4DYnAJ5ErNvfwGbwwh00vdTa8AWMwuIS9x6Mp8J 4lQBiSV7zjND2KISLx//Y4WwlSRWbL/ECFGvJ3Fj6hQ2CFtbYtnC11B7BSVOznzCMoFRdBaS sbOQtMxC0jILScsCRpZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIHxdHDLb4MdjC+fOx5i FOBgVOLh/TAnM0SINbGsuDL3EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTDG+hYVrjBaP/XiSmWppg3P9Ap8lYqNA97yvlo6V/KK6tdjIfIXlMwz3gYmZ/wR9bijsmwx a3TUIlOGKR4PQ1Y3O79ZM/HnbMZZRTnC1zSjy5ZEtBle1pdSUNLfl2XRsFgoas29DTNm/HrF s/X39YDDM9heCDu3fWST7dwVYnzouq33a4se/ilKLMUZiYZazEXFiQBoPp0iiAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7jRdwHmJ8v-pWQA5lGZN6BqYBPs Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 20:21:58 -0000 Hello, "... to which an active OCS applies" This shall refer to "active OCS" in the downstream node, since the OLR is s= ent downstream, and there it would (normally) turn into an active OCS. Cheers /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: lunes, 17 de noviembre de 2014 9:38 To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cr= uz Bartolome Subject: RE: [Dime] Updates to DOIC -05 I can live with the text proposed by Ulrich. But what is wrong with: " Therefore, the reporting node SHOULD NOT apply throttling to the set of m= essages to which an active OCS applies." ? Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Maria Cruz Bartolome a =E9crit ---- > Section 4.2.3, 13th paragraph, 2nd sentence: > Existing text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the OLR applies. > Proposed text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the sent OLR applies. > > [LM] I would say that the reporting node will not remember the previously= sent OLR, but will take care that there is an active OCS. SRD> I'm ok with Ulrich's change. [LM] and this is incorrect but not fundamental. The reporting node does not= have to "remember" a previously sent OLR. What it will do is to refer to e= xisting OCS to know that throttling should not be applied. An OCS is a cons= equence of an sent OLR but it is not an OLR itself. But not fundamental her= e. [MCruz] I am ok with Ulrich's change. It does not mean that the reporting n= ode needs to "remember" a previously sent OLR, though. The change only prop= oses to "identify" which OLR we refer to. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ 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 Mon Nov 17 12:34: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 3A4421A9089 for ; Mon, 17 Nov 2014 12:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Wq1TuvZNEafc for ; Mon, 17 Nov 2014 12:34:23 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1543E1A9008 for ; Mon, 17 Nov 2014 12:34:23 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 930C722C838; Mon, 17 Nov 2014 21:34:21 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 450224C070; Mon, 17 Nov 2014 21:34: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.0210.002; Mon, 17 Nov 2014 21:34:21 +0100 From: To: Maria Cruz Bartolome , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKSXaCAAAR7gIABTKMwgABqDwCAAHkGAIAAtOqAgAHz+gCAAFg3AIAE29nAgAB7QICAAMQGAIAAA09w Date: Mon, 17 Nov 2014 20:34:20 +0000 Message-ID: <12919_1416256461_546A5BCD_12919_5444_1_6B7134B31289DC4FAF731D844122B36E8FD982@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> <087A34937E64E74E848732CFF8354B9209867DB8@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209867DB8@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.6] 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.11.17.100023 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tBFkL2n4pee-vqRLos9De5uW_c0 Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 20:34:29 -0000 Correct! Sorry for being (too) slow! :) -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Envoy=E9=A0: lundi 17 novembre 2014 21:22 =C0=A0: MORAND Lionel IMT/OLN; Steve Donovan; Wiehe, Ulrich (NSN - DE/Munic= h); dime@ietf.org Objet=A0: RE: [Dime] Updates to DOIC -05 Hello, "... to which an active OCS applies" This shall refer to "active OCS" in the downstream node, since the OLR is s= ent downstream, and there it would (normally) turn into an active OCS. Cheers /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: lunes, 17 de noviembre de 2014 9:38 To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cr= uz Bartolome Subject: RE: [Dime] Updates to DOIC -05 I can live with the text proposed by Ulrich. But what is wrong with: " Therefore, the reporting node SHOULD NOT apply throttling to the set of m= essages to which an active OCS applies." ? Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Maria Cruz Bartolome a =E9crit ---- > Section 4.2.3, 13th paragraph, 2nd sentence: > Existing text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the OLR applies. > Proposed text: Therefore, the reporting node SHOULD NOT apply throttling = to the set of messages to which the sent OLR applies. > > [LM] I would say that the reporting node will not remember the previously= sent OLR, but will take care that there is an active OCS. SRD> I'm ok with Ulrich's change. [LM] and this is incorrect but not fundamental. The reporting node does not= have to "remember" a previously sent OLR. What it will do is to refer to e= xisting OCS to know that throttling should not be applied. An OCS is a cons= equence of an sent OLR but it is not an OLR itself. But not fundamental her= e. [MCruz] I am ok with Ulrich's change. It does not mean that the reporting n= ode needs to "remember" a previously sent OLR, though. The change only prop= oses to "identify" which OLR we refer to. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ 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. 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 Nov 17 19:26: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 0F57E1A004D for ; Mon, 17 Nov 2014 19:26:40 -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 tIWUEdcntW_E for ; Mon, 17 Nov 2014 19:26:38 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A72D1A0045 for ; Mon, 17 Nov 2014 19:26:38 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id h136so2635362oig.25 for ; Mon, 17 Nov 2014 19:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Jub0FOv7WPLl0TNlyPJDTsxcvIOw4khTSSxn6MCTjYo=; b=WEU1Ik8kjA/x1qhQZC84gFRopsi+OXzvIlb3EBZAq9A+BifYz0DmhSkoS+S09pfnDr repiBDeWkALdY8Zs46b8Azq0EdQH/uxujh/8Ea7jdW8g6Fo4OD+R4iH060e8/YrzRBwN h89Ud/DntS8//MTL5oci5PR0WQPaPtzXoscJdKbSXx91IOmYrrQ0eH+FqtZQW6W5A/Xd 3j22ANjo/piblXbJDdNMU1BvhWhLG2gZ27FUHyIzqqjgR+DKEKdb+/62jJwDiqspON4N Pwz580hSK6I6Q7Py8xknaNpjy/rv93g/V4AEeHxYlynDfdyDr1C/qf97SevLrXTXfUdO 1s7g== X-Received: by 10.182.98.168 with SMTP id ej8mr10887651obb.41.1416281197350; Mon, 17 Nov 2014 19:26:37 -0800 (PST) Received: from [172.20.1.225] ([12.204.99.170]) by mx.google.com with ESMTPSA id tp4sm1688863obc.19.2014.11.17.19.26.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 19:26:36 -0800 (PST) Message-ID: <546ABC72.9050309@gmail.com> Date: Tue, 18 Nov 2014 05:26:42 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <5465479F.5080001@gmail.com> <087A34937E64E74E848732CFF8354B9209863A74@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209863A74@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dOgKkBkbYFl9UIqFmYYaPKGEJ3c Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 03:26:40 -0000 11/17/2014 9:39 AM, Maria Cruz Bartolome kirjoitti: >>> >>> Section 3, last paragraph, 3rd sentence from end: >>> Existing text: >>> For example, one or more Diameter agents that do not support DOIC may >>> exist between a given pair of reporting and reacting nodes, as long >>> as those agents pass unknown AVPs through unchanged. >>> Proposed text: For example, one or more Diameter agents that do or do >>> not support DOIC may exist between a given pair of reporting and >>> reacting nodes, as long as those agents pass OC-specific AVPs or >>> unknown AVPs through unchanged. >>> >>> [LM] but actually, "OC-Specific AVPs" are unknown for a >>> non-supporting agent. >>> [Ulrich] yes, but the exist text does not cover the case where a DOIC >>> supporting agent exists between a given pair of reporting and >>> reacting nodes, which passes OC-specific AVPs (although not unknown) >>> through unchanged. >> SRD> I disagree with the change. We have already identified cases >> SRD> where >> a DOIC agent can change the OC-specific AVPs. > > [JiK] Agree with Steve here. And since an agent that may fiddle with non-routing AVPs is typically (or actually) a proxy, it can do whatever it see best as long as stuff does not break. > > I think we are losing a bit of context here. > Existing paragraph: > > While a reporting node sends OLRs to "adjacent" reacting nodes, nodes > that are "adjacent" for DOIC purposes may not be adjacent from a > Diameter, or transport, perspective. For example, one or more > Diameter agents that do not support DOIC may exist between a given > pair of reporting and reacting nodes, as long as those agents pass > unknown AVPs through unchanged. The report types described in this > document can safely pass through non-supporting agents. This may not > be true for report types defined in future specifications. > > The example is trying to explain that DOIC works even if there are (DOIC or non-DOIC) agents between a reporting and a reacting node (i.e. they are not "adjacent" nodes). > As it is now, a reader may wrongly infer than only non-DOIC agents may exist in between a reporting and reacting node. > But in my opinion, the example should cover both cases. > > Focusing just on the offending part, existing: > For example, one or more > Diameter agents that do not support DOIC may exist between a given > pair of reporting and reacting nodes, as long as those agents pass > unknown AVPs through unchanged. > > Proposal: > For example, one or more > Diameter agents, that may or not support DOIC, may exist between a given > pair of reporting and reacting nodes. Non supporting DOIC agents passes > unknown AVPs through unchanged. I think we cannot assure what the last sentence says. I would be ok if we change it to "..agents typically passes.." - Jouni From nobody Tue Nov 18 08: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 C614C1A1A1E for ; Tue, 18 Nov 2014 08:12:47 -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 loF9Sv2ca5eV for ; Tue, 18 Nov 2014 08:12:46 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8BB1A19FF for ; Tue, 18 Nov 2014 08:12:46 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49821 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XqlOS-000101-6C; Tue, 18 Nov 2014 08:12:43 -0800 Message-ID: <546B6FF7.2020702@usdonovans.com> Date: Tue, 18 Nov 2014 10:12:39 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <5465479F.5080001@gmail.com> <087A34937E64E74E848732CFF8354B9209863A5B@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209863A5B@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qoWtOhxZ_KNS1nLL1xbdmKuFDFE Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:12:48 -0000 Change made. Steve On 11/17/14, 1:37 AM, Maria Cruz Bartolome wrote: >>> Section 3, 4th paragraph from end, 2nd sentence: >>> Existing text: For example, a single Diameter node may be overloaded, >>> in which case reacting nodes may reasonably attempt to send requests >>> to other destinations or via other agents. >>> Proposed text: For example, a single Diameter node may be overloaded, >>> in which case reacting nodes may reasonably attempt to send requests >>> to other destinations or - if agent overload control is supported >>> (Section A.2) - via other agents. >>> >>> [LM] Not sure to understand the need for support of Agent overload >>> for that... >>> [Ulrich] In the absence of agent overload control it is always the >>> server or realm that is overloaded and then it is not reasonable to >>> attempt sending requests via other agents to the same overloaded >>> server or realm. >> SRD> Agent overload isn't yet defined so we can't refer to it in this >> document. I also perfectly ok, in fact, it is expected behavior, for >> a reacting node for a host report to send realm routed requests to a >> different agent as the reacting node does not know which host will end >> up handling the request. > [MCruz] My proposal is to remove "or via other agents". Although it is true a request may use different intermediate agents, the reacting node does not choose that as per DOIC functionality. > Then: > > Existing text: > For example, a single Diameter node may be overloaded, > in which case reacting nodes may reasonably attempt to send requests to other destinations or via other agents. > > New text: > For example, a single Diameter node may be overloaded, > in which case reacting nodes may reasonably attempt to send requests to other destinations. > > Best regards > /MCruz > From nobody Tue Nov 18 08:14: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 EE2E01A1A83 for ; Tue, 18 Nov 2014 08:14:03 -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 kAOQNclfHZ8w for ; Tue, 18 Nov 2014 08:14:02 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCCA1A1A7A for ; Tue, 18 Nov 2014 08:13:42 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49975 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XqlPQ-0001zf-Cf; Tue, 18 Nov 2014 08:13:41 -0800 Message-ID: <546B7032.6030602@usdonovans.com> Date: Tue, 18 Nov 2014 10:13:38 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , Maria Cruz Bartolome References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <5465479F.5080001@gmail.com>, <087A34937E64E74E848732CFF8354B9209863A5B@ESESSMB101.ericsson.se> <801_1416213300_5469B334_801_932_1_s71ptfi381xhojcncfb8va7h.1416213290108@email.android.com> In-Reply-To: <801_1416213300_5469B334_801_932_1_s71ptfi381xhojcncfb8va7h.1416213290108@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/F0X-u0d-H45ZHE6ALtdt-8oe2DA Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:14:04 -0000 Change made. Steve On 11/17/14, 2:34 AM, lionel.morand@orange.com wrote: > If the proposal is accepted (I'm OK with), please remove "reasonably" :) > > Envoyé depuis mon Sony Xperia SP d'Orange > > ---- Maria Cruz Bartolome a écrit ---- > > >>> Section 3, 4th paragraph from end, 2nd sentence: >>> Existing text: For example, a single Diameter node may be overloaded, >>> in which case reacting nodes may reasonably attempt to send requests >>> to other destinations or via other agents. >>> Proposed text: For example, a single Diameter node may be overloaded, >>> in which case reacting nodes may reasonably attempt to send requests >>> to other destinations or - if agent overload control is supported >>> (Section A.2) - via other agents. >>> >>> [LM] Not sure to understand the need for support of Agent overload >>> for that... >>> [Ulrich] In the absence of agent overload control it is always the >>> server or realm that is overloaded and then it is not reasonable to >>> attempt sending requests via other agents to the same overloaded >>> server or realm. >> SRD> Agent overload isn't yet defined so we can't refer to it in this >> document. I also perfectly ok, in fact, it is expected behavior, for >> a reacting node for a host report to send realm routed requests to a >> different agent as the reacting node does not know which host will end >> up handling the request. > [MCruz] My proposal is to remove "or via other agents". Although it is true a request may use different intermediate agents, the reacting node does not choose that as per DOIC functionality. > Then: > > Existing text: > For example, a single Diameter node may be overloaded, > in which case reacting nodes may reasonably attempt to send requests to other destinations or via other agents. > > New text: > For example, a single Diameter node may be overloaded, > in which case reacting nodes may reasonably attempt to send requests to other destinations. > > Best regards > /MCruz > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Tue Nov 18 08:19: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 AC5CD1A1A36 for ; Tue, 18 Nov 2014 08:19:04 -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 alqpxAJD-2Tr for ; Tue, 18 Nov 2014 08:19:03 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2051A1A1E for ; Tue, 18 Nov 2014 08:19:03 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50745 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XqlUb-0008EF-6X; Tue, 18 Nov 2014 08:19:02 -0800 Message-ID: <546B7174.3030705@usdonovans.com> Date: Tue, 18 Nov 2014 10:19:00 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , "dime@ietf.org" References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <5465479F.5080001@gmail.com> <087A34937E64E74E848732CFF8354B9209863A74@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209863A74@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0gbfeF-ULWKuBrY8zIpqT-mgxxg Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:19:04 -0000 inline... On 11/17/14, 1:39 AM, Maria Cruz Bartolome wrote: >>> Section 3, last paragraph, 3rd sentence from end: >>> Existing text: >>> For example, one or more Diameter agents that do not support DOIC may >>> exist between a given pair of reporting and reacting nodes, as long >>> as those agents pass unknown AVPs through unchanged. >>> Proposed text: For example, one or more Diameter agents that do or do >>> not support DOIC may exist between a given pair of reporting and >>> reacting nodes, as long as those agents pass OC-specific AVPs or >>> unknown AVPs through unchanged. >>> >>> [LM] but actually, "OC-Specific AVPs" are unknown for a >>> non-supporting agent. >>> [Ulrich] yes, but the exist text does not cover the case where a DOIC >>> supporting agent exists between a given pair of reporting and >>> reacting nodes, which passes OC-specific AVPs (although not unknown) >>> through unchanged. >> SRD> I disagree with the change. We have already identified cases >> SRD> where >> a DOIC agent can change the OC-specific AVPs. > [JiK] Agree with Steve here. And since an agent that may fiddle with non-routing AVPs is typically (or actually) a proxy, it can do whatever it see best as long as stuff does not break. > > I think we are losing a bit of context here. > Existing paragraph: > > While a reporting node sends OLRs to "adjacent" reacting nodes, nodes > that are "adjacent" for DOIC purposes may not be adjacent from a > Diameter, or transport, perspective. For example, one or more > Diameter agents that do not support DOIC may exist between a given > pair of reporting and reacting nodes, as long as those agents pass > unknown AVPs through unchanged. The report types described in this > document can safely pass through non-supporting agents. This may not > be true for report types defined in future specifications. > > The example is trying to explain that DOIC works even if there are (DOIC or non-DOIC) agents between a reporting and a reacting node (i.e. they are not "adjacent" nodes). SRD> I disagree, this is trying to expain that DOIC works specifically when non-DOIC agents exist between reporting and reacting nodes. Its saying that what we have defined in this document works in the presence of non supporting agents. > As it is now, a reader may wrongly infer than only non-DOIC agents may exist in between a reporting and reacting node. > But in my opinion, the example should cover both cases. > > Focusing just on the offending part, existing: > For example, one or more > Diameter agents that do not support DOIC may exist between a given > pair of reporting and reacting nodes, as long as those agents pass > unknown AVPs through unchanged. > > Proposal: > For example, one or more > Diameter agents, that may or not support DOIC, may exist between a given > pair of reporting and reacting nodes. Non supporting DOIC agents passes > unknown AVPs through unchanged. > SRD> I don't see the need for this change. Agents that support DOIC can also be reporting and reacting nodes. This change implies this isn't the case. From nobody Tue Nov 18 08:44: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 0273C1A1A84 for ; Tue, 18 Nov 2014 08:44:01 -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 guFPKI23zwRa for ; Tue, 18 Nov 2014 08:43:59 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAE41A1AB4 for ; Tue, 18 Nov 2014 08:43:19 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54301 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xqls3-0001Sg-Lr for dime@ietf.org; Tue, 18 Nov 2014 08:43:17 -0800 Message-ID: <546B7723.20102@usdonovans.com> Date: Tue, 18 Nov 2014 10:43:15 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------000504060703010008090203" 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/V0D1jtxpYGUEyKSgDdCl9EzBXzI Subject: [Dime] Changes to section 4.1.3 Agent Behavior subsection of Capability Announcement X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:44:01 -0000 This is a multi-part message in MIME format. --------------000504060703010008090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I've made some substantial changes to section 4.1.3. This was based on discussions in Honolulu pointing out that clarifications were needed. Here's the now section. Regards, Steve ----- 4.1.3. Agent Behavior Editor's Note: Need to verify changes in this section. Diameter Agents that support DOIC SHOULD ensure that all messages relayed by the agent contain the OC-Supported-Features AVP. A Diameter Agent SHOULD take on reacting node behavior for Diameter endpoints that do not support the DOIC solution. A Diameter Agent detects that a Diameter endpoint does not support DOIC reacting node behavior when there is no OC-Supported-Features AVP in a request message. For a Diameter Agent to be a reacting node for a non supporting Diameter endpoint, the Diameter Agent MUST include the OC-Supported- Features vector in request messages it receives that do not contain the OC-Supported-Features AVP. A Diameter Agent SHOULD take on reporting node behavior for Diameter endpoints that do not support the DOIC solution. A Diameter Agent detects that a Diameter endpoint does not support DOIC reporting node behavior when there is no OC-Supported-Features AVP in an answer message for a transaction that contained the OC-Supported-Features AVP in the request message. For a Diameter Agent to take on reporting node behavior for a non supporting Diameter endpoint the Diameter Agent MUST include the OC- Supported-Features vector in answer messages it receives that do not contain the OC-Supported-Features AVP. As with a Diameter endpoint taking on reporting node behavior, a Diameter Agent MUST only include the OC-Supported-Features AVP in answer messages for transactions where the request message received by the Diameter Agent had an OC-Supported-Features AVP. If a request message already has the OC-Supported-Features AVP then a Diameter Agent MAY leave it unchanged in the relayed message or MAY modify it to reflect the features appropriate for the transaction. For instance, if the agent supports a superset of the features reported by the reacting node then the agent might choose, based on local policy, to advertise that superset of features to the reporting node. If the Diameter Agent changes the OC-Supported-Features AVP in a request message then it is likely it will also need to modify the OC- Supported-Features AVP in the answer message for the transaction. As such, a Diameter Agent MAY modify the OC-Supported-Features AVP carried in answer messages. When making changes to the OC-Supported-Features AVP the Diameter Agent needs to ensure that there is no ambiguity in DOIC behavior for both upstream and downstream DOIC nodes. --------------000504060703010008090203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I've made some substantial changes to section 4.1.3.  This was based on discussions in Honolulu pointing out that clarifications were needed.

Here's the now section.

Regards,

Steve

-----
4.1.3.  Agent Behavior

   Editor's Note: Need to verify changes in this section.

   Diameter Agents that support DOIC SHOULD ensure that all messages
   relayed by the agent contain the OC-Supported-Features AVP.

   A Diameter Agent SHOULD take on reacting node behavior for Diameter
   endpoints that do not support the DOIC solution.  A Diameter Agent
   detects that a Diameter endpoint does not support DOIC reacting node
   behavior when there is no OC-Supported-Features AVP in a request
   message.

   For a Diameter Agent to be a reacting node for a non supporting
   Diameter endpoint, the Diameter Agent MUST include the OC-Supported-
   Features vector in request messages it receives that do not contain
   the OC-Supported-Features AVP.

   A Diameter Agent SHOULD take on reporting node behavior for Diameter
   endpoints that do not support the DOIC solution.  A Diameter Agent
   detects that a Diameter endpoint does not support DOIC reporting node
   behavior when there is no OC-Supported-Features AVP in an answer
   message for a transaction that contained the OC-Supported-Features
   AVP in the request message.

   For a Diameter Agent to take on reporting node behavior for a non
   supporting Diameter endpoint the Diameter Agent MUST include the OC-
   Supported-Features vector in answer messages it receives that do not
   contain the OC-Supported-Features AVP.

   As with a Diameter endpoint taking on reporting node behavior, a
   Diameter Agent MUST only include the OC-Supported-Features AVP in
   answer messages for transactions where the request message received
   by the Diameter Agent had an OC-Supported-Features AVP.

   If a request message already has the OC-Supported-Features AVP then a
   Diameter Agent MAY leave it unchanged in the relayed message or MAY
   modify it to reflect the features appropriate for the transaction.

      For instance, if the agent supports a superset of the features
      reported by the reacting node then the agent might choose, based
      on local policy, to advertise that superset of features to the
      reporting node.

   If the Diameter Agent changes the OC-Supported-Features AVP in a
   request message then it is likely it will also need to modify the OC-
   Supported-Features AVP in the answer message for the transaction.  As
   such, a Diameter Agent MAY modify the OC-Supported-Features AVP
   carried in answer messages.

   When making changes to the OC-Supported-Features AVP the Diameter
   Agent needs to ensure that there is no ambiguity in DOIC behavior for
   both upstream and downstream DOIC nodes.

--------------000504060703010008090203-- From nobody Tue Nov 18 10:04: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 3A3EC1A1A83 for ; Tue, 18 Nov 2014 10:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhoIwpaDeWmK for ; Tue, 18 Nov 2014 10:04:50 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9311A0235 for ; Tue, 18 Nov 2014 10:04:50 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 91234D5AA361E; Tue, 18 Nov 2014 18:04:45 +0000 (GMT) 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 sAII4mqv003352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Nov 2014 19:04:48 +0100 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 18 Nov 2014 19:04:48 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Steve Donovan Thread-Topic: [Dime] -05 of DOIC specification Thread-Index: AQHP/qu7Jabf3ef6KkmqVsyDAf6p+pxmotOQ Date: Tue, 18 Nov 2014 18:04:47 +0000 Message-ID: References: <5463AF67.5010009@usdonovans.com> In-Reply-To: <5463AF67.5010009@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.41] 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/3lT1y-7ms8G2u-jF5dAjxRIzXIg Cc: "dime@ietf.org" Subject: Re: [Dime] -05 of DOIC specification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:04:53 -0000 Hi Steve The last draft_ietf-dime-Ovli text 05 that was distributed is dated Nov 05,= and is the last text stored in GitHub. Is it possible for you to send the current 05 text integrating the modifica= tions we agreed upon in IETF 91 and in the exchanged mails. Thank you. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: mercredi 12 novembre 2014 20:05 =C0=A0: dime@ietf.org Objet=A0: [Dime] -05 of DOIC specification All, Here's the txt version of DOIC -05 for use in review. Regards, Steve From nobody Tue Nov 18 10:30: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 5C7F51A007C for ; Tue, 18 Nov 2014 10:30:03 -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 yUwUwz_68IvL for ; Tue, 18 Nov 2014 10:30:02 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B85C1A1AB9 for ; Tue, 18 Nov 2014 10:30:02 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51011 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XqnXI-0002HT-SQ; Tue, 18 Nov 2014 10:30:00 -0800 Message-ID: <546B9024.8050403@usdonovans.com> Date: Tue, 18 Nov 2014 12:29:56 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" References: <5463AF67.5010009@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iG07-ovy9SbBj0-ART9iHoVfa2U Cc: "dime@ietf.org" Subject: Re: [Dime] -05 of DOIC specification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:30:03 -0000 JJ, I'm in the process of making those changes. I'll send as soon as I have them ready. Regards, Steve On 11/18/14, 12:04 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > Hi Steve > > The last draft_ietf-dime-Ovli text 05 that was distributed is dated Nov 05, and is the last text stored in GitHub. > > Is it possible for you to send the current 05 text integrating the modifications we agreed upon in IETF 91 and in the exchanged mails. > > Thank you. > > Best regards > > JJacques > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoyé : mercredi 12 novembre 2014 20:05 > À : dime@ietf.org > Objet : [Dime] -05 of DOIC specification > > All, > > Here's the txt version of DOIC -05 for use in review. > > Regards, > > Steve > From nobody Thu Nov 20 18:36: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 33EF11A1A64 for ; Thu, 20 Nov 2014 07:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.747 X-Spam-Level: ** X-Spam-Status: No, score=2.747 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_NEUTRAL=0.779, T_HTML_ATTACH=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 3b1wyTqecNOw for ; Thu, 20 Nov 2014 07:04:49 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D09B1A1A00 for ; Thu, 20 Nov 2014 07:03:22 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60102 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XrTGQ-000BgA-Ff for dime@ietf.org; Thu, 20 Nov 2014 07:03:21 -0800 Message-ID: <546E02B6.30108@usdonovans.com> Date: Thu, 20 Nov 2014 09:03:18 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------020808060408070800040300" 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/Y7Hu0K0rpuWuy-c7oK6NHGnwk60 X-Mailman-Approved-At: Thu, 20 Nov 2014 18:36:36 -0800 Subject: [Dime] Early candidate DOIC-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 15:05:10 -0000 This is a multi-part message in MIME format. --------------020808060408070800040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I've attached an early candidate for the DOIC-05 specification. This change contains the updates discussed at the Honolulu Dime working group meeting, the informal meeting held the next day and comments received via the Dime mailing list. The areas still requiring work are an update to the security considerations section and adding text to the requirement conformance section. These changes have been pushed into github. I have also attached a diff file showing changes from DOIC-04. Regards, Steve --------------020808060408070800040300 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-dime-ovli-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-dime-ovli-05.txt" Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Internet-Draft Broadcom Intended status: Standards Track S. Donovan, Ed. Expires: May 24, 2015 B. Campbell Oracle L. Morand Orange Labs November 20, 2014 Diameter Overload Indication Conveyance draft-ietf-dime-ovli-05.txt Abstract This specification defines a base solution for Diameter Overload Control (DOC), referred to as Diameter Overload Indication Conveyance (DOIC). Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 24, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Korhonen, et al. Expires May 24, 2015 [Page 1] Internet-Draft DOIC November 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 11 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 13 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 14 4.2. Overload Report Processing . . . . . . . . . . . . . . . 15 4.2.1. Overload Control State . . . . . . . . . . . . . . . 15 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 19 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 20 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 21 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 23 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 23 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 24 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 25 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 25 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 25 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 26 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 26 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 27 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 Korhonen, et al. Expires May 24, 2015 [Page 2] Internet-Draft DOIC November 2014 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 30 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 31 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 31 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 32 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Issues left for future specifications . . . . . . . 34 A.1. Additional traffic abatement algorithms . . . . . . . . . 34 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 34 A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 34 Appendix B. Deployment Considerations . . . . . . . . . . . . . 34 Appendix C. Requirements Conformance Analysis . . . . . . . . . 35 Appendix D. Considerations for Applications Integrating the DOIC Solution . . . . . . . . . . . . . . . . . . . . . . 35 D.1. Application Classification . . . . . . . . . . . . . . . 35 D.2. Application Type Overload Implications . . . . . . . . . 36 D.3. Request Transaction Classification . . . . . . . . . . . 37 D.4. Request Type Overload Implications . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This specification defines a base solution for Diameter Overload Control (DOC), referred to as Diameter Overload Indication Conveyance (DOIC). The requirements for the solution are described and discussed in the corresponding design requirements document [RFC7068]. Note that the overload control solution defined in this specification does not address all the requirements listed in [RFC7068]. A number of overload control related features are left for future specifications. See Appendix A for a list of extensions that are currently being considered. See Appendix C for an analysis of conformance to the requirements specified in [RFC7068]. The solution defined in this specification addresses Diameter overload control between Diameter nodes that support the DOIC solution. The solution, which is designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. 2. Terminology and Abbreviations Abatement Korhonen, et al. Expires May 24, 2015 [Page 3] Internet-Draft DOIC November 2014 Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling. Abatement Algorithm A mechanism requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Diversion A mechanism used for overload abatement by selecting a different path for requests. Host-Routed Request The set of requests that a reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. Overload Control State (OCS) Reporting and reacting node internally maintained state describing occurrences of overload control. Overload Report (OLR) Information requesting overload control for a particular overload occurrence sent by a reporting node. Reacting Node A Diameter node that acts upon an overload report. Realm-Routed Request The set of requests that a reacting node does not know the host that will service the request. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Throttling Korhonen, et al. Expires May 24, 2015 [Page 4] Internet-Draft DOIC November 2014 A mechanism for overload abatement that limits the number of requests sent. 3. Solution Overview The Diameter Overload Information Conveyance (DOIC) solution allows Diameter nodes to request other Diameter nodes to perform overload abatement actions, that is, actions to reduce the load offered to the overloaded node or realm. A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including Diameter Clients, Diameter Servers, and Diameter Agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending Overload Reports (OLR). A reacting node acts upon OLRs, and performs whatever actions are needed to fulfill the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other nodes. A Diameter node's role as a DOIC node is independent of its Diameter role. For example, Diameter Agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter Servers can send requests towards Diameter Clients, a given Diameter node can simultaneously act as both a reporting node and a reacting node. Likewise, a Diameter Agent may act as a reacting node from the perspective of upstream nodes, and a reporting node from the perspective of downstream nodes. DOIC nodes do not generate new messages to carry DOIC related information. Rather, they "piggyback" DOIC information over existing Diameter messages by inserting new AVPs into existing Diameter requests and responses. Nodes indicate support for DOIC, and any needed DOIC parameters, by inserting an OC_Supported_Features AVP (Section 6.2) into existing requests and responses. Reporting nodes send OLRs by inserting OC-OLR AVPs (Section 6.3). A given OLR applies to the Diameter realm and application of the Diameter message that carries it. If a reporting node supports more than one realm and/or application, it reports independently for each combination of realm and application. Similarly, the OC-Supported- Features AVP applies to the realm and application of the enclosing Korhonen, et al. Expires May 24, 2015 [Page 5] Internet-Draft DOIC November 2014 message. This implies that a node may support DOIC for one application and/or realm, but not another, and may indicate different DOIC parameters for each application and realm for which it supports DOIC. Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of some of the parameters of an OLR and the procedures required for overload abatement. An overlaod abatement algorithm separates Diameter requests into two sets. The first set contains the requests that are to undergo overload abatement treatment of either throttling or diversion. The second set contains the requests that are to be given normal routing treatment. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. Overload conditions may vary in scope. For example, a single Diameter node may be overloaded, in which case reacting nodes may attempt to send requests to other destinations. On the other hand, an entire Diameter realm may be overloaded, in which case such attempts would do harm. DOIC OLRs have a concept of "report type" (Section 6.6), where the type defines such behaviors. Report types are extensible. This document defines report types for overload of a specific host, and for overload of an entire realm. A report of type "HOST_REPORT" is sent to indicate the overload of a specific host, identified by the Origin-Host AVP of the message containing the OLR, for the application-id indicated in the transaction. When receiving an OLR of type "HOST_REPORT", a reacting node applies overload abatement treatment to the host-routed requests identified by the overload abatement algorithm (see definition in Section 2) sent for this application to the overloaded host. A report of type "REALM_REPORT" is sent to indicate the overload of a realm for the application-id indicated in the transaction. The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR. When receiving an OLR of type "REALM_REPORT", a reacting node applies overload abatement treatment to realm-routed requests identified by the overload abatement algorithm (see definition in Section 2) sent for this application to the overloaded realm. While a reporting node sends OLRs to "adjacent" reacting nodes, nodes that are "adjacent" for DOIC purposes may not be adjacent from a Diameter, or transport, perspective. For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unchanged. The report types described in this Korhonen, et al. Expires May 24, 2015 [Page 6] Internet-Draft DOIC November 2014 document can safely pass through non-supporting agents. This may not be true for report types defined in future specifications. 3.1. Piggybacking Principle The overload control AVPs defined in this specification have been designed to be piggybacked on top of existing application messages. This is made possible by adding overload control AVPs, the OC-OLR AVP and the OC-Supported-Features AVP, as optional AVPs into existing commands when the corresponding Command Code Format (CCF) specification allows adding new optional AVPs (see Section 1.3.4 of [RFC6733]). There is no new Diameter application defined to carry overload related AVPs. The DOIC AVPs are carried in existing Diameter application messages. Reacting nodes indicate support for DOIC by including the OC- Supported-Features AVP in all request messages originated or relayed by the reacting node. Reporting nodes indicate support for DOIC by including the OC- Supported-Features AVP in all answer messages originated or relayed by the reporting node that are in response to a request that contained the OC-Supported-Features AVP. Reporting nodes also include overload reports using the OC-OLR AVP in answer messages. Note that the overload control solution does not have fixed server and client roles. The DOIC node role is determined based on the message type: whether the message is a request (i.e. sent by a "reacting node") or an answer (i.e. send by a "reporting node"). Therefore, in a typical "client-server" deployment, the Diameter Client MAY report its overload condition to the Diameter Server for any Diameter Server initiated message exchange. An example of such is the Diameter Server requesting a re-authentication from a Diameter Client. 3.2. DOIC Capability Announcement The DOIC solution supports the ability for Diameter nodes to determine if other nodes in the path of a request support the solution. This capability is referred to as DOIC Capability Announcement (DCA) and is separate from Diameter Capability Exchange. The DCA mechanism uses the OC-Supported-Features AVPs to indicate the Diameter overload features supported. Korhonen, et al. Expires May 24, 2015 [Page 7] Internet-Draft DOIC November 2014 The first node in the path of a Diameter request that supports the DOIC solution inserts the OC-Supported-Features AVP in the request message. Note: As discussed elsewhere in the document, agents in the path of the request can modify the OC-Supported-Features AVP. Note: The DOIC solution must support deployments where Diameter Clients and/or Diameter Servers do not support the DOIC solution. In this scenario, it is assumed that Diameter Agents that support the DOIC solution will handle overload abatement for the non supporting Diameter nodes. In this case the DOIC agent will insert the OC-Supported-Features AVP in requests that do not already contain one, telling the reporting node that there is a DOIC node that will handle overload abatement. For transactions where there was an OC-Supporting-Features AVP in the request, the agent will insert the OC-Supported-Features AVP in answers, telling the reacting node that there is a reporting node. The OC-Feature-Vector AVP will contain an indication of support for the loss overload abatement algorithm defined in this specification (see Section 5). This ensures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting node(s) in the path of the request. The reporting node inserts the OC-Supported-Features AVP in all answer messages to requests that contained the OC-Supported-Features AVP. The contents of the reporting node's OC-Supported-Features AVP indicate the set of Diameter overload features supported by the reporting node with one exception - the reporting node only includes an indication of support for one overload abatement algorithm, independent of the number of overload abatement algorithms actually supported by the reacting node. The overload abatement algorithm indicated is the algorithm that the reporting node intends to use should it enter an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested. Note that the loss algorithm defined in this document is a stateless abatement algorithm. As a result it does not require any actions by reacting nodes prior to the receipt of an overload report. Stateful abatement algorithms that base the abatement logic on a history of request messages sent might require reacting nodes to maintain state in advance of receiving an overload report to ensure that the overload reports can be properly handled. Korhonen, et al. Expires May 24, 2015 [Page 8] Internet-Draft DOIC November 2014 Reporting nodes are allowed to change the overload abatement algorithm indicated in the OC-Feature-Vector AVP if the reporting node is not currently in and overload condition and sending overload reports. The reporting node is not allowed to change the overload abatement algorithm while the reporting node is in an overload load condition. The individual features supported by the DOIC nodes are indicated in the OC-Feature-Vector AVP. Any semantics associated with the features will be defined in extension specifications that introduce the features. The DCA mechanism must also support the scenario where the set of features supported by the sender of a request and by agents in the path of a request differ. In this case, the agent updates the OC- Supported-Features AVP to reflect the mixture of the two sets of supported features. Note: The logic to determine the content of the modified OC- Supported-Features AVP is out-of-scope for this specification and is left to implementation decisions. Care must be taken not to introduce interoperability issues for downstream or upstream DOIC nodes. 3.3. DOIC Overload Condition Reporting As with DOIC Capability Announcement, Overload Condition Reporting uses new AVPs (Section 6.3) to indicate an overload condition. The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs. Two types of overload reports are defined in this document, host reports and realm reports. A report of type host is sent to indicate the overload of a specific Diameter node for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. Realm reports apply to realm-routed requests for a specific realm as indicated in the Destination-Realm AVP. Korhonen, et al. Expires May 24, 2015 [Page 9] Internet-Draft DOIC November 2014 This document assumes that there is a single source for realm-reports for a given realm, or that if multiple nodes can send realm reports, that each such node has full knowledge of the overload state of the entire realm. A reacting node cannot distinguish between receiving realm-reports from a single node, or from multiple nodes. Note: Known issues exist if multiple sources for overload reports exist. Reacting nodes have no way of determining the source and, as such, will treat them as coming from a single source. Variance in sequence numbers between the two sources can then cause incorrect overload abatement treatment to be applied for indeterminate periods of time. Reporting nodes are responsible for determining the need for a reduction of traffic. The method for making this determination is implementation specific and depend on the type of overload report being generated. A host report, for instance, will generally be generated by tracking utilization of resources required by the host to handle transactions for the Diameter application. A realm report will generally impact the traffic sent to multiple hosts and, as such, will typically require tracking the capacity of the servers able to handle realm-routed requests for the application. Once a reporting node determines the need for a reduction in traffic, it uses the DOIC defined AVPs to report on the condition. These AVPs are included in answer messages sent or relayed by the reporting node. The reporting node indicates the overload abatement algorithm that is to be used to handle the traffic reduction in the OC- Supported-Features AVP. The OC-OLR AVP is used to communicate information about the requested reduction. Reacting nodes, upon receipt of an overload report, are responsible for applying the overload abatement algorithm to traffic impacted by the overload report. The method used to determine the requests that are to receive overload abatement treatment is dependent on the abatement algorithm. The loss abatement algorithm is defined in this document (Section 5). Other abatement algorithms can be defined in extensions to the DOIC solutions. Two types of overload abatement treatement are defined, diversion and throttling. Reacting nodes are responsible for determining which treatment is appropraite for individual requests. As the conditions that lead to the generation of the overload report change the reporting node can send new overload reports requesting greater reduction if the condition gets worse or less reduction if the condition improves. The reporting node sends an overload report with a duration of zero to indicate that the overload condition has Korhonen, et al. Expires May 24, 2015 [Page 10] Internet-Draft DOIC November 2014 ended and need for use of the abatement algorithm to reduce traffic sent is no longer needed. The reacting node also determines when the overload report expires based on the OC-Validity-Duration AVP in the overload report and stops applying the abatement algorithm when the report expires. 3.4. DOIC Extensibility The DOIC solution is designed to be extensible. This extensibility is based on existing Diameter based extensibility mechanisms. There are multiple categories of extensions that are expected. This includes the definition of new overload abatement algorithms, the definition of new report types and the definition of new scopes of messages impacted by an overload report. The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes to communicate supported features. The specific features supported by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC extensions that require new normative behavior define new values for the OC-Feature-Vector AVP. DOIC extensions also have the ability to add new AVPs to the OC-Supported-Features AVP, if additional information about the new feature is required. Reporting nodes use the OC-OLR AVP to communicate overload occurrences. This AVP can also be extended to add new AVPs allowing a reporting nodes to communicate additional information about handling an overload condition. If necessary, new extensions can also define new AVPs. It is, however, recommended that DOIC extensions use the OC-Supported- Features AVP and OC-OLR AVP to carry all DOIC related AVPs. 3.5. Simplified Example Architecture Figure 1 illustrates the simplified architecture for Diameter overload information conveyance. Korhonen, et al. Expires May 24, 2015 [Page 11] Internet-Draft DOIC November 2014 Realm X Same or other Realms <--------------------------------------> <----------------------> +--^-----+ : (optional) : |Diameter| : : |Server A|--+ .--. : +---^----+ : .--. +--------+ | _( `. : |Diameter| : _( `. +---^----+ +--( )--:-| Agent |-:--( )--|Diameter| +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Server B| : : +---^----+ : : End-to-end Overload Indication 1) <-----------------------------------------------> Diameter Application Y Overload Indication A Overload Indication A' 2) <----------------------> <----------------------> Diameter Application Y Diameter Application Y Figure 1: Simplified architecture choices for overload indication delivery In Figure 1, the Diameter overload indication can be conveyed (1) end-to-end between servers and clients or (2) between servers and Diameter agent inside the realm and then between the Diameter agent and the clients. 4. Solution Procedures This section outlines the normative behavior for the DOIC solution. 4.1. Capability Announcement This section defines DOIC Capability Announcement (DCA) behavior. 4.1.1. Reacting Node Behavior A reacting node MUST include the OC-Supported-Features AVP in all request messages. A reacting node MAY include the OC-Feature-Vector AVP with an indication of the loss algorithm. Korhonen, et al. Expires May 24, 2015 [Page 12] Internet-Draft DOIC November 2014 If a reacting node includes the OC-Feature-Vector AVP then it MUST indicate support for the loss algorithm. A reacting node MUST include the OC-Feature-Vector AVP to indicate support for abatement algorithms in addition to the loss algorithm. A reacting node MUST indicate support in the OC-Feature-Vector AVP for all features the reacting node is configured to use. An OC-Supported-Features AVP in answer messages indicates there is a reporting node for the transaction. The reacting node MAY take action based on the features indicated in the OC-Feature-Vector AVP. Note: The loss abatement algorithm is the only feature described in this document and it does not require action to be taken when there is no active overload report. This behavior is described in Section 4.2 and Section 5. 4.1.2. Reporting Node Behavior Upon receipt of a request message, a reporting node determines if there is a reacting node for the transaction based on the presence of the OC-Supported-Features AVP in the request message. If the request message contains an OC-Supported-Features AVP then a reporting node MUST include the OC-Supported-Features AVP in the answer message for that transaction. A reporting node MUST NOT include the OC-Supported-Features AVP, OC- OLR AVP or any other overload control AVPs defined in extension drafts in response messages for transactions where the request message does not include the OC-Supported-Features AVP. Lack of the OC-Supported-Features AVP in the request message indicates that there is no reacting node for the transaction. A reporting node knows what overload control functionality is supported by the reacting node based on the content of the OC- Supported-Features AVP in the request message. A reporting node MUST indicate support for one and only one abatement algorithm in the OC-Supported-Features AVP. The abatement algorithm selected MUST indicate the abatement algorithm the reporting node wants the reacting node to use when the reporting node enters an overload condition. The abatement algorithm selected MUST be from the set of abatement algorithms contained in the request message's OC-Supported-Features AVP. Korhonen, et al. Expires May 24, 2015 [Page 13] Internet-Draft DOIC November 2014 A reporting node MAY indicate selection of the loss algorithm defined in this document by omitting the OC-Feature-Vector AVP. If the reporting node selects an algorithm other than the loss algorithm then the reporting node must indicate the selected overload abatement algorithm in the OC-Feature-Vector AVP. For an ongoing overload condition, a reporting node MUST NOT change the selected algorithm during the period of time that it is in an overload condition and, as a result, is sending OC-OLR AVPs in answer messages. The reporting node MAY change the overload abatement algorithm indicated in the OC-Supported-Features AVP when it is not in an overload condition and sending overload reports. The reporting node SHOULD indicate support for other DOIC features defined in extension drafts that it supports and that apply to the transaction. Note: Not all DOIC features will apply to all Diameter applications or deployment scenarios. The features included in the OC-Feature-Vector AVP are based on local reporting node policy. 4.1.3. Agent Behavior Diameter Agents that support DOIC SHOULD ensure that all messages relayed by the agent contain the OC-Supported-Features AVP. A Diameter Agent SHOULD take on reacting node behavior for Diameter endpoints that do not support the DOIC solution. A Diameter Agent detects that a Diameter endpoint does not support DOIC reacting node behavior when there is no OC-Supported-Features AVP in a request message. For a Diameter Agent to be a reacting node for a non supporting Diameter endpoint, the Diameter Agent MUST include the OC-Supported- Features vector in request messages it receives that do not contain the OC-Supported-Features AVP. A Diameter Agent SHOULD take on reporting node behavior for Diameter endpoints that do not support the DOIC solution. A Diameter Agent detects that a Diameter endpoint does not support DOIC reporting node behavior when there is no OC-Supported-Features AVP in an answer message for a transaction that contained the OC-Supported-Features AVP in the request message. Korhonen, et al. Expires May 24, 2015 [Page 14] Internet-Draft DOIC November 2014 For a Diameter Agent to take on reporting node behavior for a non supporting Diameter endpoint the Diameter Agent MUST include the OC- Supported-Features vector in answer messages it receives that do not contain the OC-Supported-Features AVP. As with a Diameter endpoint taking on reporting node behavior, a Diameter Agent MUST only include the OC-Supported-Features AVP in answer messages for transactions where the request message received by the Diameter Agent had an OC-Supported-Features AVP. If a request message already has the OC-Supported-Features AVP then a Diameter Agent MAY leave it unchanged in the relayed message or MAY modify it to reflect the features appropriate for the transaction. For instance, if the agent supports a superset of the features reported by the reacting node then the agent might choose, based on local policy, to advertise that superset of features to the reporting node. If the Diameter Agent changes the OC-Supported-Features AVP in a request message then it is likely it will also need to modify the OC- Supported-Features AVP in the answer message for the transaction. As such, a Diameter Agent MAY modify the OC-Supported-Features AVP carried in answer messages. When making changes to the OC-Supported-Features AVP the Diameter Agent needs to ensure that there is no ambiguity in DOIC behavior for both upstream and downstream DOIC nodes. 4.2. Overload Report Processing 4.2.1. Overload Control State Both reacting and reporting nodes maintain Overload Control State (OCS) for active overload conditions. The following sections define behavior associated with that OCS. 4.2.1.1. Overload Control State for Reacting Nodes A reacting node SHOULD maintain the following OCS per supported Diameter application: o A host-type OCS entry for each Destination-Host to which it sends host-type requests and o A realm-type OCS entry for each Destination-Realm to which it sends realm-type requests. Korhonen, et al. Expires May 24, 2015 [Page 15] Internet-Draft DOIC November 2014 A host-type OCS entry is identified by the pair of application-id and the node's DiameterIdentity. A realm-type OCS entry is identified by the pair of application-d and realm. The host-type and realm-type OCS entries MAY include the following information (the actual information stored is an implementation decision): o Sequence number (as received in OC-OLR) o Time of expiry (derived from OC-Validity-Duration AVP received in the OC-OLR AVP and time of reception of the message carrying OC- OLR AVP) o Selected Abatement Algorithm (as received in the OC-Supported- Features AVP) o Abatement Algorithm specific input data (as received in the OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss abatement algorithm) 4.2.1.2. Overload Control State for Reporting Nodes A reporting node SHOULD maintain OCS entries per supported Diameter application, per supported (and eventually selected) Abatement Algorithm and per report-type. An OCS entry is identified by the tuple of Application-Id, Report- Type and Abatement Algorithm and MAY include the following information (the actual information stored is an implementation decision): o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) 4.2.1.3. Reacting Node Maintenance of Overload Control State When a reacting node receives an OC-OLR AVP, it MUST determine if it is for an existing or new overload condition. Korhonen, et al. Expires May 24, 2015 [Page 16] Internet-Draft DOIC November 2014 Note: For the remainder of this section the term OLR refers to the combination of the contents of the received OC-OLR AVP and the abatement algorithm indicated in the received OC-Supported- Features AVP. The OLR is for an existing overload condition if a reacting node has an OCS that matches the received OLR. For a host report-type this means it matches the application-id and the host's DiameterIdentity in an existing host OCS entry. For a realm report-type this means it matches the application-id and the realm in an existing realm OCS entry. If the OLR is for an existing overload condition then a reacting node MUST determine if the OLR is a retransmission or an update to the existing OLR. If the sequence number for the received OLR is greater than the sequence number stored in the matching OCS entry then a reacting node MUST update the matching OCS entry. If the sequence number for the received OLR is less than or equal to the sequence number in the matching OCS entry then a reacting node MUST silently ignore the received OLR. The matching OCS MUST NOT be updated in this case. If the received OLR is for a new overload condition then a reacting node MUST generate a new OCS entry for the overload condition. For a host report-type this means a reacting node creates on OCS entry with the application-id in the received message and DiameterIdentity of the Origin-Host in the received message. Note: This solution assumes that the Origin-Host AVP in the answer message included by the reporting node is not changed along the path to the reacting node. For a realm report-type this means a reacting node creates on OCS entry with the application-id in the received message and realm of the Origin-Realm in the received message. If the received OLR contains a validity duration of zero ("0") then a reacting node MUST update the OCS entry as being expired. Note: It is not necessarily appropriate to delete the OCS entry, as there is recommended behavior that the reacting node slowly returns to full traffic when ending an overload abatement period. Korhonen, et al. Expires May 24, 2015 [Page 17] Internet-Draft DOIC November 2014 The reacting node does not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). 4.2.1.4. Reporting Node Maintenance of Overload Control State A reporting node SHOULD create a new OCS entry when entering an overload condition. Note: If a reporting node knows through absence of the OC- Supported-Features AVP in received messages that there are no reacting nodes supporting DOIC then the reporting node can choose to not create OCS entries. When generating a new OCS entry the sequence number SHOULD be set to zero ("0"). When generating sequence numbers for new overload conditions, the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report for the same application and report-type previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. Note: One way of addressing this over a reboot of a reporting node is to use a time stamp for the first overload condition that occurs after the report and to start using sequence numbers of zero for subsequent overload conditions. A reporting node MUST update an OCS entry when it needs to adjust the validity duration of the overload condition at reacting nodes. For instance, if a reporting node wishes to instruct reacting nodes to continue overload abatement for a longer period of time than originally communicated. This also applies if the reporting node wishes to shorten the period of time that overload abatement is to continue. A reporting node MUST NOT update the abatement algorithm in an active OCS entry. A reporting node MUST update an OCS entry when it wishes to adjust any abatement algorithm specific parameters, including the reduction percentage used for the Loss abatement algorithm. For instance, if a reporting node wishes to change the reduction percentage either higher, if the overload condition has worsened, or lower, if the overload condition has improved, then the reporting node would update the appropriate OCS entry. Korhonen, et al. Expires May 24, 2015 [Page 18] Internet-Draft DOIC November 2014 A reporting node MUST update the sequence number associated with the OCS entry anytime the contents of the OCS entry are changed. This will result in a new sequence number being sent to reacting nodes, instructing reacting nodes to process the OC-OLR AVP. A reporting node SHOULD update an OCS entry with a validity duration of zero ("0") when the overload condition ends. Note: If a reporting node knows that the OCS entries in the reacting nodes are near expiration then the reporting node might decide not to send an OLR with a validity duration of zero. A reporting node MUST keep an OCS entry with a validity duration of zero ("0") for a period of time long enough to ensure that any non- expired reacting node's OCS entry created as a result of the overload condition in the reporting node is deleted. 4.2.2. Reacting Node Behavior When a reacting node sends a request it MUST determine if that request matches an active OCS. If the request matches an active OCS then the reacting node MUST use the overload abatement algorithm incideated in the OCS to determine if the request is to receive overload abatement treatment. For the Loss abatement algorithm defined in this specification, see Section 5 for the overload abatement algorithm logic applied. If the overload abatement algorithm selects the request for overload abatement treatment then the reacting node MUST apply overload abatement treatment on the request. The abatement treatment applied depends on the context of the request. If the request is a host-routed request then the reacting node SHOULD apply throttling abatement treatment to the request. If the request is a realm-routed request then the reacting node SHOULD apply diversion abatement treatment to the request. If the overload abatement treatment results in throttling of the request and if the reacting node is an agent then the agent MUST send an appropriate error as defined in Section 7. The behavior of reacting nodes that are Diameter endpoints when throttling requests depends on the application and is outside the scope of this specification. Korhonen, et al. Expires May 24, 2015 [Page 19] Internet-Draft DOIC November 2014 In the case that the OCS entry indicated no traffic was to be sent to the overloaded entity and the validity duration expires or has a validity duration of zero ("0"), meaning that the reporting node has explicitly signaled the end of the overload condition then overlaod abatement associated with the overload abatement MUST be ended in a controlled fashion. 4.2.3. Reporting Node Behavior If there is an active OCS entry then a reporting node SHOULD include the OC-OLR AVP in all answer messages to requests that contain the OC-Supported-Features AVP and that match the active OCS entry. Note: A request matches if the application-id in the request matches the application-id in any active OCS entry and if the report-type in the OCS entry matches a report-type supported by the reporting node as indicated in the OC-Supported-Features AVP. The contents of the OC-OLR AVP MUST contain all information necessary for the abatement algorithm indicated in the OC-Supported-Features AVP that is also included in the answer message. A reporting node MAY choose to not resend an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node. Note: In some cases (e.g. when there are one or more agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) a reporting node may not be able to guarantee that the reacting node has received the report. A reporting node MUST NOT send overload reports of a type that has not been advertised as supported by the reacting node. Note: A reacting node implicitly advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types will be explicitly indicated by new feature bits in the OC-Feature-Vector AVP. A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. A reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero Korhonen, et al. Expires May 24, 2015 [Page 20] Internet-Draft DOIC November 2014 ("0"). The reporting node SHOULD ensure that all reacting nodes receive the updated overload report. Note: All OLRs sent have an expiration time calculated by adding the validity-duration contained in the OLR to the time the message was sent. Transit time for the OLR can be safely ignored. The reporting node can ensure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload condition have expired. When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. Therefore, the reporting node SHOULD NOT apply overload related throttling to the set of messages to which the sent OLR applies. That is, the same candidate set of messages SHOULD NOT be throttled multiple times. However, when the reporting node sends an OLR downstream, it MAY still be responsible to apply other abatement methods such as diversion. The reporting node might also need to throttle requests for reasons other than overload. For example, an agent or server might have a configured rate limit for each client, and throttle requests that exceed that limit, even if such requests had already been candidates for throttling by downstream nodes. A reporting node SHOULD decrease requested overload abatement treatment in a controlled fashion to avoid occillations in traffic. 4.3. Protocol Extensibility The DOIC solution can be extended. Types of potential extensions include new traffic abatement algorithms, new report types or other new functionality. When defining a new extension that requires new normative behavior, a new feature bit MUST be defined for the OC-Feature-Vector. This feature bit is used to communicate support for the new feature. The extension MAY define new AVPs for use in DOIC Capability Announcement and for use in DOIC Overload reporting. These new AVPs SHOULD be defined to be extensions to the OC-Supported-Features and OC-OLR AVPs defined in this document. [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing application. Korhonen, et al. Expires May 24, 2015 [Page 21] Internet-Draft DOIC November 2014 The handling of feature bits in the OC-Feature-Vector AVP that are not associated with overload abatement algorithms MUST be specified by the extensions that define the features. When defining new report type values, the corresponding specification MUST define the semantics of the new report types and how they affect the OC-OLR AVP handling. The specification MUST also reserve a corresponding new feature bit in the OC-Feature-Vector AVP. The OC-OLR AVP can be expanded with optional sub-AVPs only if a legacy DOIC implementation can safely ignore them without breaking backward compatibility for the given OC-Report-Type AVP value. If the new sub-AVPs imply new semantics for handling the indicated report type, then a new OC-Report-Type AVP value MUST be defined. Documents that introduce new report types MUST describe any limitations on their use across non-supporting agents. New features (feature bits in the OC-Feature-Vector AVP) and report types (in the OC-Report-Type AVP) MUST be registered with IANA. As with any Diameter specification, new AVPs MUST also be registered with IANA. See Section 8 for the required procedures. 5. Loss Algorithm This section documents the Diameter overload loss abatement algorithm. 5.1. Overview The DOIC specification supports the ability for multiple overload abatement algorithms to be specified. The abatement algorithm used for any instance of overload is determined by the Diameter Overload Capability Announcement process documented in Section 4.1. The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes use a strategy of applying abatement logic to the requested percentage of request messages sent (or handled in the case of agents) by the reacting node that are impacted by the overload report. Korhonen, et al. Expires May 24, 2015 [Page 22] Internet-Draft DOIC November 2014 From a conceptual level, the logic at the reacting node could be outlined as follows. 1. An overload report is received and the associated OCS is either saved or updated (if required) by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request, as indicated by the corresponding OCS entry. 4. The reacting node determines if overload abatement treatment should be applied to the request. One approach that could be taken for each request is to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. 5.2. Reporting Node Behavior The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. When a reporting node that has selected the loss abatement algorithm determines the need to request a reduction in traffic, it includes an OC-OLR AVP in response messages as described in Section 4.2.3. When sending the OC-OLR AVP, the reporting node MUST indicate a percentage reduction in the OC-Reduction-Percentage AVP. The reporting node MAY change the reduction percentage in subsequent overload reports. When doing so the reporting node must conform to overload report handing specified in Section 4.2.3. When the reporting node determines it no longer needs a reduction in traffic the reporting node SHOULD send an overload report indicating the overload report is no longer valid, as specified in Section 4.2.3. 5.3. Reacting Node Behavior The method a reacting node uses to determine which request messages are given abatement treatment is an implementation decision. Korhonen, et al. Expires May 24, 2015 [Page 23] Internet-Draft DOIC November 2014 When receiving an OC-OLR in an answer message where the algorithm indicated in the OC-Supported-Features AVP is the loss algorithm, the reacting node MUST apply abatement treatment to the requested percentage of request messages sent. Note: The loss algorithm is a stateless algorithm. As a result, the reacting node does not guarantee that there will be an absolute reduction in traffic sent. Rather, it guarantees that the requested percentage of new requests will be given abatement treatment. When applying overload abatement treatment for the load abatement algorithm, the reacting node MUST abate, either by throttling or diversion, the requested percentage of requests that would have otherwise been sent to the reporting host or realm. If reacting node comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The reacting node sending the traffic should be conservative and, for example, first send "probe" messages to learn the overload condition of the overloaded node before converging to any traffic amount/rate decided by the sender. Similar concerns apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. If the reacting node does not receive an OLR in messages sent to the formerly overloaded node then the reacting node SHOULD slowly increase the rate of traffic sent to the overloaded node. When an active overload report expires, it is suggested that the reacting node progressively decrease the amount of traffic given abatement treatment, until the reduction is completely removed and no traffic is given abatement treatment. The goal of this behavior is to reduce the probability of overload condition thrashing where an immediate transition from 100% reduction to 0% reduction results in the reporting node moving quickly back into an overload condition. 6. Attribute Value Pairs This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification Korhonen, et al. Expires May 24, 2015 [Page 24] Internet-Draft DOIC November 2014 normatively. It is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. 6.1. OC-Supported-Features AVP The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and serves two purposes. First, it announces a node's support for the DOIC solution in general. Second, it contains the description of the supported DOIC features of the sending node. The OC-Supported- Features AVP MUST be included in every Diameter request message a DOIC supporting node sends. OC-Supported-Features ::= < AVP Header: TBD1 > [ OC-Feature-Vector ] * [ AVP ] The OC-Feature-Vector sub-AVP is used to announce the DOIC features supported by the DOIC node, in the form of a flag-bits field in which each bit announces one feature or capability supported by the node (see Section 6.2). The absence of the OC-Feature-Vector AVP indicates that only the default traffic abatement algorithm described in this specification is supported. 6.2. OC-Feature-Vector AVP The OC-Feature-Vector AVP (AVP code TBD6) is of type Unsigned64 and contains a 64 bit flags field of announced capabilities of a DOIC node. The value of zero (0) is reserved. The following capabilities are defined in this document: OLR_DEFAULT_ALGO (0x0000000000000001) When this flag is set by the a DOIC reacting node it means that the default traffic abatement (loss) algorithm is supported. When this flag is set by a DOIC reporting node it means that the loss algorithm will be used for requested overload abatement. 6.3. OC-OLR AVP The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the information necessary to convey an overload report on an overload condition at the reporting node. The OC-OLR AVP does not explicitly contain all information needed by the reacting node to decide whether a subsequent request must undergo abatement using the received reduction percentage. The value of the OC-Report-Type AVP within the Korhonen, et al. Expires May 24, 2015 [Page 25] Internet-Draft DOIC November 2014 OC-OLR AVP indicates which implicit information is relevant for this decision (see Section 6.6). The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The host or realm the OC-OLR AVP concerns is determined from the Origin-Host AVP and/or Origin-Realm AVP found in the encapsulating Diameter command. The OC-OLR AVP is intended to be sent only by a reporting node. OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ] Note that if a Diameter command were to contain multiple OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs with unknown values SHOULD be silently discarded by reacting nodes and the event SHOULD be logged. 6.4. OC-Sequence-Number AVP The OC-Sequence-Number AVP (AVP code TBD3) is of type Unsigned64. Its usage in the context of overload control is described in Section 4.2. From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. The sequence number is only required to be unique between two DOIC nodes. Sequence numbers are treated in a uni- directional manner, i.e. two sequence numbers on each direction between two DOIC nodes are not related or correlated. 6.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is of type Unsigned32 and indicates in milliseconds the validity time of the overload report. The number of milliseconds is measured after reception of the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. The default value for the OC-Validity-Duration AVP is 30000 (i.e.; 30 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Korhonen, et al. Expires May 24, 2015 [Page 26] Internet-Draft DOIC November 2014 6.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is of type Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: HOST_REPORT 0 The overload report is for a host. Overload abatement treatment applies to host-routed requests. REALM_REPORT 1 The overload report is for a realm. Overload abatement treatment applies to realm-routed requests. 6.7. OC-Reduction-Percentage AVP The OC-Reduction-Percentage AVP (AVP code TBD8) is of type Unsigned32 and describes the percentage of the traffic that the sender is requested to reduce, compared to what it otherwise would send. The OC-Reduction-Percentage AVP applies to the default (loss) algorithm specified in this specification. However, the AVP can be reused for future abatement algorithms, if its semantics fit into the new algorithm. The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored. The value of 100 means that all traffic is to be throttled, i.e. the reporting node is under a severe load and ceases to process any new messages. The value of 0 means that the reporting node is in a stable state and has no need for the reacting node to apply any traffic abatement. The default value of the OC-Reduction-Percentage AVP is 0. When the OC-Reduction-Percentage AVP is not present in the overload report, the default value applies. 6.8. Attribute Value Pair flag rules Korhonen, et al. Expires May 24, 2015 [Page 27] Internet-Draft DOIC November 2014 +---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------+----+----+ |OC-Supported-Features TBD1 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-OLR TBD2 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number TBD3 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration TBD4 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type TBD5 x.x Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage TBD8 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector TBD6 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. 7. Error Response Codes When a DOIC node rejects a Diameter request due to overload, the DOIC node MUST select an appropriate error response code. This determination is made based on the probability of the request succeeding if retried on a different path. A reporting node rejecting a Diameter request due to an overload condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can assume that the same request may succeed on a different path. If a reporting node knows or assumes that the same request will not succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response SHOULD be used. Retrying would consume valuable resources during an occurrence of overload. For instance, if the request arrived at the reporting node without a Destination-Host AVP then the reporting node might determine that there is an alternative Diameter node that could successfully process the request and that retrying the transaction would not Korhonen, et al. Expires May 24, 2015 [Page 28] Internet-Draft DOIC November 2014 negatively impact the reporting node. DIAMETER_TOO_BUSY would be sent in this case. If the request arrived at the reporting node with a Destination- Host AVP populated with its own Diameter identity then the reporting node can assume that retrying the request would result in it coming to the same reporting node. DIAMETER_UNABLE_TO_COMPLY would be sent in this case. A second example is when an agent that supports the DOIC solution is performing the role of a reacting node for a non supporting client. Requests that are rejected as a result of DOIC throttling by the agent in this scenario would generally be rejected with a DIAMETER_UNABLE_TO_COMPLY response code. 8. IANA Considerations 8.1. AVP codes New AVPs defined by this specification are listed in Section 6. All AVP codes allocated from the 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP Codes registry. 8.2. New registries Two new registries are needed under the 'Authentication, Authorization, and Accounting (AAA) Parameters' registry. Section 6.2 defines a new "Overload Control Feature Vector" registry including the initial assignments. New values can be added into the registry using the Specification Required policy [RFC5226]. See Section 6.2 for the initial assignment in the registry. Section 6.6 defines a new "Overload Report Type" registry with its initial assignments. New types can be added using the Specification Required policy [RFC5226]. 9. Security Considerations Editor's Note: This section requires review and updating to reflect updates made to the rest of the document. This mechanism gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly affect this reduction. This exchange is potentially subject to multiple methods of attack, and has the potential to be used as a Denial-of-Service (DoS) attack vector. Korhonen, et al. Expires May 24, 2015 [Page 29] Internet-Draft DOIC November 2014 Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid its use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. 9.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively hop-by-hop trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer. Agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct a response. Therefore, implementations SHOULD validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report. A similar attack involves an otherwise authorized Diameter node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that Korhonen, et al. Expires May 24, 2015 [Page 30] Internet-Draft DOIC November 2014 a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from a peer that applies to a realm not handled by that peer is suspect. An attacker might use the information in an overload report to assist in certain attacks. For example, an attacker could use information about current overload conditions to time a DoS attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. 9.2. Denial of Service Attacks Diameter overload reports can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS tacks. Furthermore, since Diameter is almost always used in support of other protocols, a DoS attack on Diameter is likely to impact those protocols as well. Therefore, Diameter nodes MUST NOT honor or forward overload reports from unauthorized or otherwise untrusted sources. 9.3. Non-Compliant Nodes When a Diameter node sends an overload report, it cannot assume that all nodes will comply. A non-compliant node might continue to send requests with no reduction in load. Requirement 28 [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are necessarily trusted, and that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service. In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might reject a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. Korhonen, et al. Expires May 24, 2015 [Page 31] Internet-Draft DOIC November 2014 9.4. End-to End-Security Issues The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. At the time of this writing, the DIME working group is studying requirements for adding end-to-end security [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, when they become available, might make it easier to establish trust in non-adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism encourages Diameter agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and are beyond the scope of this document. 10. Contributors The following people contributed substantial ideas, feedback, and discussion to this document: o Eric McMurry o Hannes Tschofenig Korhonen, et al. Expires May 24, 2015 [Page 32] Internet-Draft DOIC November 2014 o Ulrich Wiehe o Jean-Jacques Trottin o Maria Cruz Bartolome o Martin Dolly o Nirav Salot o Susan Shishufeng 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 11.2. Informative References [Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013. [I-D.ietf-dime-e2e-sec-req] Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, "Diameter AVP Level Security: Scenarios and Requirements", draft-ietf-dime-e2e-sec-req-00 (work in progress), September 2013. [PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. Korhonen, et al. Expires May 24, 2015 [Page 33] Internet-Draft DOIC November 2014 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, November 2013. [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. Appendix A. Issues left for future specifications The base solution for the overload control does not cover all possible use cases. A number of solution aspects were intentionally left for future specification and protocol work. The following sub- sections define some of the potential extensions to the DOIC solution. A.1. Additional traffic abatement algorithms This specification describes only means for a simple loss based algorithm. Future algorithms can be added using the designed solution extension mechanism. The new algorithms need to be registered with IANA. See Sections 6.1 and 8 for the required IANA steps. A.2. Agent Overload This specification focuses on Diameter endpoint (server or client) overload. A separate extension will be required to outline the handling of the case of agent overload. A.3. New Error Diagnostic AVP The proposal was made to add a new Error Diagnostic AVP to supplement the error responses to be able to indicate that overload was the reason for the rejection of the message. Appendix B. Deployment Considerations Non Supporting Agents Due to the way that realm-routed requests are handled in Diameter networks, with the server selection for the request done by an agent, it is recommended that deployments enable all agents that do server selection to support the DOIC solution prior to enabling the DOIC solution in the Diameter network. Topology Hiding Interactions Korhonen, et al. Expires May 24, 2015 [Page 34] Internet-Draft DOIC November 2014 There exist proxies that implement what is referred to as Topology Hiding. This can include cases where the agent modifies the Origin-Host in answer messages. The behavior of the DOIC solution is not well understood when this happens. As such, the DOIC solution does not address this scenario. Appendix C. Requirements Conformance Analysis This section contains the result of an analysis of the DOIC solutions conformance to the requirements defined in [RFC7068]. Editor's Note: To be completed. Appendix D. Considerations for Applications Integrating the DOIC Solution This section outlines considerations to be taken into account when integrating the DOIC solution into Diameter applications. D.1. Application Classification The following is a classification of Diameter applications and request types. This discussion is meant to document factors that play into decisions made by the Diameter identity responsible for handling overload reports. Section 8.1 of [RFC6733] defines two state machines that imply two types of applications, session-less and session-based applications. The primary difference between these types of applications is the lifetime of Session-Ids. For session-based applications, the Session-Id is used to tie multiple requests into a single session. The Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application. In session-less applications, the lifetime of the Session-Id is a single Diameter transaction, i.e. the session is implicitly terminated after a single Diameter transaction and a new Session-Id is generated for each Diameter request. For the purposes of this discussion, session-less applications are further divided into two types of applications: Stateless Applications: Korhonen, et al. Expires May 24, 2015 [Page 35] Internet-Draft DOIC November 2014 Requests within a stateless application have no relationship to each other. The 3GPP defined S13 application is an example of a stateless application [S13], where only a Diameter command is defined between a client and a server and no state is maintained between two consecutive transactions. Pseudo-Session Applications: Applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use other session-related information in the Diameter requests for this purpose. The 3GPP defined Cx application [Cx] is an example of a pseudo-session application. The handling of overload reports must take the type of application into consideration, as discussed in Appendix D.2. D.2. Application Type Overload Implications This section discusses considerations for mitigating overload reported by a Diameter entity. This discussion focuses on the type of application. Appendix D.3 discusses considerations for handling various request types when the target server is known to be in an overloaded state. These discussions assume that the strategy for mitigating the reported overload is to reduce the overall workload sent to the overloaded entity. The concept of applying overload treatment to requests targeted for an overloaded Diameter entity is inherent to this discussion. The method used to reduce offered load is not specified here but could include routing requests to another Diameter entity known to be able to handle them, or it could mean rejecting certain requests. For a Diameter agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests will depend upon the application. For example, it could mean giving an indication to the entity requesting the Diameter service that the network is busy and to try again later. Stateless Applications: By definition there is no relationship between individual requests in a stateless application. As a result, when a request is sent or relayed to an overloaded Diameter entity - either a Diameter Server or a Diameter Agent - the sending or relaying entity can choose to apply the overload treatment to any request targeted for the overloaded entity. Korhonen, et al. Expires May 24, 2015 [Page 36] Internet-Draft DOIC November 2014 Pseudo-Session Applications: For pseudo-session applications, there is an implied ordering of requests. As a result, decisions about which requests towards an overloaded entity to reject could take the command code of the request into consideration. This generally means that transactions later in the sequence of transactions should be given more favorable treatment than messages earlier in the sequence. This is because more work has already been done by the Diameter network for those transactions that occur later in the sequence. Rejecting them could result in increasing the load on the network as the transactions earlier in the sequence might also need to be repeated. Session-Based Applications: Overload handling for session-based applications must take into consideration the work load associated with setting up and maintaining a session. As such, the entity sending requests towards an overloaded Diameter entity for a session-based application might tend to reject new session requests prior to rejecting intra-session requests. In addition, session ending requests might be given a lower probability of being rejected as rejecting session ending requests could result in session status being out of sync between the Diameter clients and servers. Application designers that would decide to reject mid-session requests will need to consider whether the rejection invalidates the session and any resulting session cleanup procedures. D.3. Request Transaction Classification Independent Request: An independent request is not correlated to any other requests and, as such, the lifetime of the session-id is constrained to an individual transaction. Session-Initiating Request: A session-initiating request is the initial message that establishes a Diameter session. The ACR message defined in [RFC6733] is an example of a session-initiating request. Correlated Session-Initiating Request: There are cases when multiple session-initiated requests must be correlated and managed by the same Diameter server. It is notably the case in the 3GPP PCC architecture [PCC], where multiple Korhonen, et al. Expires May 24, 2015 [Page 37] Internet-Draft DOIC November 2014 apparently independent Diameter application sessions are actually correlated and must be handled by the same Diameter server. Intra-Session Request: An intra session request is a request that uses the same Session- Id than the one used in a previous request. An intra session request generally needs to be delivered to the server that handled the session creating request for the session. The STR message defined in [RFC6733] is an example of an intra-session requests. Pseudo-Session Requests: Pseudo-session requests are independent requests and do not use the same Session-Id but are correlated by other session-related information contained in the request. There exists Diameter applications that define an expected ordering of transactions. This sequencing of independent transactions results in a pseudo session. The AIR, MAR and SAR requests in the 3GPP defined Cx [Cx] application are examples of pseudo-session requests. D.4. Request Type Overload Implications The request classes identified in Appendix D.3 have implications on decisions about which requests should be throttled first. 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. The exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. Independent Requests: Independent requests can generally be given equal treatment when making throttling decisions, unless otherwise indicated by application requirements or local policy. Session-Initiating Requests: Session-initiating requests often represent more work than independent or intra-session requests. Moreover, session- initiating requests are typically followed by other session- related requests. Since the main objective of the overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. In the absence of local policies or application specific requirements to Korhonen, et al. Expires May 24, 2015 [Page 38] Internet-Draft DOIC November 2014 the contrary, Individual session-initiating requests can be given equal treatment when making throttling decisions. Correlated Session-Initiating Requests: A Request that results in a new binding, where the binding is used for routing of subsequent session-initiating requests to the same server, represents more work load than other requests. As such, these requests might be throttled more frequently than other request types. Pseudo-Session Requests: Throttling decisions for pseudo-session requests can take into consideration where individual requests fit into the overall sequence of requests within the pseudo session. Requests that are earlier in the sequence might be throttled more aggressively than requests that occur later in the sequence. Intra-Session Requests: There are two types of intra-sessions requests, requests that terminate a session and the remainder of intra-session requests. Implementers and operators may choose to throttle session- terminating requests less aggressively in order to gracefully terminate sessions, allow cleanup of the related resources (e.g. session state) and avoid the need for additional intra-session requests. Favoring session-termination requests may reduce the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making throttling decisions. There might also be application level considerations whether some request types are favored over others. Authors' Addresses Jouni Korhonen (editor) Broadcom Porkkalankatu 24 Helsinki FIN-00180 Finland Email: jouni.nospam@gmail.com Korhonen, et al. Expires May 24, 2015 [Page 39] Internet-Draft DOIC November 2014 Steve Donovan (editor) Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: srdonovan@usdonovans.com Ben Campbell Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: ben@nostrum.com Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33145296257 Email: lionel.morand@orange.com Korhonen, et al. Expires May 24, 2015 [Page 40] --------------020808060408070800040300 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-05.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-05."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-05.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-05.txt >
Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed.
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Standards Track S. Donovan, Ed. Intended status: Standards Track S. Donovan, Ed.
Expires: April 30, 2015 B. Campbell Expires: May 24, 2015 B. Campbell
Oracle Oracle
L. Morand L. Morand
Orange Labs Orange Labs
October 27, 2014 November 20, 2014
Diameter Overload Indication Conveyance Diameter Overload Indication Conveyance
draft-ietf-dime-ovli-04.txt draft-ietf-dime-ovli-05.txt
Abstract Abstract
This specification documents a Diameter Overload Control (DOC) base This specification defines a base solution for Diameter Overload
solution and the dissemination of the overload report information. Control (DOC), referred to as Diameter Overload Indication Conveyance
(DOIC).
Requirements Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 41 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015. This Internet-Draft will expire on May 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 8 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 11
3.5. Simplified Example Architecture . . . . . . . . . . . . . 11 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 13
4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 14
4.2. Overload Report Processing . . . . . . . . . . . . . . . 14 4.2. Overload Report Processing . . . . . . . . . . . . . . . 15
4.2.1. Overload Control State . . . . . . . . . . . . . . . 14 4.2.1. Overload Control State . . . . . . . . . . . . . . . 15
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 18 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 19
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 18 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 20
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 20 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 21
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 22 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 23
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 23
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 24
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 25
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 25
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 26
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 26
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 27
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 30
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 31
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 31
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 32
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Issues left for future specifications . . . . . . . 33 Appendix A. Issues left for future specifications . . . . . . . 34
A.1. Additional traffic abatement algorithms . . . . . . . . . 33 A.1. Additional traffic abatement algorithms . . . . . . . . . 34
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 34
A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 33 A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 34
Appendix B. Deployment Considerations . . . . . . . . . . . . . 34 Appendix B. Deployment Considerations . . . . . . . . . . . . . 34
Appendix C. Requirements Conformance Analysis . . . . . . . . . 34 Appendix C. Requirements Conformance Analysis . . . . . . . . . 35
Appendix D. Considerations for Applications Integrating the DOIC Appendix D. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 34 Solution . . . . . . . . . . . . . . . . . . . . . . 35
D.1. Application Classification . . . . . . . . . . . . . . . 34 D.1. Application Classification . . . . . . . . . . . . . . . 35
D.2. Application Type Overload Implications . . . . . . . . . 35 D.2. Application Type Overload Implications . . . . . . . . . 36
D.3. Request Transaction Classification . . . . . . . . . . . 36 D.3. Request Transaction Classification . . . . . . . . . . . 37
D.4. Request Type Overload Implications . . . . . . . . . . . 37 D.4. Request Type Overload Implications . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), referred to as Diameter Overload Indication Conveyance Control (DOC), referred to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
for the future specifications. See Appendix A for a list of for future specifications. See Appendix A for a list of extensions
extensions that are currently being considered. See Appendix C for that are currently being considered. See Appendix C for an analysis
an analysis of the conformance to the requirements specified in of conformance to the requirements specified in [RFC7068].
[RFC7068].
The solution defined in this specification addresses Diameter The solution defined in this specification addresses Diameter
overload control between Diameter nodes that support the DOIC overload control between Diameter nodes that support the DOIC
solution. Furthermore, the solution which is designed to apply to solution. The solution, which is designed to apply to existing and
existing and future Diameter applications, requires no changes to the future Diameter applications, requires no changes to the Diameter
Diameter base protocol [RFC6733] and is deployable in environments base protocol [RFC6733] and is deployable in environments where some
where some Diameter nodes do not implement the Diameter overload Diameter nodes do not implement the Diameter overload control
control solution defined in this specification. solution defined in this specification.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Abatement Abatement
Reaction to receipt of an overload report resulting in a reduction Reaction to receipt of an overload report resulting in a reduction
in traffic sent to the reporting node. Abatement actions include in traffic sent to the reporting node. Abatement actions include
diversion and throttling. diversion and throttling.
Abatement Algorithm Abatement Algorithm
An mechanism requested by reporting nodes and used by reacting A mechanism requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of nodes to reduce the amount of traffic sent during an occurrence of
overload control. overload control.
Diversion Diversion
Abatement of traffic sent to a reporting node by a reacting node A mechanism used for overload abatement by selecting a different
in response to receipt of an overload report. The abatement is path for requests.
achieved by diverting traffic from the reporting node to another
Diameter node that is able to process the request.
Host-Routed Request Host-Routed Request
The set of requests that a reacting node knows will be served by a The set of requests that a reacting node knows will be served by a
particular host, either due to the presence of a Destination-Host particular host, either due to the presence of a Destination-Host
AVP, or by some other local knowledge on the part of the reacting AVP, or by some other local knowledge on the part of the reacting
node. node.
Overload Control State (OCS) Overload Control State (OCS)
Reporting and reacting node internally maintained state describing Reporting and reacting node internally maintained state describing
occurrences of overload control. occurrences of overload control.
Overload Report (OLR) Overload Report (OLR)
Information sent by a reporting node indicating the start, Information requesting overload control for a particular overload
continuation or end of an occurrence of overload control. occurrence sent by a reporting node.
Reacting Node Reacting Node
A Diameter node that acts upon an overload report. A Diameter node that acts upon an overload report.
Realm-Routed Request Realm-Routed Request
The set of requests that a reacting node does not know the host The set of requests that a reacting node does not know the host
that will service the request. that will service the request.
Reporting Node Reporting Node
A Diameter node that generates an overload report. (This may or A Diameter node that generates an overload report. (This may or
may not be the overloaded node.) may not be the overloaded node.)
Throttling Throttling
A mechanism for overload abatement that limits the number of
Throttling is the reduction of the number of requests sent to an requests sent.
entity. Throttling can include a Diameter Client or Diameter
Server dropping requests, or a Diameter Agent rejecting requests
with appropriate error responses. In extreme cases reporting
nodes can also throttle requests when the requested reductions in
traffic does not sufficiently address the overload scenario.
3. Solution Overview 3. Solution Overview
The Diameter Overload Information Conveyance (DOIC) solution allows The Diameter Overload Information Conveyance (DOIC) solution allows
Diameter nodes to request other nodes to perform overload abatement Diameter nodes to request other Diameter nodes to perform overload
actions, that is, actions to reduce the load offered to the abatement actions, that is, actions to reduce the load offered to the
overloaded node or realm. overloaded node or realm.
A Diameter node that supports DOIC is known as a "DOIC node". Any A Diameter node that supports DOIC is known as a "DOIC node". Any
Diameter node can act as a DOIC node, including clients, servers, and Diameter node can act as a DOIC node, including Diameter Clients,
agents. DOIC nodes are further divided into "Reporting Nodes" and Diameter Servers, and Diameter Agents. DOIC nodes are further
"Reacting Nodes." A reporting node requests overload abatement by divided into "Reporting Nodes" and "Reacting Nodes." A reporting
sending an Overload Report (OLR) to one or more reacting nodes. node requests overload abatement by sending Overload Reports (OLR).
A reacting node acts upon OLRs, and performs whatever actions are A reacting node acts upon OLRs, and performs whatever actions are
needed to fulfil the abatement requests included in the OLRs. A needed to fulfill the abatement requests included in the OLRs. A
Reporting node may report overload on its own behalf, or on behalf of Reporting node may report overload on its own behalf, or on behalf of
other (typically upstream) nodes. Likewise, a reacting node may other nodes. Likewise, a reacting node may perform overload
perform overload abatement on its own behalf, or on behalf of other abatement on its own behalf, or on behalf of other nodes.
(typically downstream) nodes.
A node's role as a DOIC node is independent of its Diameter role. A Diameter node's role as a DOIC node is independent of its Diameter
For example, Diameter Relay and Proxy Agents may act as DOIC nodes, role. For example, Diameter Agents may act as DOIC nodes, even
even though they are not endpoints in the Diameter sense. Since though they are not endpoints in the Diameter sense. Since Diameter
Diameter enables bi-directional applications, where Diameter Servers enables bi-directional applications, where Diameter Servers can send
can send requests towards Diameter Clients, a given Diameter node can requests towards Diameter Clients, a given Diameter node can
simultaneously act as a reporting node and a reacting node. simultaneously act as both a reporting node and a reacting node.
Likewise, a relay or proxy agent may act as a reacting node from the Likewise, a Diameter Agent may act as a reacting node from the
perspective of upstream nodes, and a reporting node from the perspective of upstream nodes, and a reporting node from the
perspective of downstream nodes. perspective of downstream nodes.
DOIC nodes do not generate new messages to carry DOIC related DOIC nodes do not generate new messages to carry DOIC related
information. Rather, they "piggyback" DOIC information over existing information. Rather, they "piggyback" DOIC information over existing
Diameter messages by inserting new AVPs into existing Diameter Diameter messages by inserting new AVPs into existing Diameter
requests and responses. Nodes indicate support for DOIC, and any requests and responses. Nodes indicate support for DOIC, and any
needed DOIC parameters by inserting an OC_Supported_Features AVP needed DOIC parameters, by inserting an OC_Supported_Features AVP
(Section 6.2) into existing requests and responses. Reporting nodes (Section 6.2) into existing requests and responses. Reporting nodes
send OLRs by inserting OC-OLR AVPs (Section 6.3). send OLRs by inserting OC-OLR AVPs (Section 6.3).
A given OLR applies to the Diameter realm and application of the A given OLR applies to the Diameter realm and application of the
Diameter message that carries it. If a reporting node supports more Diameter message that carries it. If a reporting node supports more
than one realm and/or application, it reports independently for each than one realm and/or application, it reports independently for each
combination of realm and application. Similarly, the OC-Supported- combination of realm and application. Similarly, the OC-Supported-
Features AVP applies to the realm and application of the enclosing Features AVP applies to the realm and application of the enclosing
message. This implies that a node may support DOIC for one message. This implies that a node may support DOIC for one
application and/or realm, but not another, and may indicate different application and/or realm, but not another, and may indicate different
DOIC parameters for each application and realm for which it supports DOIC parameters for each application and realm for which it supports
DOIC. DOIC.
Reacting nodes perform overload abatement according to an agreed-upon Reacting nodes perform overload abatement according to an agreed-upon
abatement algorithm. An abatement algorithm defines the meaning of abatement algorithm. An abatement algorithm defines the meaning of
the parameters of an OLR and the procedures required for overload some of the parameters of an OLR and the procedures required for
abatement. This document specifies a single must-support algorithm, overload abatement. An overlaod abatement algorithm separates
namely the "loss" algorithm (Section 5). Future specifications may Diameter requests into two sets. The first set contains the requests
introduce new algorithms. that are to undergo overload abatement treatment of either throttling
or diversion. The second set contains the requests that are to be
given normal routing treatment. This document specifies a single
must-support algorithm, namely the "loss" algorithm (Section 5).
Future specifications may introduce new algorithms.
Overload conditions may vary in scope. For example, a single Overload conditions may vary in scope. For example, a single
Diameter node may be overloaded, in which case reacting nodes may Diameter node may be overloaded, in which case reacting nodes may
reasonably attempt to send requests to other destinations or via attempt to send requests to other destinations. On the other hand,
other agents. On the other hand, an entire Diameter realm may be an entire Diameter realm may be overloaded, in which case such
overloaded, in which case such attempts would do harm. DOIC OLRs attempts would do harm. DOIC OLRs have a concept of "report type"
have a concept of "report type" (Section 6.6), where the type defines (Section 6.6), where the type defines such behaviors. Report types
such behaviors. Report types are extensible. This document defines are extensible. This document defines report types for overload of a
report types for overload of a specific server, and for overload of specific host, and for overload of an entire realm.
an entire realm.
A report of type host is sent to indicate the overload of a specific A report of type "HOST_REPORT" is sent to indicate the overload of a
server for the application-id indicated in the transaction. When specific host, identified by the Origin-Host AVP of the message
receiving an OLR of type host, a reacting node applies overload containing the OLR, for the application-id indicated in the
abatement to what is referred to in this document as host-routed transaction. When receiving an OLR of type "HOST_REPORT", a reacting
requests. This is the set of requests that the reacting node knows node applies overload abatement treatment to the host-routed requests
will be served by a particular host, either due to the presence of a identified by the overload abatement algorithm (see definition in
Destination-Host AVP, or by some other local knowledge on the part of Section 2) sent for this application to the overloaded host.
the reacting node. The reacting node applies overload abatement on
those host-routed requests which the reacting node knows will be
served by the server that matches the Origin-Host AVP of the received
message that contained the received OLR of type host.
A report type of realm is sent to indicate the overload of all A report of type "REALM_REPORT" is sent to indicate the overload of a
servers in a realm for the application-id. When receiving an OLR of realm for the application-id indicated in the transaction. The
type realm, a reacting node applies overload abatement to what is overloaded realm is identified by the Destination-Realm AVP of the
referred to in this document as realm-routed requests. This is the message containing the OLR. When receiving an OLR of type
set of requests that are not host-routed as defined in the previous "REALM_REPORT", a reacting node applies overload abatement treatment
paragraph. to realm-routed requests identified by the overload abatement
algorithm (see definition in Section 2) sent for this application to
the overloaded realm.
While a reporting node sends OLRs to "adjacent" reacting nodes, nodes While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
that are "adjacent" for DOIC purposes may not be adjacent from a that are "adjacent" for DOIC purposes may not be adjacent from a
Diameter, or transport, perspective. For example, one or more Diameter, or transport, perspective. For example, one or more
Diameter agents that do not support DOIC may exist between a given Diameter agents that do not support DOIC may exist between a given
pair of reporting and reacting nodes, as long as those agents pass pair of reporting and reacting nodes, as long as those agents pass
unknown AVPs through unchanged. The report types described in this unknown AVPs through unchanged. The report types described in this
document can safely pass through non-supporting agents. This may not document can safely pass through non-supporting agents. This may not
be true for report types defined in future specifications. Documents be true for report types defined in future specifications.
that introduce new report types MUST describe any limitations on
their use across non-supporting agents.
3.1. Piggybacking Principle 3.1. Piggybacking Principle
The overload control AVPs defined in this specification have been The overload control AVPs defined in this specification have been
designed to be piggybacked on top of existing application messages. designed to be piggybacked on top of existing application messages.
This is made possible by adding overload control top-level AVPs, the This is made possible by adding overload control AVPs, the OC-OLR AVP
OC-OLR AVP and the OC-Supported-Features AVP, as optional AVPs into and the OC-Supported-Features AVP, as optional AVPs into existing
existing commands when the corresponding Command Code Format (CCF) commands when the corresponding Command Code Format (CCF)
specification allows adding new optional AVPs (see Section 1.3.4 of specification allows adding new optional AVPs (see Section 1.3.4 of
[RFC6733]). [RFC6733]).
There is no new Diameter application defined to carry overload
related AVPs. The DOIC AVPs are carried in existing Diameter
application messages.
Reacting nodes indicate support for DOIC by including the OC- Reacting nodes indicate support for DOIC by including the OC-
Supported-Features AVP in all request messages originated or relayed Supported-Features AVP in all request messages originated or relayed
by the reacting node. by the reacting node.
Reporting nodes indicate support for DOIC by including the OC- Reporting nodes indicate support for DOIC by including the OC-
Supported-Features AVP in all answer messages originated or relayed Supported-Features AVP in all answer messages originated or relayed
by the reporting node. Reporting nodes also include overload reports by the reporting node that are in response to a request that
using the OC-OLR AVP in answer messages. contained the OC-Supported-Features AVP. Reporting nodes also
include overload reports using the OC-OLR AVP in answer messages.
Note: There is no new Diameter application defined to carry
overload related AVPs. The DOIC AVPs are carried in existing
Diameter application messages.
Note that the overload control solution does not have fixed server Note that the overload control solution does not have fixed server
and client roles. The DOIC node role is determined based on the and client roles. The DOIC node role is determined based on the
message type: whether the message is a request (i.e. sent by a message type: whether the message is a request (i.e. sent by a
"reacting node") or an answer (i.e. send by a "reporting node"). "reacting node") or an answer (i.e. send by a "reporting node").
Therefore, in a typical "client-server" deployment, the Diameter Therefore, in a typical "client-server" deployment, the Diameter
Client MAY report its overload condition to the Diameter Server for Client MAY report its overload condition to the Diameter Server for
any Diameter Server initiated message exchange. An example of such any Diameter Server initiated message exchange. An example of such
is the Diameter Server requesting a re-authentication from a Diameter is the Diameter Server requesting a re-authentication from a Diameter
Client. Client.
3.2. DOIC Capability Announcement 3.2. DOIC Capability Announcement
The DOIC solution supports the ability for Diameter nodes to The DOIC solution supports the ability for Diameter nodes to
determine if other nodes in the path of a request support the determine if other nodes in the path of a request support the
solution. This capability is referred to as DOIC Capability solution. This capability is referred to as DOIC Capability
Announcement (DCA) and is separate from Diameter Capability Exchange. Announcement (DCA) and is separate from Diameter Capability Exchange.
The DCA solution uses the OC-Supported-Features AVPs to indicate the The DCA mechanism uses the OC-Supported-Features AVPs to indicate the
Diameter overload features supported. Diameter overload features supported.
The first node in the path of a Diameter request that supports the The first node in the path of a Diameter request that supports the
DOIC solution inserts the OC-Supported-Feature AVP in the request DOIC solution inserts the OC-Supported-Features AVP in the request
message. This includes an indication that it supports the loss message.
overload abatement algorithm defined in this specification (see
Section 5). This ensures that there is at least one commonly
supported overload abatement algorithm between the reporting node and
the reacting nodes in the path of the request.
DOIC must support deployments where Diameter Clients and/or Note: As discussed elsewhere in the document, agents in the path
Diameter Servers do not support the DOIC solution. In this of the request can modify the OC-Supported-Features AVP.
scenario, it is assumed that Diameter Agents that support the DOIC
solution will handle overload abatement for the non supporting
Diameter nodes. In this case the DOIC agent will insert the OC-
Supporting-Features AVP in requests that do not already contain
one, telling the reporting node that there is a DOIC node that
will handle overload abatement.
The reporting node inserts the OC-Supported-Feature AVP in all answer Note: The DOIC solution must support deployments where Diameter
messages to requests that contained the OC-Supported-Feature AVP. Clients and/or Diameter Servers do not support the DOIC solution.
The contents of the reporting node's OC-Supported-Feature AVP In this scenario, it is assumed that Diameter Agents that support
indicate the set of Diameter overload features supported by the the DOIC solution will handle overload abatement for the non
reporting node with one exception. supporting Diameter nodes. In this case the DOIC agent will
insert the OC-Supported-Features AVP in requests that do not
already contain one, telling the reporting node that there is a
DOIC node that will handle overload abatement. For transactions
where there was an OC-Supporting-Features AVP in the request, the
agent will insert the OC-Supported-Features AVP in answers,
telling the reacting node that there is a reporting node.
The reporting node only includes an indication of support for one The OC-Feature-Vector AVP will contain an indication of support for
overload abatement algorithm. This is the algorithm that the the loss overload abatement algorithm defined in this specification
reporting node intends to use should it enter an overload condition (see Section 5). This ensures that there is at least one commonly
or requests to use while it actually is in an overload condition. supported overload abatement algorithm between the reporting node and
Reacting nodes can use the indicated overload abatement algorithm to the reacting node(s) in the path of the request.
prepare for possible overload reports and must use the indicated
overload abatement algorithm if traffic reduction is actually The reporting node inserts the OC-Supported-Features AVP in all
requested. answer messages to requests that contained the OC-Supported-Features
AVP. The contents of the reporting node's OC-Supported-Features AVP
indicate the set of Diameter overload features supported by the
reporting node with one exception - the reporting node only includes
an indication of support for one overload abatement algorithm,
independent of the number of overload abatement algorithms actually
supported by the reacting node. The overload abatement algorithm
indicated is the algorithm that the reporting node intends to use
should it enter an overload condition. Reacting nodes can use the
indicated overload abatement algorithm to prepare for possible
overload reports and must use the indicated overload abatement
algorithm if traffic reduction is actually requested.
Note that the loss algorithm defined in this document is a Note that the loss algorithm defined in this document is a
stateless abatement algorithm. As a result it does not require stateless abatement algorithm. As a result it does not require
any actions by reacting nodes prior to the receipt of an overload any actions by reacting nodes prior to the receipt of an overload
report. Stateful abatement algorithms that base the abatement report. Stateful abatement algorithms that base the abatement
logic on a history of request messages sent might require reacting logic on a history of request messages sent might require reacting
nodes to maintain state to ensure that overload reports can be nodes to maintain state in advance of receiving an overload report
properly handled. to ensure that the overload reports can be properly handled.
Reporting nodes are allowed to change the overload abatement
algorithm indicated in the OC-Feature-Vector AVP if the reporting
node is not currently in and overload condition and sending overload
reports. The reporting node is not allowed to change the overload
abatement algorithm while the reporting node is in an overload load
condition.
The individual features supported by the DOIC nodes are indicated in The individual features supported by the DOIC nodes are indicated in
the OC-Feature-Vector AVP. Any semantics associated with the the OC-Feature-Vector AVP. Any semantics associated with the
features will be defined in extension specifications that introduce features will be defined in extension specifications that introduce
the features. the features.
The DCA mechanism must also support the scenario where the set of The DCA mechanism must also support the scenario where the set of
features supported by the sender of a request and by agents in the features supported by the sender of a request and by agents in the
path of a request differ. In this case, the agent updates the OC- path of a request differ. In this case, the agent updates the OC-
Supported-Feature AVP to reflect the mixture of the two sets of Supported-Features AVP to reflect the mixture of the two sets of
supported features. supported features.
The logic to determine the content of the modified OC-Supported- Note: The logic to determine the content of the modified OC-
Feature AVP is out-of-scope for this specification and is left to Supported-Features AVP is out-of-scope for this specification and
implementation decisions. Care must be taken not to introduce is left to implementation decisions. Care must be taken not to
interoperability issues for downstream or upstream DOIC nodes. introduce interoperability issues for downstream or upstream DOIC
nodes.
3.3. DOIC Overload Condition Reporting 3.3. DOIC Overload Condition Reporting
As with DOIC Capability Announcement, Overload Condition Reporting As with DOIC Capability Announcement, Overload Condition Reporting
uses new AVPs (Section 6.3) to indicate an overload condition. uses new AVPs (Section 6.3) to indicate an overload condition.
The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP
includes the type of report, a sequence number, the length of time includes the type of report, a sequence number, the length of time
that the report is valid and abatement algorithm specific AVPs. that the report is valid and abatement algorithm specific AVPs.
Two types of overload reports are defined in this document, host Two types of overload reports are defined in this document, host
reports and realm reports. reports and realm reports.
A report of type host is sent to indicate the overload of a specific A report of type host is sent to indicate the overload of a specific
Diameter node for the application-id indicated in the transaction. Diameter node for the application-id indicated in the transaction.
When receiving an OLR of type host, a reacting node applies overload When receiving an OLR of type host, a reacting node applies overload
abatement to what is referred to in this document as host-routed abatement to what is referred to in this document as host-routed
requests. This is the set of requests that the reacting node knows requests. The reacting node applies overload abatement on those
will be served by a particular host, either due to the presence of a host-routed requests which the reacting node knows will be served by
Destination-Host AVP, or by some other local knowledge on the part of the server that matches the Origin-Host AVP of the received message
the reacting node. The reacting node applies overload abatement on that contained the received OLR of type host.
those host-routed requests which the reacting node knows will be
served by the server that matches the Origin-Host AVP of the received
message that contained the received OLR of type host.
Realm reports apply to realm-routed requests for a specific realm as Realm reports apply to realm-routed requests for a specific realm as
indicated in the Destination-Realm AVP. indicated in the Destination-Realm AVP.
This document assumes that there is a single source for realm-reports
for a given realm, or that if multiple nodes can send realm reports,
that each such node has full knowledge of the overload state of the
entire realm. A reacting node cannot distinguish between receiving
realm-reports from a single node, or from multiple nodes.
Note: Known issues exist if multiple sources for overload reports
exist. Reacting nodes have no way of determining the source and,
as such, will treat them as coming from a single source. Variance
in sequence numbers between the two sources can then cause
incorrect overload abatement treatment to be applied for
indeterminate periods of time.
Reporting nodes are responsible for determining the need for a Reporting nodes are responsible for determining the need for a
reduction of traffic. The method for making this determination is reduction of traffic. The method for making this determination is
implementation specific and depend on the type of overload report implementation specific and depend on the type of overload report
being generated. A host report, for instance, will generally be being generated. A host report, for instance, will generally be
generated by tracking utilization of resources required by the host generated by tracking utilization of resources required by the host
to handle transactions for the Diameter application. A realm report to handle transactions for the Diameter application. A realm report
will generally impact the traffic sent to multiple hosts and, as will generally impact the traffic sent to multiple hosts and, as
such, will typically require tracking the capacity of the servers such, will typically require tracking the capacity of the servers
able to handle realm-routed requests for the application. able to handle realm-routed requests for the application.
Once a reporting node determines the need for a reduction in traffic, Once a reporting node determines the need for a reduction in traffic,
it uses the DOIC defined AVPs to report on the condition. These AVPs it uses the DOIC defined AVPs to report on the condition. These AVPs
are included in answer messages sent or relayed by the reporting are included in answer messages sent or relayed by the reporting
node. The reporting node indicates the overload abatement algorithm node. The reporting node indicates the overload abatement algorithm
that is to be used to handle the traffic reduction in the OC- that is to be used to handle the traffic reduction in the OC-
Supported-Features AVP. The OC-OLR AVP is used to communicate Supported-Features AVP. The OC-OLR AVP is used to communicate
information about the requested reduction. information about the requested reduction.
Reacting nodes, upon receipt of an overload report, are responsible Reacting nodes, upon receipt of an overload report, are responsible
for applying the abatement algorithm to traffic impacted by the for applying the overload abatement algorithm to traffic impacted by
overload report. The method used for that abatement is dependent on the overload report. The method used to determine the requests that
the abatement algorithm. The loss abatement algorithm is defined in are to receive overload abatement treatment is dependent on the
this document (Section 5). Other abatement algorithms can be defined abatement algorithm. The loss abatement algorithm is defined in this
in extensions to the DOIC solutions. document (Section 5). Other abatement algorithms can be defined in
extensions to the DOIC solutions.
Two types of overload abatement treatement are defined, diversion and
throttling. Reacting nodes are responsible for determining which
treatment is appropraite for individual requests.
As the conditions that lead to the generation of the overload report As the conditions that lead to the generation of the overload report
change the reporting node can send new overload reports requesting change the reporting node can send new overload reports requesting
greater reduction if the condition gets worse or less reduction if greater reduction if the condition gets worse or less reduction if
the condition improves. The reporting node sends an overload report the condition improves. The reporting node sends an overload report
with a duration of zero to indicate that the overload condition has with a duration of zero to indicate that the overload condition has
ended and use of the abatement algorithm is no longer needed. ended and need for use of the abatement algorithm to reduce traffic
sent is no longer needed.
The reacting node also determines when the overload report expires The reacting node also determines when the overload report expires
based on the OC-Validity-Duration AVP in the overload report and based on the OC-Validity-Duration AVP in the overload report and
stops applying the abatement algorithm when the report expires. stops applying the abatement algorithm when the report expires.
3.4. DOIC Extensibility 3.4. DOIC Extensibility
The DOIC solution is designed to be extensible. This extensibility The DOIC solution is designed to be extensible. This extensibility
is based on existing Diameter based extensibility mechanisms. is based on existing Diameter based extensibility mechanisms.
There are multiple categories of extensions that are expected. This There are multiple categories of extensions that are expected. This
includes the definition of new overload abatement algorithms, the includes the definition of new overload abatement algorithms, the
definition of new report types and new definitions of the scope of definition of new report types and the definition of new scopes of
messages impacted by an overload report. messages impacted by an overload report.
The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes
to communicate supported features. The specific features supported to communicate supported features. The specific features supported
by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC
extensions must define new values for the OC-Feature-Vector AVP. extensions that require new normative behavior define new values for
the OC-Feature-Vector AVP. DOIC extensions also have the ability to
DOIC extensions also have the ability to add new AVPs to the OC- add new AVPs to the OC-Supported-Features AVP, if additional
Supported-Features AVP, if additional information about the new information about the new feature is required.
feature is required.
Reporting nodes use the OC-OLR AVP to communicate overload Reporting nodes use the OC-OLR AVP to communicate overload
occurrences. This AVP can also be extended to add new AVPs allowing occurrences. This AVP can also be extended to add new AVPs allowing
a reporting nodes to communicate additional information about a reporting nodes to communicate additional information about
handling an overload condition. handling an overload condition.
If necessary, new extensions can also define new top-level AVPs. It If necessary, new extensions can also define new AVPs. It is,
is, however, recommended that DOIC extensions use the OC-Supported- however, recommended that DOIC extensions use the OC-Supported-
Features and OC-OLR to carry all DOIC related AVPs. Features AVP and OC-OLR AVP to carry all DOIC related AVPs.
3.5. Simplified Example Architecture 3.5. Simplified Example Architecture
Figure 1 illustrates the simplified architecture for Diameter Figure 1 illustrates the simplified architecture for Diameter
overload information conveyance. overload information conveyance.
Realm X Same or other Realms Realm X Same or other Realms
<--------------------------------------> <----------------------> <--------------------------------------> <---------------------->
+--^-----+ : (optional) : +--^-----+ : (optional) :
skipping to change at page 11, line 42 skipping to change at page 12, line 24
|Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+
|Server B| : : |Server B| : :
+---^----+ : : +---^----+ : :
End-to-end Overload Indication End-to-end Overload Indication
1) <-----------------------------------------------> 1) <----------------------------------------------->
Diameter Application Y Diameter Application Y
Overload Indication A Overload Indication A' Overload Indication A Overload Indication A'
2) <----------------------> <----------------------> 2) <----------------------> <---------------------->
standard base protocol standard base protocol Diameter Application Y Diameter Application Y
Figure 1: Simplified architecture choices for overload indication Figure 1: Simplified architecture choices for overload indication
delivery delivery
In Figure 1, the Diameter overload indication can be conveyed (1) In Figure 1, the Diameter overload indication can be conveyed (1)
end-to-end between servers and clients or (2) between servers and end-to-end between servers and clients or (2) between servers and
Diameter agent inside the realm and then between the Diameter agent Diameter agent inside the realm and then between the Diameter agent
and the clients. and the clients.
4. Solution Procedures 4. Solution Procedures
This section outlines the normative behavior associated with the DOIC This section outlines the normative behavior for the DOIC solution.
solution.
4.1. Capability Announcement 4.1. Capability Announcement
This section defines DOIC Capability Announcement (DCA) behavior. This section defines DOIC Capability Announcement (DCA) behavior.
4.1.1. Reacting Node Behavior 4.1.1. Reacting Node Behavior
A reacting node MUST include the OC-Supported-Features AVP in all A reacting node MUST include the OC-Supported-Features AVP in all
request messages. request messages.
A reacting node MAY include the OC-Feature-Vector AVP with an A reacting node MAY include the OC-Feature-Vector AVP with an
indication of the loss algorithm. A reacting node MUST include the indication of the loss algorithm.
OC-Feature-Vector AVP to indicate support for abatement algorithms in
addition to the loss algorithm.
A reacting node SHOULD indicate support for all other DOIC features If a reacting node includes the OC-Feature-Vector AVP then it MUST
it supports. indicate support for the loss algorithm.
Not all DOIC features will necessarily apply to all transactions. A reacting node MUST include the OC-Feature-Vector AVP to indicate
For instance, there may be a future extension that only applies to support for abatement algorithms in addition to the loss algorithm.
session based applications. A reacting node that supports this
extension can choose to not include it for non session based A reacting node MUST indicate support in the OC-Feature-Vector AVP
applications. for all features the reacting node is configured to use.
An OC-Supported-Features AVP in answer messages indicates there is a An OC-Supported-Features AVP in answer messages indicates there is a
reporting node for the transaction. The reacting node MAY take reporting node for the transaction. The reacting node MAY take
action based on the features indicated in the OC-Feature-Vector AVP. action based on the features indicated in the OC-Feature-Vector AVP.
Note that the loss abatement algorithm is the only feature Note: The loss abatement algorithm is the only feature described
described in this document and it does not require action to be in this document and it does not require action to be taken when
taken when there is an active overload report. This behavior is there is no active overload report. This behavior is described in
described in Section 4.2 and Section 5. Section 4.2 and Section 5.
4.1.2. Reporting Node Behavior 4.1.2. Reporting Node Behavior
Upon receipt of a request message, a reporting node determines if Upon receipt of a request message, a reporting node determines if
there is a reacting node for the transaction based on the presence of there is a reacting node for the transaction based on the presence of
the OC-Supported-Features AVP. the OC-Supported-Features AVP in the request message.
If the request message contains an OC-Supported-Features AVP then the If the request message contains an OC-Supported-Features AVP then a
reporting node MUST include the OC-Supported-Features AVP in the reporting node MUST include the OC-Supported-Features AVP in the
answer message for that transaction. answer message for that transaction.
The reporting node MUST NOT include the OC-Supported-Features AVP, A reporting node MUST NOT include the OC-Supported-Features AVP, OC-
OC-OLR AVP or any other overload control AVPs defined in extension OLR AVP or any other overload control AVPs defined in extension
drafts in response messages for transactions where the request drafts in response messages for transactions where the request
message does not include the OC-Supported-Features AVP. Lack of the message does not include the OC-Supported-Features AVP. Lack of the
OC-Supported-Features AVP in the request message indicates that there OC-Supported-Features AVP in the request message indicates that there
is no reacting node for the transaction. is no reacting node for the transaction.
Based on the content of the OC-Supported-Features AVP in the request A reporting node knows what overload control functionality is
message, the reporting node knows what overload control functionality supported by the reacting node based on the content of the OC-
is supported by the reacting node. The reporting node then acts Supported-Features AVP in the request message.
accordingly for the subsequent answer messages it initiates.
The reporting node MUST indicate support for one and only one A reporting node MUST indicate support for one and only one abatement
abatement algorithm in the OC-Feature-Vector AVP. The abatement algorithm in the OC-Supported-Features AVP. The abatement algorithm
algorithm included MUST be from the set of abatement algorithms selected MUST indicate the abatement algorithm the reporting node
contained in the request message's OC-Supported-Features AVP. The wants the reacting node to use when the reporting node enters an
abatement algorithm included MUST indicate the abatement algorithm overload condition.
the reporting node wants the reacting node to use when the reporting
node enters an overload condition.
For an ongoing overload state, a reacting node MUST keep the The abatement algorithm selected MUST be from the set of abatement
algorithm that was selected by the reporting node in further requests algorithms contained in the request message's OC-Supported-Features
towards the reporting node. The reporting node SHOULD NOT change the AVP.
selected algorithm during a period of time that it is in an overload
condition and, as a result, is sending OC-OLR AVPs in answer A reporting node MAY indicate selection of the loss algorithm defined
in this document by omitting the OC-Feature-Vector AVP. If the
reporting node selects an algorithm other than the loss algorithm
then the reporting node must indicate the selected overload abatement
algorithm in the OC-Feature-Vector AVP.
For an ongoing overload condition, a reporting node MUST NOT change
the selected algorithm during the period of time that it is in an
overload condition and, as a result, is sending OC-OLR AVPs in answer
messages. messages.
The reporting node MAY change the overload abatement algorithm
indicated in the OC-Supported-Features AVP when it is not in an
overload condition and sending overload reports.
The reporting node SHOULD indicate support for other DOIC features The reporting node SHOULD indicate support for other DOIC features
defined in extension drafts that it supports and that apply to the defined in extension drafts that it supports and that apply to the
transaction. transaction.
Note that not all DOIC features will apply to all Diameter Note: Not all DOIC features will apply to all Diameter
applications or deployment scenarios. The features included in applications or deployment scenarios. The features included in
the OC-Feature-Vector AVP are based on local reporting node the OC-Feature-Vector AVP are based on local reporting node
policy. policy.
4.1.3. Agent Behavior 4.1.3. Agent Behavior
Diameter agents that support DOIC MUST ensure that all messages have Diameter Agents that support DOIC SHOULD ensure that all messages
the OC-Supporting-Features AVP. If a message handled by the DOIC relayed by the agent contain the OC-Supported-Features AVP.
agent does not include the OC-Supported-Features AVP then the DOIC
agent inserts the AVP. If the message already has the AVP then the
agent either leaves it unchanged in the relayed message or modifies
it to reflect a mixed set of DOIC features.
An agent MAY modify the OC-Supported-Features AVP carried in answer A Diameter Agent SHOULD take on reacting node behavior for Diameter
messages. endpoints that do not support the DOIC solution. A Diameter Agent
detects that a Diameter endpoint does not support DOIC reacting node
behavior when there is no OC-Supported-Features AVP in a request
message.
For a Diameter Agent to be a reacting node for a non supporting
Diameter endpoint, the Diameter Agent MUST include the OC-Supported-
Features vector in request messages it receives that do not contain
the OC-Supported-Features AVP.
A Diameter Agent SHOULD take on reporting node behavior for Diameter
endpoints that do not support the DOIC solution. A Diameter Agent
detects that a Diameter endpoint does not support DOIC reporting node
behavior when there is no OC-Supported-Features AVP in an answer
message for a transaction that contained the OC-Supported-Features
AVP in the request message.
For a Diameter Agent to take on reporting node behavior for a non
supporting Diameter endpoint the Diameter Agent MUST include the OC-
Supported-Features vector in answer messages it receives that do not
contain the OC-Supported-Features AVP.
As with a Diameter endpoint taking on reporting node behavior, a
Diameter Agent MUST only include the OC-Supported-Features AVP in
answer messages for transactions where the request message received
by the Diameter Agent had an OC-Supported-Features AVP.
If a request message already has the OC-Supported-Features AVP then a
Diameter Agent MAY leave it unchanged in the relayed message or MAY
modify it to reflect the features appropriate for the transaction.
For instance, if the agent supports a superset of the features For instance, if the agent supports a superset of the features
reported by the reacting node then the agent might choose, based reported by the reacting node then the agent might choose, based
on local policy, to advertise that superset of features to the on local policy, to advertise that superset of features to the
reporting node. reporting node.
If the agent modifies the OC-Supported-Features AVP sent to the If the Diameter Agent changes the OC-Supported-Features AVP in a
reporting node then it might also need to modify the OC-Supported- request message then it is likely it will also need to modify the OC-
Features AVP sent to a reacting node in the subsequent answer Supported-Features AVP in the answer message for the transaction. As
message, as it cannot send an indication of support for features such, a Diameter Agent MAY modify the OC-Supported-Features AVP
that are not supported by the reacting node. carried in answer messages.
Editor's note: There is an open issue on the wording around agent When making changes to the OC-Supported-Features AVP the Diameter
behavior in this case that needs to be resolved prior to finishing Agent needs to ensure that there is no ambiguity in DOIC behavior for
this document. both upstream and downstream DOIC nodes.
4.2. Overload Report Processing 4.2. Overload Report Processing
4.2.1. Overload Control State 4.2.1. Overload Control State
Both reacting and reporting nodes maintain Overload Control State Both reacting and reporting nodes maintain Overload Control State
(OCS) for active overload conditions. (OCS) for active overload conditions. The following sections define
behavior associated with that OCS.
4.2.1.1. Overload Control State for Reacting Nodes 4.2.1.1. Overload Control State for Reacting Nodes
A reacting node SHOULD maintain the following OCS per supported A reacting node SHOULD maintain the following OCS per supported
Diameter application: Diameter application:
o A host-type OCS entry for each Destination-Host to which it sends o A host-type OCS entry for each Destination-Host to which it sends
host-type requests and host-type requests and
o A realm-type OCS entry for each Destination-Realm to which it o A realm-type OCS entry for each Destination-Realm to which it
sends realm-type requests. sends realm-type requests.
A host-type OCS entry is identified by the pair of Application-Id and A host-type OCS entry is identified by the pair of application-id and
Host-Id. the node's DiameterIdentity.
A realm-type OCS entry is identified by the pair of Application-Id A realm-type OCS entry is identified by the pair of application-d and
and Realm-Id. realm.
The host-type and realm-type OCS entries MAY include the following The host-type and realm-type OCS entries MAY include the following
information (the actual information stored is an implementation information (the actual information stored is an implementation
decision): decision):
o Sequence number (as received in OC-OLR) o Sequence number (as received in OC-OLR)
o Time of expiry (derived from OC-Validity-Duration AVP received in o Time of expiry (derived from OC-Validity-Duration AVP received in
the OC-OLR AVP and time of reception of the message carrying OC- the OC-OLR AVP and time of reception of the message carrying OC-
OLR AVP) OLR AVP)
o Selected Abatement Algorithm (as received in OC-Supported-Features o Selected Abatement Algorithm (as received in the OC-Supported-
AVP) Features AVP)
o Abatement Algorithm specific input data (as received within the o Abatement Algorithm specific input data (as received in the OC-OLR
OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss AVP, for example, OC-Reduction-Percentage for the Loss abatement
abatement algorithm) algorithm)
4.2.1.2. Overload Control State for Reporting Nodes 4.2.1.2. Overload Control State for Reporting Nodes
A reporting node SHOULD maintain OCS entries per supported Diameter A reporting node SHOULD maintain OCS entries per supported Diameter
application, per supported (and eventually selected) Abatement application, per supported (and eventually selected) Abatement
Algorithm and per report-type. Algorithm and per report-type.
An OCS entry is identified by the pair of Application-Id and An OCS entry is identified by the tuple of Application-Id, Report-
Abatement Algorithm. Type and Abatement Algorithm and MAY include the following
information (the actual information stored is an implementation
The OCS entry for a given pair of Application and Abatement Algorithm decision):
MAY include the information (the actual information stored is an
implementation decision):
o Report type
o Sequence number o Sequence number
o Validity Duration o Validity Duration
o Expiration Time o Expiration Time
o Algorithm specific input data (for example, the Reduction o Algorithm specific input data (for example, the Reduction
Percentage for the Loss Abatement Algorithm) Percentage for the Loss Abatement Algorithm)
4.2.1.3. Reacting Node Maintenance of Overload Control State 4.2.1.3. Reacting Node Maintenance of Overload Control State
When a reacting node receives an OC-OLR AVP, it MUST determine if it When a reacting node receives an OC-OLR AVP, it MUST determine if it
is for an existing or new overload condition. is for an existing or new overload condition.
For the remainder of this section the term OLR referres to the Note: For the remainder of this section the term OLR refers to the
combination of the contents of the received OC-OLR AVP and the combination of the contents of the received OC-OLR AVP and the
abatement algorithm indicated in the received OC-Supported- abatement algorithm indicated in the received OC-Supported-
Features AVP. Features AVP.
The OLR is for an existing overload condition if the reacting node The OLR is for an existing overload condition if a reacting node has
has an OCS that matches the received OLR. an OCS that matches the received OLR.
For a host report-type this means it matches the app-id and host-id For a host report-type this means it matches the application-id and
in an existing host OCS entry. the host's DiameterIdentity in an existing host OCS entry.
For a realm report-type this means it matches the app-id and realm-id For a realm report-type this means it matches the application-id and
in an existing realm OCS entry. the realm in an existing realm OCS entry.
If the OLR is for an existing overload condition then it MUST If the OLR is for an existing overload condition then a reacting node
determine if the OLR is a retransmission or an update to the existing MUST determine if the OLR is a retransmission or an update to the
OLR. existing OLR.
If the sequence number for the received OLR is greater than the If the sequence number for the received OLR is greater than the
sequence number stored in the matching OCS entry then the reacting sequence number stored in the matching OCS entry then a reacting node
node MUST update the matching OCS entry. MUST update the matching OCS entry.
If the sequence number for the received OLR is less than or equal to If the sequence number for the received OLR is less than or equal to
the sequence number in the matching OCS entry then the reacting node the sequence number in the matching OCS entry then a reacting node
MUST silently ignore the received OLR. The matching OCS MUST NOT be MUST silently ignore the received OLR. The matching OCS MUST NOT be
updated in this case. updated in this case.
If the received OLR is for a new overload condition then the reacting If the received OLR is for a new overload condition then a reacting
node MUST generate a new OCS entry for the overload condition. node MUST generate a new OCS entry for the overload condition.
For a host report-type this means it creates on OCS entry with the For a host report-type this means a reacting node creates on OCS
app-id of the application-id in the received message and host-id of entry with the application-id in the received message and
the Origin-Host in the received message. DiameterIdentity of the Origin-Host in the received message.
Note: This solution assumes that the Origin-Host AVP in the answer Note: This solution assumes that the Origin-Host AVP in the answer
message included by the reporting node is not changed along the message included by the reporting node is not changed along the
path to the reacting node. path to the reacting node.
For a realm report-type this means it creates on OCS entry with the For a realm report-type this means a reacting node creates on OCS
app-id of the application-id in the received message and realm-id of entry with the application-id in the received message and realm of
the Origin-Realm in the received message. the Origin-Realm in the received message.
If the received OLR contains a validity duration of zero ("0") then If the received OLR contains a validity duration of zero ("0") then a
the reacting node MUST update the OCS entry as being expired. reacting node MUST update the OCS entry as being expired.
Note that it is not necessarily appropriate to delete the OCS Note: It is not necessarily appropriate to delete the OCS entry,
entry, as there is recommended behavior that the reacting node as there is recommended behavior that the reacting node slowly
slowly returns to full traffic when ending an overload abatement returns to full traffic when ending an overload abatement period.
period.
The reacting node does not delete an OCS when receiving an answer The reacting node does not delete an OCS when receiving an answer
message that does not contain an OC-OLR AVP (i.e. absence of OLR message that does not contain an OC-OLR AVP (i.e. absence of OLR
means "no change"). means "no change").
4.2.1.4. Reporting Node Maintenance of Overload Control State 4.2.1.4. Reporting Node Maintenance of Overload Control State
A reporting node SHOULD create a new OCS entry when entering an A reporting node SHOULD create a new OCS entry when entering an
overload condition. overload condition.
If the reporting node knows through absence of the OC-Supported- Note: If a reporting node knows through absence of the OC-
Features AVP in received messages that there are no reacting nodes Supported-Features AVP in received messages that there are no
supporting DOIC then the reporting node can choose to not create reacting nodes supporting DOIC then the reporting node can choose
OCS entries. to not create OCS entries.
When generating a new OCS entry the sequence number MAY be set to any When generating a new OCS entry the sequence number SHOULD be set to
value if there is no unexpired overload report for previous overload zero ("0").
conditions sent to any reacting node for the same application and
report-type.
When generating sequence numbers for new overload conditions, the new When generating sequence numbers for new overload conditions, the new
sequence number MUST be greater than any sequence number in an active sequence number MUST be greater than any sequence number in an active
(unexpired) overload report previously sent by the reporting node. (unexpired) overload report for the same application and report-type
This property MUST hold over a reboot of the reporting node. previously sent by the reporting node. This property MUST hold over
a reboot of the reporting node.
The reporting node MUST update an OCS entry when it needs to adjust Note: One way of addressing this over a reboot of a reporting node
the validity duration of the overload condition at reacting nodes. is to use a time stamp for the first overload condition that
occurs after the report and to start using sequence numbers of
zero for subsequent overload conditions.
For instance, if the reporting node wishes to instruct reacting A reporting node MUST update an OCS entry when it needs to adjust the
validity duration of the overload condition at reacting nodes.
For instance, if a reporting node wishes to instruct reacting
nodes to continue overload abatement for a longer period of time nodes to continue overload abatement for a longer period of time
that originally communicated. This also applies if the reporting than originally communicated. This also applies if the reporting
node wishes to shorten the period of time that overload abatement node wishes to shorten the period of time that overload abatement
is to continue. is to continue.
A reporting node MUST NOT update the abatement algorithm in an active A reporting node MUST NOT update the abatement algorithm in an active
OCS entry. OCS entry.
A reporting node MUST update an OCS entry when it wishes to adjust A reporting node MUST update an OCS entry when it wishes to adjust
any abatement algorithm specific parameters, including the reduction any abatement algorithm specific parameters, including the reduction
percentage used for the Loss abatement algorithm. percentage used for the Loss abatement algorithm.
For instance, if the reporting node wishes to change the reduction For instance, if a reporting node wishes to change the reduction
percentage either higher, if the overload condition has worsened, percentage either higher, if the overload condition has worsened,
or lower, if the overload condition has improved, then the or lower, if the overload condition has improved, then the
reporting node would update the appropriate OCS entry. reporting node would update the appropriate OCS entry.
The reporting node MUST update the sequence number associated with A reporting node MUST update the sequence number associated with the
the OCS entry anytime the contents of the OCS entry are changed. OCS entry anytime the contents of the OCS entry are changed. This
This will result in a new sequence number being sent to reacting will result in a new sequence number being sent to reacting nodes,
nodes, instructing the reacting nodes to process the OC-OLR AVP. instructing reacting nodes to process the OC-OLR AVP.
A reporting node SHOULD update an OCS entry with a validity duration A reporting node SHOULD update an OCS entry with a validity duration
of zero ("0") when the overload condition ends. of zero ("0") when the overload condition ends.
If the reporting node knows that the OCS entries in the reacting Note: If a reporting node knows that the OCS entries in the
nodes are near expiration then the reporting node can decide to reacting nodes are near expiration then the reporting node might
delete the OCS entry. decide not to send an OLR with a validity duration of zero.
The reporting node MUST keep an OCS entry with a validity duration of A reporting node MUST keep an OCS entry with a validity duration of
zero ("0") for a period of time long enough to ensure that any non- zero ("0") for a period of time long enough to ensure that any non-
expired reacting node's OCS entry created as a result of the overload expired reacting node's OCS entry created as a result of the overload
condition in the reporting node is deleted. condition in the reporting node is deleted.
4.2.2. Reacting Node Behavior 4.2.2. Reacting Node Behavior
When a reacting node sends a request it MUST determine if that When a reacting node sends a request it MUST determine if that
request matches an active OCS. request matches an active OCS.
If the request matches and active OCS then the reacting node MUST If the request matches an active OCS then the reacting node MUST use
apply abatement treatment on the request. The abatement treatment the overload abatement algorithm incideated in the OCS to determine
applied depends on the abatement algorithm stored in the OCS. if the request is to receive overload abatement treatment.
For the Loss abatement algorithm defined in this specification, see For the Loss abatement algorithm defined in this specification, see
Section 5 for the abatement logic applied. Section 5 for the overload abatement algorithm logic applied.
If the abatement treatment results in throttling of the request and If the overload abatement algorithm selects the request for overload
if the reacting node is an agent then the agent MUST send an abatement treatment then the reacting node MUST apply overload
appropriate error as defined in section Section 7. abatement treatment on the request. The abatement treatment applied
depends on the context of the request.
In the case that the OCS entry validity duration expires or has a If the request is a host-routed request then the reacting node SHOULD
validity duration of zero ("0"), meaning that it the reporting node apply throttling abatement treatment to the request.
has explicitly signaled the end of the overload condition then
If the request is a realm-routed request then the reacting node
SHOULD apply diversion abatement treatment to the request.
If the overload abatement treatment results in throttling of the
request and if the reacting node is an agent then the agent MUST send
an appropriate error as defined in Section 7.
The behavior of reacting nodes that are Diameter endpoints when
throttling requests depends on the application and is outside the
scope of this specification.
In the case that the OCS entry indicated no traffic was to be sent to
the overloaded entity and the validity duration expires or has a
validity duration of zero ("0"), meaning that the reporting node has
explicitly signaled the end of the overload condition then overlaod
abatement associated with the overload abatement MUST be ended in a abatement associated with the overload abatement MUST be ended in a
controlled fashion. controlled fashion.
4.2.3. Reporting Node Behavior 4.2.3. Reporting Node Behavior
The operation on the reporting node is straight forward. If there is an active OCS entry then a reporting node SHOULD include
the OC-OLR AVP in all answer messages to requests that contain the
If there is an active OCS entry then the reporting node SHOULD OC-Supported-Features AVP and that match the active OCS entry.
include the OC-OLR AVP in all answer messages to requests that
contain the OC-Supported-Features AVP and that match the active OCS
entry.
A request matches if the application-id in the request matches the Note: A request matches if the application-id in the request
application-id in any active OCS entry and if the report-type in matches the application-id in any active OCS entry and if the
the OCS entry matches a report-type supported by the reporting report-type in the OCS entry matches a report-type supported by
node as indicated in the OC-Supported-Features AVP. the reporting node as indicated in the OC-Supported-Features AVP.
The contents of the OC-OLR AVP MUST contain all information necessary The contents of the OC-OLR AVP MUST contain all information necessary
for the abatement algorithm indicated in the OC-Supported-Features for the abatement algorithm indicated in the OC-Supported-Features
AVP that is also included in the answer message. AVP that is also included in the answer message.
A reporting node MAY choose to not resend an overload report to a A reporting node MAY choose to not resend an overload report to a
reacting node if it can guarantee that this overload report is reacting node if it can guarantee that this overload report is
already active in the reacting node. already active in the reacting node.
Note - In some cases (e.g. when there are one or more agents in Note: In some cases (e.g. when there are one or more agents in the
the path between reporting and reacting nodes, or when overload path between reporting and reacting nodes, or when overload
reports are discarded by reacting nodes) the reporting node may reports are discarded by reacting nodes) a reporting node may not
not be able to guarantee that the reacting node has received the be able to guarantee that the reacting node has received the
report. report.
A reporting node MUST NOT send overload reports of a type that has A reporting node MUST NOT send overload reports of a type that has
not been advertised as supported by the reacting node. not been advertised as supported by the reacting node.
Note that a reacting node advertises support for the host and Note: A reacting node implicitly advertises support for the host
realm report types by including the OC-Supported-Features AVP in and realm report types by including the OC-Supported-Features AVP
the request. Support for other report types must be explicitly in the request. Support for other report types will be explicitly
indicated by new feature bits in the OC-Feature-Vector AVP. indicated by new feature bits in the OC-Feature-Vector AVP.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence A reporting node SHOULD indicate the end of an overload occurrence by
by sending a new OLR with OC-Validity-Duration set to a value of zero sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD ensure that all reacting nodes ("0"). The reporting node SHOULD ensure that all reacting nodes
receive the updated overload report. receive the updated overload report.
All OLRs sent have an expiration time calculated by adding the Note: All OLRs sent have an expiration time calculated by adding
validity-duration contained in the OLR to the time the message was the validity-duration contained in the OLR to the time the message
sent. Transit time for the OLR can be safely ignored. The was sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload condition have expiration time for all OLRs sent for that overload condition have
expired. expired.
When a reporting node sends an OLR, it effectively delegates any When a reporting node sends an OLR, it effectively delegates any
necessary throttling to downstream nodes. Therefore, the reporting necessary throttling to downstream nodes. Therefore, the reporting
node SHOULD NOT apply throttling to the set of messages to which the node SHOULD NOT apply overload related throttling to the set of
OLR applies. That is, the same candidate set of messages SHOULD NOT messages to which the sent OLR applies. That is, the same candidate
be throttled multiple times. set of messages SHOULD NOT be throttled multiple times.
However, when the reporting node sends and OLR downstream, it MAY However, when the reporting node sends an OLR downstream, it MAY
still be responsible to apply other abatement methods such as still be responsible to apply other abatement methods such as
diversion. The reporting node might also need to throttle requests diversion. The reporting node might also need to throttle requests
for reasons other then overload. For example, an agent or server for reasons other than overload. For example, an agent or server
might have a configured rate limit for each client, and throttle might have a configured rate limit for each client, and throttle
requests that exceed that limit, even if such requests had already requests that exceed that limit, even if such requests had already
been candidates for throttling by downstream nodes. been candidates for throttling by downstream nodes.
This document assumes that there is a single source for realm-reports A reporting node SHOULD decrease requested overload abatement
for a given realm, or that if multiple nodes can send realm reports, treatment in a controlled fashion to avoid occillations in traffic.
that each such node has full knowledge of the overload state of the
entire realm. A reacting node cannot distinguish between receiving
realm-reports from a single node, or from multiple nodes.
Editor's Note: There is not yet consensus on the above two
paragraphs. Two alternatives are under consideration --
synchronization of sequence numbers and attribution of reports.
If no consensus is reached then it will be left to be addressed as
an extension.
4.3. Protocol Extensibility 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The DOIC solution can be extended. Types of potential extensions
abatement algorithms, new report types or other new functionality. include new traffic abatement algorithms, new report types or other
new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension that requires new normative behavior, a
the OC-Feature-Vector. This feature bit is used to communicate new feature bit MUST be defined for the OC-Feature-Vector. This
support for the new feature. feature bit is used to communicate support for the new feature.
The extension MAY define new AVPs for use in DOIC Capability The extension MAY define new AVPs for use in DOIC Capability
Announcement and for use in DOIC Overload reporting. These new AVPs Announcement and for use in DOIC Overload reporting. These new AVPs
SHOULD be defined to be extensions to the OC-Supported-Features and SHOULD be defined to be extensions to the OC-Supported-Features and
OC-OLR AVPs defined in this document. OC-OLR AVPs defined in this document.
It should be noted that [RFC6733] defined Grouped AVP extension [RFC6733] defined Grouped AVP extension mechanisms apply. This
mechanisms apply. This allows, for example, defining a new feature allows, for example, defining a new feature that is mandatory to be
that is mandatory to be understood even when piggybacked on an understood even when piggybacked on an existing application.
existing application.
The handling of feature bits in the OC-Feature-Vector AVP that are The handling of feature bits in the OC-Feature-Vector AVP that are
not associated with overload abatement algorithms MUST be specified not associated with overload abatement algorithms MUST be specified
by the extensions that define the features. by the extensions that define the features.
When defining new report type values, the corresponding specification When defining new report type values, the corresponding specification
MUST define the semantics of the new report types and how they affect MUST define the semantics of the new report types and how they affect
the OC-OLR AVP handling. The specification MUST also reserve a the OC-OLR AVP handling. The specification MUST also reserve a
corresponding new feature bit in the OC-Feature-Vector AVP. corresponding new feature bit in the OC-Feature-Vector AVP.
The OC-OLR AVP can be expanded with optional sub-AVPs only if a The OC-OLR AVP can be expanded with optional sub-AVPs only if a
legacy DOIC implementation can safely ignore them without breaking legacy DOIC implementation can safely ignore them without breaking
backward compatibility for the given OC-Report-Type AVP value. If backward compatibility for the given OC-Report-Type AVP value. If
the new sub-AVPs imply new semantics for handling the indicated the new sub-AVPs imply new semantics for handling the indicated
report type, then a new OC-Report-Type AVP value MUST be defined. report type, then a new OC-Report-Type AVP value MUST be defined.
Documents that introduce new report types MUST describe any
limitations on their use across non-supporting agents.
New features (feature bits in the OC-Feature-Vector AVP) and report New features (feature bits in the OC-Feature-Vector AVP) and report
types (in the OC-Report-Type AVP) MUST be registered with IANA. As types (in the OC-Report-Type AVP) MUST be registered with IANA. As
with any Diameter specification, new AVPs MUST also be registered with any Diameter specification, new AVPs MUST also be registered
with IANA. See Section 8 for the required procedures. with IANA. See Section 8 for the required procedures.
5. Loss Algorithm 5. Loss Algorithm
This section documents the Diameter overload loss abatement This section documents the Diameter overload loss abatement
algorithm. algorithm.
skipping to change at page 21, line 39 skipping to change at page 23, line 8
overload report. overload report.
Reporting nodes use a strategy of applying abatement logic to the Reporting nodes use a strategy of applying abatement logic to the
requested percentage of request messages sent (or handled in the case requested percentage of request messages sent (or handled in the case
of agents) by the reacting node that are impacted by the overload of agents) by the reacting node that are impacted by the overload
report. report.
From a conceptual level, the logic at the reacting node could be From a conceptual level, the logic at the reacting node could be
outlined as follows. outlined as follows.
1. An overload report is received and the associated overload state 1. An overload report is received and the associated OCS is either
is either saved or updated (if required) by the reacting node. saved or updated (if required) by the reacting node.
2. A new Diameter request is generated by the application running on 2. A new Diameter request is generated by the application running on
the reacting node. the reacting node.
3. The reacting node determines that an active overload report 3. The reacting node determines that an active overload report
applies to the request, as indicated by the corresponding OCS applies to the request, as indicated by the corresponding OCS
entry. entry.
4. The reacting node determines if abatement should be applied to 4. The reacting node determines if overload abatement treatment
the request. One approach that could be taken for each request should be applied to the request. One approach that could be
is to select a random number between 1 and 100. If the random taken for each request is to select a random number between 1 and
number is less than the indicated reduction percentage then the 100. If the random number is less than the indicated reduction
request is given abatement treatment, otherwise the request is percentage then the request is given abatement treatment,
given normal routing treatment. otherwise the request is given normal routing treatment.
5.2. Reporting Node Behavior 5.2. Reporting Node Behavior
The method a reporting nodes uses to determine the amount of traffic The method a reporting nodes uses to determine the amount of traffic
reduction required to address an overload condition is an reduction required to address an overload condition is an
implementation decision. implementation decision.
When a reporting node that has selected the loss abatement algorithm When a reporting node that has selected the loss abatement algorithm
determines the need to request a traffic reduction it includes an OC- determines the need to request a reduction in traffic, it includes an
OLR AVP in response messages as described in Section 4.2.3. OC-OLR AVP in response messages as described in Section 4.2.3.
The reporting node MUST indicate a percentage reduction in the OC- When sending the OC-OLR AVP, the reporting node MUST indicate a
Reduction-Percentage AVP. percentage reduction in the OC-Reduction-Percentage AVP.
The reporting node MAY change the reduction percentage in subsequent The reporting node MAY change the reduction percentage in subsequent
overload reports. When doing so the reporting node must conform to overload reports. When doing so the reporting node must conform to
overload report handing specified in Section 4.2.3. overload report handing specified in Section 4.2.3.
When the reporting node determines it no longer needs a reduction in When the reporting node determines it no longer needs a reduction in
traffic the reporting node SHOULD send an overload report indicating traffic the reporting node SHOULD send an overload report indicating
the overload report is no longer valid, as specified in the overload report is no longer valid, as specified in
Section 4.2.3. Section 4.2.3.
5.3. Reacting Node Behavior 5.3. Reacting Node Behavior
The method a reacting node uses to determine which request messages The method a reacting node uses to determine which request messages
are given abatement treatment is an implementation decision. are given abatement treatment is an implementation decision.
When receiving an OC-OLR in an answer message where the algorithm When receiving an OC-OLR in an answer message where the algorithm
indicated in the OC-Supported-Features AVP is the loss algorithm, the indicated in the OC-Supported-Features AVP is the loss algorithm, the
reacting node MUST apply abatement treatment to the requested reacting node MUST apply abatement treatment to the requested
percentage of request messages sent. percentage of request messages sent.
Note: the loss algorithm is a stateless algorithm. As a result, Note: The loss algorithm is a stateless algorithm. As a result,
the reacting node does not guarantee that there will be an the reacting node does not guarantee that there will be an
absolute reduction in traffic sent. Rather, it guarantees that absolute reduction in traffic sent. Rather, it guarantees that
the requested percentage of new requests will be given abatement the requested percentage of new requests will be given abatement
treatment. treatment.
When applying overload abatement treatment for the load abatement When applying overload abatement treatment for the load abatement
algorithm, the reacting node MUST abate, either by throttling or algorithm, the reacting node MUST abate, either by throttling or
diversion, the requested percentage of requests that would have diversion, the requested percentage of requests that would have
otherwise been sent to the reporting host or realm. otherwise been sent to the reporting host or realm.
skipping to change at page 23, line 15 skipping to change at page 24, line 34
should be conservative and, for example, first send "probe" messages should be conservative and, for example, first send "probe" messages
to learn the overload condition of the overloaded node before to learn the overload condition of the overloaded node before
converging to any traffic amount/rate decided by the sender. Similar converging to any traffic amount/rate decided by the sender. Similar
concerns apply in all cases when the overload report times out unless concerns apply in all cases when the overload report times out unless
the previous overload report stated 0 percent reduction. the previous overload report stated 0 percent reduction.
If the reacting node does not receive an OLR in messages sent to the If the reacting node does not receive an OLR in messages sent to the
formerly overloaded node then the reacting node SHOULD slowly formerly overloaded node then the reacting node SHOULD slowly
increase the rate of traffic sent to the overloaded node. increase the rate of traffic sent to the overloaded node.
It is suggested that the reacting node decrease the amount of traffic When an active overload report expires, it is suggested that the
given abatement treatment by 20% each second until the reduction is reacting node progressively decrease the amount of traffic given
completely removed and no traffic is given abatement treatment. abatement treatment, until the reduction is completely removed and no
traffic is given abatement treatment.
The goal of this behavior is to reduce the probability of overload The goal of this behavior is to reduce the probability of overload
condition thrashing where an immediate transition from 100% condition thrashing where an immediate transition from 100%
reduction to 0% reduction results in the reporting node moving reduction to 0% reduction results in the reporting node moving
quickly back into an overload condition. quickly back into an overload condition.
6. Attribute Value Pairs 6. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) defined in this
skipping to change at page 23, line 39 skipping to change at page 25, line 10
A new application specification can incorporate the overload control A new application specification can incorporate the overload control
mechanism specified in this document by making it mandatory to mechanism specified in this document by making it mandatory to
implement for the application and referencing this specification implement for the application and referencing this specification
normatively. It is the responsibility of the Diameter application normatively. It is the responsibility of the Diameter application
designers to define how overload control mechanisms works on that designers to define how overload control mechanisms works on that
application. application.
6.1. OC-Supported-Features AVP 6.1. OC-Supported-Features AVP
The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and
serves two purposes. First, it announces a node's support for the serves two purposes. First, it announces a node's support for the
DOIC solution in general. Second, it contains the description of the DOIC solution in general. Second, it contains the description of the
supported DOIC features of the sending node. The OC-Supported- supported DOIC features of the sending node. The OC-Supported-
Features AVP MUST be included in every Diameter request message a Features AVP MUST be included in every Diameter request message a
DOIC supporting node sends. DOIC supporting node sends.
OC-Supported-Features ::= < AVP Header: TBD1 > OC-Supported-Features ::= < AVP Header: TBD1 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
* [ AVP ] * [ AVP ]
The OC-Feature-Vector sub-AVP is used to announce the DOIC features The OC-Feature-Vector sub-AVP is used to announce the DOIC features
supported by the DOIC node, in the form of a flag bits field in which supported by the DOIC node, in the form of a flag-bits field in which
each bit announces one feature or capability supported by the node each bit announces one feature or capability supported by the node
(see Section 6.2). The absence of the OC-Feature-Vector AVP (see Section 6.2). The absence of the OC-Feature-Vector AVP
indicates that only the default traffic abatement algorithm described indicates that only the default traffic abatement algorithm described
in this specification is supported. in this specification is supported.
6.2. OC-Feature-Vector AVP 6.2. OC-Feature-Vector AVP
The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and The OC-Feature-Vector AVP (AVP code TBD6) is of type Unsigned64 and
contains a 64 bit flags field of announced capabilities of a DOIC contains a 64 bit flags field of announced capabilities of a DOIC
node. The value of zero (0) is reserved. node. The value of zero (0) is reserved.
The following capabilities are defined in this document: The following capabilities are defined in this document:
OLR_DEFAULT_ALGO (0x0000000000000001) OLR_DEFAULT_ALGO (0x0000000000000001)
When this flag is set by the DOIC node it means that the default When this flag is set by the a DOIC reacting node it means that
traffic abatement (loss) algorithm is supported. the default traffic abatement (loss) algorithm is supported. When
this flag is set by a DOIC reporting node it means that the loss
algorithm will be used for requested overload abatement.
6.3. OC-OLR AVP 6.3. OC-OLR AVP
The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
information necessary to convey an overload report on an overload information necessary to convey an overload report on an overload
condition at the reporting node. The OC-OLR AVP does not explicitly condition at the reporting node. The OC-OLR AVP does not explicitly
contain all information needed by the reacting node to decide whether contain all information needed by the reacting node to decide whether
a subsequent request must undergo a throttling process with the a subsequent request must undergo abatement using the received
received reduction percentage. The value of the OC-Report-Type AVP reduction percentage. The value of the OC-Report-Type AVP within the
within the OC-OLR AVP indicates which implicit information is OC-OLR AVP indicates which implicit information is relevant for this
relevant for this decision (see Section 6.6). The application the decision (see Section 6.6). The application the OC-OLR AVP applies
OC-OLR AVP applies to is the same as the Application-Id found in the to is the same as the Application-Id found in the Diameter message
Diameter message header. The host or realm the OC-OLR AVP concerns header. The host or realm the OC-OLR AVP concerns is determined from
is determined from the Origin-Host AVP and/or Origin-Realm AVP found the Origin-Host AVP and/or Origin-Realm AVP found in the
in the encapsulating Diameter command. The OC-OLR AVP is intended to encapsulating Diameter command. The OC-OLR AVP is intended to be
be sent only by a reporting node. sent only by a reporting node.
OC-OLR ::= < AVP Header: TBD2 > OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
* [ AVP ] * [ AVP ]
Note that if a Diameter command were to contain multiple OC-OLR AVPs Note that if a Diameter command were to contain multiple OC-OLR AVPs
they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs
with unknown values SHOULD be silently discarded by reacting nodes with unknown values SHOULD be silently discarded by reacting nodes
and the event SHOULD be logged. and the event SHOULD be logged.
6.4. OC-Sequence-Number AVP 6.4. OC-Sequence-Number AVP
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. The OC-Sequence-Number AVP (AVP code TBD3) is of type Unsigned64.
Its usage in the context of overload control is described in Its usage in the context of overload control is described in
Section 4.2. Section 4.2.
From the functionality point of view, the OC-Sequence-Number AVP MUST From the functionality point of view, the OC-Sequence-Number AVP MUST
be used as a non-volatile increasing counter for a sequence of be used as a non-volatile increasing counter for a sequence of
overload reports between two DOIC nodes for the same overload overload reports between two DOIC nodes for the same overload
occurrence. The sequence number is only required to be unique occurrence. The sequence number is only required to be unique
between two DOIC nodes. Sequence numbers are treated in a uni- between two DOIC nodes. Sequence numbers are treated in a uni-
directional manner, i.e. two sequence numbers on each direction directional manner, i.e. two sequence numbers on each direction
between two DOIC nodes are not related or correlated. between two DOIC nodes are not related or correlated.
6.5. OC-Validity-Duration AVP 6.5. OC-Validity-Duration AVP
The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 The OC-Validity-Duration AVP (AVP code TBD4) is of type Unsigned32
and indicates in milliseconds the validity time of the overload and indicates in milliseconds the validity time of the overload
report. The number of milliseconds is measured after reception of report. The number of milliseconds is measured after reception of
the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. the first OC-OLR AVP with a given value of OC-Sequence-Number AVP.
The default value for the OC-Validity-Duration AVP is 5000 (i.e., 5 The default value for the OC-Validity-Duration AVP is 30000 (i.e.; 30
seconds). When the OC-Validity-Duration AVP is not present in the seconds). When the OC-Validity-Duration AVP is not present in the
OC-OLR AVP, the default value applies. Validity duration with values OC-OLR AVP, the default value applies.
above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration
values are treated as if the OC-Validity-Duration AVP were not
present and result in the default value being used.
Editor's note: There is an open discussion on whether to have an
upper limit on the OC-Validity-Duration value, beyond that which can
be indicated by an Unsigned32.
A timeout of the overload report has specific concerns that need to
be taken into account by the DOIC node acting on the earlier received
overload report(s). Section 6.7 discusses the impacts of timeout in
the scope of the traffic abatement algorithms.
6.6. OC-Report-Type AVP 6.6. OC-Report-Type AVP
The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The The OC-Report-Type AVP (AVP code TBD5) is of type Enumerated. The
value of the AVP describes what the overload report concerns. The value of the AVP describes what the overload report concerns. The
following values are initially defined: following values are initially defined:
0 A host report. The overload treatment should apply to requests HOST_REPORT 0 The overload report is for a host. Overload abatement
for which all of the following conditions are true: treatment applies to host-routed requests.
Either 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; or the Destination-Host is
not present in the request but the value of the peer identity
associated with the connection used to send the request matches
the value of the Origin-Host AVP of the received message that
contained the OC-OLR AVP.
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.
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:
The Destination-Host AVP is absent in the requestand the value of
the peer identity associated with the connection used to send the
request does not match a server that could serve the request.
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.
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.
The OC-Report-Type AVP is envisioned to be useful for situations REALM_REPORT 1 The overload report is for a realm. Overload
where a reacting node needs to apply different overload treatments abatement treatment applies to realm-routed requests.
for different overload contexts. For example, the reacting node(s)
might need to throttle differently requests sent to a specific server
(identified by the Destination-Host AVP in the request) and requests
that can be handled by any server in a realm.
6.7. OC-Reduction-Percentage AVP 6.7. OC-Reduction-Percentage AVP
The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 The OC-Reduction-Percentage AVP (AVP code TBD8) is of type Unsigned32
and describes the percentage of the traffic that the sender is and describes the percentage of the traffic that the sender is
requested to reduce, compared to what it otherwise would send. The requested to reduce, compared to what it otherwise would send. The
OC-Reduction-Percentage AVP applies to the default (loss) algorithm OC-Reduction-Percentage AVP applies to the default (loss) algorithm
specified in this specification. However, the AVP can be reused for specified in this specification. However, the AVP can be reused for
future abatement algorithms, if its semantics fit into the new future abatement algorithms, if its semantics fit into the new
algorithm. algorithm.
The value of the Reduction-Percentage AVP is between zero (0) and one The value of the Reduction-Percentage AVP is between zero (0) and one
hundred (100). Values greater than 100 are ignored. The value of hundred (100). Values greater than 100 are ignored. The value of
100 means that all traffic is to be throttled, i.e. the reporting 100 means that all traffic is to be throttled, i.e. the reporting
skipping to change at page 27, line 40 skipping to change at page 28, line 31
|OC-Reduction | | | |OC-Reduction | | |
| -Percentage TBD8 x.x Unsigned32 | | V | | -Percentage TBD8 x.x Unsigned32 | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
|OC-Feature-Vector TBD6 x.x Unsigned64 | | V | |OC-Feature-Vector TBD6 x.x Unsigned64 | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
As described in the Diameter base protocol [RFC6733], the M-bit As described in the Diameter base protocol [RFC6733], the M-bit
setting for a given AVP is relevant to an application and each setting for a given AVP is relevant to an application and each
command within that application that includes the AVP. command within that application that includes the AVP.
The Diameter overload control AVPs SHOULD always be sent with the
M-bit cleared when used within existing Diameter applications to
avoid backward compatibility issues. Otherwise, when reused in newly
defined Diameter applications, the DOC related AVPs SHOULD have the
M-bit set.
7. Error Response Codes 7. Error Response Codes
When a DOIC node rejects a Diameter request due to overload, the DOIC When a DOIC node rejects a Diameter request due to overload, the DOIC
node MUST select an appropriate error response code. This node MUST select an appropriate error response code. This
determination is made based on the probability of the request determination is made based on the probability of the request
succeeding if retried on a different path. succeeding if retried on a different path.
A reporting node rejecting a Diameter request due to an overload A reporting node rejecting a Diameter request due to an overload
condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can
assume that the same request may succeed on a different path. assume that the same request may succeed on a different path.
skipping to change at page 28, line 23 skipping to change at page 29, line 7
SHOULD be used. Retrying would consume valuable resources during an SHOULD be used. Retrying would consume valuable resources during an
occurrence of overload. occurrence of overload.
For instance, if the request arrived at the reporting node without For instance, if the request arrived at the reporting node without
a Destination-Host AVP then the reporting node might determine a Destination-Host AVP then the reporting node might determine
that there is an alternative Diameter node that could successfully that there is an alternative Diameter node that could successfully
process the request and that retrying the transaction would not process the request and that retrying the transaction would not
negatively impact the reporting node. DIAMETER_TOO_BUSY would be negatively impact the reporting node. DIAMETER_TOO_BUSY would be
sent in this case. sent in this case.
For instance, if the request arrived at the reporting node with a If the request arrived at the reporting node with a Destination-
Destination-Host AVP populated with its own Diameter identity then Host AVP populated with its own Diameter identity then the
the reporting node can assume that retrying the request would reporting node can assume that retrying the request would result
result in it coming to the same reporting node. in it coming to the same reporting node.
DIAMETER_UNABLE_TO_COMPLY would be sent in this case. DIAMETER_UNABLE_TO_COMPLY would be sent in this case.
A second example is when an agent that supports the DOIC solution A second example is when an agent that supports the DOIC solution
is performing the role of a reacting node for a non supporting is performing the role of a reacting node for a non supporting
client. Requests that are rejected as a result of DOIC throttling client. Requests that are rejected as a result of DOIC throttling
by the agent in this scenario would generally be rejected with a by the agent in this scenario would generally be rejected with a
DIAMETER_UNABLE_TO_COMPLY response code. DIAMETER_UNABLE_TO_COMPLY response code.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 29, line 11 skipping to change at page 29, line 43
including the initial assignments. New values can be added into the including the initial assignments. New values can be added into the
registry using the Specification Required policy [RFC5226]. See registry using the Specification Required policy [RFC5226]. See
Section 6.2 for the initial assignment in the registry. Section 6.2 for the initial assignment in the registry.
Section 6.6 defines a new "Overload Report Type" registry with its Section 6.6 defines a new "Overload Report Type" registry with its
initial assignments. New types can be added using the Specification initial assignments. New types can be added using the Specification
Required policy [RFC5226]. Required policy [RFC5226].
9. Security Considerations 9. Security Considerations
Editor's Note: This section requires review and updating to reflect
updates made to the rest of the document.
This mechanism gives Diameter nodes the ability to request that This mechanism gives Diameter nodes the ability to request that
downstream nodes send fewer Diameter requests. Nodes do this by downstream nodes send fewer Diameter requests. Nodes do this by
exchanging overload reports that directly affect this reduction. exchanging overload reports that directly affect this reduction.
This exchange is potentially subject to multiple methods of attack, This exchange is potentially subject to multiple methods of attack,
and has the potential to be used as a Denial-of-Service (DoS) attack and has the potential to be used as a Denial-of-Service (DoS) attack
vector. vector.
Overload reports may contain information about the topology and Overload reports may contain information about the topology and
current status of a Diameter network. This information is current status of a Diameter network. This information is
potentially sensitive. Network operators may wish to control potentially sensitive. Network operators may wish to control
skipping to change at page 29, line 33 skipping to change at page 30, line 20
Diameter does not include features to provide end-to-end Diameter does not include features to provide end-to-end
authentication, integrity protection, or confidentiality. This may authentication, integrity protection, or confidentiality. This may
cause complications when sending overload reports between non- cause complications when sending overload reports between non-
adjacent nodes. adjacent nodes.
9.1. Potential Threat Modes 9.1. Potential Threat Modes
The Diameter protocol involves transactions in the form of requests The Diameter protocol involves transactions in the form of requests
and answers exchanged between clients and servers. These clients and and answers exchanged between clients and servers. These clients and
servers may be peers, that is,they may share a direct transport (e.g. servers may be peers, that is, they may share a direct transport
TCP or SCTP) connection, or the messages may traverse one or more (e.g. TCP or SCTP) connection, or the messages may traverse one or
intermediaries, known as Diameter Agents. Diameter nodes use TLS, more intermediaries, known as Diameter Agents. Diameter nodes use
DTLS, or IPSec to authenticate peers, and to provide confidentiality TLS, DTLS, or IPSec to authenticate peers, and to provide
and integrity protection of traffic between peers. Nodes can make confidentiality and integrity protection of traffic between peers.
authorization decisions based on the peer identities authenticated at Nodes can make authorization decisions based on the peer identities
the transport layer. authenticated at the transport layer.
When agents are involved, this presents an effectively hop-by-hop When agents are involved, this presents an effectively hop-by-hop
trust model. That is, a Diameter client or server can authorize an trust model. That is, a Diameter client or server can authorize an
agent for certain actions, but it must trust that agent to make agent for certain actions, but it must trust that agent to make
appropriate authorization decisions about its peers, and so on. appropriate authorization decisions about its peers, and so on.
Since confidentiality and integrity protection occurs at the Since confidentiality and integrity protection occurs at the
transport layer. Agents can read, and perhaps modify, any part of a transport layer. Agents can read, and perhaps modify, any part of a
Diameter message, including an overload report. Diameter message, including an overload report.
skipping to change at page 33, line 30 skipping to change at page 34, line 18
[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", RFC 7068, November 2013. Requirements", RFC 7068, November 2013.
[S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012.
Appendix A. Issues left for future specifications Appendix A. Issues left for future specifications
The base solution for the overload control does not cover all The base solution for the overload control does not cover all
possible use cases. A number of solution aspects were intentionally possible use cases. A number of solution aspects were intentionally
left for future specification and protocol work. left for future specification and protocol work. The following sub-
sections define some of the potential extensions to the DOIC
solution.
A.1. Additional traffic abatement algorithms A.1. Additional traffic abatement algorithms
This specification describes only means for a simple loss based This specification describes only means for a simple loss based
algorithm. Future algorithms can be added using the designed algorithm. Future algorithms can be added using the designed
solution extension mechanism. The new algorithms need to be solution extension mechanism. The new algorithms need to be
registered with IANA. See Sections 6.1 and 8 for the required IANA registered with IANA. See Sections 6.1 and 8 for the required IANA
steps. steps.
A.2. Agent Overload A.2. Agent Overload
This specification focuses on Diameter endpoint (server or client) This specification focuses on Diameter endpoint (server or client)
overload. A separate extension will be required to outline the overload. A separate extension will be required to outline the
handling of the case of agent overload. handling of the case of agent overload.
A.3. New Error Diagnostic AVP A.3. New Error Diagnostic AVP
The proposal was made to add a new Error Diagnostic AVP to supplement The proposal was made to add a new Error Diagnostic AVP to supplement
the error responces to be able to indicate that overload was the the error responses to be able to indicate that overload was the
reason for the rejection of the message. reason for the rejection of the message.
Appendix B. Deployment Considerations Appendix B. Deployment Considerations
Non supporting agents Non Supporting Agents
Due to the way that realm-routed requests are handled in Diameter Due to the way that realm-routed requests are handled in Diameter
networks, with the server selection for the request done by an networks, with the server selection for the request done by an
agent, it is recommended that deployments enable all agents that agent, it is recommended that deployments enable all agents that
do server selection to support the DOIC solution prior to enabling do server selection to support the DOIC solution prior to enabling
the DOIC solution in the Diameter network. the DOIC solution in the Diameter network.
Topology hiding interactions Topology Hiding Interactions
There exist proxies that implement what is referred to as Topology There exist proxies that implement what is referred to as Topology
Hiding. This can include cases where the agent modifies the Hiding. This can include cases where the agent modifies the
Origin-Host in answer messages. The behavior of the DOIC solution Origin-Host in answer messages. The behavior of the DOIC solution
is not well understood when this happens. As such, the DOIC is not well understood when this happens. As such, the DOIC
solution does not address this scenario. solution does not address this scenario.
Appendix C. Requirements Conformance Analysis Appendix C. Requirements Conformance Analysis
This section contains the result of an analysis of the DOIC solutions This section contains the result of an analysis of the DOIC solutions
conformance to the requirements defined in [RFC7068]. conformance to the requirements defined in [RFC7068].
To be completed. Editor's Note: To be completed.
Appendix D. Considerations for Applications Integrating the DOIC Appendix D. Considerations for Applications Integrating the DOIC
Solution Solution
This section outlines considerations to be taken into account when This section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications. integrating the DOIC solution into Diameter applications.
D.1. Application Classification D.1. Application Classification
The following is a classification of Diameter applications and The following is a classification of Diameter applications and
skipping to change at page 35, line 13 skipping to change at page 35, line 49
a Diameter session-based application. a Diameter session-based application.
In session-less applications, the lifetime of the Session-Id is a In session-less applications, the lifetime of the Session-Id is a
single Diameter transaction, i.e. the session is implicitly single Diameter transaction, i.e. the session is implicitly
terminated after a single Diameter transaction and a new Session-Id terminated after a single Diameter transaction and a new Session-Id
is generated for each Diameter request. is generated for each Diameter request.
For the purposes of this discussion, session-less applications are For the purposes of this discussion, session-less applications are
further divided into two types of applications: further divided into two types of applications:
Stateless applications: Stateless Applications:
Requests within a stateless application have no relationship to Requests within a stateless application have no relationship to
each other. The 3GPP defined S13 application is an example of a each other. The 3GPP defined S13 application is an example of a
stateless application [S13], where only a Diameter command is stateless application [S13], where only a Diameter command is
defined between a client and a server and no state is maintained defined between a client and a server and no state is maintained
between two consecutive transactions. between two consecutive transactions.
Pseudo-session applications: Pseudo-Session Applications:
Applications that do not rely on the Session-Id AVP for Applications that do not rely on the Session-Id AVP for
correlation of application messages related to the same session correlation of application messages related to the same session
but use other session-related information in the Diameter requests but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application. example of a pseudo-session application.
The handling of overload reports must take the type of application The handling of overload reports must take the type of application
into consideration, as discussed in Appendix D.2. into consideration, as discussed in Appendix D.2.
skipping to change at page 36, line 5 skipping to change at page 36, line 44
this discussion. The method used to reduce offered load is not this discussion. The method used to reduce offered load is not
specified here but could include routing requests to another Diameter specified here but could include routing requests to another Diameter
entity known to be able to handle them, or it could mean rejecting entity known to be able to handle them, or it could mean rejecting
certain requests. For a Diameter agent, rejecting requests will certain requests. For a Diameter agent, rejecting requests will
usually mean generating appropriate Diameter error responses. For a usually mean generating appropriate Diameter error responses. For a
Diameter client, rejecting requests will depend upon the application. Diameter client, rejecting requests will depend upon the application.
For example, it could mean giving an indication to the entity For example, it could mean giving an indication to the entity
requesting the Diameter service that the network is busy and to try requesting the Diameter service that the network is busy and to try
again later. again later.
Stateless applications: Stateless Applications:
By definition there is no relationship between individual requests By definition there is no relationship between individual requests
in a stateless application. As a result, when a request is sent in a stateless application. As a result, when a request is sent
or relayed to an overloaded Diameter entity - either a Diameter or relayed to an overloaded Diameter entity - either a Diameter
Server or a Diameter Agent - the sending or relaying entity can Server or a Diameter Agent - the sending or relaying entity can
choose to apply the overload treatment to any request targeted for choose to apply the overload treatment to any request targeted for
the overloaded entity. the overloaded entity.
Pseudo-session applications: Pseudo-Session Applications:
For pseudo-session applications, there is an implied ordering of For pseudo-session applications, there is an implied ordering of
requests. As a result, decisions about which requests towards an requests. As a result, decisions about which requests towards an
overloaded entity to reject could take the command code of the overloaded entity to reject could take the command code of the
request into consideration. This generally means that request into consideration. This generally means that
transactions later in the sequence of transactions should be given transactions later in the sequence of transactions should be given
more favorable treatment than messages earlier in the sequence. more favorable treatment than messages earlier in the sequence.
This is because more work has already been done by the Diameter This is because more work has already been done by the Diameter
network for those transactions that occur later in the sequence. network for those transactions that occur later in the sequence.
Rejecting them could result in increasing the load on the network Rejecting them could result in increasing the load on the network
as the transactions earlier in the sequence might also need to be as the transactions earlier in the sequence might also need to be
repeated. repeated.
Session-based applications: Session-Based Applications:
Overload handling for session-based applications must take into Overload handling for session-based applications must take into
consideration the work load associated with setting up and consideration the work load associated with setting up and
maintaining a session. As such, the entity sending requests maintaining a session. As such, the entity sending requests
towards an overloaded Diameter entity for a session-based towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session ending rejecting intra-session requests. In addition, session ending
requests might be given a lower probability of being rejected as requests might be given a lower probability of being rejected as
rejecting session ending requests could result in session status rejecting session ending requests could result in session status
being out of sync between the Diameter clients and servers. being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates requests will need to consider whether the rejection invalidates
the session and any resulting session clean-up procedures. the session and any resulting session cleanup procedures.
D.3. Request Transaction Classification D.3. Request Transaction Classification
Independent Request: Independent Request:
An independent request is not correlated to any other requests An independent request is not correlated to any other requests
and, as such, the lifetime of the session-id is constrained to an and, as such, the lifetime of the session-id is constrained to an
individual transaction. individual transaction.
Session-Initiating Request: Session-Initiating Request:
skipping to change at page 37, line 45 skipping to change at page 38, line 35
D.4. Request Type Overload Implications D.4. Request Type Overload Implications
The request classes identified in Appendix D.3 have implications on The request classes identified in Appendix D.3 have implications on
decisions about which requests should be throttled first. The decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy, exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application. unless specifically defined for the application.
Independent requests: Independent Requests:
Independent requests can generally be given equal treatment when Independent requests can generally be given equal treatment when
making throttling decisions, unless otherwise indicated by making throttling decisions, unless otherwise indicated by
application requirements or local policy. application requirements or local policy.
Session-initiating requests: Session-Initiating Requests:
Session-initiating requests often represent more work than Session-initiating requests often represent more work than
independent or intra-session requests. Moreover, session- independent or intra-session requests. Moreover, session-
initiating requests are typically followed by other session- initiating requests are typically followed by other session-
related requests. Since the main objective of the overload related requests. Since the main objective of the overload
control is to reduce the total number of requests sent to the control is to reduce the total number of requests sent to the
overloaded entity, throttling decisions might favor allowing overloaded entity, throttling decisions might favor allowing
intra-session requests over session-initiating requests. In the intra-session requests over session-initiating requests. In the
absence of local policies or application specific requirements to absence of local policies or application specific requirements to
the contrary, Individual session-initiating requests can be given the contrary, Individual session-initiating requests can be given
equal treatment when making throttling decisions. equal treatment when making throttling decisions.
Correlated session-initiating requests: Correlated Session-Initiating Requests:
A Request that results in a new binding, where the binding is used A Request that results in a new binding, where the binding is used
for routing of subsequent session-initiating requests to the same for routing of subsequent session-initiating requests to the same
server, represents more work load than other requests. As such, server, represents more work load than other requests. As such,
these requests might be throttled more frequently than other these requests might be throttled more frequently than other
request types. request types.
Pseudo-session requests: Pseudo-Session Requests:
Throttling decisions for pseudo-session requests can take into Throttling decisions for pseudo-session requests can take into
consideration where individual requests fit into the overall consideration where individual requests fit into the overall
sequence of requests within the pseudo session. Requests that are sequence of requests within the pseudo session. Requests that are
earlier in the sequence might be throttled more aggressively than earlier in the sequence might be throttled more aggressively than
requests that occur later in the sequence. requests that occur later in the sequence.
Intra-session requests: Intra-Session Requests:
There are two types of intra-sessions requests, requests that There are two types of intra-sessions requests, requests that
terminate a session and the remainder of intra-session requests. terminate a session and the remainder of intra-session requests.
Implementors and operators may choose to throttle session- Implementers and operators may choose to throttle session-
terminating requests less aggressively in order to gracefully terminating requests less aggressively in order to gracefully
terminate sessions, allow clean-up of the related resources (e.g. terminate sessions, allow cleanup of the related resources (e.g.
session state) and avoid the need for additional intra-session session state) and avoid the need for additional intra-session
requests. Favoring session-termination requests may reduce the requests. Favoring session-termination requests may reduce the
session management impact on the overloaded entity. The default session management impact on the overloaded entity. The default
handling of other intra-session requests might be to treat them handling of other intra-session requests might be to treat them
equally when making throttling decisions. There might also be equally when making throttling decisions. There might also be
application level considerations whether some request types are application level considerations whether some request types are
favored over others. favored over others.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Broadcom Broadcom
Porkkalankatu 24 Porkkalankatu 24
Helsinki FIN-00180 Helsinki FIN-00180
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
Steve Donovan (editor) Steve Donovan (editor)
Oracle Oracle
7460 Warren Parkway 7460 Warren Parkway
Frisco, Texas 75034 Frisco, Texas 75034
United States United States
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
Ben Campbell Ben Campbell
Oracle Oracle
 End of changes. 158 change blocks. 
489 lines changed or deleted 504 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------020808060408070800040300-- From nobody Fri Nov 21 14:13: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 97C8F1A8A92 for ; Fri, 21 Nov 2014 14:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttyJVfQ0xkrA for ; Fri, 21 Nov 2014 14:12:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113D61A8AA8 for ; Fri, 21 Nov 2014 14:12:16 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sALMCBa0031596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 16:12:11 -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.23] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <087A34937E64E74E848732CFF8354B9209863A4D@ESESSMB101.ericsson.se> Date: Fri, 21 Nov 2014 16:12:10 -0600 X-Mao-Original-Outgoing-Id: 438300730.939396-b2b239a81caacbd64d5fc90d317c5cc2 Content-Transfer-Encoding: quoted-printable Message-Id: <85101722-1464-4DD8-B822-9D4AE49581B3@nostrum.com> References: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> <5457BECA.3050905@cisco.com> <2ADFA014-0735-4F0A-A485-E4C19179460B@nostrum.com> <545C7EA8.6070706@cisco.com> <087A34937E64E74E848732CFF8354B920985724A@ESESSMB101.ericsson.se> <4C8FAB4B-4111-4588-A2A7-D4135B30EAA0@nostrum.com> <087A34937E64E74E848732CFF8354B9209863A4D@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PFVqpjSTX5I_4dab9iij6lSDlQs Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 22:12:58 -0000 Hi, I think the plan was to just have the detailed analysis as a record in = the mail list archives. But in any case, I will send an update based on = our email exchange. Thanks! Ben. > On Nov 17, 2014, at 1:37 AM, Maria Cruz Bartolome = wrote: >=20 > Ben, all, >=20 > If we finally keep Req analysis as a separate informative draft, I = would like that you could incorporate comments I sent, as long as they = are agreeable by you. > Best regards > /MCruz >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: martes, 11 de noviembre de 2014 20:04 > To: Maria Cruz Bartolome > Cc: Benoit Claise; dime@ietf.org list > Subject: Re: [Dime] DOIC Requirements Analysis >=20 >>=20 >> On Nov 8, 2014, at 3:16 PM, Maria Cruz Bartolome = wrote: >>=20 >> Dear Ben, >>=20 >> See my comments inserted in attached doc. >> Thanks >> /MCruz >=20 > [...] >=20 > Hi, responding to comments in text: >=20 > Req 2: >=20 >> "Since =E2=80=9Cload=E2=80=9D is not covered, at least it should be = partly compliant because of this reason." >=20 >=20 > I agree, will fix. >=20 > Req 5: >=20 >> "Further study? What for?" >=20 > I don't think we've thought through dynamic discovery use cases. I = don't envision a problem here; I just think we need to think it through. >=20 > Req 6: >=20 >> "Being a SHOULD, in my opinion DOIC is compliant." >=20 >=20 > I disagree. The fact that it is a SHOULD doesn't give us a free pass. = It means that if we don't comply, we need to be able to document why. = The difference is, we are less likely to have people complain about not = complying with a SHOULD. >=20 >=20 >> "Configuration is only required to cover pure implementation specific = issues. >=20 > I don't agree that knowing whether a peer supports the mechanism is a = pure implementation issue. I think it's a security issue. I also don't = believe needing to know that certain agents may have damaged OLRs is a = pure implementation issue. (Both because we also have requirements to = work with and across non-supporting nodes.) >=20 >> without configuration=E2=80=9D >>=20 >> I do not understand what do you refer to. >>=20 >> Could you explain that? >=20 > The only way a node can tell that there's a non-supporting peer in the = path is to have an administrator tell it. >=20 >=20 > Req 8: >=20 >> [reports should be] Reporting nodes? >=20 >=20 > Yes, that's correct. >=20 > Req 10: >=20 >> The consumer is able to determine when the overload condition = improves or ends, but when the next request comes. I agree about your = description of =E2=80=9Cstale=E2=80=9D overload info. >> But then, compliance degree may be subject to interpretation. >>=20 >> I would say this is compliant. >=20 > I listed a valid use case where the consumer cannot tell when the = overload condition changes, except to wait for the expiration of the = OLR. Thus, I still consider this "partially compliant". >=20 >=20 > Req 12: >=20 >> I think DOIC is compliant. >>=20 >> The solution MUST limit the impact of an overloaded node in the = network. >>=20 >>=20 >>=20 >> I do not think we need load conveyance support to be compliant to = this requirement. >=20 > The point of the requirement is to avoid cascaded overload, where = overload at one node induces overload at others. The whole point in = requiring "load" in the first place was to help achieve this. I think = "partially compliant" is generous. >=20 > Req 17: >=20 >> But=E2=80=A6 we have mechanism to keep DOIC node throughput,included = anything related to this issue in the draft. >=20 > I'm not sure where we disagree. Do you think that we _aren't_ = compliant on Req 17? >=20 > Req 18: >=20 >> See comment on 17 >=20 > See response on 17 ;-) >=20 > Req 20: (in response to the note) >=20 >> I agree >=20 > Thanks. Do others also agree? >=20 > Req 23: >=20 >> Partly Compliant >>=20 >> DOIC Overload information can be used already by proprietary = load-balancing implementations. >>=20 >> Load information will be a plus to this. >=20 > The point of the requirement is to be make selections among _non_ = overloaded nodes in a way least likely to cause further problems. Thus, = I think the lack of "load" makes us non-compliant. (It's not like we = don't plan to do load) >=20 > Req 28: (Recommendation for security review) >=20 >> Is it independent for End-to-end sec draft? >=20 > In my personal opinion, the end-to-end work is no where near far = enough along that we can depend on it in any way. >=20 > Req 30: >=20 >> Is it independent for End-to-end sec draft? >>=20 >> This may be misinterpreted as =E2=80=9Cdouble=E2=80=9D throttling in = some cases. >=20 > I agree we need to be careful about that in the main text. Do you = disagree that we are compliant with the requirement? >=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri Nov 21 15:01: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 8095E1A8BC5 for ; Fri, 21 Nov 2014 15:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb15nO0ikGJB for ; Fri, 21 Nov 2014 15:01:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11031A8BC0 for ; Fri, 21 Nov 2014 15:01:44 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sALN1Mw1035667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 17:01:23 -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.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> Date: Fri, 21 Nov 2014 17:01:22 -0600 X-Mao-Original-Outgoing-Id: 438303682.364556-0cec1f8336f1f86bcbe229daa2fcbcdf Content-Transfer-Encoding: quoted-printable Message-Id: References: <545792B6.8030502@usdonovans.com> <087A34937E64E74E848732CFF8354B9209857284@ESESSMB101.ericsson.se> <, > <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EwS_DcVmbQgDRWGWhQ3B7P6PUbA Cc: "dime@ietf.org" Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 23:01:47 -0000 On reflection, I think there might be a subtlety here. The resulting = offered-load may still exceed the reporting node's current capacity. = This can be true even if it's sent an OLR (and thus has related OCS). As = mentioned in the surrounding node needs to still be able to protect = itself, possibly by throttling. Therefore, I propose the sentence take = the form of non-normative guidance. For example: "When a reporting node sends an OLR, it effectively delegates any = necessary throttling to downstream nodes. If the reporting node also = locally throttles the same set of messages, the overall number of = throttled request may be higher than intended. Therefore, if a reporting = node needs to apply local throttling on a set of messages that match or = overlap with existing OCS entries, it needs to consider the impact of = throttling by downstream nodes." =20 > On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote: >=20 > I can live with the text proposed by Ulrich. But what is wrong with: >=20 > " Therefore, the reporting node SHOULD NOT apply throttling to the set = of messages to which an active OCS applies." ? >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > ---- Maria Cruz Bartolome a =E9crit ---- >=20 >=20 >> Section 4.2.3, 13th paragraph, 2nd sentence: >> Existing text: Therefore, the reporting node SHOULD NOT apply = throttling to the set of messages to which the OLR applies. >> Proposed text: Therefore, the reporting node SHOULD NOT apply = throttling to the set of messages to which the sent OLR applies. >>=20 >> [LM] I would say that the reporting node will not remember the = previously sent OLR, but will take care that there is an active OCS. > SRD> I'm ok with Ulrich's change. >=20 > [LM] and this is incorrect but not fundamental. The reporting node = does not have to "remember" a previously sent OLR. What it will do is to = refer to existing OCS to know that throttling should not be applied. An = OCS is a consequence of an sent OLR but it is not an OLR itself. But not = fundamental here. >=20 > [MCruz] I am ok with Ulrich's change. It does not mean that the = reporting node needs to "remember" a previously sent OLR, though. The = change only proposes to "identify" which OLR we refer to. >=20 > Best regards > /MCruz >=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 nobody Mon Nov 24 18:18: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 4EBFB1A88B3 for ; Mon, 24 Nov 2014 18:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02Dhvafcn2KU for ; Mon, 24 Nov 2014 18:18:46 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCBA31A6F45 for ; Mon, 24 Nov 2014 18:18:45 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAP2IiUh067853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Nov 2014 20:18:44 -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.23] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_91ABD163-F867-4886-B49F-27D6028F211F" X-Mao-Original-Outgoing-Id: 438574723.996701-248b6eaa91e39d0bda4cd7b8aa603846 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Message-Id: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> Date: Mon, 24 Nov 2014 20:18:44 -0600 To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qc6xK2Tqfzcw-mWQ-bocMnqFP5U Subject: [Dime] Updated DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 02:18:52 -0000 --Apple-Mail=_91ABD163-F867-4886-B49F-27D6028F211F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here's the text from the updated requirements analysis. I updated the = summary to be more general, and updated the detail based on mail = discussion. The detail section is marked for deletion before publication = as an RFC.=20 BTW, It's appendix C now because I used the section Steve had already = reserved for it :-) Thanks! Ben. ------------------- Appendix C. Requirements Conformance Analysis This section contains the result of an analysis of the DOIC solutions conformance to the requirements defined in [RFC7068]. C.1. Deferred Requirements The DIME working group chose to defer certain requirements in order to meet an an external deadline. The 3GPP "Core Network and Terminal" working group 4 (CT4) working group wished to reference DOIC as part of Release 12. This required the DOIC base protocol to be substantially complete by the end of 2014. The deferred work includes the following: o Agent Overload - The ability for an agent to report an overload condition of the agent itself. o Load Information - The ability for a node to report its load level when not overloaded. At the time of this writing, DIME has begun separate work efforts for these requirements. C.2. Detection of non-supporting Intermediaries The DOIC mechanism as currently defined does not allow supporting nodes to automatically determine whether OC-Supported-Features or OC- OLR AVPs are originated by a peer node, or by a non-peer node and sent across a non-supporting peer. This makes it impossible to detect the presence of non-supporting nodes between supporting nodes, except by configuration. The working group determined that such a configuration requirement is acceptable. This limits full compliance with certain requirements related to the limitation of new configuration, deployment in environments with mixed support, operating across non-supporting agents, and authorization. C.3. Implicit Application Indication The working group elected to determine the application for an overload report from that of the enclosing message. This prevents sending an OLR for an application when there are no transactions for that application. As a consequence, DOIC does not comply with the requirement to be able to report overload information across quiescent connections. DOIC does not fully comply with requirements to operate on up-to-date information, since if an OLR causes all transactions to stop for an application, the only way traffic will resume is for the OLR to expire. C.4. Stateless Operation RFC7068 explicitly discourages the sending of OLRs in every answer message, as part of the requirement to avoid additional work for overloaded nodes. DOIC recommends exactly that behavior during active overload conditions. The working group determined that doing otherwise would reduce reliability and increase statefulness. (Note that DOIC does allow nodes to avoid sending OLRs in every answer if they have some other method of ensuring that OLRs get to all relevant reacting nodes.) C.5. No New Vulnerabilities The working group believes that DOIC is compliant with the requirement to avoid introducing new vulnerabilities. However, this requirement may warrant an early security expert review. C.6. Detailed Requirements [RFC Editor: Please remove this section and subsections prior to publication as an RFC.] C.6.1. General REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. *Partially Compliant*. The mechanism uses new AVPs piggybacked on existing Diameter messages to exchange overload information. It does not currently support "load" information or the ability to report overload of an agent. These have been left for future extensions. REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3. *Partially Compliant*. The DOIC AVPs can be used in any application that allows the extension of AVPs. However, "load" information is not currently supported. REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity. The overall useful throughput under load is the ultimate measure of the value of a solution. *Compliant*. DOIC provides information that nodes can use to reduce the impact of overload. REQ 4: Diameter allows requests to be sent from either side of a connection, and either side of a connection may have need to provide its overload status. The solution MUST allow each side of a connection to independently inform the other of its overload status. *Compliant*. DOIC AVPs can be included regardless of transaction "direction" REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined. *Compliant*. DOIC contains no assumptions about how peers are discovered. REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge to be configured at each node. *Partially Compliant*. Most DOIC parameters are advertised using the DOIC capability announcement mechanism. However, there are some situations where configuration is required. For example, a DOIC node detect the fact that a peer may not support DOIC when nodes on the other side of the non- supporting node do support DOIC without configuration. C.6.2. Performance REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition. *Compliant*. The specification offers guidance that implementations should apply hysteresis when recovering from overload, and avoid sudden ramp ups in offered load when recovering. REQ 8: Supporting nodes MUST be able to distinguish current overload information from stale information. *Partially Compliant*. DOIC overload reports are "soft state", that is they expire after an indicated period. DOIC nodes may also send reports that end existing overload conditions. DOIC requires reporting nodes to ensure that all relevant reacting nodes receive overload reports. However, since DOIC does not allow reporting nodes to send OLRs in watchdog messages, if an overload condition results in zero offered load, the reporting node cannot update the condition until the expiration of the original OLR. REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections. This is partially derived from the requirement for stability in REQ 7. *Not Compliant*. DOIC does not allow OLRs to be sent over quiescent transport connections. This is due to the fact that OLRs cannot be sent outside of the application to which they apply. REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends. *Partially Compliant*. (See response to previous two requirements.) REQ 11: The solution MUST be able to operate in networks of different sizes. *Compliant*. DOIC makes no assumptions about the size of the network. DOIC can operate purely between clients and servers, or across agents. REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small- scale failure from becoming a widespread outage. *Partially Compliant*. DOIC allows overload reports for an entire realm, where abated traffic will not be redirected towards another server. But in situations where nodes choose to divert traffic to other nodes, DOIC offers no way of knowing whether the new recipients can handle the traffic if they have not already indicated overload. This may be mitigated with the use of a future "load" extension, or with the use of proprietary dynamic load-balancing mechanisms. REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work. *Not Compliant*. DOIC does in fact encourage an overloaded node to send an OLR in every response. The working group that other mechanisms to ensure that every relevant node receives an OLR would create even more work. [Note: This needs discussion.] REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase. *Compliant*. The piggyback mechanism allows OLRs to be sent at the same rate as application traffic. REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms. *Compliant*. DOIC does not require or recommend changes in the handling of transport protocols or connections. C.6.3. Heterogeneous Support for Solution 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. *Partially Compliant*. DOIC works with most mixed-deployment scenarios. However, it cannot work across a non-supporting proxy that modifies Origin-Host AVPs in answer messages. DOIC will have limited impact in networks where the nodes that perform server selections do not support the mechanism. REQ 17: In a mixed environment with nodes that support the solution and nodes that do not, the solution MUST NOT result in materially less useful throughput during overload as would have resulted if the solution were not present. It SHOULD result in less severe overload in this environment. *Compliant*. In most mixed-support deployment, DOIC will offer at least some value, and will not make things worse. 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. *Compliant*. DOIC provides mechanisms to abate load from non- supporting sources. Furthermore, it recommends that reporting nodes will still need to be able to apply whatever protections they would ordinarily apply if DOIC were not in use. REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains. *Partially Compliant*. DOIC allows sending OLRs across administrative domains, and potentially to nodes in other realms. However, an OLR cannot indicate overload for realms other than the one in the Origin-Realm AVP of the containing answer. REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter. *Compliant*. DOIC sends explicit overload indication in overload reports. It does not depend on error result codes. REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of overload. The solution MUST result in at least as much useful throughput as would have resulted if the solution were not in place. *Compliant*. DOIC overload reports have the primary effect of suppressing message retries in overload conditions. DOIC recommends that messages never be silently dropped if at all possible. C.6.4. Granular Control REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node. This throttling SHOULD be graded so that it can be applied gradually as offered load increases. Overload is not a binary state; there may be degrees of overload. *Compliant*. The "loss" algorithm expresses a percentage reduction. REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. *Not Compliant*. DOIC provides no built in mechanism to determine the best place to divert messages that would otherwise be throttled. This can be accomplished with a future "load" extension, or with proprietary load balancing mechanisms. REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring. *Not Compliant*. "Load" information has been left for a future extension. C.6.5. Priority and Policy REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be desirable to send or process over others during times of overload, based on application-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition will be the responsibility of the application specification. *Compliant*. The specification offers guidance on how requests might be prioritized for different types of applications. REQ 26: The solution MUST NOT prevent a node from prioritizing requests based on any local policy, so that certain requests are given preferential treatment, given additional retransmission, not throttled, or processed ahead of others. *Compliant*. Nothing in the specification prevents application-specific, implementation-specific, or local policies. C.6.6. Security REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack or increase the severity of any existing vulnerabilities. This includes vulnerabilities to DoS and DDoS attacks as well as replay and man-in-the-middle attacks. Note that the Diameter base specification [RFC6733] lacks end-to-end security and this must be considered (see the Security Considerations in [RFC7068]). Note that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail. *Compliant*. The working group is not aware of any such vulnerabilities. [This may need further analysis.] REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes. *Partially Compliant*. Since all Diameter security is currently at the transport layer, nodes must trust immediate peers to enforce trust policies. However, there are situations where a DOIC node cannot determine if an immediate peer supports DOIC. The authors recommend an expert security review. REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node. *Partially Compliant*. (See response to previous requirement.) REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks. *Compliant*. The specification recommends that any such protection mechanism needed without DOIC should continue to be employed with DOIC. C.6.7. Flexibility and Extensibility 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. *Partially Compliant*. All DOIC overload reports are scoped to the specific application and realm. Inside that scope, overload can be reported at the specific server or whole realm scope. As currently specified, DOIC cannot indicate local overload for an agent. At the time of this writing, the DIME working group has plans to work on an agent-overload extension. DOIC allows new "scopes" through the use of extended report types. REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control. *Compliant*. DOIC allows new report types and abatement algorithms to be created. These may be indicated using the OC-Supported-Features AVP. REQ 33: The solution MUST provide a default algorithm that is mandatory to implement. *Compliant*. The "loss" algorithm is mandatory to implement. REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution. *Partially Compliant*. DOIC information can traverse non- supporting agents, as long as those agents do not modify certain AVPs. (e.g., Origin-Host). DOIC does not provide a way for supporting nodes to detect such modification. --Apple-Mail=_91ABD163-F867-4886-B49F-27D6028F211F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Here's the text from the updated requirements analysis. I updated the summary to be more general, and updated the detail based on mail discussion. The detail section is marked for deletion before publication as an RFC. 

BTW, It's appendix C now because I used the section Steve had already reserved for it :-)

Thanks!

Ben.
-------------------
Appendix C.  Requirements Conformance Analysis

   This section contains the result of an analysis of the DOIC solutions
   conformance to the requirements defined in [RFC7068].

C.1.  Deferred Requirements

   The DIME working group chose to defer certain requirements in order
   to meet an an external deadline.  The 3GPP "Core Network and
   Terminal" working group 4 (CT4) working group wished to reference
   DOIC as part of Release 12.  This required the DOIC base protocol to
   be substantially complete by the end of 2014.  The deferred work
   includes the following:

   o  Agent Overload - The ability for an agent to report an overload
      condition of the agent itself.

   o  Load Information - The ability for a node to report its load level
      when not overloaded.

   At the time of this writing, DIME has begun separate work efforts for
   these requirements.

C.2.  Detection of non-supporting Intermediaries

   The DOIC mechanism as currently defined does not allow supporting
   nodes to automatically determine whether OC-Supported-Features or OC-
   OLR AVPs are originated by a peer node, or by a non-peer node and
   sent across a non-supporting peer.  This makes it impossible to
   detect the presence of non-supporting nodes between supporting nodes,
   except by configuration.  The working group determined that such a
   configuration requirement is acceptable.

   This limits full compliance with certain requirements related to the
   limitation of new configuration, deployment in environments with
   mixed support, operating across non-supporting agents, and
   authorization.

C.3.  Implicit Application Indication

   The working group elected to determine the application for an
   overload report from that of the enclosing message.  This prevents
   sending an OLR for an application when there are no transactions for
   that application.

   As a consequence, DOIC does not comply with the requirement to be
   able to report overload information across quiescent connections.
   DOIC does not fully comply with requirements to operate on up-to-date
   information, since if an OLR causes all transactions to stop for an
   application, the only way traffic will resume is for the OLR to
   expire.

C.4.  Stateless Operation

   RFC7068 explicitly discourages the sending of OLRs in every answer
   message, as part of the requirement to avoid additional work for
   overloaded nodes.  DOIC recommends exactly that behavior during
   active overload conditions.  The working group determined that doing
   otherwise would reduce reliability and increase statefulness.  (Note
   that DOIC does allow nodes to avoid sending OLRs in every answer if
   they have some other method of ensuring that OLRs get to all relevant
   reacting nodes.)

C.5.  No New Vulnerabilities

   The working group believes that DOIC is compliant with the
   requirement to avoid introducing new vulnerabilities.  However, this
   requirement may warrant an early security expert review.

C.6.  Detailed Requirements

   [RFC Editor: Please remove this section and subsections prior to
   publication as an RFC.]

C.6.1.  General

   REQ 1:  The solution MUST provide a communication method for Diameter
           nodes to exchange load and overload information.

           *Partially Compliant*. The mechanism uses new AVPs
           piggybacked on existing Diameter messages to exchange
           overload information.  It does not currently support "load"
           information or the ability to report overload of an agent.
           These have been left for future extensions.



   REQ 2:  The solution MUST allow Diameter nodes to support overload
           control regardless of which Diameter applications they
           support.  Diameter clients and agents must be able to use the
           received load and overload information to support graceful
           behavior during an overload condition.  Graceful behavior
           under overload conditions is best described by REQ 3.

           *Partially Compliant*. The DOIC AVPs can be used in any
           application that allows the extension of AVPs.  However,
           "load" information is not currently supported.



   REQ 3:  The solution MUST limit the impact of overload on the overall
           useful throughput of a Diameter server, even when the
           incoming load on the network is far in excess of its
           capacity.  The overall useful throughput under load is the
           ultimate measure of the value of a solution.

           *Compliant*. DOIC provides information that nodes can use to
           reduce the impact of overload.



   REQ 4:  Diameter allows requests to be sent from either side of a
           connection, and either side of a connection may have need to
           provide its overload status.  The solution MUST allow each
           side of a connection to independently inform the other of its
           overload status.

           *Compliant*. DOIC AVPs can be included regardless of
           transaction "direction"



   REQ 5:  Diameter allows nodes to determine their peers via dynamic
           discovery or manual configuration.  The solution MUST work
           consistently without regard to how peers are determined.

           *Compliant*. DOIC contains no assumptions about how peers are
           discovered.



   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require that this knowledge
           to be configured at each node.

           *Partially Compliant*. Most DOIC parameters are advertised
           using the DOIC capability announcement mechanism.  However,
           there are some situations where configuration is required.
           For example, a DOIC node detect the fact that a peer may not
           support DOIC when nodes on the other side of the non-
           supporting node do support DOIC without configuration.



C.6.2.  Performance

   REQ 7:  The solution and any associated default algorithm(s) MUST
           ensure that the system remains stable.  At some point after
           an overload condition has ended, the solution MUST enable
           capacity to stabilize and become equal to what it would be in
           the absence of an overload condition.  Note that this also
           requires that the solution MUST allow nodes to shed load
           without introducing non-converging oscillations during or
           after an overload condition.

           *Compliant*. The specification offers guidance that
           implementations should apply hysteresis when recovering from
           overload, and avoid sudden ramp ups in offered load when
           recovering.



   REQ 8:  Supporting nodes MUST be able to distinguish current overload
           information from stale information.

           *Partially Compliant*. DOIC overload reports are "soft
           state", that is they expire after an indicated period.  DOIC
           nodes may also send reports that end existing overload
           conditions.  DOIC requires reporting nodes to ensure that all
           relevant reacting nodes receive overload reports.

           However, since DOIC does not allow reporting nodes to send
           OLRs in watchdog messages, if an overload condition results
           in zero offered load, the reporting node cannot update the
           condition until the expiration of the original OLR.



   REQ 9:  The solution MUST function across fully loaded as well as
           quiescent transport connections.  This is partially derived
           from the requirement for stability in REQ 7.

           *Not Compliant*. DOIC does not allow OLRs to be sent over
           quiescent transport connections.  This is due to the fact
           that OLRs cannot be sent outside of the application to which
           they apply.



   REQ 10: Consumers of overload information MUST be able to determine
           when the overload condition improves or ends.

           *Partially Compliant*. (See response to previous two
           requirements.)



   REQ 11: The solution MUST be able to operate in networks of different
           sizes.

           *Compliant*. DOIC makes no assumptions about the size of the
           network.  DOIC can operate purely between clients and
           servers, or across agents.



   REQ 12: When a single network node fails, goes into overload, or
           suffers from reduced processing capacity, the solution MUST
           make it possible to limit the impact of the affected node on
           other nodes in the network.  This helps to prevent a small-
           scale failure from becoming a widespread outage.

           *Partially Compliant*. DOIC allows overload reports for an
           entire realm, where abated traffic will not be redirected
           towards another server.  But in situations where nodes choose
           to divert traffic to other nodes, DOIC offers no way of
           knowing whether the new recipients can handle the traffic if
           they have not already indicated overload.  This may be
           mitigated with the use of a future "load" extension, or with
           the use of proprietary dynamic load-balancing mechanisms.



   REQ 13: The solution MUST NOT introduce substantial additional work
           for a node in an overloaded state.  For example, a
           requirement for an overloaded node to send overload
           information every time it received a new request would
           introduce substantial work.

           *Not Compliant*. DOIC does in fact encourage an overloaded
           node to send an OLR in every response.  The working group
           that other mechanisms to ensure that every relevant node
           receives an OLR would create even more work.  [Note: This
           needs discussion.]



   REQ 14: Some scenarios that result in overload involve a rapid
           increase of traffic with little time between normal levels
           and levels that induce overload.  The solution SHOULD provide
           for rapid feedback when traffic levels increase.

           *Compliant*. The piggyback mechanism allows OLRs to be sent
           at the same rate as application traffic.



   REQ 15: The solution MUST NOT interfere with the congestion control
           mechanisms of underlying transport protocols.  For example, a
           solution that opened additional TCP connections when the
           network is congested would reduce the effectiveness of the
           underlying congestion control mechanisms.

           *Compliant*. DOIC does not require or recommend changes in
           the handling of transport protocols or connections.



C.6.3.  Heterogeneous Support for Solution

   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.

           *Partially Compliant*. DOIC works with most mixed-deployment
           scenarios.  However, it cannot work across a non-supporting
           proxy that modifies Origin-Host AVPs in answer messages.
           DOIC will have limited impact in networks where the nodes
           that perform server selections do not support the mechanism.



   REQ 17: In a mixed environment with nodes that support the solution
           and nodes that do not, the solution MUST NOT result in
           materially less useful throughput during overload as would
           have resulted if the solution were not present.  It SHOULD
           result in less severe overload in this environment.

           *Compliant*. In most mixed-support deployment, DOIC will
           offer at least some value, and will not make things worse.



   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.

           *Compliant*. DOIC provides mechanisms to abate load from non-
           supporting sources.  Furthermore, it recommends that
           reporting nodes will still need to be able to apply whatever
           protections they would ordinarily apply if DOIC were not in
           use.



   REQ 19: It MUST be possible to use the solution between nodes in
           different realms and in different administrative domains.

           *Partially Compliant*. DOIC allows sending OLRs across
           administrative domains, and potentially to nodes in other
           realms.  However, an OLR cannot indicate overload for realms
           other than the one in the Origin-Realm AVP of the containing
           answer.



   REQ 20: Any explicit overload indication MUST be clearly
           distinguishable from other errors reported via Diameter.

           *Compliant*. DOIC sends explicit overload indication in
           overload reports.  It does not depend on error result codes.



   REQ 21: In cases where a network node fails, is so overloaded that it
           cannot process messages, or cannot communicate due to a
           network failure, it may not be able to provide explicit
           indications of the nature of the failure or its levels of
           overload.  The solution MUST result in at least as much
           useful throughput as would have resulted if the solution were
           not in place.

           *Compliant*. DOIC overload reports have the primary effect of
           suppressing message retries in overload conditions.  DOIC
           recommends that messages never be silently dropped if at all
           possible.



C.6.4.  Granular Control

   REQ 22: The solution MUST provide a way for a node to throttle the
           amount of traffic it receives from a peer node.  This
           throttling SHOULD be graded so that it can be applied
           gradually as offered load increases.  Overload is not a
           binary state; there may be degrees of overload.

           *Compliant*. The "loss" algorithm expresses a percentage
           reduction.



   REQ 23: The solution MUST provide sufficient information to enable a
           load-balancing node to divert messages that are rejected or
           otherwise throttled by an overloaded upstream node to other
           upstream nodes that are the most likely to have sufficient
           capacity to process them.

           *Not Compliant*. DOIC provides no built in mechanism to
           determine the best place to divert messages that would
           otherwise be throttled.  This can be accomplished with a
           future "load" extension, or with proprietary load balancing
           mechanisms.



   REQ 24: The solution MUST provide a mechanism for indicating load
           levels, even when not in an overload condition, to assist
           nodes in making decisions to prevent overload conditions from
           occurring.

           *Not Compliant*. "Load" information has been left for a
           future extension.



C.6.5.  Priority and Policy

   REQ 25: The base specification for the solution SHOULD offer general
           guidance on which message types might be desirable to send or
           process over others during times of overload, based on
           application-specific considerations.  For example, it may be
           more beneficial to process messages for existing sessions
           ahead of new sessions.  Some networks may have a requirement
           to give priority to requests associated with emergency
           sessions.  Any normative or otherwise detailed definition of
           the relative priorities of message types during an overload
           condition will be the responsibility of the application
           specification.

           *Compliant*. The specification offers guidance on how
           requests might be prioritized for different types of
           applications.



   REQ 26: The solution MUST NOT prevent a node from prioritizing
           requests based on any local policy, so that certain requests
           are given preferential treatment, given additional
           retransmission, not throttled, or processed ahead of others.

           *Compliant*. Nothing in the specification prevents
           application-specific, implementation-specific, or local
           policies.



C.6.6.  Security

   REQ 27: The solution MUST NOT provide new vulnerabilities to
           malicious attack or increase the severity of any existing
           vulnerabilities.  This includes vulnerabilities to DoS and
           DDoS attacks as well as replay and man-in-the-middle attacks.
           Note that the Diameter base specification [RFC6733] lacks
           end-to-end security and this must be considered (see the
           Security Considerations in [RFC7068]).  Note that this
           requirement was expressed at a high level so as to not
           preclude any particular solution.  Is is expected that the
           solution will address this in more detail.

           *Compliant*. The working group is not aware of any such
           vulnerabilities.  [This may need further analysis.]



   REQ 28: The solution MUST NOT depend on being deployed in
           environments where all Diameter nodes are completely trusted.
           It SHOULD operate as effectively as possible in environments
           where other nodes are malicious; this includes preventing
           malicious nodes from obtaining more than a fair share of
           service.  Note that this does not imply any responsibility on
           the solution to detect, or take countermeasures against,
           malicious nodes.

           *Partially Compliant*. Since all Diameter security is
           currently at the transport layer, nodes must trust immediate
           peers to enforce trust policies.  However, there are
           situations where a DOIC node cannot determine if an immediate
           peer supports DOIC.  The authors recommend an expert security
           review.



   REQ 29: It MUST be possible for a supporting node to make
           authorization decisions about what information will be sent
           to peer nodes based on the identity of those nodes.  This
           allows a domain administrator who considers the load of their
           nodes to be sensitive information to restrict access to that
           information.  Of course, in such cases, there is no
           expectation that the solution itself will help prevent
           overload from that peer node.

           *Partially Compliant*. (See response to previous
           requirement.)



   REQ 30: The solution MUST NOT interfere with any Diameter-compliant
           method that a node may use to protect itself from overload
           from non-supporting nodes or from denial-of-service attacks.

           *Compliant*. The specification recommends that any such
           protection mechanism needed without DOIC should continue to
           be employed with DOIC.



C.6.7.  Flexibility and Extensibility

   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.

           *Partially Compliant*. All DOIC overload reports are scoped
           to the specific application and realm.  Inside that scope,
           overload can be reported at the specific server or whole
           realm scope.  As currently specified, DOIC cannot indicate
           local overload for an agent.  At the time of this writing,
           the DIME working group has plans to work on an agent-overload
           extension.

           DOIC allows new "scopes" through the use of extended report
           types.



   REQ 32: The solution MUST provide a method for extending the
           information communicated and the algorithms used for overload
           control.

           *Compliant*. DOIC allows new report types and abatement
           algorithms to be created.  These may be indicated using the
           OC-Supported-Features AVP.



   REQ 33: The solution MUST provide a default algorithm that is
           mandatory to implement.

           *Compliant*. The "loss" algorithm is mandatory to implement.



   REQ 34: The solution SHOULD provide a method for exchanging overload
           and load information between elements that are connected by
           intermediaries that do not support the solution.

           *Partially Compliant*. DOIC information can traverse non-
           supporting agents, as long as those agents do not modify
           certain AVPs. (e.g., Origin-Host).  DOIC does not provide a
           way for supporting nodes to detect such modification.

--Apple-Mail=_91ABD163-F867-4886-B49F-27D6028F211F-- From nobody Tue Nov 25 01:09: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 A70871A008A for ; Tue, 25 Nov 2014 01:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 IylwKjdfu-qn for ; Tue, 25 Nov 2014 01:09:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303DC1A007E for ; Tue, 25 Nov 2014 01:09:10 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 2F2CFC0269; Tue, 25 Nov 2014 10:09:08 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 12155C8081; Tue, 25 Nov 2014 10:09:08 +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.0210.002; Tue, 25 Nov 2014 10:09:07 +0100 From: To: "dime@ietf.org" Thread-Topic: WGLC for draft-ietf-dime-congestion-flow-attributes-01 Thread-Index: AdAIjxU+v6kXSNpPTf2oD++zGQ1VZw== Date: Tue, 25 Nov 2014 09:09:06 +0000 Message-ID: <8730_1416906548_54744734_8730_3173_1_6B7134B31289DC4FAF731D844122B36E93E944@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.4] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E93E944PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.25.72121 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Hl9TegPfCOfClqtr8pAcEJF8mgo Cc: "dime-ads@tools.ietf.org" , "dime-chairs@tools.ietf.org" Subject: [Dime] WGLC for draft-ietf-dime-congestion-flow-attributes-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 09:09:20 -0000 --_000_6B7134B31289DC4FAF731D844122B36E93E944PEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As discussed at the last IETF meeting, the authors of draft-ietf-dime-conge= stion-flow-attributes have requested for a WGLC and I think the document is= stable enough for it. This email starts a two weeks WGLC for draft-ietf-dime-congestion-flow-attr= ibutes-01 (http://tools.ietf.org/html/draft-ietf-dime-congestion-flow-attri= butes-01) The WGLC will end Tuesday, December 9, 2014. Post your comments to the mailing list and if you think something needs to = be changed, put that also into the Issue Tracker. - Lionel & Jouni ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E93E944PEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

As discussed at the last IET= F meeting, the authors of draft-ietf-dime-congestion-flow-attributes have r= equested for a WGLC and I think the document is stable enough for it.<= /o:p>

 

This email starts a two week= s WGLC for draft-ietf-dime-congestion-flow-attributes-01 (http://= tools.ietf.org/html/draft-ietf-dime-congestion-flow-attributes-01)

The WGLC will end Tuesday, D= ecember 9, 2014.

 

Post your comments to the ma= iling list and if you think something needs to be changed, put that also in= to the Issue Tracker.

 

- Lionel & Jouni

 

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E93E944PEXCVZYM13corpora_-- From nobody Tue Nov 25 06:06: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 16DC61A01AA for ; Tue, 25 Nov 2014 06:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 yc7bT4mPlIj0 for ; Tue, 25 Nov 2014 06:06:40 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260721A1A46 for ; Tue, 25 Nov 2014 06:06:40 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52846 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XtGlH-0003PT-1V; Tue, 25 Nov 2014 06:06:36 -0800 Message-ID: <54748CEA.3020705@usdonovans.com> Date: Tue, 25 Nov 2014 08:06:34 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , lionel.morand@orange.com References: <545792B6.8030502@usdonovans.com> <, > <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NBaH3ttSues5VL8nAxlHgTd8iqs Cc: "dime@ietf.org" Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 14:06:46 -0000 I'm ok with Ben's wording and will make the change unless I hear objections on the list. Steve On 11/21/14, 5:01 PM, Ben Campbell wrote: > On reflection, I think there might be a subtlety here. The resulting offered-load may still exceed the reporting node's current capacity. This can be true even if it's sent an OLR (and thus has related OCS). As mentioned in the surrounding node needs to still be able to protect itself, possibly by throttling. Therefore, I propose the sentence take the form of non-normative guidance. For example: > > "When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes." > > >> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote: >> >> I can live with the text proposed by Ulrich. But what is wrong with: >> >> " Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which an active OCS applies." ? >> >> Envoyé depuis mon Sony Xperia SP d'Orange >> >> ---- Maria Cruz Bartolome a écrit ---- >> >> >>> Section 4.2.3, 13th paragraph, 2nd sentence: >>> Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. >>> Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies. >>> >>> [LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS. >> SRD> I'm ok with Ulrich's change. >> >> [LM] and this is incorrect but not fundamental. The reporting node does not have to "remember" a previously sent OLR. What it will do is to refer to existing OCS to know that throttling should not be applied. An OCS is a consequence of an sent OLR but it is not an OLR itself. But not fundamental here. >> >> [MCruz] I am ok with Ulrich's change. It does not mean that the reporting node needs to "remember" a previously sent OLR, though. The change only proposes to "identify" which OLR we refer to. >> >> Best regards >> /MCruz >> >> >> _________________________________________________________________________________________________________________________ >> >> 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 nobody Tue Nov 25 06:21: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 5AB151A1A5A for ; Tue, 25 Nov 2014 06:21:16 -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 kpdx1u1i8wmN for ; Tue, 25 Nov 2014 06:21:15 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C773B1A1A7F for ; Tue, 25 Nov 2014 06:20:52 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52857 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XtGz3-00079s-MP for dime@ietf.org; Tue, 25 Nov 2014 06:20:52 -0800 Message-ID: <54749041.6060105@usdonovans.com> Date: Tue, 25 Nov 2014 08:20:49 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------060808040607010701010600" 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/ypMbtzGobIF2PZ3_Ajyr4q6WPEw Subject: [Dime] Proposed wording change in Section 6.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 14:21:16 -0000 This is a multi-part message in MIME format. --------------060808040607010701010600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, The current wording for the OC-Supported-Features AVP says that it MUST be included in all messages a DOIC supporting node sends. The OC-Supported- Features AVP MUST be included in every Diameter request message a DOIC supporting node sends. We need to qualify this a little as there will be cases where a Diameter node supports DOIC but the application does not require use of DOIC. Requests originated by an HSS in the S6a application is an example of this as 3GPP CT4 is defining that application to only use DOIC on requests traveling from the MME to the HSS. I propose the following wording to replace the above sentence: The OC-Supported-Features AVP MUST be included by a DOIC node in every Diameter request message for applications that have defined support for the DOIC solution on messages sent by the DOIC node. Note: It is expected that there will be applications that define the use of DOIC only for requests flowing from Diameter Clients to Diameter Servers and not for requests flowing from Diameter Servers to Diameter Clients. In this case a Diameter Server that supports the DOIC solution will not include the OC-Supported-Features header in request messages it sends. I'll update the document accordingly unless I hear objections on the list. Regards, Steve --------------060808040607010701010600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

The current wording for the OC-Supported-Features AVP says that it MUST be included in all messages a DOIC supporting node sends. 

The OC-Supported-
   Features AVP MUST be included in every Diameter request message a
   DOIC supporting node sends.

We need to qualify this a little as there will be cases where a Diameter node supports DOIC but the application does not require use of DOIC.  Requests originated by an HSS in the S6a application is an example of this as 3GPP CT4 is defining that application to only use DOIC on requests traveling from the MME to the HSS.

I propose the following wording to replace the above sentence:

The OC-Supported-Features AVP MUST be included by a DOIC node in every Diameter request message for applications that have defined support for the DOIC solution on messages sent by the DOIC node.

      Note: It is expected that there will be applications that define the use of DOIC only for requests flowing from Diameter Clients to Diameter Servers and not for requests flowing from Diameter Servers to Diameter Clients.  In this case a Diameter Server that supports the DOIC solution will not include the OC-Supported-Features header in request messages it sends.

I'll update the document accordingly unless I hear objections on the list.

Regards,

Steve
--------------060808040607010701010600-- From nobody Tue Nov 25 08: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 6A52B1ACCF8 for ; Tue, 25 Nov 2014 08:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq9qzZzLmAfL for ; Tue, 25 Nov 2014 08:24:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C421ACD29 for ; Tue, 25 Nov 2014 08:24:55 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAPGOs3M051186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 10:24: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.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <54749041.6060105@usdonovans.com> Date: Tue, 25 Nov 2014 10:24:53 -0600 X-Mao-Original-Outgoing-Id: 438625493.77663-116a8feaba971d01e19abd37eb49fc54 Content-Transfer-Encoding: quoted-printable Message-Id: <6DEDC346-525E-4BC1-B18E-CF56A9D8407F@nostrum.com> References: <54749041.6060105@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GanHB6OWMoXV5PKDRJN4RqAG2xc Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed wording change in Section 6.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:24:59 -0000 I'm not sure I agree with the approach. Comments inline: > On Nov 25, 2014, at 8:20 AM, Steve Donovan = wrote: >=20 > All, >=20 > The current wording for the OC-Supported-Features AVP says that it = MUST be included in all messages a DOIC supporting node sends.=20 >=20 > The OC-Supported- > Features AVP MUST be included in every Diameter request message a > DOIC supporting node sends. >=20 >=20 > We need to qualify this a little as there will be cases where a = Diameter node supports DOIC but the application does not require use of = DOIC. Requests originated by an HSS in the S6a application is an = example of this as 3GPP CT4 is defining that application to only use = DOIC on requests traveling from the MME to the HSS. >=20 > I propose the following wording to replace the above sentence: >=20 > The OC-Supported-Features AVP MUST be included by a DOIC node in every = Diameter request message for applications that have defined support for = the DOIC solution on messages sent by the DOIC node. I don't think we need to tie this to application definitions. A DOIC = node can use DOIC with an application that doesn't "define" it. And a = deployment might choose not to use DOIC for reasons other than what is = in the definition. Also, I don't think that statement needs to be normative. We don't need = 2119 language to describe the basic flow of the protocol.=20 Proposal (non-normative) "A DOIC node indicates that it is willing to act as a reacting node for = an application by including the OC-Supported-Features AVP in each = request message it sends for that application." OTOH, if people insist on making this normative: "A DOIC node that is willing to act as a reacting node for an = application MUST include the OC-Supported-Features AVP in each request = it sends for that application" Note: "for an application" might need to be "for a realm and = application" >=20 > Note: It is expected that there will be applications that define = the use of DOIC only for requests flowing from Diameter Clients to = Diameter Servers and not for requests flowing from Diameter Servers to = Diameter Clients. In this case a Diameter Server that supports the DOIC = solution will not include the OC-Supported-Features header in request = messages it sends. >=20 > I'll update the document accordingly unless I hear objections on the = list. >=20 > Regards, >=20 > Steve > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Nov 25 08:42: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 D79651ACDDA for ; Tue, 25 Nov 2014 08:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69CpVRcybHQ5 for ; Tue, 25 Nov 2014 08:42:06 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAF1A6FE8 for ; Tue, 25 Nov 2014 08:42:05 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 11:42:05 -0500 From: Dave Dolson To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposed wording change in Section 6.1 Thread-Index: AQHQCLsXR/xgKVAA70uIPsRAkGKWgZxx2wqA//+wwaA= Date: Tue, 25 Nov 2014 16:42:05 +0000 Message-ID: References: <54749041.6060105@usdonovans.com> <6DEDC346-525E-4BC1-B18E-CF56A9D8407F@nostrum.com> In-Reply-To: <6DEDC346-525E-4BC1-B18E-CF56A9D8407F@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.72] 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/_2D-o9jueWC0l4cH6Za8l1WzKVc Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed wording change in Section 6.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:42:08 -0000 Is the idea that a host consistently either send the AVP or not send the AV= P, but be consistent for a given message type? -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Tuesday, November 25, 2014 11:25 AM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed wording change in Section 6.1 I'm not sure I agree with the approach. Comments inline: > On Nov 25, 2014, at 8:20 AM, Steve Donovan wro= te: >=20 > All, >=20 > The current wording for the OC-Supported-Features AVP says that it MUST b= e included in all messages a DOIC supporting node sends.=20 >=20 > The OC-Supported- > Features AVP MUST be included in every Diameter request message a > DOIC supporting node sends. >=20 >=20 > We need to qualify this a little as there will be cases where a Diameter = node supports DOIC but the application does not require use of DOIC. Reque= sts originated by an HSS in the S6a application is an example of this as 3G= PP CT4 is defining that application to only use DOIC on requests traveling = from the MME to the HSS. >=20 > I propose the following wording to replace the above sentence: >=20 > The OC-Supported-Features AVP MUST be included by a DOIC node in every Di= ameter request message for applications that have defined support for the D= OIC solution on messages sent by the DOIC node. I don't think we need to tie this to application definitions. A DOIC node c= an use DOIC with an application that doesn't "define" it. And a deployment = might choose not to use DOIC for reasons other than what is in the definiti= on. Also, I don't think that statement needs to be normative. We don't need 211= 9 language to describe the basic flow of the protocol.=20 Proposal (non-normative) "A DOIC node indicates that it is willing to act as a reacting node for an = application by including the OC-Supported-Features AVP in each request mess= age it sends for that application." OTOH, if people insist on making this normative: "A DOIC node that is willing to act as a reacting node for an application M= UST include the OC-Supported-Features AVP in each request it sends for that= application" Note: "for an application" might need to be "for a realm and application" >=20 > Note: It is expected that there will be applications that define th= e use of DOIC only for requests flowing from Diameter Clients to Diameter S= ervers and not for requests flowing from Diameter Servers to Diameter Clien= ts. In this case a Diameter Server that supports the DOIC solution will no= t include the OC-Supported-Features header in request messages it sends. >=20 > I'll update the document accordingly unless I hear objections on the list= . >=20 > Regards, >=20 > 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 From nobody Tue Nov 25 09:10: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 0C6E21A6FBC for ; Tue, 25 Nov 2014 09:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Jpw17twqiiMv for ; Tue, 25 Nov 2014 09:10:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41C31A6F84 for ; Tue, 25 Nov 2014 09:10:03 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CD2AA32407E; Tue, 25 Nov 2014 18:10:01 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B0CD94C074; Tue, 25 Nov 2014 18:10:01 +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.0210.002; Tue, 25 Nov 2014 18:10:01 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Early candidate DOIC-05 Thread-Index: AQHQBTP/PyuPNG4WP02nm5gUo3eHN5xxkbRg Date: Tue, 25 Nov 2014 17:10:00 +0000 Message-ID: <10946_1416935401_5474B7E9_10946_109_1_6B7134B31289DC4FAF731D844122B36E940D68@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <546E02B6.30108@usdonovans.com> In-Reply-To: <546E02B6.30108@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.4] 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.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_CXpoFN2vLke7IPYhOXI0Tap_xg Subject: Re: [Dime] Early candidate DOIC-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 17:10:12 -0000 Hi Steve, All Please find below straightforward editorial comments. Regards, Lionel ...........................................................................= ... *Section 3: DOIC nodes do not generate new messages to carry DOIC related information. Rather, they "piggyback" DOIC information over existing Diameter messages by inserting new AVPs into existing Diameter requests and responses. Nodes indicate support for DOIC, and any needed DOIC parameters, by inserting an OC_Supported_Features AVP s/ OC_Supported_Features AVP/ OC-Supported-Features AVP (Section 6.2) into existing requests and responses. Reporting nodes send OLRs by inserting OC-OLR AVPs (Section 6.3). Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of some of the parameters of an OLR and the procedures required for overload abatement. An overlaod abatement algorithm separates s/ overlaod/ overload Diameter requests into two sets. The first set contains the requests that are to undergo overload abatement treatment of either throttling or diversion. The second set contains the requests that are to be given normal routing treatment. This document specifies a single must-support algorithm, namely the "loss" algorithm (Section 5). Future specifications may introduce new algorithms. *Section 3.2: Reporting nodes are allowed to change the overload abatement algorithm indicated in the OC-Feature-Vector AVP if the reporting node is not currently in and overload condition and sending overload s/ in and overload/ in an overload reports. The reporting node is not allowed to change the overload abatement algorithm while the reporting node is in an overload load condition. s/ is in an overload load condition/ is in an overload condition *Section 3.3 Two types of overload abatement treatement are defined, diversion and s/ treatement/ treatment throttling. Reacting nodes are responsible for determining which treatment is appropraite for individual requests. s/ appropraite/appropriate *Section 3.4: Reporting nodes use the OC-OLR AVP to communicate overload occurrences. This AVP can also be extended to add new AVPs allowing a reporting nodes to communicate additional information about s/ a reporting nodes/reporting nodes handling an overload condition. *section 4.2.2 If the request matches an active OCS then the reacting node MUST use the overload abatement algorithm incideated in the OCS to determine s/ incideated/indicated if the request is to receive overload abatement treatment. [skip] In the case that the OCS entry indicated no traffic was to be sent to the overloaded entity and the validity duration expires or has a validity duration of zero ("0"), meaning that the reporting node has explicitly signaled the end of the overload condition then overlaod s/ overlaod/overload abatement associated with the overload abatement MUST be ended in a controlled fashion. *Section 4.2.3: A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. s/ a overload condition/an overload condition [skip] A reporting node SHOULD decrease requested overload abatement treatment in a controlled fashion to avoid occillations in traffic. s/ occillations/oscillations=20 *Section 6.8: In the table, replace "x.x" by the corresponding section number, e.g. : OC-Supported-Features TBD1 x.x Grouped=20=20=20=20=20 OC-Supported-Features TBD1 6.1 Grouped=20=20=20=20=20 *Section 9.1: The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide s/IPSec/IPsec confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. *Appendix D, Section D.3: Intra-Session Request: An intra session request is a request that uses the same Session- s/ An intra session request/ An intra-session request Id than the one used in a previous request. An intra session s/ An intra-session/ An intra-session request generally needs to be delivered to the server that handled the session creating request for the session. The STR message defined in [RFC6733] is an example of an intra-session requests. s/ an intra-session requests/ an intra-session request -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: jeudi 20 novembre 2014 16:03 =C0=A0: dime@ietf.org Objet=A0: [Dime] Early candidate DOIC-05 All, I've attached an early candidate for the DOIC-05 specification. This change= contains the updates discussed at the Honolulu Dime working group meeting,= the informal meeting held the next day and comments received via the Dime = mailing list. The areas still requiring work are an update to the security considerations= section and adding text to the requirement conformance section. These changes have been pushed into github. I have also attached a diff file showing changes from DOIC-04. 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. From nobody Tue Nov 25 10: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 8C0991A6FFB for ; Tue, 25 Nov 2014 10:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1NtYkynOioiQ for ; Tue, 25 Nov 2014 10:10:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C26B1A6FF8 for ; Tue, 25 Nov 2014 10:10:36 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 56C681B82CB; Tue, 25 Nov 2014 19:10:34 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 09A59C8086; Tue, 25 Nov 2014 19:10: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.0210.002; Tue, 25 Nov 2014 19:10:33 +0100 From: To: Dave Dolson , Ben Campbell , "Steve Donovan" Thread-Topic: [Dime] Proposed wording change in Section 6.1 Thread-Index: AQHQCLsXR/xgKVAA70uIPsRAkGKWgZxx2wqA//+wwaCAABVrIA== Date: Tue, 25 Nov 2014 18:10:32 +0000 Message-ID: <15923_1416939034_5474C61A_15923_10043_1_6B7134B31289DC4FAF731D844122B36E94131D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <54749041.6060105@usdonovans.com> <6DEDC346-525E-4BC1-B18E-CF56A9D8407F@nostrum.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.4] 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.11.25.125722 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OHaLo_EaOQmg7FqA4XFw2Xhl1oA Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed wording change in Section 6.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:10:56 -0000 Hi Steve, Ben, IMHO, including the OC-Supported-Features AVP is not related to the type of= request but to an application. You can advertise the supported features in every application request, even= if the OLR will be in fine received only in some specific answers (e.g. an= swer of the HSS in S6a) So the proposed text could be: OLD:=20 The OC-Supported-Features AVP MUST be included in every Diameter request= message a DOIC supporting node sends. NEW: The OC-Supported-Features AVP MUST be included in every Diameter request= message a DOIC supporting node sends for an application supporting the ove= rload control mechanism specified in this document. regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Dave Dolson Envoy=E9=A0: mardi 25 novembre 2014 17:42 =C0=A0: Ben Campbell; Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Proposed wording change in Section 6.1 Is the idea that a host consistently either send the AVP or not send the AV= P, but be consistent for a given message type? -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Tuesday, November 25, 2014 11:25 AM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed wording change in Section 6.1 I'm not sure I agree with the approach. Comments inline: > On Nov 25, 2014, at 8:20 AM, Steve Donovan wro= te: >=20 > All, >=20 > The current wording for the OC-Supported-Features AVP says that it MUST b= e included in all messages a DOIC supporting node sends.=20 >=20 > The OC-Supported- > Features AVP MUST be included in every Diameter request message a > DOIC supporting node sends. >=20 >=20 > We need to qualify this a little as there will be cases where a Diameter = node supports DOIC but the application does not require use of DOIC. Reque= sts originated by an HSS in the S6a application is an example of this as 3G= PP CT4 is defining that application to only use DOIC on requests traveling = from the MME to the HSS. >=20 > I propose the following wording to replace the above sentence: >=20 > The OC-Supported-Features AVP MUST be included by a DOIC node in every Di= ameter request message for applications that have defined support for the D= OIC solution on messages sent by the DOIC node. I don't think we need to tie this to application definitions. A DOIC node c= an use DOIC with an application that doesn't "define" it. And a deployment = might choose not to use DOIC for reasons other than what is in the definiti= on. Also, I don't think that statement needs to be normative. We don't need 211= 9 language to describe the basic flow of the protocol.=20 Proposal (non-normative) "A DOIC node indicates that it is willing to act as a reacting node for an = application by including the OC-Supported-Features AVP in each request mess= age it sends for that application." OTOH, if people insist on making this normative: "A DOIC node that is willing to act as a reacting node for an application M= UST include the OC-Supported-Features AVP in each request it sends for that= application" Note: "for an application" might need to be "for a realm and application" >=20 > Note: It is expected that there will be applications that define th= e use of DOIC only for requests flowing from Diameter Clients to Diameter S= ervers and not for requests flowing from Diameter Servers to Diameter Clien= ts. In this case a Diameter Server that supports the DOIC solution will no= t include the OC-Supported-Features header in request messages it sends. >=20 > I'll update the document accordingly unless I hear objections on the list. >=20 > Regards, >=20 > 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 _______________________________________________ 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 Tue Nov 25 10: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 B80F01A8728 for ; Tue, 25 Nov 2014 10:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GnCgVX3PUi11 for ; Tue, 25 Nov 2014 10:27:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254641A8730 for ; Tue, 25 Nov 2014 10:26:27 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7F49822C419; Tue, 25 Nov 2014 19:26:08 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5B34635C08E; Tue, 25 Nov 2014 19:26:08 +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.0210.002; Tue, 25 Nov 2014 19:26:07 +0100 From: To: Steve Donovan , Ben Campbell Thread-Topic: [Dime] Updates to DOIC -05 Thread-Index: AQHQCLkLtbhkKJujEUOTRevLVMLBtZxxpbYg Date: Tue, 25 Nov 2014 18:26:07 +0000 Message-ID: <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <545792B6.8030502@usdonovans.com> <,> <5BCBA1FC2B7F0B4C9D935572D900066815228896@DEMUMBX014.nsn-intra.net> <27821_1415638160_5460EC90_27821_11346_1_p06qflk23f6m2rnbccc4grl9.1415638140857@email.android.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <,> <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> <54748CEA.3020705@usdonovans.com> In-Reply-To: <54748CEA.3020705@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.4] 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.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/E2YEJ8ypXtVvOPtnZ5FbRs9AVI8 Cc: "dime@ietf.org" Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:27:47 -0000 I'm OK with the idea of the text proposed by Ben. I would just make clear that throttling is applicable to the fact of sendin= g/forwarding requests (cf. definition). A reporting node may apply local th= rottling if it is an agent. But if it is a server, it can either drop the e= xceeded number of requests (no response sent to the downstream) or send a s= pecific DIAMETER-TOO-BUSY response. I think that this clarification is some= how missing in the document. Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mardi 25 novembre 2014 15:07 =C0=A0: Ben Campbell; MORAND Lionel IMT/OLN Cc=A0: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome Objet=A0: Re: [Dime] Updates to DOIC -05 I'm ok with Ben's wording and will make the change unless I hear objections= on the list. Steve On 11/21/14, 5:01 PM, Ben Campbell wrote: > On reflection, I think there might be a subtlety here. The resulting offe= red-load may still exceed the reporting node's current capacity. This can b= e true even if it's sent an OLR (and thus has related OCS). As mentioned in= the surrounding node needs to still be able to protect itself, possibly by= throttling. Therefore, I propose the sentence take the form of non-normati= ve guidance. For example: > > "When a reporting node sends an OLR, it effectively delegates any necessa= ry throttling to downstream nodes. If the reporting node also locally thro= ttles the same set of messages, the overall number of throttled request may= be higher than intended. Therefore, if a reporting node needs to apply loc= al throttling on a set of messages that match or overlap with existing OCS = entries, it needs to consider the impact of throttling by downstream nodes." > >=20=20=20 >> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote: >> >> I can live with the text proposed by Ulrich. But what is wrong with: >> >> " Therefore, the reporting node SHOULD NOT apply throttling to the set o= f messages to which an active OCS applies." ? >> >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >> >> ---- Maria Cruz Bartolome a =E9crit ---- >> >> >>> Section 4.2.3, 13th paragraph, 2nd sentence: >>> Existing text: Therefore, the reporting node SHOULD NOT apply throttlin= g to the set of messages to which the OLR applies. >>> Proposed text: Therefore, the reporting node SHOULD NOT apply throttlin= g to the set of messages to which the sent OLR applies. >>> >>> [LM] I would say that the reporting node will not remember the previous= ly sent OLR, but will take care that there is an active OCS. >> SRD> I'm ok with Ulrich's change. >> >> [LM] and this is incorrect but not fundamental. The reporting node does = not have to "remember" a previously sent OLR. What it will do is to refer t= o existing OCS to know that throttling should not be applied. An OCS is a c= onsequence of an sent OLR but it is not an OLR itself. But not fundamental = here. >> >> [MCruz] I am ok with Ulrich's change. It does not mean that the reportin= g node needs to "remember" a previously sent OLR, though. The change only p= roposes to "identify" which OLR we refer to. >> >> Best regards >> /MCruz >> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> 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. >> >> 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 > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Nov 25 10: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 B6CB91A0262 for ; Tue, 25 Nov 2014 10:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Nt0R86rhdck for ; Tue, 25 Nov 2014 10:30:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9301A19EF for ; Tue, 25 Nov 2014 10:30:39 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAPIUb6E063062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 12:30:38 -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.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <15923_1416939034_5474C61A_15923_10043_1_6B7134B31289DC4FAF731D844122B36E94131D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 25 Nov 2014 12:30:37 -0600 X-Mao-Original-Outgoing-Id: 438633037.755639-fb0b6d696333541df996c5b3621afc0e Content-Transfer-Encoding: quoted-printable Message-Id: <11F770A8-3186-433D-A2A2-B0EFEAFB6768@nostrum.com> References: <54749041.6060105@usdonovans.com> <6DEDC346-525E-4BC1-B18E-CF56A9D8407F@nostrum.com> <15923_1416939034_5474C61A_15923_10043_1_6B7134B31289DC4FAF731D844122B36E94131D@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zONvsBjNawpFNKFsy5unjBJXbts Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed wording change in Section 6.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 18:30:52 -0000 > On Nov 25, 2014, at 12:10 PM, = wrote: >=20 > Hi Steve, Ben, >=20 > IMHO, including the OC-Supported-Features AVP is not related to the = type of request but to an application. > You can advertise the supported features in every application request, = even if the OLR will be in fine received only in some specific answers = (e.g. answer of the HSS in S6a) >=20 > So the proposed text could be: >=20 > OLD:=20 >=20 > The OC-Supported-Features AVP MUST be included in every Diameter = request message a DOIC supporting node sends. >=20 > NEW: >=20 > The OC-Supported-Features AVP MUST be included in every Diameter = request message a DOIC supporting node sends for an application = supporting the overload control > mechanism specified in this document. The issue is, a node might be willing to be only a reporting node, or = only a reacting node, even for the same application. That's why we need = to separate requests from answers. I would be okay with your proposed = language with a small change: "The OC-Supported-Features AVP MUST be included in every Diameter = request message a DOIC _reacting_ node sends for an application = _for_which_it_supports the overload control mechanism specified in this document." But I think to some degree we are making this hard on ourselves. It may = be better to just say that a "reacting node" sends OC-Supported-Features = in every request. Don't we already have text that indicates that a node = may be a reacting node for some applications but not others?=20 >=20 > regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Dave Dolson > Envoy=E9 : mardi 25 novembre 2014 17:42 > =C0 : Ben Campbell; Steve Donovan > Cc : dime@ietf.org > Objet : Re: [Dime] Proposed wording change in Section 6.1 >=20 > Is the idea that a host consistently either send the AVP or not send = the AVP, but be consistent for a given message type? >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Tuesday, November 25, 2014 11:25 AM > To: Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] Proposed wording change in Section 6.1 >=20 > I'm not sure I agree with the approach. Comments inline: >=20 >> On Nov 25, 2014, at 8:20 AM, Steve Donovan = wrote: >>=20 >> All, >>=20 >> The current wording for the OC-Supported-Features AVP says that it = MUST be included in all messages a DOIC supporting node sends.=20 >>=20 >> The OC-Supported- >> Features AVP MUST be included in every Diameter request message a >> DOIC supporting node sends. >>=20 >>=20 >> We need to qualify this a little as there will be cases where a = Diameter node supports DOIC but the application does not require use of = DOIC. Requests originated by an HSS in the S6a application is an = example of this as 3GPP CT4 is defining that application to only use = DOIC on requests traveling from the MME to the HSS. >>=20 >> I propose the following wording to replace the above sentence: >>=20 >> The OC-Supported-Features AVP MUST be included by a DOIC node in = every Diameter request message for applications that have defined = support for the DOIC solution on messages sent by the DOIC node. >=20 > I don't think we need to tie this to application definitions. A DOIC = node can use DOIC with an application that doesn't "define" it. And a = deployment might choose not to use DOIC for reasons other than what is = in the definition. >=20 > Also, I don't think that statement needs to be normative. We don't = need 2119 language to describe the basic flow of the protocol.=20 >=20 > Proposal (non-normative) >=20 > "A DOIC node indicates that it is willing to act as a reacting node = for an application by including the OC-Supported-Features AVP in each = request message it sends for that application." >=20 > OTOH, if people insist on making this normative: >=20 > "A DOIC node that is willing to act as a reacting node for an = application MUST include the OC-Supported-Features AVP in each request = it sends for that application" >=20 > Note: "for an application" might need to be "for a realm and = application" >=20 >=20 >>=20 >> Note: It is expected that there will be applications that define = the use of DOIC only for requests flowing from Diameter Clients to = Diameter Servers and not for requests flowing from Diameter Servers to = Diameter Clients. In this case a Diameter Server that supports the DOIC = solution will not include the OC-Supported-Features header in request = messages it sends. >>=20 >> I'll update the document accordingly unless I hear objections on the = list. >>=20 >> Regards, >>=20 >> Steve >> _______________________________________________ >> 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 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Tue Nov 25 11:04: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 8A3A21ACF03 for ; Tue, 25 Nov 2014 11:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 YKcwm2AgC8Dz for ; Tue, 25 Nov 2014 11:02:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1ED1ACEFD for ; Tue, 25 Nov 2014 11:02:45 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 8C7442AC3BB; Tue, 25 Nov 2014 20:02:43 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 717F63840A2; Tue, 25 Nov 2014 20:02: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.0210.002; Tue, 25 Nov 2014 20:02:43 +0100 From: To: Ben Campbell , "dime@ietf.org list" Thread-Topic: [Dime] Updated DOIC Requirements Analysis Thread-Index: AQHQCFYslV5S0S1BvEq9G+EcSp8zMJxxrBZg Date: Tue, 25 Nov 2014 19:02:42 +0000 Message-ID: <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> In-Reply-To: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@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.4] 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.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/D9QMkI8lzYN3jjKwjvb4P0d8pb4 Subject: Re: [Dime] Updated DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 19:02:56 -0000 Hi Ben, Steve, the text in section 1 needs also to be updated. I would propose something l= ike: 1. Introduction This specification defines a base solution for Diameter Overload Control (DOC), referred to as Diameter Overload Indication Conveyance (DOIC). The requirements for the solution are described and discussed in the corresponding design requirements document [RFC7068]. Note that the overload control solution defined in this specification does not address all the requirements listed in [RFC7068]. See Appendix C for further details on the=20 conformance to the requirements specified in [RFC7068]. In C.1: C.1. Deferred Requirements The DIME working group chose to defer certain requirements in order to meet an an external deadline. The 3GPP "Core Network and Terminal" working group 4 (CT4) working group wished to reference DOIC as part of Release 12. This required the DOIC base protocol to be substantially complete by the end of 2014. The deferred work includes the following: it is not necessary to quote CT4, as there are other groups impacts. I woul= d propose to rephrase as below: 3GPP have adopted an early version of this document as normative reference in various Diameter related specifications to support the=20 overload control mechanism in their release 12 framework. The DIME working group has therefore decided to defer certain requirements in ord= er to complete the design of an extensible generic solution before the=20 deadline scheduled by 3GPP for the completion of the protocol work in release 12 by the end of 2014. The deferred work includes the follow= ing: regards, Lionel De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mardi 25 novembre 2014 03:19 =C0=A0: dime@ietf.org list Objet=A0: [Dime] Updated DOIC Requirements Analysis Here's the text from the updated requirements analysis. I updated the summa= ry to be more general, and updated the detail based on mail discussion. The= detail section is marked for deletion before publication as an RFC.=A0 BTW, It's appendix C now because I used the section Steve had already reser= ved for it :-) Thanks! Ben. ------------------- Appendix C. Requirements Conformance Analysis This section contains the result of an analysis of the DOIC solutions conformance to the requirements defined in [RFC7068]. C.1. Deferred Requirements The DIME working group chose to defer certain requirements in order to meet an an external deadline. The 3GPP "Core Network and Terminal" working group 4 (CT4) working group wished to reference DOIC as part of Release 12. This required the DOIC base protocol to be substantially complete by the end of 2014. The deferred work includes the following: o Agent Overload - The ability for an agent to report an overload condition of the agent itself. o Load Information - The ability for a node to report its load level when not overloaded. At the time of this writing, DIME has begun separate work efforts for these requirements. C.2. Detection of non-supporting Intermediaries The DOIC mechanism as currently defined does not allow supporting nodes to automatically determine whether OC-Supported-Features or OC- OLR AVPs are originated by a peer node, or by a non-peer node and sent across a non-supporting peer. This makes it impossible to detect the presence of non-supporting nodes between supporting nodes, except by configuration. The working group determined that such a configuration requirement is acceptable. This limits full compliance with certain requirements related to the limitation of new configuration, deployment in environments with mixed support, operating across non-supporting agents, and authorization. C.3. Implicit Application Indication The working group elected to determine the application for an overload report from that of the enclosing message. This prevents sending an OLR for an application when there are no transactions for that application. As a consequence, DOIC does not comply with the requirement to be able to report overload information across quiescent connections. DOIC does not fully comply with requirements to operate on up-to-date information, since if an OLR causes all transactions to stop for an application, the only way traffic will resume is for the OLR to expire. C.4. Stateless Operation RFC7068 explicitly discourages the sending of OLRs in every answer message, as part of the requirement to avoid additional work for overloaded nodes. DOIC recommends exactly that behavior during active overload conditions. The working group determined that doing otherwise would reduce reliability and increase statefulness. (Note that DOIC does allow nodes to avoid sending OLRs in every answer if they have some other method of ensuring that OLRs get to all relevant reacting nodes.) C.5. No New Vulnerabilities The working group believes that DOIC is compliant with the requirement to avoid introducing new vulnerabilities. However, this requirement may warrant an early security expert review. C.6. Detailed Requirements [RFC Editor: Please remove this section and subsections prior to publication as an RFC.] C.6.1. General REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. *Partially Compliant*. The mechanism uses new AVPs piggybacked on existing Diameter messages to exchange overload information. It does not currently support "load" information or the ability to report overload of an agent. These have been left for future extensions. REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3. *Partially Compliant*. The DOIC AVPs can be used in any application that allows the extension of AVPs. However, "load" information is not currently supported. REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity. The overall useful throughput under load is the ultimate measure of the value of a solution. *Compliant*. DOIC provides information that nodes can use to reduce the impact of overload. REQ 4: Diameter allows requests to be sent from either side of a connection, and either side of a connection may have need to provide its overload status. The solution MUST allow each side of a connection to independently inform the other of its overload status. *Compliant*. DOIC AVPs can be included regardless of transaction "direction" REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined. *Compliant*. DOIC contains no assumptions about how peers are discovered. REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge to be configured at each node. *Partially Compliant*. Most DOIC parameters are advertised using the DOIC capability announcement mechanism. However, there are some situations where configuration is required. For example, a DOIC node detect the fact that a peer may not support DOIC when nodes on the other side of the non- supporting node do support DOIC without configuration. C.6.2. Performance REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition. *Compliant*. The specification offers guidance that implementations should apply hysteresis when recovering from overload, and avoid sudden ramp ups in offered load when recovering. REQ 8: Supporting nodes MUST be able to distinguish current overload information from stale information. *Partially Compliant*. DOIC overload reports are "soft state", that is they expire after an indicated period. DOIC nodes may also send reports that end existing overload conditions. DOIC requires reporting nodes to ensure that all relevant reacting nodes receive overload reports. However, since DOIC does not allow reporting nodes to send OLRs in watchdog messages, if an overload condition results in zero offered load, the reporting node cannot update the condition until the expiration of the original OLR. REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections. This is partially derived from the requirement for stability in REQ 7. *Not Compliant*. DOIC does not allow OLRs to be sent over quiescent transport connections. This is due to the fact that OLRs cannot be sent outside of the application to which they apply. REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends. *Partially Compliant*. (See response to previous two requirements.) REQ 11: The solution MUST be able to operate in networks of different sizes. *Compliant*. DOIC makes no assumptions about the size of the network. DOIC can operate purely between clients and servers, or across agents. REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small- scale failure from becoming a widespread outage. *Partially Compliant*. DOIC allows overload reports for an entire realm, where abated traffic will not be redirected towards another server. But in situations where nodes choose to divert traffic to other nodes, DOIC offers no way of knowing whether the new recipients can handle the traffic if they have not already indicated overload. This may be mitigated with the use of a future "load" extension, or with the use of proprietary dynamic load-balancing mechanisms. REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work. *Not Compliant*. DOIC does in fact encourage an overloaded node to send an OLR in every response. The working group that other mechanisms to ensure that every relevant node receives an OLR would create even more work. [Note: This needs discussion.] REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase. *Compliant*. The piggyback mechanism allows OLRs to be sent at the same rate as application traffic. REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms. *Compliant*. DOIC does not require or recommend changes in the handling of transport protocols or connections. C.6.3. Heterogeneous Support for Solution 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. *Partially Compliant*. DOIC works with most mixed-deployment scenarios. However, it cannot work across a non-supporting proxy that modifies Origin-Host AVPs in answer messages. DOIC will have limited impact in networks where the nodes that perform server selections do not support the mechanism. REQ 17: In a mixed environment with nodes that support the solution and nodes that do not, the solution MUST NOT result in materially less useful throughput during overload as would have resulted if the solution were not present. It SHOULD result in less severe overload in this environment. *Compliant*. In most mixed-support deployment, DOIC will offer at least some value, and will not make things worse. 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. *Compliant*. DOIC provides mechanisms to abate load from non- supporting sources. Furthermore, it recommends that reporting nodes will still need to be able to apply whatever protections they would ordinarily apply if DOIC were not in use. REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains. *Partially Compliant*. DOIC allows sending OLRs across administrative domains, and potentially to nodes in other realms. However, an OLR cannot indicate overload for realms other than the one in the Origin-Realm AVP of the containing answer. REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter. *Compliant*. DOIC sends explicit overload indication in overload reports. It does not depend on error result codes. REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of overload. The solution MUST result in at least as much useful throughput as would have resulted if the solution were not in place. *Compliant*. DOIC overload reports have the primary effect of suppressing message retries in overload conditions. DOIC recommends that messages never be silently dropped if at all possible. C.6.4. Granular Control REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node. This throttling SHOULD be graded so that it can be applied gradually as offered load increases. Overload is not a binary state; there may be degrees of overload. *Compliant*. The "loss" algorithm expresses a percentage reduction. REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. *Not Compliant*. DOIC provides no built in mechanism to determine the best place to divert messages that would otherwise be throttled. This can be accomplished with a future "load" extension, or with proprietary load balancing mechanisms. REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring. *Not Compliant*. "Load" information has been left for a future extension. C.6.5. Priority and Policy REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be desirable to send or process over others during times of overload, based on application-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition will be the responsibility of the application specification. *Compliant*. The specification offers guidance on how requests might be prioritized for different types of applications. REQ 26: The solution MUST NOT prevent a node from prioritizing requests based on any local policy, so that certain requests are given preferential treatment, given additional retransmission, not throttled, or processed ahead of others. *Compliant*. Nothing in the specification prevents application-specific, implementation-specific, or local policies. C.6.6. Security REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack or increase the severity of any existing vulnerabilities. This includes vulnerabilities to DoS and DDoS attacks as well as replay and man-in-the-middle attacks. Note that the Diameter base specification [RFC6733] lacks end-to-end security and this must be considered (see the Security Considerations in [RFC7068]). Note that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail. *Compliant*. The working group is not aware of any such vulnerabilities. [This may need further analysis.] REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes. *Partially Compliant*. Since all Diameter security is currently at the transport layer, nodes must trust immediate peers to enforce trust policies. However, there are situations where a DOIC node cannot determine if an immediate peer supports DOIC. The authors recommend an expert security review. REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node. *Partially Compliant*. (See response to previous requirement.) REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks. *Compliant*. The specification recommends that any such protection mechanism needed without DOIC should continue to be employed with DOIC. C.6.7. Flexibility and Extensibility 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. *Partially Compliant*. All DOIC overload reports are scoped to the specific application and realm. Inside that scope, overload can be reported at the specific server or whole realm scope. As currently specified, DOIC cannot indicate local overload for an agent. At the time of this writing, the DIME working group has plans to work on an agent-overload extension. DOIC allows new "scopes" through the use of extended report types. REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control. *Compliant*. DOIC allows new report types and abatement algorithms to be created. These may be indicated using the OC-Supported-Features AVP. REQ 33: The solution MUST provide a default algorithm that is mandatory to implement. *Compliant*. The "loss" algorithm is mandatory to implement. REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution. *Partially Compliant*. DOIC information can traverse non- supporting agents, as long as those agents do not modify certain AVPs. (e.g., Origin-Host). DOIC does not provide a way for supporting nodes to detect such modification. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Nov 25 13:37: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 9AE671A8941 for ; Tue, 25 Nov 2014 13:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rdpcaAN43GP8 for ; Tue, 25 Nov 2014 13:36:14 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176A81A893E for ; Tue, 25 Nov 2014 13:36:14 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49911 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XtNmN-0006gd-8Z for dime@ietf.org; Tue, 25 Nov 2014 13:36:12 -0800 Message-ID: <5474F64A.9090700@usdonovans.com> Date: Tue, 25 Nov 2014 15:36:10 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aE8R1uuHbJkRXwOPZzHvUYuXoU0 Subject: [Dime] Plan for DOIC-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 21:36:14 -0000 All, The current plan, pending review comments, is to publish DOIC-05 next week. Please have put review comments on the DIME mailing list for the version I sent out last Thursday by Monday, December 1st. If there is anything beyond editorial, please put it in a separate email for the group to sort through. Once we have worked through the review issues I will incorporate changes in the document and publish it to the IETF. The goal will be to request Dime working group last call shortly after DOIC-05 is published. Regards, Steve From nobody Tue Nov 25 14:39: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 132791A86FA for ; Tue, 25 Nov 2014 14:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDVLUFVBcJrG for ; Tue, 25 Nov 2014 14:37:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2441A7003 for ; Tue, 25 Nov 2014 14:37:28 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAPMbR6h085249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Nov 2014 16:37:27 -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.23] From: Ben Campbell Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 438647846.834007-a30ff7fdc73e47777661c23ad7e0287c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Message-Id: Date: Tue, 25 Nov 2014 16:37:26 -0600 To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OMIKsnUakM0c_-GJwKplUNGf_R4 Subject: [Dime] DOIC: Proposed Update to Security Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 22:37:31 -0000 Hi, Here's some proposed text to update the security considerations. The = main changes were to emphasize how certain decisions (OLRs only in = answers, implicit determination of Realm, application, and host) = partially mitigate certain attacks. I also added text on how a = non-supporting agent might be falsely assumed to support DOIC, and made = some general editorial changes. ------------------ 9. Security Considerations DOIC gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly effect this reduction. This exchange is potentially subject to multiple methods of attack, and has the potential to be used as a Denial-of-Service (DoS) attack vector. Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid its use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. 9.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively transitive trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct an answer. Such an answer would also need to arrive at a Diameter node via a protected transport connection. Therefore, implementations MUST validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report, and that the answer was received via an appropriate transport connection. A similar attack involves a compromised but otherwise authorized node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from a peer that applies to a realm not handled by that peer is suspect. This attack is partially mitigated by the fact that the application, as well as host and realm, for a given OLR is determined implicitly by respective AVPs in the enclosing answer. If a reporting node modifies any of those AVPs, the enclosing transaction will also be affected. 9.2. Denial of Service Attacks Diameter overload reports, especially realm-reports, can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS attacks. Furthermore, since Diameter is almost always used in support of other protocols, a DoS attack on Diameter is likely to impact those protocols as well. Therefore, Diameter nodes MUST NOT honor or forward OLRs received from peers that are not trusted to send them. An attacker might use the information in an OLR to assist in DoS attacks. For example, an attacker could use information about current overload conditions to time an attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. Operators need the ability to ensure that OLRs are not leaked to untrusted parties. 9.3. Non-Compliant Nodes In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might throttle a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. When a Diameter node sends an overload report, it cannot assume that all nodes will comply, even if they indicate support for DOIC. A non-compliant node might continue to send requests with no reduction in load. Such non-compliance could be done accidentally, or maliciously to gain an unfair advantage over compliant nodes. Requirement 28 [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are trusted, and that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service. 9.4. End-to End-Security Issues The lack of end-to-end security features makes it difficult to establish trust in overload reports that originate from non-adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. DOIC nodes MUST strip DOIC AVPs from messages received from peers that are not trusted for DOIC purposes. The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. A DOIC node cannot always automatically detect that a peer also supports DOIC. For example, a node might have a peer that is a non-supporting agent. If nodes on the other side of that agent send OC-Supported-Features AVPs, the agent is likely to forward them as unknown AVPs. Messages received across the non-supporting agent may be indistinguishable from messages received across a DOIC supporting agent, giving the false impression that the non- supporting agent actually supports DOIC. This complicates the transitive-trust nature of DOIC. Operators need to be careful to avoid situations where a non-supporting agent is mistakenly trusted to enforce DOIC related authorization policies. At the time of this writing, the DIME working group is studying requirements for adding end-to-end security features [I-D.ietf-dime-e2e-sec-req] to Diameter. These features, when they become available, might make it easier to establish trust in non- adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism encourages Diameter agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and are beyond the scope of this document. From nobody Tue Nov 25 14:49: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 6C8D71A1A64 for ; Tue, 25 Nov 2014 14:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXP48mwEH0T4 for ; Tue, 25 Nov 2014 14:47:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976831A00CD for ; Tue, 25 Nov 2014 14:47:38 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAPMlbVT086098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 16:47:38 -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.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 25 Nov 2014 16:47:36 -0600 X-Mao-Original-Outgoing-Id: 438648456.906155-4622187205ce0e9bf60da571078ea93a Content-Transfer-Encoding: quoted-printable Message-Id: <0657D19B-AD89-46AA-B125-2E8A6C9824C0@nostrum.com> References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4Onvmds63UR8MOL6E21vTJKKBqE Cc: "dime@ietf.org list" Subject: Re: [Dime] Updated DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 22:47:43 -0000 These look reasonable to me.=20 I changed the C.1 language in the repository for 05. I will leave it to = Steve to update section 1 if he agrees with that change. > On Nov 25, 2014, at 1:02 PM, = wrote: >=20 > Hi Ben, Steve, >=20 > the text in section 1 needs also to be updated. I would propose = something like: >=20 > 1. Introduction >=20 > This specification defines a base solution for Diameter Overload > Control (DOC), referred to as Diameter Overload Indication = Conveyance > (DOIC). The requirements for the solution are described and > discussed in the corresponding design requirements document > [RFC7068]. Note that the overload control solution defined in this > specification does not address all the requirements listed in > [RFC7068]. See Appendix C for further details on the=20 > conformance to the requirements specified in [RFC7068]. >=20 > In C.1: >=20 > C.1. Deferred Requirements >=20 > The DIME working group chose to defer certain requirements in order > to meet an an external deadline. The 3GPP "Core Network and > Terminal" working group 4 (CT4) working group wished to reference > DOIC as part of Release 12. This required the DOIC base protocol to > be substantially complete by the end of 2014. The deferred work > includes the following: >=20 > it is not necessary to quote CT4, as there are other groups impacts. I = would propose to rephrase as below: >=20 > 3GPP have adopted an early version of this document as normative > reference in various Diameter related specifications to support the=20= > overload control mechanism in their release 12 framework. The DIME > working group has therefore decided to defer certain requirements in = order > to complete the design of an extensible generic solution before the=20= > deadline scheduled by 3GPP for the completion of the protocol work > in release 12 by the end of 2014. The deferred work includes the = following: >=20 > regards, >=20 > Lionel [...]= From nobody Tue Nov 25 15:01: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 0F1F71A1EF5 for ; Tue, 25 Nov 2014 14:59:25 -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 d1OgWZFDs3U9 for ; Tue, 25 Nov 2014 14:59:20 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848971A1BC2 for ; Tue, 25 Nov 2014 14:59:19 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so1472304lbi.10 for ; Tue, 25 Nov 2014 14:59:17 -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=Z+afkVeCrunxv8XrMIcsEVkESwakTfEFj9llu0lI1Zc=; b=rl1xOgG1cRNmB9ley5nAVcLWk+EMlxoeogFGgX2NgVz73tqzlo/yHGPuf0skYNCnB3 7I/MI3tAxHs9czQ31aD/2W871SOydr5lXF3oxHq5BBojKeD7gNvNDEOaCs2Z3ozPTH5u ief62ac2egEPF52NowxbupuQpr5bdtIUbtNJL0VNMdObD5GManv4lGNV6Q4ohlX1cKDt GWK694fi/F1r10uVU58oABbeqSs7iV0d1Z6vFeF+Kg3r18XMuZ9hgR2VFCLIOlobVFK1 KP3/Zy/b0ZCGmGCVTS20qMG5IzO9VKMo8/EJT1gdqDHRyGCWMhbSe2x/5lHdM8DghA09 akog== X-Received: by 10.112.169.6 with SMTP id aa6mr31401717lbc.29.1416956357871; Tue, 25 Nov 2014 14:59:17 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id jj7sm714446lbc.5.2014.11.25.14.59.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 14:59:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Jouni In-Reply-To: <0657D19B-AD89-46AA-B125-2E8A6C9824C0@nostrum.com> Date: Wed, 26 Nov 2014 00:59:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54750FE8-346E-488A-AB33-183888E77540@gmail.com> References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0657D19B-AD89-46AA-B125-2E8A6C9824C0@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RhJPm6hPiUub10f_yF6DeHb-oBk Cc: "dime@ietf.org list" Subject: Re: [Dime] Updated DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 22:59:25 -0000 Looks OK to me as well. - Jouni > On 26 Nov 2014, at 00:47, Ben Campbell wrote: >=20 > These look reasonable to me.=20 >=20 > I changed the C.1 language in the repository for 05. I will leave it = to Steve to update section 1 if he agrees with that change. >=20 >> On Nov 25, 2014, at 1:02 PM, = wrote: >>=20 >> Hi Ben, Steve, >>=20 >> the text in section 1 needs also to be updated. I would propose = something like: >>=20 >> 1. Introduction >>=20 >> This specification defines a base solution for Diameter Overload >> Control (DOC), referred to as Diameter Overload Indication = Conveyance >> (DOIC). The requirements for the solution are described and >> discussed in the corresponding design requirements document >> [RFC7068]. Note that the overload control solution defined in this >> specification does not address all the requirements listed in >> [RFC7068]. See Appendix C for further details on the=20 >> conformance to the requirements specified in [RFC7068]. >>=20 >> In C.1: >>=20 >> C.1. Deferred Requirements >>=20 >> The DIME working group chose to defer certain requirements in order >> to meet an an external deadline. The 3GPP "Core Network and >> Terminal" working group 4 (CT4) working group wished to reference >> DOIC as part of Release 12. This required the DOIC base protocol to >> be substantially complete by the end of 2014. The deferred work >> includes the following: >>=20 >> it is not necessary to quote CT4, as there are other groups impacts. = I would propose to rephrase as below: >>=20 >> 3GPP have adopted an early version of this document as normative >> reference in various Diameter related specifications to support the=20= >> overload control mechanism in their release 12 framework. The DIME >> working group has therefore decided to defer certain requirements in = order >> to complete the design of an extensible generic solution before the=20= >> deadline scheduled by 3GPP for the completion of the protocol work >> in release 12 by the end of 2014. The deferred work includes the = following: >>=20 >> regards, >>=20 >> Lionel >=20 > [...] > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Nov 25 15:13: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 69E961A87AA for ; Tue, 25 Nov 2014 15:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 EE1cHk_Vqpug for ; Tue, 25 Nov 2014 15:13:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DAB1A899B for ; Tue, 25 Nov 2014 15:12:28 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 81FB022C3F1; Wed, 26 Nov 2014 00:12:26 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 67B242380E0; Wed, 26 Nov 2014 00:12: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.0210.002; Wed, 26 Nov 2014 00:12:26 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Plan for DOIC-05 Thread-Index: AQHQCPgW0pzslb+VOUKDvZ4El40xoZxx+BRQ Date: Tue, 25 Nov 2014 23:12:25 +0000 Message-ID: <16071_1416957146_54750CDA_16071_9887_1_6B7134B31289DC4FAF731D844122B36E9430FE@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5474F64A.9090700@usdonovans.com> In-Reply-To: <5474F64A.9090700@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.4] 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.11.25.200619 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/U99biT-wQOC4XChxQJtYRWQXWEA Subject: Re: [Dime] Plan for DOIC-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 23:13:19 -0000 an additional recommendation: please use a specific email subject to sort o= ut the different discussions.=20 Avoid "review of the draft" and prefer "specific comment on section 3.2" or= any other appropriate subject. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: mardi 25 novembre 2014 22:36 =C0=A0: dime@ietf.org Objet=A0: [Dime] Plan for DOIC-05 All, The current plan, pending review comments, is to publish DOIC-05 next week. Please have put review comments on the DIME mailing list for the version I = sent out last Thursday by Monday, December 1st. If there is anything beyon= d editorial, please put it in a separate email for the group to sort throug= h. Once we have worked through the review issues I will incorporate changes in= the document and publish it to the IETF. The goal will be to request Dime= working group last call shortly after DOIC-05 is published. Regards, Steve _______________________________________________ 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 Tue Nov 25 15:17: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 22C7C1A1EF7 for ; Tue, 25 Nov 2014 15:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 M8C3P5lqGDwX for ; Tue, 25 Nov 2014 15:17:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AEF1A0171 for ; Tue, 25 Nov 2014 15:17:33 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BCD1522C42D; Wed, 26 Nov 2014 00:17:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9C00C2380B9; Wed, 26 Nov 2014 00:17:31 +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.0210.002; Wed, 26 Nov 2014 00:17:31 +0100 From: To: Ben Campbell Thread-Topic: [Dime] Proposed wording change in Section 6.1 Thread-Index: AQHQCLsXR/xgKVAA70uIPsRAkGKWgZxx2wqA//+wwaCAABVrIP//+GCAgABgZ6A= Date: Tue, 25 Nov 2014 23:17:30 +0000 Message-ID: <16071_1416957451_54750E0B_16071_9977_1_6B7134B31289DC4FAF731D844122B36E9431AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <54749041.6060105@usdonovans.com> <6DEDC346-525E-4BC1-B18E-CF56A9D8407F@nostrum.com> <15923_1416939034_5474C61A_15923_10043_1_6B7134B31289DC4FAF731D844122B36E94131D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11F770A8-3186-433D-A2A2-B0EFEAFB6768@nostrum.com> In-Reply-To: <11F770A8-3186-433D-A2A2-B0EFEAFB6768@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.4] 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.11.25.200619 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ekqVgodLaLZD7ZrTrtap6h3AHs4 Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed wording change in Section 6.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 23:17:42 -0000 I understand your point and I'm OK with: "The OC-Supported-Features AVP MUST be included by reacting nodes in every = Diameter request message." Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mardi 25 novembre 2014 19:31 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Dave Dolson; Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] Proposed wording change in Section 6.1 > On Nov 25, 2014, at 12:10 PM, wrote: >=20 > Hi Steve, Ben, >=20 > IMHO, including the OC-Supported-Features AVP is not related to the type = of request but to an application. > You can advertise the supported features in every application request,=20 > even if the OLR will be in fine received only in some specific answers=20 > (e.g. answer of the HSS in S6a) >=20 > So the proposed text could be: >=20 > OLD:=20 >=20 > The OC-Supported-Features AVP MUST be included in every Diameter reques= t message a DOIC supporting node sends. >=20 > NEW: >=20 > The OC-Supported-Features AVP MUST be included in every Diameter reques= t message a DOIC supporting node sends for an application supporting the ov= erload control > mechanism specified in this document. The issue is, a node might be willing to be only a reporting node, or only = a reacting node, even for the same application. That's why we need to separ= ate requests from answers. I would be okay with your proposed language with= a small change: "The OC-Supported-Features AVP MUST be included in every Diameter request m= essage a DOIC _reacting_ node sends for an application _for_which_it_suppor= ts the overload control mechanism specified in this document." But I think to some degree we are making this hard on ourselves. It may be = better to just say that a "reacting node" sends OC-Supported-Features in ev= ery request. Don't we already have text that indicates that a node may be a= reacting node for some applications but not others?=20 >=20 > regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Dave Dolson=20 > Envoy=E9 : mardi 25 novembre 2014 17:42 =C0 : Ben Campbell; Steve Donovan= =20 > Cc : dime@ietf.org Objet : Re: [Dime] Proposed wording change in=20 > Section 6.1 >=20 > Is the idea that a host consistently either send the AVP or not send the = AVP, but be consistent for a given message type? >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Tuesday, November 25, 2014 11:25 AM > To: Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] Proposed wording change in Section 6.1 >=20 > I'm not sure I agree with the approach. Comments inline: >=20 >> On Nov 25, 2014, at 8:20 AM, Steve Donovan wr= ote: >>=20 >> All, >>=20 >> The current wording for the OC-Supported-Features AVP says that it MUST = be included in all messages a DOIC supporting node sends.=20 >>=20 >> The OC-Supported- >> Features AVP MUST be included in every Diameter request message a >> DOIC supporting node sends. >>=20 >>=20 >> We need to qualify this a little as there will be cases where a Diameter= node supports DOIC but the application does not require use of DOIC. Requ= ests originated by an HSS in the S6a application is an example of this as 3= GPP CT4 is defining that application to only use DOIC on requests traveling= from the MME to the HSS. >>=20 >> I propose the following wording to replace the above sentence: >>=20 >> The OC-Supported-Features AVP MUST be included by a DOIC node in every D= iameter request message for applications that have defined support for the = DOIC solution on messages sent by the DOIC node. >=20 > I don't think we need to tie this to application definitions. A DOIC node= can use DOIC with an application that doesn't "define" it. And a deploymen= t might choose not to use DOIC for reasons other than what is in the defini= tion. >=20 > Also, I don't think that statement needs to be normative. We don't need 2= 119 language to describe the basic flow of the protocol.=20 >=20 > Proposal (non-normative) >=20 > "A DOIC node indicates that it is willing to act as a reacting node for a= n application by including the OC-Supported-Features AVP in each request me= ssage it sends for that application." >=20 > OTOH, if people insist on making this normative: >=20 > "A DOIC node that is willing to act as a reacting node for an application= MUST include the OC-Supported-Features AVP in each request it sends for th= at application" >=20 > Note: "for an application" might need to be "for a realm and application" >=20 >=20 >>=20 >> Note: It is expected that there will be applications that define th= e use of DOIC only for requests flowing from Diameter Clients to Diameter S= ervers and not for requests flowing from Diameter Servers to Diameter Clien= ts. In this case a Diameter Server that supports the DOIC solution will no= t include the OC-Supported-Features header in request messages it sends. >>=20 >> I'll update the document accordingly unless I hear objections on the lis= t. >>=20 >> Regards, >>=20 >> Steve >> _______________________________________________ >> 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 > ______________________________________________________________________ > ___________________________________________________ >=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 ___________________________________________________________________________= ______________________________________________ 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 Nov 28 05:39: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 5D4E21A1B5F for ; Fri, 28 Nov 2014 05:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HKeScFxUkXbK for ; Fri, 28 Nov 2014 05:39:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40651A1B65 for ; Fri, 28 Nov 2014 05:39:10 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id E07EE3B4393; Fri, 28 Nov 2014 14:39:08 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id C48661800AD; Fri, 28 Nov 2014 14:39:08 +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.0210.002; Fri, 28 Nov 2014 14:39:08 +0100 From: To: Ben Campbell , "dime@ietf.org list" Thread-Topic: [Dime] DOIC: Proposed Update to Security Considerations Thread-Index: AQHQCQC4S1i5VUtIwUinOKOOt1Zwapx2DkXQ Date: Fri, 28 Nov 2014 13:39:07 +0000 Message-ID: <17325_1417181948_54787AFC_17325_576_1_6B7134B31289DC4FAF731D844122B36E959F24@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] 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.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4HqBAcmb6HECE47T6tofaLSnmqs Subject: Re: [Dime] DOIC: Proposed Update to Security Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 13:39:14 -0000 Ok with the content. Just one proposed correction in section 9.4: 9.4. End-to End-Security Issues The lack of end-to-end security features makes it difficult to establish trust in overload reports that originate from non-adjacent nodes. Any agents in the message path may insert or modify overload I assume that what you want to highlight is the lack of E2E integrity, righ= t? what about: The lack of end-to-end *integrity* features makes it difficult to establish trust in overload reports *received* from non-adjacent nodes. Any agents in the message path may insert or modify overload regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mardi 25 novembre 2014 23:37 =C0=A0: dime@ietf.org list Objet=A0: [Dime] DOIC: Proposed Update to Security Considerations Hi, Here's some proposed text to update the security considerations. The main c= hanges were to emphasize how certain decisions (OLRs only in answers, impli= cit determination of Realm, application, and host) partially mitigate certa= in attacks. I also added text on how a non-supporting agent might be falsel= y assumed to support DOIC, and made some general editorial changes. ------------------ 9. Security Considerations DOIC gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly effect this reduction. This exchange is potentially subject to multiple methods of attack, and has the potential to be used as a Denial-of-Service (DoS) attack vector. Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid its use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. 9.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively transitive trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct an answer. Such an answer would also need to arrive at a Diameter node via a protected transport connection. Therefore, implementations MUST validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report, and that the answer was received via an appropriate transport connection. A similar attack involves a compromised but otherwise authorized node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from a peer that applies to a realm not handled by that peer is suspect. This attack is partially mitigated by the fact that the application, as well as host and realm, for a given OLR is determined implicitly by respective AVPs in the enclosing answer. If a reporting node modifies any of those AVPs, the enclosing transaction will also be affected. 9.2. Denial of Service Attacks Diameter overload reports, especially realm-reports, can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS attacks. Furthermore, since Diameter is almost always used in support of other protocols, a DoS attack on Diameter is likely to impact those protocols as well. Therefore, Diameter nodes MUST NOT honor or forward OLRs received from peers that are not trusted to send them. An attacker might use the information in an OLR to assist in DoS attacks. For example, an attacker could use information about current overload conditions to time an attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. Operators need the ability to ensure that OLRs are not leaked to untrusted parties. 9.3. Non-Compliant Nodes In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might throttle a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. When a Diameter node sends an overload report, it cannot assume that all nodes will comply, even if they indicate support for DOIC. A non-compliant node might continue to send requests with no reduction in load. Such non-compliance could be done accidentally, or maliciously to gain an unfair advantage over compliant nodes. Requirement 28 [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are trusted, and that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service. 9.4. End-to End-Security Issues The lack of end-to-end security features makes it difficult to establish trust in overload reports that originate from non-adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. DOIC nodes MUST strip DOIC AVPs from messages received from peers that are not trusted for DOIC purposes. The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. A DOIC node cannot always automatically detect that a peer also supports DOIC. For example, a node might have a peer that is a non-supporting agent. If nodes on the other side of that agent send OC-Supported-Features AVPs, the agent is likely to forward them as unknown AVPs. Messages received across the non-supporting agent may be indistinguishable from messages received across a DOIC supporting agent, giving the false impression that the non- supporting agent actually supports DOIC. This complicates the transitive-trust nature of DOIC. Operators need to be careful to avoid situations where a non-supporting agent is mistakenly trusted to enforce DOIC related authorization policies. At the time of this writing, the DIME working group is studying requirements for adding end-to-end security features [I-D.ietf-dime-e2e-sec-req] to Diameter. These features, when they become available, might make it easier to establish trust in non- adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism encourages Diameter agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and are beyond the scope of this document. _______________________________________________ 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 Nov 28 07: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 7AB5A1A0052 for ; Fri, 28 Nov 2014 07:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFc3eHZa0egJ for ; Fri, 28 Nov 2014 07:43:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F7B1A002F for ; Fri, 28 Nov 2014 07:43:41 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sASFhdeU070158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2014 09:43:40 -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.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <17325_1417181948_54787AFC_17325_576_1_6B7134B31289DC4FAF731D844122B36E959F24@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 28 Nov 2014 09:43:39 -0600 X-Mao-Original-Outgoing-Id: 438882219.098424-ae86df00bb4bf77f411d5a7cbdde4a9e Content-Transfer-Encoding: quoted-printable Message-Id: References: <17325_1417181948_54787AFC_17325_576_1_6B7134B31289DC4FAF731D844122B36E959F24@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tac_hplOJ2tDuxSKKHHjIulvrAA Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC: Proposed Update to Security Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 15:43:44 -0000 I agree it should be more precise, but I think confidentially also might = matter, since we have requirements to be able to authorize who can see = overload information. I propose changing "security features" to = "integrity and confidentiality protection", and "may insert or modify" = to "may insert, read, or modify" > On Nov 28, 2014, at 7:39 AM, = wrote: >=20 > Ok with the content. > Just one proposed correction in section 9.4: >=20 > 9.4. End-to End-Security Issues >=20 > The lack of end-to-end security features makes it difficult to > establish trust in overload reports that originate from non-adjacent > nodes. Any agents in the message path may insert or modify overload >=20 > I assume that what you want to highlight is the lack of E2E integrity, = right? > what about: >=20 > The lack of end-to-end *integrity* features makes it difficult to > establish trust in overload reports *received* from non-adjacent > nodes. Any agents in the message path may insert or modify overload >=20 > regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoy=E9 : mardi 25 novembre 2014 23:37 > =C0 : dime@ietf.org list > Objet : [Dime] DOIC: Proposed Update to Security Considerations >=20 > Hi, >=20 > Here's some proposed text to update the security considerations. The = main changes were to emphasize how certain decisions (OLRs only in = answers, implicit determination of Realm, application, and host) = partially mitigate certain attacks. I also added text on how a = non-supporting agent might be falsely assumed to support DOIC, and made = some general editorial changes. >=20 > ------------------ >=20 > 9. Security Considerations >=20 > DOIC gives Diameter nodes the ability to request that downstream > nodes send fewer Diameter requests. Nodes do this by exchanging > overload reports that directly effect this reduction. This exchange > is potentially subject to multiple methods of attack, and has the > potential to be used as a Denial-of-Service (DoS) attack vector. >=20 > Overload reports may contain information about the topology and > current status of a Diameter network. This information is > potentially sensitive. Network operators may wish to control > disclosure of overload reports to unauthorized parties to avoid its > use for competitive intelligence or to target attacks. >=20 > Diameter does not include features to provide end-to-end > authentication, integrity protection, or confidentiality. This may > cause complications when sending overload reports between non- > adjacent nodes. >=20 > 9.1. Potential Threat Modes >=20 > The Diameter protocol involves transactions in the form of requests > and answers exchanged between clients and servers. These clients = and > servers may be peers, that is, they may share a direct transport > (e.g. TCP or SCTP) connection, or the messages may traverse one or > more intermediaries, known as Diameter Agents. Diameter nodes use > TLS, DTLS, or IPSec to authenticate peers, and to provide > confidentiality and integrity protection of traffic between peers. > Nodes can make authorization decisions based on the peer identities > authenticated at the transport layer. >=20 > When agents are involved, this presents an effectively transitive > trust model. That is, a Diameter client or server can authorize an > agent for certain actions, but it must trust that agent to make > appropriate authorization decisions about its peers, and so on. > Since confidentiality and integrity protection occurs at the > transport layer, agents can read, and perhaps modify, any part of a > Diameter message, including an overload report. >=20 > There are several ways an attacker might attempt to exploit the > overload control mechanism. An unauthorized third party might = inject > an overload report into the network. If this third party is = upstream > of an agent, and that agent fails to apply proper authorization > policies, downstream nodes may mistakenly trust the report. This > attack is at least partially mitigated by the assumption that nodes > include overload reports in Diameter answers but not in requests. > This requires an attacker to have knowledge of the original request > in order to construct an answer. Such an answer would also need to > arrive at a Diameter node via a protected transport connection. > Therefore, implementations MUST validate that an answer containing = an > overload report is a properly constructed response to a pending > request prior to acting on the overload report, and that the answer > was received via an appropriate transport connection. >=20 > A similar attack involves a compromised but otherwise authorized = node > that sends an inappropriate overload report. For example, a server > for the realm "example.com" might send an overload report indicating > that a competitor's realm "example.net" is overloaded. If other > nodes act on the report, they may falsely believe that "example.net" > is overloaded, effectively reducing that realm's capacity. > Therefore, it's critical that nodes validate that an overload report > received from a peer actually falls within that peer's = responsibility > before acting on the report or forwarding the report to other peers. > For example, an overload report from a peer that applies to a realm > not handled by that peer is suspect. >=20 > This attack is partially mitigated by the fact that the > application, as well as host and realm, for a given OLR is > determined implicitly by respective AVPs in the enclosing answer. > If a reporting node modifies any of those AVPs, the enclosing > transaction will also be affected. >=20 > 9.2. Denial of Service Attacks >=20 > Diameter overload reports, especially realm-reports, can cause a = node > to cease sending some or all Diameter requests for an extended > period. This makes them a tempting vector for DoS attacks. > Furthermore, since Diameter is almost always used in support of = other > protocols, a DoS attack on Diameter is likely to impact those > protocols as well. Therefore, Diameter nodes MUST NOT honor or > forward OLRs received from peers that are not trusted to send them. >=20 > An attacker might use the information in an OLR to assist in DoS > attacks. For example, an attacker could use information about > current overload conditions to time an attack for maximum effect, or > use subsequent overload reports as a feedback mechanism to learn the > results of a previous or ongoing attack. Operators need the ability > to ensure that OLRs are not leaked to untrusted parties. >=20 > 9.3. Non-Compliant Nodes >=20 > In the absence of an overload control mechanism, Diameter nodes need > to implement strategies to protect themselves from floods of > requests, and to make sure that a disproportionate load from one > source does not prevent other sources from receiving service. For > example, a Diameter server might throttle a certain percentage of > requests from sources that exceed certain limits. Overload control > can be thought of as an optimization for such strategies, where > downstream nodes never send the excess requests in the first place. > However, the presence of an overload control mechanism does not > remove the need for these other protection strategies. >=20 > When a Diameter node sends an overload report, it cannot assume that > all nodes will comply, even if they indicate support for DOIC. A > non-compliant node might continue to send requests with no reduction > in load. Such non-compliance could be done accidentally, or > maliciously to gain an unfair advantage over compliant nodes. > Requirement 28 [RFC7068] indicates that the overload control = solution > cannot assume that all Diameter nodes in a network are trusted, and > that malicious nodes not be allowed to take advantage of the = overload > control mechanism to get more than their fair share of service. >=20 > 9.4. End-to End-Security Issues >=20 > The lack of end-to-end security features makes it difficult to > establish trust in overload reports that originate from non-adjacent > nodes. Any agents in the message path may insert or modify overload > reports. Nodes must trust that their adjacent peers perform proper > checks on overload reports from their peers, and so on, creating a > transitive-trust requirement extending for potentially long chains = of > nodes. Network operators must determine if this transitive trust > requirement is acceptable for their deployments. Nodes supporting > Diameter overload control MUST give operators the ability to select > which peers are trusted to deliver overload reports, and whether = they > are trusted to forward overload reports from non-adjacent nodes. > DOIC nodes MUST strip DOIC AVPs from messages received from peers > that are not trusted for DOIC purposes. >=20 > The lack of end-to-end confidentiality protection means that any > Diameter agent in the path of an overload report can view the > contents of that report. In addition to the requirement to select > which peers are trusted to send overload reports, operators MUST be > able to select which peers are authorized to receive reports. A = node > MUST not send an overload report to a peer not authorized to receive > it. Furthermore, an agent MUST remove any overload reports that > might have been inserted by other nodes before forwarding a Diameter > message to a peer that is not authorized to receive overload = reports. >=20 > A DOIC node cannot always automatically detect that a peer also > supports DOIC. For example, a node might have a peer that is a > non-supporting agent. If nodes on the other side of that agent > send OC-Supported-Features AVPs, the agent is likely to forward > them as unknown AVPs. Messages received across the = non-supporting > agent may be indistinguishable from messages received across a > DOIC supporting agent, giving the false impression that the non- > supporting agent actually supports DOIC. This complicates the > transitive-trust nature of DOIC. Operators need to be careful to > avoid situations where a non-supporting agent is mistakenly > trusted to enforce DOIC related authorization policies. >=20 > At the time of this writing, the DIME working group is studying > requirements for adding end-to-end security features > [I-D.ietf-dime-e2e-sec-req] to Diameter. These features, when they > become available, might make it easier to establish trust in non- > adjacent nodes for overload control purposes. Readers should be > reminded, however, that the overload control mechanism encourages > Diameter agents to modify AVPs in, or insert additional AVPs into, > existing messages that are originated by other nodes. If end-to-end > security is enabled, there is a risk that such modification could > violate integrity protection. The details of using any future > Diameter end-to-end security mechanism with overload control will > require careful consideration, and are beyond the scope of this > document. >=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 nobody Fri Nov 28 08: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 2150D1A019B for ; Fri, 28 Nov 2014 08:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Jf_aUPSYV2hI for ; Fri, 28 Nov 2014 08:31:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2D11A017C for ; Fri, 28 Nov 2014 08:31:38 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id F41CE3B43F4; Fri, 28 Nov 2014 17:31:36 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id D936A384078; Fri, 28 Nov 2014 17:31:36 +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.0210.002; Fri, 28 Nov 2014 17:31:36 +0100 From: To: Ben Campbell Thread-Topic: [Dime] DOIC: Proposed Update to Security Considerations Thread-Index: AQHQCQC4S1i5VUtIwUinOKOOt1Zwapx2DkXQgAATHoCAAB3AsA== Date: Fri, 28 Nov 2014 16:31:35 +0000 Message-ID: <25871_1417192296_5478A368_25871_5993_1_6B7134B31289DC4FAF731D844122B36E95AC4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <17325_1417181948_54787AFC_17325_576_1_6B7134B31289DC4FAF731D844122B36E959F24@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.2] 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.11.28.142724 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QaflJZ6J5q6u6iF3IU_LgEsWRUc Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC: Proposed Update to Security Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:31:43 -0000 My point was that integrity covers the case "insert/modify/remove". The confidentiality aspects are covered in the next paragraph. And so my proposal.=20 Regards, lionel=20 -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: vendredi 28 novembre 2014 16:44 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: Proposed Update to Security Considerations I agree it should be more precise, but I think confidentially also might ma= tter, since we have requirements to be able to authorize who can see overlo= ad information. I propose changing "security features" to "integrity and co= nfidentiality protection", and "may insert or modify" to "may insert, read,= or modify" > On Nov 28, 2014, at 7:39 AM, wrote: >=20 > Ok with the content. > Just one proposed correction in section 9.4: >=20 > 9.4. End-to End-Security Issues >=20 > The lack of end-to-end security features makes it difficult to > establish trust in overload reports that originate from non-adjacent > nodes. Any agents in the message path may insert or modify overload >=20 > I assume that what you want to highlight is the lack of E2E integrity, ri= ght? > what about: >=20 > The lack of end-to-end *integrity* features makes it difficult to > establish trust in overload reports *received* from non-adjacent > nodes. Any agents in the message path may insert or modify overload >=20 > regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20 > Envoy=E9 : mardi 25 novembre 2014 23:37 =C0 : dime@ietf.org list Objet := =20 > [Dime] DOIC: Proposed Update to Security Considerations >=20 > Hi, >=20 > Here's some proposed text to update the security considerations. The main= changes were to emphasize how certain decisions (OLRs only in answers, imp= licit determination of Realm, application, and host) partially mitigate cer= tain attacks. I also added text on how a non-supporting agent might be fals= ely assumed to support DOIC, and made some general editorial changes. >=20 > ------------------ >=20 > 9. Security Considerations >=20 > DOIC gives Diameter nodes the ability to request that downstream > nodes send fewer Diameter requests. Nodes do this by exchanging > overload reports that directly effect this reduction. This exchange > is potentially subject to multiple methods of attack, and has the > potential to be used as a Denial-of-Service (DoS) attack vector. >=20 > Overload reports may contain information about the topology and > current status of a Diameter network. This information is > potentially sensitive. Network operators may wish to control > disclosure of overload reports to unauthorized parties to avoid its > use for competitive intelligence or to target attacks. >=20 > Diameter does not include features to provide end-to-end > authentication, integrity protection, or confidentiality. This may > cause complications when sending overload reports between non- > adjacent nodes. >=20 > 9.1. Potential Threat Modes >=20 > The Diameter protocol involves transactions in the form of requests > and answers exchanged between clients and servers. These clients and > servers may be peers, that is, they may share a direct transport > (e.g. TCP or SCTP) connection, or the messages may traverse one or > more intermediaries, known as Diameter Agents. Diameter nodes use > TLS, DTLS, or IPSec to authenticate peers, and to provide > confidentiality and integrity protection of traffic between peers. > Nodes can make authorization decisions based on the peer identities > authenticated at the transport layer. >=20 > When agents are involved, this presents an effectively transitive > trust model. That is, a Diameter client or server can authorize an > agent for certain actions, but it must trust that agent to make > appropriate authorization decisions about its peers, and so on. > Since confidentiality and integrity protection occurs at the > transport layer, agents can read, and perhaps modify, any part of a > Diameter message, including an overload report. >=20 > There are several ways an attacker might attempt to exploit the > overload control mechanism. An unauthorized third party might inject > an overload report into the network. If this third party is upstream > of an agent, and that agent fails to apply proper authorization > policies, downstream nodes may mistakenly trust the report. This > attack is at least partially mitigated by the assumption that nodes > include overload reports in Diameter answers but not in requests. > This requires an attacker to have knowledge of the original request > in order to construct an answer. Such an answer would also need to > arrive at a Diameter node via a protected transport connection. > Therefore, implementations MUST validate that an answer containing an > overload report is a properly constructed response to a pending > request prior to acting on the overload report, and that the answer > was received via an appropriate transport connection. >=20 > A similar attack involves a compromised but otherwise authorized node > that sends an inappropriate overload report. For example, a server > for the realm "example.com" might send an overload report indicating > that a competitor's realm "example.net" is overloaded. If other > nodes act on the report, they may falsely believe that "example.net" > is overloaded, effectively reducing that realm's capacity. > Therefore, it's critical that nodes validate that an overload report > received from a peer actually falls within that peer's responsibility > before acting on the report or forwarding the report to other peers. > For example, an overload report from a peer that applies to a realm > not handled by that peer is suspect. >=20 > This attack is partially mitigated by the fact that the > application, as well as host and realm, for a given OLR is > determined implicitly by respective AVPs in the enclosing answer. > If a reporting node modifies any of those AVPs, the enclosing > transaction will also be affected. >=20 > 9.2. Denial of Service Attacks >=20 > Diameter overload reports, especially realm-reports, can cause a node > to cease sending some or all Diameter requests for an extended > period. This makes them a tempting vector for DoS attacks. > Furthermore, since Diameter is almost always used in support of other > protocols, a DoS attack on Diameter is likely to impact those > protocols as well. Therefore, Diameter nodes MUST NOT honor or > forward OLRs received from peers that are not trusted to send them. >=20 > An attacker might use the information in an OLR to assist in DoS > attacks. For example, an attacker could use information about > current overload conditions to time an attack for maximum effect, or > use subsequent overload reports as a feedback mechanism to learn the > results of a previous or ongoing attack. Operators need the ability > to ensure that OLRs are not leaked to untrusted parties. >=20 > 9.3. Non-Compliant Nodes >=20 > In the absence of an overload control mechanism, Diameter nodes need > to implement strategies to protect themselves from floods of > requests, and to make sure that a disproportionate load from one > source does not prevent other sources from receiving service. For > example, a Diameter server might throttle a certain percentage of > requests from sources that exceed certain limits. Overload control > can be thought of as an optimization for such strategies, where > downstream nodes never send the excess requests in the first place. > However, the presence of an overload control mechanism does not > remove the need for these other protection strategies. >=20 > When a Diameter node sends an overload report, it cannot assume that > all nodes will comply, even if they indicate support for DOIC. A > non-compliant node might continue to send requests with no reduction > in load. Such non-compliance could be done accidentally, or > maliciously to gain an unfair advantage over compliant nodes. > Requirement 28 [RFC7068] indicates that the overload control solution > cannot assume that all Diameter nodes in a network are trusted, and > that malicious nodes not be allowed to take advantage of the overload > control mechanism to get more than their fair share of service. >=20 > 9.4. End-to End-Security Issues >=20 > The lack of end-to-end security features makes it difficult to > establish trust in overload reports that originate from non-adjacent > nodes. Any agents in the message path may insert or modify overload > reports. Nodes must trust that their adjacent peers perform proper > checks on overload reports from their peers, and so on, creating a > transitive-trust requirement extending for potentially long chains of > nodes. Network operators must determine if this transitive trust > requirement is acceptable for their deployments. Nodes supporting > Diameter overload control MUST give operators the ability to select > which peers are trusted to deliver overload reports, and whether they > are trusted to forward overload reports from non-adjacent nodes. > DOIC nodes MUST strip DOIC AVPs from messages received from peers > that are not trusted for DOIC purposes. >=20 > The lack of end-to-end confidentiality protection means that any > Diameter agent in the path of an overload report can view the > contents of that report. In addition to the requirement to select > which peers are trusted to send overload reports, operators MUST be > able to select which peers are authorized to receive reports. A node > MUST not send an overload report to a peer not authorized to receive > it. Furthermore, an agent MUST remove any overload reports that > might have been inserted by other nodes before forwarding a Diameter > message to a peer that is not authorized to receive overload reports. >=20 > A DOIC node cannot always automatically detect that a peer also > supports DOIC. For example, a node might have a peer that is a > non-supporting agent. If nodes on the other side of that agent > send OC-Supported-Features AVPs, the agent is likely to forward > them as unknown AVPs. Messages received across the non-supporting > agent may be indistinguishable from messages received across a > DOIC supporting agent, giving the false impression that the non- > supporting agent actually supports DOIC. This complicates the > transitive-trust nature of DOIC. Operators need to be careful to > avoid situations where a non-supporting agent is mistakenly > trusted to enforce DOIC related authorization policies. >=20 > At the time of this writing, the DIME working group is studying > requirements for adding end-to-end security features > [I-D.ietf-dime-e2e-sec-req] to Diameter. These features, when they > become available, might make it easier to establish trust in non- > adjacent nodes for overload control purposes. Readers should be > reminded, however, that the overload control mechanism encourages > Diameter agents to modify AVPs in, or insert additional AVPs into, > existing messages that are originated by other nodes. If end-to-end > security is enabled, there is a risk that such modification could > violate integrity protection. The details of using any future > Diameter end-to-end security mechanism with overload control will > require careful consideration, and are beyond the scope of this > document. >=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 ___________________________________________________________________________= ______________________________________________ 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 Nov 28 08:50: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 9C7B71A00A2 for ; Fri, 28 Nov 2014 08:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOtAfT66yyjK for ; Fri, 28 Nov 2014 08:50:21 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5A21A01F0 for ; Fri, 28 Nov 2014 08:50:15 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sASGoEnB025217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2014 10:50:15 -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.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <25871_1417192296_5478A368_25871_5993_1_6B7134B31289DC4FAF731D844122B36E95AC4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 28 Nov 2014 10:50:13 -0600 X-Mao-Original-Outgoing-Id: 438886213.649581-2ef02450bd87df86884080de57bb7519 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17325_1417181948_54787AFC_17325_576_1_6B7134B31289DC4FAF731D844122B36E959F24@PEXCVZYM13.corporate.adroot.infra.ftgroup> <25871_1417192296_5478A368_25871_5993_1_6B7134B31289DC4FAF731D844122B36E95AC4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/r1hN-XSn5-26oy8KrHGnELX0Q98 Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC: Proposed Update to Security Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2014 16:50:24 -0000 Oops, you are correct. I agree with your proposal. > On Nov 28, 2014, at 10:31 AM, = wrote: >=20 > My point was that integrity covers the case "insert/modify/remove". > The confidentiality aspects are covered in the next paragraph. >=20 > And so my proposal.=20 >=20 > Regards, >=20 > lionel=20 >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : vendredi 28 novembre 2014 16:44 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org list > Objet : Re: [Dime] DOIC: Proposed Update to Security Considerations >=20 > I agree it should be more precise, but I think confidentially also = might matter, since we have requirements to be able to authorize who can = see overload information. I propose changing "security features" to = "integrity and confidentiality protection", and "may insert or modify" = to "may insert, read, or modify" >=20 >> On Nov 28, 2014, at 7:39 AM, = wrote: >>=20 >> Ok with the content. >> Just one proposed correction in section 9.4: >>=20 >> 9.4. End-to End-Security Issues >>=20 >> The lack of end-to-end security features makes it difficult to >> establish trust in overload reports that originate from non-adjacent >> nodes. Any agents in the message path may insert or modify overload >>=20 >> I assume that what you want to highlight is the lack of E2E = integrity, right? >> what about: >>=20 >> The lack of end-to-end *integrity* features makes it difficult to >> establish trust in overload reports *received* from non-adjacent >> nodes. Any agents in the message path may insert or modify overload >>=20 >> regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell=20= >> Envoy=E9 : mardi 25 novembre 2014 23:37 =C0 : dime@ietf.org list = Objet :=20 >> [Dime] DOIC: Proposed Update to Security Considerations >>=20 >> Hi, >>=20 >> Here's some proposed text to update the security considerations. The = main changes were to emphasize how certain decisions (OLRs only in = answers, implicit determination of Realm, application, and host) = partially mitigate certain attacks. I also added text on how a = non-supporting agent might be falsely assumed to support DOIC, and made = some general editorial changes. >>=20 >> ------------------ >>=20 >> 9. Security Considerations >>=20 >> DOIC gives Diameter nodes the ability to request that downstream >> nodes send fewer Diameter requests. Nodes do this by exchanging >> overload reports that directly effect this reduction. This exchange >> is potentially subject to multiple methods of attack, and has the >> potential to be used as a Denial-of-Service (DoS) attack vector. >>=20 >> Overload reports may contain information about the topology and >> current status of a Diameter network. This information is >> potentially sensitive. Network operators may wish to control >> disclosure of overload reports to unauthorized parties to avoid its >> use for competitive intelligence or to target attacks. >>=20 >> Diameter does not include features to provide end-to-end >> authentication, integrity protection, or confidentiality. This may >> cause complications when sending overload reports between non- >> adjacent nodes. >>=20 >> 9.1. Potential Threat Modes >>=20 >> The Diameter protocol involves transactions in the form of requests >> and answers exchanged between clients and servers. These clients = and >> servers may be peers, that is, they may share a direct transport >> (e.g. TCP or SCTP) connection, or the messages may traverse one or >> more intermediaries, known as Diameter Agents. Diameter nodes use >> TLS, DTLS, or IPSec to authenticate peers, and to provide >> confidentiality and integrity protection of traffic between peers. >> Nodes can make authorization decisions based on the peer identities >> authenticated at the transport layer. >>=20 >> When agents are involved, this presents an effectively transitive >> trust model. That is, a Diameter client or server can authorize an >> agent for certain actions, but it must trust that agent to make >> appropriate authorization decisions about its peers, and so on. >> Since confidentiality and integrity protection occurs at the >> transport layer, agents can read, and perhaps modify, any part of a >> Diameter message, including an overload report. >>=20 >> There are several ways an attacker might attempt to exploit the >> overload control mechanism. An unauthorized third party might = inject >> an overload report into the network. If this third party is = upstream >> of an agent, and that agent fails to apply proper authorization >> policies, downstream nodes may mistakenly trust the report. This >> attack is at least partially mitigated by the assumption that nodes >> include overload reports in Diameter answers but not in requests. >> This requires an attacker to have knowledge of the original request >> in order to construct an answer. Such an answer would also need to >> arrive at a Diameter node via a protected transport connection. >> Therefore, implementations MUST validate that an answer containing = an >> overload report is a properly constructed response to a pending >> request prior to acting on the overload report, and that the answer >> was received via an appropriate transport connection. >>=20 >> A similar attack involves a compromised but otherwise authorized = node >> that sends an inappropriate overload report. For example, a server >> for the realm "example.com" might send an overload report indicating >> that a competitor's realm "example.net" is overloaded. If other >> nodes act on the report, they may falsely believe that "example.net" >> is overloaded, effectively reducing that realm's capacity. >> Therefore, it's critical that nodes validate that an overload report >> received from a peer actually falls within that peer's = responsibility >> before acting on the report or forwarding the report to other peers. >> For example, an overload report from a peer that applies to a realm >> not handled by that peer is suspect. >>=20 >> This attack is partially mitigated by the fact that the >> application, as well as host and realm, for a given OLR is >> determined implicitly by respective AVPs in the enclosing answer. >> If a reporting node modifies any of those AVPs, the enclosing >> transaction will also be affected. >>=20 >> 9.2. Denial of Service Attacks >>=20 >> Diameter overload reports, especially realm-reports, can cause a = node >> to cease sending some or all Diameter requests for an extended >> period. This makes them a tempting vector for DoS attacks. >> Furthermore, since Diameter is almost always used in support of = other >> protocols, a DoS attack on Diameter is likely to impact those >> protocols as well. Therefore, Diameter nodes MUST NOT honor or >> forward OLRs received from peers that are not trusted to send them. >>=20 >> An attacker might use the information in an OLR to assist in DoS >> attacks. For example, an attacker could use information about >> current overload conditions to time an attack for maximum effect, or >> use subsequent overload reports as a feedback mechanism to learn the >> results of a previous or ongoing attack. Operators need the ability >> to ensure that OLRs are not leaked to untrusted parties. >>=20 >> 9.3. Non-Compliant Nodes >>=20 >> In the absence of an overload control mechanism, Diameter nodes need >> to implement strategies to protect themselves from floods of >> requests, and to make sure that a disproportionate load from one >> source does not prevent other sources from receiving service. For >> example, a Diameter server might throttle a certain percentage of >> requests from sources that exceed certain limits. Overload control >> can be thought of as an optimization for such strategies, where >> downstream nodes never send the excess requests in the first place. >> However, the presence of an overload control mechanism does not >> remove the need for these other protection strategies. >>=20 >> When a Diameter node sends an overload report, it cannot assume that >> all nodes will comply, even if they indicate support for DOIC. A >> non-compliant node might continue to send requests with no reduction >> in load. Such non-compliance could be done accidentally, or >> maliciously to gain an unfair advantage over compliant nodes. >> Requirement 28 [RFC7068] indicates that the overload control = solution >> cannot assume that all Diameter nodes in a network are trusted, and >> that malicious nodes not be allowed to take advantage of the = overload >> control mechanism to get more than their fair share of service. >>=20 >> 9.4. End-to End-Security Issues >>=20 >> The lack of end-to-end security features makes it difficult to >> establish trust in overload reports that originate from non-adjacent >> nodes. Any agents in the message path may insert or modify overload >> reports. Nodes must trust that their adjacent peers perform proper >> checks on overload reports from their peers, and so on, creating a >> transitive-trust requirement extending for potentially long chains = of >> nodes. Network operators must determine if this transitive trust >> requirement is acceptable for their deployments. Nodes supporting >> Diameter overload control MUST give operators the ability to select >> which peers are trusted to deliver overload reports, and whether = they >> are trusted to forward overload reports from non-adjacent nodes. >> DOIC nodes MUST strip DOIC AVPs from messages received from peers >> that are not trusted for DOIC purposes. >>=20 >> The lack of end-to-end confidentiality protection means that any >> Diameter agent in the path of an overload report can view the >> contents of that report. In addition to the requirement to select >> which peers are trusted to send overload reports, operators MUST be >> able to select which peers are authorized to receive reports. A = node >> MUST not send an overload report to a peer not authorized to receive >> it. Furthermore, an agent MUST remove any overload reports that >> might have been inserted by other nodes before forwarding a Diameter >> message to a peer that is not authorized to receive overload = reports. >>=20 >> A DOIC node cannot always automatically detect that a peer also >> supports DOIC. For example, a node might have a peer that is a >> non-supporting agent. If nodes on the other side of that agent >> send OC-Supported-Features AVPs, the agent is likely to forward >> them as unknown AVPs. Messages received across the = non-supporting >> agent may be indistinguishable from messages received across a >> DOIC supporting agent, giving the false impression that the non- >> supporting agent actually supports DOIC. This complicates the >> transitive-trust nature of DOIC. Operators need to be careful to >> avoid situations where a non-supporting agent is mistakenly >> trusted to enforce DOIC related authorization policies. >>=20 >> At the time of this writing, the DIME working group is studying >> requirements for adding end-to-end security features >> [I-D.ietf-dime-e2e-sec-req] to Diameter. These features, when they >> become available, might make it easier to establish trust in non- >> adjacent nodes for overload control purposes. Readers should be >> reminded, however, that the overload control mechanism encourages >> Diameter agents to modify AVPs in, or insert additional AVPs into, >> existing messages that are originated by other nodes. If end-to-end >> security is enabled, there is a risk that such modification could >> violate integrity protection. The details of using any future >> Diameter end-to-end security mechanism with overload control will >> require careful consideration, and are beyond the scope of this >> document. >>=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'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. >>=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