From nobody Mon Jun 11 07:35:17 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E276130F79; Mon, 11 Jun 2018 07:35:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152872771012.2640.15482245247353586745@ietfa.amsl.com> Date: Mon, 11 Jun 2018 07:35:10 -0700 Archived-At: Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 14:35:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions WG of the IETF. Title : Diameter Group Signaling Authors : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-11.txt Pages : 26 Date : 2018-06-11 Abstract: In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter nodes to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dime-group-signaling-11 https://datatracker.ietf.org/doc/html/draft-ietf-dime-group-signaling-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-group-signaling-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 11 07:45:57 2018 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D456A130FEC for ; Mon, 11 Jun 2018 07:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCF9nAX8B7v9 for ; Mon, 11 Jun 2018 07:45:52 -0700 (PDT) Received: from mailer2.neclab.eu (mailer2.neclab.eu [195.37.70.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963E9124D68 for ; Mon, 11 Jun 2018 07:45:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer2.neclab.eu (Postfix) with ESMTP id 68F18F203A; Mon, 11 Jun 2018 16:45:50 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (neclab.eu) Received: from mailer2.neclab.eu ([127.0.0.1]) by localhost (atlas-b.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJABmuLIcCmi; Mon, 11 Jun 2018 16:45:50 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer2.neclab.eu (Postfix) with ESMTPS id 28293F2018 for ; Mon, 11 Jun 2018 16:45:48 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.27]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Mon, 11 Jun 2018 16:45:47 +0200 From: Marco Liebsch To: "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-group-signaling-11.txt Thread-Index: AQHUAZF0egv6QT/aKkak0KPzbafTMqRbH/mQ Date: Mon, 11 Jun 2018 14:45:46 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DE0EEB204@PALLENE.office.hd> References: <152872771012.2640.15482245247353586745@ietfa.amsl.com> In-Reply-To: <152872771012.2640.15482245247353586745@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dime] FW: I-D Action: draft-ietf-dime-group-signaling-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 14:45:56 -0000 We updated the group signaling draft to an 11th revision according to some = remaining improvement hints which we received. The document should be ready now to proceed. Main edits were as follows: o Clarifying text about the use of the SESSION_GROUP_STATUS_IND flag in 2nd= paragraph of Sec. 4.2.1 o Clarifying text about the use of the Group-Response-Action AVP in 3rd par= agraph of Sec. 4.4.1 o Adding text to IANA section which request two new registries for the Sess= ion-Group-Control-Vector AVP and the Session-Group-Capability-Vector AVP marco -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Montag, 11. Juni 2018 16:35 To: i-d-announce@ietf.org Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions WG of = the IETF. Title : Diameter Group Signaling Authors : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-11.txt Pages : 26 Date : 2018-06-11 Abstract: In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter nodes to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dime-group-signaling-11 https://datatracker.ietf.org/doc/html/draft-ietf-dime-group-signaling-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-group-signaling-11 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Jun 11 13:03:54 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68842130EC8; Mon, 11 Jun 2018 13:03:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152874743240.2701.1111655626828280354@ietfa.amsl.com> Date: Mon, 11 Jun 2018 13:03:52 -0700 Archived-At: Subject: [Dime] I-D Action: draft-ietf-dime-rfc4006bis-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 20:03:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions WG of the IETF. Title : Diameter Credit-Control Application Authors : Lyle Bertz David Dolson Yuval Lifshitz Filename : draft-ietf-dime-rfc4006bis-09.txt Pages : 127 Date : 2018-06-11 Abstract: This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC4006, and it must be supported by all new Diameter Credit-Control Application implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-dime-rfc4006bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-rfc4006bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 12 08:10:18 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FF9130E5C; Tue, 12 Jun 2018 08:10:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: dime@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152881621501.9270.657869602081141919@ietfa.amsl.com> Date: Tue, 12 Jun 2018 08:10:15 -0700 Archived-At: Subject: [Dime] IPR Disclosure Nokia Solutions and Networks Oy's Statement about IPR related to RFC 7683 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 15:10:15 -0000 Dear Jouni Korhonen, Steve Donovan, Ben Campbell, Lionel Morand: An IPR disclosure that pertains to your RFC entitled "Diameter Overload Indication Conveyance" (RFC7683) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3209/). The title of the IPR disclosure is "Nokia Solutions and Networks Oy's Statement about IPR related to RFC 7683" Thank you IETF Secretariat From nobody Wed Jun 13 10:30:46 2018 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4F130F18 for ; Wed, 13 Jun 2018 10:30:43 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3i7tBqYT8wB for ; Wed, 13 Jun 2018 10:30:41 -0700 (PDT) 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 5D53C130E6C for ; Wed, 13 Jun 2018 10:30:41 -0700 (PDT) Received: from [38.98.37.142] (port=34776 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1fT9bB-00AN4P-TH; Wed, 13 Jun 2018 10:30:41 -0700 To: dime@ietf.org, ecnoel@research.att.com References: <8FB01050-7B63-4A1B-B50A-974D0FA448C4@nostrum.com> From: Steve Donovan Message-ID: <06dc2172-4b2a-c0c4-e411-8928acd13a1b@usdonovans.com> Date: Wed, 13 Jun 2018 18:30:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=0.7 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] draft-ietf-dime-doic-rate-control-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 17:30:44 -0000 See my comments inline. Steve On 5/25/18 4:17 PM, Gunn, Janet P (CNV) wrote: > Not an author, but I have a strong interest in this ID. Comments in line. > Janet > > -----Original Message----- > From: DiME On Behalf Of Ben Campbell > Sent: Wednesday, May 16, 2018 1:31 AM > To: draft-ietf-dime-doic-rate-control.all@ietf.org > Cc: dime@ietf.org > Subject: [Dime] draft-ietf-dime-doic-rate-control-08 > > Substantive Comments: > > General: > The document seems inconsistent about whether rate limits are only reported during overload conditions, or in advance of overload conditions. > > I think that would be "local policy" of the serving (reporting) node, and independent of the protocol used to communicate it. I think most cases would be reactive, but I can see situations where it could be proactive. SRD> I agree with Janet, when the report is sent is very much local policy.  There is no reason to attempt to prevent proactive use of the rate mechanism. > > I’d like to see the need to allocate the rate limit across all potential sources of traffic given some more emphasis. (Maybe a sub-section of its own?) > > I agree, but again I see that as "local policy" of the serving (reporting) node. In particular, there may be reacting nodes that do not support the rate abatement algorithm. SRD> Again, I agree with Janet.  This is local policy and there may well be a mix of rate and loss if not all nodes support rate.  I don't think it is appropriate to say that rate should be preferred over loss.  But maybe I'm missing your meaning on "allocate the rate limit". > > > §1: > - “ While this can effectively decrease the load handled by the > server, it does not directly address cases where the rate of arrival > of service requests increases quickly." > > I think it fails to address cases where the load changes rapidly in either direction, right? At least, the following text seems to say that. > > I agree. When there are rapid fluctuations in the offered load, the "loss" algorithm errs both in throttling TOO MUCH when there is a dip in offered load, and throttling NOT ENOUGH when there is a spike in offered load. SRD> The text in section 1 talks about this already.  Is there a specific change being suggested? > > > > §3: Does the need for future report types to consider the rate algorithm have IANA implications? SRD> Are you suggesting that the IANA section indicate that all new report types MUST indicate whether or not the rate algorithm can be used with that report type?  I can make that change to the IANA section if it would be appropriate. > > §5.1: The first paragraph indicates state should be kept for every reacting node to which it sends an OLR. But the 5th paragraph can be interpreted to say it sends an OLR to every reacting node with which it has negotiated use of the rate algorithm. (see general comment). SRD> I'm missing something.  The first paragraph says the reporting node maintains state any time it sends a rate overload report.  The fifth paragraph is just saying that the report must include the rate information. > > §5.4: The first paragraph seems to suggest the reacting node keeps OCS for every server that has indicated support for the rate algorithm, not just nodes that have sent OLRs. Is that the intent? SRD>  Yes, that is the intent.  This allows the reacting node to make sure that the machinery needed to respond to a rate request is in place prior to receiving an OLR. > > §5.6, first paragraph: The MAY seems week here. I know and agree that we don’t want to force a particular application. But don’t we need to say that if an implementation uses a different algorithm, it MUST have the same behavior as the algorithm in section 7? > > I think it MUST "limit the message rate to the OC-Maximum-Rate AVP value in units of messages per second" (as stated in 7.3.1). The algorithm described in the rest of 7.3.1 and 7.3.2 is somewhat more sophisticated, allowing for a smoothing factor (TAU) and prioritization. I do not think we need to say that the selected algorithm MUST have those features. SRD> Again, I agree with Janet. > > §7.2, third and 4th paragraphs: I don’t understand what this is trying to say. Please elaborate. > > 3rd para - Just as a "for instance"- if the reacting node has 50/second low priority messages and 50/second high priority messages that it want to send, and has a rate limit of 75/second, it will send 25/second low priority messages and 50 /second high priority messages. The limit of 75/second applies to the combined stream of high and low priority messages, even though only the low priority messages are being abated. > > 4th para - in the same example, it could be that the high priority messages typically require more processing resources (cpu, etc) than the low priority messages (or vice versa). So cutting the rate to 75/sec may NOT produce the expected reduction in resource usage. SRD> Thanks Janet, I couldn't have explained it better. > > > -6th paragraph: “ may receive requests at a rate below its target maximum Diameter request rate while others above that target rate. But the resulting request rate presented to the overloaded reporting node will converge towards the target Diameter request rate.” > > Why do we expect traffic to converge to the rate limit? It seems like that won't happen if some reporting nodes are not sending at full capacity, unless work can be shifted from the high-rate sources to the slow-rate ones. > > Probably would be better to say that it "will converge toward a rate at or below the target Diameter request rate.” SRD> I'm okay with making Janet's suggested change. > > §7.3.1: paragraph starting with “ In situations where reacting nodes are configured with some knowledge” > > that requires knowledge of other traffic sources, not just knowledge of the reporting node. > > The example code says to transmit a message if (Xp <= TAU). But the text said the limit was “T+TAU). > > I think it is supposed to be "T+TAU" SRD> I'd like to get Eric's opinion on this.  This section was copied from the SOC RFC so if it is in error here than it is in error there as well. > > §9: I think the security considerations need more thought. What are the security considerations specific to the rate algorithm? If there aren’t any, then please describe the rational behind that. But I suspect there are, for example, can this be used for a DoS? Can it be used to help _mitigate_ a DoS? Could one reacting node cause others to be traffic starved? > > It is possible that a reacting node that does not support overload control could starve the nodes that do support overload control, but this is also true of the loss based version SRD> I'm not convinced that there are security scenarios that are new or different for rate versus those documented in the existing DOIC specifications. > > Editorial Comments: > > General: IDNits returns several issues. Some of those may be errors on its part, but I’m pretty sure some of them are real. Please resolve these. SRD> I'll look at those next time I try to submit but I've not gotten IDNits errors in the past. SRD> I've made the suggested changes below unless indicated otherwise. > > Requirements: There are instances of lower case “must” and “should”. Please use the new boilerplate from RFC 8174. > > §1 > - “protect the stability” seems awkward. Maybe “ensure the stability”? > - Also s/ “subjected with” / “subjected to”.. > > - Please cite the definitions for “reporting node” and “reacting node”. I know they are defined later, but these are somewhat non-intuitive concepts and people will likely stumble over the terms when they are used before they are defined. > - Please expand DOIC and SOC on first mention in the body. (Even if they were expanded in the abstract.) > > §2: > - Definitions of “Diameter Node” and “Diameter Endpoint”: Please use proper citations rather than just referring to the RFC in text. For example: “Diameter Node: A Diameter client, server, or agent. [RFC6733]” > > §4, > - first paragraph: > — “This extension defines”: I think this should say “This document defines…” > — Please consider active voice for the last sentence. > > - 2nd paragraph: The first sentence seems awkward. Consider something to the effect of “Since all nodes that support DOIC are required to support the loss algorithm…” > > - 3rd paragraph: This paragraph seems to belong as part of the previous paragraph. SRD> I think it is a new paragraph. > > - 4th paragraph: “ AVP in the sent to the DOIC reacting nodes”: Missing word(s)? SRD> Yes indeed, added "message sent". > > -5th paragraph: “A reporting node MAY select…” : Is that a new permission, or a statement of fact? SRD> It is a statement of fact.  Changed may to can. > > §5.1, third paragraph: The text is not clear whether this means OCS should be maintained per supported application, etc, or that it should maintain state when the rate algorithm on a per supported application, etc, basis. SRD> I don't understand the point being made here. > - 4th paragraph: s/overoload/overload > > §5.3: 2nd paragraph: This seems like a redundant restatement of the first paragraph. SRD> The first paragraph indicates that the reporting node must indicate the rate abatement algorithm in the OCS.  The second paragraph indicates that the reporting node must include the rate value in the OCS. > - third paragraph: The first sentence is convoluted; can it be broken into simpler sentences? SRD> I shorted it from:    When selecting the rate algorithm in the response to a request that    contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP    indicating support for the rate feature, a reporting node... to When selecting the rate algorithm a reporting node... > > §6.1.1, definition of " OLR_RATE_ALGORITHM”: Two periods at end of sentence. > SRD> I am hesitant to change any of the test in section 7 given that it is taken from the SOC specification.  I would prefer that Eric comment on these proposed changes before including them in the next version. > §7.1, 2nd paragraph: “ signal one another support for rate-based overload > control”: This seems awkward; are there missing words? > > §7.2, last two paragraphs: The MUSTs do not seem necessary. 2119 keywords should be used when there is some sort of choice or room for error. You don’t need them to define the basic operation of the protocol. > > §7.3.1: I found the text hard to follow. It would help to declare all the identifiers and initialization up front, and to present things in more of a stepwise fashion. > > - T is effectively a time interval, right? It would help to say that, especially later when you subtract a different time interval from it. > > - paragraph 9: Should “admit” be “emit”? > > - the example code has several mentions of SIP requests. > > §7.3.2: “ Request candidates for reduction, requests not subject to reduction (except under extenuating circumstances when there aren’t any messages in the first category that can be reduced).”: That seems like an awkward way to say that the second category is the set of requests that is only subject to reduction if there are no messages left in the first category. > > Yes, that is what it means. > > - “ This can be generalized to n priorities using n thresholds for n>2 in the obvious way.”: I suggest you refrain from calling it “obvious". > > §7.3.3: Paragraph starting with “ Then (only) if the arrival is admitted, increase the bucket by an amount…”: I think you increase the bucket _count_, right? > > > > > > > > > > > > > > This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jun 14 14:38:44 2018 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127CC130F7C for ; Thu, 14 Jun 2018 14:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZbtGjlxfaig for ; Thu, 14 Jun 2018 14:38:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1470F130F66 for ; Thu, 14 Jun 2018 14:38:30 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5ELcSPV061760 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Jun 2018 16:38:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <8B34DBC2-3A66-43CB-A9B2-4CB51C36E062@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E7588C53-A087-442B-8795-4E794F09FF0B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 14 Jun 2018 16:38:27 -0500 In-Reply-To: <06dc2172-4b2a-c0c4-e411-8928acd13a1b@usdonovans.com> Cc: dime@ietf.org, ecnoel@research.att.com To: Steve Donovan References: <8FB01050-7B63-4A1B-B50A-974D0FA448C4@nostrum.com> <06dc2172-4b2a-c0c4-e411-8928acd13a1b@usdonovans.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Dime] draft-ietf-dime-doic-rate-control-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 21:38:43 -0000 --Apple-Mail=_E7588C53-A087-442B-8795-4E794F09FF0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, See my responses inline. I removed sections that seem resolved. Thanks, Ben. > On Jun 13, 2018, at 12:30 PM, Steve Donovan = wrote: >=20 > See my comments inline. >=20 > Steve >=20 > On 5/25/18 4:17 PM, Gunn, Janet P (CNV) wrote: >> Not an author, but I have a strong interest in this ID. Comments in = line. >> Janet >>=20 >> -----Original Message----- >> From: DiME On Behalf Of Ben Campbell >> Sent: Wednesday, May 16, 2018 1:31 AM >> To: draft-ietf-dime-doic-rate-control.all@ietf.org >> Cc: dime@ietf.org >> Subject: [Dime] draft-ietf-dime-doic-rate-control-08 >>=20 >> Substantive Comments: >>=20 >> General: >> The document seems inconsistent about whether rate limits are only = reported during overload conditions, or in advance of overload = conditions. >>=20 >> I think that would be "local policy" of the serving (reporting) = node, and independent of the protocol used to communicate it. I think = most cases would be reactive, but I can see situations where it could be = proactive. > SRD> I agree with Janet, when the report is sent is very much local = policy. There is no reason to attempt to prevent proactive use of the = rate mechanism. That=E2=80=99s fine with me, but a sentence or two to that effect would = be helpful. (On re-reading, I see where section 1 talks about = =E2=80=9Capproaching overload or overloaded=E2=80=9D, but I assume = neither of those conditions are necessary?) >>=20 >> I=E2=80=99d like to see the need to allocate the rate limit across = all potential sources of traffic given some more emphasis. (Maybe a = sub-section of its own?) >>=20 >> I agree, but again I see that as "local policy" of the serving = (reporting) node. In particular, there may be reacting nodes that do not = support the rate abatement algorithm. > SRD> Again, I agree with Janet. This is local policy and there may = well be a mix of rate and loss if not all nodes support rate. I don't = think it is appropriate to say that rate should be preferred over loss. = But maybe I'm missing your meaning on "allocate the rate limit=E2=80=9D. Okay, but you still have to allocate the rate limit across all sources = that you apply the rate algorithm to, right? That is, the total offered = rate will be something like (average rate per source) * (number of = sources). Or am I misunderstanding something? >>=20 >>=20 >> =C2=A71: >> - =E2=80=9C While this can effectively decrease the load handled by = the >> server, it does not directly address cases where the rate of = arrival >> of service requests increases quickly." >>=20 >> I think it fails to address cases where the load changes rapidly in = either direction, right? At least, the following text seems to say that. >>=20 >> I agree. When there are rapid fluctuations in the offered = load, the "loss" algorithm errs both in throttling TOO MUCH when there = is a dip in offered load, and throttling NOT ENOUGH when there is a = spike in offered load. > SRD> The text in section 1 talks about this already. Is there a = specific change being suggested? Section 1 talks about rapidly increasing load. Did I miss mention of = rapidly _decreasing_ load? >>=20 >>=20 >>=20 >> =C2=A73: Does the need for future report types to consider the rate = algorithm have IANA implications? > SRD> Are you suggesting that the IANA section indicate that all new = report types MUST indicate whether or not the rate algorithm can be used = with that report type? I can make that change to the IANA section if it = would be appropriate. >>=20 I=E2=80=99m not suggesting, I=E2=80=99m asking :-) But my point was = more along whether the IANA registry for report types should include a = field about supporting the rate algorithm. >> =C2=A75.1: The first paragraph indicates state should be kept for = every reacting node to which it sends an OLR. But the 5th paragraph can = be interpreted to say it sends an OLR to every reacting node with which = it has negotiated use of the rate algorithm. (see general comment). > SRD> I'm missing something. The first paragraph says the reporting = node maintains state any time it sends a rate overload report. The = fifth paragraph is just saying that the report must include the rate = information. Actually, my question relates to my question on 5.4. The first paragraph = says to keep state for every reporting node to which it sends an OLR. = The 5th paragraph implies that it sends on OLR when it selects the rate = algorithm for a reacting node. (If you are going to include the rate = info, you have to have a report to include it in.) So it comes down to clarity about what events happen =E2=80=9Cwhen the = reporting node selects the algorithm for a reacting node=E2=80=9D vs = =E2=80=9Cwhen the reporting node sends an OLR=E2=80=9D. >>=20 >> =C2=A75.4: The first paragraph seems to suggest the reacting node = keeps OCS for every server that has indicated support for the rate = algorithm, not just nodes that have sent OLRs. Is that the intent? > SRD> Yes, that is the intent. This allows the reacting node to make = sure that the machinery needed to respond to a rate request is in place = prior to receiving an OLR. See above. >>=20 >> =C2=A75.6, first paragraph: The MAY seems week here. I know and agree = that we don=E2=80=99t want to force a particular application. But = don=E2=80=99t we need to say that if an implementation uses a different = algorithm, it MUST have the same behavior as the algorithm in section 7? >>=20 >> I think it MUST "limit the message rate to the OC-Maximum-Rate = AVP value in units of messages per second" (as stated in 7.3.1). The = algorithm described in the rest of 7.3.1 and 7.3.2 is somewhat more = sophisticated, allowing for a smoothing factor (TAU) and prioritization. = I do not think we need to say that the selected algorithm MUST have = those features. > SRD> Again, I agree with Janet. Okay. >>=20 >> =C2=A77.2, third and 4th paragraphs: I don=E2=80=99t understand what = this is trying to say. Please elaborate. >>=20 >> 3rd para - Just as a "for instance"- if the reacting node has = 50/second low priority messages and 50/second high priority messages = that it want to send, and has a rate limit of 75/second, it will send = 25/second low priority messages and 50 /second high priority messages. = The limit of 75/second applies to the combined stream of high and low = priority messages, even though only the low priority messages are being = abated. >>=20 >> 4th para - in the same example, it could be that the high = priority messages typically require more processing resources (cpu, etc) = than the low priority messages (or vice versa). So cutting the rate to = 75/sec may NOT produce the expected reduction in resource usage. > SRD> Thanks Janet, I couldn't have explained it better. Janet=E2=80=99s explanation is good, but I don=E2=80=99t get that from = the text, at least in the case of the third paragraph. In the 4th paragraph, I don=E2=80=99t understand how the reporting node = would =E2=80=9Ctake into account the workload=E2=80=9D in a useful way. = That seems to suggest the reporting node can predict the impact of = workload based decisions made by the reacting node, which seems unlikely = unless there is some out-of-band agreement. Is this really saying anything more than =E2=80=9CThe reacting nodes = will decide which messages to send and which to drop, and the result may = not be predictable by the reporting node=E2=80=9D? >>=20 >>=20 >> -6th paragraph: =E2=80=9C may receive requests at a rate below its = target maximum Diameter request rate while others above that target = rate. But the resulting request rate presented to the overloaded = reporting node will converge towards the target Diameter request = rate.=E2=80=9D >>=20 >> Why do we expect traffic to converge to the rate limit? It seems like = that won't happen if some reporting nodes are not sending at full = capacity, unless work can be shifted from the high-rate sources to the = slow-rate ones. >>=20 >> Probably would be better to say that it "will converge toward = a rate at or below the target Diameter request rate.=E2=80=9D > SRD> I'm okay with making Janet's suggested change. WFM. >>=20 >> =C2=A77.3.1: paragraph starting with =E2=80=9C In situations where = reacting nodes are configured with some knowledge=E2=80=9D >>=20 >> that requires knowledge of other traffic sources, not just knowledge = of the reporting node. >>=20 >> The example code says to transmit a message if (Xp <=3D TAU). But the = text said the limit was =E2=80=9CT+TAU). >>=20 >> I think it is supposed to be "T+TAU" > SRD> I'd like to get Eric's opinion on this. This section was copied = from the SOC RFC so if it is in error here than it is in error there as = well. I agree with getting Eric=E2=80=99s opinion :-) >>=20 >> =C2=A79: I think the security considerations need more thought. What = are the security considerations specific to the rate algorithm? If there = aren=E2=80=99t any, then please describe the rational behind that. But I = suspect there are, for example, can this be used for a DoS? Can it be = used to help _mitigate_ a DoS? Could one reacting node cause others to = be traffic starved? >>=20 >> It is possible that a reacting node that does not support = overload control could starve the nodes that do support overload = control, but this is also true of the loss based version > SRD> I'm not convinced that there are security scenarios that are new = or different for rate versus those documented in the existing DOIC = specifications. This draft adds a new feature that isn=E2=80=99t in the base mechanism. = I gather your point is to say that the new feature shares the same = security considerations as the base, and adds no new ones. Right now, = section 9 only states the former. >>=20 >> Editorial Comments: >>=20 >> General: IDNits returns several issues. Some of those may be errors = on its part, but I=E2=80=99m pretty sure some of them are real. Please = resolve these. > SRD> I'll look at those next time I try to submit but I've not gotten = IDNits errors in the past. >=20 > SRD> I've made the suggested changes below unless indicated otherwise. >>=20 =E2=80=A6 and I=E2=80=99ve deleted sections that seem resolved. [=E2=80=A6] >>=20 >> =C2=A75.1, third paragraph: The text is not clear whether this means = OCS should be maintained per supported application, etc, or that it = should maintain state when the rate algorithm on a per supported = application, etc, basis. > SRD> I don't understand the point being made here. Probably because I failed to make it. I _think_ that the reporting node keeps state for each reporting node = for which it selects rate, and further needs to subdivide that state by = application and report type. But the it doesn=E2=80=99t need to keep = state for a reporting node for which it doesn=E2=80=99t select rate, = even though that reporting node might have an application in common with = the first reporting node? [=E2=80=A6] >>=20 >> =C2=A76.1.1, definition of " OLR_RATE_ALGORITHM=E2=80=9D: Two periods = at end of sentence. >>=20 > SRD> I am hesitant to change any of the test in section 7 given that = it is taken from the SOC specification. I would prefer that Eric = comment on these proposed changes before including them in the next = version. Makes sense. >> =C2=A77.1, 2nd paragraph: =E2=80=9C signal one another support for = rate-based overload >> control=E2=80=9D: This seems awkward; are there missing words? >>=20 >> =C2=A77.2, last two paragraphs: The MUSTs do not seem necessary. 2119 = keywords should be used when there is some sort of choice or room for = error. You don=E2=80=99t need them to define the basic operation of the = protocol. >>=20 >> =C2=A77.3.1: I found the text hard to follow. It would help to = declare all the identifiers and initialization up front, and to present = things in more of a stepwise fashion. >>=20 >> - T is effectively a time interval, right? It would help to say that, = especially later when you subtract a different time interval from it. >>=20 >> - paragraph 9: Should =E2=80=9Cadmit=E2=80=9D be =E2=80=9Cemit=E2=80=9D= ? >>=20 >> - the example code has several mentions of SIP requests. >>=20 >> =C2=A77.3.2: =E2=80=9C Request candidates for reduction, requests not = subject to reduction (except under extenuating circumstances when there = aren=E2=80=99t any messages in the first category that can be = reduced).=E2=80=9D: That seems like an awkward way to say that the = second category is the set of requests that is only subject to reduction = if there are no messages left in the first category. >>=20 >> Yes, that is what it means. >>=20 >> - =E2=80=9C This can be generalized to n priorities using n = thresholds for n>2 in the obvious way.=E2=80=9D: I suggest you refrain = from calling it =E2=80=9Cobvious". >>=20 >> =C2=A77.3.3: Paragraph starting with =E2=80=9C Then (only) if the = arrival is admitted, increase the bucket by an amount=E2=80=A6=E2=80=9D: = I think you increase the bucket _count_, right? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> This electronic message transmission contains information from CSRA = that may be attorney-client privileged, proprietary or confidential. The = information in this message is intended only for use by the = individual(s) to whom it is addressed. If you believe you have received = this message in error, please contact me immediately and be aware that = any use, disclosure, copying or distribution of the contents of this = message is strictly prohibited. NOTE: Regardless of content, this email = shall not operate to bind CSRA to any order or other contract unless = pursuant to explicit written agreement or government initiative = expressly permitting the use of email for such purpose. >> _______________________________________________ >> 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 --Apple-Mail=_E7588C53-A087-442B-8795-4E794F09FF0B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsi4FMACgkQgFZKbJXz 1A2d/Q/+MzJzOC8v/QdIhcwAKvJcLMYObagkLPWWhqksmWnvRrBvyytx1esNgn9z fmHmrXgcr/BGkWyxtkwu12nOCLmOXlKtuZ+Qm9T+MSWEZfK/Ed8eWNFniuCCBi3w bzYgnTbId94Bk/TrWZYD89pOiNvakTyf3uqci+2M6LDnJY2hPCT3ABHVZjqYsnr0 YN5bEkrEWhPKRO/D+B3U9uj0LT9GFKJvO1g67xYoupM1S42AaddR4Mextm2hedby q+3dxwCPQwEVdC63EwjMdxQU0D+2peyvaTRtX0IR2jPqo8hmzVtmpeyCUWmfsLNd TF84eXqjqPjUdIA2w29pxBQRLH8jc3yTfQCMfahEaRSz4D3SSweCB9z9IhQMjoWw SuZEDDrS4eZ0K2wOFnxmV/++edK1hWBpWe644JNPuCfH6aCRHtp3H69pF4zUwQ5t 0udAF56S9oK6LO5ER1+nFt6clzvtkbZU4swI5YwTOlzvve6KELt4u2nPb+wlweFf uWuVNxlTyVKTER67epAnGcS7bj159naW25E/mvTANFiNAV8sedvogk3y34M7J+tW DwI008YRk1Q6OY+PeLQEOy44pYJ8jBcLngthho3I9sl1PiopvkYrf1yXyi7JOqDs shCYinZF5FXpphzft9G2NjuzsvmIIA4sDyblnmW0hE3Sceso/zU= =sWS4 -----END PGP SIGNATURE----- --Apple-Mail=_E7588C53-A087-442B-8795-4E794F09FF0B-- From nobody Mon Jun 18 08:44:42 2018 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415BB130DE3 for ; Mon, 18 Jun 2018 08:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.711 X-Spam-Level: * X-Spam-Status: No, score=1.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5fXhNKz4b3l for ; Mon, 18 Jun 2018 08:44:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7040612872C for ; Mon, 18 Jun 2018 08:44:38 -0700 (PDT) Received: from CO2PR05CA0010.namprd05.prod.outlook.com (2603:10b6:102:2::20) by BN3PR0501MB1220.namprd05.prod.outlook.com (2a01:111:e400:400e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.15; Mon, 18 Jun 2018 15:44:36 +0000 Received: from SN1NAM01FT007.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::203) by CO2PR05CA0010.outlook.office365.com (2603:10b6:102:2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.884.14 via Frontend Transport; Mon, 18 Jun 2018 15:44:35 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by SN1NAM01FT007.mail.protection.outlook.com (10.152.65.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.863.11 via Frontend Transport; Mon, 18 Jun 2018 15:44:35 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w5IF6n4i035008 for ; Mon, 18 Jun 2018 10:44:34 -0500 Received: from prewe13m03.ad.sprint.com (prewe13m03.corp.sprint.com [144.226.128.22]) by plsapdm1.corp.sprint.com with ESMTP id 2jn06xy3j0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 18 Jun 2018 10:44:34 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M03.ad.sprint.com (2002:90e2:8016::90e2:8016) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Jun 2018 11:44:33 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1367.000; Mon, 18 Jun 2018 10:44:33 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New Version Notification for draft-bertz-dime-policygroups-06.txt Thread-Index: AQHUBxr+4X+1b1asWkGWOYjqP/XSW6RmJ95w Date: Mon, 18 Jun 2018 15:44:33 +0000 Message-ID: <85c9ea729d8c439ea3f3773bfb51a9bc@plswe13m04.ad.sprint.com> References: <152933605470.2967.16560879250207504442.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.28] Content-Type: multipart/alternative; boundary="_000_85c9ea729d8c439ea3f3773bfb51a9bcplswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.36; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(376002)(39380400002)(2980300002)(438002)(199004)(189003)(22974007)(186003)(356003)(24736004)(102836004)(45080400002)(59450400001)(966005)(72206003)(84326002)(33964004)(26005)(7696005)(108616005)(76176011)(53546011)(2420400007)(316002)(16586007)(5250100002)(15650500001)(6916009)(478600001)(2501003)(2906002)(5660300001)(790700001)(6116002)(3846002)(575784001)(14454004)(86362001)(4546004)(336012)(106002)(2900100001)(7736002)(97736004)(606006)(229853002)(2351001)(236005)(53936002)(54896002)(68736007)(6306002)(106466001)(2473003)(5640700003)(30436002)(8676002)(426003)(446003)(14971765001)(486006)(11346002)(8936002)(1730700003)(81166006)(81156014)(476003)(126002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1220; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT007; 1:G0LdGMUoIccIbyJVqxvK1yXmLENdhbg6Vx2MIMUqlvw6BcFUDc2p8ox16JaHyes0gXHQ+reUJaBVM/y6zY1VH47KokSeksldb65ZyNDiWLwWFuPiYnsrTkrvWJtxjDwA X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fe52a6d9-227d-4876-f075-08d5d532648c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:BN3PR0501MB1220; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1220; 3:kjjJ9K8HUL9QlJRJzUX1yAL9Qn8s4AyJjknoiCcdK59yC76NV1fANedjJOnrnrAeD1F4e88yI5OvtJP9dPavOTh3D/bGGJ80h7QKMpB5/9p9gBAOxp55WOuVp6TbHQyyhAWTxFQaikGuqjeAJJs7uo0QDgV4fh4aiiPg4nwJbIITBOUlWYdbk98nu6QEeKg/APnaORTosh/ukxk0jMB1MeOUCBfSdn8gLDXTj4yxaugazgA3+Yoc8xsuGVzWQg4Qspf4uEWuYnVx86l4mqvy1pYPGTg6iean6K1xUskLbdxV3g8PG68Xh/cE/2QSYEWIErI0is/cBZdRfeXdpYyO5v/qJEDxgigMFwdhJV6RBqQ=; 25:uufAMglMIvMCYB4d7xuumIQXbtf/THjkvH586X/CllH76yZbETurljA1h5u0e8WVdWZ3AG7GHnOcR64ctzOAiB++BhwttOYJj6rGfXAp59ObmLUkxX5400OSwYQPtBs+HDEjnGiVTm61A+2UFqcZ/9vA9NoJhGN0DYho+HJvJMIqW5RZ4AjScb85AC9tpUyUCOg+VWUr7YonFnnBy42YtMWZLtvdQnArCl+LpE2rbBPxBMREgccJxAsiNPP8MMawyg7Un0xxScnZMTLevj6MtDsRGj6+LFsgyFxJMjcuzcmT9EAwbIy3S9FmEsoLDyYvLSlFA2N75XLwQRMOwurz6w== X-MS-TrafficTypeDiagnostic: BN3PR0501MB1220: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1220; 31:5D4wNobJGDNoR33DYOnto3iqHJDVpJ20jCo8OkF7PRhXDuVxr55iKWJ2kPpFfj03T5vuESukGknPndOFfvjVo+2obGgtsWX7W86+2rbjjn0ePYXkFbXKUqbIZ4DrfbFPAIzXB4wLeW++1B+ljYvnHXhkvRWCqBuzAtJbng7ybuGVWs1JPkRokAz+OesIuLeQQgw0TUzZF7ZoBt1WbGJdn/9/oZPdxlkQHQPs+/pDdy8=; 20:xJBCFKc0Zy+BXvUIHskkBrXKQlvtCUkkkORWWCdJY5BcsISc0PVTLyjnVNF+cKdbk22X6PnMa+XiE9ezE1hyljQ0GASdoiPxS2bGIS5Tlyl9ixDX8eLmjc02DEfTUTcWD28FoC9E3v1rf4gQmlcDkEgEs8hedQCuSQjGuTKLmN5D6NWTwZ8KKzh55G+Vsvc2QtE1KneVtwLakzz4c6XgOPhovv3bEsXKeW1O8u1/RIY/tquJ3VZQsbGzbx6Ij+7ah9fH7+lvfIT6o86Ps4xJ38V5b1SUeqKsTLb8Dtn3lA325+LKEfIDCFJ87twgnDyxfNMZPdUBX9Fv1LC/R6Q/KqW//UYadpiV8Vrq27EktWpRKbA8ZU30hRXrA4dnzRvMM5GGPAi7uVqgR9MzL5+5i3pqlpe1T16I1qfg+U5QiVUPn4SpHPFn/vLnDzXUPJQnW4qKEuocwu4o6YlBAH7LcKHawZiY8ZyZF7VOMPRUZqA2w+/OjkJreN74SqUf7bCK X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(28532068793085)(120809045254105)(189930954265078)(85827821059158)(219752817060721)(21748063052155); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93004095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BN3PR0501MB1220; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1220; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1220; 4:iCDCGxa9y2auULPKs/KcgafhWBWwU5wbkKy2FTnwhtxebJlC+7TaSf5XALgNcidePmWaK/f3VWi+a12EeQ0vV7AF/PJSRTAqtahJg1gsg2FdbdTZgxi2XHGcRRAaGWuTy3/ARpU3a0wtS5LNihvgbjLv6c3sdm0S8vHV83WNsh9DlA0aT0kKXZIBoE6pq/j4tym6i/Nm6eMxitd36RQ51un7nbZ4CXa35/Z1n2ObvnwIeO5OWXK3DZALbYi9sOQoW4NC+F/hu3ob4f2T2UnJUZB5hQt6N+KSpoQ0hkGBAn3w5JT5MnfJe4GROyxJ3IjNtkeeP0MaOmB2bQELiOeE5a6XG8ceup0xxDF/yWh2r0VgeGvzhyPUmRIV3gA/CGQ/Z2OgVZDWOo/G9NVpZ+bRssZuxzIdNesDBiiKKvV2AAi3MSP0qVFynY1YqWeJyvAAUZiasbRe4IWdwQhgceGTvUU+Wx0R2SVWVKJ2mWn9eUo= X-Forefront-PRVS: 0707248B64 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1220; 23:6Uy1Ns5DwCUkn1agzOfNOJHnye1RJTwHAFbSViv?= =?us-ascii?Q?1MG5bq/onw+oklGkzD6iEzDOET/L5Wrf0pOwXipFSkogq4rtzzs89e0Xd/u5?= =?us-ascii?Q?TgllF0ukY+rvTm7tG5zL0I5spWCc613y7ooKNoazazdOqQm7oKMMrKJnpQ6C?= =?us-ascii?Q?O8+gb38iGNC4HmgARCPDTLPZiWYNfIfru88KV0spReLTtV4RUk1UK7kUvPPJ?= =?us-ascii?Q?ekYeeeF9wCYgOHnqcaIyDTaoOMm8zHWnXSDKvko2dAM1xDQjHihpHsiA29Ay?= =?us-ascii?Q?GAmNLn5XLFWsLt6+QLiwd52ET1L5BWL2YtZABKshCBxtN7QWgGGTIa6lqEKs?= =?us-ascii?Q?3OElCseW5Ofvp6GZjW0cfxtACVw1cc7Gvx2U8qZRgCZPzIO46RfZ0sp60H53?= =?us-ascii?Q?GOitcMDbSpdA2d4gw4YsAn2zi3F9s2Xft8t/rMZsNN7yJCpyoCeWk+iPkGp5?= =?us-ascii?Q?Xvs32abqr6JYYVR6+GT0TnJki26CGuq8OLK1+KTYz+XZI1wWqRtxpgwQqa3o?= =?us-ascii?Q?ZNTP5VJX9BC5NbedDn0Gh3oVB4wKTZmKluwU8JXloWvPC5i+zdGAKCQ4HNyn?= =?us-ascii?Q?Ijb3/y+m3YtCV8FI7kqfFnAcPaVnJtqePD7kpAIc1iuEyoX/JS+4hFFFiaCL?= =?us-ascii?Q?Rdn0uK4s0BHuz9piROVtu35te0ynkyuVOLbqixTJ160EICqHRUTY2i7C0dzE?= =?us-ascii?Q?p2hMlNP32yeGrrHiqyo0h9v+iWwhl29mCcuoZV0ZgeeZzN3g14an+oAvK89h?= =?us-ascii?Q?b6fAOxFXOLsMU7c8FOrQqJ1oWCi93pKxpz7CtHg77pxhuFkLDitNW6CpgHYm?= =?us-ascii?Q?nFI9gep4WCtSNNUvngzLoTxD/8T0qPAXUqR46Rwo5o82LqftCYl8HylqECNF?= =?us-ascii?Q?uMUXOVIOSH7Tpa8rRbq+RXR4soXmNQcQRELQeKz4i5h27pL1CQc+ZwCT+lNf?= =?us-ascii?Q?/fB4q6cIUygR2L3GGbyf6hd4UFQLF855BWaRj85kxLXzPbDV7S3jDwOcT/wv?= =?us-ascii?Q?FUFoYoJv9c5h62r5o1hv7NM/YzOxLXvyW2DvLxPrNo3xgKnX+nzrlvIQoRcz?= =?us-ascii?Q?p7rK27R5lQAaDxEcMkCxwk0hw/fGD05Hhujp00aDyFQ4goNNE4rau3x7uVxQ?= =?us-ascii?Q?qCq98FPvhganiLOaZOZw5DchgX8IBEo8eiWfmPAJ1F3HzTQYn7Pp+NGOXv9W?= =?us-ascii?Q?Q+tS/EZXh2ULr+9cFGoJpNOMZ0XsR7+09ag1FWftdH0EBsPNECtpaIuCQbN+?= =?us-ascii?Q?4lrdWKUgOR3iWKqYYTsa6cP1Zjsz/aPF22dTlM7S07H10AXddH+4KUbkgxKm?= =?us-ascii?Q?j/6beQMR53hht9pb1vreQ9kHh9GinsL7sf3kQiVCkDagnXzosGTs2O+b2JFG?= =?us-ascii?Q?UPc0q7x5C7P5xGu1geGgSwiVSDavcUfF7w0mrMT9KcuKzCuUf7p59o5Dskrn?= =?us-ascii?Q?e2oThcK0vBniDZ4H75E1lZbClOeimgmejY+KZ6lRfHDVEmJJnPlxgGhU07GG?= =?us-ascii?Q?/v1OUOmxLUOA1TErZabAmh7nf4SgU2Jem2f5dbnXKm+TatnZv03STmANoCws?= =?us-ascii?Q?YPKRwRXVJ0a9Z7zyiX5JF+F2J49iqTMJ6kqabRn4=3D?= X-Microsoft-Antispam-Message-Info: PAndWlqccS8aj2UkILRl1++yMP4q18cCWI+CKR+bhNAntwKFsKiNlgtoxSU+k1qVskXnMgHnSrMCYWL56V/pkteGDTnrYdM/dCWaKdBbjb0HUv2MkW9BNIga0T5ey5M8cYjrkgX8zrSfHqNc+Kr81Czl/nU9qCggQ5SBIWhBuQ+nMDlj2w+6n1Zp2tqPjVvL+lp5Wl7gVhvByc3Yn0J9lvFLAyzB0ChgX5haXQXbeNo1YvEJGSVmgcYtjGbBCbij5CCuMJoPOHo9Kscg3k4IP5YWoaytaH1LfqRgv2tYOk3nxYnEC4CCaV88iLM4eVyIBDu/L7fL4yyrP+jbweBxnA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1220; 6:6I2qzsqMeNgaEDRglIbSV5lC/e/Ib+fJt31Z22gU3oAJ0mxQRhfEZUQu1y7zgfLE6fPyhWJ3wnpQOBg9w7PQKgQMsnvnJixuTjdTGI5fKEo7fkgoSd8VgSMdfYdjRO0G0KHABdeOV/kssoHPc+p2ApAE4HV0PQbvNQAp/hgk18A8fp9hG8oxL7zUmZ6N1VUGKsJsgsnfJmqxUts53Psy64DMmK3gBObeu7Qqq0mqA78mMH0h9Pax83cn5L15dcqb4kydy/X7qH01FxZZYSF9gqZG3X02ZRIEW/sMlpU9e3YsvC6e80FO9cOQvfXW+aljcjhz5lkCXca9uAAtB7xdJzqL/NRpjdkEhVGiM+o1VTuGysQpT+uPQWGPDwTri8lAlJxnMDDQCp12oTVCtGmMfhYHEZy6j5SErGrKJ8tPUpVPPhu4u1QmEqVU5Bo/3Q+jQS7VnCiQlsiMK78BcnXK7A==; 5:P6KAP7DHLlQwDk6IPBgPNKiol/Jj1d7h54EtQWb3MfcPgZ7iYEfNmJHgiVV3pcHVbyAwBceV8bDuA/dkxc2RH+mCwsT87quNskF142tA9McMLV0ZUQl6KUOzfQhBOAeYgjad6leYr5WqnJ6qkIsW+JRoKdRYNB555z4EdYJ6h3Q=; 24:EGsVX4C4/SQRvpW278P9gcjS8aOVgkFDE38ZvoMrPK0dhra76BjNg48a2qyD4Jtj2Ph/O+Y+qIHaloOENE+5JHb+v5s6ko57Y/ZZjZQEU1Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1220; 7:k0KLHppAw+ltYewvpa/ypgFXOmwz30du3zsRAglipdJcz/7gAwMvFDB5KAhvMdpYZWrszqbRzJTXlpWSC9Rh6EcHEm0KaKzP74cWZZFYy4TZkLZzvNLV+zBuAWl/4LQKjCkdvlvntmyII413E/xwhMmzDw5eE3A3vlpnbSM2MVtadDkYPQh+7kHstA7oL7YPoi9hz6rmSBZKG5KDozih84JEqVCj98XQ7XrI6M5010Le6pUgwV9FlBMzhyQnGBR2 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2018 15:44:35.3426 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fe52a6d9-227d-4876-f075-08d5d532648c X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1220 Archived-At: Subject: [Dime] FW: New Version Notification for draft-bertz-dime-policygroups-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 15:44:42 -0000 --_000_85c9ea729d8c439ea3f3773bfb51a9bcplswe13m04adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpUaGlzIHZlcnNpb24gaW5jbHVkZXMgZmlndXJlIGFuZCBzcGVsbGluZyB1cGRhdGVz Lg0KDQpMeWxlDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJv bTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPj4NCkRhdGU6IE1vbiwgSnVuIDE4LCAyMDE4IGF0IDEwOjM0IEFNDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJlcnR6LWRpbWUtcG9saWN5Z3JvdXBzLTA2 LnR4dA0KVG86IE1hcmsgQmFsZXMgPHllbGxvd2plZXAyMDE3QGdtYWlsLmNvbTxtYWlsdG86eWVs bG93amVlcDIwMTdAZ21haWwuY29tPj4sIEx5bGUgQmVydHogPGx5bGViZTU1MTE0NEBnbWFpbC5j b208bWFpbHRvOmx5bGViZTU1MTE0NEBnbWFpbC5jb20+Pg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWJlcnR6LWRpbWUtcG9saWN5Z3JvdXBzLTA2LnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMeWxlIEJlcnR6IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1iZXJ0ei1kaW1lLXBvbGljeWdy b3Vwcw0KUmV2aXNpb246ICAgICAgIDA2DQpUaXRsZTogICAgICAgICAgRGlhbWV0ZXIgUG9saWN5 IEdyb3VwcyBhbmQgU2V0cw0KRG9jdW1lbnQgZGF0ZTogIDIwMTgtMDYtMTgNCkdyb3VwOiAgICAg ICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMQ0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iZXJ0ei1k aW1lLXBvbGljeWdyb3Vwcy0wNi50eHQ8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpbnRlcm5ldC1k cmFmdHMlMkZkcmFmdC1iZXJ0ei1kaW1lLXBvbGljeWdyb3Vwcy0wNi50eHQmZGF0YT0wMiU3QzAx JTdDbHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3QzU1MDYyOWIwMWZkYzQ1ZmJhMTkyMDhkNWQ1 MzIxZWU1JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYxYjMxMzAxZDlhZGYlN0MwJTdDMSU3QzYzNjY0 OTMzMzU5NjE1NDc0OCZzZGF0YT1RMSUyQkxkJTJGUHUlMkYweUs4ME5NNUVzN0ZxSXFDTkRmQmJw dzBMcmVMdEttQ3J3JTNEJnJlc2VydmVkPTA+DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydHotZGltZS1wb2xpY3lncm91cHMvPGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1iZXJ0ei1kaW1lLXBvbGljeWdy b3VwcyUyRiZkYXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHolNDBzcHJpbnQuY29tJTdDNTUwNjI5 YjAxZmRjNDVmYmExOTIwOGQ1ZDUzMjFlZTUlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFk OWFkZiU3QzAlN0MxJTdDNjM2NjQ5MzMzNTk2MTU0NzQ4JnNkYXRhPUk2a1VtZ3A1dHFiZVh2TTJX WEdyT1I2Skg4YzlmY2ZlUzd3Z3olMkIwdlVDWSUzRCZyZXNlcnZlZD0wPg0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0ei1kaW1lLXBvbGljeWdy b3Vwcy0wNjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWJlcnR6LWRpbWUt cG9saWN5Z3JvdXBzLTA2JmRhdGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20l N0M1NTA2MjliMDFmZGM0NWZiYTE5MjA4ZDVkNTMyMWVlNSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVm MWIzMTMwMWQ5YWRmJTdDMCU3QzElN0M2MzY2NDkzMzM1OTYxNTQ3NDgmc2RhdGE9MnQxNlZadWRk MzlxckZxenluVEpUMEZtU0tMZDFrZCUyQiUyRnJhNlRKOUtRTkUlM0QmcmVzZXJ2ZWQ9MD4NCkh0 bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWJlcnR6LWRpbWUtcG9saWN5Z3JvdXBzPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZodG1sJTJGZHJhZnQtYmVydHotZGltZS1wb2xpY3lncm91cHMmZGF0YT0wMiU3QzAxJTdD bHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3QzU1MDYyOWIwMWZkYzQ1ZmJhMTkyMDhkNWQ1MzIx ZWU1JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYxYjMxMzAxZDlhZGYlN0MwJTdDMSU3QzYzNjY0OTMz MzU5NjMxMDEyNiZzZGF0YT1RaVhZZ1U4U1dFVnQzaFJndXlVOWFxeGpobHolMkJXYmo0NXJBMnB0 UnpDTHclM0QmcmVzZXJ2ZWQ9MD4NCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtYmVydHotZGltZS1wb2xpY3lncm91cHMtMDY8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3 d3cuaWV0Zi5vcmclMkZyZmNkaWZmJTNGdXJsMiUzRGRyYWZ0LWJlcnR6LWRpbWUtcG9saWN5Z3Jv dXBzLTA2JmRhdGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0M1NTA2Mjli MDFmZGM0NWZiYTE5MjA4ZDVkNTMyMWVlNSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5 YWRmJTdDMCU3QzElN0M2MzY2NDkzMzM1OTYzMTAxMjYmc2RhdGE9NWtHSW1lVkxSb2tKWXVoNk1o Z1EzWlE0cVZ6RXVUJTJGbm5uQUhuUjA0QTdVJTNEJnJlc2VydmVkPTA+DQoNCkFic3RyYWN0Og0K ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIG9wdGlvbmFsIERpYW1ldGVyIGF0dHJpYnV0ZXMgZm9y IGVmZmljaWVudA0KICAgcG9saWN5IHByb3Zpc2lvbmluZy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcmZGF0YT0wMiU3QzAxJTdD bHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3QzU1MDYyOWIwMWZkYzQ1ZmJhMTkyMDhkNWQ1MzIx ZWU1JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYxYjMxMzAxZDlhZGYlN0MwJTdDMSU3QzYzNjY0OTMz MzU5NjMxMDEyNiZzZGF0YT1XUDRXWTF1UUtHM1dnQm1MN09Wckh4b1J3ckt5ZG0xYWJ5UHpYY3Rk dmRVJTNEJnJlc2VydmVkPTA+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmlu dCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0K --_000_85c9ea729d8c439ea3f3773bfb51a9bcplswe13m04adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoaXMgdmVyc2lvbiBpbmNsdWRlcyBmaWd1cmUgYW5kIHNwZWxsaW5nIHVw ZGF0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxicj4NCkx5bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0 OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogTW9uLCBKdW4gMTgsIDIwMTggYXQgMTA6MzQg QU08YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJlcnR6 LWRpbWUtcG9saWN5Z3JvdXBzLTA2LnR4dDxicj4NClRvOiBNYXJrIEJhbGVzICZsdDs8YSBocmVm PSJtYWlsdG86eWVsbG93amVlcDIwMTdAZ21haWwuY29tIj55ZWxsb3dqZWVwMjAxN0BnbWFpbC5j b208L2E+Jmd0OywgTHlsZSBCZXJ0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx5bGViZTU1MTE0NEBn bWFpbC5jb20iPmx5bGViZTU1MTE0NEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4N Cjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iZXJ0ei1kaW1lLXBvbGljeWdyb3Vw cy0wNi50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEx5bGUgQmVy dHogYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFt ZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWJlcnR6LWRp bWUtcG9saWN5Z3JvdXBzPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 MDY8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERpYW1ldGVy IFBvbGljeSBHcm91cHMgYW5kIFNldHM8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE4LTA2 LTE4PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlk dWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDExPGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaW50ZXJuZXQtZHJhZnRzJTJGZHJhZnQt YmVydHotZGltZS1wb2xpY3lncm91cHMtMDYudHh0JmFtcDtkYXRhPTAyJTdDMDElN0NseWxlLnQu YmVydHolNDBzcHJpbnQuY29tJTdDNTUwNjI5YjAxZmRjNDVmYmExOTIwOGQ1ZDUzMjFlZTUlN0M0 ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MxJTdDNjM2NjQ5MzMzNTk2MTU0 NzQ4JmFtcDtzZGF0YT1RMSUyQkxkJTJGUHUlMkYweUs4ME5NNUVzN0ZxSXFDTkRmQmJwdzBMcmVM dEttQ3J3JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmVydHotZGltZS1wb2xpY3lncm91cHMtMDYu dHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWJlcnR6LWRp bWUtcG9saWN5Z3JvdXBzJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHolNDBzcHJp bnQuY29tJTdDNTUwNjI5YjAxZmRjNDVmYmExOTIwOGQ1ZDUzMjFlZTUlN0M0ZjhiYzBhY2JkNzg0 YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MxJTdDNjM2NjQ5MzMzNTk2MTU0NzQ4JmFtcDtzZGF0 YT1JNmtVbWdwNXRxYmVYdk0yV1hHck9SNkpIOGM5ZmNmZVM3d2d6JTJCMHZVQ1klM0QmYW1wO3Jl c2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1iZXJ0ei1kaW1lLXBvbGljeWdyb3Vwcy88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0 bWwlMkZkcmFmdC1iZXJ0ei1kaW1lLXBvbGljeWdyb3Vwcy0wNiZhbXA7ZGF0YT0wMiU3QzAxJTdD bHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3QzU1MDYyOWIwMWZkYzQ1ZmJhMTkyMDhkNWQ1MzIx ZWU1JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYxYjMxMzAxZDlhZGYlN0MwJTdDMSU3QzYzNjY0OTMz MzU5NjE1NDc0OCZhbXA7c2RhdGE9MnQxNlZadWRkMzlxckZxenluVEpUMEZtU0tMZDFrZCUyQiUy RnJhNlRKOUtRTkUlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydHotZGltZS1wb2xpY3lncm91cHMtMDY8L2E+PGJy Pg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZk YXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1iZXJ0ei1kaW1lLXBvbGlj eWdyb3VwcyZhbXA7ZGF0YT0wMiU3QzAxJTdDbHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3QzU1 MDYyOWIwMWZkYzQ1ZmJhMTkyMDhkNWQ1MzIxZWU1JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYxYjMx MzAxZDlhZGYlN0MwJTdDMSU3QzYzNjY0OTMzMzU5NjMxMDEyNiZhbXA7c2RhdGE9UWlYWWdVOFNX RVZ0M2hSZ3V5VTlhcXhqaGx6JTJCV2JqNDVyQTJwdFJ6Q0x3JTNEJmFtcDtyZXNlcnZlZD0wIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1iZXJ0ei1kaW1lLXBvbGljeWdyb3VwczwvYT48YnI+DQpEaWZmOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZy ZmNkaWZmJTNGdXJsMiUzRGRyYWZ0LWJlcnR6LWRpbWUtcG9saWN5Z3JvdXBzLTA2JmFtcDtkYXRh PTAyJTdDMDElN0NseWxlLnQuYmVydHolNDBzcHJpbnQuY29tJTdDNTUwNjI5YjAxZmRjNDVmYmEx OTIwOGQ1ZDUzMjFlZTUlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0Mx JTdDNjM2NjQ5MzMzNTk2MzEwMTI2JmFtcDtzZGF0YT01a0dJbWVWTFJva0pZdWg2TWhnUTNaUTRx VnpFdVQlMkZubm5BSG5SMDRBN1UlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYmVydHotZGltZS1wb2xpY3ln cm91cHMtMDY8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMg ZG9jdW1lbnQgZGVmaW5lcyBvcHRpb25hbCBEaWFtZXRlciBhdHRyaWJ1dGVzIGZvciBlZmZpY2ll bnQ8YnI+DQombmJzcDsgJm5ic3A7cG9saWN5IHByb3Zpc2lvbmluZy48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGdG9vbHMu aWV0Zi5vcmcmYW1wO2RhdGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0M1 NTA2MjliMDFmZGM0NWZiYTE5MjA4ZDVkNTMyMWVlNSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIz MTMwMWQ5YWRmJTdDMCU3QzElN0M2MzY2NDkzMzM1OTYzMTAxMjYmYW1wO3NkYXRhPVdQNFdZMXVR S0czV2dCbUw3T1ZySHhvUndyS3lkbTFhYnlQelhjdGR2ZFUlM0QmYW1wO3Jlc2VydmVkPTAiIHRh cmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBT ZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxocj4N Cjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+PGJyPg0KVGhpcyBlLW1h aWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMg cHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2Uu PGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_85c9ea729d8c439ea3f3773bfb51a9bcplswe13m04adsprintcom_-- From nobody Mon Jun 18 08:55:36 2018 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C21130EC1 for ; Mon, 18 Jun 2018 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.211 X-Spam-Level: * X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1886D_GCTZs for ; Mon, 18 Jun 2018 08:55:25 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0104.outbound.protection.outlook.com [104.47.34.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA6D130EC6 for ; Mon, 18 Jun 2018 08:55:24 -0700 (PDT) Received: from SN4PR0501CA0095.namprd05.prod.outlook.com (2603:10b6:803:22::33) by BY1PR0501MB1224.namprd05.prod.outlook.com (2a01:111:e400:4806::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.14; Mon, 18 Jun 2018 15:55:23 +0000 Received: from BY2NAM01FT056.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::205) by SN4PR0501CA0095.outlook.office365.com (2603:10b6:803:22::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.884.15 via Frontend Transport; Mon, 18 Jun 2018 15:55:23 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by BY2NAM01FT056.mail.protection.outlook.com (10.152.68.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.863.11 via Frontend Transport; Mon, 18 Jun 2018 15:55:22 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w5IEkDXo017403 for ; Mon, 18 Jun 2018 11:55:21 -0400 Received: from prewe13m03.ad.sprint.com (prewe13m03.corp.sprint.com [144.226.128.22]) by preapdm3.corp.sprint.com with ESMTP id 2jmvt7g77s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 18 Jun 2018 11:55:21 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M03.ad.sprint.com (2002:90e2:8016::90e2:8016) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Jun 2018 11:55:20 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1367.000; Mon, 18 Jun 2018 10:55:20 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New Version Notification for draft-bertz-dime-predictunits-04.txt Thread-Index: AQHUBxyvC+DaWlfHKUqsAOEJ1vY1PKRmKy6Q Date: Mon, 18 Jun 2018 15:55:20 +0000 Message-ID: <89496d5992e6406890ea5baa82457294@plswe13m04.ad.sprint.com> References: <152933725591.3348.14827816439758054978.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.28] Content-Type: multipart/alternative; boundary="_000_89496d5992e6406890ea5baa82457294plswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(376002)(346002)(2980300002)(438002)(189003)(199004)(575784001)(86362001)(4546004)(126002)(478600001)(336012)(5640700003)(30436002)(14971765001)(97736004)(16586007)(72206003)(966005)(476003)(2906002)(426003)(316002)(6916009)(2501003)(186003)(606006)(102836004)(10710500007)(33964004)(59450400001)(5250100002)(24736004)(486006)(26005)(106466001)(5660300001)(6346003)(108616005)(2420400007)(106002)(53936002)(7696005)(2473003)(8936002)(229853002)(45080400002)(68736007)(6116002)(8676002)(54896002)(6306002)(7736002)(446003)(2900100001)(14454004)(15650500001)(236005)(11346002)(81156014)(790700001)(3846002)(356003)(84326002)(76176011)(2351001)(81166006)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1224; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT056; 1:y5fPtKaMkaqwwyzKFd+jQkW2C8yJRuN5sHCfftCtLGzXfsUwILFWzC0Tj1Ih0Pr/xQEU2YfS/kUmaJeuRBDGDnfmriDl6GGjAJXYK8npF4go4wHl13+DnQuYCJSkD195 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3bc885db-3f61-48a9-4136-08d5d533e681 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:BY1PR0501MB1224; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1224; 3:/W6BbomfnvEE225ce3yWqXtVHy/mmBMnOkoRgeeRxRfWRHi30q63o+pGjqK7lGBjJz+ZcvOSG9idrVJcQEy3ZgMp8e0ZjspoMpKS6uh4u2xX/cUherubxQmDOc3B3Kro1kChkwpWaUQJAEjt+1TyvGLlBhbULIZ5HNBE8JZFvWmtbNNqr2NQu7ugnwbx8PQ//uvxFhDZeJpDhxEvUcdH35iM/KvMn6stLMvJ800NJHcuomXByxQTL/oFGH4Z8XZ/2SXuQB+ude5Cy0D7hkj5sxZ2UsdnXPFIRq36A08eiQtZ5c1ZGJaiwCXcyg9Q4HIY5ZcmhgXVfVfbW0iqdjqOaGhiWoyRpArp9CS8IRRdhkg=; 25:bJVOBTFUMudhRaS24zqAV51b2LuMBeAGODWmoKqhOqS1FLJl2Wn3cu0zghQdBZ09dYlr+wo2R4pJoXdWdbF3Sc8Vji11nBT8b5lERsYAZKGQimxarZiU+jf68S17ZQZ6m3Aa8z1+0lBfGkyguD3m4gsecH/8rdhXMw1N/+EADp1wMAxFYjXezXLfhDT53NuhbRTaNLqbYs20UiDh3MpxoCCiNAV/TDb4OuRIX+FGGsov4JmzqHVU7iA6uSgOQnipSJ8uadZfDphK0E/5HRnDWvcJC6+UvlolkHxyPhdxr0RfxaiLNmw829fI0jWcG1AryGSC/3uab3aSJYvQO4g4cg== X-MS-TrafficTypeDiagnostic: BY1PR0501MB1224: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1224; 31:naVgUf8BCvyZmyzqoUIoNrycMWMUH1UcaBQTZ8GDZ8bFcBi7HJ21nAchyT67NPsN1QRi/0r6X2ltdriY7823BDfJ5uAzHtrYsa/rsExLQwT3QMyzddFcZj22xclHQg0Vy5PG2aaKv9EyIBqdjbREndh0/I2Qo2f5RvMKx4sMBI8Ocktpscr7rApltiN3u85XO+EMxXrMKq5Riq/BXvDK/h0rK92Hd/wqAt70hZUYBMA=; 20:dqQvdLCIsIGRhkRHIHFeVr0XbRGtOsoUkseSSnSEOsCdwS+i+Z+xS2Jh2yf71daIWMWMV3FcPL4E6Kh92kN19l54CRwjJMhElkrMIu+ORSeN3ZFefeCWfzA4D14fIrKLVuDPoTJi+luMd2XgC/YRqBQEXqbCpjsqUXL+W/OugNOupQTl3J6AkfdUm14gg7SzXHqDXbYqc0OSpsc7s6ufi3dhIbKmPu8AetOWxA05KEu1ugEg9SadCFRwXEE//OOBK/Ay/ZaRQOmPJcB1caHDlj10CmcQOfdbzsAoUJcOPuY33c0EV5FTiog1WOlnMWJ5ZfklSBSk9vMfw5JW6nHTb/6t5ndE6CZ5S3qq1ndR4B27NJxB0x+Cksid+V8mQtIrwhIsMxA/bzZlhSoPOQKotTQhMdNnHPvbDPkn6pdhVcvNHAv4SY1mGHEcXu9ZKyK9BVhp3lQtLzDS8V0tcr05znxXIsubyzwUUh9v3FzhHxpmq2PsM2Jh5tEqaVJQh2oM X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(28532068793085)(120809045254105)(189930954265078)(219752817060721)(21748063052155); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93004095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BY1PR0501MB1224; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1224; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1224; 4:sReITGyIC+6wxetD9YidxpSu+veTMgaPmepnav3egjpcaznla0cQlsGmuRR2ft7UUgzCA0OF3gZhHdXWLXDp4Tip5xs0rQCN5XxDUHyVPe3+JEVMRsxrq5RA8KUEorV+q/mjKgptfv1R0I+1dES7ocQEB4gcJuR3sLdK6G5cIiKAOoHgBQXIf+7/X4zbE24aFXCFElUZIdhW7ji/BLM3OoosY8CMyKMAumEBr27iP8DobKOR+CxdXnUcphCVs7QqbL0TkGB8TXNIblA3HGibqIOvjTNiaXismKOtEb2ZlDqm7KfmTsG2S/rFsg3xSLG26lSbfT1IoTxAtct8782v+/DVX/gCyFMneY6PKZY8l4urHM92a6EFAk0U3aAnw6Z/s/md0LC8OWI1k0M11qnKMfclTJH0f+KcHla1qvNTAC9wzA3HOfvpoBY7qfz+xLCEpJRfH2QPdbRI7I1hmy+6Bg== X-Forefront-PRVS: 0707248B64 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1224; 23:Xqecvzc/KyX1nlXoQXQ0AxxGpTO34Se5NhtLIk0?= =?us-ascii?Q?FPJ80Ar4Zk+hOkJ0R+Rr/WTVv/Wzd7pUMllzF4Q2VgCjaC8ZRIo8poebgIIY?= =?us-ascii?Q?R7wjG+qeGvTqxyQyAvrD/Eshj3SrM/e4JIQghUbSPDXnHFnx7Zhfov/PEQqv?= =?us-ascii?Q?izKT/EWQ2nAZzMlnqf64luKrXDfnHy4lLpDagYnnJJqtnmdFIWpwKxST38AU?= =?us-ascii?Q?FAnmK5ma7o9AAhBQF22aOaJZAx/umlgprlkeAZOxv+fl+D/JCiOkVsf6tp/C?= =?us-ascii?Q?Aiv7GJXRh5qA+b2Vq6+oR3+JjbVWDGVdA8XfBjCoK5k0K0lU8BqGm1Ghq1rS?= =?us-ascii?Q?vBFygUxzT7As9HmxDirb9BA0qrvdsnldFZQ8SigEw+CZS06LknxizLv/8QiP?= =?us-ascii?Q?h+TRtuoH9nGa12HnKh5z+TXUx7lE9Nj2bzJicjVGmJNLIZBuEZ7sxMRmPIeb?= =?us-ascii?Q?db0BiycvIisTrxrrT90UyA1N3LYrDN3yB9FG63kwlBXwF5SWU4Skq2nJhKOE?= =?us-ascii?Q?1zIkEf/CSMQXGIo5sZLkj/3Lm/FysIXujWbF7/Nbc9l68HN3dLSzOYnP+W+q?= =?us-ascii?Q?9h+qQCYPtQWZkI/l5+h7eawUU44BNFff4xYWFqA2eMwjYiU9wMClxTNIMDlR?= =?us-ascii?Q?tKcDFYuDUzGSTQGxlmDOFFjEevJ1hTpi9F3wXRKoUFfWQ/LEfwiFNHg85K87?= =?us-ascii?Q?3RqXGVCeRQzw00qkk9YcaFCvls1y7wXzlUhAp4To9Ge+d800Nc2T5m5mvgfl?= =?us-ascii?Q?BtQ4nXD0PtX0eXlN4TEfsqTTLQrhrlt1bbPCet1jIEbziK9Gn1sG5qvUEyG7?= =?us-ascii?Q?63TvsHSrkoJwqTYi7BEM4lR9MN/2AYWDL0IhCVVHxmPq6qR3/AZwsqgchipE?= =?us-ascii?Q?UqQ75U6BNZdcPovCnX3OJYo8KiChasfBvV2CzVde8jU/Z+MP9FghxhcoiAhy?= =?us-ascii?Q?fJp64aDD1fHwPMMXarAXg7kgZPScvY025DTrd1U52SVA+gzF79I/H0mkIbNv?= =?us-ascii?Q?ExTas1ksZvIQswXI4yVk4IsQIq8rhupMU5hbXbmbaqYEiIijGwatY7LlzN8x?= =?us-ascii?Q?TEBX037Z7pPovNnPnaspBQ5jOHjtSVaAI0kuNiI2EZxAiIA4VJ8kUba1GduV?= =?us-ascii?Q?u41wEkRnguO/fhqmADRItE+wGS30sEhjilU0eB3mWD9LoQp7eyEHdmYstgAx?= =?us-ascii?Q?5SmX9fKJbv+/hdzFOncG72qBeFAuln72ibR7byJFb+k0B+neUDtHHrZ66VKH?= =?us-ascii?Q?kae+LlOrkncryQIURtxsDZp9/zkCKRwZcAEiNek1Gt06vF6J+/OdGk2ZoV4C?= =?us-ascii?Q?r/paToFaInmhW7qyuE6h5rftqNNrAMPRKiDfAMPgxcgOF129RwbQ1U9JQOzi?= =?us-ascii?Q?X3xFNJTnG1U8m7LymOnUGGAsS6A+JSrrzdLFETbOvty7MFqAPfok8FoUq9wf?= =?us-ascii?Q?5FVJSU6/X0wNUP3BalIWCvY+5USrsaqI1iVD5mNF8ihcMSJcLgbGoExhFLvh?= =?us-ascii?Q?/XnQHp9idead7b5ASgNu2t9kjEJR8Zfg5IsnaU3jXl3b7mCrAHRu7UxDweIU?= =?us-ascii?Q?JkTkRNjHLbkDo1EgVJ88ijzNHVWukmaNwEaRaiUI=3D?= X-Microsoft-Antispam-Message-Info: Qozx5zyZBMtytWYM0NUwD2Y5P/xDLxs1pHSDaztQeCAoamTNVmjF9L/wrs6u1Ncv64Lly1DSs8d0NF0W8BuqFuUJmIb8ixHGLxAW/KodYD8x++Oq3YMH5fWGAlhxBVrX4d+j+LbACR1OJAOeLGMW+t2mgufIJOeks5cGgwjJmhN7nVusm95vY9SbMJznbs8dcrrCbqk4xOffKixGxB1pJ8v3ZgQ7el2X8HTfZLJMp8IlYrdkWe6AK18XyaMccRguLxVIKAcwH0xjFQcAYpWaRIAstAe+ZeDWQJNUmgicA5OAyYDRuXImNqZ3AuIPGERvYlETR8KwTwt26cxUWndkDA== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1224; 6:q6sTUPps40lNlhRdYXunRA6a63tRUEpBbliJ9ZtfbJ/YoODwc6LD9c0jZL6SjaIcCDat0iW7F9tjfNjQJ2wWNObtLWns/KVV+EYSWF7YEWl1YuZKN9Fuf1rJJ6pwbQEsDHOThNcYMJjPLrdECufLmvZ47mUOM6G82j3+VnlE4p3z3By/X0toFmtc5YqyUD8kAJcA0N/PsDxHbjnujTItEUTynwRUzSjBK2373ATjCkzirhB98oqyoQZ5qQxaMB/XVZ7GvBPC1lnbWYZAcWY8HzE/uhTKGwZXHpa464irskdwL0fuyTRE06DUygNWGu/smMOKYqLoWsL+6hhmg1SZ9HrqWUzS5lBnfXUQ0oVZzI9FsL6g+445YZKcKwyUY92kOfIMhu7KXcS74SRr/XeW+p4CR3qiIPQTeMt9lfur7qfj/6Zd95HlL9SZD1qp7m8SpKa7/zKXqyDDHYpiyMComA==; 5:urBzImPtG+BedXalRyQAbzKRf1+3E+7UqE7K1u7wGzCkd/stAuQkuDn7nr/LEGEJvHXxGtomoS3EGt9Ci5aqPYi1V8Lz+75N3AF9bKbIs70yVbcKNybHc0qeDI68FIADMC8EW7SixIb8SqPpM+11NmZXq7JbRORNYCHybOPkIok=; 24:K6pde8sqFjGxtZ8d2sarqMdnYhrZBAVpn1Ko8obDZtCzoOdwbBo03pdoiFUU0pvTlTPIWiJ5uICmMOVL2odf093r3RdaEtO4h6HolrBI/2w= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1224; 7:9UsZQsQdL/3OGYlnVZMsav9F8bT6kUj62wH/9U8nGaKUvAjSxXw9at7o7jqMPp2hWCkerTjAVdZo/LQDV1qlSihjD+eV/iGgAhF17edTifjSyt3bwqqI1NPG5Y6ncDG0wzyyoLtTJ+bnbARxFGKiIRcfvqrcQuOjxIl1is5DZ8yBcWnJv1lTkq8QuUcJk3Ha+ICB4CHyGRtowvB+TPRSfsbcJv1H7o1Jbk4Ea8ZQgREdTMtwD3jrAagOcWU8gk/b X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2018 15:55:22.7415 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3bc885db-3f61-48a9-4136-08d5d533e681 X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1224 Archived-At: Subject: [Dime] FW: New Version Notification for draft-bertz-dime-predictunits-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 15:55:31 -0000 --_000_89496d5992e6406890ea5baa82457294plswe13m04adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmVyc2lvbiBidW1wIG9ubHkNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVydHot ZGltZS1wcmVkaWN0dW5pdHMtMDQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEx5bGUgQmVydHogYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogICAgICAgICAgIGRyYWZ0LWJlcnR6LWRpbWUtcHJlZGljdHVuaXRzDQpSZXZpc2lvbjogICAg ICAgMDQNClRpdGxlOiAgICAgICAgICBEaWFtZXRlciBQcmVkaWN0ZWQgVW5pdHMNCkRvY3VtZW50 IGRhdGU6ICAyMDE4LTA2LTE4DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczogICAgICAgICAgNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iZXJ0ei1kaW1lLXByZWRpY3R1bml0cy0wNC50eHQ8aHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ3d3cuaWV0Zi5vcmclMkZpbnRlcm5ldC1kcmFmdHMlMkZkcmFmdC1iZXJ0ei1kaW1lLXBy ZWRpY3R1bml0cy0wNC50eHQmZGF0YT0wMiU3QzAxJTdDbHlsZS50LmJlcnR6JTQwc3ByaW50LmNv bSU3QzQ4ODYyNjkwMWZmOTRhODhjMTliMDhkNWQ1MzNjZjg2JTdDNGY4YmMwYWNiZDc4NGJmNWI1 NWYxYjMxMzAxZDlhZGYlN0MwJTdDMSU3QzYzNjY0OTM0MDg1NTQwNjcwMiZzZGF0YT00bHEyaTBR ZW0lMkZ4JTJGbFhuNGM5amZzJTJCTlhDUVJUQ0h3ZDZKUjB1V0I4eFhJJTNEJnJlc2VydmVkPTA+ DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt YmVydHotZGltZS1wcmVkaWN0dW5pdHMvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZkcmFmdC1iZXJ0ei1kaW1lLXByZWRpY3R1bml0cyUyRiZkYXRhPTAyJTdDMDElN0NseWxl LnQuYmVydHolNDBzcHJpbnQuY29tJTdDNDg4NjI2OTAxZmY5NGE4OGMxOWIwOGQ1ZDUzM2NmODYl N0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MxJTdDNjM2NjQ5MzQwODU1 NDE2NzEyJnNkYXRhPTVROHhsSk5iRURNMGs4cmFSQ0RCQVV3djlJeDhRNlhtbDdoR0xUUCUyQjBt YyUzRCZyZXNlcnZlZD0wPg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1iZXJ0ei1kaW1lLXByZWRpY3R1bml0cy0wNDxodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYu b3JnJTJGaHRtbCUyRmRyYWZ0LWJlcnR6LWRpbWUtcHJlZGljdHVuaXRzLTA0JmRhdGE9MDIlN0Mw MSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0M0ODg2MjY5MDFmZjk0YTg4YzE5YjA4ZDVk NTMzY2Y4NiU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3QzElN0M2MzY2 NDkzNDA4NTU0MTY3MTImc2RhdGE9bzhvMlZZdENYWUhROFZ4WVZuSHNCUXFSSWpXencwWjIwRUtK OTZUalRYMCUzRCZyZXNlcnZlZD0wPg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYmVydHotZGltZS1wcmVkaWN0dW5pdHM8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1iZXJ0ei1kaW1lLXBy ZWRpY3R1bml0cyZkYXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHolNDBzcHJpbnQuY29tJTdDNDg4 NjI2OTAxZmY5NGE4OGMxOWIwOGQ1ZDUzM2NmODYlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEz MDFkOWFkZiU3QzAlN0MxJTdDNjM2NjQ5MzQwODU1NDI2NzIxJnNkYXRhPVlmeiUyQjlmeEpOajdo biUyRjMydXk0T3doaGpuTk5NdU5FQmpFV3lSNmtmb1BjJTNEJnJlc2VydmVkPTA+DQpEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJlcnR6LWRp bWUtcHJlZGljdHVuaXRzLTA0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGcmZjZGlmZiUzRnVybDIl M0RkcmFmdC1iZXJ0ei1kaW1lLXByZWRpY3R1bml0cy0wNCZkYXRhPTAyJTdDMDElN0NseWxlLnQu YmVydHolNDBzcHJpbnQuY29tJTdDNDg4NjI2OTAxZmY5NGE4OGMxOWIwOGQ1ZDUzM2NmODYlN0M0 ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MxJTdDNjM2NjQ5MzQwODU1NDI2 NzIxJnNkYXRhPUc0T3MzV09uRXJXQjh4QU9Ga0VSd25XR2tzaGpHUDZ4eU5QU3pOZHc0VGslM0Qm cmVzZXJ2ZWQ9MD4NCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUg Y29udmV5YW5jZSBvZiBwcmVkaWN0ZWQgdXNhZ2UgaW5mb3JtYXRpb24NCiAgIGZvciBwcm9wZXIg ZGltZW5zaW9uaW5nIG9mIG5ldHdvcmsgc2VydmljZXMgdGhhdCB1c2UgRGlhbWV0ZXIgYmFzZWQN CiAgIGF1dGhvcml6YXRpb24uDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmc8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cCUzQSUyRiUyRnRvb2xzLmlldGYub3JnJmRhdGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNw cmludC5jb20lN0M0ODg2MjY5MDFmZjk0YTg4YzE5YjA4ZDVkNTMzY2Y4NiU3QzRmOGJjMGFjYmQ3 ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3QzElN0M2MzY2NDkzNDA4NTU0MzY3MjYmc2RhdGE9 ZVh0MmpqQ2NleGxnckllWUJsbjUyR3BYN01DQlliaVBjdDB0bVlPMEFmTSUzRCZyZXNlcnZlZD0w Pi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBB bnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNv cGllcyBvZiB0aGUgbWVzc2FnZS4NCg== --_000_89496d5992e6406890ea5baa82457294plswe13m04adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5WZXJzaW9uIGJ1 bXAgb25seTwvc3Bhbj48L2I+PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWJlcnR6LWRpbWUtcHJlZGljdHVuaXRzLTA0LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgTHlsZSBCZXJ0eiBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZHJhZnQtYmVydHotZGltZS1wcmVkaWN0dW5pdHM8YnI+DQpSZXZpc2lv bjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswNDxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRGlhbWV0ZXIgUHJlZGljdGVkIFVuaXRzPGJyPg0KRG9jdW1l bnQgZGF0ZTombmJzcDsgMjAxOC0wNi0xODxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA3PGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaW50 ZXJuZXQtZHJhZnRzJTJGZHJhZnQtYmVydHotZGltZS1wcmVkaWN0dW5pdHMtMDQudHh0JmFtcDtk YXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHolNDBzcHJpbnQuY29tJTdDNDg4NjI2OTAxZmY5NGE4 OGMxOWIwOGQ1ZDUzM2NmODYlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAl N0MxJTdDNjM2NjQ5MzQwODU1NDA2NzAyJmFtcDtzZGF0YT00bHEyaTBRZW0lMkZ4JTJGbFhuNGM5 amZzJTJCTlhDUVJUQ0h3ZDZKUjB1V0I4eFhJJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmVydHot ZGltZS1wcmVkaWN0dW5pdHMtMDQudHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUy RmRvYyUyRmRyYWZ0LWJlcnR6LWRpbWUtcHJlZGljdHVuaXRzJTJGJmFtcDtkYXRhPTAyJTdDMDEl N0NseWxlLnQuYmVydHolNDBzcHJpbnQuY29tJTdDNDg4NjI2OTAxZmY5NGE4OGMxOWIwOGQ1ZDUz M2NmODYlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MxJTdDNjM2NjQ5 MzQwODU1NDE2NzEyJmFtcDtzZGF0YT01UTh4bEpOYkVETTBrOHJhUkNEQkFVd3Y5SXg4UTZYbWw3 aEdMVFAlMkIwbWMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0ei1kaW1lLXByZWRpY3R1bml0cy88L2E+ PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1iZXJ0ei1kaW1lLXByZWRpY3R1bml0cy0w NCZhbXA7ZGF0YT0wMiU3QzAxJTdDbHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3QzQ4ODYyNjkw MWZmOTRhODhjMTliMDhkNWQ1MzNjZjg2JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYxYjMxMzAxZDlh ZGYlN0MwJTdDMSU3QzYzNjY0OTM0MDg1NTQxNjcxMiZhbXA7c2RhdGE9bzhvMlZZdENYWUhROFZ4 WVZuSHNCUXFSSWpXencwWjIwRUtKOTZUalRYMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0ei1kaW1lLXByZWRp Y3R1bml0cy0wNDwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0 LWJlcnR6LWRpbWUtcHJlZGljdHVuaXRzJmFtcDtkYXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHol NDBzcHJpbnQuY29tJTdDNDg4NjI2OTAxZmY5NGE4OGMxOWIwOGQ1ZDUzM2NmODYlN0M0ZjhiYzBh Y2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MxJTdDNjM2NjQ5MzQwODU1NDI2NzIxJmFt cDtzZGF0YT1ZZnolMkI5ZnhKTmo3aG4lMkYzMnV5NE93aGhqbk5OTXVORUJqRVd5UjZrZm9QYyUz RCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYmVydHotZGltZS1wcmVkaWN0dW5pdHM8L2E+PGJyPg0KRGlm ZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGcmZjZGlmZiUzRnVybDIlM0RkcmFmdC1iZXJ0ei1kaW1lLXByZWRp Y3R1bml0cy0wNCZhbXA7ZGF0YT0wMiU3QzAxJTdDbHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3 QzQ4ODYyNjkwMWZmOTRhODhjMTliMDhkNWQ1MzNjZjg2JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYx YjMxMzAxZDlhZGYlN0MwJTdDMSU3QzYzNjY0OTM0MDg1NTQyNjcyMSZhbXA7c2RhdGE9RzRPczNX T25FcldCOHhBT0ZrRVJ3bldHa3NoakdQNnh5TlBTek5kdzRUayUzRCZhbXA7cmVzZXJ2ZWQ9MCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1i ZXJ0ei1kaW1lLXByZWRpY3R1bml0cy0wNDwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQom bmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGNvbnZleWFuY2Ugb2YgcHJl ZGljdGVkIHVzYWdlIGluZm9ybWF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwO2ZvciBwcm9wZXIgZGlt ZW5zaW9uaW5nIG9mIG5ldHdvcmsgc2VydmljZXMgdGhhdCB1c2UgRGlhbWV0ZXIgYmFzZWQ8YnI+ DQombmJzcDsgJm5ic3A7YXV0aG9yaXphdGlvbi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcmYW1w O2RhdGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0M0ODg2MjY5MDFmZjk0 YTg4YzE5YjA4ZDVkNTMzY2Y4NiU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdD MCU3QzElN0M2MzY2NDkzNDA4NTU0MzY3MjYmYW1wO3NkYXRhPWVYdDJqakNjZXhsZ3JJZVlCbG41 MkdwWDdNQ0JZYmlQY3QwdG1ZTzBBZk0lM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r Ij4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6 ZT0iMSI+PGJyPg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGlu Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4g QW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBj b3BpZXMgb2YgdGhlIG1lc3NhZ2UuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_89496d5992e6406890ea5baa82457294plswe13m04adsprintcom_-- From nobody Tue Jun 26 14:09:07 2018 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE68130E5D for ; Tue, 26 Jun 2018 14:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uObscVHzy1H9 for ; Tue, 26 Jun 2018 14:09:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1B6130E42 for ; Tue, 26 Jun 2018 14:09:02 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5QL8vwX007603 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jun 2018 16:08:58 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <2C4A8F89-9FB1-483F-B160-52822F71531F@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4EAE7243-9599-4BF7-824F-20D54D2BD053"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 26 Jun 2018 16:08:56 -0500 In-Reply-To: <8B34DBC2-3A66-43CB-A9B2-4CB51C36E062@nostrum.com> Cc: ecnoel@research.att.com, dime@ietf.org To: Steve Donovan References: <8FB01050-7B63-4A1B-B50A-974D0FA448C4@nostrum.com> <06dc2172-4b2a-c0c4-e411-8928acd13a1b@usdonovans.com> <8B34DBC2-3A66-43CB-A9B2-4CB51C36E062@nostrum.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Dime] draft-ietf-dime-doic-rate-control-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 21:09:06 -0000 --Apple-Mail=_4EAE7243-9599-4BF7-824F-20D54D2BD053 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 14, 2018, at 4:38 PM, Ben Campbell wrote: >=20 > Hi, >=20 > See my responses inline. I removed sections that seem resolved. >=20 > Thanks, >=20 > Ben. >=20 >> On Jun 13, 2018, at 12:30 PM, Steve Donovan = wrote: >>=20 >> See my comments inline. >>=20 >> Steve >>=20 >> On 5/25/18 4:17 PM, Gunn, Janet P (CNV) wrote: >>> Not an author, but I have a strong interest in this ID. Comments in = line. >>> Janet >>>=20 >>> -----Original Message----- >>> From: DiME On Behalf Of Ben Campbell >>> Sent: Wednesday, May 16, 2018 1:31 AM >>> To: draft-ietf-dime-doic-rate-control.all@ietf.org >>> Cc: dime@ietf.org >>> Subject: [Dime] draft-ietf-dime-doic-rate-control-08 >>>=20 >>> Substantive Comments: >>>=20 >>> General: >>> The document seems inconsistent about whether rate limits are only = reported during overload conditions, or in advance of overload = conditions. >>>=20 >>> I think that would be "local policy" of the serving = (reporting) node, and independent of the protocol used to communicate = it. I think most cases would be reactive, but I can see situations = where it could be proactive. >> SRD> I agree with Janet, when the report is sent is very much local = policy. There is no reason to attempt to prevent proactive use of the = rate mechanism. >=20 > That=E2=80=99s fine with me, but a sentence or two to that effect = would be helpful. (On re-reading, I see where section 1 talks about = =E2=80=9Capproaching overload or overloaded=E2=80=9D, but I assume = neither of those conditions are necessary?) >=20 >>>=20 >>> I=E2=80=99d like to see the need to allocate the rate limit across = all potential sources of traffic given some more emphasis. (Maybe a = sub-section of its own?) >>>=20 >>> I agree, but again I see that as "local policy" of the serving = (reporting) node. In particular, there may be reacting nodes that do not = support the rate abatement algorithm. >> SRD> Again, I agree with Janet. This is local policy and there may = well be a mix of rate and loss if not all nodes support rate. I don't = think it is appropriate to say that rate should be preferred over loss. = But maybe I'm missing your meaning on "allocate the rate limit=E2=80=9D. >=20 > Okay, but you still have to allocate the rate limit across all sources = that you apply the rate algorithm to, right? That is, the total offered = rate will be something like (average rate per source) * (number of = sources). Or am I misunderstanding something? >=20 >=20 >>>=20 >>>=20 >>> =C2=A71: >>> - =E2=80=9C While this can effectively decrease the load handled by = the >>> server, it does not directly address cases where the rate of arrival >>> of service requests increases quickly." >>>=20 >>> I think it fails to address cases where the load changes rapidly in = either direction, right? At least, the following text seems to say that. >>>=20 >>> I agree. When there are rapid fluctuations in the offered = load, the "loss" algorithm errs both in throttling TOO MUCH when there = is a dip in offered load, and throttling NOT ENOUGH when there is a = spike in offered load. >> SRD> The text in section 1 talks about this already. Is there a = specific change being suggested? >=20 > Section 1 talks about rapidly increasing load. Did I miss mention of = rapidly _decreasing_ load? >=20 >>>=20 >>>=20 >>>=20 >>> =C2=A73: Does the need for future report types to consider the rate = algorithm have IANA implications? >> SRD> Are you suggesting that the IANA section indicate that all new = report types MUST indicate whether or not the rate algorithm can be used = with that report type? I can make that change to the IANA section if it = would be appropriate. >>>=20 >=20 > I=E2=80=99m not suggesting, I=E2=80=99m asking :-) But my point was = more along whether the IANA registry for report types should include a = field about supporting the rate algorithm. >=20 >=20 >>> =C2=A75.1: The first paragraph indicates state should be kept for = every reacting node to which it sends an OLR. But the 5th paragraph can = be interpreted to say it sends an OLR to every reacting node with which = it has negotiated use of the rate algorithm. (see general comment). >> SRD> I'm missing something. The first paragraph says the reporting = node maintains state any time it sends a rate overload report. The = fifth paragraph is just saying that the report must include the rate = information. >=20 > Actually, my question relates to my question on 5.4. The first = paragraph says to keep state for every reporting node to which it sends = an OLR. The 5th paragraph implies that it sends on OLR when it selects = the rate algorithm for a reacting node. (If you are going to include the = rate info, you have to have a report to include it in.) >=20 > So it comes down to clarity about what events happen =E2=80=9Cwhen the = reporting node selects the algorithm for a reacting node=E2=80=9D vs = =E2=80=9Cwhen the reporting node sends an OLR=E2=80=9D. >=20 >>>=20 >>> =C2=A75.4: The first paragraph seems to suggest the reacting node = keeps OCS for every server that has indicated support for the rate = algorithm, not just nodes that have sent OLRs. Is that the intent? >> SRD> Yes, that is the intent. This allows the reacting node to make = sure that the machinery needed to respond to a rate request is in place = prior to receiving an OLR. >=20 > See above. >=20 >=20 >>>=20 >>> =C2=A75.6, first paragraph: The MAY seems week here. I know and = agree that we don=E2=80=99t want to force a particular application. But = don=E2=80=99t we need to say that if an implementation uses a different = algorithm, it MUST have the same behavior as the algorithm in section 7? >>>=20 >>> I think it MUST "limit the message rate to the OC-Maximum-Rate = AVP value in units of messages per second" (as stated in 7.3.1). The = algorithm described in the rest of 7.3.1 and 7.3.2 is somewhat more = sophisticated, allowing for a smoothing factor (TAU) and prioritization. = I do not think we need to say that the selected algorithm MUST have = those features. >> SRD> Again, I agree with Janet. >=20 > Okay. >=20 >=20 >>>=20 >>> =C2=A77.2, third and 4th paragraphs: I don=E2=80=99t understand what = this is trying to say. Please elaborate. >>>=20 >>> 3rd para - Just as a "for instance"- if the reacting node has = 50/second low priority messages and 50/second high priority messages = that it want to send, and has a rate limit of 75/second, it will send = 25/second low priority messages and 50 /second high priority messages. = The limit of 75/second applies to the combined stream of high and low = priority messages, even though only the low priority messages are being = abated. >>>=20 >>> 4th para - in the same example, it could be that the high = priority messages typically require more processing resources (cpu, etc) = than the low priority messages (or vice versa). So cutting the rate to = 75/sec may NOT produce the expected reduction in resource usage. >> SRD> Thanks Janet, I couldn't have explained it better. >=20 > Janet=E2=80=99s explanation is good, but I don=E2=80=99t get that from = the text, at least in the case of the third paragraph. >=20 > In the 4th paragraph, I don=E2=80=99t understand how the reporting = node would =E2=80=9Ctake into account the workload=E2=80=9D in a useful = way. That seems to suggest the reporting node can predict the impact of = workload based decisions made by the reacting node, which seems unlikely = unless there is some out-of-band agreement. >=20 > Is this really saying anything more than =E2=80=9CThe reacting nodes = will decide which messages to send and which to drop, and the result may = not be predictable by the reporting node=E2=80=9D? >=20 >=20 >=20 >>>=20 >>>=20 >>> -6th paragraph: =E2=80=9C may receive requests at a rate below its = target maximum Diameter request rate while others above that target = rate. But the resulting request rate presented to the overloaded = reporting node will converge towards the target Diameter request = rate.=E2=80=9D >>>=20 >>> Why do we expect traffic to converge to the rate limit? It seems = like that won't happen if some reporting nodes are not sending at full = capacity, unless work can be shifted from the high-rate sources to the = slow-rate ones. >>>=20 >>> Probably would be better to say that it "will converge toward = a rate at or below the target Diameter request rate.=E2=80=9D >> SRD> I'm okay with making Janet's suggested change. >=20 > WFM. >=20 >=20 >>>=20 >>> =C2=A77.3.1: paragraph starting with =E2=80=9C In situations where = reacting nodes are configured with some knowledge=E2=80=9D >>>=20 >>> that requires knowledge of other traffic sources, not just knowledge = of the reporting node. >>>=20 >>> The example code says to transmit a message if (Xp <=3D TAU). But = the text said the limit was =E2=80=9CT+TAU). >>>=20 >>> I think it is supposed to be "T+TAU" >> SRD> I'd like to get Eric's opinion on this. This section was copied = from the SOC RFC so if it is in error here than it is in error there as = well. >=20 > I agree with getting Eric=E2=80=99s opinion :-) >=20 >=20 >>>=20 >>> =C2=A79: I think the security considerations need more thought. What = are the security considerations specific to the rate algorithm? If there = aren=E2=80=99t any, then please describe the rational behind that. But I = suspect there are, for example, can this be used for a DoS? Can it be = used to help _mitigate_ a DoS? Could one reacting node cause others to = be traffic starved? >>>=20 >>> It is possible that a reacting node that does not support = overload control could starve the nodes that do support overload = control, but this is also true of the loss based version >> SRD> I'm not convinced that there are security scenarios that are new = or different for rate versus those documented in the existing DOIC = specifications. >=20 > This draft adds a new feature that isn=E2=80=99t in the base = mechanism. I gather your point is to say that the new feature shares the = same security considerations as the base, and adds no new ones. Right = now, section 9 only states the former. >=20 >>>=20 >>> Editorial Comments: >>>=20 >>> General: IDNits returns several issues. Some of those may be errors = on its part, but I=E2=80=99m pretty sure some of them are real. Please = resolve these. >> SRD> I'll look at those next time I try to submit but I've not gotten = IDNits errors in the past. >>=20 >> SRD> I've made the suggested changes below unless indicated = otherwise. >>>=20 >=20 > =E2=80=A6 and I=E2=80=99ve deleted sections that seem resolved. >=20 > [=E2=80=A6] >=20 >=20 >>>=20 >>> =C2=A75.1, third paragraph: The text is not clear whether this means = OCS should be maintained per supported application, etc, or that it = should maintain state when the rate algorithm on a per supported = application, etc, basis. >> SRD> I don't understand the point being made here. >=20 > Probably because I failed to make it. >=20 > I _think_ that the reporting node keeps state for each reporting node = for which it selects rate, and further needs to subdivide that state by = application and report type. But the it doesn=E2=80=99t need to keep = state for a reporting node for which it doesn=E2=80=99t select rate, = even though that reporting node might have an application in common with = the first reporting node? >=20 > [=E2=80=A6] >=20 >=20 >>>=20 >>> =C2=A76.1.1, definition of " OLR_RATE_ALGORITHM=E2=80=9D: Two = periods at end of sentence. >>>=20 >> SRD> I am hesitant to change any of the test in section 7 given that = it is taken from the SOC specification. I would prefer that Eric = comment on these proposed changes before including them in the next = version. >=20 > Makes sense. >=20 >>> =C2=A77.1, 2nd paragraph: =E2=80=9C signal one another support for = rate-based overload >>> control=E2=80=9D: This seems awkward; are there missing words? >>>=20 >>> =C2=A77.2, last two paragraphs: The MUSTs do not seem necessary. = 2119 keywords should be used when there is some sort of choice or room = for error. You don=E2=80=99t need them to define the basic operation of = the protocol. >>>=20 >>> =C2=A77.3.1: I found the text hard to follow. It would help to = declare all the identifiers and initialization up front, and to present = things in more of a stepwise fashion. >>>=20 >>> - T is effectively a time interval, right? It would help to say = that, especially later when you subtract a different time interval from = it. >>>=20 >>> - paragraph 9: Should =E2=80=9Cadmit=E2=80=9D be =E2=80=9Cemit=E2=80=9D= ? >>>=20 >>> - the example code has several mentions of SIP requests. >>>=20 >>> =C2=A77.3.2: =E2=80=9C Request candidates for reduction, requests = not subject to reduction (except under extenuating circumstances when = there aren=E2=80=99t any messages in the first category that can be = reduced).=E2=80=9D: That seems like an awkward way to say that the = second category is the set of requests that is only subject to reduction = if there are no messages left in the first category. >>>=20 >>> Yes, that is what it means. >>>=20 >>> - =E2=80=9C This can be generalized to n priorities using n = thresholds for n>2 in the obvious way.=E2=80=9D: I suggest you refrain = from calling it =E2=80=9Cobvious". >>>=20 >>> =C2=A77.3.3: Paragraph starting with =E2=80=9C Then (only) if the = arrival is admitted, increase the bucket by an amount=E2=80=A6=E2=80=9D: = I think you increase the bucket _count_, right? >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> This electronic message transmission contains information from CSRA = that may be attorney-client privileged, proprietary or confidential. The = information in this message is intended only for use by the = individual(s) to whom it is addressed. If you believe you have received = this message in error, please contact me immediately and be aware that = any use, disclosure, copying or distribution of the contents of this = message is strictly prohibited. NOTE: Regardless of content, this email = shall not operate to bind CSRA to any order or other contract unless = pursuant to explicit written agreement or government initiative = expressly permitting the use of email for such purpose. >>> _______________________________________________ >>> 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 >=20 --Apple-Mail=_4EAE7243-9599-4BF7-824F-20D54D2BD053 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsyq2gACgkQgFZKbJXz 1A2amxAAwdKDEFIYXxTB5lMMAN/Buyo+jt+LleEOm/BOzO7uEjLqW1gVFNnSHvv+ w5miXpuxAkGEpnIFswfDw8ggUeHKgcEhcEwfvhh//53n8jORc9QVPciDoqH2JYH0 +xCnvEvg8xg3mhkikrlXQT5m4qIHYKRYoQ+TpkVOi31cXBH8bl2qRebTrmmQTlgH 8hXGK3MfbX84kdTRP0GdgjKyA3yLQvUiogvsvZ3uTQmSZ5HEHEFK7Wf02ZzbP8B4 VPrAozYo5AiuDVj0wvqVV/AANo2Q3kn4ZZ3mg33rNkOG2jQOUzLym1oesb5/3dOH VmvQaMkogpR6YdeR7gFyTe3DesKZ+GzhUqmSEDjxg/rwZuCg2aW71glR7nOt55Pr ECwoWos8vCcNHKIj6kI5J59euiXDQzO+UBhFpqETN9ZEa1vYQlPptTJPL6LopYHy UDMd/byU2J49CT4iijPppQCz+nBGlR43KyjQ1KJUL8Z359Zx/MTROvZ/a8SQ1Rik df+kBtHPgoSz7DcNWK5S9BHnT8AEsuP7ofPg6tJhk2/VMweB2lktR5yYau4UvnBo B5vkKIKUw7BZHiJJ19ydwzC4qy11bYMYP71QtGrTNiBmNvIoMNAz0clw5rQ8yjzu NvjB2jocpq0pGYYx5ZcJpmBLAOC+SE70pzPpL9yjIodpBvGfi/0= =RDpX -----END PGP SIGNATURE----- --Apple-Mail=_4EAE7243-9599-4BF7-824F-20D54D2BD053--